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

Re: (ITS#8668) Cache overlay, unexpected behaviour and occasional segfaults



On 06/06/17 16:42, quanah@symas.com wrote:
> --On Monday, June 05, 2017 6:08 PM +0000 acrow@integrafin.co.uk wrote:
>
>> Full_Name: Alex Crow
>> Version: 2.4.40-13.el7
>> OS: Centos 7.3
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (95.172.237.70)
>>
>>
>> I'm using OpenLDAP with the caching overlay as a proxy to AD, mostly for
>> use with Postfix and Dovecot.
>>
>> I have been experiencing a strange issue whereby, when a user is moved to
>> a different OU in AD, the caching server initially returns only the
>> original OU until the cache entry expires. However, after this time, it
>> returns both the entry in the original OU and the entry in the new OU.
>> This does not seem to change even after the next expiry time has elapsed.
>> I can only seem to clear out the "old" result by wiping the cache's
>> database.
> Hi Alex,
>
> The first thing to do would be to upgrade to OpenLDAP 2.4.44 or 2.4.45 and
> confirm you can reproduce the issue in a current release.  If you can, then
> you need to provide a full backtrace, where debug symbols are enabled (the
> "-g" flag for CFLAGS for gcc), and the slapd binary is not stripped (or if
> using packaged RPMs, the debuginfo etc bits are installed).
>
> You can grab pre-compiled packages for OpenLDAP 2.4.44 from the LTB project
> at <http://ltb-project.org/wiki/download#openldap>.  I expect they'll have
> 2.4.45 packages available soon as well.
>
> Thanks,
> Quanah
>
Hi Quanah,

I've installed a new VM with the current LTB release and the crashes 
don't seem to be happening. However, we're still seeing problems with 
the cache overlay not working as expected. We had a user account moved 
between OUs this morning shortly after 9am, and now at after 2pm the 
cache is still returning both the entry from the old OU and the new one 
(where postfix can only deal with one result in this case).

Given my configuration I'd expect the cache to at least return the 
correct result after an hour at the most - or have I made a mistake?

pcacheAttrset 0 mail x-mailHost x-mailStore unixHomeDirectory displayName
pcacheTemplate (sn=) 0 3600 0 0 1800
pcacheTemplate (cn=) 0 3600 0 0 1800
pcacheTemplate (displayName=) 0 3600 0 0 1800
pcacheTemplate (mail=) 0 3600 0 0 1800
pcacheTemplate (&(objectClass=)(mail=)) 0 3600 0 0 1800
pcacheTemplate (&(objectClass=)(mail=*)) 0 3600 0 0 1800

Postfix is set up as below:

ldaptransport_server_host = ldap://ldapcache2
                   ldap://ldapcache
ldaptransport_timeout = 2
ldaptransport_search_base = OU=foo,DC=bar,DC=baz,DC=net
ldaptransport_query_filter = (mail=%s)
ldaptransport_result_attribute = x-mailHost
ldaptransport_result_filter = relay:%s
ldaptransport_expansion_limit = 1

Best regards

Alex

> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>
>
>
>

--
This message is intended only for the addressee and may contain
confidential information. Unless you are that person, you may not
disclose its contents or use it in any way and are requested to delete
the message along with any attachments and notify us immediately.
This email is not intended to, nor should it be taken to, constitute advice.
The information provided is correct to our knowledge & belief and must not
be used as a substitute for obtaining tax, regulatory, investment, legal or
any other appropriate advice.

"Transact" is operated by Integrated Financial Arrangements Ltd.
29 Clement's Lane, London EC4N 7AE. Tel: (020) 7608 4900 Fax: (020) 7608 5300.
(Registered office: as above; Registered in England and Wales under
number: 3727592). Authorised and regulated by the Financial Conduct
Authority (entered on the Financial Services Register; no. 190856).