UNIX as a DOS File and Print Server

Kim Soques and Bruce Altmann

Introduction

While NFS is a common method of sharing files between UNIX machines, it is less common as a way to share files between PCs. Given our exclusively TCP/IP network, and our users' need to work in cross-functional groups using multiple platforms (VAX, UNIX, PC), our company chose to use NFS as its enterprise-wide file-sharing method. In addition, we moved away from using serial connections for our network printers, in favor of an IP printing strategy. This model not only has been easy to integrate into our existing environment, but also has proven able to scale up or down as needed.

Since this article is targeted toward UNIX configuration, we do not discuss the issues surrounding selecting and configuring an NFS client to run on the PC. Given this, you should be aware that not all PC network software that delivers TCP/IP services to the PC includes NFS or network printing clients. In many cases these are add-ons or an enhanced version of a basic TCP/IP stack. We use SunSofts PC-NFS; however, all the PC-based NFS products operate the same for the purposes of this article. Henceforth, references to the PC software refer to a product that includes an NFS client and some support for network printing.

Something to remember when using NFS with PCs is that the single-user, "trusting" PCs are directly accessing a multiuser UNIX environment. PCs and, by extension, their users do not inherently use UNIX permissions. Many of the lessons we learned stem from that fundamental contradiction.

rpc.pcnfsd

rpc.pcnfsd lies at the heart of managing the multiuser UNIX/single-user PC contradiction. rpc.pcnfsd provides weak authentication of user IDs for the PC. An RPC server, it listens at port 150001 for authentication requests, returning the UID and all GIDs for each valid user name and password passed to it. This occurs during the PC's boot cycle, or if the user manually chooses to log out and log back in. Authentication allows the user access to the directories he/she has permissions for. If authentication fails, the user ID defaults to "nobody," and the user can only access network resources available under world permissions. This process is essential for the PC to be able to access UNIX resources.

rpc.pcnfsd is freely distributable, and available on many of the ftp sites that keep Sun patches and other information. The most current version we have found is version 2, revision 1.6, which we found on a SunSoft PC-NFS CD-ROM. If a server is already running rpc.pcnfsd, use rpcinfo to determine which version is installed. To identify the revision number, use the command

strings rpc.pcnfsd | grep ver

HP bundles rpc.pcnfsd into its operating system, but the version tends to run one revision or so behind the most current Sun code. In addition, some vendors of PC NFS clients sell proprietary versions of rpc.pcnfsd. Our tuning recommendations here apply to the Sun rpc.pcnfsd.

The essential portion of configuring a UNIX server to run rpc.pcnfsd is turning it on. The daemon is enabled in /etc/rc.local on SunOS 4.1.3, in /etc/initd/pcnfs on SunOS 5.4, and in /etc/netnfsrc under HP-UX 9.3.

For SunOS 4.1.3:

#  start up pcnfsd version 2 daemon  ("april 02, 93") by: ("altmann")
#
if  [  -f  /usr/local/etc/rpc.pcnfsd ] ;  then
/usr/local/etc/rpc.pcnfsd ;  echo  ' rpc.pcnfsd'  >/dev/console
fi

for HP-UX 9.3:

NISDOMAIN_ERR=""
##
#       PCNFS_SERVER    --     if this node is a server for PC-NFS requests.
#                              This variable controls the startup of the
#                              pcnfsd(1M) server.  See Also:  pcnfsd(1M).
##
PCNFS_SERVER=1
# (the default is 0)

Aside from its crucial role in providing UNIX user IDs, rpc.pcnfsd plays another part -- that of enabling network printing. We will discuss that aspect in more detail in the section dealing with printing.

Server Setup for File Sharing

General Setup Information

Much of the effort needed to set up a UNIX server for PC file sharing is the same as for setting up any NFS/NIS server. There are many excellent resources that cover the topic, including Hal Stern's book, Managing NIS/NFS, so we do not cover that here. Note that NIS services are not strictly necessary when setting a server up to handle PC services, though we cover some ways to broaden their use in supporting PC-based NFS.

Beyond the basic server setup are customization issues. Some of these, such as export restrictions, permissions, and shared directories, are simply enhancements to the standard configuration. Others, such as rpc.pcnfsd tuning, are specific to the server's new role.

