On 10:01 Wed 08 Feb , Russ Allbery wrote:
> Apollon Oikonomopoulos <apoi...@debian.org> writes:
>
> > Actually, it is much simpler than that: adding an `update-rc.d defaults
> > puppet && update-rc.d disable puppet` before the debhelper stanzas just
> > works and does the right thing.
>
> > Given that in either case (service disabled, or agent locked) manual
> > intervention is required (and desirable), I think it is best to just
> > disable the service. I'll prepare an upload shortly.
>
> I had completely forgotten about the logic to disable it by default. My
> recollection is that this was the result of some discussion about
> disabling the init script and this ended up being better, but I forget the
> history.
I also vaguely recall there was a discussion about this. The changelog
mentions:
* Start puppet agent by default, to reflect systemd configuration
* …but disable puppet agent on initial install
* Add dep8 tests for initially disabled puppet agent
So it seems this was done during the systemd transition (also when the
START= flag was removed from /etc/default/puppet).
>
> I think restoring the disable logic may be all that's required.
Unfortunately the disable logic is hard to get right at this point: the
agent lock location will vary depending on whether the local
administrator has touched /etc/puppet/puppet.conf (which may already be
present on first installation, especially on pre-seeded systems). I
think disabling the service is arguably a better solution and it's
trivial to get right.
Additionally, all the setups I know of use cron for running the puppet
agent, so these admins will want the service disabled anyway (of course
this is argumentum ad populum, but it serves as an indication that this
is not an unreasonable course of action).
>
> Thank you for looking at this!
>
Thanks for the feedback!
Regards,
Apollon
