Have you seen FAI? It's trival to add darcs support to it - http://www.informatik.uni-koeln.de/fai/ . The only thing it doesn't support is #2 below. You could probably add support for that - just check patch contents or something... FAI is just a collection of scripts so it is very very easy to extend and change.
On Thu, 2006-04-13 at 17:11 -0400, Fredrik Wikefeldt wrote: > Hello, > > I started to write a tool for system administration half a year ago > with the goals: > > 1. Forcing sysadmins to revision control all changes to config files > (like those in /etc) > > 2. Ability to have different "change" permissions for different files > in the same directory. For example, I don't want all sysadmins to be > able to change the /etc/sudoers because then they are practically > root. > > 3. Ability to leave files in a directory like /etc out of revision > control if I think those files will never be changed. This in fact > should be the standard. Thus, you start with the /etc tree you have > after OS install (in my case the minimum Debian). After that, I can > let apt-get add files and delete or change them too but only if they > are not revision controled. This might require modifying apt-get. > > 4. When changing the actual /etc directory (by getting a version the > revision control system), it should preferably be done no more > disruptively than when you normally change configuration files. > Whiping out the whole /etc and replacing it with another one is thus > not desirable. > > 5. Ability to block files from being revision controled. Could be > useful for files like /etc/passwd and /etc/group because you never > want to revert to a previous version where maybe a dismissed employee > still had his account. > > 6. Ability to cherry-pick changes. For example, if a mail server > setting is changed on one server and I discover later that I want to > do exactly that on another mail server, I can easily transfer the > patch/change between the servers. > > > I have written a Haskell program that does this except from the > apt-get part and 4). > But I used arch instead of darcs because I didn't know about darcs > when I started. Sounds strange given that I did it in Haskell but I > actually started writing it in bash, then went to python and then > wrote it in Haskell after being convinced about type checking. > > Now the question is, could I benefit from using darcs instead of arch > apart from integration benefits stemming from both parts being > writting in Haskell? > But more importantly, I'd like to know if I'm missing something > important here. Is the program I've written interesting? Am I solving > the right problem? Or maybe darcs can handle this right out of the > box. > > Best regards, > Fredrik Wikefeldt > Santiago de Chile > > _______________________________________________ > darcs-users mailing list > [email protected] > http://www.abridgegame.org/mailman/listinfo/darcs-users _______________________________________________ darcs-users mailing list [email protected] http://www.abridgegame.org/mailman/listinfo/darcs-users
