On Thu, Sep 1, 2011 at 6:08 AM, Andrew Hume <[email protected]> wrote: > 1) a single file (say config.all) with internal stanzas labelled by server > name > 2) two files, say config.clust and config.local. in this case, the install > process > would need to take the appropriate ref copy of config.server1 and install it > as > config.local on server1. > what schemes have you liked best for this sort of thing? (and why?)
Assuming your conf-file parser can read and deal with conflicts, I've found that having a default/global configuration file with a directory of included files much easier to deal with than a large monolithic file. Especially when a service is deployed to many different hosts in a variety of ways. Take for example a bind/named configuration. I need to keep a different configuration file for every host; if I need to change a global parameter I have to change every single file for every host. This is a real pain. Contrast that with Apache, which supports a global configuration file and includes additional configuration files in a "conf.d" directory. I can keep one copy of the global defaults for all hosts and a library of host-specific or service-specific configurations. This is much easier to manage. Of course using a configuration engine (cfengine etc.) makes it all much easier, but IIR all of them are better at copying files around than combining file parts together. -- Perfection is just a word I use occasionally with mustard. --Atom Powers-- _______________________________________________ Tech mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
