Version 4 (modified by Jamie McClelland, 11 years ago) (diff)



MF/PL is moving toward puppet as a system administration infrastructure.

administering puppet

puppet can be intimidating. If you want to help with the administration, here's instructions to get started:

setting up a development environment

Get the configuration:

git clone git://
cd puppet
git submodule init
git submodule update

And as the superuser, install the tools:

apt-get install puppet-common

then copy and update the sample configs to refer to your current environment:

cp puppet.conf.sample puppet.conf
cp fileserver.conf.sample fileserver.conf
$EDITOR puppet.conf fileserver.conf

some important changes to consider:

  • repoint [files] path in fileserver.conf
  • make a simple var dir for your dev puppetmaster to stash its data
  • repoint all the explicit dirs in puppet.conf to the var dir

Then you can launch the puppet master as a non-privileged user from the checked-out directory:

puppet master --confdir=$(pwd) --no-daemonize --verbose

The next step is to create a virtual machine that will run puppet and connect to the master. This virtual machine will be your test puppet node.

You will need to minimally install the following packages:

aptitude install puppet lsb-release

Then, edit /etc/puppet/puppet.conf adding the following line:


Replace HOSTNAME-OF-MASTER with the hostname of the machine from which yo uare running the puppet master command.

Then, run the following command on your test puppet node:

puppet agent --verbose --waitforcert 60

On your master run:

puppet cert --list

And you should see the hostname of your puppet node.

Then run (FIXME should include fingerprint verification):

puppet cert --confdir=$(pwd) --no-daemonize --sign HOSTNAME 

Replace HOSTNAME with the listed hostname from the previous command.

Once the cert is verified, you can run the following on your test puppet node to test changes to the manifests and modules:

puppet agent --no-daemonize --verbose

Making changes to MFPL's puppet files

There are three main directories:

  • files: used to store files that are copied to our servers as is
  • manifests: the place where May First/People Link specific documentation is kept
  • modules: generic modules used to help define configurations that are shared with others

Edits to any file in the files or manifests directories can be changed, committed and pushed like in any other git repo.

However, changes to the modules directory require more careful attention since thay are stored as git submodules.

  • For every submodule, you need to add a writable remote (by default, you will pulling these in read-only). You can do that with:
    git remote add mfpl-write
  • When you push your changes, you need to specify with:
    git push mfpl-write +HEAD:master