UNIX System Administration Handbook - Evi Nemeth [315]
From a client’s perspective, NIS+ looks much the same as any other administrative database system. Most data is accessed through the same library routines as always, and the complex world of domains, tables, permissions, and search paths is in the end rendered down to an analog of the original UNIX flat files.
NIS+ has nothing to do with DNS, but it borrows DNS’s naming scheme. DNS and NIS+ use names that are the inverse of filesystem paths; as you read from left to right, you go up (toward the root) in the hierarchy.
For example, cs.colorado.edu is a subdomain of colorado.edu. A machine in that domain might be named anchor.cs.colorado.edu.
By convention, the root of your NIS+ hierarchy is named the same as your site’s top-level DNS domain. If your DNS domain is xor.com, then xor.com would also be your NIS+ root domain, and marketing.xor.com might be the NIS+ subdomain for your marketing department. Since DNS and NIS+ do not interact, you risk nothing but your sanity by using the same names for both.
Technically, NIS+ doesn’t understand or enforce the idea of domains; it simply provides a generic way of creating NIS+ directories in a hierarchy, inserting various tables in those directories, and binding portions of the hierarchy to different master servers. But by convention, an NIS+ “domain” is a directory that contains subdirectories called org_dir and groups_dir. The domain’s administrative data is put in tables inside org_dir, and the credentials for the domain’s NIS+ principals are defined in groups_dir. Theoretically, a groups_dir or org_dir directory could have other subdirectories, but this isn’t normally done.
For example, org_dir.marketing.xor.com would be the name of the directory containing system tables for the marketing.xor.com domain. Syntactically, tables are referred to as if they were directories: the string hosts.org_dir.marketing.xor.com refers to the NIS+ equivalent of the /etc/hosts file for this domain. To refer to a specific entry within a table, a different syntax (not described here) is used.
Our judgement regarding NIS+ is that it should generally be avoided if possible. It works, but so do some much simpler alternatives. While it’s not worth going to great lengths to avoid, neither is there a very compelling case to be made for adopting it.
18.5 LDAP: THE LIGHTWEIGHT DIRECTORY ACCESS PROTOCOL
UNIX sites need a good way to distribute their administrative configuration data; however, the problem is really more general than that. What about nonadministrative data such as telephone and email directories? What about information that you want to share with the outside world? What everyone really needs is a generalized directory service.
A directory service is just a database, but one that makes a few assumptions. Any data set that has characteristics matching the assumptions is a candidate for inclusion. The basic assumptions are as follows:
• Data objects are relatively small.
• The database will be widely replicated and cached.
• The information is attribute based.
• Data are read often but written infrequently.
• Searching is a common operation.
The current IETF standards-track system designed to fill this role is the Lightweight Directory Access Protocol (LDAP). The LDAP specifications don’t really speak to the database itself, just the way that it’s accessed via a network. But because they specify how the data is schematized and how searches are performed, they imply a fairly specific data model as well.
The history of LDAP could not possibly be more sordid. The story begins with the OSI networking system,