[Date Prev][Date Next] [Chronological] [Thread] [Top]

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


On Nov 9, 2004, at 5:15 AM, Pierangelo Masarati wrote:

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. 

Eep. Thanks for the advice. Stupid broken LDAP clients...

Is there any way for OpenLDAP to just ignore that incoming DN and use the correct DN as default? It seems another sys admin of mine had QMP working with some older version of OpenLDAP where it didn't seem to have minded a weird DN like that.

I can't try it, but it looked like suffixAlias would have been able to do this with older builds of slapd. Am I correct in assuming that?

--
Danny Wang
The Integer Group
Unix/OS X Server admin