Click on our Sponsors to help Support SunWorld
Sysadmin by Hal Stern

The executive file fandango

Hypothetical tidbits to test your emergency-response acumen

October  1996
[Next story]
[Table of Contents]
Subscribe to SunWorld, it's free!

Handling problems in the field can be made much easier with a little preparedness. This four-part exam tests your ability (and capability) of dealing with sysadmin flame-outs from afar. (2,500 words)

Mail this
article to
a friend

Welcome to the SysAdmin practical exam. Put down your mice, grab a piece of #2 insulated wire, and prepare to give some serious answers.

Your favorite senior executive, Ms. B, is jetting across the country to give a presentation to a major potential customer. She is carrying a laptop running Windows 3.1 with a 14.4 kbaud modem, loaded with all three corporate standards for presentation packages and a garden-variety terminal emulator. There isn't a TCP/IP stack on it, but you suspect a rogue installation of America Online despite your company's insistence that these laptops not be used for personal Internet browsing (Note to quiz-takers: any snickering will preclude your use of this clue to solve Part Three below). There's a copy of the presentation tucked away on your Sun server so it can be backed up, archived, and eventually put up on your corporate marketing Web pages after Ms. B's triumphant return. Life is good enough that as a system administrator, you get worried.

At 1:00 a.m. your beeper wakes you from a wonderful dream about rewiring your half of the building with 100baseT Ethernet. It's you-know-who, and it seems there's been a little problem with her presentation. A few random keystrokes led to some unintentional editing, and now the 20-slide show is reduced to two images, one of which has the words "Poor Scalability; Lacks Reliability" superimposed over an image of your company's president. You have eight hours to reconstitute B's material in the field. Not a pretty sight, especially in your present condition. This month, we'll look at four increasingly complex solutions to this problem, using a variety of Unix and PC tools to encapsulate, transmit, compress, and otherwise transmogrify marketing bits into useful data and back again.


Part One: Pass the buck
The obvious solution is to go back to B's office, pop a floppy in the A: drive, and make a fresh copy. Pass the buck-a-shot media into a Federal Express envelope along with a note on how to copy the file back onto her laptop. Too bad you missed the Federal Express drop-off window by at least five hours. Relying on the twenty-five years of creativity, knowledge, and organized chaos that is Unix lore, you remember that you have a small engineering group in the general location of your fielded executive. They don't have PCs, but you're sure someone has a floppy to go along with the floppy drives they ordered in their SPARC workstations. You page the local system administrator, and walk through the following steps.

Solaris includes a DOS-compatible filesystem called pcfs. If you want to copy files onto a DOS-format floppy, insert the floppy in the drive, and mount it:

luey# mount -F pcfs /dev/fd0 /pc 

Copying files to /pc loads them on the floppy, and you can gauge the space remaining on the disk using df -k. All of the usual Unix commands work on the PC filesystem, so you can create directories, rename files or directories, and even use tar to ship entire directory trees to the target disk:

luey% cd /home/stern/pc
luey% tar cf . | ( cd /pc ; tar xvf - )

The example above creates a tar archive of the current directory and then explodes it under /pc. When you're finally finished filling the floppy, use eject to free the disk, and have a courier drive it to Ms. B's hotel.

DOS 8.3 filenaming conventions are implicitly enforced by pcfs. The first eight characters of a Unix filename become the prefix, and the first three after any initial dot become the suffix. There is no conversion of long names, capitals, non-acceptable DOS filename characters, or other filename mangling done by pcfs, since it tries to obey Unix filesystem semantics. Note that this is distinctly different behavior than you'll get using WABI, SunPC, or PC/NFS, where you have DOS semantics imposed on Unix filenames. When you're looking through Redmond colored glasses, long or varied Unix filenames are made DOS-acceptable; when you're mounting the DOS volume on Unix it's up to you to ensure filenames are unique.

For example, try copying a pile of Frame documents onto a floppy when they're named bookchap1.doc, bookchap2.doc, bookchap3.doc and so on. You'll end up with exactly one file on your pcfs volume named bookchap.doc. Here's an overly simple script that guarantees uniqueness in the 8.3 world:

