Overview
There are a number of areas in which LAT operations after integration with the bus will differ from operations to date. This page attempts to define these differences and identify the necessary modifications to deal with them. Work items outstanding are highlighted in red.
SASS I&T LAN
All computers with direct access to the observatory must be connected to the SASS I&T LAN, a restricted network segment within the FOF. No inbound access to this network is permitted. The "SSKI" rack was developed as a bridge between the existing MCR network and the I&T LAN. It contains a Nokia IP380 VPN/firewall appliance configured with the following interfaces:
...
- 3306/TCP (Elogbook database)
- 5432/TCP (Trending database)
- 8205/TCP (FMX master on glastlnx06)
- 8206/TCP (FMX slave on lat-dmz01)
- 8208/TCP (MOOT master on glastlnx06)
- 8209/TCP (MOOT slave on lat-dmz01)
- 40000/TCP (FASTCopy daemon on lat-dmz01)
Software Updates
A root cron job on lat-sskiw01 and lat-sskiw02 periodically executes a FASTCopy command to retrieve new RPM's from lat-dmz01:/nfs/online/rpms. This job runs every 10 minues, and will copy over any files added or modified in the last 2 days.
Database access
For Elogbook, trending, FMX, and FMX MOOT access, lat-sskiw01/02 are configured to connect to the proper port ports on lat-sskid01, which is are transparently forwarded to lat-dmz01. MOOT access still needs to be configured on lat-sskiw01, but will operate in the same way as FMX. SASS has stated that ports 8208/8209 are open across their firewall, but we have not verified this.
Science (VC08) data delivery
SASS will dump the contents of the SSR periodically and make the dump files available on has configured the PTP in the SCIT rack to automatically store SSR dump data to an SMB shared drive from on a Windows file server. The lat-sskid02 machine is configured to Samba-mount this drive as /mnt/sass, and a cron job periodically FASTCopy's any files matching the pattern /mnt/sass/VCID8/VCDU_* to lat-dmz01:/nfs/online/isoc/Incoming/VCDU/VCID8/. Two items adduce to this data path:
- The transfer cron script has been updated so that it watches new files until their size does not change over a one-minute period before transferring them to lat-dmz01. This portion of the transfer has been demonstrated with VC8 files from the SASS file server.
- A Vcdu2Pkt.sh script has been developed and placed on lat-dmz01 to perform the packet extraction and deliver the resulting
- SASS will not guarantee that dump-file deliveries to their shared drive are atomic. Accordingly, the cron script should be modified to keep a history of files seen (and sizes/md5 sums) to determine when a file is complete and ready for transfer.
- A cron script needs to be developed to run on lat-dmz01 and apply the VCDU-parsing code to these files and deliver the resulting pkt files to /gnfs/data/stage, where the existing pkt-processing can pick them upPkt2Isoc_Process.py and Pkt2Lsf_Process.py scripts can operate on them as usual. This script is in place, but the crontab entry to run it on lat-dmz01 is currently commented out.
Housekeeping/Diagnostic/Alert (VC00/01/03/10) data delivery
The original idea was to take the SSR-dump VC03 data, extract the LAT packets on lat-sskiw02, and delivery the resulting files via FASTCopy to lat-dmz01. However, with the advent of the LICOS-AstroRT interface, Byron's PTP-interface telemetry proxy server, and the idea of receiving and processing "redacted" spacecraft telemetry packets in real-time, I think a more convenient model would be to re-use the output of the HSK and Diag proxy archivers (which already include the redacted spacecraft packets). Accordingly, the LICOS_Scripts/analysis/PktMove_Process.py application should be modified to call FASTCopy to transfer proxy-output Both lat-sskiw01 and lat-sskiw02 are configured to connect to the PTP in the SCIT rack for real-time telemetry. Either (or both) machines can run the VSC proxies to retrieve and record LAT and (redacted) spacecraft packets. The PktMove_Process.py script has been updated with an additional command-line option to cause it to call a script named fcopy_atomic.sh to perform the move of the recorded .pkt files from lat-sskiw01sskiw012:/gnfs/data/stage to lat-dmz01dzm01:/gnfs/data/stage, where the existing packet-processing can pick them upPkt2Isoc_Process.py operates on them as usual. This path has been demonstrated all the way to SLAC with redacted telemetry packets from the spacecraft on 12/7/2006.
Acquisition-directory delivery
This data path needs modification has been modified on both lat-sskiw01 and lat-dmz01, by dividing the functionality of the existing Runs_Export.sh script into two parts:
- Creation of the Acquisition-directory tarball from the exported LICOS directory is performed Runs_Export_SASS.sh is now in place on lat-sskiw01, and the tarball is FASTCopy'd packages the run directories into tarballs and delivers them to lat-dmz01:/gnfs/data/LICOS.On
- Runs_Export.sh on lat-dmz01 , the tarball is scheduled for transmission back to SLAC and placed into the /nfs/data/DVD archive area.
Time synchronization
- has been so that it will continue to package and ship run directories in /gnfs/data/LICOS, and will in addition ship run-directory tarballs found there.
- This path has been demonstrated with dummy run directories all the way back to SLAC on 12/7/2006.
Time Synchronization
Both lat-sskiw machines have been updated to point to the NTP time server 10.33.44.1. After SASS corrected the configuration of one of their routers, both workstations synchronized from this server on 12/7/2006. Additionally, the local time zone of the two workstations was set to MST/ArizonaSASS has made one of their NTP servers visible to the I&T LAN. Accordingly, the /etc/ntp.conf files on lat-sskiw01/02 need to be updated to point to this server.