[csw-users] managing local data for server installations

[David Blank-Edelman]

On May 31, 2007, at 12:10 AM, Elizabeth Schwartz wrote:

>  I don't see a way to specify an alternate location for Blastwave  
> stuff...?

This leads to another interesting discussion for me. I don't want to  
hijack Betsy's thread so I've change the subject.

Are there any sites out there who have done large-scale server/client  
Blastwave installations in an NFS environment that could speak to the  
following issues:

Blastwave is so superb that we're thinking about using it as our  
primary source of binaries both for our desktop clients and some of  
our server infrastructure. For efficiency's sake we'd like to have a  
single blastwave install tree that we export out to each of the  
servers to use (vs. keeping N installations current). This has the  
added plus of making it easy to move services around to different  
hardware at a moment's notice if hardware dies.

The tricky thing with this idea is the storage of service-specific  
data. I've read the NFS userguide that suggests either loopback  
mounts or playing symlink games. The userguide sidesteps a least a  
couple of issues though:

1) blastwave packages seem to write their data all over the place.  
For example, apache stuff lives in /opt/csw/apache*/blah, mysql stuff  
in /opt/csw/mysql*, ssh configs in /opt/csw/etc, bacula in /opt/csw/ 
etc/bacula. On top of this, certain packages will drop something  
into /etc/{init,rc}.d* _only_ on the install host (yikes!).

Q: How do people handle this lack of separation between binary and  
configuration space? One symlink from /opt/csw/etc to /etc is easy, N  
symlinks from various points in the tree starts to get hairy.
Q: Are you just layering something like cfengine, puppet, radmind,  
bfcg2 or {insert random source control system here} on top of your  
configuration management process to keep all of this stuff straight?
Q: Do you have anything automated that helps you know when blastwave  
is going to write a file outside of its usual /opt/csw/space?
Q: How do you handle making sure that the init scripts that get  
installed get pushed to other hosts beyond the initial install host?
Q: Do you create a spaghetti farm of symlinks if you decide to keep  
the service's data some place else on NFS?

2) I've seen upgrades to various package tromp over configs (e.g. w/ 
apache). They are usually nice enough to save a copy of the old  
configs, but still it can be a bit of a shock to have the config go  
away after an upgrade.

Q: is there any good way to handle a situation like this besides  
having a "staging" area (perhaps a separate blastwave install tree  
just for staging)?

Is there a simpler way to think about this stuff? Anything else I've  
missed?

Thanks!

     -- dNb