view the rest of the comments
Selfhosted
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:
- selfh.st Newsletter and index of selfhosted software and apps
- 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!
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.
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-networkd
andnetworkctl reload
. Don't forget that if you change units on the filesystem asystemctl daemon-reload
is required before the previous commands.networkctl
commands such asreload
,reconfigure
,up
,down
andrenew
. 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.