- openldap-bugs - openldap.org

Re: (ITS#6331) slapd freezing, not accepting further 'write' operations while 'read' operations are unaffected
by j＠telepaths.org 15 Oct '09

15 Oct '09

I can - I just wish it wasn't a segfault for no reason. I was not doing any "write testing" at the time of the crash, so I have no idea what will trigger it. Nevertheless, I'll put slapd into trace mode and watch the logs, and will post anything of importance. Thanks again, Jeff On Oct 15, 2009, at 10:49 , Quanah Gibson-Mount wrote: > --On Thursday, October 15, 2009 5:43 PM +0000 j(a)telepaths.org wrote: > >> OK, problems: >> >> slapd just crashed for no apparent reason. >> >> slapd[8131]: segfault at 433e8a00 ip 433e8a00 sp 433e89a8 error 15 >> >> Not good. What version of slapd should I be using to guarantee: >> >> * No deadlocks >> * No replication errors >> * No SEGFAULTS >> >> It just seems like one buggy slapd release after another. Never >> happened with 2.3 releases ..... > > I assume you have core dumps enabled, and built OpenLDAP with > debugging symbols, and can provide the full backtrace of the > generated core? > > --Quanah > > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

hang during ldapmodify?
by Mark Dieterich 15 Oct '09

15 Oct '09

Hi all, I'm not sure if this is a bug or we are doing something wrong. For quite some time now, we have been using ldap to provide group information for our linux/unix desktop machines. I believer there are multiple methods of providing group access, this is the format we are using: # foobar, group, cs.brown.edu dn: cn=foobar,ou=group,dc=cs,dc=brown,dc=edu objectClass: posixGroup objectClass: top cn: ugrad gidNumber: 1200 memberUid: t1 memberUid: t2 memberUid: t3 memberUid: t4 memberUid: t5 . . . Up until recently, this had been working great. We are now experiencing hangs whenever we try to update the records with one particular group. I think the hangs are occur when we try to feed too much data to ldapmodify at a time. For instance, if I have the above group and try to apply the following ldif file: dn: cn=foobar,ou=group,dc=cs,dc=brown,dc=edu changetype: modify replace: memberUid memberUid: t1 memberUid: t2 memberUid: t3 memberUid: t4 memberUid: t5 memberUid: t6 memberUid: t7 memberUid: t8 memberUid: t9 . . . memberUid: t2477 memberUid: t2478 memberUid: t2479 The update simply hangs. Tossing a "-d 65535" shows that the process is sitting in loop spitting out messages similar to: ldap_int_select ldap_result ld 0x1e72bf0 msgid 5 wait4msg ld 0x1e72bf0 msgid 5 (timeout 100000 usec) wait4msg continue ld 0x1e72bf0 msgid 5 all 1 ** ld 0x1e72bf0 Connections: * host: ldapmaster.cs.brown.edu port: 6360 (default) refcnt: 2 status: Connected last used: Thu Oct 15 10:27:45 2009 ** ld 0x1e72bf0 Outstanding Requests: * msgid 5, origid 5, status InProgress outstanding referrals 0, parent count 0 ld 0x1e72bf0 request count 1 (abandoned 0) ** ld 0x1e72bf0 Response Queue: Empty ld 0x1e72bf0 response count 0 ldap_chkResponseList ld 0x1e72bf0 msgid 5 all 1 ldap_chkResponseList returns ld 0x1e72bf0 NULL ldap_int_select Hopefully, this means something more to someone on this list than it does to me;) Interestingly, if I drop the last entry and change the ldif file to be: dn: cn=foobar,ou=group,dc=cs,dc=brown,dc=edu changetype: modify replace: memberUid memberUid: t1 memberUid: t2 memberUid: t3 memberUid: t4 memberUid: t5 memberUid: t6 memberUid: t7 memberUid: t8 memberUid: t9 . . . memberUid: t2476 memberUid: t2477 memberUid: t2478 Then the update proceeds. However, if I change the last entry to read: memberUid: t2478000 Then it hangs again. Whereas with the last entry of memberUid: t247800 it updates just fine. This smells of some buffer filling or something else similar. We are running with debian's lenny version of openldap, version 2.4.11-1 (not sure what's different about the "-1" version). Other details which may be pertinent: - we are running back_bdb - syncprov - GSSAPI authentication I have not tried setting up a test server running 2.4.16/19, but did spend time looking through the chnage logs and bug system and didn't see anything that appeared to apply. However, I certainly could have missed something. Any help would be most appreciated, as we currently have one group which we are no longer able to add any entries to. Thanks! Mark

2 1

Re: (ITS#6331) slapd freezing, not accepting further 'write' operations while 'read' operations are unaffected
by quanah＠zimbra.com 15 Oct '09

15 Oct '09

--On Thursday, October 15, 2009 5:43 PM +0000 j(a)telepaths.org wrote: > OK, problems: > > slapd just crashed for no apparent reason. > > slapd[8131]: segfault at 433e8a00 ip 433e8a00 sp 433e89a8 error 15 > > Not good. What version of slapd should I be using to guarantee: > > * No deadlocks > * No replication errors > * No SEGFAULTS > > It just seems like one buggy slapd release after another. Never > happened with 2.3 releases ..... I assume you have core dumps enabled, and built OpenLDAP with debugging symbols, and can provide the full backtrace of the generated core? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6331) slapd freezing, not accepting further 'write' operations while 'read' operations are unaffected
by j＠telepaths.org 15 Oct '09

15 Oct '09

OK, problems: slapd just crashed for no apparent reason. slapd[8131]: segfault at 433e8a00 ip 433e8a00 sp 433e89a8 error 15 Not good. What version of slapd should I be using to guarantee: * No deadlocks * No replication errors * No SEGFAULTS It just seems like one buggy slapd release after another. Never happened with 2.3 releases ..... Jeff

1 0

Re: (ITS#6331) slapd freezing, not accepting further 'write' operations while 'read' operations are unaffected
by j＠telepaths.org 15 Oct '09

15 Oct '09

My apologies On Oct 15, 2009, at 10:26 , Quanah Gibson-Mount wrote: > --On Thursday, October 15, 2009 10:19 AM -0700 Jeff Doyle <j(a)telepaths.org > > wrote: > >> Thank you Gibson, my checkpoints (both definitions) have not changed >> since you last asked, but the fact that it can help with shutdown >> times >> is a very useful tip, thanks! >> >> Jeff > > Just to note, my first name is "Quanah", not "Gibson". "Gibson- > Mount" is my last name. > > Which is why I sign my emails thusly: > > --Quanah > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6331) slapd freezing, not accepting further 'write' operations while 'read' operations are unaffected
by quanah＠zimbra.com 15 Oct '09

15 Oct '09

--On Thursday, October 15, 2009 10:19 AM -0700 Jeff Doyle <j(a)telepaths.org> wrote: > Thank you Gibson, my checkpoints (both definitions) have not changed > since you last asked, but the fact that it can help with shutdown times > is a very useful tip, thanks! > > Jeff Just to note, my first name is "Quanah", not "Gibson". "Gibson-Mount" is my last name. Which is why I sign my emails thusly: --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6331) slapd freezing, not accepting further 'write' operations while 'read' operations are unaffected
by j＠telepaths.org 15 Oct '09

15 Oct '09

Thank you Gibson, my checkpoints (both definitions) have not changed since you last asked, but the fact that it can help with shutdown times is a very useful tip, thanks! Jeff

1 0

Re: (ITS#6331) slapd freezing, not accepting further 'write' operations while 'read' operations are unaffected
by quanah＠zimbra.com 15 Oct '09

15 Oct '09

--On Thursday, October 15, 2009 4:50 PM +0000 j(a)telepaths.org wrote: > OK, I believe the dead-lock issue is solved, however OCCASIONALLY when > attempting a restart or stop of the slapd process, it throws an error > saying 'slapd stop failed', however the slapd process does quit as > expected, so its a "false failure". > > The one possibility for the reason this is happening, aside from > blaming slapd, is that my two test boxes are VMs ... so I kind of > expect sluggish responses, especially on a VMware server as busy as > ours. I will note that our production LDAP servers are NOT VMs and > will never be ;-) > > I believe you were correct, Pierangelo. I will post my findings over > the next fews days to keep everyone in the loop. Probably the issue. Make sure you have checkpoints defined for all bdb/hdb databases as well, which will help with shutdown times. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6331) slapd freezing, not accepting further 'write' operations while 'read' operations are unaffected
by j＠telepaths.org 15 Oct '09

