Linux in Antarctica
I was approached in September 1993 by Martin Hendy at AUSLIG (Australian Surveying and Land Information Group) to give him some information about Linux to see if it was suitable for a large project they had underway.
After I showed him a couple of Linux systems and gave him a rundown, he decided to go ahead, and the end result is that there are now eight Linux boxes scattered around Australia, gathering data on the Global Positioning System. The current systems are at Darwin, Ceduna, Alice Springs, Mawson Base (Antarctica), Davis Base (Antarctica), Casey Base (Antarctica), Macquarie Island, and Hobart. More are planned for other parts of Australia.
The application is a data gathering one. The Linux boxes are attached via serial ports to a “TurboRogue” satellite receiver system, which monitors the 32-satellite Global Positioning System. Data is downloaded from the satellites and stored in a 4MB flashcard in the back of the TurboRogue, and from there it is downloaded to the Linux systems. These systems store the data and forward it to a base system in Canberra.
The monitoring of the GPS system is essential for accurate surveying work. Some other countries (notably Canada) have set up similar networks for the same purpose.
Some of the Linux systems are connected directly to AARNet via Ethernet (yes, Antarctica is networked!) while others have 14.4 Kbps modems and download data via scheduled cron jobs, using the term package. Even the machines on the net have modems, as we can't absolutely rely on the network link.
The Antarctic Linux systems are Digital 48633DX MT PCs with 8MB RAM. They have two 345MB IDE hard disks, with only one electrically connected, (the other is identically configured as a backup). They have one 1.44MB floppy drive and a spare floppy (again, not connected). They have WD8013 Ethernet cards and DataLink 14.4 Kbps modems.
The Linux systems for the other Australian sites are rack-mounted “clone” PCs, for various reasons. They are identically configured.
Each system has four serial ports, each on its own interrupt. We achieved this by making some minor modifications to a cheap 2-port serial board we bought in Canberra. The more recently installed systems have eight serial ports using two 4-port cards. The extra serial lines allow for control of more equipment.
The other custom hardware is a “rebooting module” designed and built by Anthony Wesley here in Canberra. It is a small box that attaches to a serial port, a power lead and the reset line of the computer. Basically, it expects a “healthy” signal from the computer every five minutes on the serial line, or else it “presses reset” by shorting the reset line for 30 seconds. These boxes are very rarely needed, but it's good to know that they are there.
A process runs a script to check half a dozen things every minute and outputs the “healthy” signal if they all pass.
The systems originally ran 0.99pl12 with a few patches. I chose this because I have found it stable for my own use. We have upgraded (only rarely) when we needed particular features or bugs fixed. One of the features of having the PCs running Linux (they were considering DOS) is that we can completely replace the system remotely, either via modem or the net.
Each hard disk has four partitions: a DOS partition with their old software on it (just in case), two Linux root partitions (identically configured), and a data partition (the bulk of the disk).
The Linux root partitions are 20MB and are only half full! Most of them are, in fact, taken up with things that are only included “just in case”, like kernel sources, gcc, sources for the TurboRogue controlling software and even Emacs 19.16 (to make life a little easier).
I have designed the system to be very small. It is small enough, in fact, that the whole system can operate from a single 1.44MB floppy if I leave out the “optional extras”. This is achieved by having the whole of the /usr tree in a compressed tar file which uncompresses onto a ramdisk on bootup, and having next to nothing outside of /usr. The systems on the hard disk are already uncompressed.
This means that in case of emergency we can tell the on-site operators to insert one of the duplicate “Emergency root disks” and we can operate the complete system remotely just from the floppy, including disk-fixing tools like fdisk and e2fsck.
cron is used to control the regular downloading of data from the TurboRogue and transmitting the data to Canberra. Checksums are used to ensure the data is correctly transmitted, and it is re-transmitted if necessary.
Since October 1993, when the first systems in Antarctica came on-line, an enormous amount of data has flowed from the remote systems to the main system here in Canberra. It is a great credit to Linux that it has performed so well under difficult conditions. Congratulations to Linus and all the Linux developers!
Andrew Tridgell has been involved in the Linux community since December 1992. He has worked on a number of projects, including DOSEmu, the “Linux in Antarctica” project, some TCP hacks, and, more recently, Samba. He is currently the convener of the Canberra Linux Users Group. Andrew and his wife Susan live in Canberra and enjoy bushwalking, sailing, watching TV, speaking Swedish, and eating pizza.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Ubuntu Online Summit
- Devuan Beta Release
- The Qt Company's Qt Start-Up
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- The US Government and Open-Source Software
- May 2016 Issue of Linux Journal
- The Death of RoboVM
- Open-Source Project Secretly Funded by CIA
- New Container Image Standard Promises More Portable Apps
- BitTorrent Inc.'s Sync
In modern computer systems, privacy and security are mandatory. However, connections from the outside over public networks automatically imply risks. One easily available solution to avoid eavesdroppers’ attempts is SSH. But, its wide adoption during the past 21 years has made it a target for attackers, so hardening your system properly is a must.
Additionally, in highly regulated markets, you must comply with specific operational requirements, proving that you conform to standards and even that you have included new mandatory authentication methods, such as two-factor authentication. In this ebook, I discuss SSH and how to configure and manage it to guarantee that your network is safe, your data is secure and that you comply with relevant regulations.Get the Guide