Puppet Infrastructure SOP

From FedoraProject

(Difference between revisions)
Jump to: navigation, search
m (Remove stray moin markup which referred to outdated/unused commands.)
(Minor updates)
Line 34: Line 34:
  
 
== Adding new files ==
 
== Adding new files ==
Adding new files consists of two things, adding the file and adding the manifest.  Adding the config file is similar to the alteration section above.  Just add the file to the appropriate directory, cvs add filename.  Then commit and run 'make install'
+
Adding new files consists of two things, adding the file and adding the manifest.  Adding the config file is similar to the alteration section above.  Just add the file to the appropriate directory, git add filename.  Then commit and run 'git push'
  
Once the config file is in place move to your manifests directory and add the file to whichever manifest seems appropriate.  If none do, add a new manifest.  All of our manifests exist in the services directoryFrom there the servergroups manifests group the services into logical machines.  The nodes file then includes those servergroups for submission to the servers.
+
Once the config file is in place move to your manifests directory and add the file to whichever manifest seems appropriate.  If none do, add a new manifest.  Most of our non-Fedora specific manifests exist in various puppet modulesFor manifests specific to our setup, there is a manifests directory with a servergroups directory grouping the services into logical machines.  The node file (in manifests/nodes) then includes those servergroups.
  
 
== Adding new node ==
 
== Adding new node ==
Adding new hosts of an already known type is easy.  The following example is for a builder.  First check out the manifests module.  Then add a new node file (see other node files for an example:)
+
Adding new hosts of an already known type is easy.  The following example is for a builder.  First change into the manifests/nodes directory.  Then add a new node file (see other node files for an example):
  
 
For example
 
For example
  
 
<pre>
 
<pre>
node xenbuilder3{
+
node "xenbuilder3.fedora.phx.redhat.com" {
include build
+
  include build
 
}
 
}
 
</pre>
 
</pre>
Line 57: Line 57:
 
<pre>
 
<pre>
 
git clone /git/puppet
 
git clone /git/puppet
cd puppet/manifests
+
cd puppet
vi fileserver.conf
+
vi modules/puppet/files/fileserver.conf
 +
vi modules/infra-repo/files/allows
 
git commit -a
 
git commit -a
cd ../configs
 
vi web/infrastructure.fedoraproject.org/infrastructure.conf
 
vi web/exclude.conf.erb
 
 
git push
 
git push
 
</pre>
 
</pre>
Line 87: Line 85:
 
</pre>
 
</pre>
  
=== Finalizing ===
+
to remove an existing key from the puppet CA (for example when rebuilding a machine), run
Sometimes a new node needs to have puppet restarted in order to connect correctly after its certificate has been approved.  Simply log in and run 'service puppet restart'
+
 
+
== Remove Server ==
+
To remove a server first clean the cert:
+
 
<pre>
 
<pre>
puppetca -c xenbuilderx.fedora.phx.redhat.com
+
puppetca -c xenbuilder3.fedora.phx.redhat.com
 
</pre>
 
</pre>
Then remove its node file.
+
 
 +
first.  Note that cleaning the key (puppetca -c) and revoking the key (puppetca -r) are very different concepts.  A cleaned key can still be used to access puppet, while a revoked key cannot.
 +
 
 +
=== Finalizing ===
 +
Sometimes a new node needs to have puppet restarted in order to connect correctly after its certificate has been approved. Simply log in and run 'service puppet restart'
  
 
=== Regenerate cert request ===
 
=== Regenerate cert request ===

Revision as of 04:01, 13 August 2009

Infrastructure InfrastructureTeamN1.png
Shortcut:
ISOP:PUPPET

This page is intended for people who are already familiar with puppet. It is specific to our Fedora Infrastructure though the techniques are general enough to apply to other environments.

Contents

VCS/GIT

All of our configs and manifests are stored in GIT. We also have a private GIT that stores keys, certificates and other files (like sudoers) that shouldn't be messed with or altered but by a select few people.

The following commands will check out all GIT configs (from puppet1.fedora.phx.redhat.com)

git clone /git/puppet

or if you've got a checkout already:

cd puppet
git pull

Altering config files

The config files need to be edited, saved and installed. The following example assumes everything is checked out already and is to alter a proxy file on the webserver.

cd configs
vi web/fedoraproject.org/wiki.conf
git commit -a

Once you have all of your changes in and ready run:

git push

Adding new files

Adding new files consists of two things, adding the file and adding the manifest. Adding the config file is similar to the alteration section above. Just add the file to the appropriate directory, git add filename. Then commit and run 'git push'

Once the config file is in place move to your manifests directory and add the file to whichever manifest seems appropriate. If none do, add a new manifest. Most of our non-Fedora specific manifests exist in various puppet modules. For manifests specific to our setup, there is a manifests directory with a servergroups directory grouping the services into logical machines. The node file (in manifests/nodes) then includes those servergroups.

Adding new node

Adding new hosts of an already known type is easy. The following example is for a builder. First change into the manifests/nodes directory. Then add a new node file (see other node files for an example):

For example

node "xenbuilder3.fedora.phx.redhat.com" {
  include build
}

The "include build" line refers to a 'build' group in the servergroups directory.

Node Access

If this is a new node coming from a previously un-used IP address. We need to give puppet, infrastructure and the accounts system access to the node:

git clone /git/puppet
cd puppet
vi modules/puppet/files/fileserver.conf
vi modules/infra-repo/files/allows
git commit -a
git push

On the node

Do a manual run of puppet:

puppetd -t --server=puppet

This initial run will send a certificate request over to the puppet master. once you have signed the new request (below) go back to the node and re-run the command. It may be necessary to run puppet several times on the first run to make sure that all of the dependencies get worked out.

Signing new ca request

If using one of our official kickstart scripts a server will automatically request a cert from puppet1. To view a list just run (as root)

puppetca --list

followed by a sign of whatever hostname needs to be signed:

puppetca --sign xenbuilder3.fedora.phx.redhat.com

to remove an existing key from the puppet CA (for example when rebuilding a machine), run

puppetca -c xenbuilder3.fedora.phx.redhat.com

first. Note that cleaning the key (puppetca -c) and revoking the key (puppetca -r) are very different concepts. A cleaned key can still be used to access puppet, while a revoked key cannot.

Finalizing

Sometimes a new node needs to have puppet restarted in order to connect correctly after its certificate has been approved. Simply log in and run 'service puppet restart'

Regenerate cert request

To regenerate the cert request (for example when re-kicking a box) first remove the old cert

puppetca -c xenbuilderx.fedora.phx.redhat.com

then restart puppet on the remote node. Then sign the certificate as mentioned above with --sign