[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Setting up OpenBSD on other machines
- To: misc_(_at_)_openbsd_(_dot_)_org
- Subject: Re: Setting up OpenBSD on other machines
- From: "D. J. Vanecek" <djv-list_(_at_)_bedford_(_dot_)_net>
- Date: Fri, 10 Oct 1997 09:30:23 -0400 (EDT)
- Cc: colpi_(_at_)_purdue_(_dot_)_edu
- Reply-to: djv_(_at_)_bedford_(_dot_)_net
> In message <Pine_(_dot_)_SOL_(_dot_)_3_(_dot_)_96_(_dot_)_971009120745_(_dot_)_29661B-100000_(_at_)_herald_(_dot_)_cc_(_dot_)_purdue_(_dot_)_edu> "daniel.t.colpi.1" writes:
> : I have just got OpenBSD to work on a DEC station 3100. I do not want to
> : have to go through all the hasel of making it work again for the 14 other
> : DEC stations here. I was wondering what is the best way to "copy" OpenBSD
> : from one computer to the next. I was just planning on rolling out the
> : bits and placing them on another machine. There are a few files that I
> : must save if I am going to do this (/etc/passwd /etc/crontab etc).
> : Has anyone ever tried this before? If so did you make some sort of
> : step-list for the project? If so, may I have a copy?
> Personally, I'd just do a level 0 dump on your golden machine, then do
> a restore onto your other machines. Then configure them by hand. I'd
> use the existing 3100 as a place to mount the disks from the other 14
> machines to do this on a known good system. You may need to do some
> hardware hacking to make this work, but it shouldn't be too horrible.
I'll concur with Warner on this, having recently done this with N=3.
The steplist is so short and obvious as to be almost not worth writing down:
yank drive from machine N.
jumper drive ID to not conflict on machine "golden".
Plug in, power up...
disklabel, newfs... (I assume they're not already running BSD).
In between tar and unplug, maybe you want to change /etc/myname and
/etc/mygate. Have the config on goldilocks include a nice /etc/hosts,
vanilla /etc/rc, a suitably generic netstart, fstab and exports (For now I'd
say export "/" rw to the world, so after the 14 Dwarves
can boot, you can fix them all quickly if need be). During the N=1
phase, write a sed script or whatever to do this. Maybe do a diff
and make a patch script for N>1? with a single environment variable,
NAME_OF_THE_NTH_MACHINE. The difference between the filesystems on
Dwarf1 and Dwarfn might only be /etc/myname. (For N=3, I did this all
by hand, but N=14 triggers my "write a script" circuits.)
Maybe the installed systems should be nice and open, with a permissive
/root/.rhosts, and cooperative /etc/ttys (i.e. %s/network/network secure/).
Tools required: a couple of screwdrivers, and a pad of Postit-notes
for keeping the drives straight. 1 pot coffee or other programmer fuel.
I have a feeling that this might go as fast as you can pull drives,
stick them in goldilocks, reboot her, pull drives out. Of course, you could do
this geometrically, if you wanted :)
This assumes your system will fit and you *want* it to fit, on a
single spindle. If each pmax has a different disk setup, then I would
still recommend this procedure, but tar only a miniroot-like system,
boot them, and final config them with NFS or with rdist, or whatever
suits their need. But it sounds like you want to clone goldilocks.
An alternative is get them all net-booting. If the "goldilocks" and
the 14 Dwarves are all going to be on the same LAN, this might be a
good method. There will be an unfavorable slope to the learning curve
for the first Dwarf, but after that smooth sailing. (assuming it all
works, of course. I've heard nasty rumors, particularly if size of
kernel >1MB and/or bios rev != good).
DEC used to have a procedure like this called a "rolling update" for
updating VMS etc on the old Vaxes. Maybe you are the logical candidate
to write one for a string of pmaxes? Once they're all initially installed,
it's actually an rdist, cvs, sup, whatever problem.
I know it's "Snow White" and that N(dwarf)=7...
Visit your host, monkey.org