[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