After reading the thread about a security announcement tool, I'm motivated to inquire how people maintain configuration changes across medium-sized clusters of mostly identical machines? After a little testing, executing "emerge update" isn't so bad across many machines, but going back and merging config can be a real time sink. (As large groups of machines are identical, I often use konsole with input redirected to ssh sessions to all at once.)
Every once in a while, an update comes around that absolutely requires configuration to be changed, or I'd be tempted to not merge after every update. I've toyed with putting everything important in subversion, so subsequent machines can be more easily updated. Has anyone here taken this approach? Any other tips would be appreciated.
I edit very few config files from the stock installation of most packages, yet the "replace-unmodified=yes" in dispatch-conf.conf seems to have no effect. Anyone else experience this?
Something simular went around the list almost a year ago. I'll attach it below. I have not used it, but I did keep it in the back of my mind. Excuse me if I misunderstood your question, but I think this is what you are looking for. If anyone has implemented this since, they would be better to talk to than me.
From: Donnie Berkholz; Thursday, April 22, 2004 11:35 AM
>> On Thu, 2004-04-22 at 14:00, Lombard, David N wrote: > >>>> > > Anyone know of a meta-tool designed to configure a large number of >>>> > > different programs for clusters? >> >>> > >>> > Could you expand on this? > >> >> Programs using different mechanisms for clustering generally don't
have
>> the same configuration file (MPICH, LAM-MPI, etc.). The point would be >> to have one tool that would maintain a consistent cluster
configuration
>> for all the necessary programs. >> >> It occurred to me that cfengine might do this well, but I haven't had
a
>> chnce to look into it.
I would certainly agree that cfengine would be an outstanding solution. You can use on of the config files (or even some alternate neutral format file) to drive the others. The nice thing about this solution is that the supporting stanza for each package is independent of the others, and the absence of the package on the node, e.g., LAM/MPI is not installed on the cluster, is easily handled.
Alternatively, a cluster stack like OSCAR uses its infrastructure (DB, API, &etc) to have package-specific scripts respond to events like add-node, delete-node, add-package, &etc. This maintains host lists (as you suggest above), ssh keys, and whatever else is needed by each package that is aware of the existence of the cluster. You could pursue this by proposing to add and maintain Gentoo support in OSCAR. You can start with [email protected]
NPACI Rocks is an alternate cluster stack, but it embeds RH. OSCAR currently works for RH and Mandrake, with efforts to extend to Debian currently underway.
-- David N. Lombard My comments represent my opinions, not those of Intel Corporation. -- [email protected] mailing list
