nearly all foreman installations I have ever seen have (ab)used the local host’s puppet certificate for the foreman web interface and the communication between foreman and foreman proxy directly from its location in /var/lib/puppet/ssl. A common idiom is placing the foreman user in the puppet group to give it the permissions to read certificate and private key.
This has stopped working with foreman 1.17 since this version seems to drop “excess” group privileges on startup, making it run without the puppet group membership, resulting in a “permission denied” in the connection to the proxies. Changing owner and/or permissions on the directories leading up to the certificate doesn’t help either, those are frequently reset by some mechanism.
What is the canonical way to solve this?
Use a regular let’s encrypt certificate for the web service. Will that also work for the smart proxies?
Use a locally generated and signed certificate from the puppet CA. Will the CA sign a second certificate for the same host name without invalidating the first one?.
Copy the puppet certificate from /var/lib/puppet and setting appropriate permissions on the copy. This is the option I like the least since this is likely to cause fun when the certificate expires.
We still rely on this (mis)use so I’m surprised it broke. All our CI still relies on it and tests it. Can you tell me a bit more about your env? Puppet version, which OS, whether SELinux is enabled.
Could it be you upgraded to Puppet 4 and it’s now stored in /etc/puppetlabs but not all references were updated?
CentOS 7.4, I don’t think SElinux is enabled. I only did the foreman upgrade and did not consciously touch the actual puppet installation. I restored the backup, so I don’t think that I can reliably say which puppet version was in place when the system got broken. After going back to the backup, I have:
and a chown :foreman /var/lib/puppet/ /var/lib/puppet/ssl/ /var/lib/puppet/ssl/certs/ /var/lib/puppet/ssl/certs/myfqdn.example solves the issue at least temporarily (until some process comes along and changes all those back to puppet:puppet).
To wrap this up, I tried the upgrade again a few days later, and the issue magically vanished. This must have been something very strange that has happened during the borked upgrade, I suspect some ruby issue since the ruby upgrade didn’t go quite well in the first instance.
Sorry for the noise.
