Puppet

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.

checking out the code

For read-only access (available to the public):

git clone git://git.mayfirst.org/mfpl/puppet

For write access (MFPL admins only):

git clone gitosis@git.mayfirst.org:mfpl/puppet

Then...

cd puppet
git submodule init
git submodule update

To get the most recent code after you've already checked out the repository:

git remote update
# to review changes:
git diff origin/master
git merge origin/master
# to pull in any updates to the submodules
git submodule update

setting up a development environment

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:

server=HOSTNAME-OF-MASTER

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 gitosis@git.mayfirst.org:mfpl/puppet-modules/MODULENAME
  

• When you push your changes, you need to specify with:

  git push mfpl-write +HEAD:master
  

If you want, you can edit the .git/config file in each submodule, adding the following line under your mfpl-write stanza:

push = +HEAD:master

Then, you only need to type:

{{{{ git push mfpl-write }}}

After you have made changes to a module (for example the mayfirst module), you need to add it with:

git add modules/mayfirst

Be sure not to include the trailing slash (thanks ​Riseup for that and other tips on git submodules).

Pulling in changes to the master repo

May First/People Link's Puppet Master server is on rustin.mayfirst.org which is aliased to puppetmaster.mayfirst.org.

As root on rustin:

cd /etc/puppet
git remote update

Next, check the last commit to make sure it matches the last commit you made (and want live):

On your local machine:

git log -n1

Compared with, on rustin:

git log -n1 mfpl/master

If they match, then rebase (we rebase to ensure that our local changes to files on rustin are not merged):

git rebase mfpl/master

And lastly, restart puppetmaster:

/etc/init.d/puppetmaster restart

Now, if puppet is running as a daemon on the nodes, the changes will eventually propagate. If you are running puppet manually on a node, you can test manually with:

puppet agent --verbose --no-daemonize --onetime