Re: Will rewrite context in slapd.conf solve my problem?

["Pierangelo Masarati" <ando@sys-net.it>]

> I'm looking for real life examples of rewrite context rules in
> slapd.conf...
>
> We're trying to get QuickMail Pro (remember that client? Used to be CE
> Software's email client, it's now owned by Outspring...IMHO, it's a
> crappy client, but migrating to something else is next year's project)
> to talk with an OpenLDAP server for address book information. The
> problem is, QMP sends a DN of "QMPUPDATE" to OpenLDAP and of course
> there is no DN named "QMPUPDATE". So, I'm thinking with a few rewrite
> context statements, I can get the OpenLDAP to translate "QMPUPDATE" to
> the correct search base on the server.
>
> A quick background briefing on how QMP works out an address book.
> Basically an address book object of kind ozAddressBook exists on LDAP,
> QMP queries for that object type and retrieves an attribute of
> fetchFilter (a required attribute in ozAddressBook objects) from LDAP.
> The fetchFilter then is used as a search string to query LDAP for users
> attached to that address book. Sounds simple enough, but when the
> client queries LDAP, it sends a bogus DN of "QMPUPDATE" to the server
> and slapd throws an error that stops the rest of the query dead in it's
> tracks. I'm not even certain that the DN is an attempt at a search
> base, but it looks like it...
>
> With a log level of -1, slapd gives me the following when I try to
> update an address book:
>
> Nov  8 15:51:37 pylon slapd[545]: daemon: read activity on 12
> Nov  8 15:51:37 pylon slapd[545]: connection_get(12)
> Nov  8 15:51:37 pylon slapd[545]: connection_get(12): got connid=1
> Nov  8 15:51:37 pylon slapd[545]: connection_read(12): checking for
> input on id=1
> Nov  8 15:51:37 pylon slapd[545]: ber_get_next on fd 12 failed errno=35
> (Resource temporarily unavailable)
> Nov  8 15:51:37 pylon slapd[545]: do_search
> Nov  8 15:51:37 pylon slapd[545]: >>> dnPrettyNormal: <QMPUPDATE>
> Nov  8 15:51:37 pylon slapd[545]: do_search: invalid dn (QMPUPDATE)
> Nov  8 15:51:37 pylon slapd[545]: send_ldap_result: conn=1 op=1 p=2
> Nov  8 15:51:37 pylon slapd[545]: send_ldap_result: err=34 matched=""
> text="invalid DN"
> Nov  8 15:51:37 pylon slapd[545]: send_ldap_response: msgid=2 tag=101
> err=34
> Nov  8 15:51:37 pylon slapd[545]: conn=1 op=1 RESULT tag=101 err=34
> text=invalid DN
> Nov  8 15:51:37 pylon slapd[545]: daemon: select: listen=6
> active_threads=0 tvp=NULL
> Nov  8 15:51:37 pylon slapd[545]: daemon: select: listen=7
> active_threads=0 tvp=NULL
> Nov  8 15:51:37 pylon slapd[545]: daemon: activity on 1 descriptors
> Nov  8 15:51:37 pylon slapd[545]: daemon: activity on:
> Nov  8 15:51:37 pylon slapd[545]:  12r
>
> It looks like suffixAlias could have solved this problem, but since
> that command is deprecated, I'm looking at using rewrite context
> directives. Can someone familiar with slapd help me out? Thanks in
> advance!!

I'm afraid the rewrite engine will not help you, because to even get
there, the incoming DN must be valid.  "QMPUPDATE" doesn't look like a DN
so it will trigger an error way before any rewriting can take place.  You
need to rewrite at the transport level, something that OpenLDAP doesn't do
at the moment.

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it


    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497