Missing config in puppet.conf for a new installed CentOS 7/8 host

Support
,
1

Problem:
Last week I upgraded our Foreman/Katello from 2.0.1/3.15.x to 2.3.3/3.18.1

With version 2.0.1/3.15 the puppet.conf file was created this way:
[host ~]# cat /etc/puppetlabs/puppet/puppet.conf

[main]
vardir = /opt/puppetlabs/puppet/cache
logdir = /var/log/puppetlabs/puppet
rundir = /var/run/puppetlabs
ssldir = /etc/puppetlabs/puppet/ssl

[agent]
pluginsync = true
report = true
ca_server =
certname =
environment = production
server =

Now, on a new installed CentOS 8 host, with Foreman 2.3.3/ Katello 3.18 it is created without the directories configured in the main-block. It is by default empty.

When the puppet service is started, it complains with: ā€œCouldnā€™t fetch certificate from CA serverā€

After I manually configure the directories in the main-block as it was in 2.0.1/3.15 the puppet service starts well as expected and I was able to sign the certificate for that host via the Foreman interface Infrastructure -> Smart Proxies -> Name -> Puppet CA -> Certificates.

In the puppet.conf snippet template (erb) I also see that the configuration of the correct directories for puppet in CentOS 7/8 are missing that should be used for the correct creation of the puppet.conf file.

Expected outcome:
Same result as it was in version 2.0.1/3.15
See also community-templates/puppet.conf.erb at 2.0-stable Ā· theforeman/community-templates Ā· GitHub, nore specific:

if aio_enabled && aio_available
var_dir = ā€˜/opt/puppetlabs/puppet/cacheā€™
log_dir = ā€˜/var/log/puppetlabs/puppetā€™
run_dir = ā€˜/var/run/puppetlabsā€™
ssl_dir = ā€˜/etc/puppetlabs/puppet/sslā€™

Foreman and Proxy versions:
Foreman 2.3.3
Katello 3.18.1
Foreman and Proxy plugin versions:

Distribution and version:
CentOS 7/8
Other relevant data:

2

Anyone else see this?

3

Hi,

After further investigating this I could see that those dir-config are not necessary.

The only remaining problem I have is that when the host (running centos 8) is rebooted, the puppet-service ends in a failure:

[root@myhost ~]# systemctl status puppet
ā— puppet.service - Puppet agent
Loaded: loaded (/usr/lib/systemd/system/puppet.service; enabled; vendor preset: disabled)
Active: active (running) since Tue 2021-03-16 08:40:02 UTC; 19s ago
Main PID: 1384 (puppet)
Tasks: 2 (limit: 406431)
Memory: 98.1M
CGroup: /system.slice/puppet.service
ā””ā”€1384 /opt/puppetlabs/puppet/bin/ruby /opt/puppetlabs/puppet/bin/puppet agent --no-daemonize

Mar 16 08:40:04 myhost puppet-agent[1793]: (/File[/opt/puppetlabs/puppet/cache/lib]) Failed to generat>
Mar 16 08:40:04 myhost puppet-agent[1793]: Connection to https://foreman-server:8140/puppet/v>
Mar 16 08:40:04 myhost puppet-agent[1793]: Wrapped exception:
Mar 16 08:40:04 myhost puppet-agent[1793]: Failed to open TCP connection to foreman-server:81>
Mar 16 08:40:04 myhost puppet-agent[1793]: (/File[/opt/puppetlabs/puppet/cache/lib]) Could not evaluat>
Mar 16 08:40:12 myhost puppet-agent[1793]: Connection to https://foreman-server:8140/puppet/v>
Mar 16 08:40:12 myhost puppet-agent[1793]: Wrapped exception:
Mar 16 08:40:12 myhost puppet-agent[1793]: Failed to open TCP connection to foreman-server:81>
Mar 16 08:40:12 myhost puppet-agent[1793]: Could not retrieve catalog from remote server: No more rout>
Mar 16 08:40:12 myhost puppet-agent[1793]: Applied catalog in 0.03 seconds

I need to restart the service in order to fix it.
So this is still something I need to find out why it happens.

4

OK, found the reason.
In /usr/lib/systemd/system/puppet.service I changed:

original:

After=basic.target network.target

to:

After=basic.target network-online.target

With this change the puppet service starts perfect after each reboot of the host.

1 Like