Hypermagnet

I’m Using Puppet All the Time!

Puppet is working out really well for me. I run a small technology company and administer lots of computers, and I regret not setting up Puppet many moons ago.

I started work on Hypermagnet to take care of configuration templates awhile back, but I haven’t gotten there with puppet yet. I am, however, using YoDNSconf with puppet quite often. I use YoDNSconf to manage all my private hostnames so it was an easy addition to include which puppet classes to associate with each host.

Hypermagnet and Puppet will work together someday!

Client Hostname Specific File Serving

This is awesome. I’ve been hoping for functionality like this and I’m very pleased its so simple to use.

The Deets OK, I’ll be more specific. For quite some time I’ve relied upon ssh to login to remote servers and manually edit configuration files. Its a time intensive and error prone process, and most importantly, there are no systematic procedures involved, so there are no manageable assets built up over time!

It took me awhile, but I started to use Puppet to configure services on my network which all use the same configuration files. But what about services that use a different configuration on each host? I expected to variations:

  • Client host specific configuration files
  • Configuration file templates which can be customized for each client

Client Specific Files This is what I referred to as being easier than I thought:

class rsync {

    package { rsync: ensure => latest }

    file { "rsyncd.conf":
        name => "/etc/rsyncd.conf",
        owner => "root",
        group => "root",
        mode  => 644,
        source  => "puppet://fileserver.example.com/rsync/rsyncd.$hostname.conf",
        require => Package["rsync"],
    }

}

I’m surprised that the $hostname variable uses the host short name.

Configuration File Templates This would be sweet, but I haven’t figured out how to set it up yet. Looks like ERB is the way to go.

Migrating a Puppetmaster

I’ve just about finished up the process of migrating a puppetmaster server, and it was thankfully very easy.

I’d been using subversion to store the puppetmaster manifests, and the main problem I ran into was the same one which hung me up when I first setup puppet: hostnames!

To recap, the server hostname has to be the same reverse dns for the ip address. For example:

user@hostone:/home/user$ hostname
hostone.example.com

dig -x 192.168.123.123
hostone.example.com

Yes, that’s all paraphrased. To make things easier, I removed the existing certificates:

rm -rf /var/lib/puppet/ssl/

Config::Model

Config::Model - this looks very cool! It is a Perl project that aims to serve as an interactive configuration editor. I glanced over the docs and it appears to connect with Augeas to a certain degree.

I’m using Perl more and more these days so I’m going to give it a try. Let’s see if there is a debian package… YES! libconfig-model-perl. Nuff said.

Augeas

Thanks to my trying out Puppet, I learned about Augeas yesterday. It is a serious configuration management system. It pays to try new things out!

Augeas appears to use the concept of “lenses” to see into different configuration types. I get the feeling that “lenses” could also be described as very specific parsers. Doesn’t matter though, what they do is very cool!

For example, I used the augtool command line interface to load my /etc/hosts file. In doing so, augtool parsed the file into an object tree with nodes and values. This was very appropriate as only recently I was working on the host names portion of YoDNSConf when I think I finally figured out the relationship between hostnames and DNS. In augtool, when I printed the /etc/hosts configuration tree, it displays three nodes: ipaddr, canonical, and alias. Sweet, that’s good enough confirmation that my understanding of the /etc/hosts file is correct.

Please correct me if I’m wrong, but the first entry in the line for an ip is the canonical name, and the ones following are aliases. This was important to me as I wanted to also generate PTR records for unbound local-data from the same database. In the end, it all worked out.

But back to Augeas, the only issue I have with it at the moment is that its lacking PHP bindings at this time. It does have Ruby and Python bindings though, and since Puppet is written in Ruby and I’m still interested in learning more about Ruby, it might be a good thing. Like I said, it often pays off when I try new things.

Puppet

I finally tried out puppet, and I like it! Its very simple to get started, and it appears to run smoothly and able to grow incrementally, which is how I like to do and learn things.

One of the turn-offs that kept me away from puppet was the custom syntax it uses, but it turns out to be pretty smart. Since they are fairly sophisticated configuration files, it would make sense to generate them in a systematic manner. On top of that, it uses common machine and network data, which can be stored in a centralized database.

I’d also like to do the same for nagios configuration files - I just setup nagios3 on debian and I like the progress its made since nagios2. I’ll have to review nagiosQL to see how they do it.

Debexpo

Debexpo is coming along nicely! Its the Google SoC project by Johnny Lamb which is to make packages more socially browse-able. Although I haven’t tried it yet, the idea that my mind conjures up is a mix between Ohloh and packages.debian.org.

This is a great thing! I’ve been perusing the trac code browser - its written in python and follows an MVC structure, so I should be able to make sense of it eventually. :-)

Oh yeah - the link:

http://debexpo.workaround.org/trac/

It’s All About the Packages

Just a couple thoughts about package configuration:

  • Package parameters would be stored in a database
  • Configuration form hopefully powered by a single style sheet
  • Configuration output would be powered a few types of style sheets, with some exclusive snibbet style sheets

N.B. - There are several very cool projects for Debian listed in the GSOC2008:

http://wiki.debian.org/SummerOfCode2008