dhcpleased(8) and resolvd(8) enabled in base, replacing dhclient(8)
1–10 of 79 posts
Re: dhcpleased(8) and resolvd(8) enabled in base, replacing dhclient(8)
#2> 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?
Re: dhcpleased(8) and resolvd(8) enabled in base, replacing dhclient(8)
#3> 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…
We can’t block systemd from making a network socket/connection so we daemonized the network aspects.
Re: dhcpleased(8) and resolvd(8) enabled in base, replacing dhclient(8)
#4> 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…
Also interesting to note that dhcpleased and resolvd are loosely analogous to systemd-networkd and systemd-resolved.
Re: dhcpleased(8) and resolvd(8) enabled in base, replacing dhclient(8)
#5> 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…
But in the case of Linux distributions do they let the older solution remain available.
Re: dhcpleased(8) and resolvd(8) enabled in base, replacing dhclient(8)
#6> 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…
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.
Re: dhcpleased(8) and resolvd(8) enabled in base, replacing dhclient(8)
#7> 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…
Also interesting to note that dhcpleased and resolvd are loosely analogous to systemd-networkd and systemd-resolved.
Makes it easier for embedded system to exist without systemd.
Re: dhcpleased(8) and resolvd(8) enabled in base, replacing dhclient(8)
#8> 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…
But in the case of Linux distributions do they let the older solution remain available.
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.
Re: dhcpleased(8) and resolvd(8) enabled in base, replacing dhclient(8)
#9> 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 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.
Re: dhcpleased(8) and resolvd(8) enabled in base, replacing dhclient(8)
#10> 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…
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, and just forwards data to your existing syslog daemon.
Quite a difference from "will encounter increasing difficulty sticking to it."