Printers listed beneath the ou=global entry should be available to all clients on the network. The entries here contain only a printer's name; the actual configuration data can be accessed by querying for the attributes of cn= printername ,ou=config, ou=printers,dc=plainjoe,dc=org. The ou=location tree has a similar function to the global tree. The location organizational unit is a holder for another group of organizational units, one of which is shown in Figure 8-8. Each organizational unit at this level represents a group of printers. Each client on the network can list one or more group names; the clients are then allowed to access the printers in the groups that they have listed.
The major difficulty in dealing with printers is deciding on an acceptable schema for representing printer capabilities and data. Currently, there is no standardized printer schema. The closest we have to a standard is the Internet-Draft draft-fleming-ldap-printer-schema-XX.txt. We only need to implement a subset of the schema in this document (see Figure 8-9).[5] The printer.schema file also includes a modified version of the schema presented in Network Printing, by Todd Radermacher and Matt Gast (O'Reilly). These additional object classes and attributes support the information needed to generate printcap entries for use with the Berkeley print spooler (LPD) or Patrick Powell's LPRng (http://www.lprng.com/).
* * *
Warning
The printer.schema file should be viewed as an example only. While it can be used in a production directory, my hope is that a final standardized schema will soon be available and supported by printing vendors.
* * *
Figure 8-9. The abstract printerAbstract class, structural printerService class, and auxiliary classes printerLPR, nprintPortPrinterInfo, and nprintNetworkPrinterInfo included in the printer.schema file
Begin populating the printers organizational unit with a simple network printer named hp2100. The printer-uri attribute was developed by the IETF's Printer Working Group to represent different printing systems such as ipp://, lpr://, etc. All of the printers in your directory will use a printer URI of the form lpr://
Immediately, however, we have a problem: the dNSZone and the printerService objects are both structural classes. Luckily, the default Bind 9 LDAP lookups do not use the objectclass value in searches. Therefore, you can use the extensibleObject class in the place of dNSZone. The other solution would be to define a new auxiliary object class that contained all of the attributes contained in a dNSZone object. I choose to use an extensibleObject to prevent the introduction of new schema items into our discussion.
Now that the object class conflict has been resolved, we can return to our discussion of printer attributes. The printer's domain name is stored in the relativeDomainName and zoneName attributes. The printer-name and nprintHardwareQueueName represent the remote machine (rm) and remote printer (rp) printcap variables.
dn: printer-uri=lpr://hp2100,ou=config,ou=printers,dc=plainjoe,dc=org
aRecord: 192.168.1.220
printer-name: hp2100
nprintHardwareQueueName: raw
printer-uri: lpr://hp2100
relativeDomainName: hp2100
objectClass: printerService
objectClass: nprintNetworkPrinterInfo
objectClass: extensibleObject
printer-job-k-octets-supported: 10000
zoneName: lp.plainjoe.org
You get extra points if you noticed that the nprintDNSName attribute is missing. This attribute doesn't appear because the fully qualified hostname can be determined from the relativeDomainName and zoneName attributes. Because the nprintDNSName serves the same purpose, it can be left out. The script for generating a printcap entry attempts to retrieve the nprintDNSName attribute first; in its absence, the script generates the remote printer's name by concatenating the relativeDomainName and zoneName attribute values.
Your system must be able to represent nonnetworked printers in the same namespace as networked printers. Nonnetworked printers don't have the attributes associated with a dNSZone (replaced by an extensibleObject) that are required to support DNS lookups. Of course, since such an entry describes a nonnetworked device, this detail is of no concern. Here's the LDIF representation of a nonnetworked printer:
dn: printer-uri=lpr://bjc240,ou=config,ou=printers,dc=plainjoe,dc=org
printer-name: bjc240
printer-uri: lpr://bjc240
objectClass: printerService
objectClass: printerLPR
objectClass: nprintPortPrinterInfo
nprintDeviceName: /dev/lp0
printer-aliases: canon
Directory entries that exist below the ou=global and ou=location roots contain only a printer's name. The next two directory entries state that the printer hp2100 is available for all network hosts (because it is in the global organizational unit), and the printer bitsink is available only to clients within the floor-1 group (because it is in the floor-1 group, which is within the location subtree):
dn: printer-name=hp2100,ou=global,ou=printers,dc=plainjoe,dc=org
printer-name: hp2100
objectClass: printerService
dn: printer-name=bitsink,ou=floor-1,ou=location,ou=printers,dc=plainjoe,dc=org
printer-name: bitsink
objectClass: printerService
The nprintHostPrinter AUXILIARY object class (see Figure 8-10) allows you to extend an existing entry for a network host to define membership in a printing group, and lets you list any host-specific printers that should be available to users. The entry for workstation queso.plainjoe.org associates it with the floor-1 printing group (i.e., ou=floor-1,ou=location,ou=printers,dc=plainjoe,dc=org) and includes a reference to the specific printer named draft-printer:
Figure 8-10. nprintHostPrinter object class
dn: relativeDomainName=queso,ou=hosts,dc=plainjoe,dc=org
aRecord: 192.168.1.74
nprintLocation: floor-1
objectClass: dNSZone
objectClass: nprintHostPrinter
relativeDomainName: queso
dNSTTL: 86400
nprintPrinterName: draft-printer
zoneName: plainjoe.org
Finally, you must be able to retrieve information from the directory and format it in a way that is usable by the local printing system. The generate_printcap.pl Perl script supports the printer.schema used in this section and generates printcap files from the directory that are compatible with the BSD printing system. This script supports the common LDAP searching options, such as the directory server's name and base suffix. The script also accepts the hostname of the client to receive the printcap file. Table 8-5 presents the complete set of parameters supported by generate_printcap.pl.
Table 8-5. Options to generate_printcap.pl
Parameter
Default
Description
--base
none
The base suffix used when searching the directory
--debug
off
Enables extra debugging output
--help
Summarizes command usage and parameters
--host
$HOSTNAME
The host for which you want to generate the printcap file
--printcap
printcap.$HOSTNAME
The name of the generated printcap file
--server
localhost
The hostname of the LDAP server to query
Figure 8-11. Printing information and entries for the host queso.plainjoe.org
The following command generates a printcap file for queso.plainjoe.org, given the directory entries represented by Figure 8-11:
$ generate_printcap.pl --host=queso
--base="dc=plainjoe,dc=org"
--server=ldap.plainjoe.org
Searching ou=global,ou=printers,dc=plainjoe,dc=org . . .
Using entry for "relativeDomainName=queso,ou=hosts,dc=plainjoe,dc=org"
Searching ou=floor-1,
ou=location,ou=printers,dc=plainjoe,dc=org . . .
Finished generating printcap (printcap.queso)
generate_printcap.pl uses an anonymous bind when connecting to the LDAP server. This means that the OpenLDAP server must be configured with the following access control rule, which allows read-only access to information about printers:
access to dn.children="ou=printers,dc=plainjoe,dc=org"
by * read
The resulting printcap file is:
#
# Printcap file generated automatically on Sun Jan 20 19:33:37 2002 for host queso
#
######################################################################
# printer-uri=lpr://hp2100,ou=config, ou=printers, dc=plainjoe,dc=org
# objectclass: nprintNetworkPrinterInfo
hp2100:
:sh:
:mx#10000:
:lf=/var/spool/lpd/hp2100/lpd-err:
:sd=/var/spool/lpd/hp2100:
:lp=/dev/null:
:rm=hp2100.lp.plainjoe.org:
:rp=raw:
######################################################################
######################################################################
# printer-uri=lpr://bitsink,ou=config, ou=printers, dc=plainjoe,dc=org
# objectclass: nprintNetworkPrinterInfo
bitsink:
:sh:
:mx#0:
:lf=/var/spool/lpd/bitsink/lpd-err:
:sd=/var/spool/lpd/bitsink:
:lp=/dev/null:
:rm=bitsink.lp.plainjoe.org:
:rp=bitsink:
######################################################################
######################################################################
# printer-uri=lpr://draft-printer,ou=config,ou=printers,dc=plainjoe,dc=org
# objectclass: nprintPortPrinterInfo
draft-printer:
:sh:
:mx#0:
:lf=/var/spool/lpd/draft-printer/lpd-err:
:sd=/var/spool/lpd/draft-printer:
:lp=/dev/lp0:
:sd=/var/spool/lpd/draft-printer:
:if=/opt/printers/filters/hpif.sh:
######################################################################
The details of writing Perl scripts such as generate_printcap.pl to manage information in an LDAP directory using the Net::LDAP module will be presented in Chapter 10.
Whenever you're trying to integrate network services into LDAP, remember to focus on reduction of data. Storing information in a directory has no benefit by itself; it is only worthwhile if it decreases the cost of managing the data (i.e., makes life easier for you and the people you work with). If data is used only by a single application on a single host, the information could be kept in a local database file just as easily. However, if the information is needed by several services on multiple hosts, as with user accounts or printer settings, storing the information in an LDAP directory reduces the cost of updating data by ensuring that each change needs to be made only once.
* * *
[5] The printer.schema file is available online at the web site for this book (http://www.oreilly.com/catalog/ldapsa).
Chapter 9. LDAP Interoperability
What is a chapter on interoperability doing in a book on LDAP? After all, I've presented LDAP throughout this book as a standard protocol, and standards are supposed to minimize, if not eliminate, interoperability problems. One of the major selling points of LDAP is its potential for consolidating vendor-specific or application-specific directories. We've seen many examples of this: using LDAP as a replacement for NIS, as a backend data store for DNS, and as a replacement for many ad hoc databases used in email management.
Still, while LDAP minimizes interoperability problems, "minimize" is definitely the key word. The core features of LDAP are standardized, but things such as schemas are not. There are many common object classes and attributes that can be extended by a vendor. Not only can schemas be extended, the protocol can be extended as well by creating additional operations using extensions and controls, and not all vendors support the same ones.
For each service that can be consolidated into an LDAP directory, there must be a corresponding client-side application that can access the old information in the new directory. That's not always an easy order to fill; we've already seen some clever workarounds to help older applications access an LDAP directory, such as using the pam_ldap library presented in Chapter 6 to enable non-LDAP-aware applications to authenticate users in the directory. Furthermore, sooner or later you will encounter an LDAP-enabled application that requires the directory service to implement a specific schema or extended operation.
The goal of this chapter is to discuss several technologies that you can use to solve problems of this sort. Every directory integration project is unique. I will show how to solve a number of common directory integration problems—and although the problems I discuss are typical enough, they're only a small fraction of the problems you're likely to face. The most effective way to prepare yourself to solve the problems posed by your environment is to examine the tools, concepts, and architectures that can be combined into a solution to meet the needs of your users.
Interoperability or Integration?
The terms interoperability and integration each have a different place within our coverage of LDAP. For our purposes, directory integration means enabling client applications to access data in an LDAP directory, a topic that has been covered extensively in previous chapters. Interoperability should address communication between LDAP servers themselves. The distinction between integration and interoperability begins to blur when one LDAP server becomes the client of another LDAP server.
Whenever you start thinking about interoperability or integration, your first step should be to ask what level of interoperability or integration your application requires. There are a number of solutions that provide interoperability or integration in various forms. Knowing what your application requires will make it much easier to decide which solution is appropriate. Table 9-1 lists some common approaches to interoperability and integration issues.
Table 9-1. Common directory interoperability solutions
Problem
Possible solution
Example
"What can I do if my application doesn't speak LDAP?"
Gateways that translate one directory access protocol into another
The NIS/LDAP gateway presented in Chapter 6
"How can users in a non-Unix administrative domain access services on Unix hosts?"
Cross-platform authentication services
Authenticating non-Microsoft clients against an active directory
"How can I join information contained in different directories?"
Distributed, multivendor directories glued together by referrals and references
Connecting directories from different vendors into a single DIT
"How can I unify access to the databases and directories held by multiple departments in my organization?"
Metadirectories that provide an integrated view of several disjointed directories and databases
Using an LDAP proxy server to translate entries from a second directory into the format needed by client applications
"How can I implement replication or synchronization between directories from different vendors?"
Push/pull agents that synchronize information from one directory to another
Customizing scripts or in-house tools that suck data from one server and uploading it to another directory after translating it into a format understood by the second server
This chapter examines ways to implement each approach. No single approach is a solution in and of itself; they're tools that you can use to assemble a solution that works in your environment. My intent, therefore, is to spur your imagination and introduce you to the different types of glue that are available for coordinating
directory services.
Directory Gateways
Gateways are not a new concept; we've seen gateways between different email formats, different network filesystems, and so on for years. When building a gateway for directory services, one directory protocol is used as the frontend (the "face" presented to application clients). Another protocol is used between the gateway and the backend storage mechanism. The irony of using a directory gateway to unify access to an LDAP server is that LDAP itself was originally designed as a gateway protocol for X.500.
PADL's ypldapd daemon, presented in Chapter 6, is an example of a gateway between NIS and LDAP. Packages such as ypldapd tend to do one thing and do it well. In many respects, such a gateway can simply be viewed as another LDAP client. The gateway consumes LDAP information and makes that information available to its clients through another protocol.
Another example of an NIS/LDAP gateway is the NIS service distributed with Microsoft's " Windows Services for Unix (SFU)." This Active Directory add-on provides tools for importing data from a NIS domain into Active Directory. Once NIS data has been incorporated into Active Directory, SFU can provide services for NIS clients from the Active Directory domain. For more information on the SFU product, see http://www.microsoft.com/windows/sfu/.
The main advantage of using a gateway is that you usually don't have to modify any clients. This alone can save a great deal in the cost of administration. The disadvantage of using a gateway is that translating requests and replies from one protocol to the other requires additional overhead. Furthermore, clients can't take full advantage of the LDAP directory service; they're limited to the services offered by the gateway. In many environments, these disadvantages are relatively minor.
Cross-Platform Authentication Services
Cross-platform authentication is a term heard most often in IT departments that want to authenticate logons to Unix services using Microsoft's Active Directory,[1] or authenticate logons to Windows clients using a Unix-based LDAP server. In this scenario, we're not interested in interoperability between directory services, but between a specific directory service and nonnative clients (for example, Active Directory and Unix clients).
LDAP System Administration Page 24