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 supports Intergraph's UNIX-NT products. The flagship of ISS's UNIX-NT offerings is the AccessNFS line of products. AccessNFS includes DiskShare, a server-oriented product that lets an NT system emulate an NFS server; DiskAccess, a client-side product that lets an NT system access an NFS server; and AccessNFS Gateway, a new server-side product that lets an NT system access an NFS server without any client-side software.
I recently had the opportunity to work with a beta copy of AccessNFS Gateway and the most recent release of DiskAccess (version 3.01.00.11). Both products 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 printer
exports on a server system and re-share them on the native Microsoft network as
standard Server Message Block (SMB) shares. Conceptually, AccessNFS Gateway is
similar to Microsoft's Gateway Service for NetWare in that it effectively remaps
a foreign file and print sharing methodology into the Microsoft file and print
sharing methodology. But don't linger on the comparison to Gateway Service for
NetWare too long. AccessNFS Gateway takes a more sophisticated approach than
Gateway Service for NetWare does.
Establishing the connection between an AccessNFS Gateway server and one or more NFS server systems is straightforward. You can establish multiple connections, and each connection can use a different username for authentication. As you'd expect, AccessNFS Gateway lets you map an NT username into its UNIX counterpart and supports authentication using either the Network Information Service (NIS) model (traditionally used for UNIX-to-UNIX authentication) or the PC NFS daemon (PCNFSD) model (usually used for PC-to-UNIX authentication).
Once the AccessNFS Gateway server has been authenticated to an NFS server or two, it can mount exported directories and printers. Those directories and printers are then available as shared resources sponsored by the NT system running the AccessNFS Gateway server. In other words, you bring up the Network Neighborhood map, click the NT system running the gateway software, and the NFS directories and printers appear in the list of resources. Because AccessNFS Gateway uses standard Microsoft file and print services to deliver NFS resources, any Microsoft network-aware client operating system--including DOS, Windows 3.1, Windows for Workgroups, Windows 95, and, of course, NT--can access NFS directories and printers.
As with other gateway approaches, the big question is: How is file-level security handled? For example, if you use Microsoft's Gateway Service for NetWare, NT establishes all access rights according to the privileges assigned to the single server-side user ID that manages the NetWare connection. In contrast, AccessNFS Gateway lets you use the user ID of the client accessing the shared resource. To accommodate this method, AccessNFS Gateway provides a mapping table that translates an NT username into its UNIX counterpart. Names not contained in the table are passed through directly. Given this approach, the UNIX-side access security remains completely intact--access to individual directories and files is based on the UNIX-side settings.
DiskAccess
I originally reviewed ISS's client-side NFS product, PC-NFS, in the December
1995 issue. Since that time, the product has matured a great deal. The most
important change is that the product no longer uses the PC-NFS code that
Intergraph codeveloped with Sun Microsystems. Although for years this code was
the de facto standard for PC-to-UNIX NFS access, implementing the code
in the NT environment introduced more problems and limitations than it solved.
ISS obviously recognized these limitations because the company dropped the
PC-NFS code from the product and changed the product name from PC-NFS to
DiskAccess.
The current DiskAccess release lets you authenticate the system to an NFS server during the NT logon process or at the time of connection. You can also use different authentication servers at connect time. This option is particularly useful and is not in most client-side NFS software on the market--most products authenticate you one time to one host. DiskAccess supports authentication using either the PCNFSD or NIS methodology. Screen 1 shows the Authentication tab of the DiskAccess dialog box where you select the authentication host and type (NIS or PCNFSD).
DiskAccess maintains the user authentication information separately for each user profile. Again, you won't find this feature in most NFS client products. If this feature does not seem important, consider this scenario: If you want to implement NFS in a multiuser context (e.g., using NFS in conjunction with Citrix' WinFrame, NCD's WinCenter, Tektronix' WinDD, or Insignia's NTRIGUE), support for multiple, concurrent NFS authentication is critical. DiskAccess addresses this need and the simpler case of a common workstation shared among multiple users.
DiskAccess does not provide a separate user interface for accessing NFS directories and printers; you simply use the standard Network Neighborhood (or File Manager or Print Manager) utility to browse your network. As Screen 2 shows, an NFS Network entry appears on this list of available networks. When you double-click this entry, you see additional networks containing your NFS servers, much like domains on an NT network. This list lets you target subnets you want to browse for NFS services. This approach lets you locate NFS resources beyond your local net, bypassing a limitation users experience routinely when routers segment their networks.
After you browse for the server you want, double-click the exported directory or printer to access it as if it were a native Microsoft network resource. This option is faster than having DiskAccess search entire network segments for all available NFS servers, letting you browse only the systems you define.
In addition to providing access to NFS directories and printers, DiskAccess includes a set of utilities, including Telnet, TN5250, and TN3270 for terminal access; a graphical FTP program for file transfer; a Domain Name System (DNS) Query program for name-to-address lookups; Show Mounts and RPC Information to provide details about server-side settings; and Ping for basic name and address verification. DiskAccess also includes services to implement Remote Shell (RSH) for remote command submission and Network Time Protocol (NTP) for network time synchronization.
So Many Choices, So Little Time
AccessNFS Gateway and DiskAccess solve the same problem--accessing NFS
exports from a Microsoft client system. So which one should you use? Because it
uses a gateway architecture where all traffic funnels through a common system,
AccessNFS Gateway does not, in theory, offer the same level of performance as
running multiple DiskAccess clients. But Gateway accommodates a wider variety of
Microsoft operating systems and is much easier to integrate into an existing
network. Differences notwithstanding, both are excellent choices for
accommodating access to NFS servers.
