> 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 people who want that old model, but I
suspect they will encounter increasing difficulty sticking to it.
> Because the default configuration is changing.
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?
> 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 the two, so you can use or not use either/both. Basically the opposite of systemd, which is a giant code ball of code with components tightly coupled.
And while it is likely that dhclient will eventually be removed from OpenBSD Base, it will live on in Ports, where it will be available to those who desire to use it:
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.
One of the programs does DHCP. One does resolve.conf(5) changes. Each does nothing else. It may even be possible to port each of these programs to another operating system, as I suspect they don't need special APIs (*cough*dbus*cough*) and may mostly just use POSIX-y stuff.
> 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.
> On my Debian system it ships 50+ different binaries split across 8 different packages.
Nobody cares. The number of binaries is irrelevant. What is relevant are stable, documented interfaces between them that someone else could implement if they so choose and remain compatible. And systemd people have repeatedly said they do not intend to maintain stable interfaces between the various components of systemd. As long as that's true, it's completely fair to call systemd a monolith, 50+ binaries or not.
In other words, this is a ‘only Microsoft employees may use the secret 7 on the dice’ situation.
No, it's winning because RedHat is forcing everyone's hand by hiring most of Linux desktop developers, and the rest are insufficient to maintain other solutions to keep feature parity.
It's Embrace Extend Extinguish in action, except by using the force of running two biggest distributions in addition to GNOME project. (And a bunch of others depending directly on them.) Even Debian was unable to weather all the dependencies using the new interfaces. Gentoo tries still with OpenRC, more or less successfully.
I don't think Red Hat are forcing anyone's hand. I think the fact that Red Hat are hiring passionate developers to work on something they love full time is something they should be lauded for. Of course Red Hat have to pick a project they're going to focus on, they can't focus on every implementation, and it only makes sense that community projects aren't going to have feature parity with software that's being built for enterprise use cases, worked on people whose it's their full time job. It's because of the wider support that the majority of distros decided to go with them.
Your own comment that you've linked here, which mentions Russ Allbery, has him quoted saying, "Most of those [systemd] components are clearly superior to anything we have available now on Linux platforms and will be used in the distribution going forward".
Then there's Fedora, which is upstream of Red Hat, who has many of it's contributors as Red Hat employees, so I don't see how it's odd that they would adopt software that Red Hat are invested in.
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?
> 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.
I am a sysadmin for some systems. I am merely a user for others. Servers that run my projects? Sure I will dig into what’s up. My Raspberry Pi running Raspbian so I can run my 3D printer off it? I’m a user.
> 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.
>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
How do you know it's working if you don't understand it? What's preventing some admin socket to be activated, is the firewall good, etc
you can ride and breed horses without understanding horse physiology or DNA. when you need to fix a broken or lame horse or breed a better horse, knowing how it works helps alot
presumably most sys admins are more akin to vets than riders
> 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?
My (least) favorite SystemD gotcha I discovered recently is the way it's taken over 'fstab' in some distros. I think Debian is one of them. When you edit 'fstab', you need to run 'systemctl daemon-reload'. Fine. Whatever. I don't have a huge problem with that.
However, when you try to boot after a disk has been removed from the system, it won't. Instead it drops to a recovery console, BUT if you use a distro without a 'root' password, it can't drop into the recovery console and you're screwed.
The default setup on a lot of Linux distros won't boot if you remove a non-system disk. I like SystemD more than the old init system(s), but there are some really, really dumb decisions that have been made along the way.
> Instead it drops to a recovery console, BUT if you use a distro without a 'root' password, it can't drop into the recovery console and you're screwed.
That's indeed an unfortunate situation. systemd allows you to set the SYSTEMD_SULOGIN_FORCE environment variable for the rescue.service to override this behaviour and always give you a rootshell. It's an open bug for the Debian installer to set that variable by default if installing without a root password (#952450).
It's not encroaching on fstab, it's using it as input during boot, because mounting is intimately coupled with service ordering. Think about services that reside on a network filesystem: the network has to be up to mount the filesystem, but the network in turn can require arbitrary services to run, which can require other local filesystems to be mounted. You can't get configurations like these to work without coupling mounting and service ordering.
It's fundamentally not that different from sysvinit, with its various init scripts that mounted filesystems according to the fstab.
Because systemd services can depend on mount points or cause mountpoints to come up dynamically, in a way that pure fstab does not support, e.g. for containers. So (as far as I understand) fstab is now simply an input to the actual mount system.
> 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.)
> What can I possibly gain by switching which DHCP client
Yesterday I switched to systemd-networkd on debian to gain the feature of having the hostname be set via DHCP and not have to write a script myself. In the process I pulled in a javascript dependency via policykit, which is giving me pause and I am re-evaluating if my approach is correct here.
But for this feature I had to switch DHCP server and client. TBF it's not something that comes up all the time, but it sure is something I thought was more commonly implemented.
> In the process I pulled in a javascript dependency via policykit, which is giving me pause and I am re-evaluating if my approach is correct here.
To be fair, policykit is great. It solves a real problem (namely is this user allowed to peform this action, which traditional POSIX permissions do not solve in a portably) in a very sane way that is totally optional to opt in to.
Should polkit use a different, turing complete language than JavaScript? I don't know, probably, but it's not an awful choice. There is definitely more developer literacy for JS than, say, Lua or some other bespoke monstrosity they could've picked instead.
Apologies if I mistyped this, Lua is not remotely a monstrosity. It's great! But I don't think it would be appropriate here, and I think more developers can grok JS in this day and age.
I've heard a rumour that POSIX mandates that Perl be installed, although I haven't been able to substantiate it.
POSIX-described Turing-complete interpreters include at leat the Bourne shell, awk, and sed, none of which you probably want to use for implementing a security policy.
Apparently LSB 5.0 mandates[1] both Perl (5.8) and Python (2.4), but that won't pacify anyone with an axe to grind about applications making Linux-specific assumptions.
> Apparently LSB 5.0 mandates[1] both Perl (5.8) and Python (2.4)
Wow, that didn't age well. That document actually says Python "2.4.2 or greater" and Perl "5.8.8 or greater", which doesn't help if the installed interpreters are Python 3.10 and Perl 6.c (2018.06), since both are greater than the specified versions but incompatible with them. Even if it had specified the major release (that is, Python 2.x greater than 2.4.2 and Perl 5.x greater than 5.8.8), that wouldn't help once those major releases are no longer maintained.
Python3 requires some code changes, but on the whole is the same language.
Perl 6 was intended to be an upgrade from 5, but over time developed into a completely new language that shared stylistic similarities to Perl 5. Perl 6 can't be compatible with Perl 5 to any large extent because XS isn't a thing anymore, so any modules that had binary parts to them can't be easily ported.
These days Perl 6 got renamed to "Raku", to signify that it's its own, independent language.
The Perl 5 line continues to exist and apparently plans for the next major version to be Perl 7.
The Debian policykit packages have (frustratingly) diverted from upstream here. They do not pull in mozjs, sanding users with the older and far less flexible rules files.
I care about which NTP implementation is used because OpenNTPD supports getting time constraints from TLS servers. Which.. no, I absolutely do not actually worry about NTP servers intentionally feeding my laptop the wrong time, but this is just a feature that sounds too cool to ignore. How can I not go out of my way to have that going on??
Sometimes I kinda envy people who don't have this shiny-tech-obsession and are satisfied with things just working :)
Oh don’t get me wrong I customize things. I have just moved on from customizing parts of a Linux distro. At some point I want to customize things that make more of an impact on the real world.
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.
You're right that Linux is pretty much the only operating system where users can mix and match core system components. That's precisely why people get so mad about systemd!
If I wanted to use an operating system where all the components were tightly coupled and made by a single vendor, I'd use Windows, or macOS, or a BSD. (In fact I do use those operating systems when that's what I want.) But I would also like for other kinds of systems to exist in the world. I downloaded Linux because I wanted to use an operating system that _wasn't_ macOS!
Specially because "the Unix philosophy" as preached by Linux afficionados never happened in real UNIX, it keeps being preached as some kind of cargo cult by people that weren't even around during the UNIX wars heyday.
Because it all lives in one repo, some distros make the choice of packaging all of systemd into one package, so that you can't choose to not install timesyncd or networkd.
Moving the goalposts yet again. Not only must it be technically superior for everyone, not only must it adhere to decades old computing dogma, but now it must be branded in such a way that it’s individual components must be unidentifiable?
> And while it is likely that dhclient will eventually be removed from OpenBSD Base, it will live on in Ports, where it will be available to those who desire to use it:
To be clear, OpenBSD's dhclient is not ISC dhcp client, it is a version that has been maintained in OpenBSD for many years and has a weaker form of privsep, but dhcpleased is a new daemon written to be more in-line with other OpenBSD daemons.
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, and just forwards data to your existing syslog daemon.
Quite a difference from "will encounter increasing difficulty sticking to it."
TBH you still take the performance hit for journald doing all the lookups for each received message that populate all the fields of each message. In most cases you won't notice but I have seen some people complain that this extra processing can't be disabled.
Debian has, on paper at least, still support for sysvinit, and ships with the old ifupdown-based network configuration by default. In practice it's increasingly bitrotting because it turns out that the majority of users and developers don't care.
I didn’t see the part where it’s a take it or leave it proposition and there’s politics to force people into accepting one part which is then used to force them to accept an ever growing list of unrelated parts.
OpenBSD acts as router for my home, and I run Unbound on the router to provide DNS-over-TLS capability to both OpenBSD and to the computers in my LAN. My ISP connection uses DHCP, and my ISP obviously provide DNS servers for me, but by superseding these with "127.0.0.1" through dhclient.conf I can make sure OpenBSD never inserts the ISP DNSes into resolv.conf and consequently always resolve through Unbound instead, and by letting computers in my LAN use the router (i.e. Unbound) as DNS I can make sure they too get DNS-over-TLS instead of resolving hostnames with my ISP's DNSes.
Since I don't involve Unwind here, which according to the manpages of the new daemons is what makes them prepend "127.0.0.1" to resolv.conf, and since I cannot see any apparent way of configuring the new daemons to ignore DNS information in the DHCP response the way I can with dhclient, how can I achieve what I have now? How can I prevent my ISP's DNSes from entering resolv.conf when running the new daemons?
I get the impression that my use case (which really is neither uncommon nor obscure) hasn't been thought of at all.
Yes. Clumsy. It's an unusually awkward design choice to have the software detect if another specific application is running in order to trigger the behavior, instead of just giving the user the ability to configure it.
In my opinion this whole new dhcpleased/resolvd setup is poorly planned, as it contrives the gruesome trick of being both a privacy/integrity problem (no user control over ISP DNS making its way into resolv.conf) and a userland villainy problem (forcefully altering behavior based on whether some other application is running, no matter what the user's actual intention is for running that application).
> 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 people who want that old model, but I suspect they will encounter increasing difficulty sticking to it.
> Because the default configuration is changing.
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?