NFS and NIS

Certify and Increase Opportunity.
Be
Govt. Certified Linux Administrator

NFS

NFS, the Network File System, is the most common method for providing file sharing services on Linux and Unix networks. It is a distributed file system that enables local access to remote disks and file systems. Indeed, in a properly designed and implemented NFS environment, NFS ’s operation is totally transparent to clients using remote file systems. NFS is also a popular file sharing protocol, so NFS clients are available for many non-Unix operating systems, including the various Windows versions, MacOS, VAX/VMS, and MVS.

NFS uses a standard client/server architecture. The server portion consists of the physical disks containing shared file systems and several daemons that make the shared file systems (or entire disks, for that matter) visible to and available for use by client systems on the network. This process is normally referred to as exporting a file system. Server daemons also provide for file locking and, optionally, quota management on NFS exports. NFS clients simply mount the exported file systems, colloquially but accurately called NFS mounts, on their local system just as they would mount file systems on local disks.

The possible uses of NFS are quite varied. For example, many sites store users’ home directories on a central server and use NFS to mount the home directory when users log in or boot their systems. Of course, in this case, the exported directories must be mounted as /home/username on the local (client) systems, but the export itself can be stored anywhere on the NFS server, say, /exports/users/username . Another common scheme is to export public data or project-specific files from an NFS server and to enable clients to mount these remote file systems anywhere they see fit on the local system.

The network shown in figure above shows that all the client systems (pear, mango , and so forth) mount their home directories from an NFS server named diskbeast. On diskbeast, the exported file systems are stored in the /exports/homes directory (/exports/homes/u1, /exports/homes/u2, and so on). When users log in to any given system, their home directory is automatically mounted on /home/username on that system. So, if the user u1logs in on pear, /exports/homes/u1is mounted on pear’s file system as /home/u1 (often written in host:/mount/point format, for example, pear:/home/u1 ). If u1 then logs in on mango , too (not illustrated in the figure), mango also mounts /home/u1 . Of course, logging in on two systems this way is potentially dangerous because changes to files in the exported file system made from one login session may affect the behavior of the other, but it is also very convenient, in other situations, for such changes to be immediately visible.

NFS is also used to provide diskless clients, such as X terminals or the slave nodes in a cluster, with their entire file system, including the kernel image and other boot files. Although the examples mentioned illustrate typical NFS usage, NFS can be used in almost any situation requiring transparent local access to remote file systems. In fact, you can use NFS and NIS together to create a highly centralized network environment that makes it easier to administer the network, add and delete user accounts, protect and back up key data and file systems, and give users a uniform, consistent view of the network regardless of where they log in.

Configuring NFS – Configuration of NFS is pretty simple. You add the directories you wish to export to the file /etc/exports.

• Create a directory called /public with the following command – mkdir /public
• Populate it with three empty files – touch /public/nfs1 /public/nfs2 /public/nfs3
• Next, edit the file /etc/exports – vi /etc/exports

Add the following line to /etc/exports:

/public   *(ro,sync)

Here’s an explanation of the fields in the command:

/public–The directory to be shared

*–The clients allowed to access the share. You can restrict it by IP address. For example, you could, instead of the asterisk, put

192.168.0.0/24 to restrict it to clients on the 192.168.0.0/24 network.

ro–Read only access

sync–Reply to requests only after any changes have been committed to stable storage. This is a slower, but more stable option than alternatives.

In the following screen capture, you can see how I configured /etc/exports to share /public:

NFS requires the rpcbind service to be running. Start it with the following command:

service rpcbind start

Then, start the nfs server:

/etc/init.d/nfs start

If you want NFS to start at boot, use the following command:

chkconfig –levels 235 nfs on

Enable the export immediately with the command exportfs -v. You can view the export with the command showmount -e. If you are using a firewall, you must explicitly allow traffic from your local subnet to access the server.

Configuring the NFS Client – You must install the nfs package on the client with this command:

yum -y install nfs-utils nfs-utils-lib

Once the package is installed, you can use the showmount command to view exports on an NFS server:

You can also create a new directory on your client and mount the NFS export to the directory, thus giving you access to the files in the directory:

In the above example, I mounted the export from LinuxServer01 (/public) to a directory on my local client machine, called ubuntuServer02. As you can see, after it was mounted, I was able to view the contents of the exported directory locally.

Using rsync to Synchronize Files between Servers – When administering file servers, you may want to configure replication to help minimize the chance of data loss in the event of a server crash. One way to do that is with the rsync utility, which allows you to seamlessly move one or more files from one server to another. Unlike a simple file copy, however, rsync can perform differential file transfers, transferring only the data that has changed. A benefit of rsync is that mirroring occurs with only a single transmission in each direction.

NIS

The Network Information Service distributes information that needs to be shared throughout a Linux network to all machines on the network. NIS was originally developed by Sun Microsystems and known as Yellow Pages (YP), so many commands begin with the letters yp, such as ypserv, ypbind, and yppasswd .

The information most commonly distributed across a network using NIS consists of user database and authentication information, such as /etc/passwd and /etc/group . If, for example, a user ’s password entry is shared by all login hosts via the NIS password database, that user is able to log in on all login hosts on the network, all hosts, that is, that are running the NIS client programs. However, user authentication databases are not the only use for NIS — any information that needs to be distributed across a network and that can or should be centrally administered

