openldap-bugs

openldap-bugs@openldap.org

1 participants
21003 discussions

Re: (ITS#7515) Nested liblmdb transaction bugs
by h.b.furuseth＠usit.uio.no 19 Feb '13

19 Feb '13

mdb_txn_commit(nested transaction) has more problems: - If the commit fails, it may modify the parent txn anyway. - The code to merge dirty_list into the parent is strange. I think it assumes that the dirty pages are either dirty in the parent, or have a higher page numbers than the parent's dirty pages parent. That can be wrong if a new freelist entry was used, or a "multi-page page". Branch mdb/tweaks2 in <http://folk.uio.no/hbf/OpenLDAP/openldap.git> includes a suggested fix, but could use some review - and testing by someone who actually uses nested txns. -- Hallvard

1 0

Re: (ITS#7525) Bad conversion to cn=config format - another issue
by francesco.policastro＠selex-es.com 18 Feb '13

18 Feb '13

--=_mixed 0029F46EC1257B17_= Content-Type: multipart/alternative; boundary="=_alternative 0029F470C1257B17_=" --=_alternative 0029F470C1257B17_= Content-Type: text/plain; charset="US-ASCII" Hi, I am going on with my configuration and I realized that the subtree-include directives I use in my meta backend are not converted at all to cn=config. I cannot find them in cn=config tree. I don't know if you decide to open a new ITS or not. My slapd.conf is attached below. The slapd version is 2.4.33 as patched after ITS#7525 (openldap-648d28f.tar.gz) Did anyone use subtrees with cn=config? Francesco Policastro --=_alternative 0029F470C1257B17_= Content-Type: text/html; charset="US-ASCII" Hi, I am going on with my configuration and I realized that the subtree-include directives I use in my meta backend are not converted at all to cn=config. I cannot find them in cn=config tree. I don't know if you decide to open a new ITS or not. My slapd.conf is attached below. The slapd version is 2.4.33 as patched after ITS#7525 ( <form action=http://www.openldap.org/its/index.cgi/Software%20Bugs method=post>openldap-648d28f.tar.gz</form>)   Did anyone use subtrees with cn=config? Francesco Policastro --=_alternative 0029F470C1257B17_=-- --=_mixed 0029F46EC1257B17_= Content-Type: application/octet-stream; name="slapd.conf" Content-Disposition: attachment; filename="slapd.conf" Content-Transfer-Encoding: base64 IwojIFNlZSBzbGFwZC5jb25mKDUpIGZvciBkZXRhaWxzIG9uIGNvbmZpZ3VyYXRpb24gb3B0aW9u cy4KIyBUaGlzIGZpbGUgc2hvdWxkIE5PVCBiZSB3b3JsZCByZWFkYWJsZS4KIwppbmNsdWRlCQkv dXNyL2xvY2FsL2V0Yy9vcGVubGRhcC9zY2hlbWEvY29yZS5zY2hlbWEKaW5jbHVkZQkJL3Vzci9s b2NhbC9ldGMvb3BlbmxkYXAvc2NoZW1hL2Nvc2luZS5zY2hlbWEKaW5jbHVkZQkJL3Vzci9sb2Nh bC9ldGMvb3BlbmxkYXAvc2NoZW1hL2luZXRvcmdwZXJzb24uc2NoZW1hCmluY2x1ZGUJCS91c3Iv bG9jYWwvZXRjL29wZW5sZGFwL3NjaGVtYS9keW5ncm91cC5zY2hlbWEKCmF0dHJpYnV0ZXR5cGUg KCAxLjIuODQwLjExMzU1Ni4xLjQuMjIxIE5BTUUgJ3NBTUFjY291bnROYW1lJyAKCUVRVUFMSVRZ IGNhc2VFeGFjdE1hdGNoIAoJU1lOVEFYICcxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4xNScg U0lOR0xFLVZBTFVFICkKCmF0dHJpYnV0ZXR5cGUgKCAxLjIuODQwLjExMzU1Ni4xLjQuMzUgTkFN RSAnZW1wbG95ZWVJRCcgCglFUVVBTElUWSBjYXNlRXhhY3RNYXRjaCAKCVNZTlRBWCAnMS4zLjYu MS40LjEuMTQ2Ni4xMTUuMTIxLjEuMTUnIFNJTkdMRS1WQUxVRSApCgphdHRyaWJ1dGV0eXBlICgg MS4yLjg0MC4xMTM1NTYuMS40LjggTkFNRSAndXNlckFjY291bnRDb250cm9sJyAKCUVRVUFMSVRZ IGludGVnZXJNYXRjaCAKCVNZTlRBWCAnMS4zLjYuMS40LjEuMTQ2Ni4xMTUuMTIxLjEuMjcnIFNJ TkdMRS1WQUxVRSApCgphdHRyaWJ1dGV0eXBlICggMS4yLjg0MC4xMTM1NTYuMS40LjY1NiBOQU1F ICd1c2VyUHJpbmNpcGFsTmFtZScKCUVRVUFMSVRZIGNhc2VFeGFjdE1hdGNoIAoJU1lOVEFYICcx LjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4xNScgU0lOR0xFLVZBTFVFICkKCgojIEFsbG93IExE QVB2MiBjbGllbnQgY29ubmVjdGlvbnMuICBUaGlzIGlzIE5PVCB0aGUgZGVmYXVsdC4KYWxsb3cg YmluZF92MgoKcGlkZmlsZQkJL3Zhci9ydW4vc2xhcGQucGlkCgojIC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0KYmFja2VuZAkJbWV0YQpiYWNrZW5kCQloZGIKIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t CgojIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KZGF0YWJhc2UJbWV0YQojIC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0Kc3VmZml4CQkiZGM9bmV3Y28sZGM9Y29tIgpyZWFkb25seQlvbgpyb290ZG4JCSJj bj1MZGFwQmluZFVzZXIsZGM9bmV3Y28sZGM9Y29tIgpyb290cHcJCXNlY3JldDEKCiMgbm8gYW5v bnltb3VzIGJpbmQKcmVxdWlyZSBhdXRoYwpjb25uLXR0bCAyNW0KCmRuY2FjaGUtdHRsIGRpc2Fi bGVkCgphY2Nlc3MgdG8gKgogYnkgKiBub25lCgojIGZpcnN0IGRvbWFpbgoKdXJpICJsZGFwOi8v c2VydmVyMS5pdC5kb21haW4xLmNvbS9kYz1maXJzdCxkYz1uZXdjbyxkYz1jb20iCmlkYXNzZXJ0 LWJpbmQgYmluZG1ldGhvZD1zaW1wbGUgYmluZGRuPSJjbj1MREFQIFVzZXIsb3U9SVRTdGFmZixk Yz1pdCxkYz1kb21haW4xLGRjPWNvbSIgY3JlZGVudGlhbHM9c2VjcmV0MgpjaGFzZS1yZWZlcnJh bHMgbm8KcmViaW5kLWFzLXVzZXIgdHJ1ZQptYXAgb2JqZWN0Y2xhc3MgZ3JvdXBPZk5hbWVzICoK bWFwIG9iamVjdGNsYXNzIHBlcnNvbiAqCnN1ZmZpeG1hc3NhZ2UgImRjPWZpcnN0LGRjPW5ld2Nv LGRjPWNvbSIgImRjPWl0LGRjPWRvbWFpbjEsZGM9Y29tIgpzdWJ0cmVlLWluY2x1ZGUgIm91PUFw cGxpY2F0aW9ucyxvdT1Hcm91cHMgU2hhcmVkLGRjPWZpcnN0LGRjPW5ld2NvLGRjPWNvbSIKc3Vi dHJlZS1pbmNsdWRlICJvdT1Vc2VycyxvdT0xc3QtbG9jYXRpb24sZGM9Zmlyc3QsZGM9bmV3Y28s ZGM9Y29tIgpzdWJ0cmVlLWluY2x1ZGUgIm91PVVzZXJzLG91PTJuZC1sb2NhdGlvbixkYz1maXJz dCxkYz1uZXdjbyxkYz1jb20iCnN1YnRyZWUtaW5jbHVkZSAib3U9VXNlcnMsb3U9M3JkLWxvY2F0 aW9uLGRjPWZpcnN0LGRjPW5ld2NvLGRjPWNvbSIKCiMgbWFwIHZpc2libGUgYXR0cmlidXRlcyB0 byBtYXRjaGluZyBhdHRyaWJ1dGVzIG9uIGJhY2tlbmQKbWFwIGF0dHJpYnV0ZSBkaXN0aW5ndWlz aGVkTmFtZSAqCm1hcCBhdHRyaWJ1dGUgZ2l2ZW5OYW1lICoKbWFwIGF0dHJpYnV0ZSBkZXNjcmlw dGlvbiAqCm1hcCBhdHRyaWJ1dGUgc24gKgptYXAgYXR0cmlidXRlIGNuICoKbWFwIGF0dHJpYnV0 ZSBtYWlsICoKbWFwIGF0dHJpYnV0ZSBzYW1BY2NvdW50TmFtZSAqCm1hcCBhdHRyaWJ1dGUgdXNl ckFjY291bnRDb250cm9sICoKbWFwIGF0dHJpYnV0ZSBlbXBsb3llZUlEICoKbWFwIGF0dHJpYnV0 ZSB1c2VyUHJpbmNpcGFsTmFtZSAqCgojIG1hcCBldmVyeXRoaW5nIGVsc2UgdG8gbnVsbAptYXAg YXR0cmlidXRlICoKCiMgc2Vjb25kIGRvbWFpbgoKdXJpICJsZGFwOi8vc2VydmVyMi5kb21haW4y Lm5ldC9vdT1vcmdhbml6YXRpb25hbFVuaXQsZGM9c2Vjb25kLGRjPW5ld2NvLGRjPWNvbSIKaWRh c3NlcnQtYmluZCBiaW5kbWV0aG9kPXNpbXBsZSBiaW5kZG49ImNuPWxkYXAtMixjbj1Vc2Vycyxk Yz1kb21haW4yLGRjPW5ldCIgY3JlZGVudGlhbHM9c2VjcmV0MwpjaGFzZS1yZWZlcnJhbHMgbm8K cmViaW5kLWFzLXVzZXIgdHJ1ZQptYXAgb2JqZWN0Y2xhc3MgZ3JvdXBPZk5hbWVzICoKbWFwIG9i amVjdGNsYXNzIHBlcnNvbiAqCnN1ZmZpeG1hc3NhZ2UgImRjPXNlY29uZCxkYz1uZXdjbyxkYz1j b20iICJkYz1kb21haW4yLGRjPW5ldCIKc3VidHJlZS1pbmNsdWRlICJvdT1Vc2VycyxvdT0xc3Qt bG9jYXRpb24sb3U9b3JnYW5pemF0aW9uYWxVbml0LGRjPXNlY29uZCxkYz1uZXdjbyxkYz1jb20i CnN1YnRyZWUtaW5jbHVkZSAib3U9TXktb3Usb3U9MXN0LWxvY2F0aW9uLG91PW9yZ2FuaXphdGlv bmFsVW5pdCxkYz1zZWNvbmQsZGM9bmV3Y28sZGM9Y29tIgpzdWJ0cmVlLWluY2x1ZGUgIm91PVJl bW90ZSBTaXRlcyxvdT1vcmdhbml6YXRpb25hbFVuaXQsZGM9c2Vjb25kLGRjPW5ld2NvLGRjPWNv bSIKCiMgbWFwIHZpc2libGUgYXR0cmlidXRlcyB0byBtYXRjaGluZyBhdHRyaWJ1dGVzIG9uIGJh Y2tlbmQKbWFwIGF0dHJpYnV0ZSBkaXN0aW5ndWlzaGVkTmFtZSAqCm1hcCBhdHRyaWJ1dGUgZ2l2 ZW5OYW1lICoKbWFwIGF0dHJpYnV0ZSBkZXNjcmlwdGlvbiAqCm1hcCBhdHRyaWJ1dGUgc24gKgpt YXAgYXR0cmlidXRlIGNuICoKbWFwIGF0dHJpYnV0ZSBtYWlsICoKbWFwIGF0dHJpYnV0ZSBzYW1B Y2NvdW50TmFtZSAqCm1hcCBhdHRyaWJ1dGUgdXNlckFjY291bnRDb250cm9sICoKbWFwIGF0dHJp YnV0ZSBlbXBsb3llZUlEIHBhZ2VyCm1hcCBhdHRyaWJ1dGUgdXNlclByaW5jaXBhbE5hbWUgKgoK IyBtYXAgZXZlcnl0aGluZyBlbHNlIHRvIG51bGwKbWFwIGF0dHJpYnV0ZSAqCgojIC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0KZGF0YWJhc2UJaGRiCiMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpzdWZm aXgJCWRjPWRvbWFpbi1ncm91cHMsZGM9Y29tIgpyb290ZG4JCSJjbj1ncm91cHNSb290LGRjPWRv bWFpbi1ncm91cHMsZGM9Y29tIgpyb290cHcJCXNlY3JldDQKb3ZlcmxheQkJZHlubGlzdAoKZHlu bGlzdC1hdHRyc2V0IGdyb3VwT2ZVUkxzIG1lbWJlclVSTCBtZW1iZXIKZGlyZWN0b3J5CS91c3Iv bG9jYWwvdmFyL29wZW5sZGFwLWRhdGEKCg== --=_mixed 0029F46EC1257B17_=--

1 0

Re: (ITS#7515) Nested liblmdb transaction bugs
by h.b.furuseth＠usit.uio.no 18 Feb '13

18 Feb '13

I wrote: >> Can't use a DBI from an aborted child txn, unlike aborted main txn: > (...) > Well, closing the DBI in mdb_txn_abort() caused problems. A fix > in the opposite direction is easy, if we want DBIs to work that > way: mdb_env_open() can open the DBI in any parent txns too. To get more consistent behavior, if that wasn't clear: Any parent txn will receive the DBI independently of commit/abort, just like the MDB_env. Future children of a preexisting txn still differ, which is probably for the best. Changing that would take locking. -- Hallvard

1 0

Re: (ITS#7515) Nested liblmdb transaction bugs
by h.b.furuseth＠usit.uio.no 18 Feb '13

18 Feb '13

I wrote: > Fixed in mdb.master, except: > >> Can't use a DBI from an aborted child txn, unlike aborted main txn: Yet it may be possible to use the DBI in the parent txn if mdb_dbi_open() reused a closed DBI - but it may have the wrong flags and cmp functions, or also wrong MDB_db if the close happened after txn_begin. > Fixing this caused problems and got reverted. > The DBI is available to next non-nested txn Well, closing the DBI in mdb_txn_abort() caused problems. A fix in the opposite direction is easy, if we want DBIs to work that way: mdb_env_open() can open the DBI in any parent txns too. ldbm.h: "[The database handle] denotes the name and parameters of a database, independently of whether such a database exists. It will not exist if the transaction which created it aborted, nor if another process deleted it. Preexisting transactions, other than the current transaction and any parents, must not use the new handle. Nor must their children." -- Hallvard

1 0

Re: (ITS#7525) Bad conversion to cn=config format - solved
by francesco.policastro＠selex-es.com 18 Feb '13

18 Feb '13

--=_alternative 0039EFE9C1257B16_= Content-Type: text/plain; charset="US-ASCII" My suggestion is to modify the test suite to include an uri containing spaces, just to avoid regressions. Ciao, Francesco Policastro --=_alternative 0039EFE9C1257B16_= Content-Type: text/html; charset="US-ASCII" My suggestion is to modify the test suite to include an uri containing spaces, just to avoid regressions. Ciao, Francesco Policastro --=_alternative 0039EFE9C1257B16_=--

1 0

Re: (ITS#7517) mdb_dbi_close(dbi updated in existing txn) breaks
by h.b.furuseth＠usit.uio.no 17 Feb '13

17 Feb '13

Related: If a DB is dropped (and thus the DBI closed) in a txn which has modified it, mdb_txn_commit attempted to save the DB. This could corrupt another DB if mdb_dbi_open() in another thread had reused the DBI. This is now fixed in mdb.master. -- Hallvard

1 0

Re: (ITS#7515) Nested liblmdb transaction bugs
by h.b.furuseth＠usit.uio.no 16 Feb '13

16 Feb '13

> Here are some crashes with nested liblmdb transactions. Fixed in mdb.master, except: > Can't use a DBI from an aborted child txn, unlike aborted main txn: > > $ ./bug R[cp] # Create a named DB and put an item there > $ ./bug [[o}g] # Open that DB in a child, abort, use the DBI > 40: mdb_get(txn, dbi, &key, &rdata): Invalid argument Fixing this caused problems and got reverted. The DBI is available to next non-nested txn: $ ./bug [[o}}[g] # Open DB in child, abort both txns, use DBI in new txn -- Hallvard

1 0

(ITS#7528) ldapadd not working while adding attribute having long list of values
by omkar＠mithi.com 15 Feb '13

15 Feb '13

Full_Name: Omkar Phadke Version: 2.4.30 OS: Red Hat Enterprise Linux Server release 6.0 (Santiago) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (115.111.211.142) I am trying to add bellow ldif file. Command ldapadd -d -1 -cxv -D "cn=Manager,dc=mithibo" -f /root/TestSmall.ldif -w "$LDAP_ROOT_PASSWD" > /root/log_failed.txt 2>&1 I get error ldap_add: Undefined attribute type (17) additional info: ame: attribute type undefined ldapadd exe is not present separately, in folder /usr/local/openldap/bin/ ldapadd is linked with ldapmodify Actually homecountry attribute's value is list of countries and it is very long bellow i give ldif file. but if i extract ldapmodify file from older version 2.4.23 and copied to /usr/local/openldap/bin/ then above command executes successfully. ---------------------------------------------------------------------------------- Ldif file /root/TestSmall.ldif contents -- dn: cn=homecountry,ou=boproperty,ou=user,cn=template.int,ou=domains,cn=enterprise,o=enterprise, dc=mithibo cn:homecountry objectClass: top objectClass: person objectClass: organizationalPerson objectClass: mithiBO admincompulsary: f admineditable: t allowblankvalue: t compulsary: f default: India record: user description: Home country dircontainer: cd editable: t encodedecode: f inheritsvalue: f label: Home country ldapstorage: homecountry list: Afghanistan:Afghanistan,Albania:Albania,Algeria:Algeria,American:American,Samoa:Samoa,Andorra:Andorra,Angola:Angola,Anguilla:Anguilla,Antarctica:Antarctica,Antigua and Barbuda:Antigua and Barbuda,Argentina:Argentina,Armenia:Armenia,Aruba:Aruba,Australia:Australia,Austria:Austria,Azerbaijan:Azerbaijan,Bahamas:Bahamas,Bahrain:Bahrain,Bangladesh:Bangladesh,Barbados:Barbados,Belarus:Belarus,Belgium:Belgium,Belize:Belize,Benin:Benin,Bermuda:Bermuda,Bhutan:Bhutan,Bolivia:Bolivia,Bosnia and Herzegovina:Bosnia and Herzegovina,Botswana:Botswana,Bouvet Island:Bouvet Island,Brazil:Brazil,British Indian Ocean Territory:British Indian Ocean Territory,British Virgin Islands:British Virgin Islands,Brunei:Brunei,Bulgaria:Bulgaria,Burkina Faso:Burkina Faso,Burundi:Burundi,Cambodia:Cambodia,Cameroon:Cameroon,CanadaCape:CanadaCape,Verde:Verde,Cayman Islands:Cayman Islands,Central:Central,African:African,Republic:Republic,Chad:Chad,Chile:Chile,China:China,Christmas Island:Christmas Island,Cocos Islands:Cocos Islands,Colombia:Colombia,Comoros:Comoros,Congo:Congo,Cook Islands:Cook Islands,Costa Rica:Costa Rica,Croatia:Croatia,Cuba:Cuba,Cyprus:Cyprus,Czech Republic:Czech Republic,Denmark:Denmark,Djibouti:Djibouti,Dominica:Dominica,Dominican Republic:Dominican Republic,East Timor:East Timor,Ecuador:Ecuador,Egypt:Egypt,El Salvador:El Salvador,Equatorial Guinea:Equatorial Guinea,Eritrea:Eritrea,Estonia:Estonia,Ethiopia:Ethiopia,Falkland Islands:Falkland Islands,Faroe Islands:Faroe Islands,Fiji:Fiji,Finland:Finland,France:France,French Guiana:French Guiana,French Polynesia:French Polynesia,French Southern Territories:French Southern Territories,Gabon:Gabon,Gambia:Gambia,Georgia:Georgia,Germany:Germany,Ghana:Ghana,Gibraltar:Gibraltar,Greece:Greece,Greenland:Greenland,Grenada:Grenada,Guadeloupe:Guadeloupe,Guam:Guam,Guatemala:Guatemala,Guinea:Guinea,Guinea-Bissau:Guinea-Bissau,Guyana:Guyana,Haiti:Haiti,Heard and McDonald Islands:Heard and McDonald Islands,Honduras:Honduras,Hong Kong:Hong Kong,Hungary Iceland:Hungary Iceland,India:India,Indonesia:Indonesia,Iran:Iran,Iraq:Iraq,Ireland:Ireland,Israel:Israel,Italy:Italy,Ivory Coast:Ivory Coast,Jamaica:Jamaica,Japan:Japan,Jordan:Jordan,Kazakhstan:Kazakhstan,Kenya:Kenya,Kiribati North:Kiribati North,Korea South:Korea South,Korea:Korea,Kuwait:Kuwait,Kyrgyzstan:Kyrgyzstan,Laos:Laos,Latvia:Latvia,Lesotho:Lesotho,Liberia:Liberia,Libya:Libya,Liechtenstein:Liechtenstein,Lithuania:Lithuania,Luxembourg:Luxembourg,Macau:Macau,Macedonia:Macedonia,Madagascar:Madagascar,Malawi:Malawi,Malaysia:Malaysia,Maldives:Maldives,Mali:Mali,Malta:Malta,Marshall Islands:Marshall Islands,Martinique:Martinique,Mauritania:Mauritania,Mauritius:Mauritius,Mayotte:Mayotte,Mexico:Mexico,Micronesia:Micronesia,Moldova:Moldova,Monaco:Monaco,Mongolia:Mongolia,Montserrat:Montserrat,Morocco:Morocco,Mozambique:Mozambique,Myanmar:Myanmar,Namibia:Namibia,Nauru:Nauru,Nepal:Nepal,Netherlands:Netherlands,Netherlands Antilles:Netherlands Antilles,New Caledonia:New Caledonia,New Zealand:New Zealand,Nicaragua:Nicaragua,Niger:Niger,Nigeria:Nigeria,Niue:Niue,Norfolk Island:Norfolk Island,Northern Mariana Islands:Northern Mariana Islands,Norway:Norway,Oman:Oman,Pakistan:Pakistan,Palau:Palau,Panama:Panama,Papua New Guinea:Papua New Guinea,Paraguay:Paraguay,Peru:Peru,Philippines:Philippines,Pitcairn Island:Pitcairn Island,Poland:Poland,Portugal:Portugal,Puerto Rico:Puerto Rico,Qatar:Qatar,Reunion:Reunion,Romania:Romania,Russia:Russia,RwandaS. Georgia and S. Sandwich Isls.:RwandaS. Georgia and S. Sandwich Isls.,Saint Kitts and Nevis Saint Lucia:Saint Kitts and Nevis Saint Lucia,Saint Vincent and The Grenadines:Saint Vincent and The Grenadines,Samoa:Samoa,San Marino:San Marino,Sao Tome and Principe:Sao Tome and Principe,Saudi Arabia:Saudi Arabia,Senegal:Senegal,Seychelles:Seychelles,Sierra Leone:Sierra Leone,Singapore:Singapore,Slovakia:Slovakia,Slovenia:Slovenia,Solomon Islands:Solomon Islands,Somalia:Somalia,South Africa:South Africa,Spain:Spain,Sri Lanka:Sri Lanka,St. Helena:St. Helena,St. Pierre and Miquelon:St. Pierre and Miquelon,Sudan:Sudan multiline: f multivalue: f property: t readable: t showinusage: t sync: f timestampproperty: whenchanged type: list isregenrequired: f isregencomposite: f hasscope: f allowedonlicenseexpiry: f --------------------------------------------------------------------------------

1 0

Re: (ITS#7527) Problems Adding entries to back-mdb database
by whm＠stanford.edu 13 Feb '13

13 Feb '13

--On Thursday, February 14, 2013 02:53:54 AM +0000 Howard Chu <hyc(a)symas.com> wrote: > whm(a)stanford.edu wrote: >> Full_Name: Bill MacAllister >> Version: RE24 pulled 11-Feb-2013 >> OS: debian wheezy (testing) >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (67.180.239.194) >> >> >> When attempting to add a new entry to a back-mdb database I am seeing >> the following failure: >> >> SASL/EXTERNAL authentication started >> SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth >> SASL SSF: 0 >> SASL/EXTERNAL authentication started >> SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth >> SASL SSF: 0 >> adding new entry "suRegID=uniqueid1,cn=people,dc=stanford,dc=edu" >> ldap_add: Other (e.g., implementation specific) error (80) >> additional info: index generation failed > > Since you pulled RE24 on Feb 11, your code should be producing > additional error info in syslog. Please send the slapd logs > associated with this error. Here is a log entry showing the error. (I should have looked at this sooner.) Feb 13 15:05:27 ldap-unixdev1 slapd[30667]: conn=1074 fd=20 ACCEPT from PATH=/var/run/slapd/ldapi (PATH=/var/run/ slapd/ldapi) Feb 13 15:05:27 ldap-unixdev1 slapd[30667]: conn=1074 op=0 BIND dn="" method=163 Feb 13 15:05:27 ldap-unixdev1 slapd[30667]: conn=1074 op=0 BIND authcid="gidNumber=0+uidNumber=0,cn=peercred,cn=e xternal,cn=auth(a)stanford.edu" authzid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth(a)stanford.edu" Feb 13 15:05:27 ldap-unixdev1 slapd[30667]: conn=1074 op=0 BIND dn="gidNumber=0+uidNumber=0,cn=peercred,cn=extern al,cn=auth" mech=EXTERNAL sasl_ssf=0 ssf=71 Feb 13 15:05:27 ldap-unixdev1 slapd[30667]: conn=1074 op=0 RESULT tag=97 err=0 text= Feb 13 15:05:27 ldap-unixdev1 slapd[30667]: conn=1074 op=1 ADD dn="suRegID=uniqueid1,cn=people,dc=stanford,dc=edu " Feb 13 15:05:27 ldap-unixdev1 slapd[30667]: => mdb_idl_insert_keys: c_put lo/hi failed: Invalid argument (22) Feb 13 15:05:27 ldap-unixdev1 slapd[30667]: conn=1074 op=1 RESULT tag=105 err=80 text=index generation failed Feb 13 15:05:27 ldap-unixdev1 slapd[30667]: conn=1074 op=2 UNBIND Feb 13 15:05:27 ldap-unixdev1 slapd[30667]: conn=1074 fd=20 closed Bill -- Bill MacAllister Infrastructure Delivery Group, Stanford University

1 0

Re: (ITS#7527) Problems Adding entries to back-mdb database
by hyc＠symas.com 13 Feb '13

13 Feb '13

whm(a)stanford.edu wrote: > Full_Name: Bill MacAllister > Version: RE24 pulled 11-Feb-2013 > OS: debian wheezy (testing) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (67.180.239.194) > > > When attempting to add a new entry to a back-mdb database I am seeing > the following failure: > > SASL/EXTERNAL authentication started > SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth > SASL SSF: 0 > SASL/EXTERNAL authentication started > SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth > SASL SSF: 0 > adding new entry "suRegID=uniqueid1,cn=people,dc=stanford,dc=edu" > ldap_add: Other (e.g., implementation specific) error (80) > additional info: index generation failed Since you pulled RE24 on Feb 11, your code should be producing additional error info in syslog. Please send the slapd logs associated with this error. -- -- 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:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs