• Choose a category
• All
• Classic-Fiction

* * *

Note

Puppet also supports an extensive set of comparison and arithmetic operators (even Backus-Naur Form!) for expressions as variable values. See the Puppet language guide at http://docs.puppetlabs.com/guides/language_guide.html for complete documentation.

* * *

Templates

Often you’ll want to maintain configuration files for applications that are different between servers. If you have a couple of configurations, it’s easy enough to maintain multiple files, but what if you have a very large number of differing configurations? We can manage this situation by writing ERB templates and populating the templates with node-specific information. This is done in Puppet with the template() function:

file { "apache-site":

path => "/etc/apache2/sites-available/$fqdn",

require => Package["apache2"],

content => template("apache-site.erb"),

notify => Exec["a2ensite"],

}

exec { "a2ensite $fqdn":

notify => Service["apache2"],

creates => "/etc/apache2/sites-enabled/$fqdn",

}

Here we have a file resource that creates an Apache config file named by the fqdn variable. We’ll assume that Facter is populating this variable with the fully qualified domain name of our server. The file contents are generated by an ERB template and then it notifies an exec that enables the site and notifies Apache to restart. Next we’ll write our template and place it in the expected location at /etc/puppet/templates/apache-site.erb:

DocumentRoot /var/www/

ServerName <%= name %>

allow from all

Options -Indexes

This is just a normal Apache vhost stanza, with the exception of the inline included name variable. All variables in the current scope are available to you in this manner and out-of-scope variables in other classes can be accessed by this lookupvar function, like so: scope.lookupvar('externalclass::myvariable'). Injecting variables into config file templates like this will let us drastically reduce the number of individual configuration files we need to maintain.

* * *

Note

Documentation for the ERB templating system can be found at http://www.ruby-doc.org/stdlib/libdoc/erb/rdoc/, and there are plenty of online tutorials on complex templating.

* * *

I’ve tried to give you a few real-world examples of how to implement the various features of Puppet, but the applications are vast and varied. I suggest that you take a while to peruse the community repository of Puppet modules at http://forge.puppetlabs.com/. There are plenty of great patterns of implementation and organization in these projects, and you may even come across an out-of-the-box solution to a problem of your own.

Chapter 3. Who Needs LDAP?

For many years I struggled with this question: “How do I effectively manage access control to Linux servers?” There are many options, including LDAP, Kerberos KDC, and the like, but I disliked each of them for one reason or another. Centralized auth is prone to failure and proper redundancy is painful to manage. Often password auth is well managed, but key distribution is difficult, or vice versa. With Puppet, I found a beautiful alternative. We can use Puppet to manage users and groups and distribute public keys. It can even enforce file and directory permissions and set password hashes. Gone are the days of writing big ugly scripts to push users and keys out to your whole farm of servers. We’ll see how to accomplish this in a less painful manner using Puppet.

Building the Framework

First, we’ll need a framework that can build user accounts in a repeatable fashion given a set of user attributes. We’ll use a definition to make a reusable structure that can implement the user type repeatedly with different inputs.

There is a lot going on in this snippet, so I’ll step through it point by point:

We’ve set up a class called rubyshadow that declares a package resource to install libshadow for Ruby. This is a prerequisite