[Dnsmasq-discuss] systemd service improvements

[Craig Andrews]

I'd like to propose a couple changes in terms of systemd in dnsmaq.
First, dnsmasq should always install a systemd unit so all
distributions/users can use it (if a user/distro doesn't use systemd,
the unit will be simply be ignored - no harm done). Currently, the unit
is only part of the Debian packaging. Dnsmaq may want to include an
alternate unit in the Debian packaging and a generic, for-all-distros
version in the default installation.
Second, the systemd unit should be improved a bit to feature hardening
and not running as root. Here's my proposed dnsmasq.service:
---
[Unit]
Description=A lightweight DHCP and caching DNS server
After=network.target

[Service]
User=dnsmasq
Group=dnsmasq
Type=simple
PIDFile=/run/dnsmasq/dnsmasq.pid
ExecStartPre=/usr/sbin/dnsmasq --test
ExecStart=/usr/sbin/dnsmasq -k -x /run/dnsmasq/dnsmasq.pid
ExecReload=/bin/kill -HUP $MAINPID
RuntimeDirectory=dnsmasq
CapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_NET_ADMIN
AmbientCapabilities=CAP_NET_BIND_SERVICE CAP_NET_ADMIN
PrivateTmp=yes
PrivateDevices=yes
ProtectSystem=full
ProtectHome=yes
NoNewPrivileges=yes

[Install]
WantedBy=multi-user.target
---

Compared to
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=debian/systemd.service;h=40b8d27cba21400d8b56ecc4a85266879988911d;hb=HEAD
I think this is a nice improvement.

The only issue is that the Debian version uses /etc/init.d/dnsmasq and
depends on Debian's resolvconf which other distros won't have, hence
dnsmaq will probably want to keep a special unit for Debian.

Thanks,
~Craig

[Pali Rohár]

Post by Craig Andrews
I'd like to propose a couple changes in terms of systemd in dnsmaq.
First, dnsmasq should always install a systemd unit so all
distributions/users can use it

I'm against such change. Why on the Earth install useless files into
system which do nothing? I really do not want to see that programs
starts installing systemd files just because it is "no harm".

If such thing happen, dnsmasq then should install also config file for
upstart, also for openrc, and also install shortcut for Windows start
menu for *all* systems as that is too by that definition "no harm".

[Albert ARIBAUD]

Bonjour,

Le Thu, 30 Jun 2016 21:18:02 +0200

Post by Pali Rohár

Post by Craig Andrews
I'd like to propose a couple changes in terms of systemd in dnsmaq.
First, dnsmasq should always install a systemd unit so all
distributions/users can use it

I'm against such change. Why on the Earth install useless files into
system which do nothing? I really do not want to see that programs
starts installing systemd files just because it is "no harm".
If such thing happen, dnsmasq then should install also config file
for upstart, also for openrc, and also install shortcut for Windows
start menu for *all* systems as that is too by that definition "no
harm".

I tend to agree with the principle that a systemd unit file should
only be installed on systems which use systemd. I was surprised indeed
to see that the dnsmasq git repo contains such a file.

Furthermore, the OP itself indicates that different systemd-based
distributions will require different systemd units for dnsmasq, which
shows that systemd (or upstart, or sysvinit...) files should be managed
at the distribution, not upstream application, level.

Amicalement,

[Craig Andrews]

Greetings and salutations,

Post by Albert ARIBAUD
Bonjour,
Le Thu, 30 Jun 2016 21:18:02 +0200

Post by Pali Rohár

Post by Craig Andrews
I'd like to propose a couple changes in terms of systemd in dnsmaq.
First, dnsmasq should always install a systemd unit so all
distributions/users can use it

I'm against such change. Why on the Earth install useless files into
system which do nothing? I really do not want to see that programs
starts installing systemd files just because it is "no harm".
If such thing happen, dnsmasq then should install also config file
for upstart, also for openrc, and also install shortcut for Windows
start menu for *all* systems as that is too by that definition "no
harm".

I tend to agree with the principle that a systemd unit file should
only be installed on systems which use systemd. I was surprised indeed
to see that the dnsmasq git repo contains such a file.
Furthermore, the OP itself indicates that different systemd-based
distributions will require different systemd units for dnsmasq, which
shows that systemd (or upstart, or sysvinit...) files should be managed
at the distribution, not upstream application, level.
Amicalement,

I have no argument against only installing the systemd unit if a
configure flag is specified. Many pieces of software do it that way - I
think the important thing is that it's available from dnsmasq. So I
rescind my thought to install it unconditionally.

Regarding distributing config files for upstart, openrc, and everything
else - I think there are 2 ways to look at that:
1) systemd is used by many Linux distributions, and that number is
increasing. So by distributing it, the most users benefit, as compared
to the low, and decreasing, number of users of openrc and upstart.
2) If dnsmasq wants to distribute init configs for other init systems,
that seems fine. That would just mean that if, for example, dnsmasq
distributes an upstart configuration file, then all distributions/users
of upstart can collaborate in one place instead of all being siloed.

