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?
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
