Puppet, configuration management system. Part II

In the first part, I talked about the main features of the configuration management system Puppet. In the second part, we will configure two cars in order to try basic things.

For hostnames, I decided to use the names of robots from the epic of George Lucas's Star Wars: R2D2 and C-3PO . Since R2 is smarter, it will drive C-3PO.

As an OS for experiments, I decided to use Ubuntu Server 8.04.01-LTS. It was possible and Debian, and Cent OS, and FreeBSD - it does not matter. Ubuntu Server I use because of the simplicity of its settings, the friendliness for me personally. Who likes something else is not a question.

Managing server

So let's start with R2D2, i.e. from the control machine. We put the puppetmaster package on it:
')
sudo apt-get install puppetmaster

after executing this command, the management server will be installed and launched under the puppet account.

Now we will create a configuration file for the management server. In terms of puppet, it is called a manifest. We will create site.pp manifest in the / etc / puppet / manifests directory. Content is:

file { "/etc/passwd":
owner => "root",
group => "bin",
mode => 644,
}

It should be immediately noted that since we have not specified any nodes, all the parameters specified in the manifest will be applied to all client hosts. Thus, all machines that have applied to R2D2 for configuration will verify the rights and owner of the / etc / passwd file.

The server is running on port 8140, so in case of problems, check the network settings, the client machines should have access to port 8140 on the management server.

Customer

We put the puppet package on the client:

sudo apt-get install puppet

The client, unlike the server, works under the root account in order to be able to make any changes to the system. To begin with, the client generates a certificate, which, when it is first connected to the server, asks to sign. If the certificate is signed, the client receives the current configuration, and then applies it to the machine. In the future, every half hour, the client checks whether the configuration has changed.

Add at the end of the /etc/puppet/puppet.conf config line:

[puppetd]
server=r2d2.localdomain

this tells the client which server to work with. You can specify ip, I have ip r2d2 registered in / etc / hosts.
It is VERY IMPORTANT that the server name is exactly the same as the management server signs certificates. You can check the server name in certificates using openssl:

openssl s_client -showcerts -connect r2d2.localdomain:8140

Also comment out the line:

#pluginsync=true

This option sets the synchronization of plug-ins with the server - while it is not needed, it is better to comment out.

Now run the puppet client so that it generates a certificate, sends it to the management server and requests to sign:

spanasik@c3po:~$ sudo puppetd --verbose --test
info: Creating a new certificate request for c3po.localdomain
info: Creating a new SSL key at /var/lib/puppet/ssl/private_keys/c3po.localdomain.pem
warning: peer certificate won't be verified in this SSL session
notice: No certificates; exiting

So, now the c3po certificate should be on r2d2, check its availability on r2d2, and if it is there, we will sign:

spanasik@r2d2:~$ sudo puppetca --list
c3po.localdomain
spanasik@r2d2:~$ sudo puppetca --sign c3po.localdomain
Signed c3po.localdomain

Certificate signed. Repeat the test run client:

spanasik@c3po:~$ sudo puppetd --verbose --test
warning: peer certificate won't be verified in this SSL session
notice: Got signed certificate
info: No classes to store
info: Caching catalog at /var/lib/puppet/state/localconfig.yaml
notice: Starting catalog run
info: Creating state file /var/lib/puppet/state/state.yaml
notice: Finished catalog run in 0.04 seconds

Everything works OK. Now we’ll check what happens if we change the owner of the / etc / passwd file :-)
My account is spanasik, so I will assign myself as its owner and install the 777 mask:

spanasik@c3po:~$ sudo chown spanasik:users /etc/passwd
spanasik@c3po:~$ sudo chmod 777 /etc/passwd
spanasik@c3po:~$ ls -la /etc/passwd
-rwxrwxrwx 1 spanasik users 1084 2009-09-01 12:01 /etc/passwd

Now run the puppet client:

spanasik@c3po:~$ sudo puppetd --verbose --test
notice: Ignoring cache
info: No classes to store
info: Caching catalog at /var/lib/puppet/state/localconfig.yaml
notice: Starting catalog run
notice: //File[/etc/passwd]/owner: owner changed 'spanasik' to 'root'
notice: //File[/etc/passwd]/group: group changed 'users' to 'root'
notice: //File[/etc/passwd]/mode: mode changed '777' to '644'
notice: Finished catalog run in 0.03 seconds

Voila!

spanasik@c3po:~$ ls -la /etc/passwd
-rw-r--r-- 1 root root 1084 2009-09-01 12:01 /etc/passwd

The owner is again root, and the rights as expected - 644. Well, actually, now we start the client daemon:

spanasik@c3po:~$ sudo /etc/init.d/puppet start
* Starting puppet configuration management tool [ OK ]
spanasik@c3po:~$ ps auxw | grep puppet | grep -v grep
root 6959 1.3 7.3 29584 18856 ? Ssl 13:46 0:00 ruby /usr/sbin/puppetd -w 0

Everything works OK, now every half hour c3po will check the update of the config on r2d2 and make changes to the system.

One machine, automatic deployment?

If you have only one machine, then you need to install both packages, and configure them exactly as described. I described the advantages of using the system on one machine in a previous article, the main thing is the quick launch on a new server after a crash.

You can see that in this article I did everything manually. Of course, this is not an option when you have hundreds of cars. In the case when you have a lot of machines, you can apply automatic system deployment. You make an image for installation, and pour it on the hard drives. At the very first boot, the client system will connect to the management server, and then you can use the default config, or work with each one separately. I note that I myself did not do this, because not adminyu park cars.

Here pingeee in the comments describes the possible option of spilling images on the grid, for which he thanks a lot. And the respected stasikos tells us about the FAI tool for debian-like distributors, for which we are also no less grateful.

In the following articles we will talk about more complex and interesting things that puppet allows you to do.