208
While they are not too similar, you should see a recognizable change to the mount table before and after mounting a remote filesystem.
If you are having intermittent problems or if you suspect performance problems, you might want to use the nfsstat command. It provides a wealth of statistics about your NFS connection and its
performance. You can use it to query the client, the server, or both. When called without any options, it queries both client and server. With the -c option, it queries the client. With the -s option, it queries
the server. Here is an example of querying a client:
bsd2 nfsstat -c Client Info:
Rpc Counts: Getattr Setattr Lookup Readlink Read Write Create Remove
0 0 33 2 0 21 4 0 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access
0 0 0 0 0 8 0 66 Mknod Fsstat Fsinfo PathConf Commit GLease Vacate Evict
0 13 3 0 2 0 0 0 Rpc Info:
TimedOut Invalid X Replies Retries Requests 0 0 0 0 152
Cache Info: Attr Hits Misses Lkup Hits Misses BioR Hits Misses BioW Hits Misses
232 36 74 33 0 0 0 21 BioRLHits Misses BioD Hits Misses DirE Hits Misses
13 2 18 8 13 0
Unfortunately, it seems that every operating system has its own implementation of nfsstat and each implementation returns a different set of statistics labeled in a different way. What youll be most
interested in is the number of problems in relation to the total number of requests. For example, a large number of timeouts is no cause for concern if it is a small percentage of a much larger number of
total requests. If the timeouts are less than a couple of percent, they are probably not a cause for concern. But if the percent of timeouts is large, you need to investigate. Youll need to sort out the
meaning of various numbers returned by your particular implementation of nfsstat. And, unfortunately, the labels arent always intuitive.
Several other NFS tools were once popular but seem to have languished in recent years. You probably wont have much luck in finding these or getting them running. Two of the ones that were once more
popular are nhfsstone and nfswatch. nhfsstone is a benchmark tool for NFS, which seems to have been superseded with the rather pricey SFS tool in SPEC. nfswatch is a tool that allows you to watch NFS
traffic. tcpdump or ethereal, when used with the appropriate filters, provide a workable alternative to nfswatch.
10.2 Microsoft Windows
Many of the services described in this chapter are traditionally provided by Unix systems. While more and more are becoming available, there arent a lot of tools that currently run under Windows. One
exception is nslookup, which is nearly identical to its Unix counterpart. Of course, the telnet-based testing will work as shown. And you can always test a Windows server from a Unix client. If you
want Windows-based tools, the best place to start looking is in the appropriate Windows Resource Kit from Microsoft.
209
Chapter 11. Miscellaneous Tools
This chapter contains odds and ends that dont really fit any of the categories described in previous chapters. Most of the software presented here isnt really designed with network troubleshooting in
mind, but it is, nonetheless, quite useful. These are tools that will make your life easier. With a few notable exceptions, you should already be familiar with most of the tools described here.
Consequently, the descriptions of the tools are, for the most part, fairly brief. Feel free to jump around in this chapter as needed.
11.1 Communications Tools
If you are going to effectively administer remote systems, you will need to log on remotely. Even with small networks, it isnt reasonable to jump up and run to the remote system every time you need to do
this. This section has three subsections. First, a quick review of techniques you can use to record or log your activities when using familiar tools like telnet, rlogin, and X Windows. Next comes a
discussion of vnc, a tool that allows you to view a computers graphical display remotely. Then I briefly discuss security concerns for these tools including a short description of ssh.
11.1.1 Automating Documentation
This book has assumed that you are familiar with tools like telnet, rlogin, and X Windows. To use these tools effectively, youll want to be able to record or log your activities from time to time.
Arguably, one reason documentation is so often flawed is that it is usually written after the fact. This is often done from memory or an incomplete set of notes several days after changes have been made.
While the best time to write documentation is as you go, often this simply isnt possible. When your network is down and management is calling every five minutes asking if its fixed yet, you probably
wont be pausing to write much down.
There are a few things you can do to help simplify writing documentation after the fact. First, get copious printouts at every stage, preferably with some kind of time and date stamp. When a
production system is down, it is not the time to worry about the cost of paper. Several commands you are probably already familiar with may be easy to overlook with the stress of dealing with a dead
system.
If you are using X Windows, you can use the xwd command to capture windows. To use this command, in an xterm window, type:
bsd1 xwd -out xwdfile
You can then click on the window you want to capture. In this example, the file xwdfile will be created in the current directory. The file can be examined later or printed using tools such as xv or gimp. Be
sure to give these files meaningful names so that you can sort things out later.
If you are using a text-based interface and are interested in capturing the output of a single command, you may be able to use the tee command. This command allows you to send output from a command
to both the screen and a file. For example, the following command will display the output of the command
arp -a
on the screen and write it to the file outfile:
