Stefan Schlesinger

A Systems Policy

2012-02-01T09:12:00+01:00

Recently I talked to a couple of friends, which all wailed quite a bit about their operations or internal IT departments.

Most of these teams had to fight with some very basic things. They lacked a decent monitoring system or monitoring at all. They didn’t deploy systems, they installed it by hand. Systems where not documented etc.

So here are some guidelines, I try to aspire with my team. This is by far not a complete list of things you need to run successful operations but it should give you a fair hint about what it takes.

Also please note that you might want to adapt your own policy a bit to fit your needs. I’m coming from the web industry, but we still run our own hardware, so this might especially not fit a typical cloud based infrastructure.

Systems

A System is considered the lowest part of our infrastructure and services. All rules defined here, should be considered in all other policies.

A system….

is documented at a central location.
is monitored and being graphed.
is being backuped.
is updated regularly.
has a defined production level. (spare, pre-production, production)
has a defined owner and maintainer.
has a predefined maintenance level.
has a predefined availability.
has a physical location.
has a unique name, which is resolvable by DNS.
has only required software installed.
was installed with all currently available updates.
was inspected and approved by a second man before being released to production.
All parts are functional at any time. All Faults get documented RFN and repaired as soon as possible.
There are always 2+ people informed about it.
Network access vectors are defined.
Configurations are not only available locally (including scripts).
Sensible data gets protected.

Hardware

A piece of hardware can be anything from a big server to a small temperature sensor in your server room.

A piece of hardware…

has a maintenance contract or spare hardware available.
has got an inventory number.
is labeled (hostname + inventory).
is physically secure (environmental! and mechanical access control).
has got a bill, which is documented at a central location.
should have redundant power supplies.
should have some kind of out of band management solution (OOB).
has at least one power circuit connected to an electronic circuit protected by an uninterruptible power supply (USV).

All tools needed to open and repair any part of the system are available.

Servers

A server…

has at least two disks configured with RAID >= 1.
has at least two separate network interface cards (NICs).
has all RAID controllers backed with battery backed write caches (BBWC).
was dimensioned with adequate future-proof hardware.
has a lifetime of 2+ years.

Switches

A switch…

