[systemd-devel] networkd link state

[Brendan Hide]

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.

-- 
__________
Brendan Hide
http://swiftspirit.co.za/
http://www.webafrica.co.za/?AFF1E97