Wiki Navigation

Complete Configuration

To get a feeling what can be done with puppet, take a look at the git repository of David Schmitt. He develops webhosting automation and publishes his manifests and modules under the liberal BSD License.

Get it

Either go to his gitweb or create a local clone.

The "manifests" repo contains a complete configuration, to put in $confdir (generally /etc/puppet).

$ git clone git://git.black.co.at/manifests davids-manifests

Modules are in the process of being split from the manifests repo into their own individual repositories. You will need to install at least the "common" module, and various modules for different resource classes.

# common prerequisite
$ git clone git://git.black.co.at/module-common /etc/puppet/modules/common
# virtual machine support
$ git clone git://git.black.co.at/module-virtual /etc/puppet/modules/virtual

Modules

apache: manage apache2, modules and sites; created from the Apache2 Recipe
apt: manage apt sources and keep the caches hot
backuppc: classes for the server and the client
bind: still in development
common: generic defines, functions and other miscellanea
d_i: still in development
dbp: local best practices; this module really integrates many of the other modules into a single class
dnsmasq: the simple DNS resolver and DHCP server
dovecot: install and setup IMAP and POP3 over SSL
ejabberd: install a jabberd for a single domain
exim4: install exim4 with spam- and virusscanning
git: various defines for git; including gitweb
hosting: another central module, which pulls many others together to create a customer VServer and configure it in all subsystems; still in development
ifupdown: still in development
ldap: setup a ldap server and manage users with smbldap-tools; includes custom user and group providers
mailman: partly superseded by the maillist type; needs to be reexamined
munin: configures the resource monitor "munin"; see generated page of David's installation
mysql: manage mysql databases; stillin development
nagios: this module is used by many others to register custom service checks. This enables automatic health monitoring of puppet-managed resources.
ntp: setup a local ntp subnet according to the public recommendations
php: install a good subset of php modules; supports php4 and php5
postgresql: still in development
puppet: local stuff, mostly automated tests
roundcube: a slick AJAX webmailer
samba: still in development
shorewall: from Aqueos Shorewall?: manage the firewall rules
ssh: distributes all hostkeys between all nodes.
ssmtp: no local queues anymore! send mails to a central smarthost
svn: manage repositories
udev: still in development
virtual: facts for XEN and vserver; create and start VServers

Code Samples

Here some points of interest which might give starting points to explore the manifests and modules.

Configuring a simple Node

Configure the BackupPC Server:

From manifests/site.pp:

node backuppc {
        # only use the smarthost
        $mta = ssmtp
        # this is a vserver on this host, so register correctly in nagios
        $nagios_parent = "ic.black.co.at"
        # I'm sharing an IP here, so those things have to have their own ports
        $apache2_port = 8080
        $munin_port = 5008
        $munin_stats_port = 8667

        # default configuration
        include dbp

        # configure the backuppc server
        include backuppc::server
}

Hosting

Provision and configure a complete customer VServer with a bunch of services. See the "hosting" module for how to configure two nodes from the same place. Be sure to read up everything you can find on scopes first ;)

From manifests/site_hosting/davids.pp:

hosting_vserver_configuration {
    "davids":
        domain => "black.co.at",
        type => "friend",
        context => 13,
        ip => "83.64.231.75", prefix => 27,
        admin_user => "david", admin_user_name => "David Schmitt",
        admin_user_email => "david@black.co.at",
        customer => "David Schmitt",
        admin_password => file("/etc/puppet/secrets/hosting/davids_admin_password"),
}
class davids_black_co_at {
    ## Create users for my parents and my grandmother
    hosting::user {
        rztt: realname => "Gerhard Schmitt",
            uid => 2001, admin => true;
        conny: realname => "Conny Schmitt",
            uid => 2002;
        oma: realname => "Oma Schmitt",
            uid => 2003;
    }

    # Install git.black.co.at
    include git::daemon
    include git::web
    git::web::export { [manifests, "puppet-trunk"]: }

    # Provision an additional mysql database on the database server 
    hosting::database { "fogbugz": type => mysql }
    # Create another VirtualHost
    apache2::site { "local-fogbugz":
        source => "puppet://$servername/files/hosting/davids/sites/local-fogbugz"
    }
}

Using `concatenated_file`s with export/collect

One of the newest additions to the "common" module, concatenated_file, manages a file that is puzzled together from multiple sources. For example the "munin" module uses this to build the central list of munin nodes, which is a monolithic list of paragraphs without any pre-processor.

Using storeconfigs and exported resources, every node configuration can decide what to put into the file. Since this is all done on the puppetmaster it is not only really flexible and powerful, it is also safe, since only very restricted information is passed from the client to the munin configfile.

On the munin host:

# Collect all exported files
File <<||>>

# Compile the munin.conf with a local header
concatenated_file { "/etc/munin/munin.conf":
    dir => $NODESDIR,
    header => "/etc/munin/munin.conf.header",
}

On each munin client:

@@file { "${NODESDIR}/${name}_${munin_port_real}":
    ensure => present,
    content => template("munin/defaultclient.erb"),
}

Of course, in the module, this is all wrapped into defines and classes, so the actual configuration looks like this: