< Day Day Up > |
NFS allows you to mount disks on remote systems so that they appear as though they are local to your system. Similarly, NFS allows remote systems to mount your local disk so that it looks as though it is local to the remote system. This section goes through a simple NFS server and client setup after NFS background is supplied. You can use standard-mounted directories or automounted directories with NFS. The upcoming example uses standard-mount directories, but you can use automounted directories, which mount remote directories as they are needed. Configuring NFS to achieve this functionality is simple. Here are the steps to go through in order to configure NFS:
Because NFS may be set up on your system to meet the needs of many users, you may want to understand the terminology associated with NFS. The following are commonly used NFS terms:
Example NFS ConfigurationLet's take a look at the steps to set up an NFS server and client. This example is performed on an IA-32 set of systems, but is great for learning the basics of NFS setup in general. Perform the following steps on your NFS server, with hostname asodev, to export the directory /home:
You have enabled NFS for this session, but NFS needs to be permanently enabled if you want to run it after a reboot. This can be done from ksysv.
When exportfs runs, you will have exported /home to linuxdev with read/write access as indicated by the rw. Note that you're allowing the root user on the client to access this directory with no_root_squash. This last option is important because only non-root users will be able to access the directory if it is not specified.
You want to make sure you have NFS running on the server and the/etc/exports file set up on your server so that on reboots of the server, NFS starts automatically and file systems are exported automatically. You have performed all the set up required on the server to export this file system. Next, proceed to the client part of the setup.
You need to complete a couple of steps to mount the remote directory on the client. First, you have to create a mount directory on the client. Next we need to run the mount command to mount the NFS server's directory on our client. Finally, you'll run df to see that it is indeed mounted. These steps are shown here: # mkdir /asodev_home # mount asodev:/home /asodev_home # df Filesystem 1K-blocks Used Available Use% Mounted on /dev/hda5 381139 174830 186631 49% / /dev/hda1 46636 14547 29681 33% /boot /dev/hda3 1423096 241416 1109388 18% /home none 46928 0 46928 0% /dev/shm /dev/hda2 3889924 2513180 1179148 69% /usr /dev/hda6 256667 70400 173015 29% /var /dev/hdb1 38464340 23579884 12930552 65% /home/ linuxconnect/backup asodev:/home 102456 4132 93032 5% /asodev_home # As you can see from the last entry, under df, you have the server directory of asodev:/home mounted in the local directory of /asodev_home on the client. You can now freely share files between these two systems.
The last entry is the NFS mount. This entry is going to mount the remote NFS file system asodev:/home when the client is rebooted. You specified that asodev:/home would be an nfs mount, that the file system is rw so it can be read and written, bg means that this is a background mount so a failed mount will continue trying to execute, and finally, the mount is soft allowing the client to time out after a number of retries. If you go back to the server, you can run showmount to see the remote hosts that have mounted file systems on the server, as shown in the following example: # showmount linuxdev:/home [root@localhost nfs]# This shows that linuxdev is a remote host that has mounted a file system exported by the server asodev. You did not have to run the nfs start command on the client because there were sufficient services running to support an NFS client. Using NFS is not without some security risks because you now have data that is shared on your network and many ports are now open. The following example shows a partial output of the nmap command: # nmap -sT -O localhost Starting nmap V. 3.00 ( www.insecure.org/nmap/ ) Insufficient responses for TCP sequencing (0), OS detection may be less accurate Insufficient responses for TCP sequencing (3), OS detection may be less accurate Interesting ports on localhost.localdomain (127.0.0.1): (The 1592 ports scanned but not shown below are in state: closed) Port State Service 22/tcp open ssh 23/tcp open telnet 25/tcp open smtp 111/tcp open sunrpc 989/tcp open ftps-data 1024/tcp open kdm 1031/tcp open iad2 1032/tcp open iad3 6000/tcp open X11 . . . This output shows that several ports are now open, including the telnet session used to obtain these examples from the system and several ports related to our NFS work. You used the -sT option, which is the most basic form of TCP scanning. You also used -O, which guesses the operating system of the machine. The following example is the output of the same command from the NFS client in the example: # nmap -sT -O localhost Starting nmap V. 3.00 ( www.insecure.org/nmap/ ) Interesting ports on localhost.localdomain (127.0.0.1): (The 1590 ports scanned but not shown below are in state: closed) Port State Service 21/tcp open ftp 22/tcp open ssh 23/tcp open telnet 25/tcp open smtp 111/tcp open sunrpc 139/tcp open netbios-ssn 901/tcp open samba-swat 1024/tcp open kdm 1025/tcp open NFS-or-IIS 6000/tcp open X11 10000/tcp open snet-sensor-mgmt Remote OS guesses: Linux Kernel 2.4.0 - 2.5.20, Linux 2.5.25 or Gen- too 1.2 Linux 2.4.19 rc 1-rc7) Nmap run completed -- 1 IP address (1 host up) scanned in 6 seconds This system has additional ports open, such as 901, which is for the swat tool used to configure samba. There are no unknown ports in these two outputs, so we at least know that the ports are used for known services (which are defined in /etc/services). NFS is a commonly used technique for data sharing across the network on Linux and UNIX systems. This is easy to set up and use and it is provided as a standard component in operating systems. |
< Day Day Up > |