AccessNFS

Intergraph offers several productsto accomodate NFS access from NT

Intergraph has a rich history of experience with UNIX. As Tommy Steele discusses in the sidebar, "Intergraph Maps Out Its Future with NT," Intergraph started out as a hardware manufacturer and software developer for the UNIX CAD market. In 1991, Intergraph made the dramatic decision to switch over to Windows NT and focus its hardware and software resources on the NT market. One of the by-products of Intergraph's market shift was the development and release of a series of UNIX-NT integration and coexistence software products.

Intergraph Software Solutions (ISS) develops, markets, and supportsIntergraph's UNIX-NT products. The flagship of ISS's UNIX-NT offerings is theAccessNFS line of products. AccessNFS includes DiskShare, a server-orientedproduct that lets an NT system emulate an NFS server; DiskAccess, a client-sideproduct that lets an NT system access an NFS server; and AccessNFS Gateway, anew server-side product that lets an NT system access an NFS server without anyclient-side software.

I recently had the opportunity to work with a beta copy of AccessNFSGateway and the most recent release of DiskAccess (version 3.01.00.11). Bothproducts offer new and unique features in any combined UNIX and NT environment.

AccessNFS Gateway
In a nutshell, AccessNFS Gateway lets you mount NFS directory and printerexports on a server system and re-share them on the native Microsoft network asstandard Server Message Block (SMB) shares. Conceptually, AccessNFS Gateway issimilar to Microsoft's Gateway Service for NetWare in that it effectively remapsa foreign file and print sharing methodology into the Microsoft file and printsharing methodology. But don't linger on the comparison to Gateway Service forNetWare too long. AccessNFS Gateway takes a more sophisticated approach thanGateway Service for NetWare does.

Establishing the connection between an AccessNFS Gateway server and one ormore NFS server systems is straightforward. You can establish multipleconnections, and each connection can use a different username forauthentication. As you'd expect, AccessNFS Gateway lets you map an NT usernameinto its UNIX counterpart and supports authentication using either the NetworkInformation Service (NIS) model (traditionally used for UNIX-to-UNIXauthentication) or the PC NFS daemon (PCNFSD) model (usually used for PC-to-UNIXauthentication).

Once the AccessNFS Gateway server has been authenticated to an NFS serveror two, it can mount exported directories and printers. Those directories andprinters are then available as shared resources sponsored by the NT systemrunning the AccessNFS Gateway server. In other words, you bring up the NetworkNeighborhood map, click the NT system running the gateway software, and the NFSdirectories and printers appear in the list of resources. Because AccessNFSGateway uses standard Microsoft file and print services to deliver NFSresources, any Microsoft network-aware client operating system--including DOS,Windows 3.1, Windows for Workgroups, Windows 95, and, of course, NT--can accessNFS directories and printers.

As with other gateway approaches, the big question is: How is file-levelsecurity handled? For example, if you use Microsoft's Gateway Service forNetWare, NT establishes all access rights according to the privileges assignedto the single server-side user ID that manages the NetWare connection. Incontrast, AccessNFS Gateway lets you use the user ID of the client accessing theshared resource. To accommodate this method, AccessNFS Gateway provides amapping table that translates an NT username into its UNIX counterpart. Namesnot contained in the table are passed through directly. Given this approach, theUNIX-side access security remains completely intact--access to individualdirectories and files is based on the UNIX-side settings.

DiskAccess
I originally reviewed ISS's client-side NFS product, PC-NFS, in the December1995 issue. Since that time, the product has matured a great deal. The mostimportant change is that the product no longer uses the PC-NFS code thatIntergraph codeveloped with Sun Microsystems. Although for years this code wasthe de facto standard for PC-to-UNIX NFS access, implementing the codein the NT environment introduced more problems and limitations than it solved.ISS obviously recognized these limitations because the company dropped thePC-NFS code from the product and changed the product name from PC-NFS toDiskAccess.

The current DiskAccess release lets you authenticate the system to an NFSserver during the NT logon process or at the time of connection. You can alsouse different authentication servers at connect time. This option isparticularly useful and is not in most client-side NFS software on themarket--most products authenticate you one time to one host. DiskAccess supportsauthentication using either the PCNFSD or NIS methodology.Screen 1 shows theAuthentication tab of the DiskAccess dialog box where you select theauthentication host and type (NIS or PCNFSD).

DiskAccess maintains the user authentication information separately foreach user profile. Again, you won't find this feature in most NFS clientproducts. If this feature does not seem important, consider this scenario: Ifyou want to implement NFS in a multiuser context (e.g., using NFS in conjunctionwith Citrix' WinFrame, NCD's WinCenter, Tektronix' WinDD, or Insignia'sNTRIGUE), support for multiple, concurrent NFS authentication is critical.DiskAccess addresses this need and the simpler case of a common workstationshared among multiple users.

DiskAccess does not provide a separate user interface for accessing NFSdirectories and printers; you simply use the standard Network Neighborhood (orFile Manager or Print Manager) utility to browse your network. AsScreen 2shows, an NFS Network entry appears on this list of available networks. When youdouble-click this entry, you see additional networks containing your NFSservers, much like domains on an NT network. This list lets you target subnetsyou want to browse for NFS services. This approach lets you locate NFS resourcesbeyond your local net, bypassing a limitation users experience routinely whenrouters segment their networks.

After you browse for the server you want, double-click the exporteddirectory or printer to access it as if it were a native Microsoft networkresource. This option is faster than having DiskAccess search entire networksegments for all available NFS servers, letting you browse only the systems youdefine.

In addition to providing access to NFS directories and printers, DiskAccessincludes a set of utilities, including Telnet, TN5250, and TN3270 for terminalaccess; a graphical FTP program for file transfer; a Domain Name System (DNS)Query program for name-to-address lookups; Show Mounts and RPC Information toprovide details about server-side settings; and Ping for basic name and addressverification. DiskAccess also includes services to implement Remote Shell (RSH)for remote command submission and Network Time Protocol (NTP) for network timesynchronization.

So Many Choices, So Little Time
AccessNFS Gateway and DiskAccess solve the same problem--accessing NFSexports from a Microsoft client system. So which one should you use? Because ituses a gateway architecture where all traffic funnels through a common system,AccessNFS Gateway does not, in theory, offer the same level of performance asrunning multiple DiskAccess clients. But Gateway accommodates a wider variety ofMicrosoft operating systems and is much easier to integrate into an existingnetwork. Differences notwithstanding, both are excellent choices foraccommodating access to NFS servers.