Following are Bob Kibrick's notes on how a replacement for koki was tested and configured to run. See also the notes by Jon Chock and Kevin Tsubota on how TDC and AUX were configured properly.
To all:
Here are some quick notes to document the current state of the ESI computers
which were reconfigured in order to get ESI operational despite a failing
CPU on koki:
KOKI:
The original koki CPU (an Ultra 140) overheated and was replaced with an
Ultra 170. The external 3-bay SCSI disk cabinet from the original koki
was moved onto one of the two fast-wide SCSI/ethernet Sbus boards that
were already installed in that Ultra 170. In order to boot the new koki
from the root disk that is in the external bay, at the OK prompt from
the boot PROM on the Ultra 170, enter the command:
boot /sbus/fas@0,8800000/sd@2,0:a -r
[Note that the "-r" above was inadvertently left off the original e-mail,
but is included here for completeness. See Bob Kibrick's description of
the importance of this flag elsewhere. - Bob Goodrich]
Although the Ultra 170 (i.e., the new koki) has three hme-class ethernet
interfaces (hme0 on the motherboard, hme1 on one of the Sbus boards, and
hme2 on the other Sbus board), we were only able to get interface hme1 to
function correctly.
At the present time, there is nothing plugged into the hme0 interface on
the motherboard of the Ultra 170. The ESI private network (192.168.5.x)
is connected to interface hme1, and the Keck-2 subnet (128.171.136.x) is
connected to interface hme2. The hme1 interface appears to be working OK
and thus koki has connectivity to the ESI private network.
However, even though the Keck-2 subnet is apparently connected to the hme2
interface, we were unable to get any packets to move across this interface.
When the hme2 interface was connected to the ethernet switch, the switch
showed a link light. Further, the cable tester indicated that the cable
from the switch to koki was apparently OK. Nonetheless, we could not see
any connectivity to the Keck-2 subnet via the hme2 interface on koki. In
particular, we could plug and unplug the ethernet cable from koki's hme2
interface, but koki would never log any messages indicating either loss
or restoration of carrier. Therefore koki's hme2 interface was ifconfig'ed
to the "down" state.
In order to provide a limited path from koki to the Keck-2 subnet, we
decided to use kanaha as a gateway. To accomplish this, we did the following:
1. On koki, we changed the default route to point at kanaha via the ESI
private network. The route table on koki now appears as follows:
koki{esieng}86: netstat -nr
Routing Table:
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ------ ---------
192.168.5.0 192.168.5.4 U 2 3 hme1
default 192.168.5.3 UG 0 495
127.0.0.1 127.0.0.1 UH 0 0 lo0
2. On kanaha, we had to re-enable ip forwarding. This was accomplished by
giving the following command as root:
ndd -set /dev/ip ip_forwarding 1
However, if kanaha is rebooted, this setting will be lost, and the
above command will need to be re-issued as root. Should we want to
temporarily configure things so that ip_forwarding is automatically
enabled whenever kanaha is booted, then we should create the file
"/etc/gateways" on kanaha.
3. On both TDC-2 and AUX-2, explicit, static routes had to be added to
route packets for 192.168.5.4 (the ESI private network address for koki)
via 128.171.136.60 (kanaha's Keck-2 subnet address), i.e.:
ROUTE NET TABLE
destination gateway
------------------------------
192.168.5.4 128.171.136.60
------------------------------
These explicit, static routes were added to TDC-2 and AUX-2 by K. Tsubota.
I do not know whether these were added permanently or not. If not, and
either TDC-2 or AUX-2 is rebooted, these routes will be lost and koki
will no longer be able to obtain the DCS information it needs to record
DCS keywords into FITS headers or that it needs for flexure compensation.
Thus, if either TDC-2 or AUX-2 is rebooted, these static routes may need
to be re-added.
KANAHA:
In an effort to get kanaha to work as a gateway, we tried several things,
most of which didn't help:
1. We tried starting routed on kanaha.
2. We renamed the file "/etc/notrouter" to "/etc/original.notrouter, and
then rebooted kanaha.
3. Neither item 1 nor 2 allowed kanaha to function as a gateway. Finally, I
realized that ip_forwarding must be disabled, so I called Jon Chock at
home and asked him to give the following command as root:
ndd -set /dev/ip ip_forwarding 1
Once ip_forwarding was enabled on kanaha, koki was able to exchange packets
with TDC-2 and AUX-2. Further, it was now possible to log in from kanaha
to koki (via the ESI private network) from accounts other than root.
However, at this point we were unable to access ESI keywords from kanaha.
In order to correct that problem, I had Bob Goodrich become "kics" on
kanaha and edit the file /vx/music/services so that the "esi_trtalk"
entry pointed to "esupvb.ucolick.org", which is the name by which kanaha
currently knows the private-network interface on koki. The relevant lines
of the /vx/music/services file on kanaha now read as follows:
#esi_trtalk koki.keck.hawaii.edu # ESI talks to traffic controller here
esi_trtalk esupvb.ucolick.org # Change to accomodate broken koki
Once all of these changes were made, Bob Goodrich was able to bring up the
ESI instrument software and take data. While the current arrangement of
things is rather fragile, it will hopefully be sufficient to last through
the night.
On Wednesday, if anyone has any clever ideas as to how to get koki's hme2
interface to talk directly to the Keck-2 subnet, then those would be worth
pursuing so that all of the temporary routes on koki, TDC-2, AUX-2 can be
deleted, and so that ip_forwarding no longer need be enabled on kanaha.
I think I have covered most of the salient points above. If I missed
anything, please let me know.
Regards,
Bob