Exports

The exports needed on a PC NFS server are simple. The two primary file systems the PCs will need to access are the filesystem containing user home directories and the /var/spool/pcnfs filesystem (for pcnfsd printing).

However, to keep from opening the server up to the whole network, we use the /etc/netgroup file to restrict access. A NIS map, /etc/netgroup resolves individual host names to file system access. (Without NIS, this file is moot.)

The netgroup file allows host names to be added dynamically, unlike the more static -access flags in the /etc/exports file. The netgroup format is an alias followed by an access control field, containing any one of the following: hostname, login, or domain name. (Domain name was never implemented.) The most secure method specifies user and hostname. However, we cannot rely on the same user always being at the same host, so our netgroup implementations use the hostname only. These aliases can contain approximately 60 entries. Several can be combined into still-larger aliases, with the highest-level alias used in the exports file itself.

The /etc/netgroup entry controlling access to /var/spool/pcnfs would look like this:

nova_pc_1 (crawford,,) (flato,,) (pignut,,) (introit,,) (hangnail,,) (sauk,,)\
(cheroot,,) (bibelot,,) (corolla,,) (fauve,,) (organdy,,)\
(adams,,) (philip,,) (peccary,,) (ebony,,) (cherimoya,,)\
[...]
######### /var/spool/pcnfs export
nova_pcnfs nova_pc_0 nova_pc_1 nova_pc_2

while the corresponding /etc/exports portion would be:

/var/spool/pcnfs -access=nova_pcnfs

This, in conjunction with strategic use of UNIX permissions, keeps unauthorized users from accessing what could be confidential data.

Permissions, Group Access, and Work Group Directories

Since the NFS mount on the PC is mapped to a drive letter, many users think the "virtual drive" is the same as their local disk. To maintain the illusion, we set user directories to drwx------. The user then does not receive the sort of surprise one of our users did before we adopted this rule. She had been working with someone in a different department, and called him to discuss how best to transfer a mutual file back to him. He, a UNIX user on the same server, told her not to worry, since he'd already copied it out of her home directory! We quickly found out how unamused she was to find out that the file she thought was "safe" wasn't. Our policy changed.

In a similar vein, group permissions play a larger role on the PC-based NFS server, particularly if many different departments are using the same server. To keep confusion to a minimum and ease security concerns, we give all members of a particular department a default group specific to that department.

wgs:*:6020:

Finance staff would be in group finance, while Marketing would go in group mrkt. Even if a user changed her account's permissions to drwxrwx---, Marketing staff would not be able to get into Finance's directories. This more controlled use of group permissions also makes it easy to implement work group directories.

After users start to use their home directories, they request a place to share files with other department members. To do this, we put a twist on the basic account, calling it a work group directory. We define a dummy user in the passwd file with the same primary group ID as the members of that work group. The account is locked ( a "*" in the password field), but otherwise set up normally.

wgs:*:5071:6020:WGS Work Grp Dir:/user/wgs:/bin/csh

The permissions on that account's directory are then set to drwxrwx---, enabling all members of that GID to read and write in the directory:

drwxrwx--- 13 wgs     wgs          1024 Jun 23 17:02 wgs

With no more effort than creating an account, the group has a shared space in which to work collaboratively.

Concerning permissions and access, there is one other item to cover. We mentioned earlier that rpc.pcnfsd provides "weak authentication." This means that after the server hands over a UID to the client, no more checking is done. The client carries that UID to every server it accesses, unchallenged.

Weak authentication has caused a problem that we are still struggling with. For example, when juser turns on her PC in the morning, she authenticates on server A. To access some spreadsheets in a different department, she NFS-mounts server B. If the UIDs are not identical -- that is, if juser is UID 555 on server A but is 556 on server B -- conflicts arise. At minimum, juser will not be able to access her files. Depending on the PC NFS client, juser may have access to all of the files belonging to user 555 as well.