is manage- or configurable.
is supported by the configuration backup software in use (e.g. RANCID)
provides the following protocols: STP, SNMP, IPv6 support (mgmt+multicast), RADIUS for AAA
does not forward the default VLAN (1) on it’s uplink/trunk ports.
does have a description for every port in use (including hostname and interface, e.g.: server01#eth0, server01#oob, switch03#24)
does not have any enabled, unused ports: set them to disabled and remove any other configuration for this port.
blocks or does not forward any discovery protocols on it’s user ports.
is using AAA for authenticating users.
logs to a central syslog server.

Operating Systems

An operating system (OS) is considered as everything running on a server or instance, to support a service or an application.

An Operating System…

uses OS-CHOICE-HERE/stable as default distribution on servers.
uses OS-CHOICE-HERE as default on clients.
is rebooting without any manual interventions.
provides access by SSH.
does not permit root login via SSH.
has a root password set.
has the current time, synchronized with a time server and uses TIMEZONE-CHOICE-HERE as time zone.
can resolve internal and internet names via DNS.
installs software by packages.
installs packages from a central internal repository and the official distribution repositories.
software installed by packages should conform to the FHS.
software not installed by packages should be installed by a reproducible deployment process.
has sane defaults set, for user and process environments (locales, shells, screen, got some handy tools, etc.).
should not provide typical compiler tools (gcc, build-essential).
provides a manageable AAA concept (e.g. automated provisioning and de-provisioning of staff users).
sends mails destinated for root to a central location.
provides a local mailer.

Hostnames

Hostnames exist to identify every part of your infrastructure uniquely. They are used to refer to systems in your configurations and in discussions. You should think about a naming convention, but here are some rough guidelines.

Hostnames …

have to be unique.
have to end with a number, which should never be reused and always be incremented.

Services

A service is considered as everything running on a server’s operating system, to provide continuous functionality (e.g. a script or an application).

A service…

does only log errors and auditing information. Application services may as well log more information (e.g. Apache access log).
has defined log retention times.
logs to syslog unless it’s not possible.
is authenticating only on secure connections.
has an adequate and future-proof dimensioned datastore.
was deployed in a reproducible way.

Networks

A network is considered any part of infrastructure, which is used to interconnect servers or systems. (Layer 1,2,3,4,…)

A Network…

has clear entry and routing points.
has a diagram which describes access vectors, the logical and physical setup.
is deployed in adequate and future-proof dimensions (vlans, ip addresses, bandwidth).
uses structured cabling.
there is no cross-cabling, except for very rare situations (e.g. HA cabling).

should not be used for multiple purposes at least not share one of the following classifications.

Class	Description
net	Internet/upstream network
mgmt	Management network (monitoring, remote access)
traffic	Site local traffic network
backup	Traffic network for backups
voip	Voip Telephony network
clients	A network with client workstations.
devel	A network with development machines.
staging	A network with staging equipment.

OOBs are easy to reach, even in case of an outage.
VLAN-IDs are considered global, create a list.
All VLAN-IDs below 99 are switch-local.
VLANs have a name and a location.
All address space is considered global (vlans, ip- and mac addresses, including RFC1918)

To round up my article, here is a example checklist we use to peer review new systems:

Example Review Checklist

Every newly deployed host or instance should undergo a peer-review process. The checklist below will provide you with a couple of base acceptance criteria and is going to ensure a certain level of quality. Give it to any other sysadmin and ask him or her to check the system, before it’s put into production.

* DNS works (including reverse dns)               :
* SSH login works                                 :
* Host+services monitored                         :
* Host+services graphed                           :
* All Filesystems backuped                        :
* Database dumps                                  :
* All Updates installed                           :
* Host in HostDoc                                 : 
* Puppet works                                    :
* Time is accurate                                :
* Root mails are being delivered                  :
* Firewall is active                              :
* No unneeded services are reachable (nmap)       :
* Network configuration works (+ipv6)             :
* Syslog/dmesg/oob logs are clean of errors       :

-- Physical Host --

* Root password documented                        :
* Root login works                                :
* OOB password documented                         :
* OOB login works                                 :
* OOB monitored                                   :
* Switch ports are labeled (+ documented)         :
* Hardware is labeled (+ documented in rack docu) :
* Firmware up to date                             :
* RAID level is > 1 and all disks OK              :

OpenVZ API

2011-10-26T13:10:00+02:00

I love OpenVZ, I think its one of the easiest to use virtualisation technologies on the market and it adds almost no overhead compared to other technologies.

I’ve been using it for a couple of years now and I always wanted to have a nicer way to automate container creation, configuration or actions than writing shell scripts. There are already a couple of webinterfaces around, but none of them I liked.

Another possibility would be to use libvirt - but libvirt always felt a bit too complex, since its a general API implementation for several hypervisors.

So I started to implement my own API, which should rather be a simple and minimalistic approach. The project is hosted on GitHub but you can as well install it by Rubygems.

Get ruby-openvz

Installing

 $ gem install openvz

Example: Restart

 require 'rubygems'
 require 'openvz'

 container = OpenVZ::Container.new('109')
 container.restart

Example: Provisioning

Here is the example of how a whole provisioning for a new container could look like:

 require 'rubygems'
 require 'openvz'

 container = OpenVZ::Container.new('110')

 container.create( :ostemplate => 'debain-6.0-boostrap',
                   :config     => 'vps.basic' )

 container.deboostrap( :dist   => 'squeeze',
                       :mirror => 'http://cdn.debian.net/debian' )

 container.set( :nameserver => '8.8.8.8',
                :ipadd      => '10.0.0.2',
                :hostname   => 'foo.ono.at' )

 container.start

 # Update the system
 container.command('aptitude update ; aptitude -y upgrade ; apt-key update')

 # Install puppet
 container.command('aptitude -o Aptitude::Cmdline::ignore-trust-violations=true -y install puppet')

 # Install puppet
 container.command('puppetd -t --server=puppet.ono.at')

The first version is basically able to replace the provisioning scripts I’ve been using for a while. In future versions I’d probably like to integrate this into mcollective and puppet to orchestrate my machines. :-)

