On Tue, May 31, 2016 at 02:53:34PM +0100, Terry Burton wrote:
> 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.
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 | 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
