STEP 1: INSTALL THE AGENT
An Ubuntu server will tell you all of the packages that must be installed and will give you the option to continue. If you choose to continue, Ubuntu will install all of the packages then warn you that it could not start the puppet agent
which means you need to edit the file the message refers to. So, sudo nano /etc/default/puppet, change
and save the file. Once saved, sudo service puppet start.
STEP 2: AUTHENTICATE THE CLIENT
Puppet uses certificates for authentication, so the master is basically a CA who signs certificates from the clients. Unless you tell the client otherwise, it’ll assume that the puppetmaster’s name is puppet, so you either have to handle that with DNS or by editing the client’s puppet.conf. I took the first route, which seemed easier to me.
On the client, we tell it to send it’s certificate to be signed by the puppetmaster by telling it to test:
Once that’s done, we have the puppetmaster approve the client’s certificate:
After the client certificate is signed, it’s no longer in the server’s pending list.
At this stage, the client is essentially configured. Within the next 30 minutes, it will contact the puppet master to see if any new or changed catalog items exist for it–if they do, the client will make the changes. If you’re impatient like me, you can force the client to check in by forcing another test:
Keep in mind that it’s possible that some of the client’s catalog cannot be completed while your user is logged in, depending on what the changes are. For instance, if the catalog for that client changes your user’s UID or GID, you’ll receive an error until your user is no longer logged in.
To be sure that your client is checking in on it’s own, just take a look at it’ssyslog:
Next time, we’ll take a look at the files that make up a “catalog”.