openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#7390) slapschema crashes with rwm-rewriteMap slapd
by michael＠stroeder.com 14 Sep '12

14 Sep '12

Full_Name: Version: 2.4.32 OS: Debian Squeeze URL: Submission from: (NULL) (212.227.35.94) Config with the following lines works as expected but slapschema crashes no matter whether slapd is running or not: -------------------------------------------------------------------------- overlay rwm rwm-rewriteEngine on # rewrite map for (uid=foo) with DN of entry as result rwm-rewriteMap slapd uid2dn "ldap:///ou=um-demail?entryDN?sub?uid=" -------------------------------------------------------------------------- This is self-compiled OpenLDAP 2.4.32 on Debian Squeeze linked against OpenSSL and BDB 4.8.30. Example config will follow. Maybe I even can reproduce on another system and provide gdb output.

1 0

(ITS#7389) [PATCH] MozNSS: load certificates from certdb, fallback to PEM
by jvcelak＠redhat.com 14 Sep '12

14 Sep '12

Full_Name: Jan Vcelak Version: git master OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-20120914-moznss-load-certs-from-cer… Submission from: (NULL) (209.132.186.34) If TLS_CACERT pointed to a PEM file and TLS_CACERTDIR was set to NSS certificate database, the backend assumed that the certificate is always located in the certificate database. This assumption might be wrong. This patch makes the library to try to load the certificate from NSS database and fallback to PEM file if unsuccessfull. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

(ITS#7388) [PATCH] MozNSS: ignore certdb 'sql:' prefix when checking directory existence
by jvcelak＠redhat.com 14 Sep '12

14 Sep '12

Full_Name: Jan Vcelak Version: git master OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-20120914-moznss-ignore-certdb-sql-p… Submission from: (NULL) (209.132.186.34) Mozilla NSS certificate database in newer SQL format could not be used with OpenLDAP, because the 'sql:' prefix is not removed while checking for the existence of the directory. The attached patch resolves this problem. Steps to reproduce are described in Red Hat bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=857373 The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

(ITS#7387) submit a contribution
by philippe.eychart＠mail.pf 13 Sep '12

13 Sep '12

Full_Name: Philippe EYCHART Version: 2 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.50.70.54) My work is fully described and available here: http://homepage.gna.org/ldapcppei/miniHowto.en.html Regards. PE

1 0

Re: (ITS#7385) back_mdb ENOSPC error returned from mdb_node_add incorrectly
by marco＠schirrmeister.net 13 Sep '12

13 Sep '12

--Apple-Mail=_D316E30E-F1E5-480E-A47A-F4610B0C33C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 12, 2012, at 7:49 PM, hyc(a)symas.com wrote: > Frank.Swasey(a)uvm.edu wrote: >> Full_Name: Francis Swasey >> Version: 2.4.32 >> OS: RHEL6.3 64-bit >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (132.198.21.181) >>=20 >>=20 >> In exploring converting to back_mdb, I have discovered a problem = which results >> in the following symptoms: >=20 > Thanks for the report, fixed now in git master. I saw it is also merged into the RE24 branch. I tried today the latest commit from the RE24 branch and I did not see = the error anymore in the slapadd tool. Where I noticed the No space left = on device error before. But I'm seeing it now when I run the slapindex. Unfortunately I can't reproduce it with a test dataset that I created. Probably because I have not enough attributes that I could add to index = like on the real server. If I run slapindex a second time, again error. If I run slapindex a third time, no error. The data.mdb grew a little bit during the slapindex runs. =46rom about 710MB to 1,2GB. If I remove a few index options, slapindex runs through without a = problem. The output on the test server looks like below. [root@ds71 ~]# slapadd2.4 -b dc=3Dogilvy,dc=3Dcom -l all_slapcat.ldif=20 _#################### 100.00% eta none elapsed 05m26s spd = 596.0 k/s=20 Closing DB... [root@ds71 ~]#=20 [root@ds71 ~]# slapindex2.4=20 5051fea8 =3D> mdb_tool_entry_reindex: txn_commit failed: No space left = on device (28) [root@ds71 ~]#=20 [root@ds71 ~]# slapindex2.4=20 50520b10 =3D> mdb_tool_entry_reindex: txn_commit failed: No space left = on device (28) [root@ds71 ~]#=20 [root@ds71 ~]# slapindex2.4=20 [root@ds71 ~]#=20 Since you wrote ENOSPC can only be happen in 2 places, I thought it's = still related somehow. I'm a little bit clueless right now what else I can provide. If there is something that I can provide, then let me know please and I = try to provide it. -- Marco --Apple-Mail=_D316E30E-F1E5-480E-A47A-F4610B0C33C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; = "><br><div><div>On Sep 12, 2012, at 7:49 PM, <a = href=3D"mailto:hyc@symas.com">hyc(a)symas.com</a> wrote:</div><br = class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><span = class=3D"Apple-style-span" style=3D"border-collapse: separate; = font-family: Helvetica; font-style: normal; font-variant: normal; = font-weight: normal; letter-spacing: normal; line-height: normal; = orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: = none; white-space: normal; widows: 2; word-spacing: 0px; = -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: = 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = auto; -webkit-text-stroke-width: 0px; font-size: medium; "><a = href=3D"mailto:Frank.Swasey@uvm.edu">Frank.Swasey(a)uvm.edu</a><span = class=3D"Apple-converted-space"> </span>wrote:<br><blockquote = type=3D"cite">Full_Name: Francis Swasey<br></blockquote><blockquote = type=3D"cite">Version: 2.4.32<br></blockquote><blockquote = type=3D"cite">OS: RHEL6.3 64-bit<br></blockquote><blockquote = type=3D"cite">URL:<span class=3D"Apple-converted-space"> </span><a = href=3D"ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.org/incoming/= </a><br></blockquote><blockquote type=3D"cite">Submission from: (NULL) = (132.198.21.181)<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">In exploring = converting to back_mdb, I have discovered a problem which = results<br></blockquote><blockquote type=3D"cite">in the following = symptoms:<br></blockquote><br>Thanks for the report, fixed now in git = master.</span></blockquote></div><br><div>I saw it is also merged into = the RE24 branch.</div><div><br></div><div>I tried today the latest = commit from the RE24 branch and I did not see the error anymore in the = slapadd tool. Where I noticed the No space left on device = error before.</div><div>But I'm seeing it now when I run the = slapindex.</div><div><br></div><div>Unfortunately I can't reproduce it = with a test dataset that I created.</div><div>Probably because I have = not enough attributes that I could add to index like on the real = server.</div><div><br></div><div>If I run slapindex a second time, again = error.</div><div>If I run slapindex a third time, no = error.</div><div><br></div><div>The data.mdb grew a little bit during = the slapindex runs.</div><div>=46rom about 710MB to = 1,2GB.</div><div><br></div><div>If I remove a few index options, = slapindex runs through without a problem.</div><div><br></div><div>The = output on the test server looks like below.</div><div><div>[root@ds71 = ~]# slapadd2.4 -b dc=3Dogilvy,dc=3Dcom -l = all_slapcat.ldif </div><div>_#################### 100.00% eta =   none elapsed          05m26s spd 596.0 = k/s </div><div>Closing DB...</div><div>[root@ds71 = ~]# </div><div>[root@ds71 ~]# slapindex2.4 </div><div>5051fea8 = =3D> mdb_tool_entry_reindex: txn_commit failed: No space left on = device (28)</div><div>[root@ds71 ~]# </div><div>[root@ds71 ~]# = slapindex2.4 </div><div>50520b10 =3D> mdb_tool_entry_reindex: = txn_commit failed: No space left on device (28)</div><div>[root@ds71 = ~]# </div><div>[root@ds71 ~]# = slapindex2.4 </div><div>[root@ds71 = ~]# </div></div><div><br></div><div><br></div><div>Since you wrote = ENOSPC can only be happen in 2 places, I thought it's still related = somehow.</div><div>I'm a little bit clueless right now what else I can = provide.</div><div><br></div><div>If there is something that I can = provide, then let me know please and I try to provide = it.</div><div><br></div><div><br></div><div>--</div><div>Marco</div><div><= br></div><div><br></div></body></html>= --Apple-Mail=_D316E30E-F1E5-480E-A47A-F4610B0C33C6--

1 0

(ITS#7386) back-mdb slapindex grows DB without bound
by hyc＠OpenLDAP.org 12 Sep '12

12 Sep '12

Full_Name: Howard Chu Version: 2.4.32 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (37.19.96.255) Submitted by: hyc mdb_tool_entry_next() keeps a read-only cursor open, which prevents free pages from being reclaimed. Fix coming shortly.

1 0

Re: (ITS#7385) back_mdb ENOSPC error returned from mdb_node_add incorrectly
by hyc＠symas.com 12 Sep '12

12 Sep '12

Frank.Swasey(a)uvm.edu wrote: > Full_Name: Francis Swasey > Version: 2.4.32 > OS: RHEL6.3 64-bit > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (132.198.21.181) > > > In exploring converting to back_mdb, I have discovered a problem which results > in the following symptoms: Thanks for the report, fixed now in git master. > > ldapmodify with the following ldif: > > > dn: cn=COURSE-201209-94186,ou=Groups,dc=uvm,dc=edu > changetype: modify > delete: member > member: uid=pbirnbau,ou=people,dc=uvm,dc=edu > - > > fails with the following: > > ldap_modify: Other (e.g., implementation specific) error (80) > additional info: entry update failed > > syslog records the following: > > Sep 11 14:14:23 ldap6dev slapd[6456]: conn=1002 fd=21 ACCEPT from > IP=132.198.100.216:57847 (IP=0.0.0.0:636) > Sep 11 14:14:23 ldap6dev slapd[6456]: conn=1002 fd=21 TLS established > tls_ssf=256 ssf=256 > Sep 11 14:14:23 ldap6dev slapd[6456]: conn=1002 op=0 BIND > dn="cn=manager,dc=uvm,dc=edu" method=128 > Sep 11 14:14:23 ldap6dev slapd[6456]: conn=1002 op=0 BIND > dn="cn=manager,dc=uvm,dc=edu" mech=SIMPLE ssf=0 > Sep 11 14:14:23 ldap6dev slapd[6456]: conn=1002 op=0 RESULT tag=97 err=0 text= > Sep 11 14:14:23 ldap6dev slapd[6456]: conn=1002 op=1 MOD > dn="cn=COURSE-201209-94186,ou=Groups,dc=uvm,dc=edu" > Sep 11 14:14:23 ldap6dev slapd[6456]: conn=1002 op=1 MOD attr=member > Sep 11 14:14:23 ldap6dev slapd[6456]: slap_queue_csn: queing 0x7fdb6bffd0a0 > 20120911181423.401038Z#000000#000#000000 > Sep 11 14:14:23 ldap6dev slapd[6456]: mdb_id2entry_put: mdb_put failed: No space > left on device(28) "cn=course-201209-94186,ou=groups,dc=uvm,dc=edu" > Sep 11 14:14:23 ldap6dev slapd[6456]: conn=1002 op=1 RESULT tag=103 err=80 > text=entry update failed > Sep 11 14:14:23 ldap6dev slapd[6456]: slap_graduate_commit_csn: removing > 0x7fdb54002970 20120911181423.401038Z#000000#000#000000 > Sep 11 14:14:23 ldap6dev slapd[6456]: conn=1002 op=2 UNBIND > Sep 11 14:14:23 ldap6dev slapd[6456]: conn=1002 fd=21 closed > > gdb points to the return ENOSPC at line 4806 of mdb_node_add > > -- -- 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#7383) slapd startup issue with mdb
by michael＠stroeder.com 11 Sep '12

11 Sep '12

This is a cryptographically signed message in MIME format. --------------ms030701090404000009030901 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable marco(a)schirrmeister.net wrote: > Normally I also only added an index where I saw the candidate message i= n the log. Even when there's a warning about non-indexed searches in syslog I won't = index all attributes mentioned in the message without further analyzing the fil= ter. IMHO there's no point to index additional attributes if one of the indexe= d attributes already narrows the set of search candidates to one. One examp= le are filters with (uid=3Dname) with eq-index on uid. Ciao, Michael. --------------ms030701090404000009030901 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCC BT8wggQnoAMCAQICDwCmSwABAAIAivjZQ8SBvzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQG EwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBM MSBDQSBJWDAeFw0xMjA2MDYxOTAyMTZaFw0xMzA2MDcxOTAyMTZaMCgxCzAJBgNVBAYTAkRF MRkwFwYDVQQDDBBNaWNoYWVsIFN0csO2ZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxXZGav40rnGNLxEggBW94MILWHlfC8a23Jew5U1gPlfRTXOjjzmoaZ1uCyGdgF6M VvuO9T1aTQNGH+OdeGe3P7Tfc/NsLJFJ2wtd8blvhmodUgse2eypiWjNOd4gZuhalBhgsQ0K b5D6/1foghII4E264iZlJ7AJ+UYcO+GxvFWT0YMTbLckgDkZk7c3qwTozdhYvXarvqx+8Ou/ kuxpQQhac/ebzxpu0N+RHSf2KIUS0g0tEGnPtGv6iL+9QNHc4JKo9Y9KKVw3tQy+Re+FQLxB 1fPE5F+qxuD3AUENpOwkMsqWLM94ohtx3CFqLpxfUPrnKFLAHOhHEbByYGvFPwIDAQABo4IC EDCCAgwwgaUGCCsGAQUFBwEBBIGYMIGVMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0 Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9JWC5jcnQw QAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLml4LnRjY2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1 c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAU6bgoHUbP/M34TpvF7ktg69g7P9EwDAYDVR0TAQH/ BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3 LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgTwMB0GA1UdDgQWBBS2 KAWfTfgJ/JQ63qLGwTXYLnI+LzBiBgNVHR8EWzBZMFegVaBThlFodHRwOi8vY3JsLml4LnRj Y2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX0NsYXNzMV9M MV9DQV9JWC5jcmwwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBwYK KwYBBAGCNxQCAjAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAQ3bvVUpEq+cQrLpcogyt5BJNk/WvUvOHqhzyj28M9pg9hcDl1+MYl5qqj6tR GSTLPQZyf287pcmbMwbcTGZO/gbW9v7RYcut6RauWdwKMCUmKC3J4fVfDq9ZETA2WOV68ef4 B3Gzdhghsbp3Rhp5dDmrCVKAHlafm6ZwJrEQ9P76fxnQZzRLgeKpZep5ePH5YHUB3+YaOQvJ FG0bOXvfHhRiRG7/HW2G+yDgjHSxDz8AFzMWL/RFePqZ4pn6T/SM/qU6WEpW39MWyJNoH/Kx QDYK8gGYuesn1ciMCTnjrvZQj0fonGTO4SfWekJRkuGrJ7dYSZRjYbDcWBBkdFLWzzCCBdgw ggTAoAMCAQICDgboAAEAAkqWLSQM/sXJMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNVBAYTAkRF MRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSQwIgYDVQQLExtUQyBUcnVzdENlbnRl ciBVbml2ZXJzYWwgQ0ExJjAkBgNVBAMTHVRDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQSBJ MB4XDTA5MTEwMzE0MDgxOVoXDTI1MTIzMTIxNTk1OVowfDELMAkGA1UEBhMCREUxHDAaBgNV BAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75pBuz2Lp6QuqthDVR+V8XSsncZpozVVt 5KLv5P7yemMRwleKyH3PjmYfZUVL64Biab1GjovFblqVGCrep/EfdRonq20yU+P7TVhiLP8Z 5cegDZotIYhZhM0d8cPIij6w5d4IJM/8QCy6QSOUu4ASiTVItoYE4AFPjLqpmPwcie0fiqHH hpgmHnJla/7PZdkMZEsaCfVDEWBmJuMzVprJPT40anjG5VBLyM2I5DlsUCaeQCy2O3w3sqf1 3dyzUcv03IICuNc63towXA31Qt0TaVNU6YAmQjMepdfMbspmCZ+G8D2+xophEPPR/1vkstst smUMqX0XrLonTUJczglPAgMBAAGjggJZMIICVTCBmgYIKwYBBQUHAQEEgY0wgYowUgYIKwYB BQUHMAKGRmh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2VydHNlcnZpY2VzL2NhY2VydHMv dGNfdW5pdmVyc2FsX3Jvb3RfSS5jcnQwNAYIKwYBBQUHMAGGKGh0dHA6Ly9vY3NwLnRjdW5p dmVyc2FsLUkudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUkqR1LKSevoFE63n8isWVpesQ dXMwEgYDVR0TAQH/BAgwBgEB/wIBADBSBgNVHSAESzBJMAYGBFUdIAAwPwYJKoIUACwBAQEB MDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMIH9BgNVHR8E gfUwgfIwge+ggeyggemGRmh0dHA6Ly9jcmwudGN1bml2ZXJzYWwtSS50cnVzdGNlbnRlci5k ZS9jcmwvdjIvdGNfdW5pdmVyc2FsX3Jvb3RfSS5jcmyGgZ5sZGFwOi8vd3d3LnRydXN0Y2Vu dGVyLmRlL0NOPVRDJTIwVHJ1c3RDZW50ZXIlMjBVbml2ZXJzYWwlMjBDQSUyMEksTz1UQyUy MFRydXN0Q2VudGVyJTIwR21iSCxPVT1yb290Y2VydHMsREM9dHJ1c3RjZW50ZXIsREM9ZGU/ Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlPzANBgkqhkiG9w0BAQUFAAOCAQEAOcjE m+6+mO5Icm+N53G2DpCM07LBFSGoRpBoX0oE8TrJaIQh2KXmBHVdn9LU8kt3QzLclctgvwJV 0KwcsMUUl5tlCsMPpR3s2Ek5lbWpvvr0HqtW56blAQiINV9nBd1EJFASIkRjefGbV2nOq9Yz UU+N8HA7jq1ROhd/NZZraGhjthwKyfjfHV7PKxGlY+3M0MbTIG+q/GhIfm0euDpFqhKG88e9 ALXr/uoSn3MzeOcoOWjTpW3adtFO4VWVgKbgG7jNrFbvRVlHmFLbOm4msjE5aXWxLiTwpJ2X iF4zKca1vAdAOgw9us90jEtOeiH6GzjNxEMvb7TfeO6Zkuc6HDGCA84wggPKAgEBMIGPMHwx CzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxU QyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBD bGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wCQYFKw4DAhoFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwOTExMjAxOTU1WjAjBgkq hkiG9w0BCQQxFgQU+0E5Hxed6F+8Fdmsr2y1whu833MwbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBoAYJKwYBBAGCNxAEMYGSMIGP MHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQL ExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRl ciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wgaIGCyqGSIb3DQEJEAILMYGS oIGPMHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYD VQQLExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENl bnRlciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wDQYJKoZIhvcNAQEBBQAE ggEAPPc18RzIfVnUVnXD2xBJwbbny8UE6R9+LKbdLJlPCmiKuq7iUlKvLLTJdI15gXDrWokI NH9COp2ZbUrSjmJGYufpH4lx+FXGG75YVgnxyaFyeL3WA9v/G6reiu2UT3971v6eFEMqDEjB DaP3aJ1sme86uYuRQSTyfzC2EPjww1gS5fXgOhKlEtbbdg5ltgZP6osdKX+qr0ueOBmiEs1g LyGktHeq8LAFxnWvNh50tLuLutr/vnIdnsLlw888GQSXtUQl3ugsI0q+AUv6bSmrGcImbvXK ZqeTa6JMqBxPQk5u56dCBqujjvDSCXKG1uan7packG1NeyGVZ/anPyAxhQAAAAAAAA== --------------ms030701090404000009030901--

1 0

Re: (ITS#7383) slapd startup issue with mdb
by marco＠schirrmeister.net 11 Sep '12

11 Sep '12

On Sep 11, 2012, at 8:14 PM, hyc(a)symas.com wrote: > marco(a)schirrmeister.net wrote: >> Full_Name: Marco Schirrmeister >> Version: 2.4.32 >> OS: CentOS6 x86_64 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (84.59.6.160) >> >> >> I'm testing mdb since the last versions with our dataset. >> If I use my production config slapd does't start up. >> >> The following is in the log file. >> >> Sep 11 16:48:37 ds71 slapd2.4[8349]: @(#) $OpenLDAP: slapd 2.4.32 (Sep 6 2012 >> 13:50:54) $#012#011mschirrmeister@defrsl6bh2.ogilvy.com:/home/mschirrmeister/rpmbuild/BUILD/openldap-2.4.32/servers/slapd >> Sep 11 16:48:37 ds71 slapd2.4[8349]: mdb_attr_dbs: database "dc=ogilvy,dc=com": >> mdb_open(omgPublishDate) failed: Too many open files in system (23). >> Sep 11 16:48:37 ds71 slapd2.4[8349]: backend_startup_one (type=mdb, >> suffix="dc=ogilvy,dc=com"): bi_db_open failed! (23) >> Sep 11 16:48:37 ds71 slapd2.4[8349]: slapd stopped. >> >> My /etc/security/limits.conf file has already the following entries. >> * soft nofile 65535 >> * hard nofile 65535 >> >> No matter what I try on the OS side, the error above comes up. >> >> I have about 130 index attributes in my config. Looks to me that this is the >> problem. >> If I comment 8 attributes, slapd starts fine. > > There is a hardcoded limit of 128. This same limit exists in back-bdb/hdb. You > can just edit back-mdb.h (or back-bdb.h) to raise the limit. Change the > MDB_INDICES (or BDB_INDICES) definition. > > Congratulations, no one else has hit this limit in back-bdb in the past 12 > years. Seems likely to me that you're indexing too much, but there's not > enough information here to judge. Ok, thanks for that information. I will try to increase it. But it's weird that there is no error with bdb on startup. I looked at my back-bdb.h and it has 128. I'm definitely over this number. You are right, some are too much and I could maybe remove a few indexes. Some defaults. But our own schema extension is quite long and many of those attributes are used in searches from the various apps. Normally I also only added an index where I saw the candidate message in the log. So this is then also no bug and we can close it. Sorry for being to fast with an ITS. -- Marco

1 0

(ITS#7385) back_mdb ENOSPC error returned from mdb_node_add incorrectly
by Frank.Swasey＠uvm.edu 11 Sep '12

11 Sep '12

Full_Name: Francis Swasey Version: 2.4.32 OS: RHEL6.3 64-bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (132.198.21.181) In exploring converting to back_mdb, I have discovered a problem which results in the following symptoms: ldapmodify with the following ldif: dn: cn=COURSE-201209-94186,ou=Groups,dc=uvm,dc=edu changetype: modify delete: member member: uid=pbirnbau,ou=people,dc=uvm,dc=edu - fails with the following: ldap_modify: Other (e.g., implementation specific) error (80) additional info: entry update failed syslog records the following: Sep 11 14:14:23 ldap6dev slapd[6456]: conn=1002 fd=21 ACCEPT from IP=132.198.100.216:57847 (IP=0.0.0.0:636) Sep 11 14:14:23 ldap6dev slapd[6456]: conn=1002 fd=21 TLS established tls_ssf=256 ssf=256 Sep 11 14:14:23 ldap6dev slapd[6456]: conn=1002 op=0 BIND dn="cn=manager,dc=uvm,dc=edu" method=128 Sep 11 14:14:23 ldap6dev slapd[6456]: conn=1002 op=0 BIND dn="cn=manager,dc=uvm,dc=edu" mech=SIMPLE ssf=0 Sep 11 14:14:23 ldap6dev slapd[6456]: conn=1002 op=0 RESULT tag=97 err=0 text= Sep 11 14:14:23 ldap6dev slapd[6456]: conn=1002 op=1 MOD dn="cn=COURSE-201209-94186,ou=Groups,dc=uvm,dc=edu" Sep 11 14:14:23 ldap6dev slapd[6456]: conn=1002 op=1 MOD attr=member Sep 11 14:14:23 ldap6dev slapd[6456]: slap_queue_csn: queing 0x7fdb6bffd0a0 20120911181423.401038Z#000000#000#000000 Sep 11 14:14:23 ldap6dev slapd[6456]: mdb_id2entry_put: mdb_put failed: No space left on device(28) "cn=course-201209-94186,ou=groups,dc=uvm,dc=edu" Sep 11 14:14:23 ldap6dev slapd[6456]: conn=1002 op=1 RESULT tag=103 err=80 text=entry update failed Sep 11 14:14:23 ldap6dev slapd[6456]: slap_graduate_commit_csn: removing 0x7fdb54002970 20120911181423.401038Z#000000#000#000000 Sep 11 14:14:23 ldap6dev slapd[6456]: conn=1002 op=2 UNBIND Sep 11 14:14:23 ldap6dev slapd[6456]: conn=1002 fd=21 closed gdb points to the return ENOSPC at line 4806 of mdb_node_add

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