Puppet provisioning script fails to start the Puppet agent on the target host with default settings

Support
1

Problem:

The default Puppet provisioning script seems to always fail on a somewhat bare setup using the instructions at Configuring hosts by using Puppet. This is because the first puppet agent run (foreman/app/views/unattended/provisioning_templates/snippet/puppet_setup.erb at 5.0-stable · theforeman/foreman · GitHub) attempts to do SSL registration with the server, but fails if the server does not reply in time (probably if automatic certificate signing is not enabled).

The docs indicate that the server will not sign the certificate immediately and an administrator should go to the Certificates tab to sign the request, so I think this is expected behavior.

The solution would be adding the --waitforcert=1 parameter that makes the Puppet agent wait until the certificate is signed before exiting - tested with Puppet agent 8.

Additionally, the puppet service does not appear to be started at any point in the script, so system monitoring fails unless the service is started manually. The service is enabled in multiple places - line 110 for RedHat-based systems, line 126 for Debian-based systems (possibly?), and line 184 for SUSE, Debian and Ubuntu. The service would automatically start on next boot, but the documentation does not appear to indicate that a reboot is required.

Expected outcome:

The provisioning script should finish successfully and the puppet agent should be started at the end of the run to allow monitoring / configuring the system.

Foreman and Proxy versions:

Foreman 3.19.1 and Foreman Proxy 3.19.1.

Foreman and Proxy plugin versions:

Distribution and version:

AlmaLinux 9.8, with the latest updates applied.

Other relevant data:

Setting up auto-signing may remove the issue with the setup run failing, but I have not tested it.

Foreman was installed using foreman-install with default settings, on a single server (there is no dedicated proxy server).

The hosts are registered in custom organization and location (both created with default settings, by clicking the “New” button and configuring a name - if it matters, since the default Smart Proxy (the Foreman host) appears in the default organization / location.

2

Just figured out that this can be seen as an issue report. For now I’m trying to figure out whether the behavior is expected.

In the first message I forgot to mention that the script appears to have a “start” command using puppet, but is conditioned on the @host.provision_method being image, at the end of the file. I had noticed it before, but I missed it when writing the message.

<% if @host.provision_method == 'image' -%>
<%= bin_path %>/puppet resource service puppet ensure=running
<% end -%>

There are a few more small issues that might need to be fixed, which are somewhat related:

rpm -q puppet-agent >/dev/null || rpm -Uvh ...

  • installing the RPM key for the repository using rpmkeys --import should likely be done for RedHat-based systems as well (it is currently done only for SUSE), even if the dnf command does not fail in their absence;

  • the puppet agent service enabling could (probably) be simplified by merging the enable (and possibly start) commands at the end of the file into something like:

puppet_unit=puppet
systemctl list-unit-files puppetagent.service >dev/null && puppet_unit=puppetagent
<%= bin_path %>/puppet resource service $puppet_unit enable=true
  • I think this block may be able to be rewritten in a single puppet command, similar to how the ensure=running block below it does not check for these conditions:
<% if os_family == 'Suse' || (os_name == 'Debian' && os_major > 8) || (os_name == 'Ubuntu' && os_major >= 15) -%>
<% if os_family == 'Suse' -%>
<%= bin_path %>/puppet resource service puppet enable=true
<% else -%>
systemctl enable puppet
<% end -%>
<% end -%>

I would be glad to contribute to the project if I can, but in this case I’m afraid I don’t have the background knowledge on why the template was written as it currently is (I assume there are various corner cases that had to be handled independently), and don’t have systems with older OSes where I could reliably test the changes - e.g. what would happen if the modified script ran on Debian <= 8.