From owner-freebsd-questions@FreeBSD.ORG Sun Apr 24 21:48:07 2005 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9743816A4CE for ; Sun, 24 Apr 2005 21:48:07 +0000 (GMT) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C57043D2D for ; Sun, 24 Apr 2005 21:48:07 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 4D55D5CA8; Sun, 24 Apr 2005 17:48:06 -0400 (EDT) Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28370-07; Sun, 24 Apr 2005 17:48:03 -0400 (EDT) Received: from [192.168.1.3] (pool-68-161-53-96.ny325.east.verizon.net [68.161.53.96]) by pi.codefab.com (Postfix) with ESMTP id D94105C86; Sun, 24 Apr 2005 17:48:02 -0400 (EDT) Message-ID: <426C1407.10206@mac.com> Date: Sun, 24 Apr 2005 17:47:51 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lowell Gilbert References: <200504231636.j3NGakjE027904@himinbjorg.tucs-beachin-obx-house.com> <44mzrnzzt3.fsf@be-well.ilk.org> In-Reply-To: <44mzrnzzt3.fsf@be-well.ilk.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at codefab.com cc: freebsd-questions@freebsd.org Subject: Re: Sanity check needed on an idea X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2005 21:48:07 -0000 Lowell Gilbert wrote: > Tuc 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 # $Id: backup.sh,v 1.3 2003/05/16 07:17:06 chuck Exp $ # #### if [ $# -lt 2 ]; then echo "Usage: backup.sh [...]" 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`."