Directories and Directory Server

---

Everyone working in information technology (IT) knows what a directory is, and even people who only occasionally use a computer encounter a directory sooner or later. To be more precise, they do not encounter a directory, but what they see is a directory listing similar to that shown in Exhibit 1. Note that the exact layout of a directory listing depends on the computer's operating system and the type of view configured for the directory listing.

Exhibit 1: A Typical Directory Listing

Exhibit 1 shows a listing of a directory. This kind of directory may be helpful as a first approach, but in the context of our particular needs, this view is somewhat specialized and we would like to have a broader view. For our purpose, it is more instructive to use the definition of "directory" as we find it in a general dictionary, i.e., one that is not specialized on information technologies. For example, the Oxford Dictionary defines a directory as a "book containing a list of telephone subscribers, inhabitants of a district, members of a profession." This gives exactly the concept of directory that we will use throughout this book.

For our purposes, a directory is an ordered list of objects. For example, the "white pages" of a telephone book is an ordered list of persons arranged in alphabetic order by surname and given name or initials. Using the white pages, one can find the phone number, street, and district of anyone listed in the book. In contrast, the "yellow pages" provides an ordered list of professions where one can look up, for example, a nearby barbershop. A further example from an IT environment might he a list of printers ordered by printer name. Using this directory, one could find the printer's location, the printer model, or the server to which the printer is attached. You could also search for a postscript-enabled printer near your office or base a search on some other criterion. Even whole network information systems can be stored in a directory.

As an ordered list of objects, a directory is an information storehouse that can be searched swiftly and easily. There are many potential applications for directories. Consider a domain name system (DNS) that correlates the human-friendly name of a computer (e.g., Google.com) with that computer's Internet Protocol (IP) number. NIS+ allows us to get information about users and groups. NIS+ is an improvement over NIS, the Network Information Service invented by Sun Microsystems. It allows the central administration of hostnames, users, and user home directories. If you want to find out more about NIS/NIS+, go on to Sun's Website. Gerald Carter dedicates a chapter of his book, LDAP System Administration, ^[1] to replacing NIS/NIS+ with LDAP. Both of these applications can be implemented as a directory, allowing the user to query the directory for information. The last two examples point out a further strength of LDAP. LDAP offers centralized information services across a whole network. Because LDAP is running over TCP/IP, all computers using the TCP/IP protocol can access the services offered by LDAP.

Exhibit 2 illustrates the hierachical structure of a directory where information is stored in a treelike structure that uses the DNS name space. As you can see, a hierarchical structure can accelerate searches by limiting the scope of the search to a branch of the tree. A further example of how to organize a hierarchy of different levels is shown by the number of names stored in the white pages. You can put the address where the person lives at the base level. The next higher level would be the district where that person lives. If you know the district, this knowledge will accelerate the performance of the query. The district furthermore is located in a city, the city in the country, and the country in a continent. The underlying hierarchy accelerates the search process, since you don't search for John Smith in the whole world, but you will first limit the search to Europe, then to the United Kingdom, then to London, and at the end to Bayswater. This hierarchical structure speeds the search process while keeping the results set low. You will find many more people named "John Smith" in the United Kingdom than in the district Bayswater. A smaller results set reduces network traffic and requires less work to elaborate the results.

Exhibit 2: Hierarchical Structure of DNS

The hierarchical structure depicted in Exhibit 2 also suggests the possibility of storing other attributes about the computer beyond its name and the IP number. For example, we might also want to record the disk space available, the memory available, the installed software, and similar relevant information. The directory stores all of this information in an object called an "entry." Thus the directory is an object-oriented repository. Note, however, that the LDAP standard does not specify how the information is stored in the repository. We will return to this subject later in this chapter. Note also that directories are stored on hard disks on computers. The precise method of storage is discussed at the end of this chapter. For now, we will simply assume that information is held "somewhere."

Imagine several people trying to look up the information stored on a system. If the information is to be accessed swiftly and easily, then there is a clear need for an efficient agent that serves as an intermediary between the user and the information. This mediator should shield the user from the complexity of the information-retrieval process and simply provide the requested information. Note that a "user" could be a person or a client application acting upon a user request.

Again, the example of the white pages is useful. If you do not have a copy of the local telephone directory (or are too busy to look up the number yourself), or if you need the phone number of a person or enterprise in another country or continent, you can dial an operator who will search for the number for you. This operator has access to specialized search tools that can isolate the requested phone number. Similarly, a specialized server can access a computer directory and isolate the information requested by the user. A server that looks up directory information for a client is called a "directory server." This approach has the advantage of masking the information-retrieval process. The user simply makes a request and gets a fast answer without worrying about the mechanics of the information system (how the information is maintained, stored, or organized to provide fast access).

In a client-server environment, the user needs a directory client that can access a directory server. This approach allows each side to do its specialized job. The client can concentrate on requesting information from the server and then presenting the information obtained, while the server can focus on system issues such as the efficiency of information retrieval. The directory server uses a protocol to communicate with the client; therefore, both the server and the client have to implement a common protocol. This book explores the use of LDAP as an efficient protocol.

At this point, let us observe another important point. The objective of a directory server is swift information retrieval. The speed of updating the information in the directory is not an issue. For example, consider the white pages that you use at home. The time it takes to compile the information and print the book is not a relevant issue to the user. Finding a person's phone number takes only a few seconds. For this type of application, the only important consideration is the time you spend to get the desired information, not the time it takes to update the white pages. We will come back to this point later in this chapter when we discuss the differences between databases and directories.

In this section, we learned two key definitions that will help in understanding LDAP:

• A directory server is a highly specialized server designed to facilitate fast information retrieval from directories.

• A directory is an indexed list of things or persons that is maintained in a hierarchical, object-oriented repository.

^[1]Carter, G., LDAP System Administration, O'Reilly, Sebastopol, CA, 2003.

---