 |  |
| |
As a programmer, you frequently need to deal with directory information, whether you realize it or not. Your application uses Directory Services each time it looks up a host entry, authenticates a password, or uses a printer. The Open Directory architecture unifies what used to be a random collection of flat files in /etc. The good news is that the flat files still work. The other good news is that there is a brave new world just beyond those flat files. So, while all your old Unix code should work with the Open Directory architecture, you should look for new ways to accomplish old tasks, especially if you can continue writing portable code.
To get at directory information, Unix applications typically go through the C library using such functions as gethostent( ). Higher-level APIs, such as Pluggable Authentication Modules (PAM) and Common Data Security Architecture (CDSA), also use the C library. Figure 3-2 shows how this works. The C library connects to lookupd, a thin shim that is the doorway to the DirectoryService daemon. The DirectoryService daemon consults the available plug-ins until it finds the one that can answer the directory query.
One possible route to user and password information is through the getpw* family of functions. However, those functions are not ideal for working with systems like Mac OS X that support multiple directories (flat files, NetInfo, LDAP, etc.). In particular, getpwnam( ) is not guaranteed to return a crypted password if the system has been configured to use another scheme, such as MD5 passwords. You should use the PAM API instead. PAM is included with, or available for, many flavors of Unix, so you can use it to write portable code. For more information on PAM, see the pam(8) manpage.
|  | |
| 3. Directory Services |  | 3.3. Configuring Directory Services |
Copyright © 2003 O'Reilly & Associates. All rights reserved.