From owner-freebsd-isp@FreeBSD.ORG Mon Apr 14 08:59:01 2003 Return-Path: Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 35EE437B401 for ; Mon, 14 Apr 2003 08:59:01 -0700 (PDT) Received: from users.munk.nu (213-152-51-194.dsl.eclipse.net.uk [213.152.51.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 241BE43F93 for ; Mon, 14 Apr 2003 08:59:00 -0700 (PDT) (envelope-from munk@users.munk.nu) Received: from users.munk.nu (munk@localhost [127.0.0.1]) by users.munk.nu (8.12.9/8.12.8) with ESMTP id h3EG1HJ0004670 for ; Mon, 14 Apr 2003 17:01:17 +0100 (BST) (envelope-from munk@users.munk.nu) Received: (from munk@localhost) by users.munk.nu (8.12.9/8.12.8/Submit) id h3EG1Hrg004669 for freebsd-isp@freebsd.org; Mon, 14 Apr 2003 17:01:17 +0100 (BST) Date: Mon, 14 Apr 2003 17:01:17 +0100 From: Jez Hancock To: FreeBSD ISP List Message-ID: <20030414160117.GB1608@users.munk.nu> Mail-Followup-To: FreeBSD ISP List References: <20030412133836.GA52054@users.munk.nu> <200304140023.h3E0N5D92224@flip.jhs.private> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200304140023.h3E0N5D92224@flip.jhs.private> User-Agent: Mutt/1.4.1i Subject: Re: Serial line fbsd installation with no CD X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2003 15:59:01 -0000 Hi Julian, Thanks for your reply. On Mon, Apr 14, 2003 at 02:23:05AM +0200, Julian H. Stacey wrote: > I often do remote upgrades. Tip, practice locally first, knowing if > you have to push reset, you've failed :-) Yes in general this is the idea we had for having one dev and one production box, practise on the dev box first. Right now it's not a huge issue, we're a bunch of web application developers who were looking for a home, hence the colo servers. However we plan to extend the network to provide webhosting solutions geared specifically towards the web application developer market - a no fuss no limitations (within reason) solution for developers who know what they want if you will. With this in mind we will be much more strict about the uptime and upgrading of the production server, and in general keep track of the latest STABLE branch on the dev machine (perhaps perhaps keeping the source for the production server on the dev machine up to date as well in case of security updates to the production level source tree (will be 4.7-RELEASE I think). > There's a web page on this on http://www.freebsd.org I believe, > but here are 2 ways, must be other too: > 1) NFS export a file system & do a remote install from a good 4.8 local > to a remote sub directory on 4.6.2 file system, then move in to > place as below in (3) > setenv DESTDIR /host/remote/usr1/new4.8 > cd /usr/src/etc; make distribdirs ; cd ..; make install > That way will frighten some people who are keen on security > (though you could EG have ipfw on remote blocking all but your IP for > NFS, (I'm thinking of doing that for some of mine for other reasons) Yes this is what I was thinking in my last paragraph above, use NFS to install security affected parts of the 4.7-RELEASE tree (ie sendmail) which have been ready built on the dev machine. > 2) On local 4.8 host do approx: (note this is Not exact, you need > to think what your doing, to avoid shooting in foot, but I do similar > it all the time & it works for me, though I've probably forgotten > to include something, so think & take great care :-). :) > su > setenv DESTDIR /usr1/new > mkdir /usr1/new > cd /usr/src/etc; make distrib-dirs ; cd ..; make install > cd /sys/i386/conf;config -r GENERIC;cd ../../compile/GENERIC;make depend;make;make install > cd /usr1/new > tar zcf ../new.tgz . > ftp remote > put new.tgz > > ((3) as common follow up to (1) & (2)) > rlogin or ssh remote > su > cd /usr1/new > tar zxf new.tgz > mkdir /old /new /usr/old /usr/new /var/old /var/new > echo block logins, and kick users off now. > echo backup what you value > mv /var/* /var/old/ > mv var/* /var > cd usr > rmdir * > csh > foreach i ( * ) > mv /usr/$i /usr/old/$i > mv $i /usr > end > cd .. > cp `which mv` / > cp `which reboot` / > rm -rf etc dev proc mnt sys tmp > foreach i ( * ) > /mv /$i /old/$i > /mv $i / > end > /old/bin/ls / # make sure you have a new kernel & new modules > /reboot > su ; mergemaster > recompile stuff for /usr/local & /usr/X11R6 (your old packages > can be seen by ls /var/old/db/pkg) > echo wait till happy all is ok > rm -rf /old /*/old > chflags -R noschg /old /*/old > rm -rf /old /*/old Much appreciate, thanks Julian. Hopefully we'll never have to go to this extent since we'll be tracking 4.7-RELEASE (only security patches will need applying with luck). Nice to see how others do things though! Thanks and kind regards, Jez