NFS and NIS
NIS
Network Information Service is a client-server directory service protocol for distributing system configuration data such as user and host names between computers on a computer network. NIS allows a group of machines within an NIS domain to share a common set of configuration files. This permits a system administrator to set up NIS client systems with only minimal configuration data and add, remove or modify configuration data from a single location. NIS was first developed by Sun Microsystems to centralize administration of SunOS systems. Now, NIS is supported by all major Unix-based systems including Solaris, HP-UX, AIX, Linux, NetBSD, OpenBSD, and others.
The Network Information Service, or NIS (originally called Yellow Pages or YP) is a client–server directory service protocol for distributing system configuration data such as user and host names between computers on a computer network. Sun Microsystems developed the NIS; the technology is licensed to virtually all other Unix vendors.
Because British Telecom PLC owned the name "Yellow Pages" as a registered trademark in the United Kingdom for its paper-based, commercial telephone directory, Sun changed the name of its system to NIS, though all the commands and functions still start with “yp”.
A NIS/YP system maintains and distributes a central directory of user and group information, hostnames, e-mail aliases and other text-based tables of information in a computer network. For example, in a common UNIX environment, the list of users for identification is placed in /etc/passwd, and secret authentication hashes in /etc/shadow. NIS adds another “global” user list which is used for identifying users on any client of the NIS domain.
Administrators have the ability to configure NIS to serve password data to outside processes to authenticate users using various versions of the Unix crypt(3) hash algorithms. However in such cases, any NIS client can retrieve the entire password database for offline inspection. Kerberos was designed to handle authentication in a more secure manner.
Configuring The NFS Server
Here are the steps to configure the NFS server in this scenario:
1. Edit the /etc/exports file to allow NFS mounts of the /home directory with read/write access.
/home *(rw,sync)
2. Let NFS read the /etc/exports file for the new entry, and make /home available to the network with the exportfs command.
[root@bigboy tmp]# exportfs -a [root@bigboy tmp]#
3. Make sure the required nfs, nfslock, and portmap daemons are both running and configured to start after the next reboot.
[root@bigboy tmp]# chkconfig nfslock on [root@bigboy tmp]# chkconfig nfs on [root@bigboy tmp]# chkconfig portmap on [root@bigboy tmp]# service portmap start Starting portmapper: [ OK ] [root@bigboy tmp]# service nfslock start Starting NFS statd: [ OK ] [root@bigboy tmp]# service nfs start Starting NFS services: [ OK ] Starting NFS quotas: [ OK ] Starting NFS daemon: [ OK ] Starting NFS mountd: [ OK ] [root@bigboy tmp]#
After configuring the NFS server, we have to configure its clients, This will be covered next.
Configuring The NFS Client
You also need to configure the NFS clients to mount their /home directories on the NFS server.
These steps archive the /home directory. In a production environment in which the /home directory would be actively used, you'd have to force the users to log off, backup the data, restore it to the NFS server, and then follow the steps below. As this is a lab environment, these prerequisites aren't necessary.
1. Make sure the required netfs, nfslock, and portmap daemons are running and configured to start after the next reboot.
[root@smallfry tmp]# chkconfig nfslock on [root@smallfry tmp]# chkconfig netfs on [root@smallfry tmp]# chkconfig portmap on [root@smallfry tmp]# service portmap start Starting portmapper: [ OK ] [root@smallfry tmp]# service netfs start Mounting other filesystems: [ OK ] [root@smallfry tmp]# service nfslock start Starting NFS statd: [ OK ] [root@smallfry tmp]#
2. Keep a copy of the old /home directory, and create a new directory /home on which you'll mount the NFS server's directory.
[root@smallfry tmp]# mv /home /home.save [root@smallfry tmp]# mkdir /home [root@smallfry tmp]# ll / ... ... drwxr-xr-x 1 root root 11 Nov 16 20:22 home drwxr-xr-x 2 root root 4096 Jan 24 2003 home.save ... ... [root@smallfry tmp]#
3. Make sure you can mount bigboy's /home directory on the new /home directory you just created. Unmount it once everything looks correct.
[root@smallfry tmp]# mount 192.168.1.100:/home /home/ [root@smallfry tmp]# ls /home ftpinstall nisuser quotauser smallfry www [root@smallfry tmp]# umount /home [root@smallfry tmp]#
4. Start configuring autofs automounting. Edit your /etc/auto.master file to refer to file /etc/auto.home for mounting information whenever the /home directory is accessed. After five minutes, autofs unmounts the directory.
#/etc/auto.master /home /etc/auto.home --timeout 600
5. Edit file /etc/auto.home to do the NFS mount whenever the /home directory is accessed. If the line is too long to view on your screen, you can add a \ character at the end to continue on the next line.
#/etc/auto.home * -fstype=nfs,soft,intr,rsize=8192,wsize=8192,nosuid,tcp \ 192.168.1.100:/home/&
6. Start autofs and make sure it starts after the next reboot with the chkconfig command.
[root@smallfry tmp]# chkconfig autofs on [root@smallfry tmp]# service autofs restart Stopping automount:[ OK ] Starting automount:[ OK ] [root@smallfry tmp]#
After doing this, you won't be able to see the contents of the /home directory on bigboy as user root. This is because by default NFS activates the root squash feature, which disables this user from having privileged access to directories on remote NFS servers. You'll be able to test this later after NIS is configured.
Note: This automounter feature doesn't appear to function correctly in my preliminary testing of Fedora Core 3. See Chapter 29, "Remote Disk Access with NFS", for details.
All newly added Linux users will now be assigned a home directory under the new remote /home directory. This scheme will make the users feel their home directories are local, when in reality they are automatically mounted and accessed over your network.
Configuring The NIS Server
NFS only covers file sharing over the network. You now have to configure NIS login authentication for the lab students before the job is done. The configuration of the NIS server is not difficult, but requires many steps that you may overlook. Don't worry, we'll review each one in detail.
Note: In the early days, NIS was called Yellow Pages. The developers had to change the name after a copyright infringement lawsuit, yet many of the key programs associated with NIS have kept their original names beginning with yp.
Install the NIS Server Packages
All the packages required for NIS clients are a standard part of most Fedora installations. The ypserv package for servers is not. Install the package according to the steps outlined in Chapter 6,"Installing Linux Software".
Edit Your /etc/sysconfig/network File
You need to add the NIS domain you wish to use in the /etc/sysconfig/network file. For the school, call the domain NIS-SCHOOL-NETWORK.
#/etc/sysconfig/network NISDOMAIN="NIS-SCHOOL-NETWORK"
Edit Your /etc/yp.conf File
NIS servers also have to be NIS clients themselves, so you'll have to edit the NIS client configuration file /etc/yp.conf to list the domain's NIS server as being the server itself or localhost.
# /etc/yp.conf - ypbind configuration file ypserver 127.0.0.1
Start The Key NIS Server Related Daemons
Start the necessary NIS daemons in the /etc/init.d directory and use the chkconfig command to ensure they start after the next reboot.
[root@bigboy tmp]# service portmap start Starting portmapper: [ OK ] [root@bigboy tmp]# service yppasswdd start Starting YP passwd service: [ OK ] [root@bigboy tmp]# service ypserv start Setting NIS domain name NIS-SCHOOL-NETWORK: [ OK ] Starting YP server services: [ OK ] [root@bigboy tmp]# [root@bigboy tmp]# chkconfig portmap on [root@bigboy tmp]# chkconfig yppasswdd on [root@bigboy tmp]# chkconfig ypserv on
Table 30.1 lists a summary of the daemon's functions.
Table 30-1 Required NIS Server Daemons
| Daemon Name | Purpose |
|---|---|
| portmap | The foundation RPC daemon upon which NIS runs. |
| yppasswdd | Lets users change their passwords on the NIS server from NIS clients |
| ypserv | Main NIS server daemon |
| ypbind | Main NIS client daemon |
| ypxfrd | Used to speed up the transfer of very large NIS maps |
Make sure they are all running before continuing to the next step. You can use the rpcinfo command to do this.
[root@bigboy tmp]# rpcinfo -p localhost
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100009 1 udp 681 yppasswdd
100004 2 udp 698 ypserv
100004 1 udp 698 ypserv
100004 2 tcp 701 ypserv
100004 1 tcp 701 ypserv
[root@bigboy tmp]#
The ypbind and ypxfrd daemons won't start properly until after you initialize the NIS domain. You'll start these daemons after initialization is completed.
Initialize Your NIS Domain
Now that you have decided on the name of the NIS domain, you'll have to use the ypinit command to create the associated authentication files for the domain. You will be prompted for the name of the NIS server, which in this case is bigboy.
With this procedure, all nonprivileged accounts are automatically accessible via NIS.
[root@bigboy tmp]# /usr/lib/yp/ypinit -m At this point, we have to construct a list of the hosts which will run NIS servers. bigboy is in the list of NIS server hosts. Please continue to add the names for the other hosts, one per line. When you are done with the list, type a. next host to add: bigboy next host to add: The current list of NIS servers looks like this: bigboy Is this correct? [y/n: y] y We need a few minutes to build the databases... Building /var/yp/NIS-SCHOOL-NETWORK/ypservers... Running /var/yp/Makefile... gmake[1]: Entering directory `/var/yp/NIS-SCHOOL-NETWORK' Updating passwd.byname... Updating passwd.byuid... Updating group.byname... Updating group.bygid... Updating hosts.byname... Updating hosts.byaddr... Updating rpc.byname... Updating rpc.bynumber... Updating services.byname... Updating services.byservicename... Updating netid.byname... Updating protocols.bynumber... Updating protocols.byname... Updating mail.aliases... gmake[1]: Leaving directory `/var/yp/NIS-SCHOOL-NETWORK' bigboy has been set up as a NIS master server. Now you can run ypinit -s bigboy on all slave server. [root@bigboy tmp]#
Note: Make sure portmap is running before trying this step or you'll get errors, such as:
failed to send 'clear' to local ypserv: RPC: Port mapper failureUpdating group.bygid...
You will have to delete the /var/yp/NIS-SCHOOL-NETWORK directory and restart portmap, yppasswd, and ypserv before you'll be able to do this again successfully.
Start The ypbind and ypxfrd Daemons
You can now start the ypbind and the ypxfrd daemons because the NIS domain files have been created.
[root@bigboy tmp]# service ypbind start Binding to the NIS domain: [ OK ] Listening for an NIS domain server. [root@bigboy tmp]# service ypxfrd start Starting YP map server: [ OK ] [root@bigboy tmp]# chkconfig ypbind on [root@bigboy tmp]# chkconfig ypxfrd on
Make Sure The Daemons Are Running
All the NIS daemons use RPC port mapping and, therefore, are listed using the rpcinfo command when they are running correctly.
[root@bigboy tmp]# rpcinfo -p localhost
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100021 1 udp 1024 nlockmgr
100021 3 udp 1024 nlockmgr
100021 4 udp 1024 nlockmgr
100004 2 udp 784 ypserv
100004 1 udp 784 ypserv
100004 2 tcp 787 ypserv
100004 1 tcp 787 ypserv
100009 1 udp 798 yppasswdd
600100069 1 udp 850 fypxfrd
600100069 1 tcp 852 fypxfrd
100007 2 udp 924 ypbind
100007 1 udp 924 ypbind
100007 2 tcp 927 ypbind
100007 1 tcp 927 ypbind
[root@bigboy tmp]#
Adding New NIS Users
New NIS users can be created by logging into the NIS server and creating the new user account. In this case, you'll create a user account called nisuser and give it a new password.
Once this is complete, you then have to update the NIS domain's authentication files by executing the make command in the /var/yp directory.
This procedure makes all NIS-enabled, nonprivileged accounts become automatically accessible via NIS, not just newly created ones. It also exports all the user's characteristics stored in the /etc/passwd and /etc/group files, such as the login shell, the user's group, and home directory.
[root@bigboy tmp]# useradd -g users nisuser [root@bigboy tmp]# passwd nisuser Changing password for user nisuser. New password: Retype new password: passwd: all authentication tokens updated successfully. [root@bigboy tmp]# cd /var/yp [root@bigboy yp]# make gmake[1]: Entering directory `/var/yp/NIS-SCHOOL-NETWORK' Updating passwd.byname... Updating passwd.byuid... Updating netid.byname... gmake[1]: Leaving directory `/var/yp/NIS-SCHOOL-NETWORK' [root@bigboy yp]#
You can check to see if the user's authentication information has been updated by using the ypmatch command, which should return the user's encrypted password string.
[root@bigboy yp]# ypmatch nisuser passwd nisuser:$1$d6E2i79Q$wp3Eo0Qw9nFD/::504:100::/home/nisuser:/bin/bash [root@bigboy yp]
You can also use the getent command, which has similar syntax. Unlike ypmatch, getent doesn't provide an encrypted password when run on an NIS server, it just provides the user's entry in the /etc/passwd file. On a NIS client, the results are identical with both showing the encrypted password.
[root@bigboy yp]# getent passwd nisuser nisuser:x:504:100::/home/nisuser:/bin/bash [root@bigboy yp]#
Configuring The NIS Client
Now that the NIS server is configured, it's time to configure the NIS clients. There are a number of related configuration files that you need to edit to get it to work. Take a look at the procedure.
Run authconfig
The authconfigor the authconfig-tuiprogram automatically configures your NIS files after prompting you for the IP address and domain of the NIS server.
[root@smallfry tmp]# authconfig-tui
Once finished, it should create an /etc/yp.conf file that defines, amongst other things, the IP address of the NIS server for a particular domain. It also edits the /etc/sysconfig/network file to define the NIS domain to which the NIS client belongs.
# /etc/yp.conf - ypbind configuration file domain NIS-SCHOOL-NETWORK server 192.168.1.100 #/etc/sysconfig/network NISDOMAIN=NIS-SCHOOL-NETWORK
In addition, the authconfig program updates the /etc/nsswitch.conf file that lists the order in which certain data sources should be searched for name lookups, such as those in DNS, LDAP, and NIS. Here you can see where NIS entries were added for the important login files.
#/etc/nsswitch.conf passwd: files nis shadow: files nis group: files nis
Note: You can also locate a sample NIS nsswitch.conf file in the /usr/share/doc/yp-tools* directory.
Start The NIS Client Related Daemons
Start the ypbind NIS client, and portmap daemons in the /etc/init.d directory and use the chkconfig command to ensure they start after the next reboot. Remember to use the rpcinfo command to ensure they are running correctly.
[root@smallfry tmp]# service portmap start Starting portmapper: [ OK ] [root@smallfry tmp]# service ypbind start Binding to the NIS domain: Listening for an NIS domain server. [root@smallfry tmp]# [root@smallfry tmp]# chkconfig ypbind on [root@smallfry tmp]# chkconfig portmap on
Note: Remember to use the rpcinfo -p localhost command to make sure they all started correctly.
Verify Name Resolution
As the configuration examples refer to the NIS client and server by their hostnames, you'll have to make sure the names resolve correctly to IP addresses. This can be configured either in DNS, when the hosts reside in the same domain, or more simply by editing the /etc/hosts file on both Linux boxes.
# # File: /etc/hosts (smallfry) # 192.168.1.100 bigboy # # File: /etc/hosts (bigboy) # 192.168.1.102 smallfry
Test NIS Access To The NIS Server
You can run the ypcat, ypmatch, and getent commands to make sure communication to the server is correct.
[root@smallfry tmp]# ypcat passwd nisuser:$1$Cs2GMe6r$1hohkyG7ALrDLjH1:505:100::/home/nisuser:/bin/bash quotauser:!!:503:100::/home/quotauser:/bin/bash ftpinstall:$1$8WjAVtes$SnRh9S1w07sYkFNJwpRKa.:502:100::/:/bin/bash www:$1$DDCi/OPI$hwiTQ.L0XqYJUk09Bw.pJ/:504:100::/home/www:/bin/bash smallfry:$1$qHni9dnR$iKDs7gfyt..BS9Lry3DAq.:501:100::/:/bin/bash [root@smallfry tmp]# [root@smallfry tmp]# ypmatch nisuser passwd nisuser:$1$d6E2i79Q$wp3Eo0Qw9nFD/:504:100::/home/nisuser:/bin/bash [root@smallfry tmp]# [root@smallfry tmp]# getent passwd nisuser nisuser:$1$d6E2i79Q$wp3Eo0Qw9nFD/:504:100::/home/nisuser:/bin/bash [root@smallfry tmp]#
Possible sources of error would include:
- Incorrect authconfig setup resulting in errors in the /etc/yp.conf, /etc/sysconfig/network and /etc/nsswitch.conf files
- Failure to run the ypinit command on the NIS server
- NIS not being started on the NIS server or client.
- Poor routing between the server and client, or the existence of a firewall that's blocking traffic
Try to eliminate these areas as sources of error and refer to the syslog /var/log/messages file on the client and server for entries that may provide additional clues.
Test Logins via The NIS Server
Once your basic NIS functionality testing is complete, try to test a remote login. Failures in this area could be due to firewalls blocking TELNET or SSH access and the TELNET and SSH server process not being started on the clients.
Logging In Via Telnet
Try logging into the NIS client via telnet if it is enabled
[root@bigboy tmp]# telnet 192.168.1.201 Trying 192.168.1.201... Connected to 192.168.1.201. Escape character is '^]'. Red Hat Linux release 9 (Shrike) Kernel 2.4.20-6 on an i686 login: nisuser Password: Last login: Sun Nov 16 22:03:51 from 192-168-1-100.simiya.com [nisuser@smallfry nisuser]$
Logging In Via SSH
Try logging into the NIS client via SSH.
[root@bigboy tmp]# ssh -l nisuser 192.168.1.102 [email protected]'s password: [nisuser@smallfry nisuser]$
In some versions of Linux, the NIS client's SSH daemon doesn't re-read the /etc/nsswitch.conf file you just modified until SSH is restarted. SSH logins, therefore, won't query the NIS server until this is done. Restart SSH on the NIS client.
[root@smallfry root]# service sshd restart Stopping sshd:[ OK ] Starting sshd:[ OK ] [root@smallfry root]#
NIS Slave Servers
NIS relies a lot on broadcast traffic to operate, which prevents you from having an NIS server on a different network from the clients. You can avoid this problem on your local subnet by using slave servers that are configured to automatically synchronize their NIS data with that of the single master server.
You can also consider placing multiple NIS servers on a single subnet for the sake of redundancy. To do this, configure the NIS clients to have multiple NIS servers for the domain in the /etc/yp.conf file.
Configuring NIS Slave Servers
In this scenario, you need to add an NIS slave server named nisslave (IP address 192.168.1.254) to the NIS-SCHOOL-NETWORK NIS domain. You also must configure the NIS master server, bigboy, to push its database map information to the slave whenever there is an update. Here are the steps you need.
1. As you're referring to our servers by their hostnames, you'll have to make sure the names resolve correctly to IP addresses. This can be done either in DNS, when the hosts reside in the same domain, or more simply by editing the /etc/hosts files on both servers as seen in Table 30.2.
Table 30-2 NIS Master / Slave /etc/hosts Files
| Master (Bigboy) | Slave (Nisslave) |
|---|---|
# # File: /etc/hosts (Bigboy) # 192.168.1.254 nisslave |
# # File: /etc/hosts (Nisslave) # 192.168.1.100 bigboy |
2. Configure the NIS slave as a NIS client of itself in the /etc/yp.conf file, and configure the NIS domain in the /etc/sysconfig/network file as seen in Table 30.3.
Table 30-3 NIS Master / Slave /etc/yp.conf Files
| /etc/yp.conf | /etc/sysconfig/network |
|---|---|
# # File: /etc/yp.conf (Bigboy) # ypserver 127.0.0.1 |
# # File: /etc/sysconfig/network # NISDOMAIN="NIS-SCHOOL-NETWORK" |
3. On the slave server, run ypbind so the slave can query the master server.
[root@nisslave tmp]# service portmap start Starting portmapper: [ OK ] [root@nisslave tmp]# service ypbind start Binding to the NIS domain: Listening for an NIS domain server. [root@nisslave tmp]# [root@nisslave tmp]# chkconfig portmap on [root@nisslave tmp]# chkconfig ypbind on
4. Optimize database map transfers by the NIS map transfer daemon, which should the started on both the master and slave.
[root@nisslave tmp]# service ypxfrd start Starting YP map server: [ OK ] [root@nisslave tmp]# [root@nisslave tmp]# chkconfig ypxfrd on [root@bigboy tmp]# service ypxfrd start Starting YP map server: [ OK ] [root@bigboy tmp]# [root@bigboy tmp]# chkconfig ypxfrd on
5. Do a simple database query of the master from the slave using the ypwhich command with the -m (master) switch. You should get a listing of all the tables.
[root@nisslave tmp]# ypwhich -m mail.aliases bigboy group.bygid bigboy passwd.byuid bigboy rpc.bynumber bigboy ... ... [root@nisslave tmp]#
6. Do an initial database download to the slave from the master with the ypinit command using the -s switch for a slave-type operation and specifying server bigboy as the master from which the data is to be obtained. You should see "Trying ypxfrd - success" messages. If the messages say "Trying ypxfrd - not running," then start ypxfrd on both servers.
[root@nisslave tmp]# /usr/lib/yp/ypinit -s bigboy We will need a few minutes to copy the data from bigboy. Transferring services.byservicename... Trying ypxfrd ... success Transferring group.byname... Trying ypxfrd ... success ... ... nisslave's NIS data base has been set up. If there were warnings, please figure out what went wrong, and fix it. At this point, make sure that /etc/passwd and /etc/group have been edited so that when the NIS is activated, the data bases you have just created will be used, instead of the /etc ASCII files. [root@nisslave tmp]#
If your database is corrupt or your /etc/hosts files are incorrect, you'll get map enumeration errors as shown. Use the make command again to rebuild your database on the master when necessary.
[root@nisslave tmp]# /usr/lib/yp/ypinit -s bigboy Can't enumerate maps from bigboy. Please check that it is running. [root@nisslave tmp]#
7. Now that the data has been successfully downloaded, it's time to make the slave server serve NIS clients with ypserv.
[root@nisslave tmp]# service ypserv start Starting YP server services: [root@nisslave tmp]# [root@nisslave tmp]# chkconfig ypxfrd on
8. Log on to the master server. Add the slave server to the master server's database map by editing the /var/yp/ypservers file on the master.
[root@bigboy yp]# cd /tmp [root@bigboy tmp]# cd /var/yp/ [root@bigboy yp]# vi ypservers
Add nisslave to the file.
# # File: /var/yp/ypservers # bigboy nisslave
9. The make file in the /var/yp directory defines how the NIS server will build the database map and how the master will relate to the NIS slave. Make a copy of the master's make file for safekeeping.
[root@bigboy yp]# cp Makefile Makefile.old
10. Edit the make file to allow the master to push maps to the slave.
# # File: /var/vp/Makefile # # # Allow the master to do database pushes to the slave # NOPUSH=false
11. Use the make command to rebuild the database. The make command automatically pushes database updates to the servers listed in the /var/yp/servers file.
[root@bigboy yp]# make gmake[1]: Entering directory `/var/yp/NIS-SCHOOL-NETWORK' Updating ypservers... YPPUSH: gethostbyname(): Success YPPUSH: using not FQDN name gmake[1]: Leaving directory `/var/yp/NIS-SCHOOL-NETWORK' gmake[1]: Entering directory `/var/yp/NIS-SCHOOL-NETWORK' Updating netid.byname... YPPUSH: gethostbyname(): Success YPPUSH: using not FQDN name gmake[1]: Leaving directory `/var/yp/NIS-SCHOOL-NETWORK' [root@bigboy yp]#
12. On the slave server, create a cron file in the /etc/crond.d directory, in this case named nis_sync, that will run periodic database downloads from the master server. This helps to ensure that the slave servers have current databases even if they miss updates from the master in the event the school goes offline for maintenance. Restart the cron daemon so that the configuration in this file becomes active.
[root@nisslave yp]# vi /etc/cron.d/nis_sync # # File: /etc/cron.d/nis_sync # 20 * * * * /usr/lib/yp/ypxfr_1perhour 40 6 * * * /usr/lib/yp/ypxfr_1perday 55 6,18 * * * /usr/lib/yp/ypxfr_2perday [root@nisslave yp]# service crond restart
That's a lot of work but it's still not over. There is one final configuration step that needs to be done on the NIS clients before you're finished.
Configuring NIS Clients With Slaves
Edit the /etc/yp.conf file on all the clients to include nisslave, and restart ypbind.
# # File: /etc/yp.conf (Smallfry) # domain NIS-SCHOOL-NETWORK server 192.168.1.100 domain NIS-SCHOOL-NETWORK server 192.168.1.254 [root@smallfry tmp]# service ypbind restart Shutting down NIS services: [ OK ] Binding to the NIS domain: [ OK ] Listening for an NIS domain server.. [root@smallfry tmp]#
Changing Your NIS Passwords
You should also test to make sure your users can change their NIS passwords from the NIS clients with the yppasswd command. The process is different whether there is only a single NIS master or a master-slave server relationship.
When There Is Only An NIS Master
When there is only a single NIS server, password changes can be made only on the NIS server using the yppasswd command.
Users Changing Their Own Passwords
Users can change their passwords by logging into the NIS server and issuing the yppasswd command.
[nisuser@bigboy nisuser]$ yppasswd Changing NIS account information for nisuser on bigboy.my-site.com. Please enter old password: Changing NIS password for nisuser on bigboy.my-site.com. Please enter new password: Please retype new password: The NIS password has been changed on bigboy.my-site.com. [nisuser@bigboy nisuser]$
User "Root" Changing Passwords
The root user can change other users' passwords issuing the yppasswd command with the -p switch that specifies the username that needs the change.
[root@bigboy tmp]# yppasswd -p nisuser Changing NIS account information for nisuser on bigboy.my-site.com. Please enter root password: Changing NIS password for nisuser on bigboy.my-site.com. Please enter new password: Please retype new password: The NIS password has been changed on bigboy.my-site.com. [root@bigboy tmp]#
When There Is A NIS Master / Slave Pair
With an NIS master and slave pair configuration, passwords can be changed on the NIS clients or the NIS slave, but not on the NIS master.
Possible Password Errors
There are a number of unexpected errors you may find when changing passwords - errors that have nothing to do with bad typing.
Segmentation Faults
Running the yppasswd command on the wrong client or server depending on your NIS master and slave configuration can cause segmentation fault errors. (Make sure you follow the chapter's guidelines for password changes!) Here are some sample password change failures on an NIS client with only one NIS master server.
[nisuser@smallfry nisuser]$ yppasswd Segmentation fault [nisuser@smallfry nisuser]$ [root@smallfry root]# yppasswd -p nisuser Segmentation fault [root@smallfry root]#
Daemon Errors
The yppasswdd daemon must be running on both the client and server for password changes to work correctly. When they aren't running, you'll get errors.
[root@smallfry etc]# yppasswd -p nisuser
yppasswd: yppasswdd not running on NIS master host ("bigboy").
[root@smallfry etc]#
You'll also get a similar error if you attempt to change an NIS password on an NIS master server in a master and slave configuration.
Considerations For A Non NFS Environment
In many cases NFS, isn't used to create a centralized home directory for users and, therefore, you'll have to create it on each NIS client and not on the server.
This example creates the home directory for the NIS client, smallfry. After doing this, you have to copy a BASH login profile file into it and modify the ownership of the directory and all the files to user nisuser.
Logins should proceed normally once this has been done and all the other steps have been followed.
[root@smallfry tmp]# mkdir /home/nisuser [root@smallfry tmp]# chmod 700 /home/nisuser/ [root@smallfry tmp]# ll /home total 2 drwx------ 2 nisuser users 1024 Aug 4 08:05 nisuser [root@smallfry tmp]# [root@smallfry tmp]# cp /etc/skel/.* /home/nisuser/ cp: omitting directory `/etc/skel/.' cp: omitting directory `/etc/skel/..' cp: omitting directory `/etc/skel/.kde' [root@smallfry tmp]# chown -R nisuser:users /home/nisuser [root@smallfry tmp]#
NIS Troubleshooting
Troubleshooting is always required as any part of your daily routine, NIS is no exception. Here are some simple steps to follow to get it working again.
1. The rpcinfo provides a list of TCP ports that your NIS client or server is using. Make sure you can TELNET to these ports from the client to the server and vice versa. If this fails, make sure all the correct NIS daemons are running and that there are no firewalls blocking traffic on the network or on the servers themselves. These ports change from time to time, so memorizing them won't help much.
The example tests from the client to the server.
[root@bigboy tmp]# rpcinfo -p
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 32768 status
100024 1 tcp 32768 status
391002 2 tcp 32769 sgi_fam
100009 1 udp 1018 yppasswdd
100004 2 udp 611 ypserv
100004 1 udp 611 ypserv
100004 2 tcp 614 ypserv
100004 1 tcp 614 ypserv
100007 2 udp 855 ypbind
100007 1 udp 855 ypbind
100007 2 tcp 858 ypbind
100007 1 tcp 858 ypbind
600100069 1 udp 874 fypxfrd
600100069 1 tcp 876 fypxfrd
[root@bigboy tmp]#
[root@smallfry tmp]# telnet 192.168.1.100 858
Trying 10.41.32.71...
Connected to 10.41.32.71.
Escape character is '^]'.
^]
telnet> quit
Connection closed.
[root@smallfry tmp]#
2. Always use the ypmatch, getent, and ypwhich commands to check your NIS connectivity. If there is any failure, check your steps over again and you should be able to find the source of your problem.
3. Do not fail to create a user's home directory, set its permissions, and copy the /etc/skel files correctly. If you forget, which is a common error, your users may have incorrect login prompts and no ability to create files in their home directories.
It can never be overemphasized that one of the best places to start troubleshooting is by looking in your error log files in the /var/log directory. You'll save a lot of time and effort if you always refer to them whenever the problem doesn't appear to be obvious.
NFS
Network File System (NFS) is a distributed file system protocol originally developed by Sun Microsystems in 1984,[1] allowing a user on a client computer to access files over a network in a manner similar to how local storage is accessed. NFS, like many other protocols, builds on the Open Network Computing Remote Procedure Call (ONC RPC) system. The Network File System is an open standard defined in RFCs, allowing anyone to implement the protocol.
NFS is often used with Unix operating systems (such as Solaris, AIX and HP-UX) and Unix-like operating systems (such as Linux and FreeBSD). It is also available to operating systems such as the classic Mac OS, OpenVMS, Microsoft Windows, Novell NetWare, and IBM AS/400. Alternative remote file access protocols include the Server Message Block (SMB, also known as CIFS), Apple Filing Protocol (AFP), NetWare Core Protocol (NCP), and OS/400 File Server file system (QFileSvr.400). SMB and NetWare Core Protocol (NCP) occur more commonly than NFS on systems running Microsoft Windows; AFP occurs more commonly than NFS in Macintosh systems; and QFileSvr.400 occurs more commonly in AS/400 systems.
Implementation
Assuming a Unix-style scenario in which one machine (the client) requires access to data stored on another machine (the NFS server):
- The server implements NFS daemon processes (running by default as nfsd) in order to make its data generically available to clients.
- The server administrator determines what to make available, exporting the names and parameters of directories (typically using the /etc/exports configuration file and the exportfs command).
- The server security-administration ensures that it can recognize and approve validated clients.
- The server network configuration ensures that appropriate clients can negotiate with it through any firewall system.
- The client machine requests access to exported data, typically by issuing a mount command. (The client asks the server (rpcbind) which port the NFS server is using, the client connects to the NFS server (nfsd), nfsd passes the request to mountd)
- If all goes well, users on the client machine can then view and interact with mounted filesystems on the server within the parameters permitted.
Note that automation of the NFS mounting process may take place — perhaps using /etc/fstab and/or automounting facilities.
Currently, there are three versions of NFS. NFS version 2 (NFSv2) is older and is widely supported. NFS version 3 (NFSv3) has more features, including 64bit file handles, Safe Async writes and more robust error handling. NFS version 4 (NFSv4) works through firewalls and on the Internet, no longer requires portmapper, supports ACLs, and utilizes stateful operations. Red Hat Enterprise Linux supports NFSv2, NFSv3, and NFSv4 clients, and when mounting a file system via NFS, Red Hat Enterprise Linux uses NFSv3 by default, if the server supports it.
All versions of NFS can use Transmission Control Protocol (TCP) running over an IP network, with NFSv4 requiring it. NFSv2 and NFSv3 can use the User Datagram Protocol (UDP) running over an IP network to provide a stateless network connection between the client and server.
When using NFSv2 or NFSv3 with UDP, the stateless UDP connection under normal conditions has less Protocol overhead than TCP which can translate into better performance on very clean, non-congested networks. The NFS server sends the client a file handle after the client is authorized to access the shared volume. This file handle is an opaque object stored on the server's side and is passed along with RPC requests from the client. The NFS server can be restarted without affecting the clients and the cookie remains intact. However, because UDP is stateless, if the server goes down unexpectedly, UDP clients continue to saturate the network with requests for the server. For this reason, TCP is the preferred protocol when connecting to an NFS server.
NFSv4 has no interaction with portmapper, rpc.mountd, rpc.lockd, and rpc.statd, since protocol support has been incorporated into the v4 protocol. NFSv4 listens on the well known TCP port (2049) which eliminates the need for the portmapper interaction. The mounting and locking protocols have been incorpated into the V4 protocol which eliminates the need for interaction with rpc.mountd and rpc.lockd.
Note
TCP is the default transport protocol for NFS under Red Hat Enterprise Linux. UDP can be used for compatibility purposes as needed, but is not recommended for wide usage.
All the RPC/NFS daemon have a '-p' command line option that can set the port, making firewall configuration easier.
After the client is granted access by TCP wrappers, the NFS server refers to its configuration file, /etc/exports, to determine whether the client is allowed to access any of the exported file systems. Once access is granted, all file and directory operations are available to the user.
Important
In order for NFS to work with a default installation of Red Hat Enterprise Linux with a firewall enabled, IPTables with the default TCP port 2049 must be configured. Without proper IPTables configuration, NFS does not function properly.
The NFS initialization script and rpc.nfsd process now allow binding to any specified port during system start up. However, this can be error prone if the port is unavailable or conflicts with another daemon.
Required Services
Red Hat Enterprise Linux uses a combination of kernel-level support and daemon processes to provide NFS file sharing. All NFS versions rely on Remote Procedure Calls (RPC) between clients and servers. RPC services under Linux are controlled by the portmap service. To share or mount NFS file systems, the following services work together, depending on which version of NFS is implemented:
-
nfs — (/sbin/service nfs start) starts the NFS server and the appropriate RPC processes to service requests for shared NFS file systems.
-
nfslock — (/sbin/service nfslock start) is a mandatory service that starts the appropriate RPC processes to allow NFS clients to lock files on the server.
-
portmap — accepts port reservations from local RPC services. These ports are then made available (or advertised) so the corresponding remote RPC services access them. portmap responds to requests for RPC services and sets up connections to the requested RPC service. This is not used with NFSv4.
The following RPC processes facilitate NFS services:
-
rpc.mountd — This process receives mount requests from NFS clients and verifies the requested file system is currently exported. This process is started automatically by the nfs service and does not require user configuration. This is not used with NFSv4.
-
rpc.nfsd — Allows explicit NFS versions and protocols the server advertises to be defined. It works with the Linux kernel to meet the dynamic demands of NFS clients, such as providing server threads each time an NFS client connects. This process corresponds to the nfs service.
-
rpc.lockd — allows NFS clients to lock files on the server. If rpc.lockd is not started, file locking will fail. rpc.lockd implements the Network Lock Manager (NLM) protocol. This process corresponds to the nfslock service. This is not used with NFSv4.
-
rpc.statd — This process implements the Network Status Monitor (NSM) RPC protocol which notifies NFS clients when an NFS server is restarted without being gracefully brought down. This process is started automatically by the nfslock service and does not require user configuration. This is not used with NFSv4.
-
rpc.rquotad — This process provides user quota information for remote users. This process is started automatically by the nfs service and does not require user configuration.
-
rpc.idmapd — This process provides NFSv4 client and server upcalls which map between on-the-wire NFSv4 names (which are strings in the form of user@domain) and local UIDs and GIDs. For idmapd to function with NFSv4, the /etc/idmapd.conf must be configured. This service is required for use with NFSv4.
NFS Client Configuration
NFS shares are mounted on the client side using the mount command. The format of the command is as follows:
mount -t-o :
Replace
Refer to the mount man page for more details.
If accessing an NFS share by manually issuing the mount command, the file system must be remounted manually after the system is rebooted. Red Hat Enterprise Linux offers two methods for mounting remote file systems automatically at boot time: the /etc/fstab file or the autofs service.
Mounting NFS File Systems using /etc/fstab
An alternate way to mount an NFS share from another machine is to add a line to the /etc/fstab file. The line must state the hostname of the NFS server, the directory on the server being exported, and the directory on the local machine where the NFS share is to be mounted. You must be root to modify the /etc/fstab file.
The general syntax for the line in /etc/fstab is as follows:
server:/usr/local/pub /pub nfs rsize=8192,wsize=8192,timeo=14,intr
The mount point /pub must exist on the client machine before this command can be executed. After adding this line to /etc/fstab on the client system, type the command mount /pub at a shell prompt, and the mount point /pub is mounted from the server.
The /etc/fstab file is referenced by the netfs service at boot time, so lines referencing NFS shares have the same effect as manually typing the mount command during the boot process.
A sample /etc/fstab line to mount an NFS export looks like the following example:
: 0 0
Replace
Replace with the path to the exported directory.
Replace with the local file system on which the exported directory is mounted. This mount point must exist before /etc/fstab is read or the mount fails.
Replace
autofs
One drawback to using /etc/fstab is that, regardless of how infrequently a user accesses the NFS mounted file system, the system must dedicate resources to keep the mounted file system in place. This is not a problem with one or two mounts, but when the system is maintaining mounts to many systems at one time, overall system performance can be affected. An alternative to /etc/fstab is to use the kernel-based automount utility. An automounter consists of two components. One is a kernel module that implements a file system, while the other is a user-space daemon that performs all of the other functions. The automount utility can mount and unmount NFS file systems automatically (on demand mounting) therefore saving system resources. The automount utility can be used to mount other file systems including AFS, SMBFS, CIFS and local file systems.
autofs uses /etc/auto.master (master map) as its default primary configuration file. This can be changed to use another supported network source and name using the autofs configuration (in /etc/sysconfig/autofs) in conjunction with the Name Service Switch mechanism. An instance of the version 4 daemon was run for each mount point configured in the master map and so it could be run manually from the command line for any given mount point. This is not possible with version 5 because it uses a single daemon to manage all configured mount points, so all automounts must be configured in the master map. This is in line with the usual requirements of other industry standard automounters. Mount point, hostname, exported directory, and options can all be specified in a set of files (or other supported network sources) rather than configuring them manually for each host. Please ensure that you have the autofs package installed if you wish to use this service.
autofs Configuration
The primary configuration file for the automounter is /etc/auto.master, also referred to as the master map which may be changed as described in the introduction section above. The master map lists autofs-controlled mount points on the system, and their corresponding configuration files or network sources known as automount maps. The format of the master map is as follows:
where:
-
mount-point is the autofs mount point e.g /home.
-
map-name is the name of a map source which contains a list of mount points, and the file system location from which those mount points should be mounted. The syntax for a map entry is described below.
-
options if supplied, will apply to all entries in the given map provided they don't themselves have options specified. This behavior is different from autofs version 4 where the options where cumulative. This has been changed to meet our primary goal of mixed environment compatibility.
The following is a sample /etc/auto.master file:
$ cat /etc/auto.master
/home /etc/auto.misc
The general format of maps is similar to the master map, however the "options" appear between the mount point and the location instead of at the end of the entry as in the master map:
[]
where:
-
is the autofs mount point. This can be a single directory name for an indirect mount or the full path of the mount point for direct mounts. Each direct and indirect map entry key ( above) may be followed by a space separated list of offset directories (sub directory names each beginning with a "/") making them what is known as a mutli-mount entry. -
if supplied, are the mount options for the map entries that do not specify their own options. -
is the file system location such as a local file system path (preceded with the Sun map format escape character ":" for map names beginning with "/"), an NFS file system or other valid file system location.
The following is a sample map file:
$ cat /etc/auto.misc
payroll -fstype=nfs personnel:/dev/hda3
sales -fstype=ext3 :/dev/hda4
The first column in a map file indicates the autofs mount point (sales and payroll from the server called personnel). The second column indicates the options for the autofs mount while the third column indicates the source of the mount. Following the above configuration, the autofs mount points will be /home/payroll and /home/sales. The -fstype= option is often omitted and is generally not needed for correct operation.
The automounter will create the directories if they do not exist. If the directories exist before the automounter was started, the automounter will not remove them when it exits. You can start or restart the automount daemon by issuing the following command:
$/sbin/service autofs start or $/sbin/service autofs restart
Using the above configuration, if a process requires access to an autofs unmounted directory such as /home/payroll/2006/July.sxc, the automount daemon automatically mounts the directory. If a timeout is specified, the directory will automatically be unmounted if the directory is not accessed for the timeout period.
You can view the status of the automount daemon by issuing the following command in your terminal:
$/sbin/service/autofs status