Linux Graphics Workstation Install/Setup Notes

Hardware

HP XW6000 workstations with single Pentium4 Xeon, 2.4GHz, 1.0 Gb of memory. Twin 36Gb Ultra320 Seagate ST336607LW SCSI drives. Nvidia Quadro4 980XGL graphics card and rather expensive Sony GDM-C250K monitor. Stereo capable. Gigabit ethernet.

They come with RedHat 7.3 installed, but with custom HP modifications to the default 7.3 operating system for the hardware.

Gotcha!

The immediate downside of having HP-custom RedHat 7.3 on your machine is that you cannot upgrade the kernel because the new kernel doesn't have the required aic79xx_1_3_10 driver. The SCSI card/chipset concerned is an Adaptec AIC7902 Ultra320, and seems to cause problems with older Red Hat versions. Red Hat 8.0 will not even boot off CD because it cannot see the disks. Red Hat 9.0 will boot off CD and install, but fails to reboot afterward with whining about BIOS partition table inconsistencies and out of memory during swap. All sorts of nastiness.

Thanks, HP.

Some sort of solution: on the HP website they have a RH8.0 Enabler iso image that you can burn into CD. This will boot the machine (I've found it works best if you install in GUI mode) then let you step through a relatively conventional install for Red Hat 8.0, and which also puts in the HP Adaptec drivers and also the Nvidia Quadro4 drivers. It even reboots the machine OK. The standard install parameters are below:

Install Parameters

Elect to use the graphical installation method (GUI mode, not recover)
English language
US English layout
Generic 3-button PS/2 mouse

Automatic configuration of disk partitioning
Disable /dev/sdb as possible destination, otherwise it puts swap on there
Drives set automatically to /dev/sda and /dev/sdb
Remove ALL Linux partitions
Select /dev/sda as the install disk
Review the partitioning
Add /dev/sdb as non-root disk by selecting it, hitting Edit, and entering mount point as /usr1
GRUB boot loader in /dev/sda, record in Master Boot Record /dev/sda3 is ext3 partition with boot image
/dev/sdb1 is ext3 partition

Edit eth0 ethernet interface, disable DHCP
IP: 140.163.178.210 (this is for xray3 - change as assigned)
Netmask: 255.255.255.0
Hostname: xray3
Gateway: 140.163.179.1
Primary DNS: 140.163.9.254
Secondary DNS: 140.163.20.250
Ternary DNS: not set

No firewall
No additional languages
Set root password
Set geographic location
Select a wider range of packages than the default
X config - identify card as NVIDIA GeForce 4
Leave monitor selection as probed, since it doesn't have GDM-C250K

INSTALL STARTS (takes about 15-20 mins)

Kernel is 2.4.18

TrueColor (24 bit) 1600x1200
KDE Desktop can be selected from login via Extras->Preferences->Switch Desktop
Reboot after install

Post-install Configuration

Most of the subsequent steps are found in xray0/STUBS with a script file called "exec" and some other script files, RPMs etc. The "exec" script isn't ready to run in one block, so cut and paste from the entries. Since the setup of extras is fundementally the same as the Linux servers, also running Red Hat 8.0 but with a 2.4.20 kernel, it is not reiterated here. However the setup script is enumerated in a rather voluminous fashion.

chkconfig and sundry RPMs

chkconfig rsync on
chkconfig telnet on
chkconfig rsh on
chkconfig rlogin on
chkconfig nfs on
rpm -Uv wu-ftpd-2.6.2-8.i386.rpm
chkconfig wu-ftpd on
rpm -Uv wine-20020605-2.i386.rpm
chkconfig wine on
rpm -Uv netatalk-1.5.3.1-4.i386.rpm
chkconfig atalk on
rpm -Uv glut-3.7-8.i386.rpm
rpm -Uv tk-8.3.3-74.i386.rpm blt-2.4u-7.i386.rpm
killall -USR2 xinetd

The killall gets xinetd to re-read the setups.

HOSTS, FSTAB and NFS

cat hosts.STUB >> /etc/hosts
emacs /etc/hosts

hosts.STUB is a standard /etc/hosts file with the localhost crap chopped out. We edit the final /etc/hosts to remove the hostname in 127.0.0.1 entry.

cat fstab.STUB >> /etc/fstab
emacs /etc/fstab

A standard set of NFS mounts, which we edit to remove the host machine.

source make.nfs.dirs

A standard mkdir-for-nfs script that looks like this:

mkdir /xray1 /xray2 /xray3 /xray4 /xray5 /xray6 /xray7 /xray8 /xray9
mkdir /xray10 /xray11
mkdir /xtreme1 /xtreme2 /xtreme3 /xtreme4 /xtreme5 /xtreme6
mkdir /ximpact1 /ximpact2 /ximpact3 /ximpact4
mkdir /xray1/home    
mkdir /xray1/usr1    
mkdir /xray1/usr2    
mkdir /xray2/usr     
mkdir /xray2/usr1    
mkdir /xray2/usr2    
mkdir /xtreme1/usr   
mkdir /xtreme1/usr1  
mkdir /xtreme1/usr3  
mkdir /xtreme2/usr   
mkdir /xtreme2/usr1  
mkdir /xtreme2/usr2  
mkdir /xtreme3/usr   
mkdir /xtreme3/usr1  
mkdir /xtreme3/usr8  
mkdir /xtreme4/data2 
mkdir /xtreme4/data3 
mkdir /xtreme5/usr   
mkdir /xtreme5/data1 
mkdir /xtreme6/data1 
mkdir /xtreme6/usr   
mkdir /ximpact1/usr1 
mkdir /ximpact2/usr1 
mkdir /ximpact2/usr3 
mkdir /ximpact2/usr2 
mkdir /ximpact3/usr  
mkdir /ximpact3/usr1 
mkdir /ximpact4/usr  
mkdir /ximpact4/usr1 
mkdir /xray4/usr     
mkdir /xray4/usr1    
mkdir /xray4/usr2    
mkdir /xray4/usr3    
mkdir /xray5/home    
mkdir /xray5/usr     
mkdir /xray5/usr1    
mkdir /xray5/bigdisk 
mkdir /xray6/home    
mkdir /xray6/usr1    
mkdir /xray6/usr2    
mkdir /xray7/home    
mkdir /xray7/usr1    
mkdir /xray8/home    
mkdir /xray8/usr1    
mkdir /xray8/usr2    
mkdir /xray9/home    
mkdir /xray9/usr1    
mkdir /xray9/usr2    
mkdir /xray10/home   
mkdir /xray10/usr1   
mkdir /xray11/home   
mkdir /xray11/usr1

So now mount the disks (assuming the host has been added to the respective export lists):

mount -a

Update our own export lists:

cp exports.STUB /etc/exports
emacs /etc/exports
exportfs -a

Copy a standard group file to /etc/group (changes group 20 etc):

cp group.STUB /etc/group

Users

The privileged initial few:

useradd -d /home/xtal -g 500 -m -s /bin/tcsh -u 1113 -n xtal
chmod a+rx /home/xtal
useradd -d /home/raxis -g 20 -m -s /bin/tcsh -u 1100 -n raxis
chmod a+rx /home/raxis
useradd -d /xray6/usr2/phil -g 20 -M -s /bin/tcsh -u 1114 -n phil

Then do passwd for each of these new users.

JAVA

Make some sort of attempt to let Shake-n-Bake work:

cd /usr/local
tar xvjf ~/STUB/jre*.bz
tar xvjf ~/STUB/jdk*.bz
cd ~/STUB

X11 Configuration

Most of the basic config is done by default, but the configuration files are far from optimal for the monitor.

Take a modified/hacked XF86config file and load it. Note that on the HP, the files /etc/X11/XF86Config and /etc/X11/XF86Config-4 are symbolic links to /etc/X11/XF86Config-4.nvidiaStandard so we make a /etc/X11/XF86Config-4.nvidiaModified file and link to them instead. The modified file was a combination of the XF86Config-4.nvidiaStandard and Raj's modelines for his GDM-F250 monitors which should have nearly identical specs. The program xvidtune may prove useful for setting modelines. CTRL-ALT-plus and CTRL-ALT-minus (keypad +/-) allow you to change resolution on the fly. CTRL-ALT-backspace kills the X server so you can test various incarnations.

cp XF86Config-4.nvidiaModified  /etc/X11/
ls -alF /etc/X11/XF86Config /etc/X11/XF86Config-4
rm /etc/X11/XF86Config /etc/X11/XF86Config-4
ln -s /etc/X11/XF86Config-4.nvidiaModified /etc/X11/XF86Config
ln -s /etc/X11/XF86Config-4.nvidiaModified /etc/X11/XF86Config-4

Fix up2date and run it

The standard RH8 up2date has expired certificates and the RH8 rpm is no longer on the server, so we do a temporary kludge to get it to work:

gpg --import /usr/share/rhn/RPM-GPG-KEY
gpg --import /usr/share/rhn/RPM-GPG-KEY
gpg --verify RHNS-CA-CERT.asc RHNS-CA-CERT
install -b RHNS-CA-CERT /usr/share/rhn
up2date

The list of IDs vs machine are as follows:

pdj002 - xtreme4
pdj003 - xray3
pdj004 - xtreme1
pdj005 - xray10 (old)
pdj006 - xray10
(pdj007 - xtreme3 when it finally gets configured)

Remember not to run up2date before you change to the final machine name because this will likely confuse it.

Clone Xtal

su - xtal
cd ~xtal
(cd /xray1/home/xtal ; tar cf - .) | tar xvf -

Resurrecting Xtreme4

No extra work to be done here except modifying the disabled mounts in /etc/fstab on other machines. Uses the same IP, except it's no longer an SGI. We do have to do a little bit of work to fix the NFS mounts on the other machines because /xtreme4/usr1 used to be soft-linked to /ximpact1/usr and eventually /xray2/usr1. We must remove this link and add mounts to the Linux and SGI machines:

df -k | grep xtreme4           # see what's mounted
ls -alF /xtreme4               # check the alias

rm /xtreme4/usr1               # remove the alias
umount /xtreme4/usr            # remove residual mounts
mkdir /xtreme4/home            # make mount points
mkdir /xtreme4/usr1

export DISPLAY=ximpact1:0      # edit fstab
emacs /etc/fstab
                               # add these entries to fstab and save
xtreme4:/home   /xtreme4/home   nfs rw,bg,soft 0 0
xtreme4:/usr1   /xtreme4/usr1   nfs rw,bg,soft 0 0

mount /xtreme4/home            # mount the disks
mount /xtreme4/usr1

We might (eventually) elect not to mount /xtreme4/home to anything other than /xray1 (for ~xtal updates) however right now I do have it mounted.

Now, we aim to transfer /data2 and /data3 back to xtreme4 or at least their contents since we don't want to move the disks. We will move them to /xtreme4/usr1 On xtreme4:

mkdir /usr1/raxis
chown raxis.user /usr1/raxis
rsync -azv /xray1/usr1/xtreme4/data3/raxis/. /usr1/raxis/.   # faster
rsync -azv /xtreme4/data3/raxis/. /usr1/raxis/.              # check
rsync -azv /xray1/usr1/xtreme4/data2/raxis/. /usr1/raxis/.   # faster
rsync -azv /xtreme4/data2/raxis/. /usr1/raxis/.              # check
rsync -azv /xtreme4/data2/archived/. /usr1/raxis/archived/.  

umount /xtreme4/data3
 remove /xtreme4/data3 from /etc/fstab
rmdir /xtreme4/data3
ln -s /usr1 /xtreme4/data3

umount /xtreme4/data2
 remove /xtreme4/data2 from /etc/fstab
rmdir /xtreme4/data2
ln -s /usr1 /xtreme4/data2

On xtreme5 and xtreme6:

Change script files to write to /xtreme4/usr1/raxis/archived instead of
/xtreme4/data2/archived

On xray1:

Disable crontab entry for /data3
mkdir /usr1/xtreme4/usr1
chown raxis.user /usr1/xtreme4/usr1
rsync -azv /usr/xtreme4/data3/. /usr1/xtreme4/usr1/.
\rm -rf /usr/xtreme4/data3 /usr1/xtreme4/data3
Change crontab entry from /xtreme4/data3 to /xtreme4/usr1

Disable crontab entry for /data2
Move directories from /usr1/xtreme4/data2/raxis to /usr1/xtreme4/usr1/raxis
Allow cron jobs to synchronise the directories more fully

To avoid the disk filling up, we relocate /xtreme5/data1 and /xtreme6/data1
  to the /usr disk:

Disable crontab entry for /xtreme5/data1 and /xtreme6/data1
mkdir /usr/xtreme5
chown raxis.user /usr/xtreme5
rsync -azv /usr1/xtreme5/. /usr/xtreme5/.
\rm -rf /usr1/xtreme5
ln -s /usr/xtreme5 /usr1/xtreme5
mkdir /usr/xtreme6
chown raxis.user /usr/xtreme6
rsync -azv /usr1/xtreme6/. /usr/xtreme6/.
\rm -rf /usr1/xtreme6
ln -s /usr/xtreme6 /usr1/xtreme6
rsync -azv --delete /xtreme5/data1/ /usr/xtreme5/data1/.
rsync -azv --delete /xtreme6/data1/ /usr/xtreme6/data1/.
Re-enable crontab entries with new locations

On all machines except xtreme4 and ximpact1:

umount /xtreme4/data3
 remove /xtreme4/data3 from /etc/fstab
rmdir /xtreme4/data3
ln -s /xtreme4/usr1 /xtreme4/data3

umount /xtreme4/data2
 remove /xtreme4/data2 from /etc/fstab
rmdir /xtreme4/data2
ln -s /xtreme4/usr1 /xtreme4/data2

On ximpact1:

 remove /xtreme4/data3 from /etc/exports
 remove /xtreme4/data2 from /etc/exports
 exportfs -u /data2 /data3
ln -s /xtreme4/usr1 /xtreme4/data3
ln -s /xtreme4/usr1 /xtreme4/data2
I should probably remount these directories as /usr2 and /usr3

Resurrecting Xray3

No extra work to be done here except modifying the disabled mounts in /etc/fstab on other machines. Uses the same IP, except it's no longer an SGI. None of the prior data from xray3 was worth saving, so there's not restore/file transfer to be done. One should mount /usr1 and perhaps /home at some point. This machine was transferred to Dimitar's custody after space was made for it.

Recreating Xtreme1

Also see notes above under xtreme4

Initially the XW6000 destined to be xtreme1 was installed as xray11. The /etc/exports file on xtreme1 was set to export /usr1 and /usr3 to xray11 as root. xray11 mounted these directories as part of the standard setup.

Once so mounted, we want to do several things:

Force /xtreme1/usr1 to point to /xray2/usr2 on existing machines so no ambiguity exists for ~xtal
Duplicate /xtreme1/usr3 on xray11's /usr1 disk
Unmount /xtreme1/usr3
Shutdown the existing xtreme1
Rename xray11 as the new xtreme1
Mount the new xtreme1's /usr1 disk as /xtreme1/usr3

Step 1: force /xtreme1/usr1 to point to /xray2/usr2 on all SGIs and Linux boxes:

umount /xtreme1/usr1
rmdir /xtreme1/usr1
ln -s /xray2/usr2 /xtreme1/usr1

Step 2: copy /xtreme1/usr3 onto xray11's /usr1 disk:

rsync -azv --delete /xtreme1/usr3/ /usr1/.

Step 3: Unmount /xtreme1/usr3 on all SGIs and Linux boxes

umount /xtreme1/usr3

Step 3a: paranoid second copy of /xtreme1/usr3 onto xray11's /usr1 disk:

rsync -azv --delete /xtreme1/usr3/ /usr1/.

Step 4: say goodbye to xtreme1:

shutdown -g0 -yes

Step 5: get xray11 to reincarnate as xtreme1:

umount /xtreme1/usr
umount /xtreme1/usr1
umount /xtreme1/usr3
umount any NFS filesystems
hostname xtreme1
emacs /etc/sysconfig/network
emacs /etc/sysconfig/network-scripts/ifcfg-eth0
ifdown eth0 ; ifup eth0
/etc/init.d/network stop ; /etc/init.d/network start
reboot for the Hell of it
check hostname
try NFS mounts

In the actual event some IPs in /etc/sysconfig/network-scripts/ifcfg-eth0 got mangled, but it was fixed eventually by manually hacking and restarting the network via /etc/init.d/network.

Step 6: modify NFS mounts on Linux and SGI:

Change mount to xtreme1:/usr1 as /xtreme1/usr3
Remove xtreme1:/usr, xtreme1:/usr1 and xtreme1:/usr2 mounts
Probably should add xtreme1:/home but not done at this time
May need to reboot some of the more recalcitrant SGIs

Starting HTTPD on Xtreme1

Just launch the http config GUI in the server configuation menu, enter the host name as xtreme1 and accept the rest of the defaults. I had to modify the configuration file /etc/httpd/conf/httpd.conf to explicitly activate user public_html directories. I found that symbolic links work perfectly well to link to public_html on other filesystems (done for ~xtal, xray0).

chkconfig httpd on
/etc/init.d/httpd start

The config files turn out to be in /var/www with the default machine home as /var/www/index.html.

Recreating Xtreme3

Complications - it has 3 external disks - one of which is the 36Gb disk from Dimitar's lab that I rescued from ximpact2. This should probably be returned to ximpact2 (was done so, although SCSI termination errors made me deprecate this disk for user space). /usr1, /usr2 and /usr8 are old 4Gb drives whose longevity is questionable and which might be retired. /usr2 is an internal drive so not trivially movable (I could put it in ximpact1).

phil.xtreme3.1>> df -kl
Filesystem             Type  kbytes     use     avail  %use Mounted on
/dev/root               xfs  2068624   885340  1183284  43  /
/dev/dsk/dks1d4s7       xfs 35828240 32825792  3002448  92  /usr9
/dev/dsk/dks0d3s7       efs  4088280  3032451  1055829  75  /usr2
/dev/dsk/dks1d2s7       efs  4082400  2798595  1283805  69  /usr1
/dev/dsk/dks1d3s7       xfs  4186852  3083996  1102856  74  /usr8

where
/usr1 - nz_new - move to new /xray2/usr1 disk as part of ~nz - disk emptied
/usr2 - old lab accounts - disk emptied
/usr8 - old lab accounts - disk emptied
/usr9 - 36 Gb - Dimitar Nikolov lab - mounted as /ximpact2/usr2

So what we will try and do is return the /usr9 to ximpact2 as /ximpact2/usr2 which requires us to unmount it, swap machines and remount it. Ximpact2 currently does not have a /usr2 - however we do have to change the SCSI ID from 4 to something like 3 or 5 to avoid clashes with existing SCSI bus inhabitants. Prior to retiring the existing hard drives we re-initialise them as xfs just in case we want to re-use them.

alter exports, mounts on xtreme3
alter exports, mounts on ximpact2
unmount all /xtreme3 disks including /ximpact2/usr2
shut down existing SGI xtreme3
remove SCSI bus and in particular /usr9
change /usr9 SCSI ID to 3
restart xtreme3 (no exports)
shut down ximpact2
add old /usr9 disk to SCSI chain as /usr2
restart ximpact2
restart xtreme3
change NFS mounts for /ximpact2/usr2
mount it

Somewhat messy but ultimately successful. With all the useful data moved or removed from xtreme3, we shut the old SGI down permanently and lob it into the trash. Xtreme3 was resurrected as a Linux box in the same manner as xtreme1 and xtreme4. Subsequently eviscerated into a windows configuration which is how it sits now, hence inactivated in most /etc/fstab entries. However a Linux reinstall should be relatively trivial.

Adding Dials

The SGI dials (SN-921) are no longer made, but the existing old-but-reliable dial sets seem to be usable on the Linux boxes. However the cable requirements are somewhat quirky - it's not sufficient to use a standard serial cable, even with the necessary gender exchangers. Instead, based on a cable Bill Barton was using for the same purpose on his hardware I ordered cables from the manufacturer directly. Vendor: NuData, Lakewood NJ, (800) 844 5757. Label on cable is "CUS4713 AK321". The cables are not cheap but they do "just work".

With the cable, you can plug the dialbox into serial port #1, which is dev/ttyS0 under Linux. The main gotcha here is that there is no direct SGI dial driver under Linux, so the way to get dials to work with O is somewhat of a kludge. There's a program called odials written by Joe Krahn that polls the device directly and converts dial events into mouse and keyboard X events via the Xtest extension. I put it in /home/xtal/odials but found the dial rotation to be jumpy in O8 under RedHat 8. It seems to be related to a minimum level of observable rotation for each dial increment - the small increments seem to be swallowed invisibly by O (or by X). I modified the code as odials-pdj with a multiplier (~3.0) to increase the sensitivity of the dials which reduces the jumpiness but also increases the speed of rotation. Unfortunately the program does not work properly if you start odials before the O window launches. It might also not handle multiple O windows intelligently. I created /home/xtal/O/bin/ono_dials with a gratuitous hack in the script, namely

(sleep 10 ; /home/xtal/odials/odials-pdj /dev/ttyS0 O_linux > /dev/null) &

before O starts, which will hopefully allow the O window to open before the program starts. There's also a killall odials line later on in the script because multiple copies of odials really don't play well with each other. Also created the alias

alias odials            $XTAL_ROOT/odials/odials-pdj /dev/ttyS0 O_linux

in 0_setup.com.

Should try and understand how odials works in detail, and to get it to play nicer with multiple windows or starting before the main O program starts.