Managing NFS and NIS, 2nd Edition - Mike Eisler [196]
ypbind -ypset
The use of -ypset is a security risk as it allows a third party to change the binding to a potentially hostile server. Without the -ypset parameter, attempts to change the server binding will fail:
wahoo# ypset thud
ypset: Sorry, ypbind on host localhost has rejected your request.
A more restrictive form is:
ypbind -ypsetme
which only allows root on the local machine to invoke ypset to alter the binding. To discourage manually changing the binding, the startup script does not specify either of these options when it invokes ypbind.
Network analyzers
Network analyzers are ultimately the most useful tools available when it comes to debugging network problems. They are powerful tools that allow you to inspect network traffic at every level of the network stack in various degrees of detail. Good network analyzers provide powerful filters that reduce the amount of information to what is relevant for the task at hand. Snoop, ethereal, and tcpdump are three of the most popular network analyzers available today. Snoop and ethereal provide excellent support for RPC protocols and we use them throughout the rest of this book. The snoop network analyzer is bundled with Solaris, it provides powerful filters for analysis of problems related to NFS, RPC and NIS. ethereal is a GUI-based network analyzer program available free of charge. It is available for various types of operating systems, including many flavors of Unix. These utilities require superuser privileges in order to open the network interface device.
snoop
The snoop network analyzer bundled with Solaris captures packets from the network and displays them in various forms according to the set of filters specified. Snoop can capture network traffic and display it on the fly, or save it into a file for future analysis. Being able to save the network traffic into a file allows you to display the same data set under various filters, presenting different views of the same information.
In its simplest form, snoop captures and displays all packets present on the network interface:
# snoop
Using device /dev/hme (promiscuous mode)
narwhal -> 192.32.99.10 UDP D=7204 S=32823 LEN=252
2100::56:a00:20ff:fe8f:ba43 -> ff02::1:ffb6:12ac ICMPv6 Neighbor solicitation
caramba -> schooner NFS C GETATTR3 FH=0CAE
schooner -> caramba NFS R GETATTR3 OK
caramba -> schooner TCP D=2049 S=1023 Ack=341433529 Seq=2752257980 Len=0 Win=24820
caramba -> schooner NFS C GETATTR3 FH=B083
schooner -> caramba NFS R GETATTR3 OK
mp-broadcast -> 224.12.23.34 UDP D=7204 S=32852 LEN=177
caramba -> schooner TCP D=2049 S=1023 Ack=341433645 Seq=2752258092 Len=0 Win=24820
...
By default snoop displays only a summary of the data pertaining to the highest level protocol. The first column displays the source and destination of the network packet in the form "source -> destination". Snoop maps the IP address to the hostname when possible, otherwise it displays the IP address. The second column lists the highest level protocol type. The first line of the example shows the host narwhal sending a request to the address 192.32.99.10 over UDP. The second line shows a neighbor solicitation request initiated by the host with global IPv6 address 2100::56:a00:20ff:fe8f:ba43. The destination is a link-local multicast address (prefix FF02:). The contents of the third column depend on the protocol. For example, the 252 byte-long UDP packet in the first line has a destination port = 7204 and a source port= 32823. NFS packets use a C to denote a call, and an R to denote a reply, listing the procedure being invoked.
The fourth packet in the example is the reply from the NFS server schooner to the client caramba. It reports that the NFS GETATTR (get attributes) call returned success, but it doesn't display the contents of the attributes. Snoop simply displays the summary of the packet before disposing of it. You can not obtain more details about this particular