[pkg-dhcp-devel] Bug#792894: systemd unit files for isc-dhcp-server

[Marc Haber]

On Fri, May 20, 2016 at 02:03:08AM +0100, Terry Burton wrote:
> As you know from discussions on the dhcp-users mailing list I've been
> threatening to do some systemd packaging work for ISC DHCP so I'm
> taking your contributions as a starting point.

I'm glad to hear that. Thanks for taking a look.

> I've taken a look at your unit files and taken the liberty to create
> some new ones based on them that I've added to my repo here [2].

I will give those a try, maybe even already over the weekend.

> (1) I've added "Wants" to isc-dhcp-server.target which ensures that
> subordinate services are started. Therefore you only need "enable" the
> .target file to ensure that the v4 and v6 daemons are started assuming
> they are configured.

What did my Unit files do instead? I think I didn't need to manually
enable them on my systems.

> (2) In the -v4 service file I've replaced references to dhcpd4.conf
> with dhcpd.conf since this provides compatibility across upgrades.

I am not exactly sure what I actually filed in the bug, but locally I
do have a Unit for dhcpd4.conf, one for dhcpd.conf and one for
dhcp6.conf, preserving backwards compatibility while not given people
the impression that IPv4 is still the default.

Since a few years, IPv4 is officially deprecated in the RFCs and IPv6
the default. Having a postfixless config file for v4 and a "special"
file for v6 is the wrong way, things should be the other way round in
2016. Be advised that I'm being political here, the IPv6 rollout needs
to be supported.

I can live with this change though if it saves me from maintaining
local packages. It makes me kind of sad though.

> (3) I've added an EnvironmentFile option that reads the user provided
> settings from /etc/default/isc-dhcp-server. I think only INTERFACES,
> INTERFACESv4, INTERFACESv6 and possibly OPTIONS remain relevant for
> reasons given in (8) and (9) below.

systemd Upstream is, however, pondering to remove EnvironmentFile
support since it was always wrong to have this in the first place. I
got silenced on systemd-devel for having an opinioon and losing my
temper over this issue.

> (4) You use ConditionPathExists=/etc/dhcp/{dhcpd.conf,dhcpd6.conf} to
> determine whether to start the units. I like this approach and have
> kept it as it provides nice semantics in (5) and (6) below for whether
> to start the v4 and v6 subcomponent services.
> (5) Since a dhcpd6.conf file isn't currently installed by the package
> (and probably shouldn't be, at least not yet) there is no attempt to
> start a IPv6 instance - following the principle of least surprise. You
> can simply add a dhcpd6.conf file and restart isc-dhcp-server.target
> to enable the v6 instance.

Yes, that way the original idea.

> (6) You can correspondingly disable the v4 instance by moving
> dhcpd.conf out of the way.

(6a) it used to be possible to simply move dhcpd.conf to dhcpd4.conf
to clearly distinguish v4 and v6.

> (7) I note that this is a different condition for deciding whether or
> not to start the daemon than the sys-v script which us whether or not
> INTERFACESv{4,6} is defined in /etc/default/isc-dhcp-server. Such a
> condition can't be done cleanly in systemd, i.e. you cannot have an
> enabled service (or component of a compound target) that simply
> decides not to start based on an arbitrary test). Perhaps the sys-v
> init script can be aligned to the dhcpd{,6}.conf exists approach?

I didn't look at the sys-v script because that was the mess I wanted
to get rid of.

> (8) Since you can't expand environment variables in the
> ConditionPathExists and therefore refer directly to the config files
> you may as well also hardcode the the values for DHCPDv{4,6}_CONF in
> the ExecStart/ExecStartPre lines, i.e. don't read these from
> /etc/default/isc-dhcp-server.

Yes, that was one of the reasons why I ditched the defaults file
entirely. Upstream wants people to edit unit files.

> (9) I've dropped support for extracting OPTIONS (and OPTIONSv4,
> OPTIONSv6)  from /etc/default/isc-dhcp-server since it isn't honoured
> by the most recent sysv-init script [3]. If this is accidental then
> its trivial to add this back into both systemd and sys-v.

/me doesn't care.

> A general problem that I've noticed which might cause us to modify the
> isc-dhcp-server.target approach is that the following commands will
> not have the expected effect:
> 
> service isc-dhcp-server {start,stop,restart}
> systemctl {start,stop,restart} isc-dhcp-server
> 
> (1) It doesn't appear as though you can invoke .target unit files
> using /usr/sbin/service. This'll drive some purists nuts!

I think this is something on systemd upstream's agenda to make people
migrate to the new, vendor lock-in interface asap.

> (2) Additionally, these commands as-is will actually invoke LSB
> compatibility and trigger the sys-v init script rather than the native
> isc-dhcp-server.target unit file.

Ouch. I consider this a bug in Debian's systemd packaging.

> (3) The packaging would need to do something ensure that the
> isc-dhcp-server init script (via LSB) and isc-dhcp-server.target unit
> are not both started at boot.

If this is a common issue for packages shipping both a sysv init
script and systemd units, it's up to systemd in Debian to fix this IMO.

> Would you mind taking a look to make sure these work for you, caveats
> aside, and let me have any feedback.

Will do, and I hope that I don't forget giving feedback after I did
this.

Greetings
Marc

P.S.: The address I use to file bug reports,
mh+debian-bugs at zugschlus.de, works. No need to google for other
addresses of mine.

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany    |  lose things."    Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421