Upgrading HP Firmware

2011-03-03T08:12:00+01:00

Lately we bought a new HP blade chassis to replace a customer’s old database server. All it’s services run on ~15 blades, splitted cross two HP C7000 chassis.

The Proliant BL460 G6 we bought came with much newer firmware revisions than all the existing G1 – part of the infrastructure didn’t receive much sysadmin love over quite some time. :-)

Blades, ILO, chassis and controllers where all running way outdated firmware and upgrading was highly recommended. The arising firmware combinations haven’t been tested and the new blade wouldn’t even be detected, so HP. They offered us an upgrade for about $2000 and 6 hours of downtime per chassis.

Here are some handsome findings, to do the upgrade on your own:

HP Firmware Comapatibility Matrix

HP tested certain sets of firmware for compatibility. Take a look at their compatibility matrix and try to stay within the tested boundaries. This could mean to upgrade in more than one step, if you are running an older release.

(http://h18004.www1.hp.com/products/blades/components/c-class.html)

Hp-Firmware-Catalog

There is Christian Hofstedtlers great firmware upgrade script, which automatically downloads the latest and greatest HP firmware installation packages. Its even creating softlinks, to reference cryptic firmware package names to their corresponding hardware components.

(https://github.com/zeha/hp-firmware-catalog)

You can run them from your OS as an online upgrade. Certain components still might require rebooting, to finish the “delayed upgrade”.

I would love to see HP maintaining this, since the approach provides a good example of providing customers with a modern and automated way to upgrade and monitor firmware for more recent releases.

ILO Shell

When upgrading many machines it will save you a lot of time, if you just use the SSH shell for configuring a boot device and rebooting the server.

Connect to ILO by SSH

Make sure you send the right username, AFAIK it’s case sensitive on the ILO:

     ssh phx-vnode03.oob.ono.at -l Administrator

Set an ILO Advanced Licence key

     cd /map1
     set license=YOUR-LICENCE-KEY

The advanced licence key is required to enable virtual device firmware features. Eg. to make use of the remote console or a virtual disk boot drive.

Mount and configure a network hosted ISO image as boot device

     cd /map1
     vm cdrom insert http://10.0.10.21/FW920B.2010_1129.2.iso
     vm cdrom set boot_always

…be it a firmware upgrade or an OS installation disk. Make sure you run the following command to “eject” it again:

     cd /map1
     vm cdrom eject

Monitoring

To please your monitoring system as well, check out check_mk. They wrote a couple of good SNMP checks for your HP or IBM bladecenter.

In the end I can highly recommend to keep your hardware firmware up to date. At least HP, my vendor of choice, they add a lot of useful bug fixes.

HP currently informs customers by a e-mail newsletter about updates, I would love to see this in my monitoring system too, like all the other security upgrades.

Try to plan the upgrade a bit or use existing downtimes to boot the HP Firmware Maintenance image.

munin-host-rename

2011-02-16T10:32:00+01:00

Recently we decided upon a new host naming convention for our infrastructure at my $dayjob. So I will soon be renaming a few hosts.

I noticed that munin still doesn’t provide an easy way, to rename an existing node without losing historical data. So I wrote a small shell script which does that for me and might be of use to everybody else in the same situation.

Download munin-host-rename

Synchronize Puppet with Git

2010-12-22T18:29:00+01:00

Download Puppet-Sync

Puppet really shines at automating infrastructures. You will notice a sudden change of working methodology, once you manage the first systems with it.

Instead of manually logging on to each single system for updating a certain part of configuration by issuing shell commands, you will stop to repeat yourself and just update a single piece of code, which describes the desired config state for all systems.

As recommended in the Puppet documentation you are well advised to keep your Puppet manifests under revision control.

I wrote a small script which will come in handy, to ease your life with keeping your repository and the manifests on the master in sync and should fit to most of the environments out there.

Once installed, you can store the manifests for each Puppet environment in its own GIT branch and every time you commit a new version to one of your branches, it will automatically sync the most recent version and inform the Puppet master process.

BTW. this could also be used to keep the manifests on multiple Puppet instances in sync.

Puppet-Sync

Puppet-sync is a Ruby based command line tool to synchronize every commit from a central GIT repository to your Puppet master instance. You should install it on your Puppet master and configure a GIT hook which calls the script over ssh.

Puppet-sync takes some parameters to specify how the environment on the master looks like. Run it with ’–help’ to get a list of available options. Here is an example:

puppet-sync --branch master \
            --passenger     \
            --destination /etc/puppet/environments \
            --repository ssh+git://git.ono.at/srv/git/puppet.git

By running the command above, the script connects to the git repository, fetches the manifests from the master branch and puts it into /etc/puppet/environments/production. Since we use the master branch for production, I added the logic to translate “master”-branch to “production”-environment.

Installation on the master

Instead of listing each and every shell command needed to install the environment for the script, I’d like to provide a simple manifest instead. I think this is more readable and you can either use it or figure out the appropriate shell commands. ;-)

file { "/usr/local/bin/pupept-sync":
    ensure  => present,
    source  => "file:///puppet-sync",
}

file { "/home/psync/.ssh":
    ensure  => directory,
    owner   => "psync",
    mode    => 700,
    require => User["psync"],
}

file { "/etc/puppet/environments":
    ensure  => directory,
    owner   => "psync",
    mode    => 775,
    require => User["psync"],
}

user { "psync":
    ensure     => present,
    home       => "/home/psync"
    managehome => true,
}

ssh_authorized_key { "puppet-sync-ssh-key":
    ensure  => present,
    key     => "AAAAB3.....lVBp0nPLNcs=",
    type    => "ssh-rsa"
    user    => "psync",
    require => File["${homeroot}/$name/.ssh"],
}

I have the following configuration in my puppet.conf to make puppet aware of each of the directories in /etc/environments:

...
[master]
.....
templatedir = /etc/puppet/environments/$environment/
modulepath  = /etc/puppet/environments/$environment/modules/
manifest    = /etc/puppet/environments/$environment/manifests/site.pp
manifestdir = /etc/puppet/environments/$environment/manifests

Git Hook

The only thing left is to create a Git Hook in your repository. Here is the one i use. I also created a psync user on the master, so i just need to store the private ssh key in psync’s home directory.

#!/bin/sh
#
# An example hook script to prepare a packed repository for use over
# dumb transports.
#
# To enable this hook, make this file executable by "chmod +x post-update".

branch=`echo $1 | awk -F/ {'print $3'}`

sudo -u psync ssh puppet.ono.at /usr/local/bin/puppet-sync \
                                       --passenger         \
                                       --branch $branch

exec git-update-server-info

Perfect its installed and you are ready to use it. Go ahead an try to commit a new version.

Monitoring Puppet and Bacula

2010-12-07T17:51:00+01:00

Download CheckMK Plugins

Rescently I blogged about my CheckMK APT plugin, capable of checking for upgradeable packages.

Meanwhile I wrote two more plugins, both adopting existing checks and migrated all plugins into one single ‘checkmk’ repository over at GitHub.

bacula

This check adapts the idea of Bernhard Miklautz bacula-utils. The plugin will define four different services to be monitored on each Bacula server:

bacula.errorvols

Checks the state of available backup volumes and will report critical, if errounos volumes are found. In case of an error, it will as well return the names of these volumes.

Use the bacula-clear-errvols script to resolve these issues.
bacula.freshness

Checks whether all clients have an associated backup within the last 30 hours.
bacula.fullbackups

Checks whether all clients have an associated full-backup.
bacula.fullbackupspool

Checks whether any volumes used for full-backups come from a full-backup pool.

puppet

The second plugin will monitor the status of the puppet agent. It integrates nicely with puppetstatus.py. This script was initially written by TMZ from the Fedora Infrastructure Team and can be used to enable or disable the puppet agent on a specific host.

You are able to disable Puppet on a server, by running the following command:

 sudo puppetstatus -d "Interesting things are about to happen."

The monitoring system will change the state of the Puppet check to WARNING and will display this message and the username of the person who was disabling the agent.

When the agent is not disabled on a host, the check will just change to WARNING after 3 and to CRITICAL after 4 hours.

I’d be glad to get some feedback on my plugins, please report any bugs by sending me an e-mail or leave a comment below.

Puppet+Capistrano

2010-11-25T19:31:00+01:00

I’m currently working on our upgrade to Puppet 2.6. One of the ideas I came up with was to deploy our puppet manifests (which we already store in a GIT repository) using Capistrano.

For those who don’t know Capistrano already: Capistrano is a Ruby based deployment tool, used to get application code from a source control system to your application servers. Initially Capistrano was written to deploy Ruby on Rails applications. Meanwhile they also provide a ‘railsless-deploy’ module, which can be used to deploy any other code or framework.

What I like most about Capistrano, is that you don’t have to install it on your servers. It’s designed to read a couple of instructions from a “Capfile” which resides in the top directory of your application code. Once you trigger the deployment of a release, it will connect to your servers using SSH and trigger commands to deploy your Puppet manifests.

Important for all of this to work propperly is a SSH setup which uses public keys for authentication.

Capistrano will connect to the Puppet master and issue GIT commands against your GIT server. So not only password-less authentication to the puppet server must work, but also connecting from a shell on the Puppet server to the GIT server.

Installation

Capistrano is distrubuted as a ruby gem. If your distribution does already provide a package, use it. Otherwise you can simply use rubygems.

  gem install capistrano

Capify

Next up copy the Capfile below, to your Puppet top level directory. Here is how it should look like:

  ls -l puppet/
  -rw-r--r--   1 sts sts  1499 Nov 26 10:33 Capfile
  -rw-r--r--   1 sts sts  1464 Nov  9 20:02 README
  -rw-r--r--   1 sts sts   907 Nov  9 20:04 TODO
  drwxr-xr-x   6 sts sts   204 Nov  9 20:02 manifests
  drwxr-xr-x  42 sts sts  1428 Nov 22 11:04 modules

There are some variables you need to change in order to make it work with your setup. Basically look through all lines which start with “set” and ajust them according to your needs.

Basically Capistrano is going to do the following:

Connect to your puppet server.
Create a directory for the release eg. /etc/puppet/git/#{:branch}/releases/20101125203021.
Checkout the HEAD of the specified GIT branch to this directory, by connecting from your Puppet server, to your GIT server using SSH.
Ajust the symlink from /etc/puppet/git/#{:branch}/current to point to the new release.
Tell Fusion Passenger to reload the application code by creating the following file: /usr/share/puppet/rack/puppetmasterd/tmp/restart.txt

require 'railsless-deploy'
require 'net/smtp'

set :application,     "puppet"
set :user,            "root"
set :use_sudo,        true
set :group_writebale, false
set :deploy_to,       "/etc/puppet/git/#{:branch}"
set :keep_releases,   2

set :scm,         "git"
set :repository,  "git+ssh://sts@git.ono.at/srv/git/#{application}.git"
set :branch,      "master"

role :app, "puppet.ono.at"

namespace :deploy do

    task :default do
        update
        cleanup
    end

    task :notify do
        changes_list = "puppet-changes@ono.at"
        user_name    = `git config user.name`.strip
        user_email   = `git config user.email`.strip
        commits      = `git log --pretty=oneline --abbrev-commit #{previous_revision}..#{current_revision}`.strip

        msg          = <<EOM
From: "#{user_name}" <#{user_email}>
To: #{changes_list}
Subject: [puppet] deployed #{release_name}.

The following changes where just pushed to puppet by #{user_name}:

  Branch  : #{:branch}
  Release : #{release}
  Server  : #{:app}

Applied Commits /////////////////////////////////////////////// ///////

#{commits}

If you want to revert this release, please run:

 $ cap deploy:rollback

Cheers,
Capistrano.
EOM

        Net::SMTP.start('localhost') do |smtp|
             smtp.send_message msg, user_email, changes_list
        end
    end

    dec "Restart Puppetmaster"
    task :restart, :roles => :app do
        run "touch /usr/share/puppet/rack/puppetmasterd/tmp/restart.txt"
    end
end

Configure GIT

Please also make sure you configure GIT with your name and e-mail address. Capistrano will read these from your git configuration to send out notification e-mails.

    git config --global --add user.name "CHANGE-ME"
    git config --glibal --add user.email "CHANGE-ME"

Go

You should be able to deploy updates to your Puppet servers using the following command:

  cap deploy

Future enhancements

If you’ve got any ideas or see a way to enhance this process, I’d be glad if you leave me a comment. :-)

