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)
In reply to: DNS server priority and VPNs (was: The "Devuan" Debian fork and the fuss about systemd) by kleptog
Parent article: The "Devuan" Debian fork

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