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.
this post was submitted on 05 Aug 2023
12 points (92.9% liked)
Selfhosted
39435 readers
7 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 1 year ago
MODERATORS
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.
I get your points and that's a valid issue however, systemd-networkd is 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 applications can manage systemd. They don't seem to work right now for network, but this allows you to change unit options dynamically.
An interesting thing to consider is that in most cases you can have your network configurations in /etc/systemd/network but only bring them online when required. This for me seems to solve most cases, you've your network all configured and ready to go.
Thanks for this useful reply! I think I'll just need to closely examine my setup and figure out if I really need the ability to up/down interfaces like I described or whether the more persistent approach of networkd is actually more suitable for me. Sometimes I just want to reproduce behaviour that I've used before, but may not actually need.
Well networkctl up enXX + pre-configured network files with the addresses and whatnot might be a suitable for your requirements.
Personally, I will use both: On servers with fixed network connections I will tend to use ifupdown; but on my linux laptops I'll use networkmanager or networkd which tend to have nice UI's for joining various forms of wifi networks. On my laptops for some VPN's i"ll use the ifupdown configuration, which lets me setup all sorts of exotic configurations (bridges, vlans, vxlan,, vpns, namespaces, etc.) The linux command line tooling has a litany of functions to check/test/diagnose/tweak networking settings, and they work across all the distros, AND they can reveal the full details of the network, as the kernel sees it. NetworkManager, networkd, connmann, etc, often omit details in the name of simplifying for the most common scenarios.
I'm using ifupdown2 and have services depending on the state of virtual network devices (BindsTo=sys-devices-virtual-net-.device).
I hate systemd with a passion, as the refuses to wait for networking when you haven some service specified to be started After networking, but it start when the start of networking actions has sbeen tarted (not after networking is finished bringing up everything)
The only think I let systemd do is monitor the state of the devices and set the interface name, as udev seems to mess these names up in combination with systemd (and there is to much depending on systemd now in Debian to get rid of the junk)
I hate systemd with a passion, as the refuses to wait for networking when you haven some service specified to be started After networking
If you apply what is written at https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/#cutthecraphowdoimakesurethatmyservicestartsafterthenetworkisreallyonline it will work.
Systemd-networkd has a learning curve, once you learn it you'll find it superior and more flexible than anything else.
If you apply what is written at https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/#cutthecraphowdoimakesurethatmyservicestartsafterthenetworkisreallyonline it will work.
Then I'll need to do a global rewrite of all distrubution delivered service files and replace network.target with network-online.target. Then I don't understand why maintainers all keep using network.target. For every service that needs some kund of netwirj active I alkready have iverrides to link then to the virtual or physical interfaces they actually use.
Systemd-networkd has a learning curve, once you learn it you’ll find it superior and more flexible than anything else.
I still find it a solution desperately looking for a problem to solve. Yes, you can control loads of dependencies, but you could already do that with the init scripts. The main selling point on introduction was 'it is faster'. Why would you want something faster when you use it once every kernel update? When you design your solutions correctly (redundant), you won't even notice a reboot of 1 system in the setup.
Then I don’t understand why maintainers all keep using network.target.
Because most services are able to dynamically accommodate networking changes and act accordingly and it's rare to have cases where we really need a working link with addresses and a proper connection when the service starts. For those special cases, as described, you need to enable systemd-networkd-wait-online.service and include After=network-online.target and/or Wants=network-online.target in your service.
Programs should be designed to detect and react to networking changes and both Apache and Nginx are good examples of software that does that. There are simpler cases like stuff that needs to bind to non-existent IPs at boot (before networking) that can be dealt with ipv4.ip_nonlocal_bind and net.ipv6.ip_nonlocal_bind as described here.
This may also interest you as it includes what "up" means a few other details: https://systemd.io/NETWORK_ONLINE/
I still find it a solution desperately looking for a problem to solve.
Systemd does a LOT more than "you can control loads of dependencies", it solves tons of painful issues and provides a cohesive ecosystem of tools to manage stuff like:
- Start services in parallel (while init was one after the other)
- Defer service startup until they are actually needed
- Replace a bunch of poorly integrated tools such as dhcpcd, dhcpv6, chrony, NetworkManager, resolvconf, logrotate among others with a cohesive ecosystem of tools that are way easier to work with;
- Has facilities to deal with IPv6 advanced use cases like IPv6-PD without having to depend on four different packages;
- Centralizes logs and provides
journalctlas a unified interface so you can quickly browse them by specific, filters, timestamps and events. - Replaces
crontabwith something auditable that actually makes sense; - Monitors the status of your services and restarts them if they crash according to specific rules. Can also be used to limit execution time and trigger notifications when stuff fails.
- Allows you to isolate your processes with sandboxing (like jails) techniques by restricting what resources (CPU time, RAM, networking, filesystems) they can access by settings everything in a single unit file. Even setup basic firewalls for your services;
- Create full fledged containers both privileged and non-privileged here and here while providing tools such as
machinectlto manage them.
Systemd is very useful and most people (including myself) don't know about half of the things it can do. It isn't teached because of the current poor state of thing when it comes to software development but if you use it you'll quickly find how to have systems running very well with less processes than conventionally.
Replace a bunch of poorly integrated tools such as NetworkManager
You got me here... I'm now battling NetworkManager in scripting (alas, still no Ansible in place there, I doubt it'll be long before I have implemented it), the thing just refuses any configuration via files. Time to dive into the networkd setup. I also hope I can get rid of the very unstable ppoe and wide-dhcpv6-client setup I have here now via ifupdown2 on Debian. The restart I like as well. Time for a deep dive I guess. On Debian NM never caught on, thank $preferredDdiety, but at work it's a disaster.
https://github.com/systemd/systemd/issues/481
wide-dhcpv6-client is easy, any systemd-networkd IPv6 guide will have what you need.
I'll see what I can manage. Thanks for the pointers.
When I can manage simple ipv4 networking via networkd I'm already happy, as it means I can ditch NM again at work, that's giving me a lot more headaches then a flapping SLAAC that I'm not dependent on. (already switched back to my super stable tunnel) The situation here is a setup with 2 ipv6 tunnels, 1 ipv6 SLAAC, source based routing and no default gateway in main routing table for ipv6. Everything runs via the ipv4 pppoe connection. (and a load of vlans both sides of my router to internet)
Ahaha that’s gonna take a while to figure out. Good luck.
Btw, policy based routing: https://serverfault.com/questions/682462/how-to-do-policy-routing-with-systemd/877537#877537 and https://www.freedesktop.org/software/systemd/man/systemd.network.html#%5BRoutingPolicyRule%5D%20Section%20Options
Then I'll limit myself to the situation at work. ifupdown2 works great and doesn't need replacing at home.