Managing NFS and NIS, 2nd Edition - Mike Eisler [138]
>
The inode numbers match what pfiles earlier displayed on the NFS client. However, inode numbers are unique per local filesystem. We can make doubly sure this is the file by comparing the major and minor device numbers from the uinode command, 136 and 7, with that of the filesystem that is mounted on /export :
spike# ls -lL /dev/dsk/c0t0d0s7
brw------- 1 root sys 136, 7 May 6 2000 /dev/dsk/c0t0d0s7
spike#
Clearing lock state
Continuing with our example from Section 11.3.2, at this point we know that the file is locked by another NFS client. Unfortunately, we don't know which client it is, as crash won't give us that information. We do however have a potential list of clients in the server's /var/statmon/sm directory:
spike# cd /var/statmon/sm
spike# ls
client1 ipv4.10.1.0.25 ipv4.10.1.0.26 gonzo java
The entries prefixed with ipv4 are just symbolic links to other entries. The non-symbolic link entries identify the hosts we want to check for.
The most likely cause of the lock not getting released is that the holding NFS client has crashed. You can take the list of hosts from the /var/statmon/sm directory and check if any are dead, or not responding due to a network partition. Once you determine which are dead, you can use Solaris's clear_locks command to clear lock state. Let's suppose you determine that gonzo is dead. Then you would do:
spike# clear_locks gonzo
If clearing the lock state of dead clients doesn't fix the problem, then perhaps a now-live client crashed, but for some reason after it rebooted, its status monitor did not send a notification to the NLM server's status monitor. You can log onto the live clients and check if they are currently mounting the filesystem from the server (in our example, spike:/export). If they are not, then you should consider using clear_locks to clear any residual lock state those clients might have had.
Ultimately, you may be forced to reboot your server. Short of that there are other things you could do. Since you know the inode number and filesystem of file in question, you can determine the file's name:
spike# cd /export
find . -inum 5516985 -print
./home/mre/database
You could rename file database to something else, and copy it back to a file named database. Then kill and restart the SuperApp application on client1. Of course, such an approach requires intimate knowledge or experience with the application to know if this will be safe.
Chapter 12. Network Security
The simplicity and transparency provided by NFS and NIS must be weighed against security concerns. Providing access to all files to all users may not be in the best interests of security, particularly if the files contain sensitive or proprietary data. Not all hosts may be considered equally secure or "open," so access may be restricted to certain users. Transparency must be limited when dealing with secured hosts: if you have taken precautions to prevent unauthorized access to a machine, you don't want someone to be able to sit down and use an open window or logged-in terminal to access the secured machine. To enforce access restrictions, you always want password verification for users, which means eliminating some of the network transparency provided by NIS.
This chapter describes mechanisms for tightening access restrictions to machines and filesystems. It is not intended to be a complete list of security loopholes and their fixes. The facilities and administrative techniques covered are meant to complement the network transparency provided by NFS and NIS while still enforcing local security measures. For a more detailed treatment of security issues, refer to Practical Unix Security, by Garfinkel and Spafford (O'Reilly & Associates, 1996).
User-oriented network security
One area of concern is user access to hosts on the network. Figure 12-1 shows several classes of permissions to consider, reflecting the ways in which a user might access a host from another host on the network.
Figure 12-1. Client-server remote logins
Remote logins are not the only concern; remote execution