LUX 263 - Linux System Administration III

Lesson 5: Chapter 21, Chapter 21, NIS and LDAP

Objectives:

This lesson discusses scheduled NIS and LDAP in Linux. Objectives important to this lesson:

  1. NIS
  2. An NIS client
  3. Using yppasswd
  4. Setting up the NIS server
  5. LDAP
  6. Setting up the LDAP server
  7. Tools for LDAP
Concepts:
Chapter 21

NIS stands for a lot of things, depending on what your context is. In the context of this text, NIS 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 outside class.
  • 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 its filename.
    • /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 purposes. This article from Infoworld discusses that point of view.

On 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:

  1. Searched for ypbind with the command:
    dnf search ypbind.
  2. Found ypbind.x86_64
  3. Entered the command:
    sudo dnf install ypbind.x86_64
  4. 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.)
  5. 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.
  6. 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 do this.
  7. First, run su root, and switch to your root id. Only root is allowed to change/set the domain name.
  8. Next, try a command like this:
    /bin/domainname nis.domain
    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.
  9. Enter the command echo $?. A value of 0 will tell you that the command ended successfully. Any other number would be an error condition.
  10. Still acting as root, enter the command ypbind. This should work, but we are not done.
  11. 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 name is.
  12. 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.
  13. 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.
  14. 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 on LDAP.

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 classes.

  • 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 servers
  • 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 does

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 here.

  1. 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.)
  2. 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.

 

Week 5 Assignments:

Assignment 1, Exercises from chapter 21: 1 through 6

Assignment 2, LDAP Lab from chapter 21, as described above. 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.