openldap-bugs December 2009

openldap-bugs@openldap.org

28 participants
133 discussions

Re: (ITS#6412) compute loop in openldap 2.4.20
by hyc＠symas.com 03 Dec '09

03 Dec '09

Howard Chu wrote: > aej(a)WPI.EDU wrote: >> I ran for a long time with -d1 and it didn't loop again. >> >> Then, I changed it from running in an xterm under script to simply: >> >> slapd -d1 2> /filename >> >> This started looping almost immediately. The script is in >> http://users.wpi.edu/~aej/trace > > I think we'll need a copy of your client and server certs to reproduce this > locally to identify a fix. And your slapd.conf / ldap.conf / .ldaprc TLS settings. > In the meantime you can revert the patch for ITS#6304 to avoid this problem, until we come up with a real fix. (Revert slapd/connection.c:1.446) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6300) Add kqueue support to slapd
by bduncan＠apple.com 03 Dec '09

03 Dec '09

On Nov 22, 2009, at 6:43 PM, Howard Chu wrote: > bduncan(a)apple.com wrote: >> On Sep 22, 2009, at 1:02 PM, Quanah Gibson-Mount wrote: >>=20 >>> --On Tuesday, September 22, 2009 7:23 PM +0000 bduncan(a)apple.com >>> wrote: >>>=20 >>>> Subject should have been: "PATCH - Added kqueue support to slapd" = to >>>> make clear this ITS tracks a patch that has been submitted. >>>=20 >>> What OS(es) has this kqueue support been tested with? For example, >>> the last time I looked at kqueue on OSX 10.5, it was very marginal, >>> and missing most of the important pieces, which meant it wouldn't >>> work for OpenLDAP or Postfix, etc. >>=20 >> It was tested on OS X 10.6. Should work on all BSDs; nothing OSX- >> specific about the kqueue usage in the patch. As far as kqueue >> support in OS X 10.5, from what I see, most everything is there. >> Certainly all of the kqueue features in this patch are supported in = OS >> X 10.5. >=20 > To expand on this: there are a lot of comments around the web that = kqueue was fairly broken at least up to 10.5. E.g. this: >=20 > http://lists.schmorp.de/pipermail/libev/2008q4/000523.html Perhaps I missed something in that thread, but the only specific = complaint was regarding kqueue and stdin. And it's true that OS X's = kqueue didn't support EVFILT_{READ|WRITE} on *devices* (stdin, tty's, = /dev/* ) until 10.6. I don't believe OpenLDAP actually needs that = feature, though. >=20 > Since we also use a pipe for the wake_sds[] in our event loop, if = kqueue only supports sockets, then it cannot be used reliably in slapd. The OS X kqueue has *always* supported EVFILT_{READ|WRITE} on sockets, = pipes, fifos, files. Same for kqueue in the BSDs. (FWIW, I believe the = BSDs have always supported devices in kqueue.) I think everything OpenLDAP needs from kqueue has been, and is, = supported by OS X and the BSDs. If there is a specific kqueue filter or = fd type that OpenLDAP needs and isn't supported, please let me know. Although I don't think it's necessary, you could add a test to the = configure script to ensure kqueue supports the types of fd's OpenLDAP = needs by doing something like this: int fd; /* or int fds[2]; */ /* do something to create an fd here: open(2), pipe(2), socket(2), = etc. */ struct kevent ev; EV_SET(&ev, fd, EVFILT_READ, EV_ADD, 0, 0, 0); int kq =3D kqueue(); if (kq < 0) { ac_have_kqueue =3D false; } else { struct timespec to =3D {0,1}; /* anything so that kevent will = return */ int ret =3D kevent(kq, &ev, 1, &ev, 1, &to); close(kq); ac_have_kqueue =3D (ret >=3D 0); } If the fd isn't supported 'ret' should be -1 and errno should be = ENOTSUP. -- Bryan Duncan

1 0

(ITS#6413) Race replicating syncrepl config
by rein＠OpenLDAP.org 03 Dec '09

03 Dec '09

Full_Name: Rein Tollevik Version: CVS head OS: Solaris URL: Submission from: (NULL) (84.215.13.80) Submitted by: rein There is a race condition when the syncrepl config in cn=config is initialized in a MMR configuration. Seen by test050, but so far only on Solaris10 x86_64. The problem appear to be that a do_syncrepl task can be added to the thread queue while syncrepl_config is deleting it. It removes any tasks already in the queue, but the main loop in daemon.c is still running when the thread processing have been paused and can add new tasks to the thread queue from its runqueue. A patch is coming. An alternative fix may be to stop processing the runqueue when threading is paused. That may still leave the possibility of a task being added to the thread queue as a result of syncrepl input, although I haven't seen that happen. Rein Tollevik Basefarm AS

1 0

Re: (ITS#6412) compute loop in openldap 2.4.20
by hyc＠symas.com 03 Dec '09

03 Dec '09

aej(a)WPI.EDU wrote: > I ran for a long time with -d1 and it didn't loop again. > > Then, I changed it from running in an xterm under script to simply: > > slapd -d1 2> /filename > > This started looping almost immediately. The script is in > http://users.wpi.edu/~aej/trace I think we'll need a copy of your client and server certs to reproduce this locally to identify a fix. And your slapd.conf / ldap.conf / .ldaprc TLS settings. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6412) compute loop in openldap 2.4.20
by aej＠WPI.EDU 03 Dec '09

03 Dec '09

I ran for a long time with -d1 and it didn't loop again. Then, I changed it from running in an xterm under script to simply: slapd -d1 2> /filename This started looping almost immediately. The script is in http://users.wpi.edu/~aej/trace

1 0

(ITS#6412) compute loop in openldap 2.4.20
by aej＠wpi.edu 03 Dec '09

03 Dec '09

Full_Name: Allan E. Johannesen Version: 2.4.20 OS: RedHat Linux URL: http://users.wpi.edu/~aej/typescript.txt Submission from: (NULL) (130.215.36.68) In one server environment, I've found that slapd starts consuming CPU. I ran it -d-1 and it seemed to run ok. Then I tried -d1. That usually worked, but on one occasion it ran away, too. I think debugging affects the timing. My belief is that it's in a certificate retry loop of some sort. I'll attach a log of the -d1 output showing some cert retries. This run didn't go into the loop, though. The one debug -d1 which went into a compute loop was spewing these. I managed to ^C it, but also managed to delete the typescript, so I can't show the thousands of retries on the one connection which had kept it busy.

1 0

Re: (ITS#6411) Possible bug in Overlay pPolicy
by jarbas.junior＠gmail.com 03 Dec '09

03 Dec '09

--0016367f92e6a19d180479d1aa27 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Attached to the configuration file server testing openldap squeeze. I made some changes to the file /etc/ldap/slapd.overlay.conf being included by /etc/ldap/slapd.conf and discovered that the problem is with the overlay rwm, because when I comment that overlay the problem does not appear. If I keep the following entries rwm overlay the problem happen again: moduleload rwm overlay rwm Even with the other settings overlay rwm commented the problem continues. Any ideas? 2009/12/2 Howard Chu <hyc(a)symas.com>: > jarbas.junior(a)gmail.com wrote: >> >> Full_Name: Jarbas Peixoto Junior >> Version: 2.4.11 / 2.4.17 / 2.4.20 >> OS: Gnu/Linux Debian >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (200.152.34.143) >> >> >> Possible bug in Overlay pPolicy >> >> I have OpenLDAP installed via the Debian Lenny package functioning >> normally. >> >> Aiming to test the version of Debian Squeeze in the test machine install= ed >> package slapd (2.4.17-2.1) with the same set of Debian Lenny (2.4.11). >> >> However, when testing the overlay pPolicy noticed that a wrong password >> authentication, runs all objects in the ldap database, causing a "delay" >> that >> does not exist in version Lenny. >> >> Below is some information that may be useful in detecting the problem: >> >> File: slapd.conf >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> moduleload =A0 =A0 =A0ppolicy >> overlay ppolicy >> ppolicy_default >> "cn=3Ddefault,ou=3DLdapPassword,ou=3DPoliticas,ou=3DBuiltin,dc=3Dprevide= ncia,dc=3Dgov,dc=3Dbr" >> ppolicy_use_lockout >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> ldapsearch -LLL -x -H ldap://squeeze -b >> ou=3DLdapPassword,ou=3DPoliticas,ou=3DBuiltin,dc=3Dprevidencia,dc=3Dgov,= dc=3Dbr >> '(cn=3Ddefault)' >> dn: >> cn=3Ddefault,ou=3DLdapPassword,ou=3DPoliticas,ou=3DBuiltin,dc=3Dpreviden= cia,dc=3Dgov,d >> =A0c=3Dbr >> objectClass: top >> objectClass: device >> objectClass: pwdPolicy >> pwdAttribute: userPassword >> description:: >> UG9sw610aWNhIGRlIFNlbmhhIERlZmF1bHQgcGFyYSB0b2RvcyB1c3XDoXJpb3M=3D >> pwdAllowUserChange: TRUE >> pwdFailureCountInterval: 3600 >> pwdGraceAuthNLimit: 5 >> pwdInHistory: 0 >> pwdLockoutDuration: 60 >> pwdMaxAge: 7776000 >> pwdMinAge: 0 >> pwdMinLength: 6 >> pwdSafeModify: FALSE >> pwdCheckQuality: 1 >> pwdExpireWarning: 600 >> cn: default >> pwdMustChange: FALSE >> pwdMaxFailure: 10 >> pwdLockout: FALSE >> >> date ; ldapsearch -LLL -x -H ldap://squeeze -b >> ou=3Dusuarios,dc=3Dprevidencia,dc=3Dgov,dc=3Dbr -D >> uid=3Djarbas.peixoto,ou=3Dpessoas,ou=3Dusuarios,dc=3Dprevidencia,dc=3Dgo= v,dc=3Dbr -w >> wrong-password '(uid=3Djarbas.peixoto)' cn mail pwdFailureTime >> pwdAccountLockedTime modifyTimeStamp ; date >> Qua Dez =A02 16:14:56 AMST 2009 >> ldap_bind: Invalid credentials (49) >> Qua Dez =A02 16:15:36 AMST 2009 >> >> grep 'access_allowed: search access to' /var/log/debug | wc -l >> 83714 >> >> The question is: why access all entries in LDAP? > > Don't know. This would have to be the result of a search operation, but > there is no search code in ppolicy.c. Since ppolicy cannot be the culprit= , > we'll need to see the rest of your config to track down the issue. > > -- > =A0-- Howard Chu > =A0CTO, Symas Corp. =A0 =A0 =A0 =A0 =A0 http://www.symas.com > =A0Director, Highland Sun =A0 =A0 http://highlandsun.com/hyc/ > =A0Chief Architect, OpenLDAP =A0http://www.openldap.org/project/ > --0016367f92e6a19d180479d1aa27 Content-Type: application/x-gzip; name="ldap-squeeze.tgz" Content-Disposition: attachment; filename="ldap-squeeze.tgz" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g2rgwh8a1 H4sIAISmF0sAA+1aW28bxxXWK/dXDCgjIhNSInVLakBAGUpKhFKXiLJjN06N4e6QnHh3Zz2zK4lu +hP6H5r2IciDn4K+9JV/rN+ZvZDUxVEQKgWKPZDBuZ4558y5ztr4PPLWXRUOVx4NWoDdVmultb2z s9napn4bf3Ycv+32p7sr7fZWa+fTzS1qt9o7ra3NFdZ6PJJmkJiYa8ZWvuN6wM16JOS1itXtdfsq 4DJkz4zQ5veg63eCVdbRbxN5qZ6yDRG7G77How1TKIWz6qyyAxNrHk9/GknOPMGO5Ujz6Y/Tfynm KYN/gQwlGl/L0FNXhkVcc9YjPH0eDPhTYNj7DeCkFAg2/YkpxlNqiQ6iT46SnJZIy9CVEfdBEbMc UCNI/Fg2Aw4EuvniBXA9F99xNuOwtlNPKVYDLGG4ZMNkOFQ6ILz/FmYdMnBWV9m+1CKWl9ywL3w1 wDIMLgWIwX0xhBDTA4m3vjsWAWcCVH0n3Ljrc2Mc8OcnmMxh7sLs8g1XabGeth+y2MiwWL76i+tD aR6MWw/dza3Wp4NfsQW0xEqPIpiXCh+86y3uy09gkw/eEY2j0RV3XZWE8a/bBG2JufvwTYa0/8Gr vUk40iqJHk5TpHzpTvL1UKJMaTzOzrS4lJ6APXBWi9A55rFuMGqdyDhtdKNhgwFp/ZeP8pXL/bmD TkOsFiae/sDslHzHYWoz41yLpLdWmKGD3lD6c/gvud7QSZj6mczbYBGh7kn4Y7IArkdJIMIYjuVt IpixJg4r4ORzUoNluHewqbSDxWb+iDtPoEV0xMn0/aXw6QxfjRjEBJfRZJfkFqz1i2DRPTirWOcL 2pMBSIwNw4HkMbjrO3cvoBkncxzTn7WEiHLBgRmwEUx/9hKffKgMp/8MJEzSCRSGRMTjcWUjMXrD lwN7F4TpOF/PiXXQ6XKtxYhEku3zFfcqA+6+eT32BlaeaqSGQ+sufQlxCvJuHH6MThWRktbdtHcY nHhCwq5ttVrAPkrgzA10w/Ph9QKhkphhhlB+lfAwlh7HPk2yI9xRsjZ3T0ksrU7w7KYQGMR16qad WCm/GY+x0zOVbau2ImbxWLAwCQaQpxqybJrFin22zlgPNyeyQXbJ/cQy4aJrbBSIwZdUIVDx0GOh iqUrB/6EySCCvTK4FOvOQ1c4+cGVz3Dyb4lKc/GJOKAwFE5/5FCki15/o9/vsdoFhkykdMx6Vjf6 wk20jCcbtgEfr9w3AmrS4xOh6w72dTtdoWM5lC6PxSHp85wpGn/DxazZ6Haa1ECqEthND9gSBDRw 37Y/ickdOxFPLzGZ730jJvnW50LL4aRr9Ylx31dXNkAekRux9w+NiBXdfqfbW16YLELUzUQF3lwY k+YrdBpJOs0JDkyE5ntiM9XEz2EaIrSZQSwjxWAlT5dF4KozSLFXKqnxfYgSeyrb5zEfkBavtpgb 7qUZzVNWO7/oPmXnSdi8gOk1u3miQ1peXx65jpcfnx7sOFqp2AsZq4IY7sElNAqqqnYyumLsr/3+ l52/vbDJVL9/SAbb3vyMKc1GMC5yiXAqiMke2a9JdT29ImzAUIHSMZlFMANT9cXrARzFHnD9Stm1 mefuRbOQ10B3pC7pZ6CXJq45eWX3yzrMEgCV9Aof75hkOJTXlUr1A0RVrR+NPbsXVqStr4RDD0RA WLjjckRbI9+JyiYVSXcthw5P34eedMX8Tjjw62qxu5qqPei1rnyGdddiBVoMuG8YAgFs+WosQrgq zXa33zBilg0mFDGucElwsrhibMhCBYbHRDMskK76aiyBifYqF5dK0VGb2LHYLfLK7nZlx7r7BA45 Mcn0B4qIYCKXaqZ9kBw05JiHfCR044NCTDWyUik08kWRnVCQTLMRG+A8mzZkkXcoDVSJkgtKMwL+ ToQ2hNIlukhCJ5WqTSDy0LtRtf5t+ncrbMNCQcps6Sfvxjo+oqVhtJTOyJWV8hTl4WqsSWR7PTlE 5CZevDQCw1/gTxEeW9MESKNAe4TcLitA2BAUBmSjBsUMZ9N/pGpns4Jl6bYN0chc5uqNRiK9ExuT G6OiBTXDD2ayVkNdhUJXxNsCA82ZsEGJOfZdijCEqBueNJHPJydoVypY3jDJoNji4tItpOMNHkVa XafTFZtG94/2G7aRluGEJu1/QTnzxSTKulhHGWRBT8Vm7p003bfL5gf6SNMSY88taPGED6L15BhX 1+Dz6xoqaagGkM/WV4jLDqWByKlEx/M0FMOyfqj0FdfI60bZ6MIhAu5OTYTIhFpk6HmCnuXni5Sl qyBVavRJb9INp3QDtrUvfGSDME277z6VTV2CmYQupHyJjOVc5NoG44AG2jmNwYxJ8jiTbv+kYRvP nh3tZ5d1M+xDceeL8qyWPX1+cN7rvFxeInBfHqBwb9CxIhFYzEj6L0+65wdnvYx/JCgQRV5BCIpN HSrvQ1vJrM2/G6w9fgqTS/whSczN8LdJEfVYhTJWy4x2s4IirWlsVRFkxxSRMB9w0ghP8d1D+Z4M Yi3EXnVGWdXJi6PBhH1MlQPqvf/t21cJKyu3LWf5Z9j33+3te95/W7tbm5vZ+y89/G6ttNq7O+1W +f77e8AH3n8X3Oky3oGX50bh//Kogvj14OYSX2xXbTw5Oz99Dvy2eqF80j5KJVTzC0rTrFeH+3uX iYmEyyJBLzgQ8aVYHkE3nXUe3Z3sEmcDeaM5S80ZrBH/ZlMGnhylJj2PtW2VsMrOzk57R92Xi8zS +47yp+9jhCYb6o0Ix2llstTk9CZ32dNnwVzez35fe2LIEb9tIZG1kbztkS6eIbG9Utqj/hlWW9Kp 83kiEfHDDxcc+QGobl/7yn2jkthK5/zg8OjkYkE2kKsY6fyZLE/6fWsqIw0debzL1/QxIS6kk3XT n9c8jrUc2PotzeDziVDFY6Sr7MHVl2X86+Ob+h/wSNjiymZdnfQ0yjpB4ezF9tF4vwpyxivUhtv6 kg8kLppoW9OCallxEI5kKNYcrGguDFVUaB9aCx6sWh9CNXTaPBMG7tLw+a1deoK8jsEc1+740D4L 51ikPTah9/AavY8ivRbTH3lg82xfxJSJixHmrbTC6X8CgZOyT1Jri3XCAr3nYJtVa+sf11+9qmH/ Xu0b3nzXaf75229azT98+wmG6zRbZdUn7doior0nm/UnW5h5Wr2PzpgsOUAditrY3KLr/k8Kv0Tj HbR9X3yhILpqGcaiDaTUvpvgm+Xd3miNKS2TMHsgEdcRFV8qp1sZeW1LxvvpvI1ygdq5Anlvhq7+ ZLOgrkfvzozPCnbvLkKTuwl9OFnJPFlzx8/dZihxlcfWytcyCQRZD1XfYTf7Rnf/lc0hwN39pX7z 6lJs96rTXdVxQQjm1hjMys1Krj/OeZr1gU6XLQzC92DiXmrvOm2vtv5J/QbmRQ6wCfTfcc7dLLlh zsDci0Z+lTYLYvE4odp8ILV3L62vXn2fUWwpBEnowvHOOvbphJDPjZm5BXUUVNXaR7CeBY0EG2f2 E2r91vhRaOLbo3145Nuj9IhSrwN5Jp86Efdkq16b45r69Xouo1X27OToq2cH0KwR5EOxQDAokJuG QPqilz6TqSSrvXkeGh4hGFRS1S1iYNZNf16nr7YfeDPO1s3HSsjBcnl8cPz5wfnpIfgMwKUICj5y 4zodrjGOfsDj/JnxMThMD1PDgsdiIG807QflpnKZbZwO6dbMbDptNBE6s0zA/jeHlye9o/4F2Nuf hDyQrv0kyxa+QTwGO94k9HFQwU3ez36bdBdGxAusMJ8PhC+8Z+dHBQvlm0IJJZRQQgkllFBCCSWU UEIJJZRQQgkllFBCCSWUUEIJJZRQQgkllFBCCSWUUEIJJZRQQgn/x/Bfxxv0fABQAAA= --0016367f92e6a19d180479d1aa27--

1 0

Re: (ITS#6411) Possible bug in Overlay pPolicy
by hyc＠symas.com 02 Dec '09

02 Dec '09

jarbas.junior(a)gmail.com wrote: > Full_Name: Jarbas Peixoto Junior > Version: 2.4.11 / 2.4.17 / 2.4.20 > OS: Gnu/Linux Debian > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (200.152.34.143) > > > Possible bug in Overlay pPolicy > > I have OpenLDAP installed via the Debian Lenny package functioning normally. > > Aiming to test the version of Debian Squeeze in the test machine installed > package slapd (2.4.17-2.1) with the same set of Debian Lenny (2.4.11). > > However, when testing the overlay pPolicy noticed that a wrong password > authentication, runs all objects in the ldap database, causing a "delay" that > does not exist in version Lenny. > > Below is some information that may be useful in detecting the problem: > > File: slapd.conf > ==================== > moduleload ppolicy > overlay ppolicy > ppolicy_default "cn=default,ou=LdapPassword,ou=Politicas,ou=Builtin,dc=previdencia,dc=gov,dc=br" > ppolicy_use_lockout > ==================== > > ldapsearch -LLL -x -H ldap://squeeze -b > ou=LdapPassword,ou=Politicas,ou=Builtin,dc=previdencia,dc=gov,dc=br > '(cn=default)' > dn: cn=default,ou=LdapPassword,ou=Politicas,ou=Builtin,dc=previdencia,dc=gov,d > c=br > objectClass: top > objectClass: device > objectClass: pwdPolicy > pwdAttribute: userPassword > description:: UG9sw610aWNhIGRlIFNlbmhhIERlZmF1bHQgcGFyYSB0b2RvcyB1c3XDoXJpb3M= > pwdAllowUserChange: TRUE > pwdFailureCountInterval: 3600 > pwdGraceAuthNLimit: 5 > pwdInHistory: 0 > pwdLockoutDuration: 60 > pwdMaxAge: 7776000 > pwdMinAge: 0 > pwdMinLength: 6 > pwdSafeModify: FALSE > pwdCheckQuality: 1 > pwdExpireWarning: 600 > cn: default > pwdMustChange: FALSE > pwdMaxFailure: 10 > pwdLockout: FALSE > > date ; ldapsearch -LLL -x -H ldap://squeeze -b > ou=usuarios,dc=previdencia,dc=gov,dc=br -D > uid=jarbas.peixoto,ou=pessoas,ou=usuarios,dc=previdencia,dc=gov,dc=br -w > wrong-password '(uid=jarbas.peixoto)' cn mail pwdFailureTime > pwdAccountLockedTime modifyTimeStamp ; date > Qua Dez 2 16:14:56 AMST 2009 > ldap_bind: Invalid credentials (49) > Qua Dez 2 16:15:36 AMST 2009 > > grep 'access_allowed: search access to' /var/log/debug | wc -l > 83714 > > The question is: why access all entries in LDAP? Don't know. This would have to be the result of a search operation, but there is no search code in ppolicy.c. Since ppolicy cannot be the culprit, we'll need to see the rest of your config to track down the issue. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6411) Possible bug in Overlay pPolicy
by quanah＠zimbra.com 02 Dec '09

02 Dec '09

--On Wednesday, December 02, 2009 8:25 PM +0000 jarbas.junior(a)gmail.com wrote: > Full_Name: Jarbas Peixoto Junior > Version: 2.4.11 / 2.4.17 / 2.4.20 > OS: Gnu/Linux Debian > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (200.152.34.143) ppolicy doesn't execute searches. Please provide your entire slapd.conf, minus passwords. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6408) 2.4.20 slapd hangs at 99% cpu when adding data
by hyc＠symas.com 02 Dec '09

02 Dec '09

andreas(a)canonical.com wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I also just uploaded a new attachment to the launchpad bug entry with the > contents of the slapd.d/ directory. Thanks, a fix was committed to HEAD yesterday. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs December 2009