At 08:55 12/03/2001 -0800, you wrote: It's a proof of concept hack -- "hey look, debconf can be shoehorned
into the web" -- not production code. To make it really usable as a production server, it should probably be changed to use a real web server, or at least a dedicated process, to serve web requests, with some kind of communication between there and debconf. It should also be changed to use SSL and some form of real authentication.
Okay. So I'd want to use a real webserver. I made a little test where a cgi script tries to call a frontend in the way dpkg-reconfigure does. I also altered the frontend so that it wouldn't start a crummy webserver - it just prints stuff. Is this the right way to start off? Or should I try to understand all the db interactions, and call them immediately from the script, bypassing the frontend stuff alltogether?
> Another unrelated question: we also need to be able to backup the > configuration files easily (just backup etc, basically). Now I thought I > didn't have to backup the debconf db in /var, is this still true? Depends on if you're using debconf 0.9 -- if so, the db is in /var/cache, and a number of interesting refinements ar epossible..
I'm using unstable, so yes. But should i actually back it up? Are there a lot of packages that overwrite the stuff in /etc based on the db, or are those freak occurrencies, and can i get away with just backing up /etc?
Thanks Mourad