Regenerate puppet resource types in a foreman setup

Support
1

Problem:
Unable to generate puppet resource types

All puppet agents of a certain environment have started to show this issue: [MODULES-5802] - Jira

To spare you from reading through the whole thing, there were two remedies suggested:
First, restart the server. This I tried, without effect.

Second, the thing that apparently worked for everybody is to regenerate the resource types:

This is looking a lot like environment bleed.

Something worth trying (and has worked for another user) is using puppet generate to generate pcore types, you can read more here . If you’re using r10k, you’ll run into a problem of course. The current recommendations for that scenario are here.

The problem is, when I try to run puppet generate types --environment development Puppet seems to look in the wrong folder for the environments:
Could not find a directory environment named 'development' anywhere in the path: /opt/puppetlabs/server/data/puppetserver/.puppetlabs/etc/code/environments

This is despite the fact that the environment path is given as an absolute in puppet.conf:
environmentpath = //etc/puppetlabs/code/environments

In fact, changing that folder doesn’t affect anything. It’s as if that file isn’t even read.

Being very inexperienced with foreman, having “inherited” the setup from my predecessor, I wonder if this is due to puppet being managed by foreman, and how I would go about regenerating these types in a puppet installation managed by foreman.

Expected outcome:

It would be nice if my development environment worked again…

Foreman and Proxy versions:
foreman: 1.17.4
proxy: No idea where to look that up…

2

Hi,

on your puppetserver, could you pleas run the following commands and post the output, just to make sure puppet actually uses the correct configuration:

puppet config print environmentpath
puppet config print confdir
puppet config print codedir

Also, maybe try puppet config print all | grep '/opt/puppetlabs/server/data/puppetserver/.puppetlabs/etc/code/environments' to try to figure out where that odd path comes from.

Sidenode, but that’s probably not relevant here: You can look up your proxy versions on the About page of the Foreman UI (under Administer).

3

Thanks, yes, there seem to be quite a few odd things here…
environmentpath: /home/ubuntu/.puppetlabs/etc/code/environments
confdir: /home/ubuntu/.puppetlabs/etc/puppet
codedir: /home/ubuntu/.puppetlabs/etc/code

Apparently, /home/ubuntu/puppetlabs has the entire folder structure duplicated, but there are no files in there. The folders aren’t links, either. So that explains why I got the impression that changing the config file didn’t do anything. It does in fact not do anything.
What is completely unclear is how anything works at all? I mean, the webhooks fire, the code is checked out, nodes can be added, and the other environment isn’t having any problems at all, so obviously I must be completely misunderstanding the nature of this setup…

As for config print all, if I grep the entire path I get nothing back, but if I grep for /home/ubuntu/.puppetlabs it looks like I get pretty much every single folder configuration. Where on earth is puppet even taking that config from? There is only one puppet.conf on the entire machine, and that’s in the place where apparently nobody’s looking…

4

Paths are different for root and a normal user.

5

Akh, dammit, I executed as puppet user but forgot -H!
In that case, things look like this:
environmentpath: /opt/puppetlabs/server/data/puppetserver/.puppetlabs/etc/code/environments
confdir: /opt/puppetlabs/server/data/puppetserver/.puppetlabs/etc/puppet
codedir: /opt/puppetlabs/server/data/puppetserver/.puppetlabs/etc/code

Which only makes things more confusing. /opt/puppetlabs/server/data/puppetserver/.puppetlabs/etc exists, but it is empty. Not even subfolders…

6

What ekohl wrote is completely right. Running puppet commands from a non priviledged account can lead to really strange behaviour.
I assume you were running thos commands as the user ubuntu (or some user that has $HOME set to /home/ubuntu). Try rerunning those via sudo or directly from a root shell.