NIS uses a standard client-server architecture arrayed in one of several possible configurations. NIS configurations revolve around the notion of a domain. An NIS domain is not the same as an Internet or DNS domain. A DNS domain name (more specifically, a fully qualified domain name, or FQDN), as you know, is the official name that uniquely identifies a system to the Internet domain name system. An NIS domain name refers to a group of systems, typically on a LAN or on only a subnet of a LAN, that use the same NIS maps. NIS domains are typically used as system management tools, a convenient method for organizing groups of machines that need to access the information shared across a network using a set of common NIS maps.

NIS databases are stored in DBM format, a binary file format based on simple ASCII text files. For example, the files /etc/passwd and /etc/group can be converted directly to DBM format using an ASCII-to-DBM conversion program named makedbm.

Each NIS domain must have at least one system that functions as an NIS server for that domain. An NIS server is a centrally-administered repository for information that is shared across the network using NIS. NIS clients are programs that use NIS to query designated servers for information that is stored in the servers’ databases, which are known as maps. NIS servers can be further subdivided into master and slave servers. A master server maintains the authoritative copies of the NIS maps.

A slaveserver maintains copies of the NIS databases, which it receives from the master NIS server whenever changes are made to the databases stored on the master. In NIS configurations that use slave servers, the slaves receive copies of the DBM databases, not the ASCII source files. The yppush program notifies slave servers of changes to the NIS maps, and then the slaves automatically retrieve the updated maps in order to synchronize their databases with the master. NIS clients do not need to do this because they communicate with their designated server(s) to obtain current information. The rationale for slave servers is to provide redundancy — if the master server is unavailable for some reason, slave servers function as backup servers until the master is again available.

Four NIS topologies are commonly used:

• A single domain with a master server, no slave servers, and one or more clients
• A single domain with a master server, one or more slave servers, and one or more clients
• Multiple domains, each with its own master server, no slave servers, and one or more clients
• Multiple domains, each with its own master server, one or more slave servers, and one or more clients

Configuring the NIS Master Server – The canonical copies of all NIS files are stored on the master server. The databases used to store the information are called NIS maps. In FreeBSD, these maps are stored in /var/yp/[domainname] where [domainname] is the name of the NIS domain. Since multiple domains are supported, it is possible to have several directories, one for each domain. Each domain will have its own independent set of maps.

NIS master and slave servers handle all NIS requests through ypserv(8). This daemon is responsible for receiving incoming requests from NIS clients, translating the requested domain and map name to a path to the corresponding database file, and transmitting data from the database back to the client.

Setting up a master NIS server can be relatively straight forward, depending on environmental needs. Since FreeBSD provides built-in NIS support, it only needs to be enabled by adding the following lines to /etc/rc.conf:

nisdomainname=”test-domain”

nis_server_enable=”YES”

nis_yppasswdd_enable=”YES”

• Line 1 – This line sets the NIS domain name to test-domain.
• Line 2 – This automates the start up of the NIS server processes when the system boots.
• Line 3 – This enables the rpc.yppasswdd(8) daemon so that users can change their NIS password from a client machine.

Care must be taken in a multi-server domain where the server machines are also NIS clients. It is generally a good idea to force the servers to bind to themselves rather than allowing them to broadcast bind requests and possibly become bound to each other. Strange failure modes can result if one server goes down and others are dependent upon it. Eventually, all the clients will time out and attempt to bind to other servers, but the delay involved can be considerable and the failure mode is still present since the servers might bind to each other all over again.

A server that is also a client can be forced to bind to a particular server by adding these additional lines to /etc/rc.conf:

nis_client_enable=”YES” # run client stuff as well

nis_client_flags=”-S NIS domain,server”

After saving the edits, type /etc/netstart to restart the network and apply the values defined in /etc/rc.conf. Before initializing the NIS maps, start ypserv(8):

# service ypserv start

Setting up a NIS Slave Server – To set up an NIS slave server, log on to the slave server and edit /etc/rc.conf as for the master server. Do not generate any NIS maps, as these already exist on the master server. When running ypinit on the slave server, use -s (for slave) instead of -m (for master). This option requires the name of the NIS master in addition to the domain name

To finish the configuration, run /etc/netstart on the slave server in order to start the NIS services.

Setting Up an NIS Client – An NIS client binds to an NIS server using ypbind(8). This daemon broadcasts RPC requests on the local network. These requests specify the domain name configured on the client. If an NIS server in the same domain receives one of the broadcasts, it will respond to ypbind, which will record the server’s address. If there are several servers available, the client will use the address of the first server to respond and will direct all of its NIS requests to that server. The client will automatically ping the server on a regular basis to make sure it is still available. If it fails to receive a reply within a reasonable amount of time, ypbind will mark the domain as unbound and begin broadcasting again in the hopes of locating another server.

To start the NIS client immediately, execute the following commands as the superuser:

# /etc/netstart

# service ypbind start

After completing these steps, running ypcat passwd on the client should show the server’s passwd map.

Back to Tutorial