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

Stig Sandbeck Mathisen ssm at debian.org
Mon Aug 5 22:54:59 UTC 2013


Russ Allbery <rra at debian.org> writes:

> Maybe do both of those things?
>
> It really seems odd to me to make assumptions about the DNS space of
> the local network, even if we ship it disabled by default.

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.

As you noted: Changing the server= hostname in puppet.conf will most
likely introduce prompts on upgrades in many places. I'd want to avoid
that, since it does not scale well.

A few more points to think about:

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

* 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?

* 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.

-- 
Stig Sandbeck Mathisen



More information about the Pkg-puppet-devel mailing list