On Wed, 12 Sep 2001, Reena John wrote:
> 14. Changes to the LDAP lookup:
>
> * Abandoned auto-guess of LDAP library (was in fact broken).
> * Added support for OpenLDAP 2.0.6 (changed API from 1.x release).
> * Use ldap_search and asynchronous ldap_result instead of ldap_url_search.
> * Changes to the way multiple values are returned.
> * Miscellaneous internal tidies.
>
> Above, in the item before the last, it says 'Changes to the way multiple
> values are returned' .
>
> Could someone in the know please respond with more detail about what those
> changes are?
I suppose I ought to know. However, I am not an expert in ldap, and the
changes were in fact taken from a patch submitted by somebody who does
really use ldap. IIRC, the changes made the format of multiple values
the same as is used by NIS+. This has now made it into the latest
versions of the manual, where it says:
----------------------------------------------------------------
In the common case where you specify a single attribute in your LDAP query,
the result is not quoted, and if there are multiple values, they are separated
by commas. If you specify multiple attributes, they are returned as space-
separated strings, quoted if necessary, preceded by the attribute name. For
example,
ldap:///o=base?attr1,attr2?sub?(uid=fred)
might yield
attr1="value one" attr2=value2
If you do not specify any attributes in the search, the same format is used
for all attributes in the entry. For example,
ldap:///o=base??sub?(uid=fred)
might yield
objectClass=top attr1="value one" attr2=value2
The "extract" operator in string expansions can be used to pick out individual
fields from such data.
----------------------------------------------------------------
This piece of information was marked as "new" (by change bars) in the
3.20 edition.
The 3.10 edition says:
It is possible for multiple values, separated by newlines, to be
returned for both ldap and ldapm, but in the former case you know that
whatever values are returned all came from a single entry in the
directory.
This was the original implementation (again taken from code that was
submitted to me.)
> This is an addendum to the mail below. You'll notice that #14 in the
> ChangeLog of exim-3.168 also has a point stating:
>
> * Use ldap_search and asynchronous ldap_result instead of ldap_url_search.
>
> Could you explain what that means? ldap_url_search does not appear to be an
> option (like ldap_default_servers).
This is all to do with the way LDAP is driven from Exim. Again, the
change was a recommendation from a serious LDAP user. Previously, Exim
used a function called ldap_url_search(), which did not return until all
the results were available. It now fires off a query, and then calls
ldap_result(), which waits for the answers - and may get them one at a
time if there's more than one coming. I don't think this change will
have any effect that is visible outside, other than performance.
Philip
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
