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:
- MCR "private" network (lat-dmzXX, lat-licosXX, etc.)
- MCR "public" network (lat-hobbitXX, lat-orcXX, etc.)
- ASU "relay" network (path through which the above two LAN segments are VPN'd back to SLAC)
- SASS/LAT network (lat-sskidXX, details below)
This last network is the pathway to the SASS I&T LAN. It is configured as a "DMZ" from the point of view of both SLAC and SASS, in the sense that the lat-sskidXX servers are accessible for outbound connections and established traffic on specific ports from both the MCR private network on the SLAC side, and the LAT workstations on the I&T LAN on the SASS side. However, the lat-sskidXX servers themselves cannot initiate connections towards hosts on either network.
The lat-sskidXX servers (in particular lat-sskid01) act as endpoints for SSH tunnels that provide connectivity back to specific ports on the MCR bastion host. These tunnels are initiated by the /etc/init.d/sski-tunnel startup script on lat-dmz01, in much the same way that the SSH tunnels from SLAC to the MCR are initiated by the /etc/init.d/lattunnel startup script on glastlnx06. Each forwarded port is open across the SASS firewall for connections from the LAT I&T workstations (lat-sskiw01/02) to the "DMZ" servers (lat-sskid01/02). The follwing ports are forwarded:
- 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.
Database access
For Elogbook, trending, and FMX access, lat-sskiw01/02 are configured to connect to the proper port on lat-sskid01, which is 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 an SMB shared drive from 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:
- 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 up.
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 .pkt files from lat-sskiw01:/data/stage to lat-dmz01:/gnfs/data/stage, where the existing packet-processing can pick them up.
Acquisition-directory delivery
This data path needs modification 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 on lat-sskiw01, and the tarball is FASTCopy'd to lat-dmz01:/gnfs/data/LICOS.
- On lat-dmz01, the tarball is scheduled for transmission back to SLAC and placed into the /nfs/data/DVD archive area.
Time synchronization
SASS 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.