Showing posts with label NFS. Show all posts
Showing posts with label NFS. Show all posts

Wednesday, 1 May 2013

How to setup AUTOFS / AUTOMOUNT in NFS

Using Automount services(Autofs)

# vim auto.master
  /home   /etc/auto.home

# vim auto.home
   nfs  -rw  192.168.0.130:/home/nfs

Started autofs. Logged in as an NFS user and the exported home directory get automatically mounted.

# vim /etc/auto.master
/home /etc/auto.home  ------ means to mount directory specified in auto.home into "/home" all NFS shares specified in auto.home should mount under "/home"

# vim auto.home
nfs -rw 192.168.0.130:/home/nfs 

------ "192.168.0.130:/home/nfs" will be mounted into
 "nfs"(nfs -- first field)

SERVER SetUP


# mkdir /automount
# cd /automount/
# mkdir documents
# touch documents/commands.txt

# vim /etc/exports
/automount      10.0.0.154/255.0.0.0(rw,sync)
 

# service nfs restart
# service nfslock restart

CLIENT SetUp

 
# vim /etc/auto.master
   /test    /etc/auto.test

# vim/etc/auto.test
  autofs  rw,sync  10.0.0.180:/automount

# service autofs restart

NFS Mounting options -Soft v/s Hard Mounting

Soft v/s Hard Mounting

There are some options which govern the way the NFS client handles a server crash or network outage. one of the cool things about NFS is that it can handle this gracefully if you set up the client right. There are two distinct failure modes:
 
Soft

 
If a file request fails, the NFS client will report an error to the process on thee client machine requesting the file access.

Hard

The programme accessing a file on a NFS mounted file system will hang when the server crashes. The process cannot be interrupted or killed (except be a "sure kill") unless you also specify intr. When the NFS server is back online the program will continue undisturbed from where it was. We recommend using hard,intr on all NFS mounted file systems.

ex:
  
Device    mountpoint fs-type   options      dump  fsckorder

Host:/home /home1     nfs     rw,hard,intr    0      0

Setting block size to optimize transfer speed

The rsize and wsize mount options specify the site of the chunks of data that the client and server pass back and forth to each other.

rsize = n will set the NFS read buffer size to n bytes

        (default is 4096)
