Best practices for NIS use
Yesterday we introduced NIS, the Network Information Service. In the second and final article in this series, let’s look at how to use it effectively.This article is excerpted from the newly published book Linux Administration Handbook, Second Edition.
One nice feature of NIS is that it can be understood by mere mortals. NIS is analogous to copying files around; in most cases, it’s unnecessary for administrators to be aware of NIS’s internal data formats. Administration is done with the same old flat files, and only one or two new procedures need to be learned.
Since NIS domains cannot be linked, NIS is not suitable for managing a large network of machines unless a single configuration is to be applied to every machine. You can divide a large network into several NIS domains, but each domain must be administered separately. Even if a large network does use a single configuration, limitations on the scaling of slave servers mean that in practice these sites usually come up with some other mechanism to keep their NIS servers in sync. They often end up rolling their own back-end databases and making their NIS servers fetch their data from this central source.
If a slave server is down or inaccessible when a map is changed, the slave’s copy will not be updated. Slaves must periodically poll the master to be sure that they have the most recent version of every map. Although basic tools for polling are provided with NIS, you must implement the polling scheme you want by using cron. Even so, two different versions of a map could possibly be served simultaneously for a while, with clients randomly seeing one or the other.
NIS is minimally secure. Broadcast mode is particularly bad; any host on a network can claim to serve a particular domain and feed bogus administrative data to NIS clients. You can avoid this problem by explicitly enumerating the permissible NIS servers for each client.
You can restrict the hosts that are able to read a server’s maps by explicitly listing them in /etc/ypserv.conf; however, this technique is not 100% secure. You can also improve the security of your system by distributing your shadow password file with some other technique (such as rdist or rsync); we don’t recommend using NIS to serve shadow passwords.
Older versions of Linux NIS contain known security holes. If you are running an older system, make sure you get the latest upgrades before starting NIS.
Prioritizing sources of administrative information
Configuration information can be distributed in several ways. Every system understands flat files and knows how to use DNS to look up hostnames and Internet addresses. Most also understand NIS. Since a given piece of information could come from several potential sources, Linux provides a way for you to specify the sources that are to be checked and the order in which the checks are made.
In the original (pre-Linux) implementation of NIS, some configuration files (the /etc/passwd and /etc/group files in particular) had to be configured to “invite in” the contents of the corresponding NIS maps. The invitation was extended by inclusion of special incantations in the files themselves. A lone “+” at the beginning of a line would include the entire NIS map, “+@netgroup” would include only entries relevant to a given netgroup, and “+name” would include a single entry.
This approach was never very well liked, and it has been superseded by a central config file, /etc/nsswitch.conf, that allows an explicit search path to be specified for each type of administrative information. The original behavior can be emulated by use of a compatibility mode, but it’s unlikely you would want to use this feature on a newly configured network. (Unfortunately, emulation is most distributions’ default.)
A typical nsswitch.conf file looks something like this:
passwd: files nis hosts: files dns group: files .
Each line configures one type of information (usually, one flat-file equivalent). The common sources are nis, nisplus, files, dns, and compat; they refer to NIS, NIS+, vanilla flat files (ignoring tokens such as “+”), DNS, and NISified flat files (honoring “+”), respectively. DNS is a valid data source only for host and network information.
Support for each source type comes from a shared library (/lib/libnss*), so distributions vary slightly in the sources they support. Some distributions provide out-of-the-box support for LDAP (see page 520) and/or Hesiod, a directory service based on DNS. Another source commonly supported on Linux (and unfortunately not very well documented) is db, which reads a hashed version of the map from /var/db (for example, /var/db/passwd.db). If your flat files are large, the use of hashed versions can substantially increase lookup speed.
Sources are tried from left to right until one of them produces an answer for the query. In the example above, the gethostbyname routine would first check the /etc/hosts file, and if the host was not listed there, would then check DNS. Queries about Unix groups, on the other hand, would check only the /etc/group file.
If necessary, you can define the “failure” of a source more specifically by putting bracketed expressions after it. For example, the line
hosts: dns [NOTFOUND=return] nis
causes DNS to be used exclusively if it is available; a negative response from the name server makes queries return immediately (with a failure code) without checking NIS. However, NIS is used if no name server is available. The various types of failures are shown in the table below; each can be set to return or continue, signifying whether the query should be aborted or forwarded to the next source.
Failure modes recognized in /etc/nsswitch.conf
The source doesn’t exist or is down.
What Are Linux NIS and NIS+
NIS and NIS+ share as many differences as they share similarities. These programs, commonly known as Network Information Service and Network Information Service Plus, deliver a simple network lookup and check of processes and databases.
NIS is formally known as Sun Yellow Pages and provides information that the entire network should know. Notably, NIS and NIS+ provide the following information:
- Login passwords, names, or home directories (e.g. /etc/password)
- Group information (e.g. /etc/group)
- IP numbers and hostnames (e.g. /etc/hosts)
This article will explain how NIS and NIS plus work. The article will also highlight the key differences and similarities between the two frameworks. Finally, you will learn when to go with NIS and when to consider using NIS+.
What is NIS?
Network information system, NIS, is a naming and administration mechanism used by administrators of smaller networks. NIS stands out as a distributed database that allows users to maintain the right and consistent configuration of files within a network.
Developed by Sun Microsystems, NIS also allows users to access system files from anywhere. It is part of the robust Network File System or NFS and features an array of daemons and commands for various other services, including NIS and NFS. Notable NIS components include servers, clients, NIS maps, and a NIS domain.
The NIS Syntax is as shown below:
What is NIS+?
Also developed by Sun Microsystems, NIS+ is a directory service used by system administrators to store shared credentials in the form of NIS+ tables. It is a replacement of NIS which is older and more basic.
This network information service provides a central place where network administrators can store client credentials where everyone can access. The service is ideal for storing machine addresses, mail information, security information, network details, Ethernet information, and other shared client credentials. It comes with a set of commands to help administer the name space.
NIS vs. NIS+ Comparison
NIS and NIS+ share more than their name—they share a common objective. However, they also have an array of differences. Notably, Network Information Service Plus (NIS+) is an enhanced version of the original Network Information Service. It implies that it has new features and different terminology for similar concepts.
The below table summarizes the difference between NIS and NIS+.
Comparison Table Between NIS and NIS+
| NIS | NIS+ |
|---|---|
| It features the flat domains and has no hierarchy. | It features the hierarchical domains and stores the data in different namespace levels. |
| It allows the use of similar machine names and user names. | The machine and user cannot share a name. Besides, you cannot have a dot (.) in either of the names. |
| All names and commands are pretty case-sensitive. | The commands and names are not case-sensitive. |
| Does not use any authentication. | Uses DES authentication. |
| Uses two-column tables to store data. | Uses multi-column tables to store data. |
| The client has only one choice of network information source. | The client has a range of network information sources to choose from including DNS, NIS, NIS+, or any local /etc. file. |
| Features a maximum size of 1024 bites, a limitation applying to all the NIS map files. | There are no size limitations. |
| Does not support the encrypted and secure RPC. | Supports the secure and encrypted RPC. |
| It uses RPC Version 2. | It uses RPC version 3. |
| Will often delay the updates for batch propagation. | It propagates incremental updates instantly. |
NIS and NIS+ Domain Structure
Notably, unlike most versions of original protocols, NIS+ does not improve NIS. Instead, it works as its replacement. NIS aims to address the network administration requirements of relatively small client-server requirements. Thus, it is more suitable for environments with a few hundred clients, trusted users, and a few multipurpose servers.
But you will need NIS+ for large, modern and complex client-server network administrations. It comes with more autonomy. It will conveniently handle networks with up to 10,000 multivendor clients and up to 100 specialized servers located worldwide. The domain hierarchy is similar to that of DNS. However, it is more developed and able to store information about users, workstations, and network services.
NIS+ features interoperability characteristics that allow you to upgrade from NIS. It also allows continued interaction with DNS as initially provided by NIS. The nispopulate command allows NIS compatibility if you intend to move from NIS to NIS Plus.
An example file of NIS is:
An example of a NIS+ file is:
How NIS Works
You must have a single machine within your network acting as a NIS server for NIS to work. However, you can still have multiple NIS servers, with each server serving a different NIS domain.
You can also utilize cooperating servers where one machine will act as a master server while the rest will be NIS slave servers. In such an arrangement, slave servers will only have NIS database copies and will receive and implement changes from the master server.
The main reason for having one or more slave servers in your systems is to maintain the uptime of your network throughout. Thus, client machines can check through any fast or reliable slave servers whenever a master server is down or too slow.
How NIS+ Works
NIS+ works by supporting authentication and data encryption—and it does this over a secure and reliable RPC. Thus, this is a better security tool than NIS.
The naming model here leverages a tree structure, with each node in the tree directly corresponding to a NIS+ object. The design has up to six trees, including table, link, directory, group, entry, and private.
The root directory forms the basis of the NIS+ namespace. The two special directories include the groups_dir and the org_dir. The groups_dir is responsible for access control since it has NIS+ group objects. On the other hand, the org_dir contains administration tables such as hosts, passwd, and mail_aliases.
Conclusion
Now, choosing between NIS and NIS+ is not a hard choice. Consider NIS+ if you have serious security needs within your networks. Although it is slightly easy to administer, it will remarkably secure your systems. On the other hand, NIS is generally an administration protocol. It is pretty easy to minister but lacks security measures.
About the author
Kennedy Brian
Brian is a computer scientist with a bias for software development, programming, and technical content development. He has been in the profession since 2015. He reads novels, jogs, or plays table tennis whenever not on gadgets. He is an expert in Python, SQL, Java, and data and network security.