I recommend the packages from Natty (Ubuntu version 11), even if you're on Maverick (10.04). They are the most up-to-date (2.6x) and you'll find the most help on this version of puppet. You also won't have to bother with rubygems, etc..
If you're not using Natty, you can do apt-get pinning or just download the packages manually. I didn't want things "going bump in the night", so I downloaded the packages manually and installed. I also chose to run the client (agent) as a service, some people run it via cron. The details of what I did:
dpkg -i *.debsudo service puppet startsudo dpkg -i *.debsudo service puppetmaster startsudo puppetca --sign (fqdn)OK, you've got it installed on both sides. You need name resolution for this to work, so at minimum, the client needs to know how to get to the server, so put an entry in your hosts file on the client pointing to the server and restart the client. Now, do the following on both client and server and see that it's running.
sudo tail -f /var/log/syslog
sudo puppetca --list
sudo puppetca --sign (hostname)
If you want the joe text editor to be available on your system, put this in there.
package { 'joe':
ensure => present,
}
Want to make sure apache is running? Do this:
package { 'apache2':
ensure => installed,
}
service {
'apache2':
ensure => running,
enable => true,
require => Package['apache2']
}
Want a directory to be created on the machine?
file { '/tmp/mydir:
ensure => directory,
mode => 777,
}
You can (and should) push your own files down to your clients as well (taken from the manual):
file { "/etc/sudoers":
mode => 440,
owner => root,
group => root,
source => "puppet:///modules/module_name/sudoers"
}
Create a user on the box? (Notice the password hash)
user { "joe":
ensure => present,
shell => '/bin/bash',
home => '/home/joe',
managehome => true,
password => '$6$y./0s6u8$9cftGIJhrot/0lzGNDkW1GzgJJ3tcakzDBSyMxhHyOTfQmOEHUoQiXFU0YhJAIjwS/lc0OVwf/7NPORVw1LY99',
}
Have a service restart when one of its config files change?
See the "trifecta" in the cheat sheet: http://docs.puppetlabs.com/puppet_core_types_cheatsheet.pdf
Testing your code before deploying
puppet --parseonly myfile.pp
find /etc/puppet -name "*pp" -exec puppet --parseonly '{}' \;
The above is the gist of how it all works and is pretty powerful. You can see how this can get unruly, though, when you have 100s of packages, config files and users. Organizing your puppet config into modules and classes and using inheritance gives you the power to have "roles" for your machines that can build upon one another.
There is also the concept of nodes, so you can say things like, "I want all nodes except node3 to have this package."
Putting your code in SCM: You should check this code into a source control management system (SVN, Git, etc). My system is not that big, but deployment flow works like this:
It's not perfect, but my system isn't that big and is currently internal. There are docs on scaling puppet if you're interested.
The gotcha here is that you CAN'T use the include for this if you want to send in a parameter. I hate that. So, you need to do:
node /^foo-[4-8].bar.local/ inherits default {
notify {"${hostname} connected" : }
class { myclass: var1 => "my value" }
include other_class_sans_parameter
}
Say you need rebuild a node and want to reinstall puppet. In short, you'll get cert errors unless you do the following
sudo puppetca --sign <hostname>