[systemd-devel] networkd link state

["Jóhann B. Guðmundsson"]

On 12/04/2014 04:36 PM, Brendan Hide wrote:
> On 2014/12/04 17:54, "Jóhann B. Guðmundsson" wrote:
>>
>> On 12/04/2014 03:47 PM, O Neill, David M wrote:
>>> What do you think?
>>
>> I think this should be consisted with other unit enablement in 
>> systemd not handled by introducing a new enabled/disabled "flag"
> I think the idea has some merit. But I also think a *new* flag isn't 
> the right, especially since we already have flags that (mostly) 
> achieve this already.
>
> Also, config-wise, admins don't work with separate unit files for 
> every network interface - we have .net{dev,work} files.
>
> br0.netdev:
> [NetDev]
> Name=br0
> Kind=dummy
> #^ currently valid, though I don't know what the results would be.
> #Kind=bridge
>
> enp0s25.network:
> [Match]
> Name=enp0s25
> [Network]
> DHCP=none
> #^ currently valid, though I don't know what the results would be.
> #Bridge=br0
>
> The problem with this is that it could still be configured, even if in 
> a broken state, where the admin might want that it leave the device 
> alone completely or disabled (as in `ip link set enp0s25 down`). This 
> might also cause a lot of noise in the logs if the config "breakage" 
> isn't static. Again, I haven't tested and I don't know what the actual 
> results would be.
>
> Alternatively:
> By {en,dis}able, we usually simply adjust whether or not a file will 
> be found in a location. For example, renaming the file would work to a 
> degree:
> mv /etc/systemd/network/enp0s25.network{,.disable}
>
> The only problem I see with this strategy would be if you have 
> multiple rulesets with wildcards. For example you have this .disabled 
> config for enp0s25 but you also have a less-specific ruleset for en* 
> in a second (non-disabled) config. That less-specific ruleset could 
> enable the interface with an unwanted configuration.
>

To be consistent with construction of other type units we would have to 
introduce [Install] section and .network type units would have to be 
enabled/disabled ( most likely by create symlinks in network.target ) 
tjhen administrators simply run systemctl enable enp0s25.network or 
systemctl enable br0.netdev etc.

Tom probably has some insight why this route was not choicen to begin 
with in the overall design to handle enable/disable (if up/down ) of 
network devices?