APT Plugin for CHECK_MK

2010-10-10T10:10:00+02:00

We are using Check_MK for monitoring at work. It features a quite nice replacement for NRPE agents and automatic Nagios configuration generation.

I wrote an APT Plugin which will refresh the package cache on every agent, every 60 minutes and check for new Debian upgrades or security updates. Depending on the severity it will return different Nagios status codes:

OK - No upgrades are available.
WARNING - Only non-security upgrades are available.
CRITICAL - Security upgrades are available (might also involve normal upgrades).

its hosted at GitHub.

Agent installation

Install the python-apt package and copy plugins/apt to your servers. You would properly want to add this to puppet.

  aptitude install python-apt
  git clone git://github.com/sts/checkmk-apt.git
  checkmk-apt/plugins/apt /usr/lib/check_mk_agent/plugins/apt
  chmod a+x /usr/lib/check_mk_agent/plugins/apt

Installing on your Nagios Server

Copy checks/apt to your checks directory and run a Check_MK inventarize and config update.

  git clone git://github.com/sts/checkmk-apt.git
  cp  checkmk-apt/checks/apt /usr/local/share/check_mk/scripts/
  chmod a+x /usr/local/share/check_mk/scripts/apt

  # Check_MK Inventory+Generate Nagios Configuration
  check_mk -I alltcp
  check_mk -U
  invoke-rc.d nagios3 restart