The goal of including the systemd unit is for there to be one place
(dnsmasq aka upstream) for fixes, improvements, and development to take
place. For example, if someone notices that dnsmasq can be hardened,
that change currently has to be made in every distribution separately.
That lack of collaboration is really inefficient - tons of effort is
being wasted. It also introduces confusion and maintainability problems;
with every distribution being inconsistent, that's just one more
variable dnsmasq has to deal with when a bug report or feature request
is made.

I'm not currently using Debian, so I can't comment too much on its
systemd unit. Ideally, I'd love to see the same unit used for all
distributions. But if that's not possible, just like how distributions
can patch source code if they have to, distributions can patch
upstream's systemd units. Such patching is not a reason to stop
distribution of something (be it source code, configuration, or anything
else).

Thanks,
~Craig

[Kurt H Maier]

Post by Craig Andrews
I have no argument against only installing the systemd unit if a
configure flag is specified. Many pieces of software do it that way - I
think the important thing is that it's available from dnsmasq. So I
rescind my thought to install it unconditionally.

What would the configure flag be passed to?

It would take more lines of code to modify the build process to suit
this than it would just to write the unit file, and then you'd still
have to rewrite the unit file for each distro.

The traditional allocation of init responsibilities has always been such
as to free the upstream developer from the administrative minutiae by
devolving the systems management functions to those whose experience and
daily operations have better formed them for the performance of such
maintenance takss, thereby releasing the upstream developers for the
more task-specific duties and deliberations.

In short, I still think a generic unit file in /contrib is best, and
people who want to use it will be okay if they have to copy it where
their OS wants it. dnsmasq runs in a lot of places systemd doesn't, so
systemd is not to be taken as given.

khm

[Kurt H Maier]

The "make" invocation. Just like how there is a "-DHAVE_DNSSEC" option,
there could be a "-DHAVE_SYSTEMD" one.

What is the advantage to putting this in the makefile itself? None of
the distributions you mentioned ship dnsmasq source directly; they ship
packages. The packagers all have build scripts. The build scripts put
the files into place. Why does this need to be offloaded onto dnsmasq?

The point isn't (necessarily) to conserve lines of code - the point is
to have one place for distributions/users to collaborate in order to
best develop and maintain this portion of the project. And each distro
does not (and absolutely should not) rewrite the unit file. (Would you
be happy if each distro patched dnsmasq? Same thing.)

Each distro *does* patch dnsmasq. Why does modifying dnsmasq's Makefile
make it easier for all these hypothetical people to contribute than
having the unit file in /contrib?

