Configuation management

[Oscar Levi <elf@buici.com>]

What is see is a very aggressive design proposal.  I'm not in for such
a direction at the moment because I want something that will work in a
couple of weeks and will solve the really tough problems I experience
as an SA.

  1) Backup of configuration files is a hassle since they may be
     located all over the joint.  Debian does a *very* good job of
     putting config files in one place, so this is mitigated though
     not solved since much of the data is etc is really system
     controlled and not SA controlled, e.g. ld.so.cache.
  2) Version control.  This is a whopper.  How many times have we
     misedited a config file and the a) not noticed immediately or b)
     forgotten how the previous state looked.
  3) Integration of config file edits with daemon restart.  This is
     simply a hook to the init.d scripts and various other levers.
  4) Integration of help, info, samples, and relevent man pages.  This
     is a recent requirement that I think can be handled with some
     info links.
  5) Unobtrusive.  It is very important for whatever configuration
     management is implemented to be completely compatible with the
     config files that we all know an love.  I don't have a beef with
     the layout of most software configuration files and would rather
     focus on solving the SA problems instead of architecting a better
     method of configuration.  That's why 4) is interesting.
  6) Seamless.  Changes made by a hapless standin SA who knows the
     ropes, but may not know the ins and outs of this new tool must
     not be lost.  In the scheme I envision, there are the config
     files as we already know them and another set in
     /var/config/HOSTNAME which are under source control.  The tool
     does multi-way merging when necessary.
  7) Remove adminstration.  This is the most onerous requirement.  I
     think it is imperative to look forward to secure, reliable,
     remote admin where the version controlled files are kept at a
     central location and are disseminated over the net.  Visualize
     the ability to distribute a common policy change to a network of
     machines: the NTP server has changed so we need to let every
     machine on the net know about it.

     It is helpful to step back from 7) for a moment and ruminate
     about NIS which seeks to solve this problem, too.  If we take the
     points 5) and 6) to heart, then we see that NIS is really too
     heavyweight since it require each service to be compiled it.  I
     want something that will work right now and will accomodate *any*
     new package.

Let me state that I think it is a good idea to rethink SA from
scratch.  I expect that the only intelligent way to do it, though, is
to provide a library against which applications can link. Then we can
deb-admin-ify applications one by one.