Serial line fbsd installation with no CD

Jez Hancock jez.hancock at
Mon Apr 14 08:59:01 PDT 2003

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 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,

More information about the freebsd-isp mailing list