Re: [exim] LDAP connection caching problem?

Góra strony
Delete this message
Reply to this message
Autor: John Dalbec
Data:  
Dla: exim-users
Nowe tematy: SSL LDAP connection caching problem (was Re: [exim] LDAP connection caching problem?)
Temat: Re: [exim] LDAP connection caching problem?
John Dalbec wrote:

> John Dalbec wrote:
>
>> Nigel Wade wrote:
>>
>>> John Dalbec wrote:
>>>
>>>> John Dalbec wrote:
>>>>
>>>>> Exim 4.50, 4.52:
>>>>> routing seems to work OK, but the delivery process (in some cases)
>>>>> can't seem to
>>>>> talk to LDAP. The search should return no results. OpenLDAP 2.0.x
>>>>> library, Novell eDirectory 8.7.3.4 server.
>>>>>
>>>>> exim -d -M ... yields:
>>>>>
>>>>> after ldap_url_parse: host=... port=636
>>>>> re-using cached connection to LDAP server ...:636
>>>>> Start search
>>>>> search ended by ldap_result yielding -1
>>>>> ldap_result failed
>>>>> ldap_result failed: 81, Can't contact LDAP server
>>>>> lookup deferred: ldap_result failed: 81, Can't contact LDAP server
>>>>> condition check lookup defer
>>>>>
>>>>> Any thoughts?
>>>>> TIA,
>>>>> John
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> By post-hoc reasoning I worked out that a new address rewriting rule
>>>> I had added seemed to be tickling the problem.
>>>>
>>>> ^([a-z]+).([0-9]+)@((?:...)ysu\\.edu)\$ "\
>>>>         ${lookup ldap\
>>>>         {user=... \
>>>>         pass=... \
>>>>         ldaps:///...?uid?sub?(uid=${quote_ldap:$1$2})}\
>>>>         {$1$2@$3}fail}"         Eh

>>>>
>>>> We plan to convert our dotted local parts to undotted local parts.
>>>> This rule is intended to make sure the dotted addresses keep working
>>>> after we change the local parts in LDAP. We won't necessarily be
>>>> able to change them all at once so we have to check the directory to
>>>> see whether the correct local part is dotted or undotted.
>>>>
>>>> Does anyone see a problem with this rule?
>>>> Thanks,
>>>> John
>>>>
>>>
>>> Are you sure the LDAP server is listening on the ldaps (i.e.
>>> encrypted) port 636, and that it and Exim are fully configured for
>>> the encryption handshake (TLS, SSL or whatever is being used)?
>>
>>
>>
>> Yes, I have other LDAP-based rules that work just fine. The rule that
>> I pasted is not actually what fails. The failure occurs in this router:
>>
>>   driver = accept
>>   check_local_user
>>   hide condition = ${lookup ldap\
>>         {user=... \
>>         pass=... \
>>         ldaps:///...?mail?sub?(mail=${quote_ldap:$local_part@...})}\
>>         {yes}{no}}
>>   domains = ...
>>   transport = ...

>>
>> We have (essentially) two virtual domains. Users in domain A have
>> their mailboxes stored in one directory tree; users in domain B (but
>> not in domain A) have their mailboxes stored in another directory
>> tree. We do have some users in both domains, so given an address in
>> domain B, I have to check whether an address in domain A exists with
>> the same local part, and if so, I have to route the e-mail to the
>> domain A transport.
>>
>> This router works fine until I insert the rewriting rule above, and
>> then I get the errors shown above.
>> John
>>
>>
>
> The problem seems to be triggered when Exim routes a recipient address
> in domain B with a .forward file of the form "blah@???,
> \a.b@domainB". Exim runs through the address rewriting rules from the
> top when it processes the .forward file and the LDAP searches start
> failing after the problematic rewriting rule.
>
> I don't think it's an LDAP server issue because I wrote a Perl script to
> perform the same sequence of searches and it worked just fine.
>
> Any ideas?
> Thanks,
> John
>

The problem seems to be related to a non-cached search occurring in a
subprocess. Maybe OpenLDAP or OpenSSL is keeping some state information that
gets lost when the child process ends? Is that possible?
Thanks,
John