4 ms·

Could someone explain why systemd needs DNS/NTP fallbacks to begin with? Why aren’t these both runtime configs? EDIT: I assumed there were also runtime configs

Could someone explain why systemd needs DNS/NTP fallbacks to begin with? Why aren’t these both runtime configs? EDIT: I assumed there were also runtime configs based on the name "fallback." My question is primarily why you need compiled-in fallbacks, and secondarily why the fallback configs aren't pulled from config files.

gdamjan1 6y ago
it is runtime config. these are defaults in case the distro doesn't change it, or the admin doesn't set it.
sascha_sl 6y ago
They are, these are the defaults for unset. As Lennart says, asking your distro vendor to set defaults or just doing it on your own system is much better. This issue is just being upset on behalf of the people that don't mind or care and just want working infrastructure.
Xylakant 6y ago
They are runtime configs. The build-time defaults are fallbacks for when no runtime config is set. https://www.freedesktop.org/software/systemd/man/systemd.network.html#DNS= https://www.freedesktop.org/software/systemd/man/systemd.net... https://www.freedesktop.org/software/systemd/man/timesyncd.conf.html# https://www.freedesktop.org/software/systemd/man/timesyncd.c...
- louwrentius 6y ago
  It would better to fail than to use fallbacks that are not desired.
aequitas 6y ago
I could imagine if you want to fetch external resources for first boot configuration on embedded or satellite installations. You need DNS for that, and NTP (or hardware time) for https to work. Nowadays even pre-OS processes (UEFI) use internet. For example internet recovery on Mac's.
- wrkronmiller 6y ago
  interesting point, but I'd think DHCP or a baked-in config file in the system image would do the trick no?
numpad0 6y ago
Yeah and if no runtime configs are set why not let it fail? systemd ain’t youtube-dl or awscli.
- ori_b 6y ago
  So that system administrators know they misconfigured it, rather than having it silently do the wrong thing.
ashkante 6y ago
If I want my systems to fail in DNS resolution if the DHCP server doesn't give them a DNS server address (by design), I'm essentially SoL then? My option then is to block outgoing TCP/UDP 53 on my firewall, except from my forwarders. Or maybe I should just suck it up and start building systemd in-house an give it a bogus default, with all the maintenance and overhead that involves? So, in a few months to a few years, when systemd silently switches to DNS over HTTPS, what then? Maintain a (growing) blacklist of public DoH servers? I'd much prefer my software to fail (and let me know), rather than assume some default someone, somewhere, somewhen thought a good idea.
peterwwillis 6y ago
More to the point: does any Linux software at all use a default DNS or NTP server? NSS resolver library doesn't default to using a specific DNS provider, and it's a DNS resolver. NTPd might default to using ntp.org pools, but that might just be my distro's default configs. To me this is more evidence that Systemd is really just "Poetteringd": whatever he feels like it should have, it has. Really disappointed that distros continue to use this software rather than start a community replacement that addresses its shortcomings. If I re-did systemd, it would retain the same functionality, but not come enabled by default, and it'd be broken up into independent packages to be installed as needed. It would also use standard interfaces and do away with the binary formats, defer to existing system software rather than default to its own custom versions, de-complicate its awkward filesystem tree and simplify management of service configs, make the command-line interface more sane, and begin integrating more cloud-specific features to replace more complex cloud software (such as for service discovery, cluster management, and HA). All these fixes would allow the "anti-systemd" crowd (of which I am a card-carrying member) to run a simple init system if they want, or extend it to the full range of systemd functionality. It would remove glaring pain points and user friction, embrace the existing system's default functionality (and backwards compatibility), and extend the software to be more useful in cluster environments. In addition, if this were maintained by the community, all distros could adopt it like they did systemd, and we don't have a half dozen different service systems like before. Now please somebody reply and tell me why this is a terrible idea...
- hedora 6y ago
  It more-or-less worked that way for decades (and it worked better), so it’s not a terrible idea. My theory is that the big distros are intentionally destroying forwards and backwards compatibility on the desktop as much as possible. The more often window managers, desktop software, etc., stop working, the less their own teams have to compete with existing software. Wayland’s X11-as-a-second-class-citizen and gtk’s elimination of API stability are two other good examples of this. Also, tearing down established standards is a great way to sabotage the various BSD’s out there. What they don’t get is that sabotaging the rest of the community is undermining their own market share within Linux, even as it shrinks Linux’s market share.