#! /bin/sh
for i in $*
	ecn=`basename $i`
	ecn=`echo $ecn | tr ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz`
	ecn=`echo $ecn | sed -e 's@\.@-@g' -e 's@\+@@g'`
	namelen=`echo $ecn | wc | awk '{print $3}'`
	ecn=`echo $ecn | cut -c1-8`
	if [ -f $ecn -a "$i" != "$ecn" ]
		ecn=`echo $ecn | cut -c1-6`
		while [ -f $ecn ]
			count=`expr $count + 1`
	if [ "$i" = "$ecn" ]
		echo $i becomes $ecn
		mv $i $ecn

If you have the volume manager running and watching the floppy drive, you won't need to perform the mount operation as root. Instead, let the volume manager identify the new DOS volume and mount it under /floppy:

luey% volcheck
luey% cd /floppy/floppy0

vold looks for a DOS volume label on the floppy, and will mount the diskette using that name as a mount point if one is present. Had your diskette been given the label crisis when you formatted it, you would have seen it mounted as /floppy/crisis. If there's no label, the floppy becomes /floppy/unnamed_floppy, and in either case, floppy0 is a symbolic link to the current mounted diskette. When you're done moving data to the floppy, eject again spits out the media.

Scoring: Give yourself one point if you thought that was a trivial example, two points if you've already played with pcfs, and three points if you know that the floppy uses programmed I/O and not DMA, making it a real pig on the CPU.

Part Two: All alone on the telephone
Consider Part One a warm up for the real test of your data manipulation skills. Let's forget about the office close to your executive. You need to solve this one using a telephone, a modem, and a terminal emulator. Fortunately, nearly every commerical terminal emulator, including the default application in Windows, supports some kind of file transfer protocol. Our approach in this case is to have Ms. B dial in to the Unix server, and then use Xmodem to slurp the binary file down to her PC.

Xmodem and friends send text (ASCII) or binary files with error-checking and retries on errors. You can be reasonably sure that a file transferred with one of these protocols will arrive intact on the other end. The Unix versions also understand how to convert from DOS-delimited ASCII files to Unix conventions, so extra control-Ms at the end of the line and control-Z end of file markers will be removed when you upload files from a PC to your Unix server.

Xmodem is a fairly crusty protocol, having been around since 1977. Ymodem is a better version, using 1,024-byte transfers instead of the 128 (really old) or 256 (slightly more modern) buffer sizes used by Xmodem. Zmodem is still better yet, but as you get more recent, you'll find fewer and fewer off-the-shelf emulators that support the protocol. Find out more by exploring c|net's on-line glossary.

Here's a script to walk through as you negotiate a file transfer to parts unknown:

Scoring: Give yourself only one point if you asked if this works over ISDN. Score two points if you think that building a PPP connection and using ftp would be easier, and mark a high score of three points if you know that Xmodem uses a cyclic redundancy check (CRC) to ensure that payloads arrive without bit errors.

Part Three: Ms. America, Online
Going the dial-in route begs a host of questions: What if you don't allow dial-in access? What if your key executive did not have her digital token card, or S/Key passwords, on her person? What do you do with a binary file and a seven-bit dial-in modem pool and access route? When in doubt, it's e-mail to the rescue.

The trivial solution is to mail the presentation to Ms. B, and let her pick it up from a dial-in mail server. She can save the file locally, and your job is (almost) done. Alternatively, you can call her bluff on the America Online installation, and mail the document to, and allow her to use AOL's download facility to save the message to her laptop's disk.

Trick question: how do you get the binary file through your Unix mailer (which is probably not eight-bit clean) and through the other mailers along the way, which require ASCII-only input? Using Sun's mailtool in the Open Windows environment, you'll find that binary attachments are handled using uuencode, a tool designed to expand binary files into ASCII representations. Do the same for Ms. B's talk, preparing an ASCII file to be mailed:

luey% uuencode talk.ppt talk.ppt > talk.uu
luey% mail  < talk.uu

The first argument to uuencode is the name of the local file to be encapsulated by uuencode. The second gives the name of the file as it should be exploded by the decoding process, and the output is tucked into a file suitable for mailing. The downside to this approach is that you need a uudecoder on the laptop. You'll find a suitable one called uucode on America Online, so you can have Ms. B bootstrap the repair process by downloading and installing that first. There are several versions of uucode available for downloading on the net as well.

