:: Re: [DNG] ifconfig vs ip
トップ ページ
このメッセージを削除
このメッセージに返信
著者: Rainer Weikusat
日付:  
To: dng
題目: Re: [DNG] ifconfig vs ip
Rainer Weikusat <rweikusat@???> writes:
> Simon Walter <simon@???> writes:
>> I am working on some cdist scripts for setting up some network interfaces.
>>
>> So far I am modifying the /etc/network/interfaces and then bring down
>> and up the interfaces. For a while now /etc/init.d/networking has a
>> warning that it is deprecated. I understand why. So I issue:
>> # ip address flush dev xxx && ip link set xxx down
>>
>> Which seems to work fine. However, when I try to bring the device back
>> up with the new config with "ifup xxx"
>> It fails. If I first issue a "ifdown xxx" then it works.
>
> ifupdown uses a state file (/etc/network/run/ifstate) to record which
> interfaces are up and ifup refuses to activate an interface recorded as
> active. You could remove the relevant interface entries manually,
> however, a more sensible course of action is
>
> 1. ifown <iface>
> 2. modify interfaces definition
> 3. ifup <iface>


Additional explanation for that: ifupdown supports triggering additional
actions upon interface up/ down either by putting scripts into
/etc/network/if*.d directories or adding commands to the
/etc/network/interfaces stanzas. This means an interface can only be
brought down cleanly using the same configuration used to bring it up
(unless the corresponding actions are initiated manually as needed). It
can then be reconfigured as desired, possibly including the changing
scripts/ commands and brought up again.

This stop-modify-restart is a bit coarse-grained and it's also possible
to do this manually without 'interface downtime' but there's no general
interface for that: The sequence of commands will depend on both the
running configuration and the desired configuration and has to be worked
out beforehand and then executed. Considering that the modified
interfaces file can be created before causing any side effects and then
be swapped atomically via mv in between the down and the up, 'play nice
with the system' is IMHO a better idea.

Changing the stored configuration while the interface is up bound to
cause trouble unless care is taken to ensure that this can be
interrupted at any point (imagine a sudden power outage) with the system
still remaining in or capable of returning to an operational state.