The "Devuan" Debian fork and the fuss about systemd

Posted Dec 3, 2014 8:26 UTC (Wed) by mgb (guest, #3226)
In reply to: The "Devuan" Debian fork and the fuss about systemd by Cyberax
Parent article: The "Devuan" Debian fork

> I'm connected to a VPN and I have a media-center in my home network. Which DNS server should resolve its name?

If you were a client on one of our business VPNs the answer while you were connected would be that no DNS server should resolve the name of your media center for you.

Your sysadmin may have different requirements but it's unlikely he or she would want you to use possibly malicious DNS servers that systemd hears about from DHCP.

DNS server priority and VPNs (was: The "Devuan" Debian fork and the fuss about systemd)

Posted Dec 3, 2014 9:35 UTC (Wed) by cesarb (subscriber, #6266) [Link] (6 responses)

I don't know much about how VPNs are configured in the real world, and this seems like a good opportunity to learn. So far, I've only used "toy" VPNs with vtun, and I don't recall using alternate DNS servers with them.

How does a VPN server tell the client which DNS server to use? Is it DHCP over the virtual link? Is it IKEv2's configuration attributes? Is it PPP's negotiation? Something else?

In none of the options I just mentioned, AFAIK, there's a "override other DNS servers" flag (it wouldn't even make sense - what if the user were to connect to more than one VPN setting the same "override other DNS servers" flag?). So there must be some other mechanism by which the VPN server administrator tells the client to use the VPN's DNS servers and only the VPN's DNS servers. Do you know where I could read more about that mechanism?

Because without such a mechanism, the most logical response from the VPN client software would be to dump all learned DNS servers from all links in the /etc/resolv.conf file, where they would be queried either in random order or in sequential order. In the latter case, the ordering between "work" and "home" VPNs (pizza's and Cyberax's examples both have two VPNs) would depend on which one was connected to last.

DNS server priority and VPNs (was: The "Devuan" Debian fork and the fuss about systemd)

Posted Dec 3, 2014 9:58 UTC (Wed) by kleptog (subscriber, #1183) [Link] (5 responses)

Well, what used to happen is that the VPN servers/DHCP clients would dump all over the settings in resolv.conf and if you were lucky it would put them back after disconnect. The DNS settings are part of the setup packet, just like the routes and gateways. If you had multiple VPNs and/or DHCP your DNS would work about 50% of the time. Basically you had to configure it manually.

So instead a bit of glue called resolveconf was created and each program that wanted to setup DNS would dump its settings in a directory and another script would look at its priority list and select the one with the highest prio.

This mostly works, although it can in no way merge the results. You get one of the choices, but you have some control over the choice.

What happened in my case is that one of those files got created and had a high prio (NetworkManager is dead last in prio) but the DHCP client had gone. Hence broken DNS. Ofcourse, these files are stored in /var/run so a reboot would have fixed it but that's the lame solution. You can edit /etc/resolv.conf by hand, but it just gets overwritten again next time you start a VPN.

Once you have a daemon that knows the relationship between the DNS settings and the VPN server/DHCP client (like in systemd) it can make sure the settings are correct even if the server dies abnormally.

You could have done this by making resolv.conf smarter, but sysvinit doesn't provide a way to determine if something is still running. Note that NetworkManager has some smarts internally so if you're only using that it works better. But if you use stuff besides that you're left with the glory of resolveconf.

DNS server priority and VPNs (was: The "Devuan" Debian fork and the fuss about systemd)

Posted Dec 3, 2014 12:44 UTC (Wed) by mgb (guest, #3226) [Link] (4 responses)

> Once you have a daemon that knows the relationship between the DNS settings and the VPN server/DHCP client (like in systemd) it can make sure the settings are correct even if the server dies abnormally.

Except that systemd doesn't do that.

Poettering did propose an extension to handle the xhamster problem[1] but the existing Domains="..." option and the new Domains="*" syntax are the opposite of VPN DNS security. Systemd also lacks the dynamic reconfiguration which resolvconf provides.

Without a clean functional design systemd is forever adding more and more keywords to the systemd hairball and it's still not even close to implementing the functionality provided but existing trusted solutions.

[1] http://lists.freedesktop.org/archives/systemd-devel/2014-...

DNS server priority and VPNs (was: The "Devuan" Debian fork and the fuss about systemd)

Posted Dec 4, 2014 21:19 UTC (Thu) by paulj (subscriber, #341) [Link] (3 responses)

Yeah, the ever growing number of options for service/unit/etc. files are starting to make even the more complicated shell scripts in older init systems looksensible. :(

DNS server priority and VPNs (was: The "Devuan" Debian fork and the fuss about systemd)

Posted Dec 4, 2014 21:41 UTC (Thu) by anselm (subscriber, #2796) [Link] (2 responses)

At least the systemd options are documented in very visible man pages. Most of the clever hacks in the more complicated init shell scripts of the traditional setup aren't.

DNS server priority and VPNs (was: The "Devuan" Debian fork and the fuss about systemd)

Posted Dec 4, 2014 22:05 UTC (Thu) by mgb (guest, #3226) [Link] (1 responses)

> At least the systemd options are documented in very visible man pages. Most of the clever hacks in the more complicated init shell scripts of the traditional setup aren't.

To boot a traditional sysvinit server you just need to get the sequence numbers in order - something that your distro almost always gets right and you never need to change.

There's no more need for you to try to understand how shell scripts are written than there is for you to be able to disassemble ELF files in your head.

Systemd is much more complicated - and much more prone to random boot failure - because it is so much harder to express every one of the O(N^2) dependencies and it's not feasible to prove whether your dependency graph is complete.

DNS server priority and VPNs (was: The "Devuan" Debian fork and the fuss about systemd)

Posted Dec 5, 2014 0:07 UTC (Fri) by mchapman (subscriber, #66589) [Link]

> Systemd is much more complicated - and much more prone to random boot failure - because it is so much harder to express every one of the O(N^2) dependencies and it's not feasible to prove whether your dependency graph is complete.

Oh, puhlease. Very few units need inter-service dependencies (on my system, it appears to be about a fifth of them). Those that do are usually bundled together anyway (e.g. sshd.service wants sshd-keygen.service). The remaining dependencies are mostly along the lines of "I need the network" (and the service is not smart enough yet to work before the network has been brought up). Most dependencies are "wants" rather than "requires" anyway, which makes it very *hard* to break boot.

The sysadmin simply doesn't need to worry themselves about this stuff. A simple "systemctl list-dependencies multi-user.target" proves that systemd can solve this problem completely on its own.