Kickstart Configuration Managers

[Chris Geddings]

On Fri, 2004-04-02 at 12:08, Adam T. Gautier wrote:

> 
> Anyway, this is off topic for this list.  Does anyone have any 
> suggestiuons about what they would like to see in standard web-based ks 
> config database?
> 

So, I have some ideas, though I'm still trying to work some of them into
a verbal representation that makes good sense.  What's in my head isn't
very understandable at the moment.

Essentially, the thing should start as general as possible to be as
flexible as possible, and allow for building up the bits that are
discovered to need shoring up or building up good ideas as time goes on.

It is very important that the tool not get into a lot of macro language
garbage.  There is enough of that out there...what I want to see is
something that makes my managing kickstart files easier, I don't want to
see kickstart re-invented, or a super language stuck on top of the
existing language.  (Very loose use of the term language here.)  Keeping
the tool from imposing itself on top of kickstart will help prevent a
catch up game...ideally, the tool shouldn't even care about versions of
kickstart.

Obviously, if at some point the tool could start doing validation of
individual configurations, that might change, but that isn't even a near
term goal of what I would like to see.

Really, what I want to do initially is chunk up the kickstart configs
into manageable pieces.  I have some code I was given that probably does
what I want to some degree, though I've not had time to poke at it
fully.  I know the concept is there though.

I have two major feature descriptions:
* What I want to do is maintain "stub" files through a web interface.  I
want those stub files to be version controlled, so that I can see what
the changes to individual stubs were and when, and I can roll back to
previous versions easily.

* Additionally, I want to be able to group these stub files into logical
groups.  I want similar kinds of version controls over these groups of
stub files.  I want to be able to access these stub files either
directly/"dynamically", or "compile" the groups of stub files out to a
directory that can be accessed as static files.

That's pretty much it in the beginning.  Well, I want the web interface
to be reasonably secure, and not horribly ugly or awkward.  Notice
though, that if implemented properly, the above description could apply
to several configuration type challenges.  Indeed, the code I've not
looked at closely is currently being used to maintain iptables.

Anyway, wanted to get this response out, as I've been meaning to send it
for a bit of time now.

--Chris