When we first implemented NFS for PCs, we did not worry about this. Most users had only one NFS mount and authenticated on that machine. Now, however, use of NFS on PCs has become more accepted and widespread. When we set out to implement a corporate-wide application that relied upon NFS mounts to central servers, we realized the mess we had in front of us. We have been working to implement a global UID registry as a stopgap measure, but at this point the registry involves lots of rework for all our systems administrators. Unsurprisingly, they have been slow to adopt this for anything other than new accounts. We are eagerly awaiting something like DCE or NIS+ for PC clients, since at this time even SunOS 5.4 handles PCs in NIS-compatibility mode.

Tuning for NFS Performance

Optimizing a server for PC file and print services does not stop with starting rpc.pcnfsd and adding NIS enhancements. Since the server is no longer a compute box or a major time-sharing platform, but a file server, it needs to be tuned for NFS performance. An NFS accelerator card is essential -- we use Prestoserve on our Sun 4.1.3 machines. These cards handle write caching, keeping the client from having to wait on a completed disk write on the server. While NFS accelerator cards do entail some initial cost, they quickly pay for themselves in decreased wait time and fewer hostile users.

Another important item is to enable the UDP checksums. NFS uses UDP, a stateless protocol, to transmit packets, and the RFC for NFS does not specify that it must do data checking. In Managing NIS/NFS, Hal Stern states that "without the checksums, it's possible to read or write corrupted data" (p. 317). The UDP checksum provides this missing data verification step. As Stern notes, "NFS requests containing UDP checksum errors are rejected on the server, and will be re-transmitted by the client" (p. 317).

On by default in SunOS 5.4, UDP checksums are turned off in Sun 4.1.3 machines. To implement them, edit /usr/kvm/sys/netinet/in_proto.c and change the udp_cksum line (near the end) from

udp_cksum = 0

to

udp_cksum =1

Reconfigure the kernel and then reboot.

Another key NFS tuning parameter is to increase the number of nfsds running. As more and more users are added, the eight nfsds SunOS starts by default become inadequate. A handy rule of thumb is to run approximately eight nfsds per every 50 users, up to the maximum recommended by the OS provider (30 for SunOS 4.1.3). Less than this can result in temporarily dropped mounts with the PC clients, which is alarming for the end user -- "Not reading drive K" generates quite a few support calls!

Our final NFS tuning hint involves adjusting the number of MAXUSERS in the kernel. The paper "Sun Performance Tuning Overview," from SMCC Technical Marketing (December 1993), suggests setting MAXUSERS equal to two times the amount of RAM on the server, up to the maximum suggested for the operating system (225 for SunOS 4.1.3). This setting is twice Sun's recommendation for non-NFS servers. Changing MAXUSERS optimizes the NFS buffer queue sizes, the I/O buffer sizes, and the table sizes in the kernel, preventing bottlenecks.

Network Printing Setup

Migration from Serial to IP Printing

Originally, UNIX network printers were made available on our TCP/IP network via a serial connection to a terminal server. Under our old method, we could trace a printing problem from the client originating the job through to the server. Unfortunately, the link from the server to the printer was difficult to troubleshoot. As we began implementing PC-NFS enterprise-wide, this level of uncertainty was unacceptable. We decided to use MiLan's Fastport 3100/3100CX, moving us from reliance on serial protocols to TCP/UDP.

The Fastport is a network-aware device that accepts Berkeley LP protocol requests and spools them to the attached printer. It can be monitored remotely via telnet, thus making printing much easier to troubleshoot. With the Fastport handling the connection between the printer and the server, we can now trace a printing problem almost to the parallel cable linking the Fastport and the printer.

MiLan Attachment and Setup

The MiLan Fastport provides a flexible interface between our servers and printers. It can be set up to perform filtering or not on the box itself, with some models supporting autosensing. The Fastport also supports many different printer description languages, though we have standardized upon three -- UNIX ASCII, DOS ASCII, and PostScript. These three we can move through the same queue, since a Fastport set up for autosensing can handle the carriage return/line feed issues between UNIX and DOS ASCII. This single-queue approach also simplifies matters for our PC users, since they only point to the one queue name for all their printing requirements. For printer languages that contain escape codes, like HPCL and HPGL, we find it easiest to set up a separate queue. We try to avoid this, however.

The details of configuring printer setup files vary so widely from operating system to operating system -- even from one OS version to the next -- that we do not have enough column inches to cover that here. However, with each Fastport MiLan ships software that covers configuring the various server types, along with good documentation.

