The recent release of an x509 security provider for MCollective has motivated me to do some more work on the mcollective cookbook. Although it worked well enough to play around with, the configuration was not especially flexible and the cookbook did not lend itself to wrapping.

MCollective 1.2 was the current release when I originally wrote the cookbook, and the configuration reflected that. New features introduced in later releases of MCollective weren’t enabled - it worked, but not at its best. The configuration defaults now reflect MCollective 2.2.

Configuration is almost entirely parameterised. If you have need to override the cookbook’s templates to implement your configuration, I’d like to improve this further.

The MCollective “identity” is now configurable via an attribute, but continues to default to node['fqdn']. When your node name and your identity match, you can use the chef-server discovery plugin - so this default may change in the next major release.

Version 0.11.0 of the cookbook is now available on the community site and on Github. If you find it doesn’t do what you need, or you have suggestions to improve it, please open issues on github.

Last year, Venda released a project to create and manage a simple x509 PKI using Chef and Chris Andrews introduced it with his blog post, “Deploying a PKI With Chef”.

A few people tried out it out after the initial release (and submitted patches or bug reports - thankyou!), and it has since been renamed to become the x509 cookbook, which you can find on the community site or on github.

I’ve found it useful of late, so let’s take another look.

What’s The Problem?

You’ve decided to SSL-enable one of your internal services, and that means you need an x509 certificate. The cheapest and easiest option is to generate a self-signed certificate, but this option is not without drawbacks.

When you connect to a service using a self-signed certificate, you can be confident that your communication is encrypted, but you can’t be sure who you’re communicating with. You are protected from attackers “sniffing” data from an insecure network, but not from attackers creating a fake service in front of the one you expect to connect to (a man-in-the-middle attack).

It’s also annoying to users, as most software will (rightly!) warn you that self-signed certificates are not to be trusted.

A better option is to run an internal Certificate Authority, and use that to sign the certificates for your SSL-enabled services. You can import your CA’s certificate into your browser (or OS), which will then trust services using certificates that it has signed.

It’s not hard to make your own CA, but getting a signed certificate for your service necessarily involves a number of steps:

1. On the host, generate a secret key and a certificate signing request (CSR)
2. Get the CSR to the internal CA
3. Create a signed certificate using the CSR and the internal CA
4. Get the signed certificate to the host
5. Install the signed certificate

Venda wanted to automate this process and the result is the x509 cookbook, and the chef-ssl-client gem.

I recently needed to run 32-bit Perl 5.8 on a 64-bit Centos 6 system. Initial research suggested that perlbrew would be the easiest way of achieving this, but I wasn’t able to find a walkthrough.

Here’s what worked for me…

1. Install perlbrew

You’ll need to install perlbrew from the CPAN, and it has a load of dependencies. The wonderful App::cpanminus makes this experience as painless as possible, so I installed it before moving onto perlbrew itself.

1
2
3

$ sudo yum install perl-CPAN
$ sudo cpan App::cpanminus
$ sudo cpanm install App::perlbrew

1. Initialise perlbrew

Next, get perlbrew ready for use. Pay attention to the output of the init step - it will direct you to make a change to your shell configuration.

1
2

$ perlbrew init
$ perlbrew install-patchperl

2. Install 32-bit Libraries

Installing these two packages was enough to build a 32-bit perl core. If you’re building additional XS modules against the 32-bit perl, they may require other 32-bit libraries to be installed.

1

$ sudo yum install glibc-devel.i686 libgcc.i686

3. Build A Perl

1
2
3
4
5
6
7
8
9

$ perlbrew install 5.8.9 -Accflags="-m32 -march=i686" -Aldflags="-m32 -march=i686" -Alddlflags="-shared -m32 -march=i686"
Fetching perl-5.8.9 as /home/zts/perl5/perlbrew/dists/perl-5.8.9.tar.bz2
Installing /home/zts/perl5/perlbrew/build/perl-5.8.9 into ~/perl5/perlbrew/perls/perl-5.8.9