wsize - n will set the NFS write buffer size to n bytes(")

While mounting manually the mount options can be specified as below
 
# mount -t nfs 192.168.0.25:/home /home1 -o rsize=8292,wsize=8192,hard,intr,nolock

nolock disables NFS locking and stops the statd and lockd daemons and lock will enable it.

How to Setup NFS Server in Linux

NFS depends on the portmapper daemon
/etc/init.d/portmap start
/etc/init.d/portmap status

Providing NFS service requires the service of si daemons,

portmap:Enables NFS clients to discover the NFS services

         available on a given NFS server
nfsd   :provides all NFS services except file locking and

         quota management
lockd  :Starts the kernels NFS lock manager
statd  :Implements NFS lock recovery when an NFS server

        system crashes
rquotad:Handles user file quotas on exported volumes to NFS

        clients
mountd : Processes NFS client mount requests

The daemons are all part of the nfs-utils package. If your distribution does not include them in the startup scripts, then you should add them and configure it to start in the following

order,
  portmap
  nfsd
  mountd
  statd
  rquotad (if necessary)

The nfs-utils package has a sample startup script for redhat and the script will take care of starting all the NFS server daemons for you except the portmapper.

/etc/rc.d/init.d/nfs start/stop/status/restart
/etc/init.d/portmap start
/etc/init.d/nfs start
/etc/init.d/nfslock start


Verifying that NFS is running

To do this, query the portmapper with the command 


# rpcinfo -p
 

to find out what services it is providing. You should get something like this:

# rpcinfo -p portmapper

Making changes to /etc/exports later on

If you come back and change your /etc/exports file, the changes you make may not take effect immediately.  You should therefore run the command


# rpcinfo -pra -- to force nfsd to re-read the /etc/exports file. If you can't find exportfs command, then you can kill nfsd and restart it.

exportfs command will also let you manipulate the list of available exports or list the currently exported file systems

# exportfs -v // List currently exported file systems

# exportfs -v -u 192.168.0.25:/home // remove an exported 

         file system

Setting up an NFS Client

1. Mounting remote directories:

Firstly, kernal on the client machine needs to be compiled with NFS support.

Portmapper should be running on the client machine and to use NFS file locking you also need statd and lockd running on both the client and the server. With portmap,lockd, and statd running you should now be able to mount the remote directory from your server just the way you mount a local hard drive, with the mount command

mounting home dir of master.com to slave.com

 # mount -t nfs 192.168.0.25:/home /home1 OR
 # mount -t nfs 192.168.0.25:/home /home1 -o -rw,soft

to unmount the file system

# umount /home1
 

Getting NFS file system to be mounted at boot time

NFS file systems can be added to /etc/fstab, the only difference is that the file system type will be set to nfs and the dump and fsck order will have to
be set to zero.

ex:
   

Device        mountpoint fs-type options dump fsckorder
host.com:/home  /home1    nfs      rw     0     0


Tuesday, 30 April 2013

NFS Server (Network File Systems)

NFS was developed to allow machines to mount a disk partition on a remote machines as if it were on a local hard drive.

--->  This allows for fast seamless sharing of files across a network.
 

---> Main config files to edit to setup an nfs server are:

           1. /etc/exports
           2. /etc/hosts.allow
           3. /etc/hosts.deny



/etc/exports file 

exports file contains a list of entries, each entry indicates a volume that is shared and how its shared.

EX:- 
directory machine1(option11,option12) machine2(option21,option22)

Where
Directory: The directory that want to share. It may be an entire volume though it need no be. If you share a directory then all directories under it within the same file system will be shared as well.


machine1 and machine2: client machines that will have access to the directory. The machines may be listed by their DNS address or their IP address (machine.company.com or 192.168.0.25) Using Ip address is more reliable and more secure.

Option XX: The option listing for each machine will describe what kind of access that machine will have. Imp options are,
     
A.ro: The directory is shared read only; the client machine will

  not be able to write to it. This is the default.

B.rw: The client machine will have read and write access to the

  directory.

C.no_root_squash: By default, any file request made by user root on the client machine is treated as if it is made by user nobody on the server.If no_root_squash is selected, then root on the client machine will have the same level of access to the files on the system as root on the server. This can have serious security implications, although it may be necessary if you want to perform any administrative work on the client machine that involves the exported directories. You should not specify this option without a good reason.

D.no_subtree_check: if only part of a volume is exported, a routine called subtree checking verifies that a file that is requested from the client is in the appropriate part of the volume: if the entire volume is exported disabling this check will speed up transfers.

E.sync: By deault, all but the most recent version of the exportfs command will use async behavior, telling a client machine that a file write is complete.
  ie, it has been written to stable storage - when NFS has finished handing the write over to the file system. This behavior may cause data corruption if the server reboots, and sync option prevents this.
             
EG: /var/tmp 192.168.0.25(async,rw)


/etc/hosts.allow and /etc/hosts.deny

Those two files specify which computers on the network can use services on your machine. Each line of the file contains a single entry listing a service and a set of machines.


When a server gets a request from a machine, it does the following,
----> It first checks the hosts.allow file to see if the machine matches a description listed in there. If it does then the machnie is allowed access.


----> if the machine does not matches an entiry in hosts.allow, the server then checks hosts.deny to see if the client matches a listing in there.if it does then the machine is denied access.


----> if the client matches no listings in either file, then it is allowed access.


Configuring /etc/hosts.allow and /etc/hosts.deny for NFS security

----> In addition to controlling access to services handled by inetd, this file can also control access to NFS by restricting connections to the daemons that provide NFS services. Restrictions are done on a pre-services basic.
      
----> The first daemon to restrict access to is the portmapper. This daemon essentialy just tells requesting clients how to find all the NFS services on the system.
       
----> Restricting access to the portmapper is the best defense against someone braking into your system through NFS because completely unauthorized clients won't know where to find the NFS daemons.
       
----> However there are two things to watch out for, First restricting portmapper isn't enough if the intruder already knows for some reason how to find those daemons. And second, if you are running NIS, restricting portmapper will also restrict request to NIS. In general it is a good idea with NFS to explicitly deny access to IP address that you don't need to allow access to.
   
----> The first step in doing this is to add the following entry to /etc/hosts.deny
         portmap:ALL


----> If you have a newer version of nfs-utils, add entires for each of the NFS daemons in hosts.deny
            lockd:ALL
            mountd:ALL
            rquotad:ALL
            statd:ALL


----> If we choose ALL:ALL in the file /etc/hosts.deny, which causes any service that looks at these files to deny access to all hosts unless it is explicitly allowed.
        
----> In hosts.allow use the following format  


service: host [or network/netmask], host [or network/netmask]
     
here host is IP address of a potential client. If we want to allow access to 192.168.0.1 and 192.168.0.2, we could add the following entry to /etc/hosts.allow
   portmap: 192.168.0.1 , 192.168.0.2
 

For recent nfs-utils versions, we would also add the following
[these entries are harmless even if they are not supported]
    lockd: 192.168.0.1 , 192.168.0.2
    mountd: 192.168.0.1 , 192.168.0.2
    rquotad: 192.168.0.1 , 192.168.0.2
    statd: 192.168.0.1 , 192.168.0.2

---- If you ntend to run NFS on a large number of machines in a local network, /etc/hosts.allow also allow for network/netmask style entries in the same manner as /etc/exports above.