[HN Gopher] dhcpleased(8) and resolvd(8) enabled in base, replac...
___________________________________________________________________
dhcpleased(8) and resolvd(8) enabled in base, replacing dhclient(8)
Author : zdw
Score : 41 points
Date : 2021-07-17 20:48 UTC (2 hours ago)
(HTM) web link (undeadly.org)
(TXT) w3m dump (undeadly.org)
| rascul wrote:
| Might be useful to add OpenBSD in the title somewhere.
| bonzini wrote:
| > 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 wrote:
| We can't block systemd from making a network socket/connection
| so we daemonized the network aspects.
| Denvercoder9 wrote:
| Also interesting to note that dhcpleased and resolvd are
| loosely analogous to systemd-networkd and systemd-resolved.
| egberts1 wrote:
| Makes it easier for embedded system to exist without systemd.
| 1vuio0pswjnm7 wrote:
| But in the case of Linux distributions do they let the older
| solution remain available.
| Denvercoder9 wrote:
| 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 wrote:
| 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 wrote:
| How about removing all of it and just running daemontools,
| runit or s6. Is this easy.
| tinus_hn wrote:
| 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.
| throw0101a wrote:
| > _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.
| Denvercoder9 wrote:
| _> 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.
| rkangel wrote:
| 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.
| IgorPartola wrote:
| 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?
| throw0101a wrote:
| > _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(tm) 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.
| Denvercoder9 wrote:
| _> 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.
| cesarb wrote:
| > 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.)
| throw0101a wrote:
| > _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]
___________________________________________________________________
(page generated 2021-07-17 23:00 UTC)