(ITS#7529) mdb.c missing #if MDB_DEBUG at line 3514
by mark＠ibiblio.org
Full_Name: Mark
Version: 2.4.33
OS: Solaris 10 & 11
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (203.63.89.15)
The stock 2.4.33 fails to compile mdb with this error:
cc -I/usr/local/include -L/usr/local/lib -I../../../include -I../../../include
-I.. -I./.. -I./../../../libraries/libmdb -I/usr/local/include -L/usr/local/lib
-c ./../../../libraries/libmdb/mdb.c -o mdb.o
"./../../../libraries/libmdb/mdb.c", line 3514: undefined symbol: top
"./../../../libraries/libmdb/mdb.c", line 3514: left operand of "->" must be
pointer to struct/union
cc: acomp failed for ./../../../libraries/libmdb/mdb.c
The problem is top is defined inside #if MDB_DEBUG but used without the same #if
qualifier.
The fix is:
/bin/perl -pe '($. == 3514) && s%^%#if MDB_DEBUG\n%' -i
libraries/libmdb/mdb.c
/bin/perl -pe '($. == 3517) && s%^%#endif\n%' -i libraries/libmdb/mdb.c
10 years, 7 months
Re: (ITS#7515) Nested liblmdb transaction bugs
by h.b.furuseth＠usit.uio.no
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
10 years, 7 months
Re: (ITS#7525) Bad conversion to cn=config format - another issue
by francesco.policastro＠selex-es.com
--=_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"
<font size=2 face="sans-serif">Hi,</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br><font size=2 face="sans-serif">I cannot find them in cn=config tree.</font>
<br><font size=2 face="sans-serif">I don't know if you decide to open a
new ITS or not. </font>
<br><font size=2 face="sans-serif">My slapd.conf is attached below. The
slapd version is 2.4.33 as patched after ITS#7525 (</font>
<form action=http://www.openldap.org/its/index.cgi/Software%20Bugs method=post><font size=2 face="sans-serif">openldap-648d28f.tar.gz</font></form><font size=2 face="sans-serif">)</font>
<br>
<br><font size=2 face="sans-serif"> </font>
<br>
<br><font size=2 face="sans-serif">Did anyone use subtrees with cn=config?</font>
<br><font size=2 face="sans-serif">Francesco Policastro</font>
--=_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_=--
10 years, 7 months
Re: (ITS#7515) Nested liblmdb transaction bugs
by h.b.furuseth＠usit.uio.no
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
10 years, 7 months
Re: (ITS#7515) Nested liblmdb transaction bugs
by h.b.furuseth＠usit.uio.no
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
10 years, 7 months
Re: (ITS#7525) Bad conversion to cn=config format - solved
by francesco.policastro＠selex-es.com
--=_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"
<font size=2 face="sans-serif">My suggestion is to modify the test suite
to include an uri containing spaces, just to avoid regressions.</font>
<br>
<br><font size=2 face="sans-serif">Ciao,</font>
<br><font size=2 face="sans-serif">Francesco Policastro</font>
--=_alternative 0039EFE9C1257B16_=--
10 years, 7 months
Re: (ITS#7517) mdb_dbi_close(dbi updated in existing txn) breaks
by h.b.furuseth＠usit.uio.no
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
10 years, 7 months
Re: (ITS#7515) Nested liblmdb transaction bugs
by h.b.furuseth＠usit.uio.no
> 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
10 years, 7 months
(ITS#7528) ldapadd not working while adding attribute having long list of values
by omkar＠mithi.com
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
--------------------------------------------------------------------------------
10 years, 7 months
Re: (ITS#7527) Problems Adding entries to back-mdb database
by whm＠stanford.edu
--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
10 years, 7 months
