Practical Linux: A Bosnian Experience
I'm a U.S. Army officer stationed in Darmstadt, Germany and forward deployed to the former Yugoslavia. Soon after coming to Europe in 1994 I discovered the “Linux Revolution” and have looked for innovative uses ever since. My first opportunity was with my unit in Darmstadt: I converted an unused 80386 machine with 8MB of RAM and a 120MB hard drive into a router/mailer/WWW server. Its primary purpose was to route packets between the 10Mb/s Ethernet and a 19.2 kb/s SLIP link into a DDN termserver. In the 20 months since it came on-line, it has never failed to provide reliable routing and dependable e-mail service.
When the US Army deployed to Bosnia as part of the Implementation Force, we brought with us a complex, impractical data lifeline. The backbone of Army tactical communications is a system called Mobile Subscriber Equipment. It provides between 13 and 58 secure, encrypted digital voice trunks and 16-64KB of encrypted data trunks. Every headquarters has a communications shelter outside with a BBN T/20 packet switch that routes TCP/IP traffic onto an X.25 packet switch network, effectively creating a giant, secure Class B network spanning all of Northern Bosnia.
The unsecured, unclassified portion of the network is provided by Motorola Network Encryption System (NES) boxes scattered throughout the theater. The NES boxes use a firefly algorithm to encrypt unclassified data, pass it over the classified packet network, and decrypt it on the other side, where it gets routed onto the DDN and evetually onto the Internet.
The plus side of this arrangement is Internet access to the soldiers in Bosnia. Originally, we intended to use the system to pass logistical and other non-sensitive data to the supporting elements in the rear, but it provided a way to pass non-sensitive data and morale e-mail as well. The pipelines are small, and the amount of data forced down them is huge, but it has proved to be an effective, if unwieldy system.
As the signal officer for one of the twelve US Brigades in Bosnia, I am responsible for the care and feeding of approximately 100 desktop and laptop computers, all running Windows for Workgroups with the Microsoft TCP/IP stack. The physical layout of the network at our Brigade Headquarters is quite tenuous: two 250m 10Base2 segments with 30 computers on one and 6 on the other, joined by an Ethernet repeater. In the rough and tumble military world, it's almost a full-time job keeping the cable and all connectors together, dry, and passing data.
The Linux solution stems from the need for a centralized SMTP gateway and information warehouse. The machine is a Pentium 166 sitting on an Intel Atlantis motherboard, with 512KB of cache and 64MB of RAM, with just under 2GB of storage. I'm running kernel version 1.3.100, completely ELF and modularized.
Before I came on the unit, Pegasus mail (a free POP3-based mail client for MS Windows) was used to retrieve mail from various e-mail hosts in Germany. Because of the low bandwidth, users were waiting 5-10 minutes to download just a few messages, and users' mail was “trapped” on the computer used to retrieve messages.
My solution involved the Samba package coupled with the security built in to Windows for Workgroups. I used Samba to export the /home directory of the server, and created user accounts for everyone. The Pegasus mail executables and library files were put in the /home directory with 640 permission flags and root:users as the owner:group. Windows users were then instructed to attach (in Windows parlance) the \\MAILSERV\MAIL share as their M: drive. The Pegasus initialization file required that I use a static drive label (M:, for mail) The user then created an icon in Windows pointing to the M:\WINPMAIL.EXE file.
Adding users was tedious until I broke down and wrote a Perl script to create the entry in /etc/passwd and personalize a generic PMAIL.INI file that was copied over from the /etc/skel directory.
The result is a secure, seamless e-mail server that allows users to log in using the familiar WfW login prompt and run a common e-mail client from any PC on the network. Pegasus uses POP3 to download mail from the Linux box, then stores the mail on the Linux box in the user's home directory. Outgoing mail is sent to the Linux machine for delivery; unreliable links and slow network response made it too easy for a user to leave mail stuck in the outbound queue when he shut down the e-mail client.
One additional advantage of the Linux box on my network is that I can run my own name server. I began with Nicolai Langfeldt's caching named mini-howto and set all my Windows clients to point to the Linux machine as a primary DNS. I discovered that a significant chunk of my bandwidth was disapearing due to net surfers. I tried to limit the number of browsers my users had, but I found it was easier to send the browsers bogus IP addresses for certain “unsavory” sites that shouldn't be visited with a government computer. I told my named to return the IP of the Linux machine, and created a web page to scold my serious offenders. Everyone got a chuckle out of it, and I got my bandwidth back to a usable level.
I have also been able to provide a whois server for a sizable chunk of the deployed soldiers with e-mail accounts, and an intranet web site with photos and info pertinent to the command.
The Samba programming team has put together an excellent package that allows me to cater to the users' demand for a Windows operating system without tying me to the propriatary e-mail and server programs of Windows NT. I look forward to future releases of Samba that will include domain services and validation, and I'm always on the lookout for new ideas and applications for Linux.
1LT John Gorkos is the Communications officer for the 16th Corps Support Group. He hacks Linux when he's not making radio checks or splicing telephone cable. Since there's not much else to do in Bosnia right now, he divides his time between work, lifting weights, and sleeping. He can be reached by e-mail at email@example.com.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Google's SwiftShader Released
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Interview with Patrick Volkerding
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Tech Tip: Really Simple HTTP Server with Python
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide