Does anybody have experience with both systems enough to compare them?
I'm currently using ifupdown on my Debian server as that's the default, but it seems that the modern way of managing the local network is via systemd-networkd so I'm contemplating putting the effort in to migrate.
Would those of you who have experience with it, recommend it?
In my short investigation, I have made the following observations:
- using networkd means you can use networkctl to manually control the interfaces which is quite convenient
- networkd aims to be fully declarative
- networkd separates the creation of virtual interfaces (netdev files) from their configuration (network files)
- networkd doesn't support all networking features (e.g. namespaces)
- networkd is systemd, but surprisingly I can't find information on how to create other unit files that depend on the individual network files going up or down, other than networkd-dispatcher. I don't like dispatcher because just like ifupdown it triggers all the scripts and you need if tests to exclude all interfaces you don't need to be affected. I'd like to write unit files that can be targeted to activate and deactivate when a particular interface goes up or down.
- networkd, other than via dispatcher, does not seem to support adding arbitrary commands to run like ifupdown supports via e.g. pre-down, post-up, etc.
TCB13@lemmy.world 1 year ago
First thing I do after every server Debian install: remove that old networking, remove chrony, install systemd-networkd, systemd-resolved, systemd-timesyncd. Why? Because 1) you get a way cleaner system that runs less processes to do the same and 2) systemd-* is better.
dr_robot@kbin.social 1 year ago
Thanks for your reply! One thing I'm struggling with networkd is hysteresis. That is, toggling the interface down and then back up does not do what I expect it to. That is, setting the interface down does not clear up the configuration, and setting the interface up does not reconfigure the interface. I have to run reconfigure for that. I was hoping that the declarative approach of networkd would make it easy to predict interface state and configuration.
This does make sense because configuration is not the same as operational state. However, what would the equivalent of ifdown (set interface down and remove configuration) and ifup (set interface up and reconfigure) be using networkd and networkctl? This kind of feature would be useful for me to test config changes, debug networking issues, disconnect part of the network while I'm making some changes, etc.
TCB13@lemmy.world 1 year ago
I get your points and that’s a valid issue however,
systemd-networkdis designed for more persistent configurations but you’ve a few options:systemctl reload systemd-networkdandnetworkctl reload. Don’t forget that if you change units on the filesystem asystemctl daemon-reloadis required before the previous commands.networkctlcommands such asreload,reconfigure,up,downandrenew. Read more about them here.Temporary / volatile runtime units: manually drop a config under
/run/systemd/network/it will apply until you reboot the machine.Transient scope units: those are kind of supersede temporary units as they are managed through a D-Bus interface so 3rd party interface can manage systemd. They don’t seem to work right now for network, but they might eventually do and this allows you to change options dynamically like they do for standard services.
An interesting thing to consider is that in most cases you can have your network configurations in
/etc/systemd/networkbut only bring them online when required. This for me seems to solve most cases, you’ve your network all configured and ready to go.