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

[acrow@integrafin.co.uk]

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.

Here is my slapd.conf:

### Schema includes ###########################################################
include                 /etc/openldap/schema/core.schema
include                 /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include                 /etc/openldap/schema/misc.schema
#include                 /etc/openldap/schema/nis.schema
include                 /etc/openldap/schema/custom.schema
include                 /etc/openldap/schema/adstuff.schema

## Module paths ##############################################################
modulepath              /usr/lib64/openldap/
moduleload              back_ldap
moduleload              pcache
#moduleload             rwm

# Main settings ###############################################################
TLSCACertificateFile /etc/openldap/cacerts/cacertchain.pem
TLSCertificateFile /etc/openldap/cacerts/certkey.pem
TLSCertificateKeyFile /etc/openldap/cacerts/certkey.pem
TLSVerifyClient   never

pidfile                 /var/run/openldap/slapd.pid
argsfile                /var/run/openldap/slapd.args
allow                   bind_v2

database config
rootdn "cn=admin,cn=config"
rootpw {SSHA}blahblahblah

### Database definition (Proxy to AD) #########################################
database                ldap
readonly                yes
protocol-version        3
rebind-as-user
uri                     "ldap://foo ldap://bar ..."
suffix                  "dc=foo,dc=bar,dc=net"
rootdn                  "dc=foo,dc=bar,dc=net"
timelimit               5


overlay pcache
pcache    bdb 100000 1 1000 100
pcacheAttrset 0 mail x-mailHost x-mailStore unixHomeDirectory
pcacheTemplate (sn=) 0 3600 0 0 1800
pcacheTemplate (cn=) 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

cachesize 10000
directory /var/lib/ldap
index       objectClass eq
index       cn,sn,uid,mail  pres,eq,sub

### Logging ###################################################################
loglevel                0


Here is an example of a search returning two results from the cache:

# extended LDIF
#
# LDAPv3
# base <OU=baz,DC=foo,DC=bar,DC=net> with scope subtree
# filter: mail=test_ajc@integrafin.co.uk
# requesting: x-mailHost
#

# test_ajc, DMD, COPS, ...
dn: cn=test_ajc,ou=DMD,ou=COPS, ...
 dc=bar,dc=net
x-mailHost: imap.bar.net

# test_ajc, SysAdmin, ITDIV, ...
dn: cn=test_ajc,ou=SysAdmin,ou=ITDIV, ...
 dc=bar,dc=net
x-mailHost: imap.bar.net

# search result
search: 2
result: 0 Success

# numResponses: 3
# numEntries: 2

The newer, correct entry is the lower one.

We also occasionally suffer segfaults, eg:

[8432930.512516] slapd[19550]: segfault at 108 ip 00007f4204c401de sp
00007f41c1ff94d0 error 6 in libldap_r-2.4.so.2.10.3[7f4204c18000+56000]
[8434338.469945] slapd[30666]: segfault at 108 ip 00007f102a5c41de sp
00007f1014c744d0 error 6 in libldap_r-2.4.so.2.10.3[7f102a59c000+56000]
[8951331.245103] slapd[9653]: segfault at 11d8 ip 00007f01c523d1de sp
00007f01abffd4d0 error 6 in libldap_r-2.4.so.2.10.3[7f01c5215000+56000]
[10140511.797794] slapd[10247]: segfault at 108 ip 00007fbc84de01de sp
00007fbc477fc4d0 error 6 in libldap_r-2.4.so.2.10.3[7fbc84db8000+56000]

I've not determined what, if anything specific triggers these.

Any insights much appreciated.

Alex