Monday, May 24, 2010

2010 P1: FINAL PRESENTATION MAY 26 2010

 Eli present




















jonathan present





























wee yong present























Eli present demo with explaination




Network File System (NFS)

What is NFS?
Network File System (NFS) is a protocol which allows user on a client computer to access files over a network similar to how local storage is being accessed. Being built on Open Network Computing Remote Procedure Call (ONC RPC) systems and is an opened standard defined in RFCs, it means anybody would be able to implement the protocol.

Benefits of NFS
• Local machine use less disk space because commonly used data can be stored on a single machine and still remain accessible to others over the network.
• Ability to provide single home directory for user on every machine throughout the network.
• Storage devices such as floppy disks, CDROM drives, and Zip® drives can be used by other machines on the network. This may reduce the number of removable media drives throughout the network.

Install NFS
There are 3 ways to install NFS:
  1. Installing through YUM
  2. Install RPM packages
  3. Build from source
Let us take a look at the first 2 methods.

Yum (Yellowdog Updater Modified)
Install through Yum is simple. Just execute the following command to install.
# yum install nfs-utils

RPM Package Manager
Installing through RPM Package manager requires a bit more work. Normally we will install from the CD/DVD-ROM provided. By in any case a CD/DVD-ROM is not available; we might have to download the rpm file from online source.
a.Navigate to the source, which most like be the CD/DVD-ROM. The source CD/DVD-ROM have to be inserted first

#cd /media/RHEL_5.3\x86_64\DVD/Server

b.Installing through RPM
# rpm -ivh nfs-utils-1.0.6-2tr.i586.rpm

Configuring NFS serverEnabling NFS
Before start NFS, you need to have the following services already running:

# service nfs start
# service portmap start
#service nfslock start


Both services will start on boot using the following command:
#chkconfig nfs on
#chkconfig portmap on


To verify the exports is exporting properly, and use the following command:
#showmount –e ipaddress-of-nfs-server

You need to restart NFS daemon to apply changes in the /etc/exports file. It depends on your Linux distribution. The restarting of NFS may diff. Debian users:
#/etc/init.d/nfs-kernel-server restart

Linux users
#/etc/init.d/nfs restart

If add more NFS exports to the /etc/exports file, you have to either restart NFS daemon or run commands exportfs:
#exportfs -ra

Troubleshooting
Problem 1: Unable see file mounted file system
Solution:
1. Check if file system is mounted.(e.g nano /proc/mounts OR mount -f )
2a.If file system is mounted; it may be that another file system is mounted on top of it.
  • unmount and remount both volume, or
  • export file system on server before mounting(Restart the NFS server)
  • 2b.If file system is not mounted, refer to problem 3
Problem 2: File request hang /access to file timeout
Solution:
i. Refer to problem 3.

Problem 3: Unable to mount a file
Error: Failed, reason given by server: Permission denied
Solution:
  • Check etc/exports to make sure client has the right kind of access right(read access =ro, read/write=rw )
  • Type the following to force the exports to be re-read
    ~]# exportfs -ra
  • Check /proc/fs/nfs/exports to make sure volume and client are listed correctly.
  • Try to login in to server from client via Telnet OR ssh
  • Type the following command to list the current connected users (one of the listings should be your login session and the name of your client machine as the server sees it. Try using this machine name in your /etc/exports entry. Try to ping the client from the server and vice-visa. If this doesn't work, or if there is packet loss, you. It might be cause by a lower level network problem)
    ~]# who
  • It is not possible to export both a directory and its child (for example both /usr and /usr/local). You should export the parent directory with the necessary permissions, and all of its subdirectories can then be mounted with those same permissions.

    Error: RPC program not registered (Another RPC error)
    Solution:
  • Check whether NFS is running; execute the command rpcinfo with option –p on the server. You should be able to see something like this :

    ~]# rpcinfo -p
    program vers proto port
    100000 2 tcp 111 portmapper
    100000 2 udp 111 portmapper
    100011 1 udp 749 rquotad
    100011 2 udp 749 rquotad
    100005 1 udp 759 mountd
    100005 1 tcp 761 mountd
    100005 2 udp 764 mountd
    100005 2 tcp 766 mountd
    100005 3 udp 769 mountd
    100005 3 tcp 771 mountd
    100003 2 udp 2049 nfs
    100003 3 udp 2049 nfs
    300019 1 tcp 830 amd
    300019 1 udp 831 amd
    100024 1 udp 944 status
    100024 1 tcp 946 status
    100021 1 udp 1042 nlockmgr
    100021 3 udp 1042 nlockmgr
    100021 4 udp 1042 nlockmgr
    100021 1 tcp 1629 nlockmgr
    100021 3 tcp 1629 nlockmgr
    100021 4 tcp 1629 nlockmgr
  • If you get this type of error “No Remote Programs Registered”, this means you have to check /etc/hosts.allow and /etc/hosts.deny to make sure that the client is actually accessible.
  • If the entries appear to be correct, check /etc/hosts (or your DNS server) and make sure that the machine is listed correctly and also make sure you can ping the server from the client.
  • Check error log for helpful messages: Authentication errors from bad /etc/hosts.allow entries will usually appear in /var/log/messages, but may appear somewhere else depending on how your system logs are set up.
  • The man pages for syslog can help you figure out how to set up logs. Finally, some older operating systems may behave badly when routes between the two machines
    are asymmetric.
  • You can try executing the following command from the client and see if the word "asymmetric" shows up anywhere in the output. If it does then this may be causing packet loss. However asymmetric routes are not usually a problem on recent Linux distributions.
    Tracepath
  • If you get the error “Remote system error” It means that there is no route to host, but if you can ping the server correctly, then you might be having an overzealous firewall. Check any firewalls that may be set up, either on the server or on any routers in between the client and the server.
