Puppet tutorial series
(Linux configuration management)- Part 1: Powering up with Puppet 2.6
- Part 2: Client and Server
Installing servers with Puppet
In the first part of the tutorial, we installed Puppet directly from the source. This is a great way to learn and experiment, but for production purposes we would like to use a standard package - in this case, an Ubuntu package we can install viaapt-get
. This
way, you can ensure that the same version of Puppet is present on your
servers and update it automatically if need be. The Ubuntu package also
has a few bonus features that the source package doesn’t.If you want to follow along with the tutorial using your existing Puppet source install, that’s fine. It’s a good idea to make sure you’re using the same version of Puppet on both client and server, or you may run into obscure and annoying problems, so either install from the same source package on your client machine, or set up two fresh machines with the Ubuntu package as described below.
The version of Puppet in the standard Ubuntu repositories is a little old, so add Mathias Gug’s puppet-backports repository to your machine so that you can get a more recent version:
# add-apt-repository ppa:mathiaz/puppet-backports
# apt-get update
# apt-get install puppet puppetmaster
You can now start the Puppetmaster daemon and make the service persistent:# update-rc.d puppetmaster defaults
# puppet master --mkusers
If there is a firewall between the Puppetmaster and its clients (eg
an iptables firewall on the Puppetmaster server itself) you will need to
open TCP port 8140 to the clients.Create a client manifest
In Part 1 of the Puppet Tutorial we created a file/etc/puppet/manifests/nodes.pp
, which lists the nodes (machines) that Puppet knows about, and what configuration they should have. Currently it looks like this:
node myserver {
include ntp
}
As we’re adding a new node to the system, we need to modify the file so that it reads like this:
node myserver {
include ntp
}
node myclient {
include ntp
}
Authorising a client
Puppet uses SSL (Secure Sockets Layer), an encrypted protocol, to communicate between master and clients. This means that only a client with a correctly signed SSL certificate can access the Puppetmaster and receive its configuration. To exchange certificates between the master and client, follow this procedure.Configuring the client to contact the server
Edit your/etc/puppet/puppet.conf
file to tell the client where to find the Puppetmaster:server = myserver.mydomain.com
Generate a certificate request
On the client, run:# puppet agent --test
info: Creating a new certificate request for myclient.mydomain.com
info: Creating a new SSL key at /etc/puppet/ssl/private_keys/myclient.mydomain.com.pem
warning: peer certificate won't be verified in this SSL session
notice: Did not receive certificate
notice: Set to run 'one time'; exiting with no certificate
Sign the certificate
On the master:# puppetca -l
myclient.mydomain.com
There is a certificate request pending for myclient
. To sign it, run:# puppetca -s myclient.mydomain.com
notice: Signed certificate request for myclient.mydomain.com
notice: Removing file Puppet::SSL::CertificateRequest myclient.mydomain.com at
'/var/lib/puppet/ssl/ca/requests/myclient.mydomain.com.pem'
If there is no certificate request listed, the client was not able to
contact the server for some reason. Check that you have the right
server address set in puppet.conf
on the client, and that TCP port 8140 is open on both the master and client firewalls. The puppet master
daemon also needs to be running on the master.Run Puppet for the first time
On the client, you should now be able to run:# puppet agent --test
notice: Got signed certificate
info: Caching catalog at /var/puppet/state/localconfig.yaml
notice: Starting catalog run
notice: //ntp/Service[ntp]/ensure: ensure changed 'stopped' to 'running'
notice: Finished catalog run in 0.92 seconds
Just as on the server in the first part of the tutorial, Puppet is now applying the ntp
class to myclient
. At the moment all this class does is ensure the ntp
service is running, but of course it could do many more interesting things. And that’s what we’ll look at next time in Part 3.
No comments:
Post a Comment