[Pkg-puppet-devel] Bug#854487: Bug#854487: Bug#854487: Bug#854487: Binary-only package puppet was silently converted into a package shipping and running a service

[Apollon Oikonomopoulos]

On 15:07 Wed 08 Feb     , Apollon Oikonomopoulos wrote:
> On 19:10 Tue 07 Feb     , Russ Allbery wrote:
> > Alexander Kurtz <alexander at kurtz.be> writes:
> > 
> > > However, now somebody decided, that it's a good idea to drop the
> > > puppet-agent package and move the service file back to the puppet
> > > package [1]. This is bad, very, very bad. Here's why:

(In defense of moving things back to puppet from puppet-agent, apart 
 from #826730 and #827867, it was also breaking the upgrade path for 
 people from jessie, since puppet-agent would not be installed 
 automatically for those who had puppet installed.)

> > 
> > I don't think this is the problem.  I think the problem is that the
> > service is enabled by default.
> > 
> > There's no harm in having everything in one package provided that the
> > service defaults to *disabled*, not enabled.  My recollection is that this
> > is even what the puppet-agent package did, although maybe I'm
> > misremembering.
> 
> Sort of, actually in 3.x the service was enabled, but the agent was 
> disabled in postinst using puppet agent --disable. Nowadays I think it 
> makes more sense to simply not enable the service by default.
> 
> > But it looks like the default installation logic may have
> > been lost with the merge into a single puppet package.
> 
> For the record, this is exactly what happened.

Digging a bit further into the issue, the `puppet agent --disable' logic 
is still there, but it does not currently work for the following 
reasons:

 - In an attempt to be as safe as possible, we create the lock file 
   manually (i.e. not via `puppet agent --disable') in *preinst*, with a 
   hardcoded path to the lockfile 
   (/var/lib/puppet/state/agent_disabled.lock). However:

 - puppet agent's default vardir was changed during the migration to 4.x 
   from /var/lib/puppet to /var/cache/puppet and the agent lockfile path 
   was not updated. Even if it was updated, it still depends on the 
   actual values of vardir and/or agent_disabled_lockfile present in the 
   [main] and [agent] sections of /etc/puppet/puppet.conf.

Now, I fixed that by a) adjusting the path in preinst, b) adding an 
explicit `puppet agent --disable' call in postinst before the debhelper 
stanzas, which will always do the right thing no matter what the config 
value for agent_disabled_lockfile is. I also updated the DEP-8 tests to 
actually check that the lock *puppet agent knows about* is present on 
installation. This should give the same behavior as puppet 3.7.

> 
> > 
> > For systemd, I think the fix may be as easy as using --no-enable in a
> > dh_systemd_enable override.  I'm not sure how this used to be done for
> > dh_installinit.

For dh_installinit things are unfortunately not that straightforward.  
The only way I can see for this to work, is to call dh_installinit 
--no-scripts to prevent dh_ii from modifying the maintainer scripts and 
then manually add most of the boilerplate code without that single 
`update-rc.d puppet defaults' call. I find this ugly enough to not 
prefer it over the `puppet agent --disable' approach.