On 27 May 2016 at 14:12, Marc Haber <mh+debian-b...@zugschlus.de> 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
