/!\ Note: make sure to read the coding style guidelines before committing to the Puppet repository. Running puppet-lint on the manifest files you modified is also suggested

Puppet

As per Wikipedia: Puppet is a tool for managing the configuration of Unix-like systems, declaratively. The developer provides puppet templates for describing parts of the system, and, when these templates are deployed, the runtime puts the managed systems into the declared state.

Puppet consists of a custom declarative language to describe system configuration, distributed using the client-server paradigm (using XML-RPC protocol), and a library to realize the configuration. The resource abstraction layer enables administrators to describe the configuration in high-level terms, such as users, services and packages.

How it works

Puppet configuration lives in /home/admin/puppet.git. Make sure to not clone the repository directly on your home directory on any of the GNOME servers but do a local clone on your personal computer.

To change the configuration:

git clone ssh://puppet-back/git/puppet.git
vim $some_file
git commit -a
git push

If the configuration changes aren't applied, use the following command on the target machine to see debug output:

/usr/sbin/puppetd --test

Goal

All hosts should be configured using puppet. This ensures all configuration changes can are logged and benefit from version control. Further, eases disaster recovery.

Setting up Puppet on a new host

Here's a quick recipe for getting puppet going on a machine:

rpm -Uvh http://dl.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpm
yum install puppet facter
echo '172.31.1.53 puppet puppet.gnome.org' >> /etc/hosts
chkconfig puppet on
service puppet start

In the puppet config:
  Add entry to manifests/nodes.pp

On puppet.gnome.org:
  puppetca --sign <host>.gnome.org

(Requires the machine to be connected to the back-channel at the Red Hat server, since puppet doesn't have a public IP)

Login access to the Puppet Master server

The puppet server doesn't currently have a public IP. All the details need to login are available at the ../Bastion wiki page.

Mounting an external directory on the Puppet Master (practical example)

Modify /etc/puppet/fileserver.conf on puppet-back by adding the following content:

[dns]
path /srv/dns
allow 172.31.1.23
  1. Make sure SELinux labels are properly set on the files you want Puppet Master to be able to read.
  2. Restart the Puppet Master with service puppetmaster restart.

  3. Add the file on a class this way:

file { "/var/named/chroot/master/gnome.org.signed":
     owner   => "root",
     group   => "named",
     mode    => 0644,
     source  => "puppet:///dns/built/gnome.org.signed",
   }

Adding passwords or secret keys on Puppet

Note: DO NOT include plain text passwords on the Puppet repository, use this procedure instead!

Hiera-Eyaml-GPG has been configured for safely looking up passwords (but generally node-specific configurations and values too!) from a GPG-Encrypted Eyaml file.

The file is located under /etc/puppet/hieradata/secrets.eyaml on puppet-back. Modifying the file can be done by using the eyaml command. The eyaml command will pick up puppet-back's private keys by default for decrypting/encrypting the relevant file. Using your own GPG Key is totally legit. Make sure to first add the needed recipient under /etc/puppet/hieradata/hiera-eyaml-gpg.recipients though and make sure your key is ultimately trusted by the default key or you'll need the eyaml's --gpg-always-trust flag in place.

Editing the file:

sudo -u puppet eyaml edit /etc/puppet/hieradata/secrets.eyaml

Your preferred editor will be fired up, the file decrypted for you to add new values. Once done close the editor, eyaml will automatically encrypt the file again.

Referencing a Hiera lookup on a Puppet manifest:

$variable_name = hiera('class_name::variable_name')

And then on a template file:

<%= @variable_name %>

Updating the host shouldn't happen with puppetd --test but with the following command instead:

puppetd --onetime --verbose --ignorecache --no-daemonize --no-usecacheonfailure --no-splay

The command above is the equivalent of puppetd --test without the show_diff flag which is specified on puppet.conf for daemon runs but seems to be superseded by the --test flag when specified on the command line. You may consider adding an alias on your bashrc to not forget the show_diff flag as true. As you can guess the result would be displaying the password in plain text on the gnome-sysadmin mailing list when the change will be pushed to Git.

Sysadmin/Puppet (last edited 2016-03-31 10:01:30 by AndreaVeri)