Direct LDAP Lookup
Prior to version 5.1 of the messaging software, the MTA did not have the ability to directly look up information in the Directory Server via LDAP. Rather, the MTA had a small cache of information, such as user IDs and mail addresses, that was periodically synchronized against the Directory Server. This was originally done when Directory Server performance was not as good as it is today. Now that the Directory Server is able to keep up with the requests from the Message Server, the MTA's cache is redundant and becomes a bottleneck, as well as adding administrative overhead. You may also hear the term dirsync used to describe the process or the daemon that is run to synchronize the data between the Directory Server and MTA's cache. One reason the use of the MTA cache was abandoned is that in some situations the information in the cache would become stale, causing some interesting problems—for example, users added to the system would not appear in the MTA cache until the next dirsync was run. Password changes would not necessarily be immediately reflected either. By using direct LDAP access, these problems are avoided.
So, it is highly recommended that the MTA be configured to utilize direct LDAP lookups.
Why is it so desirable to move to direct LDAP lookups?
Dirsync was used in iPlanet Message Server and in SIMS before that for a number of reasons that were good at the time. Dirsync provides a decoupling of the messaging server from the directory infrastructure, which, in the days of SIMS 3.5, was immature (by which we mean slow and not entirely reliable). It also reflected the ancestry of the product, which had been entirely independent of LDAP.
Dirsync represented a technical compromise. Given that LDAP was slow and unreliable, the approach taken was to predigest the directory information into databases for use by the MTA. In theory, this should give better performance and independence from the directory. In practice, however, these databases have been the bane of our lives. Wherever you have persistent structured data, there is always the concern that it can become inconsistent. And when you have a long update process like dirsync, you have a very unpleasant window where a failure can lead very quickly into a situation where manual intervention is required for a restart.
Dirsync also imposes a very abnormal load on the directory. Both the incremental dirsync and full dirsync queries are difficult for the directory server, very unlike the sort of query for which the directory was designed, which is “here is a attribute/value pair, find me the matching entry.”
Since the days of SIMS, the directory technology has improved significantly. Now, the directory is very robust and much faster. The behavior of the directory is much better than the behavior of the databases used by the MTA. So the balance of the compromise is now very different. The speed of looking up a user in the directory is still too slow for the MTA to use the directory in a simplistic way, but with the inclusion of a pre-process cache for reading the directory information, we have found that the throughput in general goes up. To be fair, we can construct loads where the throughput goes way up or way down, but with a realistic load there is a net gain in throughput.
But the real win is in robustness. By going to the direct LDAP mode, you eliminate a whole set of complicated persistent data structures, replacing them with transparent ephemeral data structures. This not only eliminates a set of failure modes, but (and this is probably more important) means that the probability of needing manual intervention after any sort of incident is significantly reduced.
When Sun first introduced the direct LDAP mode, they did so more tentatively than was wise. Initial thoughts were to err on the side of caution by making dirsync the default mode for version 5.2 of the Messaging Server. In retrospect that was an error. The direct LDAP mode, after Sun had cleaned up a couple of weird corner cases, has proven far more robust and easy to deploy than they had ever hoped.
In the next release, Sun intends to make direct LDAP mode the only mode of operation now that it is known to work well. We are that satisfied with its behavior. It makes the directory deployment easier and the MTA much more stable, and makes it much easier to recover from any sort of hardware or software failure.
Already there is functionality in the area of mailing groups that is only supported in direct LDAP mode. Given that dirsync is now code with a very limited life expectancy, you can expect the developers to concentrate their efforts in the direct LDAP mode. Thus, dirsync is now more or less in maintenance mode only.
Beginning with version 5.1 of the Messaging Server, the ability to directly look up information from the Directory Server is available, though it was not well documented until version 5.2. The default, however, is that the MTA still caches information unless explicitly configured to perform this direct LDAP lookup. In future versions of the Messaging Server, the default will be direct LDAP lookup.
Four MTA configuration files must be modified to enable direct LDAP lookup:
mappings
job_controller.cnf
option.dat
imta.cnf
All of these files are in the config directory for the MTA:
/msgHome/msg-Instance/imta/config/
where msgHome is the directory where the Messaging Server software was installed, and Instance is the name of the messaging instance (install), often the hostname (short host name)
▾ Testing LDAP Lookup
A simple experiment can be done to demonstrate the value and verify that direct LDAP lookup works:
1. | With the messaging system running, add a user via the
imadmin
command. See Chapter 6, “Software Installation and Configuration,” on page 69. |
2. | Send a message to this user from another user's account. You should get a “user not found” message, or something to that effect. |
3. | Sync the MTA
with the directory:
|