Bug#792894: systemd unit files for isc-dhcp-server

[Marc Haber]

On Wed, Jun 01, 2016 at 01:19:50PM +0100, Terry Burton wrote:
> On 31 May 2016 at 16:08, Terry Burton  wrote:
> > 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].
> 
> Issues with patches raised: [1], [2].

I really like your way to approach things. Appreciated.

Greetings
Marc

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

Bug#792894: systemd unit files for isc-dhcp-server

[Marc Haber]

On Tue, May 31, 2016 at 02:53:34PM +0100, Terry Burton wrote:
> On 27 May 2016 at 14:12, Marc Haber  wrote:
> > On Fri, May 20, 2016 at 02:03:08AM +0100, Terry Burton wrote:
> <...snip...>
> 
> Marc: Apologies. My mailer spammed your reply so I didn't read this
> before posting my most recent update.

np

> >> (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.
> 
> Mine (up to date Jessie) simply didn't attempt to start the
> subcomponents but nevertheless set the target's state to running.

Do yours do that correctly now?

> >> (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.
> 
> I'm on the same page here.

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

> >> (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.
> <...snip...>
> >> (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.
> 
> Hmm... Thanks for the info. Perhaps removing the defaults file is
> ultimately the way to go.

As a final goal, I am afraid yes.

> 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!)

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
:-(

> > 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.
> 
> .service overrides LSB cleanly whereas .target does not.

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.

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

Agreed.

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

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.

> 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

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

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | 

Bug#792894: systemd unit files for isc-dhcp-server

[Terry Burton]

Control: block 792894 by 826011 826012

On 31 May 2016 at 16:08, Terry Burton  wrote:
> 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].

Issues with patches raised: [1], [2].

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

Bug#792894: systemd unit files for isc-dhcp-server

[Terry Burton]

On 31 May 2016 at 14:53, Terry Burton  wrote:
> On 27 May 2016 at 14:12, Marc Haber  wrote:
>> On Fri, May 20, 2016 at 02:03:08AM +0100, Terry Burton wrote:
<...snip...>
>>> 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.
>
> .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.

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/

Bug#792894: systemd unit files for isc-dhcp-server

[Terry Burton]

On 27 May 2016 at 14:12, Marc Haber  wrote:
> On Fri, May 20, 2016 at 02:03:08AM +0100, Terry Burton wrote:
<...snip...>

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

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

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

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

I'm on the same page here.

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

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!)

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

.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

Bug#792894: [PATCH] Re: Bug#792894: systemd unit files for isc-dhcp-server

[Terry Burton]

On 20 May 2016 at 02:03, Terry Burton  wrote:
<...snip...>
> 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...

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
diff --git a/debian/control b/debian/control
index f873489..9beb3ef 100644
--- a/debian/control
+++ b/debian/control
@@ -10,6 +10,7 @@ Build-Depends:
  dpkg-dev (>= 1.13.2),
  debhelper (>= 9.20151220),
  dh-autoreconf,
+ dh-systemd (>= 1.5),
  groff,
  pkg-config,
  po-debconf,
diff --git a/debian/isc-dhcp-server.isc-dhcp-server-v6.service 
b/debian/isc-dhcp-server.isc-dhcp-server-v6.service
new file mode 100644
index 000..bb4e35c
--- /dev/null
+++ b/debian/isc-dhcp-server.isc-dhcp-server-v6.service
@@ -0,0 +1,10 @@
+[Unit]
+Description=ISC DHCP Server for IPv6 (dhcpd6.conf)
+After=network.target
+ConditionPathExists=/etc/dhcp/dhcpd6.conf
+
+[Service]
+EnvironmentFile=-/etc/default/isc-dhcp-server
+ExecStartPre=/usr/bin/touch /var/lib/dhcp/dhcpd6.leases
+ExecStartPre=/usr/sbin/dhcpd -f -t -6 -q $OPTIONS -cf /etc/dhcp/dhcpd6.conf
+ExecStart=/usr/sbin/dhcpd -f -6 -q $OPTIONS -cf /etc/dhcp/dhcpd6.conf 
$INTERFACESv6
diff --git a/debian/isc-dhcp-server.service b/debian/isc-dhcp-server.service
new file mode 100644
index 000..072e6c9
--- /dev/null
+++ b/debian/isc-dhcp-server.service
@@ -0,0 +1,11 @@
+[Unit]
+Description=ISC DHCP Server for IPv4 (dhcpd.conf)
+After=network.target
+ConditionPathExists=/etc/dhcp/dhcpd.conf
+
+[Service]
+EnvironmentFile=-/etc/default/isc-dhcp-server
+ExecStartPre=/bin/sh -c '[ -n "$INTERFACES" -a -z "$INTERFACESv4"] && echo 
"DHCPv4 interfaces are no longer set by the INTERFACES variable in 
/etc/default/isc-dhcp-server.  Please use INTERFACESv4 instead. Migrating 
automatically for now, but this will go away in the future." >&2 || true'
+ExecStartPre=/usr/bin/touch /var/lib/dhcp/dhcpd.leases
+ExecStartPre=/usr/sbin/dhcpd -f -t -4 -q $OPTIONS -cf /etc/dhcp/dhcpd.conf
+ExecStart=/usr/sbin/dhcpd -f -4 -q $OPTIONS -cf /etc/dhcp/dhcpd.conf 
$INTERFACESv4 $INTERFACES
diff --git a/debian/rules b/debian/rules
index b8358fc..627d98b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -37,7 +37,7 @@ CONFFLAGS+=--enable-use-sockets
 endif
 
 %:
-   dh $@ --parallel --with autoreconf
+   dh $@ --parallel --with autoreconf,systemd
 
 override_dh_auto_configure:
 
@@ -83,6 +83,7 @@ override_dh_install:
 override_dh_installinit:
dh_installinit -Nisc-dhcp-server
dh_installinit -pisc-dhcp-server --error-handler=true
+   dh_installinit -pisc-dhcp-server --error-handler=true 

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 

Bug#792894: systemd unit files for isc-dhcp-server

[Terry Burton]

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.