[arch-projects] Configuration Management

Paul Mattal paul at mattal.com
Sat Aug 28 23:13:33 EDT 2004


It would be nice to have a system within Arch to manage configuration 
files. I'd really like to be able to express my Arch Linux systems 
setups as a set of installed packages and a number of configuration sets 
and then not have to back up all the system files. This allows a 
sysadmin to create another Arch box just like the one he's already got 
in minutes.

This system would allow one to easily package up configurations and 
deploy them to multiple machines. For instance, I set up each desktop 
user box in my office for printing in the same way, and I set up nfs to 
mount the same filesystems, and even enscript to use letter rather than 
A4 paper. It would be nice to be able to point each box at a "config 
repo" with configurations associated with packages, and then have pacman 
automatically pick up those configurations when I install the 
corresponding packages.

I'd like to hear people's input on how to make this work best in Arch 
and whether or not they'd think it useful. I can describe
something I've worked on for the arch-toaster by way of example of the
kind of thing I'm talking about, which led me to desire a more 
general-purpose tool.

For the toaster, I have an "arch-toaster" package which contains a lot
of dependencies on packages the toaster needs, plus default
configuration files and a fairly reusable perl script which had 2 main 
purposes:

1) to deploy the "default" configuration files to "current" locations 
(if there's no "current" version already) where they can be further 
customized, if desired

2) to deploy the "current" configuration files to their real "field" 
locations on the filesystem after editing, or after updating the system 
(since configuration files must in some cases replace package files), 
making backups as it does so to avoid ever destroying any intended 
changes made directly in the field

Additionally, I added a third function to the script, useful in 
development: to roll the configuration files from the field back into 
"current" and store them in a tar.gz which I could then roll back into 
my package build as I refined the arch-toaster package. This was my 
means of collecting my changes as I went along. Then all I had to 
continue to maintain was the list of files that would be under control 
of my configuration management system, and it handled the rest.

Anyhow, I'm mostly curious if people think this is a good idea, or if 
they think there is a better way, or both. This would be a sizeable 
project, but not that awfully complex, I don't think.

- P




More information about the arch-projects mailing list