Live data from Hacker News

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

undeadly.org

31–40 of 79 posts

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

#31

Earlier quoted context omitted.

> 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 sha…

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 switchin…

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 :)

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

#32
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.

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

#33

Earlier quoted context omitted.

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 switchin…

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

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

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

#34

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, a…

I think the current path of least resistance would be unwind with unwind.conf forwarding to unbound.

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

#35
post #30
post #13

Earlier quoted context omitted.

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.

We're in a thread about OpenBSD, a Unix that keeps literally the entire OS (except for ports) in one repo, and ships them together. So this is a strange criticism to make.

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!

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

#36

Earlier quoted context omitted.

> 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 sha…

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 switchin…

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

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

#37

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, a…

I think the current path of least resistance would be unwind with unwind.conf forwarding to unbound.

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).

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

#38

Earlier quoted context omitted.

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 switchin…

> 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 bo…

Yep. Hit that one too.

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

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

#39
post #30

Earlier quoted context omitted.

We're in a thread about OpenBSD, a Unix that keeps literally the entire OS (except for ports) in one repo, and ships them together. So this is a strange criticism to make.

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 ot…

They are free to make that criticism but they should do it without invoking "the Unix philosophy" which Linux has never adhered to.

Unix never had interchangable components like that.

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

#40

Earlier quoted context omitted.

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

> 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 co…

Doesn't POSIX and Linux Standard Base already mandate certain scripting languages to be preinstalled, such as Python?
Post reply on HN