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