This could take a while. You can run the following command on another shell to track the status:

  tail -f ~/perl5/perlbrew/build.perl-5.8.9.log

perl-5.8.9 is successfully installed.

That’s all there is to it, though the result isn’t quite perfect. While the above invocation builds a 32-bit perl, it doesn’t override the system’s archname - so the resulting @INC looks like this:

1
2
3
4
5
6

@INC:
    /home/zts/perl5/perlbrew/perls/perl-5.8.9/lib/5.8.9/x86_64-linux
    /home/zts/perl5/perlbrew/perls/perl-5.8.9/lib/5.8.9
    /home/zts/perl5/perlbrew/perls/perl-5.8.9/lib/site_perl/5.8.9/x86_64-linux
    /home/zts/perl5/perlbrew/perls/perl-5.8.9/lib/site_perl/5.8.9
    .

For my purposes, this is simply an aesthetic issue - the x86_64-linux directories contain 32-bit shared objects - and I chose not to spend any more time perfecting it. If you happen to know which option(s) I’m missing, please leave a comment below.

I recently attempted to use Chef to configure several VMs with software I wanted to play with. My goal only went as far as provisioning a minimally useful instance of each application - it didn’t need to be production-ready, but it did need to start.

The applications were:

• Jenkins, a CI tool written in Java,
• Graphite, graphing tool written in Python, and,
• Sensu, a monitoring tool written in Ruby.

Additionally, Sensu requires:

• RabbitMQ, a message broker written in Erlang, and,
• Redis, a key-value store written in C.

None of the dependencies are particular esoteric in a modern environment, though the variety seen here underscores the need for good configuration management. The guest OS was Ubuntu 12.04, as many community-contributed Chef cookbooks prefer or require Ubuntu and I wanted things to proceed as smoothly as possible.

In an earlier post describing my PPTP VPN configuration, one reason I gave for my use of the (relatively) insecure protocol was that the IPsec alternative appeared to require building updated versions of the software. I’m delighted to report that that’s no longer the case.

The versions of openswan and xl2tpd shipping with Ubuntu 12.04 (precise) are more recent than those mentioned in the elderly walkthroughs I’d found, and have worked for the OS X clients I’m using.

It’s very easy to configure a machine as a KVM host these days. Modern releases of Ubuntu and Centos both offer simple installation methods that provide a useful system with minimal configuration.

Creating guests is a different story. A number of good tools are available, supporting a huge variety of installation scenarios. While it’s reassuring to know you won’t be limited by your tools, it can be a frustrating experience when you’re just getting started.

This post shows how ubuntu-vm-builder can be used to go from zero to fully-installed Chef client in under 2 minutes.

First things first: PPTP, as a protocol, has a number of serious security issues. As a general rule, don’t use it. I’m aware of the risks, and am accepting them for this implementation.

PPTP’s main advantage is that it’s very easy to configure. I briefly investigated the state of IPsec/L2TP, and found a lot of advice to build things from source because the distro packaged versions are too old. That’s fine advice, but I wanted to get something started quickly. Once I’ve built a build box, I’ll be revisiting this decision.

We’ve been building out a new development environment at work - virtualised using KVM, and managed with Chef and MCollective. It has made it so easy to try out new things that I found myself wishing I had the same facilities for my own projects.

An article on Hacker News had me taking another look at Hetzner, which was followed a few days later by an order for a dedicated server with a quad-core i7, 32GB memory, and a pair of 3TB SATA disks. Hetzner gets mixed reviews, but the negatives weren’t enough to put me off - the prices are good, and I’m not planning to host any critical services. I’ll try not to complain when I get what I pay for.

The rest of this post describes the initial configuration of the server for use as a KVM host.

A common configuration management pattern is to generate snippets of configuration into a “.d” directory, which are subsequently compiled into a complete configuration - either by a script, or through support from the application itself.

This pattern works well when you’re maintaining a set of snippets, or adding to it, but removing snippets from the set can present a challenge. If you need to specifically remove a snippet from a node, you can always use the File resource with action :delete to do so. But what do you do if you don’t know which snippets need to be removed?

Starting

I switched to Emacs sometime in 2009. At the time, I was using TextMate most of the time (though diving frequently into vi, as befitting my background as a system administrator). There wasn’t any singular event that drove me to try out Emacs, but I do remember being frustrated by TextMate’s performance with a particularly large project at work. I’d noticed Emacs-using colleagues having a much better time of things, and some stories about Emacs on Hacker News had piqued my interest.

The learning curve was initially quite steep, which presented something of a challenge - I needed to use the tool to get work done, and couldn’t afford to significantly slow myself down for an unknown period. I bought PeepCode’s “Meet Emacs” screencast to see a quick introduction to the essential features, and get a handle on my ignorance. It’s important to know what you don’t know, and the screencast helped me reach “conscious competence” quickly enough to stick with it.

Following the advice in “Meet Emacs”, I used the Emacs Starter Kit for my initial configuration. It was awesome. More awesome than I could comprehend; despite spending time poking around the contents of my new ~/.emacs.d, only the most superficial aspects of the configuration made much sense. I had an editor that was powerful and feature-rich, but the much-vaunted malleability of the Emacs environment lay beyond my grasp.

Fortunately, my earlier switch to OS X had brought with it a certain serenity in the face of technology. If an opinionated application (or OS) does what you want, most of the time, it’s worth going along with it in the places you disagree. That this is largely antithetical to the Emacs view of the world is not lost on me.

So, I spent my first couple of years with Emacs using a barely-customised ESK configuration, and I was pretty happy with it. While missing some of vi’s functionality, I choose not to install any vi-compatibility features. The lynch-pin of my commitment turned out to be magit, the excellent git mode for Emacs. Having become accustomed to such seamless interaction with my VCS, I can no longer imagine working without it.

Restarting

Though I was largely happy with the end result, the amount of magic (or sufficiently advanced technology) bothered me. Nor was this entirely academic - I had been putting up with a bunch of quirks I was sure could be fixed, if only I knew how. Last week, I came across the article that helped me start down that road.

“Emacs Configuration Rewrite” documents Steven Danna’s experience rebuilding his Emacs configuration from scratch. The result is positively minimalist alongside ESK, and lacks many features and customisations the latter delivers “out of the box”. I decided that probably didn’t matter to me - after all, if I missed something enough to add it back in, that would simply drive me to learn how to do that. Above all else, Steven’s configuration showed me that I could start out with something I could comprehend completely, and expand from there. So that’s what I did.

The initial commit to my emacs configuration repo doesn’t tweak anything - it simply introduces the skeleton that everything else hangs off. I’ve added one thing at a time as I’ve needed it, and understood it. That’s not to say it’s entirely (or even mostly) original work - I’ve picked things up from various places, but they only go into my config when I understand what they do. No blind copy-and-paste, no cargo cults.

Emacs makes this exercise pretty easy. The built-in help can give you the value and meaning of any variable (C-h v), and the documentation for any function (C-h f). For anything implemented in elisp (and that’s nearly everything), you can even jump straight to the source. This was way too much to deal with when I first started using Emacs, but I regret leaving it so long to come back to it.

The Future

I don’t like unnecessary wheel reinvention. My goal is to understand how things fit together, that I might change them according to my needs - I don’t feel that meeting that goal demands personally entering every single sexp into my Emacs configuration.

The Emacs Starter Kit has evolved considerably since I made a personal fork in 2009, and I made no attempt to evolve my forked configuration with it. It contains lots of good stuff, and I’ve started to look more closely at exactly how it’s put together. As my understanding grows, I expect to be able to reuse larger pieces of elisp (from ESK and elsewhere) without feeling that my configuration is outgrowing my competence.

I may move to an ESK-based configuration again in the future, and I’m glad I used one in the past. In the present, I’m appreciating a greater understanding of a smaller set of features.