15 Oct '09

OK, I believe the dead-lock issue is solved, however OCCASIONALLY when attempting a restart or stop of the slapd process, it throws an error saying 'slapd stop failed', however the slapd process does quit as expected, so its a "false failure". The one possibility for the reason this is happening, aside from blaming slapd, is that my two test boxes are VMs ... so I kind of expect sluggish responses, especially on a VMware server as busy as ours. I will note that our production LDAP servers are NOT VMs and will never be ;-) I believe you were correct, Pierangelo. I will post my findings over the next fews days to keep everyone in the loop. Thanks, Jeff

1 0

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

15 Oct '09

> Apparently, accessing that URL requires a valid account. In any case, you > should run slapd under valgrind for a while, in order to locate the leak. Sorry about that. The URL should be accessible now. I will start the valgrind work a bit later this morning on the left coast. Bill -- Bill MacAllister, System Software Programmer Unix Systems Group, Stanford University

1 0

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

14 Oct '09

On Wed, 14 Oct 2009, masarati(a)aero.polimi.it wrote: > Should be fixed in HEAD (one-line fix, see overlays/memberof.c 1.25 -> 1.26). > > Please test. Thanks, p. Thanks - I applied this to openldap 2.4.19 and the entryCSNs now match on all nodes, as long as they're all up when a group is modified. I still get something strange if one node is down: if I remove a user from a group on the working node, then bring the failed node back, the failed node doesn't sync the modified group and user objects. For example, if I remove testuser3 from testgroup2 while node 2 is down, then bring node 2 back, I get this on node 1: dn: uid=testuser3,ou=people,dc=dom memberOf: cn=testgroup1,ou=group,dc=dom entryCSN: 20091015040419.455869Z#000000#001#000000 dn: cn=testgroup2,ou=group,dc=dom member: uid=testuser2,ou=people,dc=dom entryCSN: 20091015040419.455869Z#000000#001#000000 And this on node 2: dn: uid=testuser3,ou=people,dc=dom memberOf: cn=testgroup2,ou=group,dc=dom memberOf: cn=testgroup1,ou=group,dc=dom entryCSN: 20091015033445.046089Z#000000#002#000000 dn: cn=testgroup2,ou=group,dc=dom member: uid=testuser2,ou=people,dc=dom member: uid=testuser3,ou=people,dc=dom entryCSN: 20091015033233.354687Z#000000#001#000000 I don't have this problem with changes that don't involve member/memberOf attributes. For example, I can add a description attr to the group object while node 2 is down, and when I bring it back up, it picks up the change. On both nodes I've got the memberof and syncprov overlays turned on, in that order. dn: olcOverlay={0}memberof,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig olcOverlay: {0}memberof dn: olcOverlay={1}syncprov,olcDatabase={1}hdb,cn=config objectClass: olcSyncProvConfig olcSpCheckpoint: 100 10 olcSpSessionlog: 1000 olcOverlay: {1}syncprov Thanks, Mike

