Managing NFS and NIS, 2nd Edition - Mike Eisler [128]
Avoiding automounted filesystems
Utilities run out of cron, such as nightly find jobs, are easily overworked by the automounter. The solution is to modify cron jobs to avoid remote filesystems:
Confine cron jobs to run find on local filesystems.
Use an option to find like -xdev or -mount to force find to not cross mount points.
This uses the above constraints to implement a script to search for core files:
mount | grep -v remote | awk ' { print $1 } ' | xargs -i find {} -name 'core*' -
mount | /usr/bin/mailx -s"core file report" joe@eng
The mount invocation shows what is currently mounted, grep filters out anything that isn't local, awk prints the first argument (the mount points), xargs passes each mount point to a separate invocation of find, and find searches for files starting with the name core within the mount point's filesystem.
Chapter 10. PC/NFS Clients
PC/NFS refers to an implementation of the NFS protocol for IBM-compatible personal computers running the Windows or NT operating systems. Originally, NFS implementations for the IBM-compatible PC were confined to the client-side of NFS. Today, most vendors of PC/NFS offer both a client and server, though they are often packaged and sold separately. This chapter is confined to PC/NFS clients, and where it uses the term "PC/NFS" the term "PC/NFS client" is meant.
Using PC/NFS, PC machines can mount NFS filesystems as logical disks and use them as large virtual disks. Note that a client-only implementation does not limit the direction or types of file transfer operations that are possible within PC/NFS. It simply means that the PC is always the active entity in the Windows-NFS server relationship; the user must mount an NFS filesystem on the PC and then copy files between it and the local disk. In this chapter, we'll look at why you would want to use PC/NFS, alternatives to PC/NFS, setting up PC/NFS, and PC/NFS usage issues.
PC/NFS today
The first NFS client for Microsoft DOS or Windows operating systems was developed by Sun Microsystems in the mid-1980s and was called "PC/NFS." The PC/NFS brand name has become a generic term to refer to any product that provides an NFS client feature on Microsoft operating systems. Today, Sun Microsystems has abandoned the PC/NFS business, leaving a fairly competitive field of several vendors of commercial PC/NFS products. There are also some freeware or shareware clients if you look hard enough, but there does not appear to be much development activity around them.
It is beyond the scope of this book to provide a detailed survey of PC/NFS implementations, since they each have unique features, and new releases for each arrive all the time. You can use Internet search engines, Usenet archives from sources like google.com, and as a last resort, queries to Usenet's comp.protocols.nfs newsgroup to get feedback on what products people prefer. You can also look at www.connectathon.org to see which companies test products at the annual Connectathon interoperability testing event. While the Connnectathon web site won't tell you which companies test NFS and which of those have PC/NFS clients, the list of companies is not too long, so you could go to the web site of each and see which have PC/NFS implementations.
When selecting a PC/NFS implementation, your minimum set of required features should include all of the following:
NFS Versions 2 and 3
NFS over UDP and TCP
Some integration with Unix authorization
The last feature amounts to allowing users of PC/NFS clients to use the same password to access the NFS server as they would if they were logging into the system the NFS server resides on. Some PC/NFS clients accomplish this by acting as an NIS client to access the password database from NIS. Most will also integrate by the use of the PCNFSD protocol. This was a protocol invented by Sun Microsystems to