Back to computational resources
Notes on configuring SGI Indigos for the Machine Listening Group
dpwe@media.mit.edu 1996jan09
based on notes from setting up paradise.media.mit.edu
(0) Send mail to net-request@media.mit.edu indicating the desired hostname
for the new machine, where it will be installed (i.e. which fiber
box it will hang off) and requesting an IP address.
(1) Install basic 5.3 from CD - if it is not already installed
(2) Install varsity update from CD - C++, NFS, Media libraries, whatever
(3) Boot the machine,
go into EZsetup,
set the hostname to paradise,
the ip address to 18.85.5.82
uncheck default netmask, enter 0xffffffc0 (six f's)
check "turn on NFS"
N.B. for reconfiguration:
- the host name is actually recorded in /etc/sys_id
as the unqualified name, e.g. "kew"
- the ip address is the entry that corresponds to the
host name in /etc/hosts . That's where it gets it from!
(4) edited /etc/init.d/network : add at line 393 (final version)
# Media Lab only!
echo "Adding Media Lab fixed gateway for VLW area"
route add default 18.85.5.65 1
# NOTE THE TRAILING " 1" !!!!!
# end of Media Lab only
In general, the gateway address (18.85.5.65 here) will be
the same as the IP address (18.85.5.82 here) except the
last field will be n*64+1 , where n is as large as it
can be without making this value larger than the last
field of the IP address (gateway address = (IP address & 0xFFFFFFC0) + 1)
(5) set /etc/config/ifconfig-1.options as:
netmask 255.255.255.192 broadcast 18.85.5.127
At a guess, the broadcast address is the gateway address + 62
( (IP & 0xFFFFFFC0) + 0x3F )
(6) set /etc/resolv.conf from KEW as:
hostresorder bind local nis
domain media.mit.edu
nameserver 18.85.13.74 this group's fileserver (CGA)
nameserver 18.85.2.138
nameserver 18.85.2.171
(7) setup a basic /etc/hosts
127.0.0.1 localhost
18.85.0.2 media-lab.media.mit.edu amt
18.85.5.82 paradise.media.mit.edu paradise i.e. this host
18.85.0.1 amtgw
18.85.13.106 hub.media.mit.edu mas-disk
18.85.13.74 cga.media.mit.edu cga
18.85.2.138 bayer.media.mit.edu dns
18.85.2.171 aleve.media.mit.edu
(8) ftp'd /etc/sendmail.cf from kew, put it on paradise
Clearly, you have to do this after you have got the network up.
(9) added standard mounts to /etc/fstab
mas-disk:/mas /mas nfs bg,ro,soft 0 0
cga:/bvg/re/local/iris /usr/local nfs bg,rw,soft 0 0
That last line sets the /usr/local to be the central irix one for
our group, not for other groups.
(10) mkdir /mas; mkdir /usr/local
(11) set /etc/config/automount.options to:
-f /mas/etc/auto.master.sgi
(12) ln -s /usr/local/gnu /usr/gnu
(12.5) Add standard bvg links:
ln -s /mas/bvg /bvg
ln -s /bvg/ti /ti
ln -s /bvg/re /re
ln -s /bvg/mi /mi
ln -s /bvg/ut /ut
Adding the extra level of indirection - /bvg - means that all
three possible versions, /ti, /bvg/ti and /mas/bvg/ti will work.
Of these, *only* /bvg/ti works on CGA, so we include it to allow
scripts to work on all machines including CGA.
(13) add new accounts to /etc/passwd (copy lines from media-lab /etc/passwd,
modify the home directory location, create new home directories as:
cd /usr/people; cp -pr guest ; chown -R
- however, you shouldn't need to do this; you should just enable
the NIS password file
At this stage you should either remove or at least disable logins
for the various 'default' accounts (demos, 4Dgifts, EZSetup).
The second field of their passwd file entries, the encrypted
password, is empty ("::"); you can make it impossible to log into
those accounts by making it a single asterisk, since this cannot
correspond to a real password, i.e.:
demos:*:993:997:Demonstration User:/usr/demos:/bin/csh
For system security, you should ensure that *none* of the accounts
in /etc/passwd have an empty passwd field ("::"). There is a
popular mode of attach for SGIs that exploits the lp account if
its password is left empty.
(14) set the root password
(14.5) Set the timezone. /etc/TIMEZONE must be
TZ=EST5EDT
(14.7) Set the clock slaving. At present, all clocks slave to KEW,
which itself slaves to SOUND, which slaves to MEDIA-LAB (I think)
which seems to be locked to an atomic clock somewhere. To
participate in this glorious chain, make /etc/config/timed.options be:
-F kew rhythm finchley mozart -P /usr/tmp/.timetrim
.. although in the future we should probably set up a
'timelords' group, which would make the default config right.
(14.8) Get rid of the default mail aliases file. It's worthless
Make it so that it contains just:
root:bvg-admin@media.mit.edu
.. which is an alias for the bvg system manager (dpwe,kdm at pres)
(14.9) Set up /etc/sudoers so that /usr/local/bin/sudo will work.
/etc/sudoers is the list of which users are permitted to
execute sudo, but it has a complex syntax. Safest to copy
it from an existing machine, *however*, all working /etc/sudoers
*must* be of mode 400 i.e. only readable by root. Thus
do something like:
on KEW: sudo cp /etc/sudoers /usr/tmp;
sudo chmod a+r /usr/tmp/sudoers
on NEW MACHINE:
cp /net/kew/usr/tmp/sudoers /etc/sudoers
chmod 400 /etc/sudoers
(15) Enable NIS (= yp or yellow pages):
/etc/chkconfig yp on
echo "-ypsetme" >! /etc/config/ypbind.options
echo "bhg" >! /var/yp/ypdomain set the domainname as 'bhg'
echo "+::0:0:::" >> /etc/passwd indicate passwd to use yp
Seems like we should also set up the passwd= line in /etc/svc.conf,
but I guess that's only on DECstations.
(15.5) If the machine is on a subnet that currently has no 'bhg' ypserver
it won't find a ypserver. Apparently the fiber concentrators
filter out the yp broadcast packets from escaping their row of
connections. The symptoms of this are "Cannot find server for
NIS domain 'bhg'". You must:
(a) /etc/chkconfig ypserv on # this machine becomes a slave ypsrv
(b) It *should* be ypinit -s kew . But this appears to be defeated
by the concentrators or something. So you can duplicate it
by copying the /var/yp/bhg directory from a different slave server
such as finchley, e.g.
% rsh finchley -l root
finchley % cd /var/yp
finchley % tar cf bhg.tar bhg/
finchley % ftp newmachine
(log in as root)
ftp > cd /var/yp
ftp > put bhg.tar
ftp > quit
finchley % logout
% cd /var/yp
% tar xf bhg.tar # builds the /var/yp/bhg/ maps here
(c) Tell the master YP server, KEW, that this machine is a new
slave YP server, i.e. add a new line,
"newmachine.media.mit.edu", to the end of
/var/yp/ypservers on KEW.
(d) Test the function. After rebooting (to start all the YP
servers), try this on KEW:
% cd /var/yp
% touch /etc/passwd.yp % pretend we changed the master db
% ./ypmake passwd % run the yp update. It should go:
> updated passwd (19:49:39 01/23/96)
Finding NIS servers: kew.media.mit.edu finchley.media.mit.edu
sound.media.mit.edu reich.media.mit.edu
yppush[15782]: reich.media.mit.edu called
yppush[15785]: kew.media.mit.edu called
yppush[15784]: finchley.media.mit.edu called
yppush[15783]: sound.media.mit.edu called
yppush[15781]: From kew.media.mit.edu about passwd.byname:
version up to date
Finding NIS servers: kew.media.mit.edu finchley.media.mit.edu
sound.media.mit.edu reich.media.mit.edu
yppush[15792]: reich.media.mit.edu called
yppush[15793]: sound.media.mit.edu called
yppush[15794]: finchley.media.mit.edu called
yppush[15795]: kew.media.mit.edu called
yppush[15791]: From kew.media.mit.edu about passwd.byuid:
version up to date
< pushed passwd (19:49:46 01/23/96)
%
Your new machine should be in the lists and there should
not be any errors. If step (b) failed, there will be an error
like 'Error in map format'.
(15.6) Setup /etc/exports so that all the local partitions are exported
to bvg. Do a 'df' to find out which partitions are local (efs).
New machines tend to have just a single partion, / , thus
/etc/exports is:
/ bvg
/CDROM -ro,nohide
(15.7) Add this machine to the 'bvg' netgroup. You do this by adding
to /etc/netgroup on KEW. It should be obvious, basically you
have to append "(newmachine.media.mit.edu,,bhg)" (yes, two commas)
to the line defining bvgsgi. As the yp master, the netgroups
on KEW get propagated to all the yp slave servers, and thus to
the other machines.
(16) reboot, try logging in to a YP account, should be OK.
(17) all done!
Here are some older notes on reformatting SGI disks, something I once
had to do:
HOW TO INITIALIZE A HARD-DISK FOR AN SGI INDIGO
-----------------------------------------------
1993mar28 dpwe
I just went through the exercise of copying the system disk of our
original IP12 Indigo, Mozart, onto a new, identical disk (410M Seagate)
which, however, was supplied formatted as an option disk. There
are enough wrinkles to make this worth documenting.
a) Change the partitions
The system disk has three partitions (in addition to the mystical
'volume header' we will discuss below): root (/) (16M in this case),
swap (raw data, 40M) and /usr (the rest, 355M). The option disk,
naturally, has just one partition of 411M across this entire space.
Thus it was necessary to change the partitioning of the new disk.
This is accomplished by the program 'fx', which can be run from
unix as 'fx', or from miniroot as 'boot stand/fx'. In order
to change the volume header info, you need to invoke it as
'fx -x' ('boot stand/fx --x') but I'm not sure if this is necessary.
On startup, fx prompts you for the scsi controller and device numbers.
The controller was 0 for both disks, and the device was 1 for the
bottom (system) disk bay, and 2 for the middle (option) disk bay.
Thus the partitions on these drives are /dev/dsk/dks0d1s0
|| | \- partition 0
(the raw devices have the same names || \--- drive 1 (system)
but in /dev/rdsk instead - didn't need |\----- controller 0
them). \------ scsi disk
For the system-partitioning, root is 0, swap is 1 and /usr is 6.
For the option partitioning, usr1 is 7.
In both cases, partition 8 is the volume header and 10 is the entire disk.
Anyway, back to fx. To repartition the option disk as a system disk
I first backed up all the data on the option disk (since I was about
to lose it all), then unmounted it (umount /usr1), removed its entry
from /etc/fstab (to prevent problems on reboot) then ran fx on
controller 0, disk 2.
Inside fx, I went to the [r]epartition menu, which conveniently
offers you two preconfigured setups, [ro]otdrive and [o]ptiondrive.
[ro]otdrive was what I wanted and what I did. That appeared to
work, although later on I actually 'boot stand/x --x'ed the drive,
and [a]uto reformatted it. It *may* be necessary to 'label/create/boot'
the reconfigured disk like this.
b) Making new file systems
When the partitions have been changed, you need to write superblocks into
the new unix partitions. Back at the unix prompt, you run 'mkfs' on the
relevent partitions:
% mkfs /dev/dsk/dks0d2s0
initializes the new root partition (which will be /dev/dsk/dks0d1s0 when
the disk moves to the lower slot) and
% mkfs /dev/dsk/dks0d2s6
initializes the new usr partition. Be careful: if you 'mkfs' on the
wrong disk (i.e. your live system disk) you kill yourself very badly.
c) Copying across the system files
To copy the existing system onto these partitions, I mounted them:
% cd /
% mkdir newroot newusr
% mount -t efs /dev/dsk/dks0d2s0 /newroot
% mount -t efs /dev/dsk/dks0d2s6 /newusr
The mounts report that the /dev/dsk/dks.. does not exist if the partitions
are not right, or that the file is in the wrong format if the partitions
have not been mkfs'd.
The next stage was to copy the existing / and /usr onto the new disk:
% cd /
% dump 0f - / | (cd /newroot ; restore xf -)
restore: set owner/mode for . [y/n]? y
took about a minute, and
% cd /usr
% dump 0f - / | (cd /newusr ; restore xf -)
restore: set owner/mode for . [y/n]? y
took about 25 minutes to copy all 300M (or so).
'df /' and df '/newroot' should agree to within about 10 blocks, as
should 'df /usr' and 'df /newusr'. I was worried at the (small)
discrepency: I tracked it down to directories in the new copy
occupying fewer blocks than the original; presumably, these original
directories are exhibiting 'memory' of containing many more files
at some time in the past.
d) Setting up the volume header files
Now you would expect that the disk is all set, so I tried replacing the
old system disk with the newly set up disk. This looked ok, but early
on in the boot, the miniroot (funny screen) reports 'Cannot find boot
file on disk' or similar.
It turns out that SGI disks have this funny partition called the
volume header which is used to store special non-unix files, like
the miniroot etc. Although repartitioning correctly made this
partition, we still need to copy these special files onto the new
disk. This is all done through 'dvhtool'.
The contents of the volume header are listed as follows:
The volume header partition is /dev/dsk/dks0d?vh, so for our
two drives (original system is d1, part-installed system is d2):
% dvhtool -v list /dev/dsk/dks0d1vh
Current contents:
File name Length Block #
sgilabel 512 2
ide 658432 4
sash 253952 1290
symmon 199680 1786
'sgilabel' describes the disk, and is generated by 'fx' I think.
'ide' is necessary for indigos. 'sash' is the missing boot file,
and 'symmon' is an optional symbolic monitor (I hear). Looking
on our new disk reveals the problem:
% dvhtool -v list /dev/dsk/dks0d2vh
Current contents:
File name Length Block #
sgilabel 512 3
So we need to copy 'ide', 'sash' and perhaps 'symmon' from the
volume header of disk 1 to disk 2. We copy them to temporary
unix files, then write them out:
% dvhtool -v get ide /usr/tmp/ide dks0d1vh
% dvhtool -v add /usr/tmp/ide ide dks0d2vh
% dvhtool -v get sash /usr/tmp/sash dks0d1vh
% dvhtool -v add /usr/tmp/sash sash dks0d2vh
% dvhtool -v get symmon /usr/tmp/symmon dks0d1vh
% dvhtool -v add /usr/tmp/symmon symmon dks0d2vh
% rm /usr/tmp/{ide,sash,symmon}
% dvhtool -v list /dev/dsk/dks0d2vh
Current contents:
File name Length Block #
sgilabel 512 3
ide 658432 4
sash 253952 1290
symmon 199680 1786
NOW we are all set. Shutdown the machine, take out the old system
disk (bottom bay), move the new system disk into that bay, and
restart. Should come up. If not, replace the disks in their
original bays, and backup several steps. Actually, to recreate
what I did exactly, you could (after restoring the old system
disk to the bottom bay) enter 'System administration' by hitting
escape during boot, then run 'fx' from miniroot '--x' and reformat
the option disk (disk 2). This seems to get the partitioning right,
since it is already partitioned for [ro]ot. You then need to
start up fully, and go back to b).
dpwe 1993mar28
Back to computational resources
Back to Machine Listening Group home page