openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

(ITS#6330) slapd memory leak
by whm＠stanford.edu 13 Oct '09

13 Oct '09

Full_Name: Bill MacAllister Version: 2.4.18 OS: Debian 5.0 URL: http://www.stanford.edu/~whm/files/slapd/readme.html Submission from: (NULL) (75.26.167.150) We have observed what we believe to be a memory leak in OpenLDAP 2.4.18 in testing while dynlist support. We have a script that randomly expands the member lists of groups defined using dynlist. Running this script for a period of about 24 hours forces the slapd process to swap. It is not clear at all that dynlist is the problem because we were not able to see the problem with our test script until we surrounded each query with a bind/unbind. (At least we didn't wait long enough to see it.) All queries perform GSSAPI binds to the directory. The problem is unaffected by using either the MIT or Heimdal GSSAPI libraries. Our build of OpenLDAP 2.4.18 follows the debian configuration with the exceptions: * Patch for ITS6287 * Patch for ITS6308 * Patch to the index slots * disable support for tcp_wrappers and disable rlookups The details of software versions, build options, slapd configuration, scripts, db_stat output and testing procedures are at http://www.stanford.edu/~whm/files/slapd/readme.html.

1 0

(ITS#6329) memberof overlay doesn't update entryCSN
by msmith＠cbnco.com 13 Oct '09

13 Oct '09

Full_Name: Michael Smith Version: 2.4.18-55.1 OS: SLES11 (SUSE) URL: Submission from: (NULL) (207.164.182.8) Hi, It looks like the memberof overlay doesn't update a user object's entryCSN when a group object is changed. I believe this causes trouble with syncrepl, at least in a multi-master configuration: if one node is down when the group object is changed, it won't know it needs to update the user object when it comes back. I'm a little confused because while the entryCSNs don't change on the server where the group is updated, they do change on the other servers in the replication group. For example, if I add a user to a group on node 2, the user's entryCSN on node 2 might be "20091008032402.932100Z#000000#002#000000": old timestamp, correct server ID. On node 1 the entryCSN might be "20091008032142.915412Z#000000#002#000000": current timestamp, correct server ID. I'm using syncrepl with refreshAndPersist and syncprov. The memberof overlay is using its default configuration. In the stacking order, memberof comes before syncprov, but it behaved the same way in both orders. All nodes are configured with memberof and syncprov. The servers' clocks are in sync (NTP). There was a thread on openldap-software here: http://thread.gmane.org/gmane.network.openldap.general/45790/focus=45808 This is what my configuration looks like on node 1: dn: cn=config # ... olcServerID: 1 dn: olcDatabase={1}hdb,cn=config # ... olcAccess: {0}to attrs=userPassword by self write by dn.subtree="ou=service,dc=dom" read by * auth olcAccess: {1}to attrs=shadowLastChange by self write by * read olcAccess: {2}to attrs=userPKCS12 by self read by * none olcAccess: {3}to * by * read olcDbIndex: objectclass eq olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq olcLimits: {0}dn.subtree="ou=service,dc=dom" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited olcSyncrepl: {0}rid=002 provider=ldap://ldap2.dom binddn="cn=repluser,ou=service,dc=dom" bindmethod=simple credentials=xxxxxx searchbase="dc=dom" attrs="*,+" type=refreshAndPersist schemachecking=off tls_cacert=/etc/openldap/ssl/ca.crt tls_reqcert=demand interval=00:00:05:00 retry="60 +" olcMirrorMode: TRUE dn: olcOverlay={0}memberof,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig olcOverlay: {1}memberof dn: olcOverlay={1}syncprov,olcDatabase={1}hdb,cn=config objectClass: olcSyncProvConfig olcSpCheckpoint: 100 10 olcSpSessionlog: 1000 olcOverlay: {0}syncprov Node 2 looks the same, but with olcServerID: 2 and provider=ldap://ldap1.dom. Thanks, Mike

1 0

Re: (ITS#6320)
by j＠telepaths.org 12 Oct '09

12 Oct '09

Just to clear up any confusion: * Issue is not resolved * Waiting for a response from you guys Please advise. Jeff

1 0

Re: (ITS#6328) Configure OpenLDAP with BO
by quanah＠zimbra.com 12 Oct '09

12 Oct '09

--On Monday, October 12, 2009 9:04 AM +0000 hervelam(a)hotmail.com wrote: > Full_Name: HervE > Version: 2.2.29 Usage questions need to go to openldap-software(a)openldap.org or openldap-technical(a)openldap.org. I would note you are using an ancient unsupported release as well. I'd advise moving to something newer. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6328) Configure OpenLDAP with BO
by hervelam＠hotmail.com 12 Oct '09

12 Oct '09

Full_Name: HervE Version: 2.2.29 OS: Windows XP URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.41.232.181) I am trying to configure BusinessObjects in order to use OpenLDAP with it. In the LDAP authentification menu in BO, I have to map all the following attributes with the appropriate tags: Mappings of LDAP server attributes Object class: Static Group: Member of static group: Dynamic Group: Dynamic Group Filter: Group description: User object Class: Username: Full name of the user: Email User: User Description: Default LDAP search attributes Default group research attribute: Default user research attribute: Can anyone help me please? Regards, HervE

1 0

Re: (ITS#6320)
by j＠telepaths.org 12 Oct '09

12 Oct '09

OpenLDAP ITS: OK the issue is looking more and more like buggy slapd behavior. I have now narrowed down the issue to an instance where slapd is partially "hung" and will not stop nor restart. This directly correlates to replication breaking because SLAPD is breaking: Oct 11 18:22:08 server1 slapd[10771]: <= bdb_equality_candidates: (uidNumber) not indexed Oct 11 18:22:08 server1 slapd[10771]: <= bdb_equality_candidates: (gidNumber) not indexed Oct 11 18:22:08 server1 slapd[10771]: <= bdb_equality_candidates: (uidNumber) not indexed Oct 11 18:46:41 server1 slapd[10771]: <= bdb_equality_candidates: (uidNumber) not indexed Oct 11 18:48:37 server1 slapd[10771]: <= bdb_equality_candidates: (uidNumber) not indexed Oct 11 18:49:05 server1 slapd[10771]: daemon: shutdown requested and initiated. Oct 11 18:49:05 server1 slapd[10771]: slapd shutdown: waiting for 0 operations/tasks to finish As you can see, the exact time when this occurs doesn't bring anything interesting to the logs. You can see the repeated string of index warnings (not an issue, just haven't indexed this attribute yet) followed by my attempt to restart slapd when I receive a notification indicating there is a replication discrepancy. I have grepped through all of my logs (dmesg, debug, syslog) for anything related to slapd. What you see above is the more interesting of the hits returned. PLEASE help -- the issue is getting more serious now, and by the evidence I've presented, is looking more and more out of my control. You've seen my config - can anyone think of why this would happen? It seems vaguely like a locking issue .... Thanks Jeff

1 0

Re: (ITS#6320)
by j＠telepaths.org 11 Oct '09

11 Oct '09

> FYI .... > > Before going to sleep last night, I left a persistent connection > open to an LDAP server: > > > SyncInfo Received > > SyncInfo Received > > SyncInfo Received > > SyncInfo Received > ldap_result: Can't contact LDAP server (-1) <-- > sometime during the night, the connection breaks. > This turned out to be the Kerberos credentials acquired for this test command had expired. Last night, I ran the same command via Simple Bind before going to sleep. The connection is still alive several hours later. This disproves the theory of firewall-induced timeouts for replication that is achieved outside the current local zone. Jeff

1 0

Re: (ITS#6320)
by j＠telepaths.org 10 Oct '09

10 Oct '09

FYI .... Before going to sleep last night, I left a persistent connection open to an LDAP server: SyncInfo Received SyncInfo Received SyncInfo Received SyncInfo Received ldap_result: Can't contact LDAP server (-1) <-- sometime during the night, the connection breaks.

1 0

Re: (ITS#6320)
by j＠telepaths.org 09 Oct '09

09 Oct '09

OK, since my last correspondence, things seemed to be going OK. All changes had been replicated perfectly until last night, I deleted one record, and it only deleted on 4 of 6 of my servers. I removed it manually from one of the other two 'offending' servers. The last one then deleted the record on its own. So it seems as though SyncRepl is highly flaky. I looked into the firewall timeout issue and determined that it is not the cause (if it were, this issue would be happening every 30 minutes (default firewall timeout for the LDAP service)). We're still using the accesslog DB for write-transactions. Jeff

1 0

Re: (ITS#6325) test054: test failed - producer and consumer databases differ
by michael＠stroeder.com 08 Oct '09

08 Oct '09

A syncrepl-related error also happened in test050. I also can not reproduce easily. test failed - server 1 and server 4 configs differ >>>>> ./scripts/test050-syncrepl-multimaster failed for bdb (exit 1) make[2]: *** [bdb-mod] Error 1 make[2]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' make: *** [test] Error 2

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs