Part 2 - Our first client
Contents
In Part 1 we set up a basic puppetmaster, it was not able to do much yet but all the building blocks in place for configuring numerous nodes, serving files to them and putting logic onto these client nodes.
Your first manifest
A manifest is a bit of puppet language that describes what you wish to do on a server, in our example the manifests live in files ending in .pp in the /etc/puppet/manifests/ directory.
As mentioned in the introduction we'll focus our efforts around the /etc/hosts file, starting simple by simply placing a centrally stored file on a client and then gradually moving to a more complex setup.
First we need to look a bit at how we collect resources into named groups. In puppet the simplest form of a collection is called a class, a class allows us to put one or more resources in a handy group that can then be included into a specific node, you will see how to include it into the node a bit later. For now it's enough to know that in general all things that goes into a node needs to at some point live in a class.
To read more about classes and see samples of inheritance see the Language Tutorial
A sample class that will hold our hosts file can be seen below - without any meat yet, it is just an empty class:
class hosts {
}
Place this into a file called /etc/puppet/manifests/classes/hosts.pp as you can imagine this isn't doing anything useful yet, but it will be enough to introduce the concept of nodes.
Before going on, you need to start the puppetmaster using the init script, simply run /etc/init.d/puppetmaster start
Your first node
We now have a manifest to apply to nodes - even though it is empty the end result will be that nothing happens, that is fine for now. Now lets create a node, my test machine will be called simply dev1.devco.net you can use whatever hostname works for your network.
Create a file in /etc/puppet/manifests/nodes/dev1.devco.net.pp with the following in it:
node "dev1.devco.net" {
include hosts
}
This tells the puppetmaster that when the host dev1.devco.net comes to ask for it's configuration the puppetmaster will apply what is in the hosts class. In future other classes will also be included in this file.
Installing Puppet on the client
As before when we installed the puppetmaster we'll use yum to get puppet onto the node, simply do the following:
dev1# yum install puppet facter . . . Running Transaction Installing: facter ######################### [1/2] Installing: puppet ######################### [2/2] Installed: puppet.noarch 0:0.24.4-1.el5 Dependency Installed: facter.noarch 0:1.3.8-1.el5 Complete!
And lets just make sure the puppet daemon isn't actually running just yet by doing:
- It is ok if the next step says FAILED instead of OK
dev1# /sbin/service puppet stop Stopping puppet: [OK]
Remember we use DNS or /etc/hosts entries to make sure that puppet will resolve to the right place, so double check using the ping command that ping puppet will communicate with the master.
Running puppet on the client the first time
The communications between client and master is all encrypted using SSL, this has implied requirements for certificates etc, on the first run puppet will send a certificate signing request to the master, this is how it will look:
dev1# puppetd --test info: Creating a new certificate request for dev1.devco.net info: Creating a new SSL key at /var/lib/puppet/ssl/private_keys/dev1.devco.net.pem warning: peer certificate won't be verified in this SSL session notice: No certificates; exiting
You now need to sign the request - effectively allowing future communications, do this on the puppetmaster:
master# /usr/sbin/puppetca --list dev1.devco.net master# /usr/sbin/puppetca --sign dev1.devco.net Signed dev1.devco.net
There are ways to simplify this processing using autosigning, we'll discuss that later on.
Starting the puppet daemon
If you now start the puppet server and monitor the log files you should see something along these lines:
dev1# /etc/init.d/puppet start Starting puppet: [ OK ] dev1# tail -f /var/log/messages Aug 7 19:28:38 dev1 puppetd[29404]: Reopening log files Aug 7 19:28:38 dev1 puppetd[29404]: Starting Puppet client version 0.24.4 Aug 7 19:28:39 dev1 puppetd[29404]: Starting catalog run Aug 7 19:28:39 dev1 puppetd[29404]: Finished catalog run in 0.21 seconds
On the puppetmaster host your log files will show:
Aug 7 19:28:39 master puppetmasterd[32156]: Compiled configuration for dev1.devco.net in 0.07 seconds
Conclusion
If you see similar lines on your machines then you've successfully completed the tasks in this part, so far you have achieved the following in addition to what you did in part 1:
You've created a configuration - called a manifest - that will go onto a remote host
You've created a node that tells your puppetmaster what manifests to put on your client machines
- You have installed your first client machine and established secure communications between it and the master
- You started the puppet daemon and it will now check in with the master every 30 minutes and perform any actions defined there
In the next part we will put some more meat into our hosts class and you will see how the client automatically get this change done on it.
You could in theory repeat the steps for a 100 nodes now, you can create node entries for each, telling them to include the hosts class and you can set up secure communications between the whole lot. In Part 3 we'll start copying some files to the clients!