centralizing network configuration

[Ben Scott]

On 5/28/07, Paul Lussier <p.lussier at comcast.net> wrote:
> I'd be more than happy to discuss this topic in more depth, either on
> or off-list.  And I'd certainly be very interested in learning more
> about the environment which you're trying to manage, since that might
> spur more ideas.

  I'd like to encourage the discussion be public, as I am very
interested in this as well, and I'd bet good money others are, too.
("Public" could mean on-list, IRC/chat archives, or notes from
meatspace meetings.  I volunteer keep minutes for any meatspace
meetings.  (As an aside: I hear-by propose "meating" as a contraction
for "meatspace meeting".))

  Most of my thoughts on the matter have already been included in what
Paul wrote (indeed, he's gone a lot further than I have, in both
design and implementation).

  Most of my efforts were for automating deployment of many small
networks, which I did at lot of at Net Technologies.  We sold a lot of
"does-everything" Linux servers to customers.  While customers had
infinitely variable environments, there were common patterns which I
was always trying to exploit.  This evolved into a set of canned
config files and scripts, which were installed and customized by still
more scripts.  It was very ad hoc, but it worked, for suitable
definitions of "worked".

  One thing it didn't do was give us something to push the config back
to a central support database at Net Tech.  When I looked at existing
solutions on the web and in the literature, they were always focused
on an organization with a hierarchical, top-down structure.  You make
changes at the top, and they trickle down.  Our situation was all
autonomous systems, not tied to a single overmind, so that wouldn't
work.  I guess we wanted to be able to make changes in the middle,
have them trickle down authoritatively, and trickle up informatively.

  There are solutions to force downward, and solutions to inform
upward, but nothing that did both.  Sticking imprecise monitoring
solutions onto systems which were built from precise master data
always seemed like a horrible waste.

  I never did come up with anything comprehensive, and then I left for
another job, which has a whole different set of problems that are
exactly the same.  (HHOS)

> ... Unfortunately we've essentially re-implemented cfengine ...

  I'm minded of "Greenspun's Tenth Rule":  "Any sufficiently
complicated C or Fortran program contains an ad-hoc,
informally-specified, bug-ridden, slow implementation of half of
Common Lisp."

  (Ob: "... including Common Lisp" -- Robert Morris)

  There's something very meta here.

-- Ben