SDI-104 Operator's Manual
Version 2008
[Search Manual] [Table of Contents] [FAQ] [Go to Previous] [Go to Next]
This appendix is a list of questions that McIDAS User Services and the SSEC Data Center commonly receives from SDI users. The questions are organized by categories for general information, system setup, and troubleshooting.
Q. What are the main differences between my "old" SDI and the "new" SDI-104 system?
A. See the McIDAS Website's SDI Migration Information page for a discussion of the differences.
Q. How are ingestor and server software updates distributed?
A. The ingestor and server (i.e., ADDE) software updates are available, with their installation script, on the McIDAS Website's SDI Software Updates page. The updates are prepackaged and are subsequently installed on the CompactFlash using the installation script. The updates can be transferred to the SDI-104 over ethernet via secure copy (scp) or copied from the USB memory stick, which mounts on the SDI-104 front panel USB port.
Q. How will security updates be distributed?
A. Like the ingestor and server software updates, operating system security updates will be distributed as packages in a section titled System Updates on the McIDAS Website's SDI Software Updates page.
A. FIFO stands for First In First Out. It is a pipe that looks like a file.
Q. What is the difference between files /etc/init.d/ingcntl and /etc/rc4.d/S30inge?
A. S30inge is a script in the system run-level directory /etc/rc4.d. The file /etc/init.d/ingcntl is the ingestor startup script, used mainly for manually stopping and restarting the ingestor.
In order for the ingestor to restart automatically upon system booting, an ingestor auto-startup script must be included in the system run-level directory /etc/rc4.d, where run-level 4 is a multi-user level. When SDIs are shipped, /etc/rc4.d and /etc/init.d/ingcntl are soft linked (so all changes made in one are also made in the other) so the ingestor will be brought up when the system reboots.
Q. Can the GVAR SDI be configured to hold, for example, more CONUS images than SH images?
A. No. It can't because the GVAR SDI retains data in the order it is received. We suggest writing images you want to keep to another local machine.
Q. Under what circumstances are SDF (Stretched Data Format) files created on a GVAR SDI? And how are they used?
A. SDF files are created when there are both clock and data going into an ingest card. SDFs are immediately written to disk in 1 MB files whether or not they contain any useful data. These files are then analyzed bit by bit looking for sync. If no sync is found in the entire 1 MB file, the file is deleted immediately. If sync is found, the block is identified. If the block is a Block 11, it is indexed in a *.B11 index file. If the block is 1-10 it is indexed in the last *.INDX file. If it is a block 0, it is either indexed in the last existing *.INDX file or a new INDEX file is created if it is the start of a new image. A new image is determined when the Priority Frame Start Time has changed and the CRC is valid. If the Priority Frame Start Time changes and the CRC is bad, at least 3 consecutive identical Priority Frame Start Times are needed to start a new image if the CRC fails each time.
Technically, only clock is needed for SDFs to be created. The ingestor will not generate any files at all if there is no clock; it may even appear as if the ingest process is hung. If you have clock but no data, SDFs will be generated, but no sync would ever be found, and the files would be immediately deleted, so during casual inspection it may appear as though no SDFs are being created.
Q. How do you change to a different ingestor type (e.g., from GVAR to MTSAT)?
A. Changing the ingestor type (e.g., from GVAR to MTSAT) is also known as "cross-grading". Although it's possible to cross-grade, the procedure is complicated and varies, depending on the ingestor and version. Therefore, you should contact SSEC for assistance.
Q. How do I remotely access my SDI??
A. As shipped, the SDI is delivered with a DSA private key for SSH access. This key is unique to your organization. This SSH key is used to access the root account on the SDI. See Accessing the SDI in Chapter 1 for details.
Q. Why doesn't the SDI have a root password at the keyboard?
A. The SDI, as a server appliance, is built for a machine room environment where physical access is effectively identical to administrator access. The operating system itself is difficult to tamper with or destroy due to its being loaded from CompactFlash and run from RAM. A password-protected console login can be enabled if your circumstances specifically require it. See Accessing the SDI in Chapter 1 for details.
A. The SDI arrives configured with network, service and ingest settings appropriate for your environment from information you give us. Most of the as-shipped system settings can be overridden through a user customization script placed on the hard drive (/data/opt/etc/rc.local). Some packages such as the ADDE server situate their configuration files on the /data/opt/etc directory as well. For more information, see Appendix B - Customizing an SDI.
Q. What time zone should my SDI ingestor be set to?
A. The time zone setting does not matter to the SDI.
Q. How do I write to the CompactFlash?
A. We strongly recommend that the CompactFlash not be overwritten or modified except by maintenance scripts provided by SSEC. This is done in order to maintain a supported configuration of the SDI.
Q. How do I implement my site's security policy on my SDI?
A. The SDI includes a minimal set of services as shipped - ADDE and SSH. These services can both be trimmed using TCP wrapper practices, with the minor detail that the hosts.allow and hosts.deny files must be placed in /etc on the ramdisk by the rc.local user customization script.
Q. What if the SDI's hard drive fails?
A. The CompactFlash has the utilities we use to partition, format, and build a contingency boot partition on a fresh hard drive. Replacing the hard drive is a user serviceable item.
Q. What if the SDI's CompactFlash won't boot?
A. As shipped, the SDI includes a bootable partition on the hard drive as a contingency in this unlikely event. The BIOS is configured to boot from the hard drive if the CompactFlash will not boot the system. The CompactFlash is only written during software updates and should not fail during the lifetime of the SDI.
Q. We just installed our SDI, but upon startup, we get the message Open error on /dev/sib0 no such device or address, and no data is ingested. Why?
A. This message indicates that the SDI board was not found by the ingestor. Please contact SSEC for assistance.
Q. The front panel's green Status LED stopped flashing. Why did this happen?
A. If the front panel's green Status LED was initially flashing but then stopped, please check for a valid clock signal. If the SDI does not receive a clock signal, the LED will stop flashing.
If there is a valid clock signal present at the clock input, reboot the SDI and check to see if the LED flashes for 16 seconds after the system has rebooted. If, after a reboot, the LED does not flash, please contact SSEC for assistance.
Q. I connected an analog monitor and keyboard to the SDI, but the monitor remains dark. Why?
A. If an analog monitor is not connected to the SDI at power up or reboot, the internal CPU board disables the video port. To enable the video port, connect an analog monitor to the SDI and reboot the system.
Q. I tried to change a configuration file and either wasn't allowed, or the change didn't stick through a reboot. Why?
A. The operating system loads from CompactFlash into the ramdisk. Therefore, changes made to the files on the ramdisk do not stick after a reboot. Most user customizations happen by way of the /data/opt/etc files resident on the hard drive. Please contact SSEC if there is a particular situation not covered in this manual.
Q. How do I remove a "bad" image (e.g., an image with a future date and time that was generated due to a problem at the ground station) from my GVAR SDI ?
A. First, remove the index files for the bad data from the data directory (usually /data). See GVAR Image Index Files in Chapter 3 for more information about index files.
Then remove all references to the bad image in the descripter files. Be careful not to edit the descriptor files while image starts are writing to the files. Edit the files between images, or stop the ingestor, edit the files, then restart the ingestor. See GVAR Descriptor Files in Chapter 3 for more information about descriptor files.
Q.What should I do if old files still exist on the system (ramdisk) after a package update?
A. Normally, old files should not remain on the ramdisk after a package update. If the update procedure worked correctly (including no old files on the ramdisk), the last line sent to the console and Python log when doing the package update should look similar to that below.
[root yyyymmdd hh:mm:ss INFO] Successfully wrote flash memory and updated ramdisk.
Return to runlevel 4 to resume operation.
|
If this line does not appear after the python package update process, you will need to reboot the system. Otherwise old files may remain on the ramdisk. Before rebooting the system, check the contents of the /mnt/HDD/packages directory. If there are any old package files, delete them. Rebooting will then force the packages to be unpacked and installed in the ramdisk.
When an SDI-104 system boots, first the system looks for package files to unpack in /mnt/CFD/packages. Then the system looks for files in /mnt/HDD/packages. Therefore any packages in the /mnt/HDD/packages directory will overwrite any files loaded from /mnt/CFD/packages.
[Search Manual] [Table of Contents] [FAQ] [Go to Previous] [Go to Next]