Might be useful to add OpenBSD in the title somewhere.
dhcpleased(8) and resolvd(8) enabled in base, replacing dhclient(8)
11–20 of 79 posts
Re: dhcpleased(8) and resolvd(8) enabled in base, replacing dhclient(8)
#12> We are moving from a model where dhclient on 1 interface believes it is MASTER of /etc/resolv.conf and a bunch of system aspects, and the userbase is familiar with a pile of hacky control knobs in dhclient.conf. > Towards a model where multiple interfaces + unwind can advertise their DNS resolution abilities to resolvd, which then sorts the offers and maintains a configuration. > dhclient will remain available for…
> An old and somewhat crusty cross-platform daemon replaced by an OS-specific set of daemons, that takes care of managing /etc files that have been there forever. The older solution remains available, but may bitrot or otherwise become harder to maintain in the future. > Wait, isn't this what systemd is "accused" of doing all the time? Each of these do one thing and one thing only. The code is loosely coupled between…
> Basically the opposite of systemd, which is a giant code ball of code with components tightly coupled.
> [..]
> The use or non-use of of either of these program will also not effect device discovery / hot-plugging, mounting of file systems, system run levels, network time, system logging, etc.
This comes up again and again in the systemd discussion, but it's at best a mischaracterization. Yes, there's some code sharing between different components, but it's not a monolith. On my Debian system it ships 50+ different binaries split across 8 different packages. You can use the network management without using the NTP service, the journal without using the device manager, the tmpfiles manager without using the user manager, etc.
Most, if not all, of these components only depend on the service manager (i.e. PID 1). That's more or less unavoidable for an event-driven system, there'll always be a dependency on the event bus. The components itself can be freely swapped out for different, even incompatible, implementations. If you don't even want to run the service manager, all external interfaces are stable, pretty well-documented and relatively straightforward, so it's even possible to write a completely independent implementation without breaking external dependencies.
By the way, if we're talking about loose coupling and POSIX, this OpenBSD implementation isn't it either. resolvd has an hardcoded reference to the unwind socket, and they use a special BSD-only socket type to communicate between the different processes.
Re: dhcpleased(8) and resolvd(8) enabled in base, replacing dhclient(8)
#13Earlier quoted context omitted.
> An old and somewhat crusty cross-platform daemon replaced by an OS-specific set of daemons, that takes care of managing /etc files that have been there forever. The older solution remains available, but may bitrot or otherwise become harder to maintain in the future. > Wait, isn't this what systemd is "accused" of doing all the time? Each of these do one thing and one thing only. The code is loosely coupled between…
> Basically the opposite of systemd, which is a giant code ball of code with components tightly coupled. > [..] > The use or non-use of of either of these program will also not effect device discovery / hot-plugging, mounting of file systems, system run levels, network time, system logging, etc. This comes up again and again in the systemd discussion, but it's at best a mischaracterization. Yes, there's some code sha…
systemd fundamentally made a branding mistake, not a technical one. Putting all of these components under one 'systemd' umbrella name meant that people simplistically think of them as one thing and then start making the 'Unix philosophy' argument.
Re: dhcpleased(8) and resolvd(8) enabled in base, replacing dhclient(8)
#14Earlier quoted context omitted.
> An old and somewhat crusty cross-platform daemon replaced by an OS-specific set of daemons, that takes care of managing /etc files that have been there forever. The older solution remains available, but may bitrot or otherwise become harder to maintain in the future. > Wait, isn't this what systemd is "accused" of doing all the time? Each of these do one thing and one thing only. The code is loosely coupled between…
> Basically the opposite of systemd, which is a giant code ball of code with components tightly coupled. > [..] > The use or non-use of of either of these program will also not effect device discovery / hot-plugging, mounting of file systems, system run levels, network time, system logging, etc. This comes up again and again in the systemd discussion, but it's at best a mischaracterization. Yes, there's some code sha…
What I also don’t get: why the hell would do I care which NTP implementation is used in most cases. What I do care about is that it’s running and working. systemd has a good init system and a decent set of other services. Could things be improved? Sure. But honestly as long as when I boot my Debian-derived distro it works as expected why am I going yo go digging into how it works? What can I possibly gain by switching which DHCP client or which NTP daemon I’m using?
Re: dhcpleased(8) and resolvd(8) enabled in base, replacing dhclient(8)
#15Earlier quoted context omitted.
> An old and somewhat crusty cross-platform daemon replaced by an OS-specific set of daemons, that takes care of managing /etc files that have been there forever. The older solution remains available, but may bitrot or otherwise become harder to maintain in the future. > Wait, isn't this what systemd is "accused" of doing all the time? Each of these do one thing and one thing only. The code is loosely coupled between…
> Basically the opposite of systemd, which is a giant code ball of code with components tightly coupled. > [..] > The use or non-use of of either of these program will also not effect device discovery / hot-plugging, mounting of file systems, system run levels, network time, system logging, etc. This comes up again and again in the systemd discussion, but it's at best a mischaracterization. Yes, there's some code sha…
> Yes, there's some code sharing between different components, but it's not a monolith.
So I can take the code for just systemd-resolved and port it to FreeBSD or Solaris?
Re: dhcpleased(8) and resolvd(8) enabled in base, replacing dhclient(8)
#16Earlier quoted context omitted.
But in the case of Linux distributions do they let the older solution remain available.
Sure they do, I run a few systems which use systemd with older dhcp daemons. And for example Raspbian uses systemd for process management, but completely disables its network parts, using their own solutions instead. One of the best parts of the systemd is how easy it is to disable/replace any part of it. The resolved and timesyncd are easy, but even things like journald have a mode when it keeps no files on disk, an…
How about removing all of it and just running daemontools, runit or s6. Is this easy.
Re: dhcpleased(8) and resolvd(8) enabled in base, replacing dhclient(8)
#17Earlier quoted context omitted.
> Basically the opposite of systemd, which is a giant code ball of code with components tightly coupled. > [..] > The use or non-use of of either of these program will also not effect device discovery / hot-plugging, mounting of file systems, system run levels, network time, system logging, etc. This comes up again and again in the systemd discussion, but it's at best a mischaracterization. Yes, there's some code sha…
What I also don’t get: why the hell would do I care which NTP implementation is used in most cases. What I do care about is that it’s running and working. systemd has a good init system and a decent set of other services. Could things be improved? Sure. But honestly as long as when I boot my Debian-derived distro it works as expected why am I going yo go digging into how it works? What can I possibly gain by switchin…
> What I also don’t get: why the hell would do I care which NTP implementation is used in most cases.
Because some implementations have time jump while others have it slew it slowly.
On boot-up a jump may be fine to get with ± some number of milliseconds, but once the system is running, there are situations where jumps could be a problem (especially in the negative direction, where a moment is "repeated").
> But honestly as long as when I boot my Debian-derived distro it works as expected why am I going yo go digging into how it works? What can I possibly gain by switching which DHCP client or which NTP daemon I’m using?
Because as a sysadmin it is your job to understand how a system works. There should be very little "magic" happening. Sure there are many times where things Just Working™ is fine (it's why I run a Mac at home), but many others where you should understand why things are working the way they are.
Re: dhcpleased(8) and resolvd(8) enabled in base, replacing dhclient(8)
#18Earlier quoted context omitted.
> Basically the opposite of systemd, which is a giant code ball of code with components tightly coupled. > [..] > The use or non-use of of either of these program will also not effect device discovery / hot-plugging, mounting of file systems, system run levels, network time, system logging, etc. This comes up again and again in the systemd discussion, but it's at best a mischaracterization. Yes, there's some code sha…
> Yes, there's some code sharing between different components, but it's not a monolith. So I can take the code for just systemd-resolved and port it to FreeBSD or Solaris?
[deleted]
Re: dhcpleased(8) and resolvd(8) enabled in base, replacing dhclient(8)
#19Earlier quoted context omitted.
> Basically the opposite of systemd, which is a giant code ball of code with components tightly coupled. > [..] > The use or non-use of of either of these program will also not effect device discovery / hot-plugging, mounting of file systems, system run levels, network time, system logging, etc. This comes up again and again in the systemd discussion, but it's at best a mischaracterization. Yes, there's some code sha…
What I also don’t get: why the hell would do I care which NTP implementation is used in most cases. What I do care about is that it’s running and working. systemd has a good init system and a decent set of other services. Could things be improved? Sure. But honestly as long as when I boot my Debian-derived distro it works as expected why am I going yo go digging into how it works? What can I possibly gain by switchin…
> What I also don’t get: why the hell would do I care which NTP implementation is used in most cases. What I do care about is that it’s running and working.
You should care whether it's SNTP (which only slews and/or steps the clock periodically) or full NTP (which also adjusts the clock frequency, so once it's synchronized, no further slew and/or step is needed). Full NTP is better.
Looking quickly at the manual pages for systemd-timesyncd and systemd-timedated, I can see that systemd-timesyncd is just SNTP, so a full NTP implementation like chrony or ntpsec should be preferred. From what I can see, if you have chrony installed and configured correctly, systemd's "timedatectl set-ntp true" (enable NTP) will prefer to enable chrony instead of systemd-timesyncd (it goes through systemd-timedated which looks at /usr/lib/systemd/ntp-units.d/, where chrony is usually listed first).
(Also, there's some difference between chrony and ntpsec; AFAIK, chrony is much better when you have an intermittent network connection.)
Re: dhcpleased(8) and resolvd(8) enabled in base, replacing dhclient(8)
#20Earlier quoted context omitted.
What I also don’t get: why the hell would do I care which NTP implementation is used in most cases. What I do care about is that it’s running and working. systemd has a good init system and a decent set of other services. Could things be improved? Sure. But honestly as long as when I boot my Debian-derived distro it works as expected why am I going yo go digging into how it works? What can I possibly gain by switchin…
> What I also don’t get: why the hell would do I care which NTP implementation is used in most cases. Because some implementations have time jump while others have it slew it slowly. On boot-up a jump may be fine to get with ± some number of milliseconds, but once the system is running, there are situations where jumps could be a problem (especially in the negative direction, where a moment is "repeated"). > But hone…
> Because as a sysadmin it is your job to understand how a system works.
No, as a sysadmin your job is to deliver a working system. To do that it usually helps to understand how the system works, but it's not a necessity. As long as something keeps working, and you're equipped to go digging if and when it's necessary, it's fine to not understand or know how something works.