The most recent documentation can be retrieved here. It boils down to installing puppet-agent. If this is to be a local, more simplistic install you may wish to disable the Puppet services at this time:
puppet resource service puppet ensure=stopped enable=falsepuppet resource service pxp-agent ensure=stopped enable=falsepuppet resource service mcollective ensure=stopped enable=false
There are many ways to configure Hiera, this way has proved the most flexible and extendable to me. In short, configure Hiera at /etc/puppetlabs/puppet/hiera.yaml for the master configuration, then provide a configuration that allows for node-specific overrides and multiple base cases.
Problem: If you look in the /var/log/puppetlabs/puppetserver/puppetserver.log you will likely see a message resembling java.lang.NumberFormatException: For input string: "". This is usually caused by a disk space issue that's caused it to fail to update the serial file. Digging into the stack trace you can see it's likely having an issue with this file.
Solution: first clear up disk space (the Puppet reports and nodesusually are the culprits) then check the /etc/puppetlabs/puppet/ssl/ca/inventory.txt. In there you're going to grab the hex code of the last certificate issued (the source format will be 0x1234 but you just want to copy 1234). Open the /etc/puppetlabs/puppet/ssl/ca/serial file, insert the hex code into the file, save, and check to make sure its ownership is by the PuppetServer process (usually puppet:puppet). Restart the PuppetServer, and request new certificates.
PuppetServer Logs Not Being Removed
Problem: the log files for puppetserver are not being removed (usually in /var/log/puppetlabs/puppetserver).
Solution: add the following to the root crontab with crontab -e as root to remove logs older than a week:
Problem: when starting PuppetDB it may start momentarily, then in the /var/log/puppetlabs/puppetdb/puppetdb-daemon.log it is killed for out of Java heap space. This usually is freshly after an upgrade and the database is too large for the migrations to happen normally.
Solution: destroying the puppetdb database and recreating it is quite effective. Since the database is dynamically populated anyway this is usually the easiest solution.
root@puppetdbsystem$ puppet resource service puppetdb ensure=stoppedroot@puppetdbsystem$ puppet resource package puppetdb ensure=latestroot@puppetdbsystem$ su - postgrespostgres@puppetdbsystem$ dropdb puppetdb ; createdb puppetdb; exitroot@puppetdbsystem$ puppet resource service puppetdb ensure=running
PuppetDB Not Working
Problem: cannot run Puppet since PuppetServer complains about receiving an error from PuppetDB. This usually includes something like Failed to execute '/pdb/query/v4/nodes/ masternode.company.com/facts and some talk about port 8140 not functioning.
Solution: this error is indicating that there's an issue communicating with PuppetDB from PuppetServer. There are a number of things that can cause this, try the following:
Make sure that the PostgreSQL database is running. During upgrades there may be multiple versions of PostgreSQL installed which will mean you need to force the older versions to stop and restart the service for the newer version.