STEP 1: INSTALL THE AGENT
1
| me@client:~$ sudo aptitude install puppet |
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
1
2
3
4
| * Starting puppet agentpuppet not configured to start, please edit /etc/default/puppet to enable ...done. |
which means you need to edit the file the message refers to. So, sudo nano /etc/default/puppet, change
1
2
| # Start puppet on boot?START=no |
to
1
2
| # Start puppet on boot?START=yes |
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:
1
2
3
4
5
6
| me@client:~$ sudo puppet agent --testwarning: peer certificate won't be verified in this SSL sessionwarning: peer certificate won't be verified in this SSL sessionwarning: peer certificate won't be verified in this SSL sessionExiting; no certificate found and waitforcert is disabledORme@client:~$ puppetd –server puppet.example.com –waitforcert 60 –test |
Once that’s done, we have the puppetmaster approve the client’s certificate:
1
2
3
| me@puppet:/etc/puppet$ sudo puppetca --list new-server.local (6F:47:D1:6B:F3:B0:4B:94:00:92:5E:F7:E5:38:7C:C9)me@puppet:/etc/puppet$ |
1
2
3
4
| me@puppet:/etc/puppet$ sudo puppetca --sign new-server.localnotice: Signed certificate request for new-server.localnotice: Removing file Puppet::SSL::CertificateRequest new-server.local at '/var/lib/puppet/ssl/ca/requests/new-server.local.pem'me@puppet:/etc/puppet$ |
After the client certificate is signed, it’s no longer in the server’s pending list.
1
2
| me@puppet:/etc/puppet$ sudo puppetca --listme@puppet:/etc/puppet$M |
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:
1
2
3
4
5
6
7
8
| me@new-server:~$ sudo puppet agent --testwarning: peer certificate won't be verified in this SSL sessioninfo: Caching certificate for new-server.localinfo: Caching certificate_revocation_list for cainfo: Caching catalog for new-server.localinfo: Applying configuration version '1330636935'notice: /Stage[main]//Package[ntp]/ensure: ensure changed 'purged' to 'present'--- /etc/ntp.conf 2011-09-02 18:42:40.000000000 +0000 |
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:
1
| me@client:~$ sudo more /var/log/syslog | grep puppet-agent |
Next time, we’ll take a look at the files that make up a “catalog”.
REFERENCES
http://eison.net/2012/03/puppetmaster-xcvii-getting-your-new-server-registered/
http://www.unixmen.com/install-puppet-master-and-client-in-ubuntu/
