[Pkg-puppet-devel] Starting puppet agent by default

[Russ Allbery]

Stig Sandbeck Mathisen <ssm at debian.org> writes:

> Even when "disabled" with "puppet agent --disable", the puppet agent
> will create an SSL key, a certificate request, upload this to the
> configured (or default) puppet master, and retrieve the ca cert and the
> signed agent certificate.

> I've now pushed a few commits in the packaging repo where "puppet agent
> --disable" has been run. I changed it in the "puppet" package, which
> holds the "puppet agent" init script, systemd unit, and not much else.

> With what I pushed to the packaging repo now, it says:
>   
>   root at puppet-agent # puppet agent --test   
>   Notice: Skipping run of Puppet configuration client; administratively disabled (Reason: 'Disabled by default on new installations');
>   Use 'puppet agent --enable' to re-enable.

> …after signing the cert on the master. It's one step in a direction I
> hope is the right one.

Yeah, that definitely makes me a lot more comfortable.  It feels like that
stops short of doing any actual harm.

> A few more points to think about:

> * The puppet agent process may around until enabled, and possibly being
>   restarted by systemd a few times.

Can we disable the Puppet agent by creating the lock file in preinst
rather than using the official command-line method?  (We have code at
Stanford that manipulates the lock files directly because we do things
like include administrative comments in them.)

> * Running "puppet agent" may work when "puppet-common" is installed, and
>   then not work when installing "puppet" until someone runs "puppet
>   agent --enable".  Should the "--disable" be in "puppet-common", even
>   if this does not enable the puppet agent service?

Yes, I think so.

> * The set of puppet packages probably need renaming. The current set of
>   packages reflects how puppet looked at 0.25, and puppet has changed a
>   bit since that.

Agreed.  Maybe puppet-common => puppet-client and puppet => puppet-service?
(puppet-service isn't a great name, but I can't think of a better one
off-hand.)

-- 
Russ Allbery (rra at debian.org)               <http://www.eyrie.org/~eagle/>