Puppet+Passenger

2010-08-31T21:09:00+02:00

Puppet is a configuration management tool, its been under heavy development for almost five years now. It became a major open source project in the last few years, surrounded by a large community.

In most of the current environments Puppet Masters will either run on webrick or for the larger environments mongrel was quite standard for a while now.

But Puppet is as well able to be run from within Apache or Nginx. Then you would be using mod_rails (aka. Phusion Passenger). This solution is known to scale best, but was always a bit bulky to install.

Debian’s Puppet package maintainers have prepared the puppetmaster package in Squeeze for an easy installation with mod_rails, so I think this could get the new standard way to install the puppet server.

Rescently the Debian project announced the freeze on its testing branch (codename “Squeeze”) which in consequence means that: no more new features will be added and all work will be consentrated on polishing testing up to production level.

I thought it to be a good time then to prepare the “Squeeze” upgrade of my puppet servers and write a short article about it.

Install the packages

  aptitude install puppetmaster libapache2-mod-passenger

Enable the Apache Modules

  a2enmod headers
  a2enmod ssl

Manually change config.ru

Update: Meanwhile you can skip this step.

I had to manually fix the Rackup-file which comes with the squeeze puppetmaster package. This file contains logic for initializing puppetmaster as a rack application. It still tries to initialize puppetmaster, although the puppet server component was renamed to master.
There is already a open Debian bug for this, and should get fixed until the final release. See bug #593557

