Network File System (NFS)

 < 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:

1. Start NFS on the server.

2. Setup /etc/exports on the server.

3. Run exportfs on the server.

4. Create a directory on the client under which the remote directory will be mounted.

5. Mount the remote disks on the client.

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:

Node

A computer system that is attached to or is part of a computer network.

Client

A node that requests data or services from other nodes (servers).

Server

A node that provides data or services to other nodes (clients) on the network.

File system

A disk partition or logical volume.

Export

Makes a file system available for mounting on remote nodes using NFS.

Mount

Accesses a remote file system using NFS.

Mount point

The name of a directory on which the NFS file system is mounted.

Import

Mounts a remote file system.


Example NFS Configuration

Let'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:

1. Start NFS:

 # rpcinfo -p    program vers proto   port     100000    2   tcp    111  portmapper     100000    2   udp    111  portmapper     100024    1   udp   1024  status     100024    1   tcp   1024  status     391002    2   tcp   1031  sgi_fam # /etc/rc.d/init.d/nfs start Starting NFS services: 60G[  0;32mOK0;39m  ] Starting NFS quotas: 60G[  0;32mOK0;39m  ] Starting NFS daemon: 60G[  0;32mOK0;39m  ] Starting NFS mountd: 60G[  0;32mOK0;39m  ] # rpcinfo -p    program vers proto   port     100000    2   tcp    111  portmapper     100000    2   udp    111  portmapper     100024    1   udp   1024  status     100024    1   tcp   1024  status     391002    2   tcp   1031  sgi_fam     100011    1   udp    986  rquotad     100011    2   udp    986  rquotad     100011    1   tcp    989  rquotad     100011    2   tcp    989  rquotad     100003    2   udp   2049  nfs     100003    3   udp   2049  nfs     100021    1   udp   1026  nlockmgr     100021    3   udp   1026  nlockmgr     100021    4   udp   1026  nlockmgr     100005    1   udp   1027  mountd     100005    1   tcp   1032  mountd     100005    2   udp   1027  mountd     100005    2   tcp   1032  mountd     100005    3   udp   1027  mountd     100005    3   tcp   1032  mountd 

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.

2. Update the /etc/exports file to include a directory, which we want to be available to all systems as shown below:

 # cat /etc/exports # /etc/exports for linux development /home   linuxdev(rw,no_root_squash) 

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.

3. The last step to perform on the server is to run the exportfs command to make /home available to other systems:

 # exportfs -a exportfs:  No  'sync'  or  'async'  option  specified  for  export "linuxdev:/home".   Assuming default behaviour ('sync').   NOTE: this default has changed from previous versions 

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.

1. Next, update the /etc/fstab file to include the mount.

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.

2. To make this mount persist across reboots, you need to update the /etc/fstab file to include the entry for /asodev_home, as shown in the following example:

 # cat /etc/fstab LABEL=/           /                         ext3    defaults       1 1 LABEL=/boot       /boot                     ext3    defaults       1 2 none              /dev/pts                  devpts  gid=5,mode=620 0 0 LABEL=/home       /home                     ext3    defaults       1 2 none              /proc                     proc    defaults       0 0 none              /dev/shm                  tmpfs   defaults       0 0 LABEL=/usr        /usr                      ext3    defaults       1 2 LABEL=/var        /var                      ext3    defaults       1 2 LABEL=/backup     /home/linuxconnect/backup ext3    defaults       1 2 /dev/hda7         swap                      swap    defaults       0 0 /dev/fd0         /mnt/floppy            auto    noauto,owner,kudzu 0 0 /dev/cdrom       /mnt/cdrom      iso9660 noauto,owner,kudzu,ro     0 0 asodev:/home     /asodev_home              nfs     rw,bg,soft     0 0 

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 > 


    Linux on HP Integrity Servers. A System Administrator's Guide
    Linux on HP Integrity Servers: A System Administrators Guide
    ISBN: 0131400002
    EAN: 2147483647
    Year: 2004
    Pages: 100

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net