Hi,

in order to address #592539, I have written a bunch of systemd units
which take care of starting isc-dhcp-server without the init script,
catering for IPv6 setups.

These units activate themselves for IPv4 if dhcpd.conf or dhcpd4.conf
is found, and for IPv6 if dhcp6d.conf is found. Due to shortcomings in
the semantics of a systemd unit, /etc/default/isc-dhcp-server is not
honored any more at all.

These are my first systemd units, so there might be beginner's errors.

They are meant to go in /lib/systemd/system, but were only tested on
my system in /etc/systemd/system.

isc-dhcp-server.target:
[Unit]
Description=ISC DHCP Server (all protocols)
After=network.target

[Install]
WantedBy=multi-user.target


isc-dhcp-server-v4.service:
[Unit]
Description=ISC DHCP Server for IPv4 (dhcpd4.conf)
After=network.target
ConditionPathExists=/etc/dhcp/dhcpd4.conf
PartOf=isc-dhcp-server.target

[Service]
Environment="DHCPD4_CONF=/etc/dhcp/dhcpd4.conf"
ExecStartPre=/usr/sbin/dhcpd -f -t -4 -q $OPTIONS -cf "$DHCPD4_CONF"
ExecStart=/usr/sbin/dhcpd -f -4 -q $OPTIONS -cf "$DHCPD4_CONF"

[Install]
WantedBy=isc-dhcp-server.target


isc-dhcp-server-v4-old.service:
[Unit]
Description=ISC DHCP Server for IPv4 (dhcpd.conf)
After=network.target
ConditionPathExists=/etc/dhcp/dhcpd.conf
PartOf=isc-dhcp-server.target

[Service]
Environment="DHCPD_CONF=/etc/dhcp/dhcpd.conf"
ExecStartPre=/usr/sbin/dhcpd -f -t -4 -q $OPTIONS -cf "$DHCPD_CONF"
ExecStart=/usr/sbin/dhcpd -f -4 -q $OPTIONS -cf "$DHCPD_CONF"

[Install]
WantedBy=isc-dhcp-server.target



isc-dhcp-server-v6.service:
[Unit]
Description=ISC DHCP Server for IPv6
After=network.target
ConditionPathExists=/etc/dhcp/dhcpd6.conf
PartOf=isc-dhcp-server.target

[Service]
Environment="DHCPD6_CONF=/etc/dhcp/dhcpd6.conf"
ExecStartPre=/usr/sbin/dhcpd -f -t -6 -q $OPTIONS -cf "$DHCPD6_CONF"
ExecStart=/usr/sbin/dhcpd -f -6 -q $OPTIONS -cf "$DHCPD6_CONF"

[Install]
WantedBy=isc-dhcp-server.target



I place those unit files under the ISC license and will relicense
freely if asked to by the package maintainers to ease packaging for
Debian.

Greetings
Marc

Hi Marc, et al.

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 can't speak for the Debian packaging team so maybe Michael Gilbert
can review this and let us know whether this is on track.

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've used the latest Debian sys-v init script from the packaging
repository [3] as my reference for what's sane.

Compared to the originals units:

