On Oct 12, 2006, at 20:05 , Luke Kanies wrote:

Brandon S. Allbery KF8NH wrote:
Luke recently mentioned a presentation by Tom Limoncelli about why he doesn't do automated configuration management; does anyone have a pointer to this, or a summary or etc.? I'm still coming up to speed on a lot of this stuff (and noticing that the currently existing tools don't in general seem to fit our needs very well... but then neither does what we're currently using :/ ).

I don't have a pointer to Tom's presentation, but I'd love to hear how current tools won't work for you.

We support systems researchers; this leads to a real need for one-off machines which nevertheless get our configuration as much as possible, but with local adjustments. The "standard model" for configuration management, on the other hand, assumes every machine in a given class is effectively a clone.

We currently handle this by allowing a local configuration database to override the global configuration. It serves our needs, and is also useful for testing (i.e. I can make a change to a handful of machines in the classes that need to be modified, and then either wipe the change by removing the local database entries or migrate them to the global config). But this is the kind of thing that the tools I've looked at dom't seem to support very well; I *can* do it with cfengine, but that has other problems (and I end up using cfengine as little more than a slightly smarter shell script).

(Where our stuff currently falls short is related but not closely so: I migrated us from scripts that executed as a result of updated system configuration "packages" being installed, to something based on Makefiles. This proved to be a bad move, and I'm currently hacking around it by migrating all the rules to execute unconditionally instead of trying to detect all the possible changes. But as long as I have to rework everything anyway, might as well try to find a better solution in general....)

# # #

I should also mention, closer to the actual topic: while my current needs are distinctly practical, I'm of the very strong opinion that the growth of the discipline depends on theory --- otherwise it ends up looking like a bit of an arms race as we hack things together to try to keep up with changes. (Heck, that was the situation I walked into, and even applying a not entirely correct theory helped clean things up a lot.)

brandon s. allbery    [linux,solaris,freebsd,perl]     [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon university    KF8NH

lssconf-discuss mailing list

Reply via email to