[Pkg-puppet-devel] Bug#718776: Bug#718776: puppet: setting /etc/default/puppet START=no is ignored with systemd

Helmut Grohne helmut at subdivi.de
Mon Aug 5 11:06:30 UTC 2013


I will fullquote your response, because you indicated, that it was meant
for public consumption.

On Mon, Aug 05, 2013 at 12:45:16PM +0200, Stig Sandbeck Mathisen wrote:
> Helmut Grohne <helmut at subdivi.de> writes:
> 
> > After installing puppet, it is not started by sysvinit, but it is
> > started by systemd. This behaviour is inconsistent. Puppet should either
> > be autostarted on all init systems or on no init systems.
> 
> I changed the default to "yes", to make sure the service is a bit more
> concistent between init systems.

This makes very much sense. Users who don't want the service running,
should simply install puppet-common instead.

> > Ideally puppet-agent should detect whether it is configured and exit
> > successfully if no suitable configuration is found. That would
> > entirely remove the need for a START=no shell configuration.
> 
> Puppet agent does that. If it does not have a signed certificate from
> the master, it will stop.

This does not match my experience. I had a puppet agent process started
by systemd, that kept running. It had no suitable master configured.

The system log indicates:
Aug 05 12:09:49 $HOSTNAME puppet-agent[26307]: Creating a new SSL key for $FQDN
Aug 05 12:10:01 $HOSTNAME puppet-agent[26307]: Could not request certificate: getaddrinfo: Name or service not known

The intended behaviour matches my expectation.

> > On a personal note, it would be nice to have a package that provides
> > puppet as a tool (especially puppet apply) without puppet agent
> > service. I guess this is not gonna happen, but I found it worth
> > mentioning.
> 
> That is provided by the "puppet-common" package.

Thanks for enlightening me on this aspect! The naming of the package is
not intuitive, since -common is usually used for internal components of
a package group. I don't think the cost of renaming outweighs the
potential benefits. Maybe the relation to the puppet-common package
could be explained in the long description of the puppet binary package?
I suggest appending a sentence along the lines "All of the actual puppet
software is contained in the puppet-common package" to the first
paragraph.

> (The puppet packages were split after how a very old version of puppet
> worked. If puppet was packaged today, most things would be in the
> "puppet" package.)
> 
> -- 
> Stig Sandbeck Mathisen <ssm at debian.org>

Helmut



More information about the Pkg-puppet-devel mailing list