Scoring: Take one point if you thought that you might miss the eight-hour completion window waiting for mail to be delivered outside your site to Add two beans if you thought that using a MIME-compliant mailer would eliminate the uuencoding mess, and join us again in a few months for a further MIME discussion. Finally, score a trey if you realized that this is a security hole, since you're broadcasting sensitive customer material in the clear to a most popular Internet target. Give yourself another bonus point if you thought of using PGP to encrypt the file and sending it as an ASCII armor text file, a solution that works fine if you've taken the time to configure PGP and distribute keys before people hopped onto airplanes.

Part Four: Problems of size and number
Our final twist on this tale involves a file that's too big to fit on a single floppy, multiple file transmissions that may prove difficult to do in sequencing and installation, and the problem of time. What do you do when you give someone instructions using filename as a placeholder in an example, and then they call you back and ponder why "It's asking me if I want to overwrite file FILENAME?" Moving one file is often traumatic enough.

At 14.4 kbaud, you're looking at about 1,000-1,500 bytes a second depending upon the modem's compression, line noise, and the exact protocol used. Sending a three-megabyte presentation, complete with corporate clip art, will chew up more than an hour; sending several talks may take you outside of your time-to-repair window.

The appropriate Unix solution is to create a tar archive of the multiple files, compress it, and then pull it with Xmodem or mail it to the recipient. There's a PC utility called pkzip or zip that combines both functions. Don't confuse this utility, written by Phil Katz and distributed as shareware by his company PKware, with the GNU utility gzip. The latter uses the same compression algorithm but doesn't handle multiple files in a single archive. The two aren't interchangeable. You'll need to get a Unix version of zip to get started; find out more about the shareware PC version from the somewhat funky Link Everything Online (LEO).

Creating a zip archive on your Unix system is similar to building a tar file:

luey% zip talk.ppt talk2.ppt talk3.ppt
adding talk1.ppt (imploded 86%)
adding talk2.ppt (imploded 84%)
adding talk3.ppt (imploded 68%)

You'll see each file being added to the archive, and the compression ratio achieved. It's not unusual for zip to compress a Powerpoint presentation by 8:1 or 10:1, making it the preprocessor of choice when dealing with dial-up lines. Extracting files from the zip archive is just as easy:

C:\> pkunzip

The unzip utilities support a -v flag to let you inspect (view) the contents of the zipfile without extracting anything:

C:\> pkunzip -v
Length  Method   Size  Ratio   Date    Time   CRC-32     Name ("^" ==> case
 ------  ------   ----  -----   ----    ----   ------     ----   conversion)
690688  Implode  95055  86%  05-22-96  19:28  06324b19   talk1.ppt
399872  Implode  62961  84%  09-23-96  23:12  24f0763e   talk2.ppt
 63488  Implode  20291  68%  10-08-96  10:36  be8646e2   talk3.ppt
------          ------  ---                              -------
1154048          178307  85%                              3      

You'll see the files in the archive, their compression ratios, and their true size upon explosion. Taking selected files from the archive by specifying their names on the pkzip command line will save you time and disk space, both of which may be precious commodities.

Scoring: Receive one point for knowing that version 2.04g is the latest revision of pkzip, and that anything claiming to be version 3.00 or version 3.00b is actually a trojan horse virus that is remarkably dangerous to your PC's hard drive. Two points are awarded to readers that know about winzip a Windows GUI on top of the zip utility that may make navigation of the options and archive explosion easier for the DOS-challenged. Winzip also handles tar files and files reduced with the Unix compress utility. Finally, give yourself three points for knowing that zip2exe turns a zipfile into a self-extracting DOS executable. This tool must be run on a DOS/Windows machine, however. Converting the archive into something runnable is ideal if the recipient doesn't have pkunzip already installed.

Are there some practical lessons to be learned from this month's rapid romp through crisis intervention? Pre-load file transfer, archiving, and encapsulation tools on any mobile equipment. Insist that key presentations and materials be kept on a centrally managed server so they can be retrieved or restored in the event of an emergency. Review procedures for shuffling files and ensure that each non-technical traveler has a data steward familiar with his or her configuration and data conversion needs. You may not get many accolades for being conscientious, but at least you'll garner a few more nights of sleep.

Click on our Sponsors to help Support SunWorld


What did you think of this article?
-Very worth reading
-Worth reading
-Not worth reading
-Too long
-Just right
-Too short
-Too technical
-Just right
-Not technical enough

[Table of Contents]
Subscribe to SunWorld, it's free!
[Next story]
Sun's Site

[(c) Copyright  Web Publishing Inc., and IDG Communication company]

If you have technical problems with this magazine, contact

Last modified: