WRQ Solves The Unix-NT Connectivity Mystery
By Ahmad Abualsamid
As Microsoft sells more and more copies of its Windows NT workstation, an important question continues to pop up. How can I use an NT box to connect to my Unix servers and access all my files and printers? The answer depends on which network file system (NFS) is installed on your Unix server, and whether you want to configure your Unix server to talk to NT or configure your NT clients to talk to your Unix servers (NFS clients for NT), or both.
WRQ's Reflection NFS Connection for Window
s NT 6.1 is a great NFS client for Windows NT. With relative ease it lets you access your Unix files and folders through the familiar Windows Explorer interface. Unix folders (or directories) can be mapped to local drives just like any other directory mapped off a Novell NetWare server or an NT server. I used the NFS NT client over t
he course of several days and was very pleased with its performance.
NFS Today, NFS Tomorrow?
I installed the software at Network Computing's University of Wisconsin-Madison lab on a Windows NT client running NT 4.0 and equipped with 64 MB of RAM. The computer was installed with client-32 and had several NetWare directories mapped to local drives. I used the NFS NT client to access NFS files off a Solaris 2.5.1 server with 192 MB of RAM and about a dozen exported directories to couple hundreds Unix workstations. Installation was automatic. The only catch was that it requires administrator access on the NT side.
Once installed, the software provides complete acce
ss to files residing on an NFS server. It also lets you print to any server running Line Printer Daemon (LPD) on your network. The package not only includes the NFS client but also comes with a set of network applications typically available on a Unix workstation-ping, finger and FTP clients.
The Reflection Server Manager is even more interesting, as it lets you set up several daemon-like NT services (servers in WRQ lingo) on your NT box. These include a finger server, FTP server, identification daemon, LPD and a Web server. All of those servers are disabled by default, but once you run the Reflection Server Manager, you can start any of them with one mouse click.
The sweetest part of WRQ's package is the NFS client. This NFS client for NT was the easiest I have ever installed. The setup was automatic-no fuss, no hassle. Once installed, a new entry appears under "Network Neighborhood," called NFS Network. Clicking on this entry gives you a list of identifiable NFS servers on the network. To identify a
server, the NFS client can use the combination of your NT Hosts file, Network Information Service (NIS) maps or Network Search.
A Hosts file is the easiest to understand, as it lists servers and their corresponding IP addresses. The client queries the servers to discover if they are serving NFS directories (basically running nfsd), and
if so, what directories are they exporting. If NIS is enabled, the NFS client can request the hosts list from an NIS map and then query those hosts. A Network Search is performed via a broadcast, and it can be limited to your subnet, or the entire local network based on the class of your IP address. Regardless of the method the NFS client uses to identify NFS servers on the network, the operation is transparent to the user. After you click on NFS Network in the Network Neighborhood, you'll be presented with a list of NFS servers. Clicking on any server in the list displays a list of exported directories from that server. Now you can navigate through those directories, or
you can map any of them to a local hard drive. Once a mapping is established, the Unix files and folders can be accessed from the familiar Windows Explorer, a DOS window or within your application(s). Full support for long file names is maintained. For example, I wrote this article on my NT workstation while saving the actual file to my Unix directory, which is mapped off a SunSoft Solaris server. Everything integrates perfectly with the NT environment.
Can I Read That File?
Mapping an NFS directory does not give you full access to it; the Unix server has to authenticate the user making the connection. The NFS NT client lets you do this in three different manners.
First, you can connect as an anonymous user, which will give you access only to those directories/files that have the relevant read/write/execute permissions set. In Unix, this means that the last three entries in a file's permission list should be rwx for an anonymous user to gain full access. This method is insecure and should be
used with caution.
Another other method is to set up a daemon on the Unix server to authenticate connections from a PC client. The daemon is called PCNFSD and requires Unix system administration skills. Once set up, it queries the local password and group files on the Unix server to authenticate connections.
The final method-my favorite-
involves using the built-in NIS support. The NFS client can be provided with the host name of an NIS server. When you try to make a connection to an NFS server, the NT NFS client forwards the user name and password to the NIS server for authentication. NIS is frequently used in Unix to distribute password files, group files and mount points, as well as to provide a slew of information to Unix clients. (If you have a Unix network, chances are that you already have an NIS server setup. In a smaller environment, your NFS server and NIS server may be the same machine.) This method is preferred because it requires the least setup, and centralized authentication can be p
rovided regardless of how many NFS servers you connect to. The NIS authentication is limited to connections made to NFS servers and is not meant to replace any other NT authentication scheme.
File permissions differ between Unix and NT. Because Windows Explorer does not know about Unix file permissions, you cannot access or change Unix permissions from the Explorer. However, the product comes bundled with NFS administrator, a utility that enables browsing files and directories similar to the Windows Explorer. This utility lets you view and modify file and directory permissions on the Unix side. The NFS administrator, as shown above, shows the Windows name, NFS name, NFS file permissions, level of access (owner, group or other), DOS attributes and DOS names. The DOS attributes are a simple translation of the Unix file permissions. By changing the Unix file permissions, the NFS administrator assigns Hidden, Read-only and Archive attributes to the file accordingly. Going in the other direction is possible to
o, but since DOS (and hence NT) does not know about Unix groups and ownership, it does not make much sense. The NFS Administrator also has a couple of tools that let you input a Unix host name and then report on which daemons it is running and what directories it is exporting.
As mentioned earlier, the package comes with a set of services, includi
ng an FTP server. I enabled it on my NT workstation. It took me couple of minutes to configure the powerful set of options. Shortly afterwards I was FTP-ing to my NT workstation, grabbing files from it and putting files on its local hard drive. I thought the FTP server was very handy, especially because it has various powerful options typically found in complex Unix FTP daemons. For example, you can set up both anonymous and password-authenticated FTP and limit access to a range of IP addresses.
Printing via LPR can also be handy. I pointed LPR to a server running LPD and printed without any difficulty.
Authentication is done once per session. That has
its advantages, but it means that simultaneously accessing files from different NFS servers using multiple accounts is not possible. Depending on your setup, this may or not be a problem. n
Ahmad Abualsamid is a server systems engineer at Epic Systems Corp. and a doctoral student at the University of Wisconsin-Madison. He can be reached at sami@maf.wisc.edu.
|
REPORTS
ANALYTICS
Follow 