Problem 4: No access rights to files on mounted volume
Solution:1. If it is a write permission problem, check the export options on the server by looking at /proc/fs/nfs/exports and make sure the filesystem is not exported read-only.
  • You will need to re-export it read/write (don't forget to run exportfs -ra after editing /etc/exports).
  • Also, check /proc/mounts and make sure the volume is mounted read/write (although if it is mounted read-only you ought to get a more specific error message). If not then you need to re-mount with the rw option.
  • If it is the username mappings problem, it is different depending on whether you are trying to do this as root or as a non-root user.
    2a.If you are not root, then usernames may not be in sync on the client and the server.
  • Execute the following on both the client and the server and make sure they give the same UID number. If they don't then you are having problems with NIS, NIS+, rsync, or whatever system you use as sync usernames:
    ~]# id
  • Check group names to make sure that they match as well.
  • Also, make sure you are not exporting with the all_squash option. If the user names match then the user has a more general permissions problem unrelated to NFS.

    2b.If you are root, then you are probably not exporting with the no_root_squash option;
  • Check /proc/fs/nfs/exports or /var/lib/nfs/xtab on the server and make sure the option is listed.
  • Writing to the NFS server as root is a bad idea unless you have an urgent need -- which is why Linux NFS prevents it by default.
  • If you have root squashing and you want to keep it as that setting, you can only try to get root to have the same permissions on the file that the user nobody should have, then remember that it is the server that determines which uid root gets mapped to. By default, the server uses the UID and GID of nobody in the /etc/passwd file, but this can also be overridden with the anonuid and anongid options in the /etc/exports file. Make sure that the client and the server agree about which UID nobody gets mapped to.
Problem 5: File request hang /access to file timeout
Solution:
  • Upgrade to a 2.4 kernel should solve the problem.
  • Export with the no_wdelay option forces the program to use o_sync() instead, which may prove faster.
Problem 6: Strange error/log message
Solution:1. Message in the following format:
Jan 7 09:15:29 server kernel: fh_verify: mail/guest permission failure, acc=4, error=13
Jan 7 09:23:51 server kernel: fh_verify: ekonomi/test permission failure, acc=4, error=13
The messages are harmless.
2. The following messages frequently appear in the logs:
Kernel: nfs: server server.domain.name not responding, still trying
Kernel: nfs: task 10754 can't get a request slot
Kernel: nfs: server server.domain.name OK

The second line message means that the client-side RPC code has detected a lot of timeouts (perhaps due to network congestion, perhaps due to an overloaded server), and is throttling back the number of concurrent outstanding requests in an attempt to lighten the load. The cause of these messages is basically sluggish performance.
3. After mounting, the following message will appear:
nfs warning: mount version older than kernel
Upgrade your mount package and/or am-utils. (If for some reason upgrading is a problem, you may be able to get away with just recompiling them so that the newer kernel features are recognized at compile time).

4. Errors in startup/shutdown log for lockd
nfslock: rpc.lockd startup failed
This message is also harmless. Older versions of rpc.lockd needed to be started up manually, but newer versions are started automatically by nfsd. Many of the default startup scripts still try to start up lockd by hand, in case it is necessary. You can alter your startup scripts if you want the messages to go away.

5. The following message appears in the logs:
kmem_create: forcing size word alignment - nfs_fh
This results from the file handle being 16 bits instead of a multiple of 32 bits, which makes
the kernel grimace. It is harmless.

Problem 7: Real permission doesn’t match permission in /etc/exports
Solution:
/etc/exports are very sensitive to whitespace - so the following statements are not the same:

/export/dir hostname(rw,no_root_squash)
/export/dir hostname (rw,no_root_squash)


The first line will give hostname read/write to /export/dir without squashing root privileges. The second line will give hostname read/write privileges with root squash and it also grant everyone else read/write access, without squashing root privileges.

Problem 8: Flaky and Unreliable behavior
Solution:
Simple commands such as ls will work, but anything that transfers a large amount of information will causes the mount point to lock.
This could be one of two problems:
1. It will happen if you have ipchains on at the server and/or the client and you are not allowing fragmented packets through the chains. Allow fragments from the remote host and you'll be able to function again.

2. You may be using a larger rsize and wsize in your mount options than the server supports. Try reducing rsize and wsize to 1024 and seeing if the problem goes away. If it does, then increase them slowly to a more reasonable value.

Problem 9: nfsd won’t start
Solution:
Check the file /etc/exports and make sure root has read permission. Check the binaries and make sure they are executable. Make sure your kernel was compiled with NFS server support. You may need to reinstall your binaries if none of these ideas helps.

Problem 10: File corruption when having multiple client
Solution:
If a file has been modified within one second of its previous modification and left the same size, it will continue to generate the same inode number. Because of this, constant reads and writes to a file by multiple clients may cause file corruption. Fixing this bug requires changes deep within the filesystem layer.