Date: Sun, 24 Apr 2005 17:47:51 -0400 From: Chuck Swiger <cswiger@mac.com> To: Lowell Gilbert <freebsd-questions-local@be-well.ilk.org> Cc: freebsd-questions@freebsd.org Subject: Re: Sanity check needed on an idea Message-ID: <426C1407.10206@mac.com> In-Reply-To: <44mzrnzzt3.fsf@be-well.ilk.org> References: <200504231636.j3NGakjE027904@himinbjorg.tucs-beachin-obx-house.com> <44mzrnzzt3.fsf@be-well.ilk.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Lowell Gilbert wrote:
> Tuc <tuc@ttsg.com> writes:
>> I'm to the point where going to upgrade software or make a config
>>change on 10 servers gets really annoying. I was looking to do something
>>a little different. I know there are other things out there to do this
>>(cfengine) but wondered if that was alot more than I need.
May I make a suggestion, based on prior observation of such tools?
Try shepherding a test network of two machines-- your config server and a
client-- through a significant update (ie, a security patch where the kernel
or libc or some such vital piece gets updated). If it took you longer than:
(# of clients) * (time required to update 1 machine by hand)
...you've got yourself an answer. However, the story doesn't end there,
quite. :-)
Every once in a blue moon, an update goes out which breaks something, perhaps
not on a test system, but maybe on machines with older CPU's (for example,
somebody turned on SSE optimizations in the kernel, only you still have P2
clients). Be ready and willing to test for and fix this if it happens. And
remember, it's not so bad when you know just what went wrong, and when, and why.
[ In real life, what happens is that on Tuesday, you have the head of
such-and-such department complaining that nobody was able to use their
such-and-such server all day yesterday, why is it broken, and when is it going
to be working? Perhaps last Friday, somebody else pushed out an update which
broke whatever it was...? Well, that's harder to figure out, although time
pressure and cheerful encouragement of a buncha people who can't get their
work done adds a certain charm to the experience. ]
If you've got the resources, time, and organizational willpower to use this
test network just as I've described, something like cfengine will deliver for
you. But it's not for everyone, that's for sure. I'd prefer something
simpler, myself.
[ ... ]
>> If machineX didn't need a different etc/hosts.allow lets say than
>>a "default" one, I would just link /mnt/machineX/etc/hosts.allow to
>>../../etc/hosts.allow .
>>
>> Does this sound too convoluted?
>
>
> To be honest, yes. Maintaining the links you need seems like it will
> be just as much work as doing the upgrade. And some of the
> configuration needs to be *different* on each machine...
Agreed. Disk space is really cheap, I'd rather use that than spend a lot of
admin time to set up and maintain all of these links. There's nothing wrong
with using NFS, but the network is a shared resource with contention limits
and round-trip delay [1], whereas local disk access is fast.
If I had to, I'd rather rsync /usr/local between boxes, but one is using
ports, have your package builder box create packages of all of the stuff you
use, and copy and install those on client boxes as needed.
------
[1]: At least as far as bandwidth to a single server is concerned, regardless
of whether you have a switch or a hub.
> A little better might be to point your path into the shared tree, but
> you'll need to also build those ports in that location, using that
> path as a PREFIX. Obviously, my idea is still half-baked.
I'd suggest simply copying the config files from your machines to a central
place, and then placing that info into version control under CVS (or
Subversion, whatever). This serves as an online backup of your config files,
so it's a fine thing if this central machine has a tape drive doing backups.
You might even convince people to change things in a workarea, test them, and
then checkout the changes on production machines, although developers seem to
understand and tolerate version-control-software tools more than sysadmins
usually do. Regardless, if you re-import this location whenever a human makes
a significant change, you'll have something resembling change control and
auditing for the config files, as well as a backup copy handy if you need 'em.
--
-Chuck
#! /bin/sh
####
#
# Backup script. Takes SSH key as the first argument, then a list of
# one or more hostnames to backup. This script removes slashes found
# in hostnames and tests whether a host is pingable before trying to
# operate on that host.
#
# In other words, if you configure one host at a time to backup okay
# by adjusting SSH keys and such, running "./backup.sh _ident_ *.com"
# at a later date will backup all of the hosts manually configured
# automaticly. If a host is down, it will be skipped without its
# files being deleted by the "rsync --delete" or "rm" commands
# (if enabled; see below).
#
# Copyright (c) 2003. Charles Swiger <chuck@pkix.net>
# $Id: backup.sh,v 1.3 2003/05/16 07:17:06 chuck Exp $
#
####
if [ $# -lt 2 ]; then
echo "Usage: backup.sh <SSH key> <host1> [<host2>...]"
exit 1
fi
ID=${1}
shift
echo "Authenticating via SSH key id: ${ID}"
echo
PATH=/usr/local/bin:/usr/bin:/usr/sbin:/usr/libexec:/usr/lib:/bin:/sbin
MKDIR="mkdir -p"
RM="/bin/rm -rf"
RSYNC_RSH="ssh -i ${ID}"
export RSYNC_RSH
COPY="rsync -aqRC --copy-unsafe-links --delete"
# Alternative COPY version if you don't have or want to use rsync:
# COPY="scp -rq -i ${ID}"
# Loop through all of the remaing arguments, and test whether reachable
for name ; do
CLIENT=`echo "$name" | tr -d '/'`
if { ! /sbin/ping -q -c 1 -t 10 ${CLIENT} > /dev/null ; } then
echo "${CLIENT} is unpingable and may be down. Consult errors above."
continue
fi
echo "Backing up ${CLIENT} at `date`."
# This is the destination to backup the client to.
DESTROOT=/export/Backups/"${CLIENT}"/
####
# DANGEROUS: (optionally) completely clean contents first?
#
# You will probably be sorry if you leave this enabled and run
# backups via cron. Only turn this on when running by hand.
# ${RM} ${DESTROOT}
####
${MKDIR} ${DESTROOT}
${COPY} ${CLIENT}:/etc ${DESTROOT} 2> /dev/null
${COPY} ${CLIENT}:/var/log ${DESTROOT} 2> /dev/null
${COPY} ${CLIENT}:/var/named ${DESTROOT} 2> /dev/null
${COPY} ${CLIENT}:/usr/local/etc ${DESTROOT} 2> /dev/null
# add directory locations you care about here...
${COPY} ${CLIENT}:/opt/apache/conf ${DESTROOT} 2> /dev/null
done
echo
echo "Finished backup at `date`."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?426C1407.10206>