1 0

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

14 Oct '09

OK, for anyone following this thread, please refer to ITS #6331, as I believe this issue may not be a "replication issue" at all, rather a deadlock PREVENTING replication. Might as well close this ticket, thanks for everyone's help. Jeff

1 0

Re: (ITS#6331) slapd freezing, not accepting further 'write' operations while 'read' operations are unaffected
by j＠telepaths.org 14 Oct '09

14 Oct '09

OK, I was able to compile a set of Debian packages for version 2.4.19 using the source obtained from openldap.org. I have set up a mirror of our production environment (less a few servers). I have two provider servers in mirrormode, and configured for multimaster syncrepl. So far, no locks, no replication issues, everything seems peachy. Though, in real-life, the problem has a tendency to reappear sometimes a week after a slapd-restart. We'll see what happens. I will continue to update this ticket, detailing any further developments. Thanks again Pierangelo and Gibson, I appreciate your help. Jeff

1 0

Re: (ITS#6331) slapd freezing, not accepting further 'write' operations while 'read' operations are unaffected
by j＠telepaths.org 14 Oct '09

14 Oct '09

Thanks for responding, Pierangelo. I am asking (begging) my chief engineer to entertain this idea. Will report back ASAP. Thanks, Jeff On Oct 14, 2009, at 11:52 AM, masarati(a)aero.polimi.it wrote: >> Version: 2.4.17 > >> Occasionally, I will find one of my servers (running Debian/Lenny >> with >> back-ported slapd version 2.4.17) in a state where the following >> occurs: >> >> * Write operations will 'freeze' - leaving the requester at a frozen >> prompt or >> frozen LDAP-client of some kind (from wherever the write-operation >> originated). >> * slapd refuses to 'stop', even though it indicates that its >> waiting for >> "0" >> processes to complete. >> * Logs do not indicate a segfault nor any poorly terminated >> processes. >> * Read operations on same server continue to function normally. >> Any data >> that >> existed before the "freeze" is returned as it should be. > > You probably hit ITS#6276, which was fixed in 2.4.18. Can you > upgrade and > test? > > p. >

1 0

Re: (ITS#6331) slapd freezing, not accepting further 'write' operations while 'read' operations are unaffected
by masarati＠aero.polimi.it 14 Oct '09

14 Oct '09

> Version: 2.4.17 > Occasionally, I will find one of my servers (running Debian/Lenny with > back-ported slapd version 2.4.17) in a state where the following occurs: > > * Write operations will 'freeze' - leaving the requester at a frozen > prompt or > frozen LDAP-client of some kind (from wherever the write-operation > originated). > * slapd refuses to 'stop', even though it indicates that its waiting for > "0" > processes to complete. > * Logs do not indicate a segfault nor any poorly terminated processes. > * Read operations on same server continue to function normally. Any data > that > existed before the "freeze" is returned as it should be. You probably hit ITS#6276, which was fixed in 2.4.18. Can you upgrade and test? p.

1 0

Re: (ITS#6331) slapd freezing, not accepting further 'write' operations while 'read' operations are unaffected
by j＠telepaths.org 14 Oct '09

14 Oct '09

Quanah, Thanks for responding. Here are the answers to your questions: ldd /usr/sbin/slapd linux-vdso.so.1 => (0x00007fff4f1ff000) libldap_r-2.4.so.2 => /usr/lib/libldap_r-2.4.so.2 (0x00007f2646c5e000) liblber-2.4.so.2 => /usr/lib/liblber-2.4.so.2 (0x00007f2646a4f000) libdb-4.6.so => /usr/lib/libdb-4.6.so (0x00007f2646705000) libodbc.so.1 => /usr/lib/libodbc.so.1 (0x00007f26464a9000) libslp.so.1 => /usr/lib/libslp.so.1 (0x00007f2646297000) libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x00007f264607d000) libgnutls.so.26 => /usr/lib/libgnutls.so.26 (0x00007f2645dcb000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x00007f2645b93000) libresolv.so.2 => /lib/libresolv.so.2 (0x00007f264597f000) libltdl.so.3 => /usr/lib/libltdl.so.3 (0x00007f2645778000) libwrap.so.0 => /lib/libwrap.so.0 (0x00007f264556f000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007f2645353000) libc.so.6 => /lib/libc.so.6 (0x00007f2645000000) libnsl.so.1 => /lib/libnsl.so.1 (0x00007f2644de8000) libdl.so.2 => /lib/libdl.so.2 (0x00007f2644be4000) libtasn1.so.3 => /usr/lib/libtasn1.so.3 (0x00007f26449d4000) libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0x00007f2646fb5000) libz.so.1 => /usr/lib/libz.so.1 (0x00007f26447bd000) libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 (0x00007f2644556000) /lib64/ld-linux-x86-64.so.2 (0x00007f2646ea9000) From slapd.conf: tool-threads 4 # this has varied between 1 and 4 syncprov-checkpoint 1 5 # we've tried using the default settings, very lax settings, etc - never made a difference. checkpoint 10 1 # checkpointing for Berkeley And the rest of the Berkeley settings in our DIT suffix area: database hdb cachesize 10000 idlcachesize 30000 checksum cachefree 20 dncachesize 100000 dbconfig set_cachesize 1 0 2 dbconfig set_lg_max 10485760 dbconfig set_flags db_log_autoremove dbconfig set_lg_bsize 2097152 dbconfig set_lk_max_objects 5500 dbconfig set_lk_max_locks 5500 dbconfig set_lk_max_lockers 5500 The version of BDB is as fully-patched as Debian keeps up with it. We (as a company) stay on top of updates, while Debian only tends to fix security bugs and pretty much will ignore feature issues and lack- luster functionality in their packages. They do this religiously, which is shameful. Thanks again, Jeff

1 0

Re: (ITS#6329) memberof overlay doesn't update entryCSN
by masarati＠aero.polimi.it 14 Oct '09

14 Oct '09

> 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. Should be fixed in HEAD (one-line fix, see overlays/memberof.c 1.25 -> 1.26). Please test. Thanks, p.

1 0

Re: (ITS#6330) slapd memory leak
by masarati＠aero.polimi.it 14 Oct '09

14 Oct '09

> 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. Apparently, accessing that URL requires a valid account. In any case, you should run slapd under valgrind for a while, in order to locate the leak. p.

1 0

Re: (ITS#6331) slapd freezing, not accepting further 'write' operations while 'read' operations are unaffected
by quanah＠zimbra.com 14 Oct '09

14 Oct '09

--On Wednesday, October 14, 2009 1:11 AM +0000 j(a)telepaths.org wrote: > Full_Name: Jeff Doyle > Version: 2.4.17 > OS: Debian/Lenny > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (130.94.106.251) > > > Greetings, > > Occasionally, I will find one of my servers (running Debian/Lenny with > back-ported slapd version 2.4.17) in a state where the following occurs: > > * Write operations will 'freeze' - leaving the requester at a frozen > prompt or frozen LDAP-client of some kind (from wherever the > write-operation originated). * slapd refuses to 'stop', even though it > indicates that its waiting for "0" processes to complete. > * Logs do not indicate a segfault nor any poorly terminated processes. > * Read operations on same server continue to function normally. Any > data that existed before the "freeze" is returned as it should be. > > Modules used: > > * accesslog > * back_hdb > * back_monitor > * back_relay > * back_rwm > * syncprov > > Servers are all fairly new, and reasonably beefy for their purposes: > > * 6GB RAM > * 2+ GHz CPU, all QuadCore Xeon and all running amd64 kernel (current > with Lenny) > * Plenty of Disk Space (gigs and gigs) > * Servers are SLEEPING (0.00 avg load) > > slapd is making use of 'tool-threads' with a value of '4' - however > changing this value has had no effect - Just a side note. tool threads only affects offline operations (slapadd). How many threads do you have configured? What version of BDB is slapd linked against? Is the bdb version fully patched? What is your checkpoint directive set to in both the accesslog and hdb databases? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6332)
by l.mierzwa＠gmail.com 14 Oct '09

14 Oct '09

--0016e6d7df78582bd90475e3ecd0 Content-Type: text/plain; charset=ISO-8859-1 > but when I add member attribute I mean: when I add it to ldif, so it looks like: dn: cn=shell,ou=access,<basedn> changetype: modify replace: objectClass objectClass: groupOfNames objectClass: top - replace: cn cn: shell - replace: description description: blablabla - replace: member member: uid=user1[...] member: uid=user2[...] member: uid=user3[...] --0016e6d7df78582bd90475e3ecd0 Content-Type: text/html; charset=ISO-8859-1 > but when I add member attribute I mean: when I add it to ldif, so it looks like: dn: cn=shell,ou=access,<basedn> changetype: modify replace: objectClass objectClass: groupOfNames objectClass: top - replace: cn cn: shell - replace: description description: blablabla - replace: member member: uid=user1[...] member: uid=user2[...] member: uid=user3[...] --0016e6d7df78582bd90475e3ecd0--

1 0

(ITS#6332) replication issues
by lmierzwa＠gmail.com 14 Oct '09

14 Oct '09

Full_Name: £ukasz Mierzwa Version: 2.4.18/19 OS: Linux / Freebsd URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.232.239.146) I'm using syncrepl with this config on master overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 and on slaves syncrepl rid=100 provider=ldap://ldap-master type=refreshOnly interval=00:00:01:00 retry="60 +" searchbase="<base>" filter="(objectClass=*)" scope=sub schemachecking=off bindmethod=sasl saslmech=DIGEST-MD5 authcid="<replicator login>" credentials="<pass>" starttls=yes I modify data on master using ldapmodify with this ldif: dn: cn=shell,ou=access,<basedn> changetype: modify replace: objectClass objectClass: groupOfNames objectClass: top - replace: cn cn: shell - replace: description description: blablabla note that only description is getting new value, cn and objectClass are being set to the same value as before modification and everything works, slaves are getting changed data, but when I add member attribute (which also is set to the same value as it was) slaves are not seeing any change, logs on slaves are only showing "do_syncrep2: rid=100 LDAP_RES_SEARCH_RESULT" Master is ubuntu 9.04 with openldap 2.4.15 + I tested 2.4.18 from 9.10, same result. Slaves are ubuntu 9.04 (2.4.15 and 2.4.18) and Freebsd 7.0 (2.4.19)

1 0

Re: (ITS#6251) GnuTLS cipher suite failure
by kent＠cpttm.org.mo 13 Oct '09

13 Oct '09

Hi, I am having this issue, but setting the cipher suite to +RSA:+AES-256-CBC:+SHA1 doesn't fix the problem. slapd.conf: TLSCipherSuite +RSA:+AES-256-CBC:+SHA1 TLSCACertificateFile /etc/ldap/ssl/cacert.pem TLSCertificateFile /etc/ldap/ssl/cert.pem TLSCertificateKeyFile /etc/ldap/ssl/key.pem Debug log of slapd: tchingRuleUse: ... supportedFeatures $ supportedApplicationContext ) ) TLS: could not set cipher list +RSA:+AES-256-CBC:+SHA1. main: TLS init def ctx failed: -1 slapd destroy: freeing system resources. slapd stopped. Output of "gnutls-cli -l": ... TLS_RSA_EXPORT_ARCFOUR_40_MD5 0x00, 0x03 SSL 3.0 TLS_RSA_ARCFOUR_SHA1 0x00, 0x05 SSL 3.0 TLS_RSA_ARCFOUR_MD5 0x00, 0x04 SSL 3.0 TLS_RSA_3DES_EDE_CBC_SHA1 0x00, 0x0a SSL 3.0 TLS_RSA_AES_128_CBC_SHA1 0x00, 0x2f SSL 3.0 TLS_RSA_AES_256_CBC_SHA1 0x00, 0x35 SSL 3.0 Certificate types: X.509, OPENPGP Protocols: SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2 Ciphers: AES 256 CBC, AES 128 CBC, 3DES 168 CBC, DES CBC, ARCFOUR 128, ARCFOUR 4 0, RC2 40, NULL MACs: SHA, MD5, SHA256, SHA384, SHA512, MD2, RIPEMD160, NULL Key exchange algorithms: Anon DH, RSA, RSA EXPORT, DHE RSA, DHE DSS, SRP DSS, SR P RSA, SRP, PSK, DHE PSK Compression: LZO, DEFLATE, NULL -- Kent Tong SME accounting software package for just MOP30. See http://www.cpttm.org.mo/index_c.php?pg=cpttm/department/is/ispu/accsys/inde… for more.

1 0

(ITS#6331) slapd freezing, not accepting further 'write' operations while 'read' operations are unaffected
by j＠telepaths.org 13 Oct '09

13 Oct '09

Full_Name: Jeff Doyle Version: 2.4.17 OS: Debian/Lenny URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (130.94.106.251) Greetings, Occasionally, I will find one of my servers (running Debian/Lenny with back-ported slapd version 2.4.17) in a state where the following occurs: * Write operations will 'freeze' - leaving the requester at a frozen prompt or frozen LDAP-client of some kind (from wherever the write-operation originated). * slapd refuses to 'stop', even though it indicates that its waiting for "0" processes to complete. * Logs do not indicate a segfault nor any poorly terminated processes. * Read operations on same server continue to function normally. Any data that existed before the "freeze" is returned as it should be. Modules used: * accesslog * back_hdb * back_monitor * back_relay * back_rwm * syncprov Servers are all fairly new, and reasonably beefy for their purposes: * 6GB RAM * 2+ GHz CPU, all QuadCore Xeon and all running amd64 kernel (current with Lenny) * Plenty of Disk Space (gigs and gigs) * Servers are SLEEPING (0.00 avg load) slapd is making use of 'tool-threads' with a value of '4' - however changing this value has had no effect - Just a side note. Inform me of any further configs and/or information that you need, and I will provide it promptly. Thanks, Jeff

1 0

(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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs