hi,
i want to thank Philip for his prompt reply. However, I find that our the
return value from our ldap lookup does not conform to the exim
documentation. Which is why I thought the change (see excerpt from
changelog in mail below) in exim-3.168 might explain it.
i would appreciate it if exim-ldap users (and hopefully the creator of the
code) would come forward with samples of what is returned in their ldap lookup.
A typical ldap lookup on our system when $local_part=John would look like:
lookup ldapm {LDAP_URL(CN_MATCH)}{$value}
LDAP_URL = ldap:///o=base?alias,mail,cn,ou,telephonenumber?sub?
CN_MATCH = &(mail=*)${perl{cn_match}{$local_part}}
alias=JohnS ou="Engineering" ou="Engineering" mail=*** mail=***
telephonenumber="***" cn="John Smith" cn="John P Smith" cn="JSmith" cn=""
alias=JohnR ou="Engineering" mail=*** telephonenumber="***" cn="Reena John"
cn="Reena Philipos John" cn="Reena P John"
You can see that the multiple values for cn and ou are not separated by
commas. Also, (and not visible) the return values from multiple attributes
(e.g. between mail=* and telephonenumber=*) are space separated but not
individual strings. However, as specified in the documentation, the values
returned from different entries (records) are separated by newlines.
thanks for the forum and your attention,
Reena
At 09:18 AM 9/13/2001 +0100, Philip Hazel wrote:
>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.
