ReleaseEngineering/Puppet/Usage: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
Line 12: Line 12:
* The packages can have different sections or "Types" that can be "exec", "user", "package", "file", "service"
* The packages can have different sections or "Types" that can be "exec", "user", "package", "file", "service"
* You have to enter as the "root" user for the puppet masters and the repo is in /etc/puppet/manifests. '''You don't have to do any reconfiguration''' but just apply your patch or checkout your changes.
* You have to enter as the "root" user for the puppet masters and the repo is in /etc/puppet/manifests. '''You don't have to do any reconfiguration''' but just apply your patch or checkout your changes.
'''NOTE: Careful what you do with the checkout since you can loose the locally added password.''' Run hg diff if you don't know what I am saying.
'''NOTE: Careful what you do with the checkout since you can lose the locally added password.''' Run hg diff if you don't know what I am saying.
* Test that what you are adding gets picked up by the slave. To do so log in as "root" on a staging slave and run this:
* Test that what you are adding gets picked up by the slave. To do so log in as "root" on a staging slave and run this:
  puppetd --test --server staging-puppet.build.mozilla.org
  puppetd --test --server staging-puppet.build.mozilla.org

Revision as of 23:28, 29 March 2010

Puppet: Usage | Server Setup | Client Setup

This document is intended to serve as a guide to interacting with the Puppet server installed on staging-puppet.b.m.o and production-puppet.b.m.o.

Definitions

  • Type - Puppet documentation talks a lot about this. Each different "type" deals with a different aspect of the system. For example, the "user" type can do most things related to user management (passwords, UID/GID, homedirs, shells, etc). The 'package' type deals with package management (eg, apt, rpm, fink, etc). And so on.

Understanding and using Puppet

  • We have an internal cvs repository for the binaries that we want to keep versioned and synced with the slaves.
  • The site-{staging,production}.pp files declare the list of slaves and each slave has defined which classes to include.
  • The classes buildslave.pp and staging-buildslave.pp include most of the packages (devtools, nagios, mercurial, buildbot, extras, etc) we want.
  • The packages can have different sections or "Types" that can be "exec", "user", "package", "file", "service"
  • You have to enter as the "root" user for the puppet masters and the repo is in /etc/puppet/manifests. You don't have to do any reconfiguration but just apply your patch or checkout your changes.

NOTE: Careful what you do with the checkout since you can lose the locally added password. Run hg diff if you don't know what I am saying.

  • Test that what you are adding gets picked up by the slave. To do so log in as "root" on a staging slave and run this:
puppetd --test --server staging-puppet.build.mozilla.org

This step should take several seconds and if it is successful you will see a message similar to this:

notice: //Node[<slave name>]/buildslave/extras/Exec[<your command>]/returns: executed successfully

REMEMBER: The slaves are declared in one of the site files and include some classes. Your class has include the package you are modifying.

Common Use Cases

Installing a library for scratchbox

In this use case, I installed the libhildon-fm-2 library for scratchbox which is accomplished by running this command on any slave (--yes to auto-confirm and --force-yes for the authentication prompts):

/scratchbox/moz_scratchbox -p apt-get --yes --force-yes install libhildonfm2-dev

NOTE: Since puppet runs as root and scratchbox does not allow that I had to use "su - cltbld -c <command>". NOTE2: Since we are running the command as another user we have to specify a "path" variable. Puppet verifies if a command has to be installed by checking if a file exists. To indicate this we add the variable "creates".

To see the patch follow this link and you will see that:

  • We created a new package (extras.pp), added an "exec" type section to it and called this package from two of the classes (buildslave.pp & staging-buildslave.pp) that different slaves include.


Updating a password

Passwords are stored in a hashed format alongside other user information. We do not put the hashes in a public location for hopefully obvious reasons - please make sure you don't do this by accident.

Let's say you want to update cltbld's password. First, you need to generate the new hash. You can do that by running the following:

makepasswd --clearfrom=- --crypt-md5
# now type the password and hit ^D a couple times

Now, copy and paste that password into /etc/puppet/manifests/build/cltbld.pp as the 'password' for the cltbld user.

Installing a package through yum

needs testing Installing a package through yum is dead easy. Here's an example for installing nano.

Documentation/Links

Puppet has reasonably complete documentation, although navigating it can be a challenge.