“Give me a place to stand and a lever long enough and I will move the world.”

I was grumbling under my breath at a configuration management system today, and reminded of this wonderful statement by Archimedes.

Configuration management is the discipline of building systems which manage other systems — cfengine is a well-known open source example. I needed to reboot a few hosts on a regular schedule — easily handled in 5 minutes with “vi /etc/crontab” on each, or an ssh loop to append to the crontab on each affected system. I was struck by how many levels of indirection I needed to traverse to get this done with configuration management. This in turn prompted some thought about why jumping through the various hoops was worthwhile.

There are many excellent reasons to use configuration management:

• Time savings — over repeating the same actions over and over; this increases with the number of hosts involved.
• Consistency — configuration management ensures that (portions of) systems which should be identical really are.
• Reproducibility — because CMS is naturally tied into version control, it is easy to either examine or recreate the state of affairs at an arbitrary time in the past.
• Modeling — a CMS ends encompasses a representation of all the systems it manages. This efficient representation of those systems is quite useful for examining and comparing them. It’s especially useful with a large or dynamic population of administrators, as it provides a single place to learn about the whole constellation of systems, and enforces some consistency among the various ways admins can manage systems.

In the simplest case, to make a machine reboot once, I could pull the plug and put it back (assuming I was near, or could get to, the machine). In a non-CMS scenario, I would do it with ssh and the shutdown -r. In this case, it was considerably more involved:

• Launch PuTTY.
• Log into a system with a checkout of the CMS configuration files.
• Find the appropriate file (non-trivial if the managed constellation is complicated).
• Fetch the latest version of the file (with multiple users, it’s unlikely my checkout is current).
• Edit the file corresponding to /etc/crontab or /var/spool/cron/root (I used kate, as I don’t enjoy either vi or emacs, and BBEdit wasn’t available); kate popped back an X11 session tunneled through ssh.
• Create a pair of local machine sets in the file (cfengine calls these ‘aliases’), each including half the covered systems (the systems reboot at staggered times, so they’re not all down at once).
• Create the pair of crontab lines, one for each machine set, embedding the pair of different reboot times and the shutdown -r command.
• Check the modified crontab file back into the version control system; enter a message for the change log.
• In a distributed CMS, staging hosts pick up the changes from version control, either on a schedule or when manually kicked for emergency/rush changes.
• The affected hosts pick up the change from the CMS, and implement the specified change.

The reason Archimedes’ quote is apropos is that configuration management provides excellent leverage — I can edit one file in one place, and easily affect several systems (potentially hundreds or thousands). Each hoop I have to jump through provides an additional fulcrum. I can sit at my desk and use PuTTY to log into dozens of systems, across the world — without even knowing where they are. Each change I make to the version control system is automatically picked up by every host participating in the system, and available to every admin with a checkout. I don’t have to log into 8 machines (even uninteractively) to make them reboot — I can orchestrate it all from my local workstation.

Unfortunately, mistakes are leveraged too; there is often no good way to test changes to production systems during business hours. If the changes are restricted to non-production hours, when the admin might not be around to monitor them (and shouldn’t have to — it’s an automated system, after all!), the window could be closed by the time the admin sees whether the change was successful. Missing a change window can easily defer a change 24 hours.

I upgraded to iPhone OS v2.0 a while before I got a 3G iPhone (very worthwhile for me, since I spend most of my time outside Wi-Fi coverage now). Since the upgrade, I have noticed a few things which I have not seen mentioned elsewhere.

Continual pseudo-GPS updating in original models

On my original iPhone under iPhone OS v1.x, tapping the crosshair button in Maps used to locate me — the button turned blue while the iPhone was fixing my location, then turned grey again when done. To update my location I had to tap the button to get a new location fix. Under v2.0, after tapping the button it stays blue, and the iPhone updates my location automatically until I tap again (to turn it grey and switch location auto-updating off) or exit Maps. This is well-known on 3G models, but I was surprised and pleased to see auto-relocation on the original iPhone.

Pause to rotate (walker unfriendly)

Under iPhone 1.x, I could rotate the iPhone to re-orient Safari while walking. Under v2.0 the iPhone does not reorient while I am walking — I have to stand still for it to notice the change in orientation and rotate. Annoying, as it means I will have to stop in the middle of crowds to trigger rotation.

More switches to iPod.app when resuming music playback?

Under v1.x, after a sync or reboot, the first time I hit the earphone button to start music playback, the iPhone would switch into iPod mode, but I could stop and start without switching into iPod mode. I have a feeling that it switches into iPod mode sometimes now (after I first started and stopped playback), at times when it would not have before. This is unconfirmed, though.

Upside-down for iPod videos

I believe this changed from v1.1.4 to v2.0, but could be wrong about when. In earlier software versions, iPod movie playback only worked when rotated 90° counterclockwise. Alex hates this, as it puts the speakers behind your right hand. With v2.0, iPod movies can also be played back 90° clockwise, which puts the speakers under the left hand. YouTube still only works counterclockwise, though.

Loss of background functionality with apps vs. Safari

I am very happy with NetNewsWire, Twitteriffic, and Instapaper, but iPhone 2.0 doesn’t let them run in the background. This means NetNewsWire and Twitteriffic always need to update when I launch them, as opposed to the Mac apps which update automatically in the background. It also means I cannot multitask — when I was using NewsGator Online and m.twitter.com, I was able to switch between Safari tabs and Mail, and keep them working in the background as I switched to whichever was done. The apps are much better than the webapps, but the regression of having to wait really bugs me. Fortunately it’s lessened somewhat by the 3G iPhone’s improved update speed.

Another disappointment is that neither NetNewsWire nor Twitteriffic supports rotation. I thought Apple didn’t support it outside Safari proper (both NetNewsWire and Twitteriffic incorporate the WebKit engine Safari uses) until I realized Instapaper supports rotation, and Stanza supports rotation (even upside-down, which Safari does not). I’m sure there are real reasons Brent & Craig have not yet provided rotation in their apps, but as I understand it, they are not allowed to discuss them, or how Instapaper & Stanza do it — even under NDA, despite the fact that this is released software!

On the other hand, reading Slashdot via NewsGator Online stunk. The delay to get each article was very aggravating, and NGO was useless on the train. NNW/iPhone makes reading Slashdot a pleasure.

Also, Remote is great.