While talking with Tom, it struck me that we could use bcfg2 to manage
our filer configs. Filers are basically a bunch of files with some
sort of way to trigger a re-read. If we mount the /etc dirs of a filer
on the management node and run bcfg2 in a chrooted environment against
that directory structure, we get “instant” manageability of the config
files.
A few custom actions that fire off when the config files change and we
have something we can use to better enforce policy on the filers. And
we could build up a fake filer using the Netapp emulator to act as a
test environment.
Of course, two things occur to me after talking with Narayan about it.
I’m now a bit deflated that someone already thought of doing this (though
with VM images and read-only netboot systems). Second, I think someone
would chase me around with a baseball bat if we actually went through
with this.
Nonetheless, it was a fun thought experiment. Just thought I would
share. 🙂
“The distance between insanity and genius is measured only by success.â€
Very interesting approach. Do you find it often that you need to push site-wide config bits to all n number of filers? Or are most of your configuration changes atomic wrt yay on filer n, nay on filer n+1, etc?
Also what made unix@utexas.edu/its/ pick bcfg2 and not the smattering of other cfgmgmt solutions out there?
Cheers from ct.us.
@Nick:
It’s not uncommon to have to do this. We built a platform for doing this at AMD with just a bunch of make files for some of the more common files (snap mirror stuff, for example).
The bigger reason to do this is to enforce consistency and regularize the change management process. If everyone plays by the same rules, it makes it easier to understand what’s going on with the systems in the long term.
DFM sort of provides the capability to do this for you, but it was very onerous and was more for auditing the correctness of configurations vs having long term change management and logging of changes.
bcfg2 was here before I arrived. I believe cfengine and puppet were also evaluated but this one won out because of features and usability. I don’t have any of the details really. Coming from a cfengine background, it takes a 180 degree shift in ideology to understand bcfg2’s “define the end state” vs cfengine’s “define the path” mentality.
I’ve come across cases where I wished bcfg2 had the ability to just define the path, especially for events that only ever need to be run once on a system (eg, configuring LVM for my MySQL partitions).