(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.
(2) In the -v4 service file I've replaced references to dhcpd4.conf
with dhcpd.conf since this provides compatibility across upgrades.
(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.
(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.
(6) You can correspondingly disable the v4 instance by moving
dhcpd.conf out of the way.
(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?
(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.
(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.
(10) Support for changing the PID file location in
/etc/default/isc-dhcp-server now seems a little odd given that we no
longer take the conf file from here so I've dropped it. This could
alternatively be passed in OPTIONSv{4,6} if we were to enable these.

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

This could spoil an otherwise neat approach. Any suggestions welcome...

I'm not intending to wire up the maintainer scripts until we have an
agreed approach so you'll have to hand-pick the unit files from my
repo [2] into {/etc,/lib}/systemd/system for the time being.

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


[1] https://lists.isc.org/pipermail/dhcp-users/2016-May/020093.html
[2] https://github.com/terryburton/isc-dhcp-debian/commit/26d3a94e00853f17141a6f748169dc2a26366b15
[3] http://anonscm.debian.org/cgit/pkg-dhcp/isc-dhcp.git/tree/debian/isc-dhcp-server.init.d


Thanks.

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

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

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

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.

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.

Yes, that way the original idea.

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

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

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

/me doesn't care.

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

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

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

Greetings
Marc

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

On 20 May 2016 at 02:03, Terry Burton <tez@terryburton.co.uk> wrote:
<...snip...>

So it does not appear that using a target unit to aggregate a group of
service files into a single unit of service management is actually
aligned to the systemd developers' intentions. Rather target unit are
more focussed on machine states and boot processes akin to changing
runlevel in sys-v. Shame... The upshot is that patches to
/usr/sbin/service (in the sysvinit-utils package) to give the same
treatment to .target files as for .service files when overriding an
LSB script are unlikely to be accepted which scuppers the original
approach by Marc.

So please consider for inclusion this simplified approach [1] (also attached).

* We have distinct service files for V4 and V6 instances,
isc-dhcp-server.service and isc-dhcp-server-v6.service.
* They are both enabled and started by default...
* ... however they have a precondition on the relevant dhcpd{,6}.conf
file existing.
* They support INTERFACESv4 and INTERFACESv6 specified in
/etc/default/isc-dhcp-server.
* As with sys-v, we provide a deprecation warning if INTERFACES is
specified, but it is accepted for now.
* They support the OPTIONS parameter in /etc/default/isc-dhcp-server
(note that support for this is currently lacking in the sys-v script.)
* The DHCPDv{4,6}_PID options are not relevant to systemd and so are ignored.
* The DHCPDv{4,6}_CONF options are removed because ConditionPathExists
requires that these locations be hard-coded. If the user requires
these to be different then they can instead override the .service file
(overlay in /etc/systemd/system, etc.) as is more usual with systemd.

I hope this is acceptable.


[1] https://github.com/terryburton/isc-dhcp-debian/commit/f2e4a1cd3c13ee2e77ee855267b24e30a597b562.diff


All the best,

Terry

<...snip...>

Marc: Apologies. My mailer spammed your reply so I didn't read this
before posting my most recent update.

Mine (up to date Jessie) simply didn't attempt to start the
subcomponents but nevertheless set the target's state to running.

I'm on the same page here.
<...snip...>

Hmm... Thanks for the info. Perhaps removing the defaults file is
ultimately the way to go.

Before then there would seem to be a missing piece at the packaging
infrastructure level to make Debian user's upgrade experience more
pleasant under such circumstances. It's also not clear that exposing
sysadmins directly to unit files is necessarily a positive step.
(Filed under bigger issues!)

.service overrides LSB cleanly whereas .target does not. .target seems
to be a powerful mechanism for controlling groups of service units
under a single unit of control but it's not clear (to me) that that is
precisely the intention of the systemd folks... I'm see if I can raise
consensus about this. If it is intended that target to works in this
way then it is clear that /usr/sbin/service should be patched to allow
.target to override LSB.

For the time being my V2 patches (in some ways inferior to your V1
base) attempt to provide a path of least resistance to being included
in the isc-dhcp-server packaging.

I don't have the time (and patience) or standing within the Debian
community to work through all of the broader issues involved to make
your original approach work seamlessly but will have a little poke
where I can. /me ducks

<...snip...>

Okay, I've now seen this [1] which blesses target units as a mechanism
for multiple service unit control, and the related open issue
regarding propagation of reload actions from targets to services [2]
(which doesn't affect isc-dhcp-server).

So to make target units a first order citizen would require changes to
at init-system-helpers scripts [3] and systemd
(/lib/lsb/init-functions.d/40-systemd) [4].


[1] https://lists.freedesktop.org/archives/systemd-devel/2015-July/033628.html
[2] https://github.com/systemd/systemd/issues/710
[3] https://sources.debian.net/src/init-system-helpers/1.34/script/
[4] https://sources.debian.net/src/systemd/230-1/debian/extra/init-functions.d/40-systemd/

Control: block 792894 by 826011 826012

Note that the "blocks" tags I've added are soft since we always have
the less-preferable but simpler approach [3] vs this more thorough
approach [4].


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826011
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826012
[3] https://github.com/terryburton/isc-dhcp-debian/tree/systemd-simple
[4] https://github.com/terryburton/isc-dhcp-debian/tree/systemd

np

Do yours do that correctly now?

If we're on the same page, it doesn't hurt to also support the -v4
files. But: You do the work, you decide.

As a final goal, I am afraid yes.

The drop-in mechanism (/etc/systemd/system/foo.d/somefile.conf as
addition to the contents of foo.service) does work rather nicely. It's
just something entirely different, and if we want to continue
supporting sysv init scripts and the systemd unit we need to have both
:-(

So that would be a non-issue if the LSB scripts get renamed to match
the systemd unit names. LSB init scripts do no-op themselves if called
directly and they detect systemd, so one could have a wrapper script
identically named to the target.

Agreed.

Acceptable. I am aware that my unit files are somewhat radical in
their change (ditching the init scripts entirely), they were never
meant to be included in the package verbatim at this time.

If you tell me explicitly what you want me to do, I can see what I can
do.

Greetings
Marc

I really like your way to approach things. Appreciated.

Greetings
Marc

After a wheezy->jessie->stretch upgrade, isc-dhcp-server is reported
as failing in systemctl, but the daemon is running.  I suspect this
could have been prevented with a proper systemd service file for
isc-dhcp-server, although that is mostly just a gut feeling.
Last activity on this bug was in June 2016.  Seems like plenty of time
to get a service file into the package.

What are current plans on this bug?  I guess it is too late for Stretch?

As represented by the buginfo, this is considered blocked by #826011
and #826012.  Help there would get this moving faster.

Best wishes,
Mike

Hello,

As mentioned in [0], isc-dhcp-server has failed state in Stretch (via
systemd). /etc/init.d/isc-dhcp-server seems to be "buggy" on IPv6 part.

With this settings in /etc/default/isc-dhcp-server :
--
INTERFACES="MY_INTERFACE_NAME"
INTERFACESv4="MY_INTERFACE_NAME"
--

isc-dhcp-server service can be manage with systemd.

Hi,

I wonder why these two bugs are considered blockers for this one? From
the 3 scenarios below

  * DHCPv4 only
  * DHCPv6 only
  * DHCPv4 and DHCPv6

only the last one would need to have both started, so only this _might_
have a use for compound target units. But even if they are not
available, one can still enable/start each service separately via its
own service file. This means that 826011 and 826012 are, at most, nice
to have, but in no way are they blocking systemd service files for
isc-dhcp-server, right?

In addition, the current init script based mechanism for running both is
also buggy: When one service got killed, its PID file is still around,
which results in the init script refusing to start ANY of them unless
that PID file is removed.

So, please, replace the current init script with proper, independent
systemd service files for both dhcpdv4 and dhcpdv6 for bullseye. A
compound target unit can still be added later.

Bye...

    Dirk

From
_might_
nice
is
around,

Ping - any update on this? It would be good to get this sorted as
mentioned above. isc-dhcp is one of the few popular packages left
without native units.

It would seem that this is becoming increasingly urgent. With systemd
256, I noticed this in the logs:

systemd-sysv-generator[154521]: SysV service
'/etc/init.d/isc-dhcp-server' lacks a native systemd unit file. ~
Automatically generating a unit file for compatibility. Please update
package to include a native systemd unit file, in order to make it safe,
robust and future-proof. ! This compatibility logic is deprecated,
expect removal soon. !

Given that ISC announced the end of maintenance for ISC DHCP as of the
end of 2022, maybe it's time I considered finally migrating to Kea.

Another small update from the systemd v257-rc1 release notes published
today:

     * Support for System V service scripts is deprecated and will be
       removed in v258. Please make sure to update your software
       *now* to include a native systemd unit file instead of a legacy
       System V script to retain compatibility with future systemd releases.

Dear submitter,

as the package isc-dhcp has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see https://bugs.debian.org/1143544

The version of this package that was in Debian prior to this removal
can still be found using https://snapshot.debian.org/.

Please note that the changes have been done on the master archive and
will not propagate to any mirrors until the next dinstall run at the
earliest.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Thorsten Alteholz (the ftpmaster behind the curtain)