LUX 263 - Linux System Administration III
Lesson 5: Chapter 21, Chapter 21, NIS and LDAP
This lesson discusses scheduled NIS and LDAP in Linux. Objectives
important to this lesson:
- An NIS client
- Using yppasswd
- Setting up the NIS server
- Setting up the LDAP server
- Tools for LDAP
NIS stands for a lot
of things, depending on what your context is. In the context of this text,
stands for Network Information Service, a directory service which was
previously called Yellow Pages, which explains why its tools all start
with the letters "yp", such as ypcat and ypmatch,
which are used to display and search NIS data files (maps).
The link in the last sentence explains the name change to NIS, which was
due to copyright infringement.
NIS holds network information, such as usernames and passwords, system
names, and IP addresses. NIS has a limitation that discourages its use
in some environments: it does not encrypt data that flows across
a network. As the Wikipedia article mentions, a remedy was offered by
Sun in its Solaris 2 (1992) as NIS+, but it was harder to implement and
unpopular, so it was removed from Sun's offerings in Solaris 11.
Facts about NIS:
- NIS is organized in domains, each one having one master
server, and as many slave servers as may be needed by larger networks.
- An NIS domain is a set of NIS maps, which are database files.
The collection of all maps is called the NIS database.
- Like Active Directory or DNS, the slave servers hold a copy
of the database, which they receive from the master server.
- Each system (computer) can belong to only one NIS domain.
- A system can use NIS, DNS, and/or local files as sources of information.
This is configured in the /etc/nsswitch.conf
file. This file allows you to specify that password information held
in NIS is to be overridden by the information in /etc/passwd.
The text recommends this approach, because it allows each system
to have a unique root password. Personally, I can see a good and a bad
side to this advice. Think about that for a discussion
- Page 771 lists eight different files that can be used as source files
for NIS. Each holds a different kind of information, as indicated by
- /etc/group - group and member information
- /etc/gshadow - shadow passwords for groups
- /etc/hosts - host names and IP addresses
- /etc/passwd - user information and passwords
- /etc/printcap - printer information
- /etc/rpc - Remote
Procedure Call information
- /etc/services - service names and port numbers
- /etc/shadow - This is a problem, in terms of the reason for shadow
password files. NIS makes them available to everyone
on the system. See this note about NIS
and shadow file service.
- Information from each of the source files is converted to a database
map file, which is an indexed database file for NIS. Some
source files are stored in two maps, each of them indexed differently.
The text explains that the maps act like functions, which
make RPC calls to the database.
- Although the ypcat command can be used to view the contents
of a map file, it may look rather odd. The example on page 772 shows
two lines from passwd.byname, which shows that fields in the file's
records are separated by colons, and that the passwords for the
users are stored in encrypted form.
- You can run a system without NIS, using only DNS or LDAP for similar
article from Infoworld discusses that point of view.
page 773, there is a set of instructions for installing the NIS client,
which leaves out instructions that will vary, depending on the kind of
Linux you are running on your workstations and servers. Since we are supposed
to be running Fedora 24, this is what I did, which you will modify based
on your system:
- Searched for ypbind with the command:
dnf search ypbind.
- Found ypbind.x86_64
- Entered the command:
sudo dnf install ypbind.x86_64
- Read the silly warning and entered the password for my user ID. (I
made the user fedora an administrator when I installed the virtual machine.)
- Waited for the system to install ypbind and yptools,
as the text promised that it would. Congratulated myself for not accepting
the default memory configuration when I installed the VM, since it took
more room than that to install this utility.
- Trying to run ypbind failed at this point because I had not set an
NIS domain name. The text does not provide any instructions to
- First, run su root, and switch to your root id. Only root is
allowed to change/set the domain name.
- Next, try a command like this:
This is an example. In our classroom, append your initials
to the letters "nis" so the domains will not be the
same from one machine to another.
- Enter the command echo $?. A value of 0 will tell you
that the command ended successfully. Any other number would be an error
- Still acting as root, enter the command ypbind. This should
work, but we are not done.
- Turn to page 774. The text informs us, a bit late, that you need to
set the NIS domain name in another file. Still logged on as root,
you can use echo and redirection to do this:
echo "NISDOMAINNAME=nis.domain" >> /etc/sysconfig/network
Make sure to use the actual domain name you chose in place of the italic
phrase in the example above. This will append a line to the network
file that specifies the name of your domain.
Note the mild warning on page 774 that you could also set the domain
name with the command nisdomainname, followed by an argument,
but this method is only valid for the current session. It would be forgotten
when the system is rebooted. Entering the command nisdomainname without
an argument will confirm what the system currently thinks the domain
- It is also necessary to set an NIS domain
name for the device you are setting up. The link in the previous
sentence leads to a discussion about this topic that tells us to edit
the /etc/hosts file on this computer, editing the line about
localhost to read localhost.nis.domain. Save the file.
- Next, enter the command:
domainname -F /etchosts
which will add the new information in hosts to your environment by telling
domainname to read that file now.
- The last practical section in the text about setting up the client
is to edit /etc/yp.conf. This is the file where you specify the
name of the NIS server, as shown on page 775.
On page 779, the text begins a section on setting up the NIS server that
the last section needed to know about. In the future, I think I will recommend
that we read the whole chapter first, then decide which parts should have
been in what order. Like many of the author's discussions, this one seems
to go back and forth for several pages. A web reference that covers a
lot of the same material is on
this site. You may find it easier to take in.
I have found a great many old sources of information about NIS on the
web, most of which are quite old. The bottom line seems to be that most
people would not choose to use NIS. So we will go on with the material
The text begins its section on LDAP on page 786. The author tells
us in the introduction that Lightweight Directory Access Protocol
was designed to run on TCP/IP networks, and that is was meant to be used
to access information that does not change often. The database
in an LDAP system is called a directory. The text explains some
basic terms in the LDAP system, most of which are commonly used in database
- entry - a single unit of information in an LDAP directory
(it has parts, of course); a record in this database
- attributes - fields in an entry; each must have a name
and one or more values (which makes this different from most databases)
- schema - a standard for organization of information
in any LDAP database; the text cautions us not to modify the
schema, because doing so would make our data inaccessible to other LDAP
- UUID - Universally Unique Identifier; a unique Identifier for
each entry in the directory, theoretically unique on the Internet
- distinguished name (DN) and relative distinguished name
(RDN) - each entry also has a distinguished name, which is unique
for every entry; a distinguished name is constructed by elements from
the entry's attributes and from its parent's distinguished name; this
reference from ldap.com makes the subject clearer than the text
On page 787, the text mentions some improvements that have been made
to make an LDAP system more dynamic. We should move on to the more practical
portion of the discussion, starting on page 789. An Internet source for
information about this topic is available
- The text specifies two packages to install (openldap-clients
and openldap-servers). The howtoforge document specifies three
others, and that you can install them all with one command. (yum, this
time. Are you getting tired of a different installation tool every half
hour? I know I am.)
- I recommend that you follow the steps in the text to install and configure
ldap, or in the link above from howtoforge, or in a procedure you would
prefer to try. Document your experience with your chosen method, and
turn in a report on it for this week's LDAP lab.