On 9/1/2011 9:08 AM, Andrew Hume wrote:
think of this as a sort of survey.
i am building a distributed cluster application which now has
two distinct sets of configuration info:
a) cluster-wide, shared by all components
b) server-specific, shared by components on a single server
for now, these are human-readable and editable text files
(NOT xml). the most likely changes to this information will be
A) tweaking of values for a new type of server (fair few over a day or so)
B) cloning server2's config for server3
my question is: how would you prefer to arrange these in the file-system?
the two obvious answers are
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?)
I've been moderately impressed by how a well-organized sudo file can do
this. Sure, there're a lot of per-host sudo installations out there and
the files can get horrible, but a well done one is quite nice to behold
and elegantly allows one to do both per-host and global with one file
and relative ease.
At a previous job, We had a directory with sudo stuff and would separate
it all out, global, per host, etc, so that they could all be edited, and
even permission controlled to the extent possible with revision control
and access. You wanted one user to be able to make sudo edits for a
particular machine (file) but not all machines? Fine, no problem;
nevermind that they could put whatever they wanted into that file, it
was more about modularity than strict security. Then 'make' would
construct and distribute out the completed sudo file to all the hosts.
Another place there was an m4 template group that did something similar
to construct a master file using macros. You didn't really have to edit
the m4 templates except under rare circumstances, but it could build and
distribute out whatever was needed.
_______________________________________________
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/