Right now, note how each of these distribution's systemd units are
https://github.com/gentoo/gentoo/blob/cae8d8ccd7658253a336a7595796f8a9264332de/net-dns/dnsmasq/files/dnsmasq.service-r1
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=debian/systemd.service;h=40b8d27cba21400d8b56ecc4a85266879988911d;hb=HEAD
http://pkgs.fedoraproject.org/cgit/rpms/dnsmasq.git/tree/dnsmasq.service
The differences are in paths (a Makefile can eliminate those difference)
and different security features (which are only different because some
distros didn't notice some security features).

Are you suggesting dnsmasq override distribution file heirarchies? And
why do you assume packagers "didn't notice" some of the security
features? Is it impossible they decided not to enable them for specific
reasons?

Distros are trying to use upstream units and get upstreams to include
* Fedora: https://fedoraproject.org/wiki/Packaging:Systemd#Unit_Files
"Ideally, systemd unit files are reusable across distributions and
shipped with the upstream packages. Please consider working with
upstream to integrate the systemd files you prepare in the upstream
sources."
* https://wiki.archlinux.org/index.php/DeveloperWiki:Systemd#Units "Use
the upstream unit files whenever they exist"

Fedora wants this because Red Hat pays the systemd maintainers, so any
time they can get other projects to do their work for them, they save
money. Arch wants this because they're undermanned and their packagers
need all the help they can get. I don't think either of these
conditions are universal.

A growing number of projects (big and small) have upstreamed systemd

I'm not sure "me, too" is a very good reason to make this change. I
would instead start by convincing the distros you mention above to use
the unit file dnsmasq already has in /contrib, and getting them all on
the same page. dnsmasq is a very flexible tool whose deployment needs
to be crafted to the situation in which it is used. Aside from some
tuning tweaks, most of the applications you list are classical
monoliths, where dnsmasq is very commonly used as part of a larger
package of tools.

In short, the only people who would save time on this are packagers, and
the only time it would really save them is not having to add a "copy
unit file" line in their build scripts.

For example, I frequently build dnsmasq for deployment to networking
devices of all shapes and sizes; a coworker most frequently builds
dnsmasq as part of openstack or docker+kubernetes development. In each
of those cases, we're building on a systemd-equipped machine, but we're
not installing dnsmasq as a systemwide service suitable for activation
by systemd. I'd argue that you may find such deployments of dnsmasq are
far, far more common than you'd think.

I support your plan to get all the distro packagers on the same page,
and standardize the unit file for everyone. I just really don't think
the dnsmasq build system is the place to do it.

khm

[Pali Rohár]

Post by Kurt H Maier
I'm not sure "me, too" is a very good reason to make this change. I
would instead start by convincing the distros you mention above to
use the unit file dnsmasq already has in /contrib, and getting them
all on the same page. dnsmasq is a very flexible tool whose
deployment needs to be crafted to the situation in which it is
used. Aside from some tuning tweaks, most of the applications you
list are classical monoliths, where dnsmasq is very commonly used as
part of a larger package of tools.

I fully agree, /contrib is the best place where to have it.

[Jan Psota]

Dnia 2016-07-05, o godz. 16:28:14
Craig Andrews <***@integralblue.com> napisał(a):
[...]

I agree with _all_ you've written.

(I'm Gentoo on systemd user - 7s to boot from grub prompt to xdm.
Booted from cheap pendrive not SSD! :-)

--
Jan Psota

[Kurt H Maier]

Post by Craig Andrews
I'd like to propose a couple changes in terms of systemd in dnsmaq.
First, dnsmasq should always install a systemd unit so all
distributions/users can use it (if a user/distro doesn't use systemd,
the unit will be simply be ignored - no harm done).

Incorrect. Aside from the uselessness of spamming systemd files onto
inappropraite OSes, systemd has very specific location requirements
for where these files may be installed -- which means a 'default'
installation of dnsmasq may wind up trying to create directories on a
partition it may not have write permission to, and a DESTDIR or PREFIX
installation may wind up putting service files in places not even
systemd would look for them.

Further, the systemd service file format has no specification and is
subject to arbitrary change. It is not fair to mandate the dnsmasq
maintainers (or any not-systemd-maintainer) track these changes and
try to keep up with them.

Finally, while I consider it very kind of Simon to include things like
this in contrib/, the face remains that systemd only runs on a subset of
linux distributions, the majority of which already have dnsmasq packages
available. Lots of people run dnsmasq on openbsd, freebsd, etc -- and
of course systemd unit files will do no good there.

This sort of idea makes sense for a very specific use case, but I am
certain it would only make the build process more complicated than it's
worth.

Post by Craig Andrews
is only part of the Debian packaging. Dnsmaq may want to include an
alternate unit in the Debian packaging and a generic, for-all-distros
version in the default installation.

Debian should be responsible for their own init scripts. Not just
Debian -- all packagers should be handling init in the manner
appropriate to their software environment. This is the *only* way to be
sure that the init method matches the process supervisor's requirements
and keeps up with configuration mandates therefrom.

Post by Craig Andrews
Second, the systemd unit should be improved a bit to feature hardening

This should go to the packagers of your operating system.

Respectfully,
khm

[Simon Kelley]

Replying to original post, but I've also read the rest of the thread.

I agree with most of the other replies: a systemd unit file is
equivalent to an init script - not something to be installed by the
dnsmasq source distribution,

you'll find that

make install

doesn't add any files apart from the dnsmasq binary and man page.

The dnsmasq source distro _does_ have a systemd unit file to act as a
template for distros/installations to use, its in contrib/systemd

I'm happy to add your code there, either as an alternative or
replacement of the existing unit file.

Cheers,

Simon.

Post by Craig Andrews
I'd like to propose a couple changes in terms of systemd in dnsmaq.
First, dnsmasq should always install a systemd unit so all
distributions/users can use it (if a user/distro doesn't use systemd,
the unit will be simply be ignored - no harm done). Currently, the unit
is only part of the Debian packaging. Dnsmaq may want to include an
alternate unit in the Debian packaging and a generic, for-all-distros
version in the default installation.
Second, the systemd unit should be improved a bit to feature hardening
---
[Unit]
Description=A lightweight DHCP and caching DNS server
After=network.target
[Service]
User=dnsmasq
Group=dnsmasq
Type=simple
PIDFile=/run/dnsmasq/dnsmasq.pid
ExecStartPre=/usr/sbin/dnsmasq --test
ExecStart=/usr/sbin/dnsmasq -k -x /run/dnsmasq/dnsmasq.pid
ExecReload=/bin/kill -HUP $MAINPID
RuntimeDirectory=dnsmasq
CapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_NET_ADMIN
AmbientCapabilities=CAP_NET_BIND_SERVICE CAP_NET_ADMIN
PrivateTmp=yes
PrivateDevices=yes
ProtectSystem=full
ProtectHome=yes
NoNewPrivileges=yes
[Install]
WantedBy=multi-user.target
---
Compared to
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=debian/systemd.service;h=40b8d27cba21400d8b56ecc4a85266879988911d;hb=HEAD
I think this is a nice improvement.
The only issue is that the Debian version uses /etc/init.d/dnsmasq and
depends on Debian's resolvconf which other distros won't have, hence
dnsmaq will probably want to keep a special unit for Debian.
Thanks,
~Craig
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss