
Sad news today: systemd-resolved to be deployed in Ubuntu 16.10 - rcarmo
https://lists.dns-oarc.net/pipermail/dns-operations/2016-June/014964.html
======
tener
If systemd is so horrible why is everyone switching to it? EDIT: This is an
honest question. I read quite a few negative comments on it and yet people in
charge seem to be convinced this is the way forward. I'm curious why.

~~~
jacquesm
Because systemd makes certain desktop related tasks easier to present to the
user. It's a huge loss imnsho because linux on the desktop wasn't held back by
a lack of such niceties but by market conditions, at the same time linux on
the _server_ will be held back by systemd because of its tendency to do things
'its' way.

I haven't seen any single subsystem harm the linux eco-system as much as
systemd has and while I understand the desktop vendors clout in this the
server is where linux shines and that was territory that was hard won.

If all systemd had done was offer an alternative init system then that would
have been a non-event, to take over the entirety of the linux system side
tried-and-true and battle tested utilities is irresponsible at best and
dangerous at worst. It wasn't broken, so it did not need fixing / rewriting.

~~~
maheart
I use systemd on my desktop, mobile phone, and servers. I'm paid to maintain
Linux servers. systemd is a _great_ addition to the Linux server ecosystem.
It's infinitely easier to write a systemd init script that is functionally
correct, than it is to write the equivalent init script in shell.

> It wasn't broken, so it did not need fixing / rewriting.

Writing a robust init script in shell is a HUGE pain. Every distro seemed to
have their own tools and methods for writing init scripts (e.g. Red Hat had
/etc/init.d/functions, Debian had its own, Ubuntu had upstart) -- all of them
sucked. systemd makes it easy (and for the most part, portable across systemd
distros).

~~~
snaky
> Writing a robust init script in shell is a HUGE pain

In trivial case, it's simple in any modern distro [1]

In non-trivial case, it's complicated. And the complexity is not going away,
all you can do is move the complexity to one corner or another.

When you add the complexity to the shell script, it's right there, plain and
clear.

When you move the complexity to systemd, it's not magically goes away - it
just moves to thousands of lines of C code (of not the best quality on this
planet, to say the least).

[1]
[https://wiki.gentoo.org/wiki/Handbook:X86/Working/Initscript...](https://wiki.gentoo.org/wiki/Handbook:X86/Working/Initscripts#Writing_initscripts)

~~~
scrollaway
> When you move the complexity to systemd, it's not magically goes away

You're ignoring that complexity was added to _every single init script_. Every
init script had its own potential bugs, issues, race conditions, dependency
logic, etc etc.

Now you're moving it to one single master system.

No, it's not "magically going away". The _repetition_ is going away. The code
duplication of an extremely complex system is going away.

~~~
snaky
The repetition is easy. Any modern Linux distro solved the repetition problem
long ago. You don't need systemd monster for that.

    
    
      depend() {
        need localmount
        after bootmisc
      }
      reload() {
        ebegin "Reloading configuration"
        start-stop-daemon --signal HUP --pidfile ${pidfile} ${command##*/}
        eend $?
      }

~~~
scrollaway
systemd the init system is by no means a monster (may I remind you and
everyone else again that -resolved is merely a project under the systemd
umbrella).

I'm not even sure where to begin when addressing a comment like this. You're
biased against systemd in the first place so I don't see the point in
discussing this.

It's really amusing that basic software engineering principles are thrown out
of the window the moment things get political.

~~~
snaky
The modularity of systemd-the-monster is greatly overrated. The "basic
software engineering principles" you are talking about are not about tightly-
coupled interdependent in and out ball of mud with no documented protocols and
APIs.

Things get political that very second back then when systemd crowd started
pushing their agenda to the masses using strategies like _gentle push_.

------
3princip
I have used Linux (mainly Ubuntu) exclusively for years and love it. I do some
devops when needed, run a few websites etc. Granted, I'm not a full-time
sysadmin but I do plenty of work with Linux.

I don't understand why systemd is taking over or what benefit it has bought.
It works for now, is that enough?

It feels like a monstrosity of overly complex and questionable design. Yet, it
spreads. Throwing "unix philosophy", a most agreeable set of ideas, out the
window.

Maybe I'm just being reactionary and slow to adapt.

~~~
Macuyiko
I agree. First the whole thing about systemd closing nohup and screen
processes on logout and now this... I have been thinking about switching to
freebsd as well, at least for my server environments.

Any good recommendations re: Linux distros that follow the Unix philosophy
closely whilst still being up to date in terms of packages?

~~~
akerro
The last on battle field are Void Linux, Slackware and Getnoo.

~~~
thde
Don't forget Alpine Linux

------
userbinator
_The process turns a request for binary DNS data into into XML, feeds it into
the sytemd /dus ecosystem, which turns it into binary DNS to send it to the
forwarder. The binary DNS answer then gets turned into XML goes through
systemd/dbus, then is turned back into binary DNS to feed back into glibc._

This reminds me of [http://thedailywtf.com/articles/XXL-
XML](http://thedailywtf.com/articles/XXL-XML) and the "XML fever" that
infected most of the enterprise and otherwise software developers many years
ago. Whenever I see some system XML-ifying everything, it's usually a good
indicator of grotesque complexity elsewhere in it too.

~~~
scrollaway
How else would you send the data to dbus? dbus is xml-based.

This is caused by resolved requiring a separate forwarder. "XML" isn't
inherently bad.

~~~
wtbob
> dbus is xml-based.

No, it's not: [https://dbus.freedesktop.org/doc/dbus-
specification.html](https://dbus.freedesktop.org/doc/dbus-specification.html)

> "XML" isn't inherently bad.

Yes, it is (well, as a data format; as a markup language it's ugly but
serviceable). XML is incredibly verbose, arcanely complex and a colossal time-
sink of man-hours which could have been spent on pretty much anything else in
computing. It's the JavaScript of data formats (which is amusing, since
JavaScript's data format JSON is actually not half bad).

------
Philipp__
What really struck me was the fact that desktop community (not sure if this
would be happiest word for it, but I think you'll understand) is dictating the
fate of whole Linux. For me Linux was and is primary a server OS. Than
worsktation one, and on the last spot consumer desktop OS. I mean for desktop
perspective systemd maybe isn't _that_ bad, but for servers I am sure there
are better solutions.

~~~
maheart
I maintain Linux servers. I also write backend/server software. systemd is a
Godsend. It's infinitely easier to write a systemd init script, than it is to
write a robust init script in shell.

systemd (by leveraging cgroups) makes it easier to 'track' started processes.
It makes it easier to stop/kill processes. It also provides handy security
features (e.g. PrivateTmp).

~~~
nisa
Can we stop talking about the init scripts? systemd does that well, we all got
it. I personally was not overwhelmed when having to use it but it's step
forward from sysv init scripts - no one sane doubts that.

All the recent talk about systemd is about the other components that replace
certain basic userland compoments.

logind for sessions changed the default to kill background tasks on logout,
now it's about the implementation of the dns resolver that comes with systemd.
There are other implementations that replace cron, ntpd, syslog...etc.pp. All
of this has a dependency on glibc and uses dbus.

This has nothing to do with init scripts. This is an attempt to improve on the
status quo of userland tools close to the OS. systemd appears to provide some
minimal userland that comes with a Linux kernel and aims to be a userland API.
I personally think this is a bad idea but I kind of see the point why you
might want to do this.

The IMHO absolutely warranted criticism for some of these replacements is that
they are not better designed, that they create new dependencies and complicate
things without reason and there is a tendency to create some systemd specific
API that userland has to implement - breaking compatibility with other POSIX
systems - something that was hard to do even before systemd.

So it's not about init scripts - it's about revamping essential userland tools
in a way that's badly designed according to some.

Personally I hold no grudge against this but I'm not keen on using this or
having to deal with this as a sysadmin. It's a undocumented black box once you
have run into problems and you are busy reading C code or capturing dbus
calls. I have usually better things to do.

And for the initscripts - you could have done this with runit/s6 and mkdir
with cgroups in 2008 if you wanted. You could have used setsid before that.
This was deprecated and now systemd (or something else that implements the
kernel API) is the whole mananger of cgroups.

I personally think the systemd way is not the right direction to take as it's
horrible inflexible and will bite Linux but I can understand why you might
disagree here strongly.

~~~
ZeroGravitas
It's interesting that at least twice in these comments someone has claimed
that this was a desktop technology that was going to ruin servers, and when
server using professionals reply that it's really good for servers they get
what read to be quite angry responses.

I don't know much about it, but even from my position of ignorance it's clear
that the level of debate is very low.

~~~
digi_owl
I wonder how many of those servers are web hosts.

There seems to be a line drawn where those that do web hosting and similar
love systemd, while other server admins loath it for introducing needless
complexities.

I have taken to thinking about web hosting as "uptime by machine gun". This in
that they achieve uptime not by maintaining solid server configs, but by
rapidly firing containers and/or VMs at the problem until it goes away.

[http://www.commitstrip.com/en/2015/07/08/true-story-
fixing-a...](http://www.commitstrip.com/en/2015/07/08/true-story-fixing-a-
self-ddos/)

~~~
snaky
Seems to be true since the famous "400 restarts a day is OK"

[http://harmful.cat-v.org/software/ruby/rails/is-a-
ghetto](http://harmful.cat-v.org/software/ruby/rails/is-a-ghetto)

~~~
digi_owl
dear deity...

------
akerro
I just gave up on Linux distributions and switched to FreeBSD. Every year
there are more steps backward in every Linux disto than good changes.

~~~
naivepiano
I see that this change (systemd) is mostly driven by desktop software dev
teams. If linux chooses to care mostly about the desktop aspect (IMHO previous
such experiments like Unity were total flops but I'm not an expert) instead of
its server one then maybe that's the opportunity for BSDs to cover up the
void. Not a bad thing at all.

~~~
akerro
No, I think it's good change. Last year I stopped contributing to ArchLinux,
I'm seriously considering doing the same for FreeBSD/PC-BSD now. BSDs have a
lot to catch-up, even things like network-manager don't work on BSD, it have
to be ported, or network connections have to be configured manually in rc
files. Personally it's ok for me to work like that. OpenVPN configuration in
FBSD was EASIER than doing the same in UI on KDE5 nm-applet. (Personal
opinion->) I think connection to VPN providers is more stable and I lose less
data on BSD than on Arch. So it was another benefit :) Generally a lot of
things are much easier in BSDs, there is literally ONE manual for everything
and it applies from FBSD-NetBSD-OpenBSD-DragonFlyBSD. When one manual for a
thing for ArchLinux doesn't apply to Ubuntu or even worse tutorial from Ubuntu
doesn't work on Debian, things become ugly... I value it a lot.

~~~
gaius
_things like network-manager don 't work on BSD_

That is a feature not a bug.

~~~
akerro
Why? My parents are using openSUSE because it's very Windows-like, they would
have no chance against PC-BSD.

------
abgrant
Sad indeed. Every IT product reaches a stage where the basic things are done.
Then bloat is added to keep programmers employed and to create new problems
that secure a steady income from consulting.

But perhaps I'm biased: I just had to use chattr to keep the &/!&%"/!
NetworkManager from overwriting /etc/resolv.conf. All these things just worked
10 years ago.

~~~
justinsaccount
> All these things just worked 10 years ago

10 years ago most resolvers did not use source port randomization no one had
DNSSEC deployed.

~~~
JdeBP
10 years ago would be 2006. In 2006, three of the most popular DNS server
softwares, djbdns, PowerDNS (ranked third in a contemporary survey of content
DNS servers), and MaraDNS, all had source port randomization. As did mine,
although its ranking was somewhat lower. (-:

djbdns had had it since the previous century, MaraDNS for 5 years, mine for
roughly the same, and PowerDNS for (I think) 1.

~~~
justinsaccount
I said resolvers, not servers. What client side dns libraries did source port
randomization in 2006?

~~~
JdeBP
Resolvers are exactly what I told you about. You clearly don't know the
jargon.

The RFC terminology for in-application DNS client libraries is _stub
resolvers_. RFC 1034 section 5.3.1. A _resolver_ in contrast is the complete
subsystem, sometimes implemented as a stub resolver together with a separate
program that it makes remote procedure calls to, that does query resolution.
RFC 1034 section 2.4.

Yes, it's arcane terminology. It's not mine. I've been telling people to think
of DNS like HTTP since the turn of the century. But if you use it, use it
correctly.

* [http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/dn...](http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/dns-server-roles.html)

~~~
justinsaccount
Great... can you answer my question?

What client side dns libraries did source port randomization in 2006? AFAIK it
wasn't until 2008 when most things were fixed.

People keep talking about the good old days before systemd where everything
worked perfectly, but that ignores the fact that things were pretty broken.

If you care about things like local caching and failover, things are still
pretty broken. Most unix systems are horribly fragile out of the box. You
either run something like dnsmasq or unbound locally or use a hack like
[https://github.com/kvz/nsfailover](https://github.com/kvz/nsfailover). A
large number of distributed systems completely grind to a halt when the
primary name server fails (if only everyone used anycast...)

------
vidarh
I'm conflicted about this. I've yet to find a Linux distribution that actually
acts the way the documentation for /etc/resolv.conf claims the options in
resolv.conf should work (most of the options do nothing or work differently
than you'd expect).

Basically, if you rely on the system/glibc provided DNS resolution on most
Linux distros and you want reliability, your best bet is to run a local DNS
server and point everything there either way.

That's not changing with systemd-resolved in the state it is today, but who
knows, maybe someone actually paying attention to the resolver stub will
finally make that situation improve.

~~~
JdeBP
> _most of the options do nothing or work differently than you 'd expect_

Please give examples.

------
voltagex_
>\- It accepts DNS forwarders for all its interfaces. That means if you are on
wifi and 3g, or ethernet and wifi, you have more than one DNS server from
logically different networks. With no way of guaranteeing which logical
network you asking.

That's going to be very inconvenient for laptop users...

~~~
steventhedev
How does this play out with wifi networks that resolve dns requests for say,
"google.com" with their "click to accept the terms of your municipal free
wifi" page?

~~~
bazzargh
I use a mac and the same issue is there; all I do is override the DNS on the
wireless connection to use 8.8.8.8. In systemd-land, I'd expect that to be in
/etc/systemd/wireless.network:

    
    
        [Match]
        Name=wlan0
    
        [Network]
        DNS=8.8.8.8
    

(other settings omitted). However, DNS hijacking isn't necessary for a captive
portal - they can reroute port 80 traffic and respond with 511 per
[https://tools.ietf.org/html/rfc6585#section-6](https://tools.ietf.org/html/rfc6585#section-6),
(quite common now as the interaction is better for non-browser phone apps) or
advertise the login page via DHCP as in
[https://tools.ietf.org/html/rfc7710](https://tools.ietf.org/html/rfc7710).

~~~
steventhedev
not necessary, and yet very common. And setting your DNS server to 8.8.8.8
doesn't help when they reply with their internal gateway for all DNS requests.

FYI - android fires a request to
[http://clients3.google.com/generate_204](http://clients3.google.com/generate_204),
I'm fairly confident windows/ios/mac/ubuntu all do something similar.

------
pmontra
I'm surprised that so many comments are about systemd, if it is evil or not,
and so few about this actual issue. Is a system with this DNS implementation
safe, would it work, is something you want to use?

Maybe the author is biased but the list of issues and potential
vulnerabilities is so long that there could be CVEs reserved now waiting only
for the release of software.

------
sunseb
Systemd is arguably the most hated Linux software ever. Why have all major
distros switched to this thing ? I don't get it.

~~~
corney91
A good description of why it's superior to init scripts:
[https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_a...](https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_archlinux_embrace_systemd/d3rhxlc)

I don't know enough about resolved to comment on this new development, but as
a sysadmin I much prefer systemd as an init system.

~~~
dkarapetyan
Upstart wasn't bad at all. It actually worked really well. I've never dealt
with other init scripts but now that my dev/deploy target is freebsd I don't
really see any issues with shell scripts as init scripts either. I don't need
any fancy parallelization and socket activation and all that fancy jazz for a
backend server.

~~~
pas
It was unfinished, almost unmaintained, and basically left for dead. It was
(and is still) a lot better than shell scripts, but the problem (of system
[lifecycle] management, including initialization) is complex and hard to
isolate/decouple and evolve in a sane manner.

------
JdeBP
> _It uses nsswitch to basically take over gethostbyname() and getaddrinfo().
> This means any software using a DNS library like ldns, unbound, bind, knot,
> etc bypasses this system and gets an inconsistent DNS view from the rest of
> the system. It explicitly does not support those kind of applications._

> _It won 't work well with applications that have their own DNS code inside.
> Such as browsers._

The systemd developers have addressed M. Wouters' charges as follows. Such
applications are classed as

> _legacy software which does not use libnss-resolve_

\--
[https://github.com/systemd/systemd/issues/3420#issuecomment-...](https://github.com/systemd/systemd/issues/3420#issuecomment-223245328)

and

> _legacy DNS clients_

\--
[https://github.com/systemd/systemd/issues/3420#issuecomment-...](https://github.com/systemd/systemd/issues/3420#issuecomment-223253526)

The systemd developers maintain that

> _programs really should use NSS (with nss-resolve as backend) or resolved 's
> native bus APIs, but not talk DNS themselves._

\--
[https://github.com/systemd/systemd/issues/3420#issuecomment-...](https://github.com/systemd/systemd/issues/3420#issuecomment-223253526)

------
JdeBP
It's interesting to contrast Paul Wouters' dismissal of source port
randomization with the conversation on the Ubuntu mailing list with Martin
Pitt, the systemd developer and Ubuntu systemd maintainer whose announcement
precipitated M. Wouters' critique.

> > _source port randomization is enabled by default to further protect
> against DNS spoofing attacks._

> [...] _source port randomization is pretty useless_ [...]

\-- Paul Wouters, [https://lists.dns-oarc.net/pipermail/dns-
operations/2016-Jun...](https://lists.dns-oarc.net/pipermail/dns-
operations/2016-June/014964.html)

> _ATM resolved uses randomized ID fields_ [...] _. It does not use source
> port randomization though,_

\-- Martin Pitt, [https://lists.ubuntu.com/archives/ubuntu-
devel/2016-May/0393...](https://lists.ubuntu.com/archives/ubuntu-
devel/2016-May/039364.html)

> _I 'm concerned what this says about the maturity of the project: djbdns
> introduced source port randomization back in 1999._

\-- Seth Arnold, [https://lists.ubuntu.com/archives/ubuntu-
devel/2016-May/0393...](https://lists.ubuntu.com/archives/ubuntu-
devel/2016-May/039370.html)

~~~
digi_owl
Wouters dismissal seems to be related to resolved being a LAN DNS only.

> ... as you are most likely just doing DNS on the local network.

~~~
JdeBP
It is the predication on something that M. Pitt says isn't the case that
provides the contrast, however.

------
insulanian
What are some good resources for getting up to speed with systemd quickly for
a web dev who didn't do extensive Linux administration besides setting up
hosting on EC2 instances with nginx and REST API controlled by supervisor
(software)?

~~~
pas
[https://www.digitalocean.com/community/tutorials/systemd-
ess...](https://www.digitalocean.com/community/tutorials/systemd-essentials-
working-with-services-units-and-the-journal) for the bare minimum

[http://linoxide.com/linux-how-to/systemd-boot-
process/](http://linoxide.com/linux-how-to/systemd-boot-process/) for how it
starts up

[https://lwn.net/Articles/604609/](https://lwn.net/Articles/604609/) cgroups
[https://lwn.net/Articles/531114/](https://lwn.net/Articles/531114/)
namespaces

[https://dvdhrm.wordpress.com/2013/07/08/thoughts-on-linux-
sy...](https://dvdhrm.wordpress.com/2013/07/08/thoughts-on-linux-system-
compositors/) logind/sessions/seats

[http://0pointer.net/blog/projects/socket-activated-
container...](http://0pointer.net/blog/projects/socket-activated-
containers.html) and finally "the series" from the horse's mouth :)

------
yousry
sudo systemctl stop systemd-resolved sudo systemctl disable systemd-resolved

After that you can use whatever you like.

------
dkarapetyan
My new dev/deploy target is freebsd. It's actually kinda nice. It treats the
user with respect and doesn't pretend to know better.

------
vamur
Systemd sounds good in theory until you cannot disable systemd-journald and it
grows to 50M RAM. And out of nowhere dozens of gvfsd* processes are spawned
for no apparent reason.

------
mianos
Debian anyone?

~~~
i_have_to_speak
Debian 8 comes with systemd. There is a fork [1], but not really popular.

[1] [https://devuan.org/](https://devuan.org/)

~~~
misterwavey
it'd be funny to fork devuan and replace init with systemd.

