dhcpleased(8) and resolvd(8) enabled in base, replacing dhclient(8)
undeadly.org
undeadly.org
> 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?
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."
https://web.archive.org/web/20161210172826/http://article.gm...
https://lists.freedesktop.org/archives/systemd-devel/2010-Se...
> 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:
* https://cvsweb.openbsd.org/ports/net/isc-dhcp/
* https://github.com/openbsd/ports/tree/master/net/isc-dhcp
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.
> [..]
> 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.
So this is a strange criticism to make.
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!
Unix never had interchangable components like that.
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.
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.
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
presumably most sys admins are more akin to vets than riders
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.)
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.
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.
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.
[1]: https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Languages...
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.
It’s not: https://shellhaters.org
Lua is definitely the opposite of 'bespoke monstrosity'. It's pretty much the intersection of tiny interpreter, fast execution, and simple language.
On Linux there are no hard dependencies although your distro may enforce a udev dependency.
Sometimes I kinda envy people who don't have this shiny-tech-obsession and are satisfied with things just working :)
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.
Learned the hard way the need for the 'nofail' flag in 'fs_mntops' field, which was undocumented in the man page in the early versions ...
It's fundamentally not that different from sysvinit, with its various init scripts that mounted filesystems according to the fstab.
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).
Allow me to introduce you to BSD users. (I don’t get it either).
So I can take the code for just systemd-resolved and port it to FreeBSD or Solaris?
And dbus. The components being discussed here don't depend on either.
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.
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.
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.
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.
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sbin/dhcpleased...
OpenBSD's previous dhclient: https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sbin/dhclient/
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.
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).
resolvconf was designed to take DNS inputs from many sources and allow the user to tailor these to their needs.
While it's not yet ported, I use dnsmasq to allow several dynamical DNS resolvers plug and unplug themselves from the systemwide resolver.