[[PageOutline]] = 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 [https://we.riseup.net/riseup+tech/puppet-git-submodules 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 }}}