If it's less than a half dozen machines, you can likely get away with clusterssh, which allows you to control multiple machines at once via ssh. But if you have more, or you want a more elegant and centralized way of managing configuration, you want Puppet. Yes, there's also cfengine, but puppet is said to be more flexible. I can't comment on that, since I've only used cfengine briefly, and thought it was too complicated to be worth it. Having said that Puppet has a fairly steep learning curve as well.
Puppet has a client-server architecture. The client is "puppet" the server is "puppetmaster". Installing puppetmaster will automagically install puppet on the same host. For other hosts that you want to control via your main puppetmaster host, simply install just the puppet package.
By default puppet clients expect their master to be called "puppet" in DNS, but you can change this. If you plan to have multiple puppetmasters(for whatever reason, such as separate networks/clients etc) it's probably a good idea to change this(see below on how to do that). Having said that, the puppet system is clever enough that it won't just start changing things on clients that you specify on the puppetmaster. In fact it's the clients that poll the server for changes, and will only apply a change to themselves, if they've exchanged keys with the server beforehand.
So how do I get the clients to talk to the master?
puppetd --server yourpuppetmaster --waitforcert 60 --test
The puppetmaster can list which clients have asked to be controlled by it:
puppetca --list
Finally, if the server wants to control that client, it should sign it's certificate that the client requested in the previous steps:
puppetca --sign puppetclientname
Note, the puppet client on the puppetmaster server itself, is already authorized, and doesn't need to go through the above steps.
Let's first try creating a file. Puppet can push out existing files, but it can also create new ones. For this first example, we'll try the latter.
You put the configs in /etc/puppet/manifests, and by default, puppet expects there to be a file called "site.pp" You can split up your configs and have other files in the same directory, and then link them from site.pp, but we'll do that later. For now just add this to your site.pp file(which you'll create):
# Create "/tmp/testfile" if it doesn't exist.
class test_class {
file { "/tmp/testfile":
ensure = present,
mode = 644,
owner = root,
group = root }
}
# tell puppet on which client to run the class
node yourpuppetclient { #this is the name of one or more of your puppet clients
include test_class
}
Here's another simple example for running a script.
Notice the "require" statement which is where Puppet's power lies.
class test2 {
exec { "my test program"
cwd "/var/tmp",
command = "/var/tmp/test.sh",
alias = "testscript",
# require = User['tibor'], #require that the user "tibor" exists before running the script }
} #And then specify which client to apply it to:node yourpuppetclient { include test }
So when will the changes be applied?
By default puppet applies its changes every 30min. If you want to manually apply an update, you can run
puppetd -o -v
Changing the puppet master name from the default "puppet"
This is optional...In /etc/puppet/puppet.conf on each client add[puppetd]
server=yourpuppetmasterserver
and on the server only under the [puppetmasterd] section
certname=yourpuppetmasterserver
To make sure this post is not too overwhelming, I'll stop here. Next post about puppet, I'll include some more complex examples to show the power of Puppet. -T
