A Transparent UNIX/PC Conncection via NFS
Jonathan Feldman To an MS-DOS user trying to share files with an ongoing UNIX application, the never-ending file transfers required can get frustrating. FTP (File Transfer Protocol), which is widely available and allows users to transfer files ad hoc from one type of system to another, is not an acceptable day-to-day method of data entry. This article details a method of ending the "FTP-shuffle" by means of the also widely available NFS (Network File System) protocol. I implemented FTP software's PC/TCP-Interdrive NFS solution in response to a request from the Chatham County Tax Assessor's office for a system that would allow them to scan property photographs directly from an MS-DOS PC to an AIX filesystem. The plan entailed scanning from an MS-DOS PC using inexpensive color scanners (HP ScanJet II) and the free scanning software that comes with them. The FTP route was rejected as time-consuming and requiring additional training. Instead, the office requested a remote filesystem methodology, and to help with its implementation, the Chief Assessor devised a logical method of organizing the images -- there would eventually be thousands -- so that no one directory would get too many entries. The photos would be scanned into a multi-level subdirectory based upon municipality, map number, and parcel number. With the directory structure specified, the only thing left to do was to implement an NFS system that would act exactly like each clerk's D: drive. Given the office system's infrasturcture, there were two options available for implementing the cross-platform NFS. One option was to use a "server" architecture (I use the term loosely). This would be an NLM (NetWare Loadable Module) product that would run on one of the Novell servers. The users would treat the NFS-mounted volume the same way they would any other Novell files. The other option was to use an MS-DOS NFS client, which would involve loading appropriate drivers onto each PC. We chose to use an MS-DOS NFS client. Doing so bypassed the Novell box entirely, and would be more efficient in terms of network traffic and software overhead (see Figure 1). After some research into available client-based NFSs,we discovered that the solution was already installed on our network drives. Our office has a site-license for FTP Software's PC/TCP, a fairly complete TCP/IP implementation that coexists nicely with Novell drivers on a user's PC. Thus far, we had used PC/TCP only for Telnet services and FTP. We also used it as the TCP/IP stack for application software, such as AGE Logic's Xoftware X-Windows server and Unisys's DW-Mapper/Infoconnect, that uses TCP/IP as its transport medium. NFS services, called "Interdrive" by FTP Software, were included right along with the PC/TCP package. Implementation Before attemtping to configure all the scanning stations at once, I ran a pilot program. For my test I configured the Tax Assessor "taxonomy" AIX host to export the image filesystem. Then I configured a test PC for Interdrive operation. This turned out to be amazingly simple. I configured AIX to allow the scanning stations to mount the "images" filesystem by adding a line to the /etc/exports file (see Figure 2). I then ran the exportfs command to tell NFS that I had made a change. (You need to run exportfs by hand only if you don't want to reboot -- AIX will run exportfs for you when you reboot and export all the file systems listed in /etc/exports.) Other types of UNIX NFS servers look at the datestamp of the /etc/exports file each time somebody tries to mount a filesystem; they reread the file if the stamp has changed. I could have used the AIX system management tool, smit, to add the permissions, but I prefer to use the command line to explicitly tell AIX what I want to do. If you prefer to use smit to configure your NFS system, use the following chain of menu choices: Communications Applications and Services NFS Network File System (NFS) Add A Directory to Exports List Then fill in the screen appropriately, and hit ENTER to commit (see Figure 3). If you have a different version of UNIX, such as Dynix, hand-editing the /etc/exports file is your only option. Consult your system documentation to make sure that this is appropriate and see Figure 2 for an example entry). Most systems (such as AIX) ship with NFS configured to be self-starting. You can usually check this by typing
ps -ef | grep nfsd
and seeing if there are a few nfsd processes hanging around. If not, your system is not configured to act as an NFS server, and you may have to edit the appropriate system startup files: /etc/rc.nfs for AIX, /etc/rc2.d/SxxNFS for System V-style UNIX. Make sure that the lines that invoke /etc/nfsd, rpc.mountd, rpc.statd, and rpc.lockd are all uncommented. (Again, consult your system documentation for information on starting NFS on your particular system.) DOS Client Configuration I used FTP's KAPPCONF utility to configure my test PC. KAPPCONF is a setup program that edits your pctcp.ini, which is a file very much like win.ini or system.ini. KAPPCONF adds, deletes, or modifies stanzas depending upon what part of PC/TCP you're configuring. Using the menus, I told it that I wanted to mount a filesystem called "images" from the UNIX server called "taxonomy" onto the MS-DOS drive D:. I could have done this for any type of UNIX, not just AIX. I accepted the default values, and KAPPCONF modified my pctcp.ini accordingly. I saved the additional stanzas to a file (which I called idrive.ini, but you could call it anything you like) so that I could concatenate them to the scanning stations' pctcp.inis later (see Figure 4). I ran the NFS support driver, an MS-DOS driver called idrive. I Then tried mounting the filesystem using the PC/TCP idmnt -a (interdrive mount -all) command, only to get a "permission denied" message. I realized that I was using the wrong name for my PC in the AIX hosts file, so I changed it. Bingo! It worked. I played around with this for a little while, in Windows and in DOS, using various applications to see how robust it was. I did discover, after perusing the PC/TCP README files, that while PC/TCP supports using the UMB and EMS for its buffers, this is not only a bad idea under Windows, but is strictly forbidden. Apparently, there is a known bug in the PC/TCP kernel that does not interact well with Windows when it is using anything but standard memory. To protect against unexpected events, set any use-emm settings to "no" in your pctcp.ini file if you want to use it with Windows. Another requirement for using PC/TCP with Windows is that you must load PC/TCP's virtual 386 driver in the [386Enh] stanza of your system.ini. Also, remember to have a search path to the home directory of PCTCP. Our site uses the Novell command
MAP S1:=SERVER/DRV2:PCTCP23
so that the necessary PCTCP DLL files are locatable at all times. FTP also recommends adding a VPCTCP stanza to your system.ini to avoid possible software conflicts (see Figure 5). Once we had finished testing, I modified the boot floppies of the stations that would be scanning to include the necessary PC/TCP stanzas (Figure 4). This merely required concatenating the stanzas to each station's already existing pctcp.ini. Because we were concerned about MS-DOS base memory and could not load the drivers "high," I included the idrive and idmnt -a commands in each station's Windows startup batch file. At the end of the batch file, I included commands to unload the drivers when the Windows session was done (see Figure 6 for a sample batch file). Memory-conscious administrators may want to note that although we did not need QEMM for this particular application, it works well with PC/TCP and InterDrive. Remaining Issues The client stations are up and running and scanning away as planned. However, the J. Edgar Hoover types among you will have noticed that the MS-DOS clients are mounting the UNIX filesystems with very little in the way of security (hostname only). This is in large part because NFS doesn't have terribly good security in the first place. A further protection is that most users are incapable of the hostname-masquerading it would take to break this simple security. We have, however, drawn a line of demarcation between the mapping data and the images by giving the images a separate filesystem. The mapping data is not available for NFS export to anybody. Password security is available under PC/TCP, but we chose not to use it. (Most users have a plethora of passwords already. Moreover users can't even access the idrive or idmnt commands unless they log into the Novell network.) I leave the implementation of a more secure MS-DOS/UNIX NFS client as an exercise for the interested reader. Note, however, that high-security methods differ and can be vendor-specific, as in the case of IBM's Secure NFS. Be aware that other methods (such as user/password combinations) are easily compromised by the sophisticated user.
About the Author
Jonathan Feldman works with UNIX and NetWare at the Chatham County Government in Savannah, Georgia. He likes to keep things simple so that even he can understand them. In his spare time he writes, and grows roses and babies. He can be reached at 912/927-2096 or jonathan%degobah@ost.com.
|