XML server configuration management This is something I started playing with, and then got sidetracked with work that pays the bills. Perhaps you'll find it a useful starting point. The problem I was trying to solve involved a few tens of machines, with similar, but not identical configurations. For example, not all of them have the same ethernet NICs, not all of them will want to run a particular service, and so on. The solution I was designing revolved around 2 different configuration 'databases' (for want of a better term). Each database was implemented as an XML document. The server database -- servers.xml ---------------------------------- This is where you describe the servers that you want to configure. As you can see in the example, server's can inherit from earlier definitions. The example server, 'clan', is a freebsd server, and a freebsd-smp server. These definitions are included in the file with simple XML entity inclusions. A look in proto/freebsd-server.xml shows some of the things that you want to define for a basic server. You can see that there's a basic kernel configuration file here, and a list of services that the stock-server should run -- in this case, a firewall. proto/freebsd-server-smp.xml shows how this can be extended. In this instance, an SMP server just has two additional kernel config options. This is a very early prototype. There are lots of different ways to structure this data. The services database -- services.xml ------------------------------------- This is a list of all the services that you might install on a host. The aim here is that each service, if added, will add some lines to one or more system configuration files. For example, the ipfw-firewall service adds some options to the kernel config file, and a line to /etc/rc.conf. The dns service just adds a line /etc/rc.conf. And so on. Note the wins service. Instead of simply embedding a chunk of the Samba config file in to the XML, the Samba options and parameters are themselves XMLised. Any entries in here may be extended or overridden in the servers.xml file. You can see an example of this in the wins service on clan. As well as taking whatever the defaults are, it specifies two additional Samba options, one in the [global] section, and one in a section called [foo]. Note that there is no mechanism to completely delete an entry that's specified in a service. Creating the config files ------------------------- The rest of the system revolves around creating the configuration files that should then be pushed on to the host you're trying to configure (using rsync, scp, or whatever). The philosophy is that each configuration file should have one XSLT stylesheet that generates the configuration file. A few sample ones are provided. You can use these examples with a suitable XSLT processor. I recommend xsltproc from ports/textproc/libxslt. (all these examples assume that you're in the directory that contains the .xsl file) etc/rc.conf.xsl # xsltproc --param host "'clan'" rc.conf.xsl ../servers.xml Generates the rc.conf file for the host. kernel/kernel.xsl # xsltproc --param host "'clan'" kernel.xsl ../servers.xml Generates the kernel configuration file for the host. services/wins/smb.conf.xsl # xsltproc --param host "'clan'" smb.conf.xsl ../../servers.xml Generates an smb.conf file for the host. Notes ----- Gut instinct tells me that this is quite a flexible way to describe your server configuration, if only I had the time to come up with a sensible way of 'masking' configuration from a service that you might not want on the host. However, the overhead is quite high, because you need to have one XSLT file per configuration file you want to generate. That's one reason I never took this any further, although I suspect a lot of the XSLT can be factored out in to import'able stylesheets. There are other advantages as well -- for example, it would be relatively easy to produce a web page describing your servers, and the services they provide. As I say, perhaps this will prove a useful starting point for someone.