1 / 15

Remote Disk Access with NFS

Remote Disk Access with NFS. NFS Background. Developed inside Sun Microsystems in early 1980’s Based on 2 similar but distinct protocols MOUNT  Initial Negotiation between Server and Client Determines which file systems are available for mounting

teresa
Download Presentation

Remote Disk Access with NFS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Remote Disk Access with NFS

  2. NFS Background • Developed inside Sun Microsystems in early 1980’s • Based on 2 similar but distinct protocols • MOUNT Initial Negotiation between Server and Client • Determines which file systems are available for mounting • NFS Allows Client to Utilize Files in Directory

  3. NFS Description • Network File System(NFS) • An abbreviation for Network File System, a file format and set of drivers created by Sun Microsystems Incorporated that allows DOS/Windows and UNIX applications to share files on disk drives running under UNIX. NFS relies on remote procedure calls (RPCs) for communication between clients and servers. • Allows any network user to access disk space over a networks. • Incorporates with NIS to access specific file folders for each user

  4. Important NFS Concepts • Virtual File System (VFS) – transparently and automatically redirects for mounted files to the server • Remote Procedure Call (RPC) – used for background mounting of a folder with a file system • Hard Mounting – Continuously trying to remount a file system • Soft Mounting – Repeated RPC failures cause the NFS to fail and not hang

  5. Important NFS Daemons • portmap – manages connections for applications that use the RPC specification • nfs – starts necessary RPC processes • nfslock – allows clients to lock files within the NFS file system • netfs – allows processes running on the client to mount an NFS file system

  6. Installing NFS • RedHat Linux installs NFS by default • Automatically activated when system boots • To check: • rpm –qa | grep nfs • If list is empty, one needs to installed • Another way : • yum install nfs*

  7. Configuring NFS on the Server • Needs • portmap • nfs • nfslock • Correctly configured /etc/exports file

  8. Configuring the /etc/exports file • Main NFS configuration file • 2 columns: • 1st Directories made available on the network • 2nd Networks or DNS domains that can access the directories and options • Options include: • ro, rw, no_root_squash, no_subtree_check, sync

  9. The /etc/exports file #/etc/exports /public 134.198.161.101(rw, sync, no_root_squash) /public 134.198.161.102(rw, sync, no_root_squash) /public 134.198.161.103(rw, sync, no_root_squash) /public 134.198.161.104(rw, sync, no_root_squash) /public 134.198.161.254(rw, sync, no_root_squash) • NFS Users Control Panel in Linux

  10. Starting NFS on the Server • Configure required daemons chkconfig –level 35 nfs on chkconfig –level 35 nfslock on chkconfig –level 35 portmap on • Use /etc/init.d to start daemons service portmap start service nfs start service nfslock start • Test NFS rpcinfo –p localhost

  11. Starting NFS on the Client • Configure required daemons chkconfig –level 35 netfs on chkconfig –level 35 nfslock on chkconfig –level 35 portmap on • Use /etc/init.d to start daemons service portmap start service netfs start service nfslock start • Test NFS rpcinfo –p

  12. NFS Directory Mounting -- Temporary mkdir /home ls /home mount –t nfs 134.198.161.103:/public /home ls /home <Listing of Directory>

  13. Security Levels • “Share-wide”: authorized clients can access any file under that share. • “File-level”: before accessing any file, client needs to be authenticated; in fact, client authenticated once and uses UID for future accesses.

  14. Server security: nfsd and mountd • On the server we can decide that we don't want to trust any requests made as root on the client. We can do that by using the root_squash option in /etc/exports: /home slave1(rw,root_squash)

  15. This is, in fact, the default. It should always be turned on unless you have a very good reason to turn it off. To turn it off use the no_root_squash option. • Now, if a user with UID 0 (i.e., root's user ID number) on the client attempts to access (read, write, delete) the file system, the server substitutes the UID of the server's 'nobody' account. Which means that the root user on the client can't access or change files that only root on the server can access or change.

More Related