 | Level: Intermediate Martin Brown (mc@mcslp.com), Freelance Writer, Consultant
18 Apr 2006 Examine how to use the Network Information Service (NIS) to share core databases between Linux® and UNIX®, and how to use the Network File System (NFS) to share file systems, both with direct links and through the automounter. Although UNIX and Linux are similar, there are some differences between the two that can complicate the process of integrating the two systems. Both, for example, share the same authentication system, but most systems are also standalone. Sharing this authentication information enables you to provide a single sign-on (SSO) functionality to any of the servers in your network.
Sharing data through NIS
The Network Information Service (NIS) was developed by Sun Microsystems, and was also known as the Yellow Pages service. The mechanics of the system are simple -- the standard system databases, such as /etc/hosts and /etc/passwd, are converted into a generic database format (using the DBM format, an acronym that has long since lost its meaning).
These databases are held on the NIS server (also known as the NIS master). All of the individual databases are placed into a named domain and then shared from the master using the Remote Procedure Call (RPC) interface. A number of different files are supported, including:
- passwd (and the /etc/shadow file if supported)
- groups
- hosts
- netmask
- netgroup
- automount
- services
- protocols
- ethers
- aliases (for mail)
Slave servers (for example, those machines that want to provide a backup copy of NIS master databases) copy the published databases from the server. NIS clients query an NIS server when they need to look up information, for example, when a user logs in. The NIS client never stores information, because the client is bound (through the ypbind tool) to an NIS server. The resulting structure looks like Figure 1 below.
Figure 1. The NIS master or slave structure
Changes to the NIS database are propagated to slave servers whenever a change is made, or manually, by using the yppush command.
Direct changes to the NIS database that are driven by the user, for example, when a user changes their password, are communicated directly to the NIS master server, which updates the database and propagates the changes to any slave servers.
Choosing NIS or NIS+
The main difference between NIS and NIS+ is that the latter supports authentication and encryption for data exchanges between the NIS master and slave computers. NIS+ is, however, significantly more difficult and complex to set up and keep running because of the security requirements. NIS+ also extended the naming system so that databases were placed into a tree structure rather than a single domain, allowing for much more complicated and wider-ranging distribution.
NIS is typically fine in any standard environment and, within a correctly configured network, poses no security threat if the same network is attached to the Internet. You should use NIS+ only in environments where the private network is more exposed, for example, within a university or multi-site installation where the NIS data is exchanged over public networks.
Setting up an NIS server
Solaris, AIX®, and HP-UX installations include support for the NIS system by default. Linux® distributions often come with NIS as standard, and the glibc library comes with support for NIS. However, you might need to install the toolkit required to configure and manage an NIS installation. For an NIS server under Linux, you need the following packages:
With these installed, you need to edit the supplied makefile, usually contained in /var/yp/Makefile. This contains the configuration parameters that will be used to build the initial YP database. You need to edit the definition for all to include the type of files that you want to support through NIS. By default, the rule includes all files, as shown in Listing 1.
Listing 1. Definition for all
all: passwd group hosts ipnodes ethers networks rpc services protocols \
netgroup bootparams aliases publickey netid netmasks c2secure \
timezone auto.master auto.home ageing \
auth.attr exec.attr prof.attr user.attr audit.user
|
You might remove any of these that you don't want; for example, you might simply want to share the passwd, group, and hosts files.
You are now ready to populate the database. First set the NIS domain name:
On a Linux server, edit the /var/yp/securenets and /etc/ypserv.conf files to match your local networks. These files control which machines can share and access information within your NIS domain.
Now initialize the database:
The ypinit command does the rest for you using the makefile to convert the source files (for example, /etc/passwd) into the NIS format.
If at any time you change the contents of the source files, change to the /var/yp directory and run make again to rebuild the databases:
If you want to allow individual users to update their login passwords remotely, ensure that the rpc.yppasswdd daemon is running; it accepts requests from clients to update the NIS database directly so that the changes are propagated through the master and slaves and picked up correctly by any clients.
Setting up an NIS client
To set up an NIS client, you need to define the NIS domain name, start the local NIS services, and then initialize these services to look up their information from an NIS master, or master slave. The key to the process is ypbind, which attaches the client machine to the NIS server.
Under UNIX, the NIS server is determined automatically when ypbind is called. Under most versions of Linux, you must set the list of valid NIS servers in the /etc/yp.conf file, for example:
The basic process for connecting the client to the NIS server is:
- Set the NIS domain:
$ domainname mcslp.nis.
- Start
portmap, the RPC mapper daemon if it is not already running: $/sbin/portmap.
- Create the /var/yp directory, this will be used to hold some of the NIS information.
- Start up
ypbind: $ /usr/sbin/ypbind.
Now test that the NIS connection is active by using ypcat to query the database directly. For example, to get a dump of the NIS passwd file ordered by name, you would use:
That dumps the entire passwd database. Before the systems actually use the NIS database information, you must reconfigure the data sources used by the system to look up information.
The nsswitch.conf
The nsswitch.conf file on both Linux and UNIX is typically used to determine where the system looks up information on different data. For example, you can configure the nsswitch.conf file to look up host information in files, query the DNS, or use the NIS system to look up the information.
The file configures not only the sources used to locate the information, but also the order in which the different sources are queried. Choosing the right order can affect whether the correct data source is queried and the resilience of your network in case of failure.
The format of the file is a simple list of the system databases, followed by a list of the data sources to use in the desired order, one service per line. For example, Listing 2 shows the initial lines of a simple nsswitch.conf file set up for NIS, DNS, and local file resolution.
Listing 2. The initial lines of a simple nsswitch.conf file
passwd: nis files
shadow: nis files
group: nis files
hosts: nis dns files
networks: nis dns files
|
In Listing 2, you can see the definition for passwd is to use the NIS database first (if it is available). When a user logs in, the NIS tables will be consulted first. If the service returns an error that the username could not be found, then the system consults the next item in the list -- in this case, the local files.
Some tips for correctly setting and using the nsswitch.conf file:
- Always specify files as the last option, particularly for passwd, shadow, and hosts data. Failure to do so might render your machine unusable, as it will reject even the root user if the NIS system fails.
- Ensure that the file data contains critical logins, hosts, and other information.
- For a machine connected to the Internet, it is generally more efficient to use DNS for Internet-based resolving than relying on the forwarding system in NIS.
Sticking to these tips should ensure that you do not lock yourself out of your own system.
Sharing files through NFS
The Network File System (NFS) was also developed by Sun Microsystems as a method for sharing files among machines. When you share a directory with NFS, you can then mount the directory from another machine just as if it was a local disk. The same security, file permissions, and other data is replicated between the NFS client and the NFS server. This is why you should share user data through NIS, because the user ID, group ID, and other information applies to NFS shared files.
In general, you should configure the directories to be shared first, before starting the NFS server. Within Linux, you can do this through the /etc/exports file, which defines the directory and options for the shared directory (such as security restrictions). For example, to share /export/data only to the machines within the your network, you might use a line like the following:
/export/data *.mcslp.pri(rw,sync) *(sync)
|
The rw option sets the sharing to read or write for all clients in your network and a default of read-only for all other hosts. The sync option ensures that the remote mounts synchronize their file system data with the server.
Within Solaris, you use the /etc/dfs/dfstab file to specify share commands to be run to export a given directory over NFS. For example, you could share the same directory, allowing read or write to all using the following line:
share -F nfs -o rw /export/data
|
On AIX, use the smit tool to share specific directories, or use the SAM tool on HP-UX.
In all cases, once the files and configuration have been created, you should start the NFS server process.
On clients, you need to start the NFS client process only. You can then mount an NFS file system using the mount command. You specify the server name, followed by a colon, and the full path to the remote directory, like this:
$ mount bear:/export/data /mnt/data
|
You can also use the same basic format to mount NFS directories automatically by using the /etc/fstab or /etc/vfstab files to mount the NFS directory at boot. Better still, use the automount system to simplify the mounting process while getting the best performance out of your server.
Using the automounter
As an extension to NFS, you should consider using the automount system. This component automatically mounts directories when they are referenced. For example, with an NFS share automatically configured for /mnt/data, the NFS share associated with /mnt/data would automatically be mounted and made available the moment you typed:
Once the directory had stopped being regularly used, the directory would be unmounted. The automounter becomes particularly useful when sharing user directories -- individuals can log in to any machine and have their home directory automatically mounted and available to them from a remote NFS server.
Using the automounter not only simplifies the way you mount remote directories from an NFS server, it also helps to reduce the load on the server from provided statistical and heartbeat communication to a client that is not actively using the NFS share.
UNIX variants include the automounting capability. Within Linux, you must configure automounting within the kernel and reboot the machine before configuring the automount configuration and starting the automounter.
To configure automounter, you must first edit the /etc/auto.master or /etc/autofs/auto.master file. This defines the top level share sets, mapping top-level directories to another mapping file. For example, the following file maps /home and /mnt to two other maps:
/home /etc/autofs/auto.home
/mnt /etc/autofs/auto.mnt
|
Within the /mnt directory and the corresponding map, you then configure subdirectories and the NFS directories to which they map. For example, Listing 3 is a fragment from the mnt map.
Listing 3. Fragment from the mnt map
applications atuin:/Volumes/Shared1/Applications
archiveprepare atuin:/Volumes/Shared1/ArchivePrepare
backupprepare atuin:/Volumes/Shared1/BackupPrepare
build atuin:/Volumes/Shared1/Build
correspondence atuin:/Volumes/Shared1/Correspondence
devprojects atuin:/Volumes/Shared1/DevProjects
docarchive atuin:/Volumes/Shared1/DocArchive
incoming atuin:/Volumes/Shared1/Incoming
information atuin:/Volumes/Shared1/Information
|
Because the fragment shown in Listing 3 is in the /mnt map, when a user visits /mnt/applications, the automounter runs the command to mount the mapped NFS share, in this case, atuin:/Volumes/Shared1/Applications.
On UNIX, you then need to start the automount daemon. This is called automount on most UNIX variants, or automountd, while within many Linux variants, it is called autofs and is started with:
Synchronizing time
When using both NIS or NIS+ and NFS, it can be a good idea to ensure that your time is correctly synchronized across servers. This is vital for NIS or NIS+, as the time is used during the distribution of information to ensure that the databases are up to date. If your machines become out of sync, then slaves might stop downloading information from the master, or updates to the master might be refused.
The easiest way to achieve time synchronization is with the Network Time Protocol (NTP), a standard or installable component on most Linux machines and an increasingly common component in UNIX variants.
Once you have downloaded and compiled, or separately installed the package, the key component is the ntpd daemon. The ntpd daemon runs in the background and can be configured both to supply time synchronization information and automatically update the time of the local machine according to a server.
If you are using NIS, set the NIS master to provide synchronization information for the rest of the network. Either configure the server to use its built-in clock or, if it is connected to the Internet, get the server to get its time sync information from one of the many public servers. For example, my ISP provides an NTP service. The /etc/ntp.conf configuration file holds the name of the NTP server at my ISP, like this:
server ntp0.zen.co.uk minpoll 12 maxpoll 17
|
Each NIS server and client in the network is then configured using the same /etc/ntp.conf file to communicate with the NIS master for their time information:
server atuin.mcslp.pri minpoll 12 maxpoll 17
|
With both systems configured, start the NTP daemon on the NIS master using:
Then repeat the process on each NIS slave server and client.
Summary
Communicating and sharing information makes the process of integrating your UNIX and Linux systems together much easier. Once you share login and other information, your users can connect and use your UNIX and Linux machines without worrying about separate passwords. If you combine this with NFS sharing, you can share the files and, if you use the automounter with users individual home directories, then they can continue to use their own files and resources, as well as those otherwise shared through the file system, regardless of the operating system or machine on which they are working.
Resources Learn
Discuss
About the author | | | Martin Brown has been a professional writer for more than seven years. He is the author of numerous books and articles across a range of topics. His expertise spans myriad development languages and platforms -- Perl, Python, Java™, JavaScript, Basic, Pascal, Modula-2, C, C++, Rebol, Gawk, Shellscript, Windows®, Solaris, Linux, BeOS, Mac OS X and more -- as well as Web programming, systems management, and integration. He is a Subject Matter Expert (SME) for Microsoft and regular contributor to ServerWatch.com, LinuxToday.com, and IBM developerWorks. He is also a regular blogger at Computerworld, The Apple Blog, and other sites. You can contact him through his Web site. |
Rate this page
| |
