Updating a Limited Access (Secure) Environment

A secure installation can either be a binary-only installation or a development installation. The binary-only installation is trivial and will not be coverered because it's update is identical to updating any other binary installation. The development installation is more complex and can be addressed in either of two modes depending on whether classified code exists on the secure system that can not be migrated our of this environment. Since often the code is not classified in a secure system, only the data and/or its application, we'll focus on describing how to maintain code in a classified system when all the code is unclassified. This is the case at WIANG and this description applies directly to their network.

First, note that there are three common components involved in system update:

  1. Updating code

  2. Updating static data

  3. Updating the database schema

Updating the Code

This involves updating the C, Fortran, C++, & TCL code, the associated scripts and configuration files. At Volk, the procedure for updating this code according to the unclassified CVS server is based upon the employment of an unclassified data portal with internet access at Volk and a transfer user on the classified system. At Volk the unclassified portal is a computer in their conference room. When a program team first arrives at Volk they must update this machine from the unclassified CVS server as they would their normal machines. All of the updates to this machine should be either updates (U) or patches (P). Watch the CVS update progress and verify there are no notices that there are unchecked-in changes on this machine (these would typically be identified as either merges, M, or conflicts, C). If there are any indications of unchecked-in changes on this machine these changes must be traced down and fixed as appropriate before proceding. There's no general rule for what to do when these discrepancies are found, the solutions must generally addressed on a individual basis. The one exception to this rule is when nobody can figure out what's changed (or why) and the classified system needs an immediate update. In this case just delete the entire module containing the offending code and check out a new version from the unclassifed CVS server.

Once this unclassified portal machine has been updated a tarball of the code using the following command:

cd ~; Transfer_JFORCES

This script will create a tarball named /tmp/jforces_xfer.tgz. Copy this routine onto a CD and take it to the classifed system. NOTE: Leave the unclassifed portal as it exists until either ready to transfer code from the classified system to the unclassifed server or you want to import a new version of the code from the unclassified system. This portal serves as a baseline of the code on the secure system and is a key component of code maintenance.

The classified system needs to have a code transfer user in addition to the general forces user. At Volk these users are named “xfer” and “forces” respectively. Log in as the xfer user. Mount the CD and extract the code using a line like:

cd ~; tar -zxvf /dev/cdom/jforces_xfer.tgz (the CD devicename might have to be modified for your installation)

Next, log off and back on the classified system (again as the xfer user). The reason for logging off & back on is to invoke any environmental changes that are part of the update. Then do a “big_make” and see if everything makes. A common source of linking errors is that one or more files deleted from the unclassified system still reside on the classified system. It's important that all of these files are found and removed both At this point you'll want to verify the system works before proceding. IMPORTANT: before checking the system it is important to clear out any temporary files created by forces users that the “xfer” user does not have access to. If nobody else is on the system the 800 pound gorilla method for this is to become root and clean out all temporary files in /tmp using a command like “ rm /tmp/*”. Then reboot for good measure. If you don't want to do this just switch user to the other forces user, go to /tmp, and delete each file owned by that user individually.

Once everything makes and checks out ( you DEFINITELY want to test the installation before proceding), the new code should be checked into CVS on the classified system. If you don't remember which machine is your cvs server, type “echo $CVSROOT”. Commit the transfer user's entire directory by typing:

cd ~; cvs commit -m “imported most recent unclassified code” > /tmp/notes

You can then look at /tmp/notes to verify that you don't have any unrecognized code that should be recognized (unrecognized code will be preceded by a question mark in this file). Typically I wouldn't do this. Instead, switch user to the production forces user in one terminal and checkout a new copy of the code from CVS (e.g. type “cd ~; cvs update”), close this terminal window and switch user to the production forces user in another terminal, and then issue a “big_make”. If new files have been added to the unclassified system they'll now show up as unsatisfied external references when the system builds. In this case return to the xfer user, find the files and BOTH add and commit them to CVS (e.g. cvs add (filename); cvs commit (filename)), return to the production user, go to the directory the file is in, and issue a “cvs update” command. Repeat until everything builds and then test the system.

Finally, there's often a need to transfer code from the classified system to the outside world. Naturally, this must be done with extreme caution to verify no classified data or code is taken from the classified system. But in the case of WIANG, there is no classified code. In this case we usually make a tarball of the code on the classified system by typing “cd ~; Transfer_JFORCES” and copying the resultant tarball (/tmp/jforces_xfer.tgz) to a CD. Then, after reverifying no classified information is on the CD, we take the CD to the unclassified system, mount the CD, and transfer the code to that system using a command like: “cd ~; tar -zxvf /dev/cdrom/jforces_xfer.tgz”. Afterwards the code should be result and checked on this system. If all is well then commit this information to the unclassified system (e.g. “cvs commit”). You might have to update the local code from CVS if any code's been updated externally since the last update. Please verify that this will not adversely affect the changes you're intending to put in the CVS system. Also, if you need to update this portal machine you might want to consider taking all updates back to the classified system as described above. Finally, after commiting the code from the portal system you'll want to go to another open JFORCES machine (e.g. Aries, lightning, or a laptop), update it's code with the new code in CVS, and rebuild and test. Again, verify that allo modules mak; this last step is required to verify that a new file has not been added to CVS from the classified system (it won't go to the repository if you don't add it and that would stop anybody else from building correctly).

Updating Static Data

JFORCES static data includes data found in the $DTA_DIR directory. Some of this data is under CVS control. Static data controlled by CVS includes the icon bitmaps and the database archive directory $DTA_DIR/db_prototype. Additional data that you might want to consider transferring to classified systems include 1) rastor map data found in $DTA_DIR/maps, and 2) geographic outlines found in $DTA_DIR/graphics. In all cases you'll want to use caution transferring these data modules into the classified system. Typically it's best just to update files on an individual basis instead of a bulk transfer. But transferring each directory in bulk is an option if you're certain that the incoming data will not destroy the existing data. To do this create a tarball “ of the directory (e.g. Cd $DTA_DIR; tar -zcvf bitmaps –exclude CVS”) and transfer it to the classified system and extract it there. Be sure to add the files to CVS when those modules are under CVS control. Alternately, make sure the files are transferred to each computer in the classified system.

Updating the DataBase Schema

Typically it's impossible to transfer the database between the classified and unclassified systems. Instead, the patches found on the JFORCES website (http://code-warrior/ftp/pub/postgres_support/patches/) should be retrieved, transferred into the classifed system using CD or floppy, and applied using the pg_apply_patch script. A README in this directory describes how to apply the patches. Note that these patches have names incorporating the patch dates and should be applied in order. It's best if these patches are applied only once. For that reason I usually keep a directory of applied patches on each computer hosting a database and apply only those with later dates should be applied. The patches should be moved to this directory after being applied.

Note that in production installations there's typically only one database server. This is the only machine that requires database patches. The database server can be found for any machine by looking at ~/.odbc.ini. If there are any problems please reference the JFORCES FAQ site on common database problems.