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