gdamjan1 6y ago

it is runtime config. these are defaults in case the distro doesn't change it, or the admin doesn't set it.

sascha_sl 6y ago

They are, these are the defaults for unset. As Lennart says, asking your distro vendor to set defaults or just doing it on your own system is much better. This issue is just being upset on behalf of the people that don't mind or care and just want working infrastructure.

Xylakant 6y ago

They are runtime configs. The build-time defaults are fallbacks for when no runtime config is set. https://www.freedesktop.org/software/systemd/man/systemd.network.html#DNS= https://www.freedesktop.org/software/systemd/man/systemd.net... https://www.freedesktop.org/software/systemd/man/timesyncd.conf.html# https://www.freedesktop.org/software/systemd/man/timesyncd.c...

louwrentius 6y ago
It would better to fail than to use fallbacks that are not desired.

aequitas 6y ago

I could imagine if you want to fetch external resources for first boot configuration on embedded or satellite installations. You need DNS for that, and NTP (or hardware time) for https to work. Nowadays even pre-OS processes (UEFI) use internet. For example internet recovery on Mac's.

wrkronmiller 6y ago
interesting point, but I'd think DHCP or a baked-in config file in the system image would do the trick no?

numpad0 6y ago

Yeah and if no runtime configs are set why not let it fail? systemd ain’t youtube-dl or awscli.

ori_b 6y ago
So that system administrators know they misconfigured it, rather than having it silently do the wrong thing.

ashkante 6y ago

If I want my systems to fail in DNS resolution if the DHCP server doesn't give them a DNS server address (by design), I'm essentially SoL then? My option then is to block outgoing TCP/UDP 53 on my firewall, except from my forwarders. Or maybe I should just suck it up and start building systemd in-house an give it a bogus default, with all the maintenance and overhead that involves? So, in a few months to a few years, when systemd silently switches to DNS over HTTPS, what then? Maintain a (growing) blacklist of public DoH servers? I'd much prefer my software to fail (and let me know), rather than assume some default someone, somewhere, somewhen thought a good idea.

peterwwillis 6y ago

More to the point: does any Linux software at all use a default DNS or NTP server? NSS resolver library doesn't default to using a specific DNS provider, and it's a DNS resolver. NTPd might default to using ntp.org pools, but that might just be my distro's default configs. To me this is more evidence that Systemd is really just "Poetteringd": whatever he feels like it should have, it has. Really disappointed that distros continue to use this software rather than start a community replacement that addresses its shortcomings. If I re-did systemd, it would retain the same functionality, but not come enabled by default, and it'd be broken up into independent packages to be installed as needed. It would also use standard interfaces and do away with the binary formats, defer to existing system software rather than default to its own custom versions, de-complicate its awkward filesystem tree and simplify management of service configs, make the command-line interface more sane, and begin integrating more cloud-specific features to replace more complex cloud software (such as for service discovery, cluster management, and HA). All these fixes would allow the "anti-systemd" crowd (of which I am a card-carrying member) to run a simple init system if they want, or extend it to the full range of systemd functionality. It would remove glaring pain points and user friction, embrace the existing system's default functionality (and backwards compatibility), and extend the software to be more useful in cluster environments. In addition, if this were maintained by the community, all distros could adopt it like they did systemd, and we don't have a half dozen different service systems like before. Now please somebody reply and tell me why this is a terrible idea...

hedora 6y ago
It more-or-less worked that way for decades (and it worked better), so it’s not a terrible idea. My theory is that the big distros are intentionally destroying forwards and backwards compatibility on the desktop as much as possible. The more often window managers, desktop software, etc., stop working, the less their own teams have to compete with existing software. Wayland’s X11-as-a-second-class-citizen and gtk’s elimination of API stability are two other good examples of this. Also, tearing down established standards is a great way to sabotage the various BSD’s out there. What they don’t get is that sabotaging the rest of the community is undermining their own market share within Linux, even as it shrinks Linux’s market share.