|
⇤ ← Revision 1 as of 2006-09-07 20:36:41
Size: 6206
Comment:
|
Size: 3350
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 10: | Line 10: |
| We have 3 solaris machines in the control room: op140m, op440m, and op540m. | We have 2 solaris machines in the control room: op440m, and op540m. |
| Line 13: | Line 13: |
| It runs the '''Mode Cleaner Autolocker''' and the '''conlogger'''. It's the only machine on which the '''tds''' suite of software tools works. Pretty much all the other machines are only made useful by ssh-ing into this machine. |
|
| Line 16: | Line 14: |
| op140m is an old Sun Enterprise refrigerator. It runs the NDS server for our Martian Network. It also runs EPICs screens, the daily MEDM checklist snapshot, and the '''RGAlogger'''. |
op540m is a Sun Blade 1500, with much unfulfilled potential. It usually runs StripTool. If you try to use it, X will occasionally, randomly crash and drop you to the login screen. You may then need to kill some zombie processes from your last session, so they don't keep building up. |
| Line 19: | Line 16: |
| op540m is a Sun Blade 1500, with much unfulfilled potential. fb40m, a Sun Blade 1000 running solaris, is in rack 1Y7. It does the frame building, and has a 1.8 TB RAID array mounted on it as /frames . /frames is also cross-mounted onto op140m. fb40m can function as an operator console if needed. It runs a daily cron job which runs /cvs/cds/caltech/scripts/backup/rsync.backup , which incrementally backs up /frames and /cvs/cds onto the LIGO /archive facility in Powell-Booth. |
fb40m, a Sun Blade 1000 running solaris, is in rack 1Y7. It does the frame building, and has a 1.8 TB RAID array mounted on it as /frames . fb40m can function as an operator console if needed. It runs a daily cron job which runs /cvs/cds/caltech/scripts/backup/rsync.backup , which incrementally backs up /frames and /cvs/cds onto the LIGO /archive facility in Powell-Booth. |
| Line 27: | Line 22: |
| We also have 2 linux control room machines: linux2 and linux3. | We also have 2 linux control room machines: linux2 and rosalba. |
| Line 31: | Line 26: |
| linux3 is an underpowered Dell. It runs matlab, and EPICs, and DTT, and may have ps2pdf installed for good ilogging. | rosalba is a white Dell running 64-bit CentOS 5. It runs matlab, but no LIGO-specific tools. |
| Line 35: | Line 30: |
| linux101 is a controls machine by the vacuum rack, dedicated to running the vacuum EPICS control screen. | linux3 is a controls machine by the vacuum rack, dedicated to running the vacuum EPICS control screen. |
| Line 43: | Line 38: |
| -- 1) '''su''': broken. You have to ssh in as root to change anything. '''sudo''' is now available. | |
| Line 45: | Line 39: |
| 3) firefox is broken, so no elog. (just click "ignore" when it complains, I'm using it now.) 4) no installation of acroread 5) Can't make PDFs. 6) The DTT path is strange. There are two versions of DTT floating around; only one allows us to load xml files. 7) Cannot print to file with DTT |
|
| Line 53: | Line 42: |
| 1) Rob doesn't know the root password. Can someone tell him what it is? | |
| Line 55: | Line 43: |
| 3) Doesn't have working '''tds''' stuff. 4) op540m doesn't appear to be in the NDS database (on op140m?) so you can't, eg, say "ssh op540m". Try "ssh 131.215.113.215". [AJW 5/8/06: just tried it, it works on op140m and op440m, but not rana/gate40m). 5) In principle, it _can_ run dataviewer, dtt, EPICS. True? |
|
| Line 61: | Line 46: |
C) op140m: 1) Has a strange flickering screen. 2) Firefox doesn't work (there's a version installed in /home/rana, but it doesn't work). D) linux2: 1) Dataviewer was broken on this machine. We found that there was one of the message queues left over from the dataviewer crash most likely. So we had to clear that with the following bash command: for i in `ipcs -q | grep $USER | awk '{ print $2 }'`; do ipcrm -q $i; done; The same command can be found in /usr/local/bin/dataviewer script, where, however, it is commented out. If someone decides to uncomment that, it would fix this same problem with stuck message queues every time dataviewer is restarted. But then we will not be able to run multiple copies of the dataviewer. Alternatively one could simply reboot the machine if the same problem is encountered again. E) linux3: 1) Nothing is obviously broken except stuff that is buggy on linux (like dtt, tds) |
|
| Line 83: | Line 51: |
| -) We should mount one /usr/ disk for all the suns, and another for all the linux machines, containing all the ligo-non-specific stuff like acrobat, ghostview, matlab, firefox, emacs, perl, grace, xdiff, gimp, wget, rsync, libpng, ps2pdf, joinPDF, gcc, ... -) We should set up our /cvs/cds/caltech/.cshrc file so that it works for both linux and suns (right now it only works for suns) and have all computers use the same /home/controls directory that invokes /cvs/cds/caltech/.cshrc . |
|
| Line 98: | Line 58: |
| -) Do all the sun computers run the same version of solaris? They should all run solaris 9. Do all the linux computers run the same version of linux? They should all run RH whatever. |
|
| Line 104: | Line 61: |
-) EPICS ALH system should work |
Here is a summary: There's a bit of craziness in our linux/solaris setup. For some reason, having to do with GNOME, /home/controls/ cannot be the same on all the machines. Thus, there is a directory called /cvs/cds/caltech/users/ where everyone should put their files. Each control room machine (except for rana) has a symbolic link from /users -> /cvs/cds/caltech/users
Solaris
We have 2 solaris machines in the control room: op440m, and op540m. op440m is a Sun Blade 1500, and is currently the machine on which most useful stuff (scripts, etc) works well. It's pretty much the only thing that can be counted on to work with all the CONFIGURE and LOCKING scripts.
op540m is a Sun Blade 1500, with much unfulfilled potential. It usually runs StripTool. If you try to use it, X will occasionally, randomly crash and drop you to the login screen. You may then need to kill some zombie processes from your last session, so they don't keep building up.
fb40m, a Sun Blade 1000 running solaris, is in rack 1Y7. It does the frame building, and has a 1.8 TB RAID array mounted on it as /frames . fb40m can function as an operator console if needed. It runs a daily cron job which runs /cvs/cds/caltech/scripts/backup/rsync.backup , which incrementally backs up /frames and /cvs/cds onto the LIGO /archive facility in Powell-Booth.
Linux
We also have 2 linux control room machines: linux2 and rosalba. linux2 is a dual-processor Xeon. It can run EPICS, use some of the ezca tools, run DTT, and run matlab. No scripts run on this machine.
rosalba is a white Dell running 64-bit CentOS 5. It runs matlab, but no LIGO-specific tools.
A third machine, linux1, is headless. It is the NFS (disk) server for /cvs/cds . It has two large disks, one mirroring the other in a simple RAID configuration.
linux3 is a controls machine by the vacuum rack, dedicated to running the vacuum EPICS control screen.
Broken Stuff
Here is a list of what's currently known to be broken on the control room machines.
A) op440m:
- 2) No one knows how to install matlab on a Sun, which would be nice. 8) We aren't in GNOME anymore. What happened? GNOME is much better than CDE.
op540:
- 2) Can't run the cool GNOME desktop. 6) Rana (the gateway computer, AKA gate40m, except that it doesn't know that) doesn't know about op540m
- (131.215.113.215); it's not in its /etc/hosts file, and doesn't partake in the DNS serving that, I think, is handled by op140m.
F) Everything:
- -) We should have updated versions of ligotools, etc,
- on both the sun and linux computers. Complete list: dataviewer, dtt, gds stuff, ligotools, ... ???
- Where is the official, latest version of the source state code we run in the PSL, vacuum, video and AUX crates? It should all be in /cvs/cds/caltech, and then mirrored (if necessary) to luna so that executables can be built. Where is the official, latest version of the source code for the front end SUS, LSC, ASC, PEM, IOO...?
-) all computers should mount fb40m:/frames -) we should check/verify the backup in /cvs/cds/caltech/scripts/backup is running on fb40m