Explicit empty foreman::user_groups parameter does not prevent 'puppet' group addition

[pkranenburg]

In a previous version I could explicitly set parameter '::foreman::user_groups' to the empty array, thus preventing the automatic addition of a 'puppet' group entry. This is no longer the case after a logic change in foreman::config.

However, this logic change seems to add a 'puppet' group entry even if the host (where I wish to install foreman) is only a puppet client (it happens to be the case that in my environment foreman and puppet compilation masters all run on different hosts). Since puppet client installation do not configure a 'puppet' group, the foreman::config manifest fails when creating the 'foreman' user.

[ekohl]

This was changed in e16eaa3. It now automatically determines it when Puppet client certificates are used. You're right that this can be an issue but I do wonder how you manage permissions then. By default only root can read those files.

It feels like an additional parameter is needed for this.

[pkranenburg]

I guess the point is that the 'puppet' group is unmanaged on a puppet client-only host. Apparently, after manual creation of group 'puppet' the foreman manifest succeeds. Afterwards, the puppet 'ssl' directory has been assigned this 'puppet' group, so foreman runs just fine. I'm not sure when this group change happens.

[ekohl]

Yes, we sort of rely on puppet-foreman_proxy for that:
https://github.com/theforeman/puppet-foreman_proxy/blob/f8708aead65df2334275499229dfce8184cfb136/manifests/config.pp#L119-L139
It's not pretty, but so far we haven't found a better way (we're actively looking into that).

Also, I think Puppet itself does some odd things when the puppet group is present and can change some permissions.

This largely dates back to the Puppet < 4 days when the agent package created the puppet user.