RSSWORKSHOPSSharing Files In A Web World Via NFSby Don Mac Leod File and print service has become as ubiquitous as blonde hair in SouthernCalifornia. We're not just saddled with solutions that come only from Orem.Although providing file and print services has become increasingly commonplace,providing Web, or more specifically, HTML source page editing to multipleusers is still on the fringe. What we're talking about is native accessto HTML sources, regardless of the client platform and OS. NFS is one excellentsolution to this dilemma. It's a solid technology and it works great. Sun Microsystems' NFS has been around for years and has been recently revised(see RFCs 1094 and 1813; http://ds.internic.net/rfc/rfc1094.txt and http://ds.internic.net/rfc/rfc1813.txt ),yet it has never achieved the market acceptance on the desktop accordedto other similar technology. The reasons are many, but the two most oftenmentioned are performance and the memory requirements of the NFS client. Putting Theory Into Practice At Syracuse University, our departmentalWeb server (netsys.syr.edu) runs on a 32-MB Sun SPARC 2 running Solaris2.4. In the past it was a RS/6000 running AIX. In the future it may be anIntel box running NT. Or maybe a... well, you get the picture. We have trieda number of ways to provide native access for our users to edit their pageson n etsys, but nothing has proved universal ("What do you mean Solsticefor Solaris 2.x doesn't support Macs!") and a change in platform hasalways required reengineering the system. That has left us with FTP as theonly universal access. NFS became an obvious solution to the universal access problem. Our clientsnow are all running more capable OSes and have sufficient memory in theirmachines, so performance isn't an issue because only a few users requireaccess, and they require it infrequently. We tested a collection of thelatest examples of NFS products for various platforms, particularly fortheir interoperability capabilities. We examined the following software: IBM AIX (4.1.4 and 3.2.5); IBM OS/2Warp Connect with the TCP/IP 2.0 NFS Kit; Tenon Intersystems MachTen; FreeBSD2.2; Sun Solaris 2.4; and Intergraph DiskAccess for Windows95, PC-NFS forNT and DiskShare for NT. The goal was to see what the pitfalls might befor different clients when editing HTML pages, which were accessed via NFS-mounteddirectories. Configuration and Setup Getting the Unix systems to interoperatevia NFS was not a problem, but each flavor does have its own incantation.FreeBSD has the most traditional implementation, even though the code isn'tfrom Sun. Solaris has now adopted the "share" nomenclature forexporting file s ystems and hides them in /etc/dfs/dfstab instead of thetraditional /etc/exports. The AIX versions use traditional mount and /etc/exportsconventions, but they also wrap the commands in their System ManagementInterface Tool (SMIT) to provide a menu-driven interface for novice AIXadministrators. On the Macintosh platform, MachTen is an amazing beast. In essence it isa complete BSD-style Unix system running as an application under the MacOS.The whole system comes on 10 diskettes and installs like any other Macintoshapplication. Upon starting the MachTen "application," a terminalwindow appears and the equivalent of a Unix system boot takes place withinthe window. The ne tworking facilities are familiar BSD-style Unix and theNFS functions employ the expected mount and /etc/exports constructs. Theremarkable part is that the MacOS can be made to see the Unix part of thesystem and vice versa. IBM's implementation of NFS for OS/2 Warp Connect is the same product ithas been shipping for OS/2 f or quite a while. It does require a patch towork with the version of TCP/IP included in Warp. Configuration can be accomplishedthrough OS/2's notebook metaphor configuration menus or by directly editingvarious configuration files. Unix administrators may prefer to directlyedit the CONFIG files, since these files are almost identical to the /etc/fstaband /etc/exports files with which they are already familiar. The Intergraph products for Windows95 and NT are clearly the newest andmost Windows-like of the group. Installation is the standard Windows "blue-screen"setup program. Configuration requires a PCNFSD or NIS server on the localnetwork (more on this later). Once the configuration is complete and theuser is authenticated, access to exported file systems is accomplished throughthe same File Manager/Network Neighborhood model used for accessing othernetwork resources. The integration into the existing Windows95 interfaceis very impressive. Potholes and Rainbows In the early days of desktop NFS, three problemswere of major concern. First, all host-based file names (that is, Unix)had to be converted to 8.3 DOS file names. The ability to mitigate namingconstructs among different operating systems is inherent in the NFS protocol,but the resulting "manufactured" file names were often difficultfor users to decipher. (Take a look at the "native" NetWare namesfor Macintosh files and you'll get the idea.) Second, DOS and Unix use different character sequences to determine theend of a line. For example, DOS wants a carriage return/line feed pair (0xD/0xA)to indicate an end of a line, while Unix is happy with just a line feed(0xA). In contras t, Macintosh uses a single carriage return (0xD) to indicatethe same thing. Finally, NFS performance was never comparable to that ofcompeting technologies, especially NetWare. The naming issues are far less problematic than they once were, since allof the newer systems can handle long file names, but some issues sti ll persistthat require the protocol to intervene. In general, names are still limitedby the individual operating systems. The end-of-line issue has traditionally been solved by passing text filesthrough a filter that adds or deletes appropriate characters. These facilitiesstill exist, but they are inconvenient and often result in documents thatrequire further reformatting. All of the platforms were able to ingest foreigndocuments given a capable enough editor/word processor. We used Describewith OS/2, Win95 and NT; Framemaker with Unix and BBedit with Macintoshwithout problem. The obvious solution is to settle on a universal word processing formatfor your organization and the "text" problem won't be an issue.Most users will already have a word processor, like Word, that would bea likely candidate for a reference format. However, be aware that olderdocument processors, such as those for Win3.1, will not work with the longfile names. In our particular test we were editing HTML documents, which aren't verypicky about formatting since the browser reads in a string of characters.This means that you can put one platform's HTML text on the NFS-mounteddirectory of another platform and export the Web page to the world withoutmuch concern for the formatting of the source. With regards to performance issues, Sun has addressed that directly withits most recent release-version 3-of the protocol (see RFC 1813). Amongother things, it implements a client-side caching mechanism that can greatlyreduce the number of server requests for frequently accessed data. Sun,Intergraph, IBM's AIX and FreeBSD all support the new protocol. The restare sure to update their implementation s oon. In all, using these new NFS products is more seamless than we expected-onceeverything was installed. Installation is still a problem in some casesand often only because the vendor is not particularly flexible in the wayit intends users to implement the product. Intergraph offers no way to establisha stand alone client with basic mounting rights. Its products insist on "authenticating"against a PCNFSD server. Its Win95 product DiskAccess also supports authenticatingagainst a NIS domain. These features are of great benefit when installing a large number of workstationsinto an existing NIS-based environment. Its lack of flexibility is troublesomefor lesser implementations, where setting up an NIS domain or a PCNFSD serverwould be considered unnecessary overhead. When we contacted Intergraph to inquire about this predicament, we weretold the company implemented "authentication" in this fashionfor the sake of security. We pointed out that authenticating via a user-definablePCNFSD or NIS server does not provide any level of security, since userscan force a query from a host of their own design. Intergraph didn't seemto understand this until we described a security-flawed scenario. Establishing IDs In our scenario we ran both Intergraph's NFS server(DiskShare, which includes a PCNFSD daemon) and NFS client on the same box.We were then able to establish whatever user ID we wanted by simply pointingthe "authentication" process on the NFS client to the PCNFSD processrunning on the same machine. In reality, NFS security is entirely basedon a server's ability to "trust" a client and by the manner inwhich volumes are exported (for example, read-only). Our concern with this experiment was to evaluate NFS as a medium for universalaccess to a departmental Web server in a heterogeneous environment. We foundit a viable alternative. We also learned that this might be an attractivealternative for heterogeneous departments on a budget. For example, MachTenon a Macintosh makes a fine Web and NFS server and both services come bundledwith the product. Likewise, adding Intergraph's DiskShare to an NT Workstationalong with IBM's free Web server (which unlike Microsoft's product supportsNT Workstation) can create a very low-cost Intel-based server. Don Mac Leod is manager of network integration at Syracuse University.He can be reached at dmacleod@syr.edu. What Does The Future Hold For NFS?We're sure all the LAN Manager and NetWare system administrators out thereare wondering why anyone would even consider using NFS for sharing files.After all, their platforms can support most clients adequately and manysites simply avoid the heterogeneity issue by mandating against troublesomeplatforms. But the Web might bring NFS into their shops in the very nearfuture, whether they want it or not. Sun has recently announced a proposed specification for a "public"version NFS for use in Web servers it is calling WebNFS (http://www. sun.com/sunsoft/Whats-new/pubnfs.html).Sun is already talking with major Web browser developers and is hopefulthat it will include support in its products in subsequent releases. Withsupport from browser vendors we should be able to use URLs in the form ofnfs://server/path. Sun has at least three very good reasons to support such a product. First,Sun's demonstration tests have shown WebNFS to be as much as 10 times fasterthan HTTP in downloading files. The additional speed may affect the waypeople use Web servers in the future. Second, WebNFS would allow users toleverage the existing Sun NFS servers in their organizations. Finally, WebNFSwould greatly enhance the capability of a Java-based Internet PC. With theinclusion of WebNFS, the mythical Internet PC starts to look an awful lotlike the early diskless workstations on which Sun built its company. UpdatedJune 14, 1996 |
