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
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.
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 puppet-back:/git/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:
puppet agent -t
All hosts should be configured using puppet. This ensures all configuration changes can are logged and benefit from version control. Further, eases disaster recovery.
Login access to the Puppet Master server
The puppet masters don't currently have a public IP. Connecting to them happens by using their vpn.*.gnome.org DNS entries:
- vpn.puppet.gnome.org (Puppet 2.X series)
- vpn.puppetmaster01.gnome.org (Puppet 3.X series)
The Bastion wiki page has the instructions for a proper .ssh/config setup.
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 puppet agent -t --test but with the following command instead:
puppet agent --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.