Now change /usr/share/puppet/rack/puppetmasterd/config.ru to:

  # a config.ru, for use with every rack-compatible webserver.
  # SSL needs to be handled outside this, though.
  
  # if puppet is not in your RUBYLIB:
  # $:.unshift('/opt/puppet/lib')
  
  $0 = "puppetmasterd"
  require 'puppet'
  
  # if you want debugging:
  # ARGV &lt;&lt; "--debug"
  
  ARGV &lt;&lt; "--rack"
  require 'puppet/application/master'
  # we're usually running inside a Rack::Builder.new {} block,
  # therefore we need to call run *here*.
  run Puppet::Application[:master].run

Configure Puppet

When you lounch Puppet the first time, it will generate the SSL certificates. Make sure you configured the puppet certname option to fit your hostname.

If puppetmaster started before you configured it, you can simply delete the ssl directory (/var/lib/puppet/ssl) and restart the puppet master. It will regenerate the directory automatically.

The following represents my puppet configuration in /etc/puppet/puppet.conf.

  [main]
  logdir=/var/log/puppet
  vardir=/var/lib/puppet
  ssldir=/var/lib/puppet/ssl
  rundir=/var/run/puppet
  factpath=$vardir/lib/facter
  templatedir=$confdir/templates
  
  [master]
  certname=puppet.ono.at
  ssl_client_header=SSL_CLIENT_S_DN
  ssl_client_verify_header=SSL_CLIENT_VERIFY      

  [agent]
  server=puppet.ono.at

  [cert]
  autosign=false

