Cosine Jeremiah and his Musings

Know what Capistrano is? I did a presentation on it in February, so I know a little about it. At the time I was investigating it as a hopeful candidate that could assist with configuration management for general systems administration for an environment of about 150 Solaris systems. I discovered that Capistrano is a fantastic program and a great tool for application deployment. Honestly there is no reason you should ever put up with the act of moving an application to production being more than a few keystrokes, and using Capistrano makes that possible. However, Capistrano was unable to help out such a large Unix environment.

Capistrano has no facility for continuing tasks upon failure. In a large Unix environment, stuff needs to happen even if only 98% of the systems are up. What about the 2% not available? They can get the update later when they’re back. We needed a tool that can just do the work and get it done on the 98% and report on who failed. Later, when the failed systems are back online, the tool should automatically update them on the next run. Then we can go about fixing the issues causing those 2% of systems to fail and rest assured that all our changes will be pushed soon.

I intend to fill this gap. Jamis Buck, the maintainer of Capistrano, also wrote the Net::SSH module for Ruby. It is a spectacular module. With it, I plan to write an agentless tool that runs from a central server and uses SSH to log into each system for whatever task necessary. Couple it with some tools to manage users, groups, system configurations, and software installations, and a new tool to conquer the world will be born.

If you want to conquer the world with me, let me know! 😉

I have written a similar tool before. Back when I worked at Abbott I wrote a little tool we called confmgt. I used Perl because when I started the project around 1999 or 2000 that was the best language I knew. Additionally, Perl was installed on every Research and Development Unix system in the company, so I could count on it being present. The original version ran on a central server and used rdist to push files to target hosts after performing some non-trivial logic on which files to include in and exclude from the transfer.

Eventually the tool grew and features were added, and by version 3.0 (the last major version when I left Abbott) the program used rsync by default and could be run either from central server or from the host being updated. More complicated configurations required features to include more customization in how distribution areas were laid out. Despite still being written in Perl, I was very proud of the 3.0 release of confmgt. It was a masterpiece of Perl and of programming in general. With this release other Unix administrators were no longer coming to me and asking for new features; instead they came, asked, and then left knowing how to do what they were requesting. I have rarely felt greater pride in my work.

So now I am going to repeat myself, but this time in Ruby. Instead of rsync I will use Net::SFTP. The configuration file will likely be similar to Capistrano’s so that people familiar with one can use the other easily (as it should be!). It is time to change the world.