8 ms·

dhcpleased(8) and resolvd(8) enabled in base, replacing dhclient(8)

117 points by zdw 5y ago

bonzini 5y ago
> 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?
- egberts1 5y ago
  We can’t block systemd from making a network socket/connection so we daemonized the network aspects.
- Denvercoder9 5y ago
  Also interesting to note that dhcpleased and resolvd are loosely analogous to systemd-networkd and systemd-resolved.
  - egberts1 5y ago
    Makes it easier for embedded system to exist without systemd.
- 1vuio0pswjnm7 5y ago
  But in the case of Linux distributions do they let the older solution remain available.
  - Denvercoder9 5y ago
    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.
  - theamk 5y ago
    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."
    - 1vuio0pswjnm7 5y ago
      How about removing all of it and just running daemontools, runit or s6. Is this easy.
      - epse 5y ago
        Not that bad, if you consider writing your own unit files for each service because the system only provides systemd
    - yrro 5y ago
      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.
    - 1vuio0pswjnm7 5y ago
      This is what Torvalds had to say about the developers of systemd https://web.archive.org/web/20161210172826/http://article.gmane.org/gmane.linux.kernel/1368617 https://web.archive.org/web/20161210172826/http://article.gm...
- tinus_hn 5y ago
  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.
  - op00to 5y ago
    I didn’t see this with systemd either, so that’s good.
    - kasabali 5y ago
      Which part of "gently pushing" didn't you see? https://lists.freedesktop.org/archives/systemd-devel/2010-September/000391.html https://lists.freedesktop.org/archives/systemd-devel/2010-Se...
      - op00to 5y ago
        The last time I read that thread I was just learning to ride a dinosaur.
        tinus_hn 5y ago
        That must have been a long time ago. Remind me, when did the project recant this position?
- throw0101a 5y ago
  > 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://cvsweb.openbsd.org/ports/net/isc-dhcp/ * https://github.com/openbsd/ports/tree/master/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.
  - Denvercoder9 5y ago
    > 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.
rascul 5y ago
Might be useful to add OpenBSD in the title somewhere.
- zdw 5y ago
  OpenBSD was in the title when I originally posted this but it was removed...
  - notaplumber 5y ago
    It definitely should not have been, this is news related to OpenBSD, there are no portable versions of either daemon.
- amatecha 5y ago
  mod suggestion: could just prepend the title with "OpenBSD Journal: "
daneel_w 5y ago
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.
- tedunangst 5y ago
  I think the current path of least resistance would be unwind with unwind.conf forwarding to unbound.
  - daneel_w 5y ago
    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).
    - rsmarples 5y ago
      I agree, although I am biased! resolvconf was designed to take DNS inputs from many sources and allow the user to tailor these to their needs.
nine_k 5y ago
This is very reasonable. I hope a Linux port will appear soon. While it's not yet ported, I use dnsmasq to allow several dynamical DNS resolvers plug and unplug themselves from the systemwide resolver.
endymi0n 5y ago
I couldn't not read a "please" into dhcpleased, so I immediately had a flashback to this being a joke or a reference to INTERCAL: https://en.wikipedia.org/wiki/INTERCAL#Details https://en.wikipedia.org/wiki/INTERCAL#Details

117 points by zdw 5y ago

> 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?

egberts1 5y ago
We can’t block systemd from making a network socket/connection so we daemonized the network aspects.
Denvercoder9 5y ago
Also interesting to note that dhcpleased and resolvd are loosely analogous to systemd-networkd and systemd-resolved.
- egberts1 5y ago
  Makes it easier for embedded system to exist without systemd.
1vuio0pswjnm7 5y ago
But in the case of Linux distributions do they let the older solution remain available.
- Denvercoder9 5y ago
  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.
- theamk 5y ago
  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."
  - 1vuio0pswjnm7 5y ago
    How about removing all of it and just running daemontools, runit or s6. Is this easy.
    - epse 5y ago
      Not that bad, if you consider writing your own unit files for each service because the system only provides systemd
  - yrro 5y ago
    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.
  - 1vuio0pswjnm7 5y ago
    This is what Torvalds had to say about the developers of systemd https://web.archive.org/web/20161210172826/http://article.gmane.org/gmane.linux.kernel/1368617 https://web.archive.org/web/20161210172826/http://article.gm...
tinus_hn 5y ago
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.
- op00to 5y ago
  I didn’t see this with systemd either, so that’s good.
  - kasabali 5y ago
    Which part of "gently pushing" didn't you see? https://lists.freedesktop.org/archives/systemd-devel/2010-September/000391.html https://lists.freedesktop.org/archives/systemd-devel/2010-Se...
    - op00to 5y ago
      The last time I read that thread I was just learning to ride a dinosaur.
      - tinus_hn 5y ago
        That must have been a long time ago. Remind me, when did the project recant this position?
throw0101a 5y ago
> 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://cvsweb.openbsd.org/ports/net/isc-dhcp/ * https://github.com/openbsd/ports/tree/master/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.
- Denvercoder9 5y ago
  > 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.

rascul 5y ago

Might be useful to add OpenBSD in the title somewhere.

zdw 5y ago
OpenBSD was in the title when I originally posted this but it was removed...
- notaplumber 5y ago
  It definitely should not have been, this is news related to OpenBSD, there are no portable versions of either daemon.
amatecha 5y ago
mod suggestion: could just prepend the title with "OpenBSD Journal: "

daneel_w 5y ago

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.

tedunangst 5y ago
I think the current path of least resistance would be unwind with unwind.conf forwarding to unbound.
- daneel_w 5y ago
  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).
  - rsmarples 5y ago
    I agree, although I am biased! resolvconf was designed to take DNS inputs from many sources and allow the user to tailor these to their needs.

nine_k 5y ago

This is very reasonable. I hope a Linux port will appear soon. While it's not yet ported, I use dnsmasq to allow several dynamical DNS resolvers plug and unplug themselves from the systemwide resolver.

endymi0n 5y ago

I couldn't not read a "please" into dhcpleased, so I immediately had a flashback to this being a joke or a reference to INTERCAL: https://en.wikipedia.org/wiki/INTERCAL#Details https://en.wikipedia.org/wiki/INTERCAL#Details