After the certificates are generated, you should disable the puppetmaster daemon in /etc/default/puppetmaster by setting $START from yes to no.

Apache Configuration

Finally configure an Apache virtual host to listen on port 8140 and point it to the ssl certificates generated by puppet. Put the following configuration in /etc/apache2/sites-available/puppetmaster:

  ## Puppetmaster Apache Vhost Configuration
  
  ## Passenger Limits
  PassengerHighPerformance   on
  PassengerMaxPoolSize       12
  PassengerPoolIdleTime    1500
  # PassengerMaxRequests   1000
  PassengerStatThrottleRate 120
  RackAutoDetect            Off
  RailsAutoDetect           Off
  
  Listen 8140
  
  <VirtualHost *:8140>
     ServerName puppet.ono.at
  
     SSLEngine on
     SSLCipherSuite SSLv2:-LOW:-EXPORT:RC4+RSA
  
     SSLCertificateFile      /var/lib/puppet/ssl/certs/puppet.ono.at.pem
     SSLCertificateKeyFile   /var/lib/puppet/ssl/private_keys/puppet.ono.at.pem
     SSLCertificateChainFile /var/lib/puppet/ssl/ca/ca_crt.pem
     SSLCACertificateFile    /var/lib/puppet/ssl/ca/ca_crt.pem
  
     ## CRL checking should be enabled; if you have problems with
     ## Apache complaining about the CRL, disable the next line
     SSLCARevocationFile     /var/lib/puppet/ssl/ca/ca_crl.pem
     SSLVerifyClient         optional
     SSLVerifyDepth          1
     SSLOptions              +StdEnvVars
  
     ## The following client headers allow the same configuration
     ## to work with Pound.
     RequestHeader set X-SSL-Subject %{SSL_CLIENT_S_DN}e
     RequestHeader set X-Client-DN %{SSL_CLIENT_S_DN}e
     RequestHeader set X-Client-Verify %{SSL_CLIENT_VERIFY}e
  
     RackAutoDetect On
  
     DocumentRoot /usr/share/puppet/rack/puppetmasterd/public
  
     <Directory "/usr/share/puppet/rack/puppetmasterd">
         Options None
         AllowOverride None
         Order allow,deny
         allow from all
     </Directory>
  </VirtualHost>

Now enable the virtual host configuration, enable all required modules and restart the Apache daemon:

  a2ensite puppetmaster
  a2enmod header
  a2enmode passenger
  apache2ctl configtest
  apache2ctl restart

Final Step - Test

After everything is in place, please test your setup. Open up a web browser and point it to the following Url [adapt the hostname]:

https://puppet.ono.at:8140

You should see a line stating:

“The environment must be purely alphanumeric, not ””

Happy Birthday!

2010-08-16T15:12:00+02:00

I was a bit surprised when I opened my inbox today. Today is my birthday, but today is also Debian’s Birthday! thank.debian.net
Happy Birthday Debian!