synchronising failover web servers

Scott Lambert lambert at lambertfam.org
Sat Apr 10 10:09:37 PDT 2004


On Sat, Apr 10, 2004 at 01:38:12PM +1000, Aristedes Maniatis wrote:
> The problems we have right now are:
> 
> 1. how to sync the html directories
> 2. how to sync config files (eg httpd.conf, contents of /usr/local/etc, 
> and so on)
> 
> I have been experimenting with various options. For (2), I have been 
> thinking of creating a cvs repository to which we commit all changes 
> and then creating cvs checkout scripts on the deployment machines. That 
> way rollback is easy, we can comment changes, and testing on a third 
> testing box is easy. However, cvs is not well suited to files scattered 
> all over a file system. It expects to deal with a single folder full of 
> files and folders.

One word "Makefiles". :-) I have a lot of system configs in cvs.
Eventually I'll have all of them.  Each subsystem config has it's
own directory and I have Makefiles setup to work the subdirs where
necessary.  We check the configs out in our home directories on each
machine and run :

$ make update install [test] [restart]

The Makefiles take care of su'ing where necessary.  The test and restart
targets are used where appropriate.  Test does things like "apachectl
graceful", "nagios -v nagios.cfg", "spamassassin --lint", .... I try to
make sure restart depends on the test target but I still explicitly use
test on the command line.  

I have a lot of other convenience targets for things like setting up the
bind chroot environment, downloading addon rule sets for SpamAssassin,
running sdiff on the KERNCONF files, diffing the installed configs
with the cvs'd configs in case someone does things to the live configs
and forgets to commit to CVS.  

The bind configs include a script which I add to cron to update
themselves.  Other often changing configs are the same way.  Yet other
less redundant/scarier downtime consequence configs have to be updated
and installed manually.  I have a "dist" target to ssh to a list of
machines to run the make line on each.  But there is a human watching
for errors.

The better the Makefile, the easier the building of a new machine.  I'm
still learning better ways to do things with make.

-- 
Scott Lambert                    KC5MLE                       Unix SysAdmin
lambert at lambertfam.org       http://www.lambertfam.org/~lambert/resume.html



More information about the freebsd-isp mailing list