Printing

Choosing and setting up MiLan boxes is only the first step in our printing strategy. Once IP printing is enabled, there are still decisions to make in how to approach spooling print jobs from the PC. There are two options available: pcnfsd printing and Berkeley LP protocol.

pcnfsd Printing

rpc.pcnfsd on the server enables what we call "pcnfsd printing," a method of providing network printing to the PC without using the Berkeley LP protocol. Using pcnfsd printing, a PC will print through an LPT port redirected to an NFS mount. Once the print job is copied to the NFS mount (that is, on the server), rpc.pcnfsd then executes lpr on that spool file. Until recently, the NFS client we used on the PC did not support the Berkeley LP protocol, so this was our only network printing option. Berkeley LP is supported in more recent versions of our PC NFS client, so we are increasingly using the LP protocol as a more reliable printing transport, for reasons outlined below.

rpc.pcnfsd Changes

rpc.pcnfsd by default has a printing timeout of 50 seconds. We have found this setting has a tendency to fail on large files such as presentations. Not only does the print job stop, but often rpc.pcnfsd hangs when this timeout occurs.

To make pcnfsd printing more reliable, we recommend making the changes noted in Listing 1 to the rpc.pcnfsd source code. We took these suggestions from SunService, after contacting them with our printing timeout problem. These changes do not eliminate the problem completely, but they do lessen its frequency.

printcap Entries

For pcnfsd printing, printcap configuration is no different from usual. To use Berkeley LP printing, the server's lp daemon must be set up to accept remote requests. This is no different from setting it up to accept lp requests from remote UNIX boxes, however.

rpc.pcnfsd Monitoring Tools

As we mentioned earlier, we run a perl script called pcnfsdcheck.pl to help us monitor rpc.pcnfsd (see Listing 2). Run from a cron job, pcnfsdcheck.pl checks the 150001 port to make sure that rpc.pcnfsd is still responding. If it is not, the script kills the process and restarts it. It also contains a syslog function, return codes, and the option to test remote hosts. We have tested it under perl 4.03X and perl 5.001 on HPUX 9.X, SunOS 4.1.3.X, and SunOS 5.4.

Typing

pcnfsdcheck.X.X.X.pl -h

will give a list of the options available. Note that the -f flag only works on a localhost, so do not use it with the -n option. Used without the -n <node> option, pcnfsdcheck.pl will poll the localhost. -s is silent mode, although errors will write to STDOUT. The -l option will write to syslog. This is most effective with the -s option. The -f will cause pcnfsdcheck.pl to try to run ps to get the PID, then kill and restart rpc.pcnfsd (localhost). We recommend using:

pcnfsdcheck.pl -n node_to_check -s -l -f

The script is setup by default to run on SunOS 4.1.3.X, but you can configure it to run on other operating systems by changing the LOCAL CUSTOMIZE section to match your OS.

A side note: the syslog function requires the syslog.ph perl header, so check /usr/local/lib/perl for this file. If the perl installation on the server was questionable, the -l flag will break the pcnfsdcheck.pl code. If you do not have syslog.ph, check the h2ph ("header to perl header") man page for how to proceed.

To use pcnfscheck.pl, install it in /usr/local/etc as

755 root daemon pcnfsdcheck.VENDOR.OS.pl

-rwxr-xr-x  1 root     daemon       7015 May 15 17:04 pcnfsdcheck.Sun.4.X.pl
-rwxr-xr-x  1 root     daemon       7015 May 15 17:04 pcnfsdcheck.Hpux.9.X.pl

The crontab entry would be as follows:

# check pcnfsd, fix, and log every 15 min
1,16,31,46 * * * *
/usr/local/etc/pcnfsdcheck.Sun.4.X.pl -s -l -f

This hands-free checking means that we no longer find out about rpc.pcnfsd dying from our unhappy users, and our support calls are kept for bigger problems. Phasing out pcnfsd printing will reduce our need for pcnfsdcheck.pl, but not eliminate it, since client authentication plays such a key role in determining the PC's access to network resources.

Conclusion

At a high level, setting up this environment entails the following steps: