If this makes sense to you, HELP, otherwise, nothing to see here, move along.
I’m trying to simplify the task of configuring and maintaining Linux servers at work and I want to build on some existing configuration management system to do so. We are using Ubuntu Linux distribution, and I was thinking of just building on the APT package management tools they’ve borrowed (among other things) from Debian, but I decided to look for something distro agnostic.
I’ve spent a lot of time and frustration the last day trying to get the server working for Chef, a new system written in Ruby. I spent time scanning their bugtracker and asking for help in their IRC group to no avail. It still doesn’t work, and I have no more idea why than when I started.
I’m really doubting my decision:
- Chef has only been packaged for the bleeding edge version of Ubuntu. Um yeah, great, I really want to use beta software on my SERVERS.
- The installation documemtation advises that I dowload and install Ruby Gems from a tarball becuase the version in the Ubuntu repositories isn’t to their liking. Great, I have to install extra shit by hand before I can use the software I want to use so I don’t have to install shit by hand. That’s efficient, right?
- Chef relies on OpenID for authentication. Sweet! I can use my MySpace account to manage my servers! Well, I could, if only I could figure out the appropriate URL for the myspace authentication endpoint (and I was batshit insane). As for how I integrate OpenID authentication with anything else I’m using, I’m sure it will be easy and obvious what to do, in a year or two.
- Oh yeah, I forgot the most important thing: It doesn’t work. At least it doesn’t work for me. I’ve installed all the prerequisites, I’ve run their “installer,” and I can even get to the login page of “chef-server” but when I actually try to log in, it falls down and goes BOOM. I get a generic error page warning me about a socket error. I tried to diagnose it myself to no avail, there wasn’t anything in the log files because…
- Chef server truncates its log files willy nilly. It actually writes a fair amount of info to its log file, but you’d never know by looking at it after the fact, because after every request, it ends up as a zero-length file. Useful, huh? The trick is to ‘tail -F’ the file before restarting chef-server. This prints the output as it is written to the file, and reopens the file each time it gets truncated, which happens multiple times during the request.
- For what it is worth, I figured out what was wrong here, for some bizzarre reason, the hosts file on the machine was only readable by root, which casued lookups for localhost to fail when chef-server was trying to connect to the couchDB server.
Now, to be fair, the Chef site makes it clear in a nice green sidebar that Chef is young and a work in progress. I knew that when I started with it. I didn’t expect it to be production ready, but I thought it was far enough along to start working with. Clearly, I’m reconsidering that.
I’m also reconsidering the assumption that sent me to Chef in the first place, that it was desirable, at this point, not to take a dependancy on a specific Linux distribution by trying to build off of APT, the package distribution and management system at the heart of Debian and Ubuntu. The truth is APT is awesome. One of the reasons given for creating Chef was that Puppet, an earlier Ruby-based configuration management system choked on dependancy management. I haven’t seen that complaint about APT, not lately, in fact, that’s one of the things they love most about Debian and Ubuntu, people love it so much that say things like “I want apt to bear my children,” or words to that effect.
So, my thought is that I create my own apt repository. I’ll create derivates of the ubuntu packages I need custom versions of, and I’ll create configuration packages derived from their configuration packages whenever possible. Machine and role specific packages can be used to manage rollouts and/or I can different repository tiers for different classes of servers, in much the same way that Debian and Ubuntu have different tiers for testing, stable, unstable, etc. I’m sure I’ll run in to headaches on the way, but it least they will be headaches that other people have suffered and I can learn from their experience.