- openldap-bugs - openldap.org

Re: (ITS#6652) accesslog anomaly in db drop/re-import
by masarati＠aero.polimi.it 01 Feb '11

01 Feb '11

Marco Pizzoli wrote: > Hi, > the (same?) problem arises again. > > I downloaded the upgraded source, created a new accesslog and today tried to > slapcat/drop/slapadd. > This is the error that I'm encountering: > > [ldap@ldap03 db_log]$ time /usr/local/openldap/sbin/slapadd -b "cn=log03,dc= > mycorp.it" -l dump_ldap_dblog_20110201.ldif > .### 17.14% eta 01h17m elapsed 15m56s spd 443.0 > k/s str2entry: invalid value for attributeType reqAttr #1 (syntax > 1.3.6.1.4.1.1466.115.121.1.15) > slapadd: could not parse entry (line=13502606) > _### 17.14% eta 01h17m elapsed 15m56s spd 330.0 > k/s > Closing DB... > > The corrupted entry is: > > dn: reqStart=20110128141509.000004Z,cn=log03,dc=mycorp.it > objectClass: auditSearch > structuralObjectClass: auditSearch > reqStart: 20110128141509.000004Z > reqEnd: 20110128141510.000000Z > reqType: search > reqSession: 6521 > reqAuthzID: cn=Manager,dc=myregion,dc=mycorp.it > reqDN: uid=pe1748,ou=People,dc=myregion,dc=mycorp.it > reqResult: 0 > reqScope: base > reqDerefAliases: never > reqAttrsOnly: FALSE > reqFilter: (&(objectClass=*)) > reqAttr: * > reqAttr: > reqEntries: 1 > reqTimeLimit: -1 > reqSizeLimit: 500 > entryUUID: c18cf535-bbbd-4a0c-b5bb-848da7e39dbf > creatorsName: cn=Manager,cn=log03,dc=mycorp.it > createTimestamp: 20110128141510Z > entryCSN: 20110128141510.000116Z#000000#003#000000 > modifiersName: cn=Manager,cn=log03,dc=mycorp.it > modifyTimestamp: 20110128141510Z A fix is in HEAD (ITS#6819); more is coming. Please test. Thanks, p.

1 0

(ITS#6819) invalid attributes in search request
by masarati＠aero.polimi.it 01 Feb '11

01 Feb '11

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.200) Submitted by: ando As per RFC4511 we ignore unknown attributes in search requests, and we handle special attributes according to RFC 3673 and RFC 4529; however we probably should ignore and discard invalid attributes (i.e. attributes not conforming to section 2.5. of RFC4512). A noteworthy example is that right now slapd accepts "" (the empty string). Although there is no strong motivation for discarding non conforming requests (and, as per RFC 3673 and RFC 4529, the production attributeSelector of Section 4.5.1.8. of RFC 4511 had to be extended, so this code should be updated whenever that production is modified further), I think this change would be in the spirit of OpenLDAP's slapd (i.e. liberal in accepting requests with invalid productions, but strict in not letting them proceed further). One case where an invalid production is causing problems downstream is in accesslog, where the empty string is written as the value of a reqAttr, which is invalid per the syntax of reqAttr which is an LDAPString. As a consequence, a slapcat of such an accesslog entry cannot be reloaded. I am fixing accesslog otherwise, but probably invalid attributeselectors should be filtered out when parsing search requests. p.

1 0

Re: (ITS#6652) accesslog anomaly in db drop/re-import
by masarati＠aero.polimi.it 01 Feb '11

01 Feb '11

Marco Pizzoli wrote: > Hi, > the (same?) problem arises again. > > I downloaded the upgraded source, created a new accesslog and today tried to > slapcat/drop/slapadd. > This is the error that I'm encountering: > > [ldap@ldap03 db_log]$ time /usr/local/openldap/sbin/slapadd -b "cn=log03,dc= > mycorp.it" -l dump_ldap_dblog_20110201.ldif > .### 17.14% eta 01h17m elapsed 15m56s spd 443.0 > k/s str2entry: invalid value for attributeType reqAttr #1 (syntax > 1.3.6.1.4.1.1466.115.121.1.15) > slapadd: could not parse entry (line=13502606) > _### 17.14% eta 01h17m elapsed 15m56s spd 330.0 > k/s > Closing DB... > > The corrupted entry is: > > dn: reqStart=20110128141509.000004Z,cn=log03,dc=mycorp.it > objectClass: auditSearch > structuralObjectClass: auditSearch > reqStart: 20110128141509.000004Z > reqEnd: 20110128141510.000000Z > reqType: search > reqSession: 6521 > reqAuthzID: cn=Manager,dc=myregion,dc=mycorp.it > reqDN: uid=pe1748,ou=People,dc=myregion,dc=mycorp.it > reqResult: 0 > reqScope: base > reqDerefAliases: never > reqAttrsOnly: FALSE > reqFilter: (&(objectClass=*)) > reqAttr: * > reqAttr: > reqEntries: 1 > reqTimeLimit: -1 > reqSizeLimit: 500 > entryUUID: c18cf535-bbbd-4a0c-b5bb-848da7e39dbf > creatorsName: cn=Manager,cn=log03,dc=mycorp.it > createTimestamp: 20110128141510Z > entryCSN: 20110128141510.000116Z#000000#003#000000 > modifiersName: cn=Manager,cn=log03,dc=mycorp.it > modifyTimestamp: 20110128141510Z I've found that a search for '*' does generate a log with only one reqAttr value, reqAttr: * However a search for '*' '' (the empty string) actually generates a log like the one you posted. I'll fix this, but in the meanwhile you should fix your client. p.

1 0

Re: (ITS#6818) back-meta: do not denormalize attrs without equality rule
by masarati＠aero.polimi.it 01 Feb '11

01 Feb '11

h.b.furuseth(a)usit.uio.no wrote: > masarati(a)aero.polimi.it writes: >> Subject: (ITS#6818) back-meta: do not denormalize attrs without equality rule > > Is this denormalizion a user-visible or internal matter? AFAIK it's about generating a printable form of some normal forms, e.g. UUIDs. It's used very seldom, but for some reasons that bit of code assumed an EQUALITY rule was present, and I ran into that after enabling undefined attr filters to be saved in Filter structures for logging purposes (ava.c 1.53 -> 1.54). I don't think the user needs to be aware of that. p.

1 0

Re: (ITS#6652) accesslog anomaly in db drop/re-import
by marco.pizzoli＠gmail.com 01 Feb '11

01 Feb '11

--00504502c82c9d7fc8049b363033 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, the (same?) problem arises again. I downloaded the upgraded source, created a new accesslog and today tried t= o slapcat/drop/slapadd. This is the error that I'm encountering: [ldap@ldap03 db_log]$ time /usr/local/openldap/sbin/slapadd -b "cn=3Dlog03,= dc=3D mycorp.it" -l dump_ldap_dblog_20110201.ldif .### 17.14% eta 01h17m elapsed 15m56s spd 443.0 k/s str2entry: invalid value for attributeType reqAttr #1 (syntax 1.3.6.1.4.1.1466.115.121.1.15) slapadd: could not parse entry (line=3D13502606) _### 17.14% eta 01h17m elapsed 15m56s spd 330.0 k/s Closing DB... The corrupted entry is: dn: reqStart=3D20110128141509.000004Z,cn=3Dlog03,dc=3Dmycorp.it objectClass: auditSearch structuralObjectClass: auditSearch reqStart: 20110128141509.000004Z reqEnd: 20110128141510.000000Z reqType: search reqSession: 6521 reqAuthzID: cn=3DManager,dc=3Dmyregion,dc=3Dmycorp.it reqDN: uid=3Dpe1748,ou=3DPeople,dc=3Dmyregion,dc=3Dmycorp.it reqResult: 0 reqScope: base reqDerefAliases: never reqAttrsOnly: FALSE reqFilter: (&(objectClass=3D*)) reqAttr: * reqAttr: reqEntries: 1 reqTimeLimit: -1 reqSizeLimit: 500 entryUUID: c18cf535-bbbd-4a0c-b5bb-848da7e39dbf creatorsName: cn=3DManager,cn=3Dlog03,dc=3Dmycorp.it createTimestamp: 20110128141510Z entryCSN: 20110128141510.000116Z#000000#003#000000 modifiersName: cn=3DManager,cn=3Dlog03,dc=3Dmycorp.it modifyTimestamp: 20110128141510Z Thanks Marco Pizzoli On Sun, Jan 2, 2011 at 4:01 PM, <masarati(a)aero.polimi.it> wrote: > > Full_Name: Marco Pizzoli > > Version: 2.4.23 > > OS: Linux x86_64 > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (193.41.84.11) > > > > > > Hi, > > I had a problem with my Accesslog database. > > I was investigating an anomaly that I had and, in doing this, I tried t= o: > > - backup (slapcat) my accesslog db > > - drop the entire db (rm -f alock, *.bdb, log.*, __db*) > > - slapadd the db > > > > In slapadd I obtained this error: > > > > --- BEGIN > > /usr/sbin/slapadd -b "cn=3Dlog,dc=3Dmycorp.it" -l > > /srv/bck/dump_db_log.ldif.20100916 > > . 0.00% eta 08h35m elapsed spd > 90.2 > > k/s > > str2entry: invalid value for attributeType reqControls #0 (syntax > > 1.3.6.1.4.1.4203.666.11.5.3.1) > > slapadd2.4: could not parse entry (line=3D4907) > > - 0.01% eta 05h58m elapsed spd > 205.7 > > k/s > > Closing DB... > > --- END > > > > I went to that line and found this entry: > > > > --- BEGIN > > dn: reqStart=3D20100913065628.000008Z,cn=3Dlog,dc=3Dmycorp.it > > objectClass: auditSearch > > structuralObjectClass: auditSearch > > reqStart: 20100913065628.000008Z > > reqEnd: 20100913065628.000009Z > > reqType: search > > reqSession: 1129 > > reqAuthzID: > > cn=3Dsyncrepl-ldap04,ou=3Dutenze_tecniche_openldap,ou=3DGestori,dc=3Dmy= corp.it > > reqControls: {0}{1.3.6.1.4.1.4203.1.9.1.1 controlValue > > "30440K0103043M7269643N > > > 3030332M7369643N3030342M63736O3N32303130303931333036353130362O3932343735= 355K2 > > 330303030303023303033233030303030300001PP"} > > reqControls: {1}{2.16.840.1.113730.3.4.2 criticality TRUE} > > reqDN: dc=3Dmycorp.it > > reqResult: 0 > > reqScope: base > > reqDerefAliases: never > > reqAttrsOnly: TRUE > > reqFilter: (objectclass=3D*) > > reqAttr: 1.1 > > reqEntries: 0 > > reqTimeLimit: -1 > > reqSizeLimit: 1 > > entryUUID: 2beb0bd0-ba32-4a00-93da-748ef2177cc7 > > creatorsName: cn=3DManager,cn=3Dlog,dc=3Dmycorp.it > > createTimestamp: 20100913065628Z > > entryCSN: 20100913065628.167225Z#000000#003#000000 > > modifiersName: cn=3DManager,cn=3Dlog,dc=3Dmycorp.it > > modifyTimestamp: 20100913065628Z > > --- END > > > > Having produced this ldif using slapcat and not having "touched" the > > environment > > in between could I assume this to be a bug? > > The entry showed is related to an access made by another OL server of m= y > > deployment, which is in mirrormode(=3Dtrue). > > This OL is 2.4.23 with BDB4.8.30. Other OLs are 2.4.22 with BDB4.8.26 > > > > > > I deleted this entry and retried the import. > > Now I have the following error: > > --- BEGIN > > /usr/sbin/slapadd2.4 -b "cn=3Dlog,dc=3Dmycorp.it" -l > > /tmp/dump_db_log.ldif.20100916_Corrected > > " 4.69% eta 01h07m elapsed 03m19s spd > 542.3 > > k/s > > str2entry: invalid value for attributeType reqRespControls #0 (syntax > > 1.3.6.1.4.1.4203.666.11.5.3.1) > > slapadd2.4: could not parse entry (line=3D3099715) > > * 4.70% eta 01h07m elapsed 03m20s spd > 979.8 > > k/s > > Closing DB... > > --- END > > > > The "corrupted" entry is this one: > > > > --- BEGIN > > dn: reqStart=3D20100913093021.000000Z,cn=3Dlog,dc=3Dmycorp.it > > objectClass: auditBind > > structuralObjectClass: auditBind > > reqStart: 20100913093021.000000Z > > reqEnd: 20100913093021.000001Z > > reqType: bind > > reqSession: 2746 > > reqAuthzID: > > reqControls: {0}{1.3.6.1.4.1.42.2.27.8.5.1} > > reqRespControls: {0}{1.3.6.1.4.1.42.2.27.8.5.1 controlValue "3000"} > > reqDN: uid=3Dpe1597,ou=3DPeople,dc=3Dmycorp.it > > reqResult: 0 > > reqVersion: 3 > > reqMethod: SIMPLE > > entryUUID: 192cbddf-4b5c-431d-a92e-c2f84fa4b7be > > creatorsName: cn=3DManager,cn=3Dlog,dc=3Dmycorp.it > > createTimestamp: 20100913093021Z > > entryCSN: 20100913093021.411398Z#000000#003#000000 > > modifiersName: cn=3DManager,cn=3Dlog,dc=3Dmycorp.it > > modifyTimestamp: 20100913093021Z > > --- END > > > > Is this a software bug? > > > > If yes, do I need to produce other infos related to my environment? > > Hi, I have fixed a couple of bugs in reqControls validation. However a > problem remains: the validator expects control values to consist in > hexadecimal digits (0-9, a-f), while your values in some cases aren't. > This could be related to interoperation issues between different slapd > versions, although I couldn't go back to the point where this change in > syntax occurred, if any. > > p. > > --=20 _________________________________________ Non =E8 forte chi non cade, ma chi cadendo ha la forza di rialzarsi. Jim Morrison --00504502c82c9d7fc8049b363033 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, the (same?) problem arises again. I downloaded the upgraded s= ource, created a new accesslog and today tried to slapcat/drop/slapadd. = This is the error that I'm encountering: [ldap@ldap03 db_log]$ t= ime /usr/local/openldap/sbin/slapadd -b "cn=3Dlog03,dc=3D<a href=3D"ht= tp://mycorp.it">mycorp.it</a>" -l dump_ldap_dblog_20110201.ldif .###=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 17.14% eta 01h17= m elapsed=A0=A0=A0=A0=A0=A0=A0=A0=A0 15m56s spd 443.0 k/s str2entry: invali= d value for attributeType reqAttr #1 (syntax 1.3.6.1.4.1.1466.115.121.1.15)= slapadd: could not parse entry (line=3D13502606) _###=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 17.14% eta 01h17= m elapsed=A0=A0=A0=A0=A0=A0=A0=A0=A0 15m56s spd 330.0 k/s Closing DB...<= br> The corrupted entry is: dn: reqStart=3D20110128141509.000004Z= ,cn=3Dlog03,dc=3D<a href=3D"http://mycorp.it">mycorp.it</a> objectClass: auditSearch structuralObjectClass: auditSearch reqStart:= 20110128141509.000004Z reqEnd: 20110128141510.000000Z reqType: searc= h reqSession: 6521 reqAuthzID: cn=3DManager,dc=3Dmyregion,dc=3D<a hre= f=3D"http://mycorp.it">mycorp.it</a> reqDN: uid=3Dpe1748,ou=3DPeople,dc=3Dmyregion,dc=3D<a href=3D"http://mycorp= .it">mycorp.it</a> reqResult: 0 reqScope: base reqDerefAliases: ne= ver reqAttrsOnly: FALSE reqFilter: (&(objectClass=3D*)) reqAtt= r: * reqAttr: reqEntries: 1 reqTimeLimit: -1 reqSizeLimit: 500 entry= UUID: c18cf535-bbbd-4a0c-b5bb-848da7e39dbf creatorsName: cn=3DManager,cn= =3Dlog03,dc=3D<a href=3D"http://mycorp.it">mycorp.it</a> createTimestamp= : 20110128141510Z entryCSN: 20110128141510.000116Z#000000#003#000000 modifiersName: cn=3DM= anager,cn=3Dlog03,dc=3D<a href=3D"http://mycorp.it">mycorp.it</a> modify= Timestamp: 20110128141510Z Thanks =A0=A0=A0=A0=A0=A0 Marco Pi= zzoli <div class=3D"gmail_quote">On Sun, Jan 2, 2011 at 4:01 PM, <<a href=3D"mailto:masarati@aero.polimi.it">masarati(a)aero.pol= imi.it</a>> wrote: <blockquote class=3D"gmail_quote" style=3D"= margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); paddi= ng-left: 1ex;"> > Full_Name: Marco Pizzoli > Version: 2.4.23 > OS: Linux x86_64 > URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_blank">ft= p://ftp.openldap.org/incoming/</a> > Submission from: (NULL) (193.41.84.11) > > > Hi, > I had a problem with my Accesslog database. > I was investigating an anomaly that I had and, in doing this, I tried = to: > - backup (slapcat) my accesslog db > - drop the entire db (rm -f alock, *.bdb, log.*, __db*) > - slapadd the db > > In slapadd I obtained this error: > > --- BEGIN > /usr/sbin/slapadd -b "cn=3Dlog,dc=3D<a href=3D"http://mycorp.it" = target=3D"_blank">mycorp.it</a>" -l > /srv/bck/dump_db_log.ldif.20100916 > . =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0.00% eta 08h35m elapsed= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 spd =A090.2 > k/s > str2entry: invalid value for attributeType reqControls #0 (syntax > 1.3.6.1.4.1.4203.666.11.5.3.1) > slapadd2.4: could not parse entry (line=3D4907) > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0.01% eta 05h58m elapsed= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 spd 205.7 > k/s > Closing DB... > --- END > > I went to that line and found this entry: > > --- BEGIN > dn: reqStart=3D20100913065628.000008Z,cn=3Dlog,dc=3D<a href=3D"http://= mycorp.it" target=3D"_blank">mycorp.it</a> > objectClass: auditSearch > structuralObjectClass: auditSearch > reqStart: 20100913065628.000008Z > reqEnd: 20100913065628.000009Z > reqType: search > reqSession: 1129 > reqAuthzID: > cn=3Dsyncrepl-ldap04,ou=3Dutenze_tecniche_openldap,ou=3DGestori,dc=3D<= a href=3D"http://mycorp.it" target=3D"_blank">mycorp.it</a> > reqControls: {0}{1.3.6.1.4.1.4203.1.9.1.1 controlValue > "30440K0103043M7269643N > =A03030332M7369643N3030342M63736O3N32303130303931333036353130362O39323= 43735355K2 > =A0330303030303023303033233030303030300001PP"} > reqControls: {1}{2.16.840.1.113730.3.4.2 criticality TRUE} > reqDN: dc=3D<a href=3D"http://mycorp.it" target=3D"_blank">mycorp.it</= a> > reqResult: 0 > reqScope: base > reqDerefAliases: never > reqAttrsOnly: TRUE > reqFilter: (objectclass=3D*) > reqAttr: 1.1 > reqEntries: 0 > reqTimeLimit: -1 > reqSizeLimit: 1 > entryUUID: 2beb0bd0-ba32-4a00-93da-748ef2177cc7 > creatorsName: cn=3DManager,cn=3Dlog,dc=3D<a href=3D"http://mycorp.it" = target=3D"_blank">mycorp.it</a> > createTimestamp: 20100913065628Z > entryCSN: 20100913065628.167225Z#000000#003#000000 > modifiersName: cn=3DManager,cn=3Dlog,dc=3D<a href=3D"http://mycorp.it"= target=3D"_blank">mycorp.it</a> > modifyTimestamp: 20100913065628Z > --- END > > Having produced this ldif using slapcat and not having "touched&q= uot; the > environment > in between could I assume this to be a bug? > The entry showed is related to an access made by another OL server of = my > deployment, which is in mirrormode(=3Dtrue). > This OL is 2.4.23 with BDB4.8.30. Other OLs are 2.4.22 with BDB4.8.26<= br> > > > I deleted this entry and retried the import. > Now I have the following error: > --- BEGIN > /usr/sbin/slapadd2.4 -b "cn=3Dlog,dc=3D<a href=3D"http://mycorp.i= t" target=3D"_blank">mycorp.it</a>" -l > /tmp/dump_db_log.ldif.20100916_Corrected > " =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 4.69% eta 01h07m el= apsed =A0 =A0 =A0 =A0 =A003m19s spd 542.3 > k/s > str2entry: invalid value for attributeType reqRespControls #0 (syntax<= br> > 1.3.6.1.4.1.4203.666.11.5.3.1) > slapadd2.4: could not parse entry (line=3D3099715) > * =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 4.70% eta 01h07m elapsed= =A0 =A0 =A0 =A0 =A003m20s spd 979.8 > k/s > Closing DB... > --- END > > The "corrupted" entry is this one: > > --- BEGIN > dn: reqStart=3D20100913093021.000000Z,cn=3Dlog,dc=3D<a href=3D"http://= mycorp.it" target=3D"_blank">mycorp.it</a> > objectClass: auditBind > structuralObjectClass: auditBind > reqStart: 20100913093021.000000Z > reqEnd: 20100913093021.000001Z > reqType: bind > reqSession: 2746 > reqAuthzID: > reqControls: {0}{1.3.6.1.4.1.42.2.27.8.5.1} > reqRespControls: {0}{1.3.6.1.4.1.42.2.27.8.5.1 controlValue "3000= "} > reqDN: uid=3Dpe1597,ou=3DPeople,dc=3D<a href=3D"http://mycorp.it" targ= et=3D"_blank">mycorp.it</a> > reqResult: 0 > reqVersion: 3 > reqMethod: SIMPLE > entryUUID: 192cbddf-4b5c-431d-a92e-c2f84fa4b7be > creatorsName: cn=3DManager,cn=3Dlog,dc=3D<a href=3D"http://mycorp.it" = target=3D"_blank">mycorp.it</a> > createTimestamp: 20100913093021Z > entryCSN: 20100913093021.411398Z#000000#003#000000 > modifiersName: cn=3DManager,cn=3Dlog,dc=3D<a href=3D"http://mycorp.it"= target=3D"_blank">mycorp.it</a> > modifyTimestamp: 20100913093021Z > --- END > > Is this a software bug? > > If yes, do I need to produce other infos related to my environment?<br= > Hi, I have fixed a couple of bugs in reqControls validation. =A0However a<b= r> problem remains: the validator expects control values to consist in hexadecimal digits (0-9, a-f), while your values in some cases aren't.<= br> This could be related to interoperation issues between different slapd versions, although I couldn't go back to the point where this change in= syntax occurred, if any. p. </blockquote></div> -- _______________________= __________________ Non =E8 forte chi non cade, ma chi cadendo ha la forz= a di rialzarsi. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Jim Morrison <div style=3D"visibility: hidden; left: -5000px; position: absolute; z-inde= x: 9999; padding: 0px; margin-left: 0px; margin-top: 0px; overflow: hidden;= word-wrap: break-word; color: black; font-size: 10px; text-align: left; li= ne-height: 130%;" id=3D"avg_ls_inline_popup"> </div> --00504502c82c9d7fc8049b363033--

1 0

Réf. : Re: (ITS#6810) slapd crashes writing to bdb backend
by Bruno_Haleblian＠carrefour.com 01 Feb '11

01 Feb '11

--0__=4EBBF2B9DFA5BFCE8f9e8a93df938690918c4EBBF2B9DFA5BFCE Content-type: multipart/alternative; Boundary="1__=4EBBF2B9DFA5BFCE8f9e8a93df938690918c4EBBF2B9DFA5BFCE" --1__=4EBBF2B9DFA5BFCE8f9e8a93df938690918c4EBBF2B9DFA5BFCE Content-type: text/plain; charset=US-ASCII Hi, Quanah, Here are my answers plus some comments. All is under ext3 fs BDB log files and data files are one seperate filesystem BDB is 4.6.21 with patch 4 (as provided by http://ltb-project.org/wiki/download ) Running on a VSPhere4 VM - this hardware emulated : 00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 01) 00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 01) 00:07.0 ISA bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 08) 00:07.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01) 00:07.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 08) 00:07.7 System peripheral: VMware Virtual Machine Communication Interface (rev 10) 00:0f.0 VGA compatible controller: VMware SVGA II Adapter 00:10.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 01) The 2 servers are in mirror mode. See below the diff between their conf and here's a slapd.conf extract plus the DB_CONFIG file. Most parameters have been provided in the early ages with the old slapd (2.2.x). Mirroring setup is based on admin guide -------------- slapd.conf excerpt -------------- # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include my schemas serverID 2 pidfile /var/ldap/server/var/run/slapd.pid argsfile /var/ldap/server/var/run/slapd.args loglevel 256 allow bind_v2 gentlehup off idletimeout 3600 defaultsearchbase "dc=carrefour,dc=com" timelimit unlimited sizelimit unlimited database bdb suffix "dc=carrefour,dc=com" rootdn "cn=*******,dc=carrefour,dc=com" rootpw ******* directory /var/ldap/data cachesize 500000 maxderefdepth 5 checkpoint 512 720 # Indices to maintain index objectclass,entryCSN,entryUUID eq index uid pres,eq,sub index cn,sn pres,eq,sub,subany index memberOf,eduPersonOrgUnitDN,eduPersonPrimaryOrgUnitDN,employeeNumber,seeAlso eq index businessCategory eq index eduPersonAffiliation,employeeType eq index mail eq index givenName eq index userCertificate eq # some acces rules, granting write user replic dn="uid=replic,dc=carrefour,dc=com" #... overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 syncrepl rid=001 provider=ldap://X.X.X.X bindmethod=simple binddn="uid=replic,dc=carrefour,dc=com" credentials=********** searchbase="dc=carrefour,dc=com" schemachecking=on type=refreshAndPersist retry="20 +" mirrormode on # pour cacti database monitor ------------- -------------- slapd.conf diff between mirror peers -------------- < serverID 1 --- > serverID 2 27c27 < loglevel 0 --- > loglevel 256 132c132 < provider=ldap://X.X.X.X --- > provider=ldap://X.X.X.Y -------------- DB_CONFIG -------------- #==================================================================== # BDB configuration # # Provided by LTB-project (http://www.ltb-project.org) #==================================================================== set_cachesize 1 0 1 set_flags DB_LOG_AUTOREMOVE set_lg_regionmax 1048576 set_lg_max 10485760 set_lg_bsize 2097152 set_lg_dir /var/ldap/logs -------------- Regards Bruno HALEBLIAN |---------+----------------------------> | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |---------+----------------------------> >---------------------------------------------------------------------------------------------------------------------| | | | Quanah Gibson-Mount <quanah(a)zimbra.com> | | | |Pour : bruno_haleblian(a)carrefour.com, openldap-its(a)openldap.org | |cc : | |Objet : Re: (ITS#6810) slapd crashes writing to bdb backend | | | | 31/01/2011 22:14 | >---------------------------------------------------------------------------------------------------------------------| --On Friday, January 28, 2011 9:47 AM +0000 bruno_haleblian(a)carrefour.com wrote: > Full_Name: Bruno HALEBLIAN > Version: 2.4.23 > OS: RHEL 5.5/64 bits > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (92.243.12.111) > > > Hello, > I'm stuck with "random" slapd crashes, my slapd has been tested > successfully in read mode but since I run updates, I get several crashes > a day, with no BDB corruption (recover and restart OK) but I can't let > this go to production stage. > > Here's the first core stack I caught, I'll send more if I meet different > ones. > > Thanks for your help. Hi Bruno, What type of filesystem is BDB located on? I.e., NFS, ext3, SAN, etc. Also, what version of BDB are you using from Oracle? Can you provide your configuration file/cn=config directory (minus any passwords)? Thanks, Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration This e-mail and any attachment are confidential and intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient, please telephone or email the sender and delete this message and any attachment from your system. Unauthorized publication, use, dissemination, forwarding, printing or copying of this e-mail and its associated attachments is strictly prohibited. http://disclaimer.carrefour.com/ Let's respect the environment together. Only print this message if necessary --1__=4EBBF2B9DFA5BFCE8f9e8a93df938690918c4EBBF2B9DFA5BFCE Content-type: text/html; charset=US-ASCII Content-Disposition: inline <html><body> <tt>Hi,</tt> <tt>Quanah,</tt> <tt>Here are my answers plus some comments.</tt> <tt>All is under ext3 fs</tt> <tt>BDB log files and data files are one seperate filesystem</tt> <tt>BDB is 4.6.21 with patch 4 (as provided by <a href="http://ltb-project.org/wiki/download">http://ltb-project.org/wiki/download</a> )</tt> <tt>Running on a VSPhere4  VM - this hardware emulated : </tt> <tt>00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 01)</tt> <tt>00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 01)</tt> <tt>00:07.0 ISA bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 08)</tt> <tt>00:07.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01)</tt> <tt>00:07.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 08)</tt> <tt>00:07.7 System peripheral: VMware Virtual Machine Communication Interface (rev 10)</tt> <tt>00:0f.0 VGA compatible controller: VMware SVGA II Adapter</tt> <tt>00:10.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 01)</tt> <tt>The 2 servers are in mirror mode. See below the diff between their conf</tt> <tt>and here's a slapd.conf extract plus the DB_CONFIG file. </tt> <tt>Most parameters have been provided in the early ages with the old slapd (2.2.x).</tt> <tt>Mirroring setup is based on admin guide</tt> <tt>--------------</tt> <tt>slapd.conf excerpt</tt> <tt>--------------</tt> <tt># See slapd.conf(5) for details on configuration options.</tt> <tt># This file should NOT be world readable.</tt> <tt>#</tt> <tt>include         my schemas</tt> <tt>serverID        2</tt> <tt>pidfile         /var/ldap/server/var/run/slapd.pid</tt> <tt>argsfile        /var/ldap/server/var/run/slapd.args</tt> <tt>loglevel        256</tt> <tt>allow   bind_v2</tt> <tt>gentlehup       off</tt> <tt>idletimeout     3600</tt> <tt>defaultsearchbase       "dc=carrefour,dc=com"</tt> <tt>timelimit       unlimited</tt> <tt>sizelimit       unlimited</tt> <tt>database        bdb</tt> <tt>suffix          "dc=carrefour,dc=com"</tt> <tt>rootdn          "cn=*******,dc=carrefour,dc=com"</tt> <tt>rootpw          *******</tt> <tt>directory       /var/ldap/data</tt> <tt>cachesize       500000</tt> <tt>maxderefdepth   5</tt> <tt>checkpoint      512     720</tt> <tt># Indices to maintain</tt> <tt>index           objectclass,entryCSN,entryUUID eq</tt> <tt>index           uid     pres,eq,sub</tt> <tt>index           cn,sn   pres,eq,sub,subany</tt> <tt>index           memberOf,eduPersonOrgUnitDN,eduPersonPrimaryOrgUnitDN,employeeNumber,seeAlso    eq</tt> <tt>index           businessCategory eq</tt> <tt>index           eduPersonAffiliation,employeeType eq</tt> <tt>index           mail    eq</tt> <tt>index           givenName       eq</tt> <tt>index           userCertificate eq</tt> <tt># some acces rules, granting write user replic dn="uid=replic,dc=carrefour,dc=com"</tt> <tt>#...</tt> <tt>overlay syncprov</tt> <tt>syncprov-checkpoint 100 10</tt> <tt>syncprov-sessionlog 100</tt> <tt>syncrepl rid=001</tt> <tt>                provider=ldap://X.X.X.X</tt> <tt>                bindmethod=simple</tt> <tt>                binddn="uid=replic,dc=carrefour,dc=com"</tt> <tt>                credentials=**********</tt> <tt>                searchbase="dc=carrefour,dc=com"</tt> <tt>                schemachecking=on</tt> <tt>                type=refreshAndPersist</tt> <tt>                retry="20 +"</tt> <tt>mirrormode on</tt> <tt># pour cacti</tt> <tt>database monitor</tt> <tt>-------------</tt> <tt>--------------</tt> <tt>slapd.conf diff between mirror peers</tt> <tt>--------------</tt> <tt>< serverID        1</tt> <tt>---</tt> <tt>> serverID        2</tt> <tt>27c27</tt> <tt>< loglevel        0</tt> <tt>---</tt> <tt>> loglevel        256</tt> <tt>132c132</tt> <tt><                 provider=ldap://X.X.X.X</tt> <tt>---</tt> <tt>>                 provider=ldap://X.X.X.Y</tt> <tt>--------------</tt> <tt>DB_CONFIG</tt> <tt>--------------</tt> <tt>#====================================================================</tt> <tt># BDB configuration</tt> <tt>#</tt> <tt># Provided by LTB-project (<a href="http://www.ltb-project.org">http://www.ltb-project.org</a>)</tt> <tt>#====================================================================</tt> <tt>set_cachesize   1 0 1</tt> <tt>set_flags               DB_LOG_AUTOREMOVE</tt> <tt>set_lg_regionmax        1048576</tt> <tt>set_lg_max              10485760</tt> <tt>set_lg_bsize            2097152</tt> <tt>set_lg_dir      /var/ldap/logs</tt> <tt>--------------</tt> <tt> </tt> Regards Bruno HALEBLIAN <img width="16" height="16" src="cid:1__=4EBBF2B9DFA5BFCE8f9e8a93df@carrefour.com" border="0" alt="Inactive hide details for unnamed section"> <table V5DOTBL=true width="100%" border="0" cellspacing="0" cellpadding="0"> <tr valign="top"><td width="1%"><img width="72" height="1" src="cid:2__=4EBBF2B9DFA5BFCE8f9e8a93df@carrefour.com" border="0" alt=""> </td><td style="background-image:url(cid:3__=4EBBF2B9DFA5BFCE8f9e8a93df@carrefour.com); background-repeat: no-repeat; " width="1%"><img width="222" height="1" src="cid:2__=4EBBF2B9DFA5BFCE8f9e8a93df@carrefour.com" border="0" alt=""> </td><td width="100%"><img width="1" height="1" src="cid:2__=4EBBF2B9DFA5BFCE8f9e8a93df@carrefour.com" border="0" alt=""> Quanah Gibson-Mount <quanah(a)zimbra.com> Pour : bruno_haleblian(a)carrefour.com, openldap-its(a)openldap.org cc : Objet : Re: (ITS#6810) slapd crashes writing to bdb backend 31/01/2011 22:14</td></tr> </table> <tt>--On Friday, January 28, 2011 9:47 AM +0000 bruno_haleblian(a)carrefour.com wrote: > Full_Name: Bruno HALEBLIAN > Version: 2.4.23 > OS: RHEL 5.5/64 bits > URL: </tt><tt><a href="ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.org/incoming/</a></tt><tt> > Submission from: (NULL) (92.243.12.111) > > > Hello, > I'm stuck with "random" slapd crashes, my slapd has been tested > successfully in read mode but since I run updates, I get several crashes > a day, with no BDB corruption (recover and restart OK) but I can't let > this go to production stage. > > Here's the first core stack I caught, I'll send more if I meet different > ones. > > Thanks for your help. Hi Bruno, What type of filesystem is BDB located on?  I.e., NFS, ext3, SAN, etc. Also, what version of BDB are you using from Oracle?  Can you provide your configuration file/cn=config directory (minus any passwords)? Thanks, Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra ::  the leader in open source messaging and collaboration </tt> <div class=Section1> This e-mail and any attachment are confidential and intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient, please telephone or email the sender and delete this message and any attachment from your system. Unauthorized publication, use, dissemination, forwarding, printing or copying of this e-mail and its associated attachments is strictly prohibited. <a href="http://disclaimer.carrefour.com"> http://disclaimer.carrefour.com </a> Let's respect the environment together. Only print this message if necessary <o:p></o:p> </div> </body></html> --1__=4EBBF2B9DFA5BFCE8f9e8a93df938690918c4EBBF2B9DFA5BFCE-- --0__=4EBBF2B9DFA5BFCE8f9e8a93df938690918c4EBBF2B9DFA5BFCE Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=4EBBF2B9DFA5BFCE8f9e8a93df(a)carrefour.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIX lI+py+0PopwxUbpuZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFk IFNtYXJ0U2F2ZXIhAAA7 --0__=4EBBF2B9DFA5BFCE8f9e8a93df938690918c4EBBF2B9DFA5BFCE Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <2__=4EBBF2B9DFA5BFCE8f9e8a93df(a)carrefour.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=4EBBF2B9DFA5BFCE8f9e8a93df938690918c4EBBF2B9DFA5BFCE Content-type: image/gif; name="pic10697.gif" Content-Disposition: inline; filename="pic10697.gif" Content-ID: <3__=4EBBF2B9DFA5BFCE8f9e8a93df(a)carrefour.com> Content-transfer-encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIue zf///wAAAAAAAAAAAAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq7046827 70RiFMRinqggEUNSHIchG0BCfHhOjAuhEDeUqTASLCbBhQrhG7xis2j0lssN DopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYRRghXcAGFhoUE TwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09l mgkHLZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtC KW3jfz4uMKmq3xu4N0nKBVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQ EEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAITihRL/4FEwbp28BXMMcoscQC VxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFRM00oQAqN IstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE 4zk+T6FGuQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3m pOaKnL0Z2EKvNMSILEThKhCgzMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI +LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpbqxIKsjUPRgD7I2XYV6wy rOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33YEWQ YNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1 KOODHiu+4aEwNEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcs oCWOOUwgltIwAKRxJgbIkJAQZEq02YliZnpZZ4BH3CnYOXldOUOfQoYDqF1L FHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCcoCgrMFsROrIEX3o2w hVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eI xJJoUBc+3CbBuwZEV5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4se nwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvHESfCwVt5hTgYiqQqtdRNHQIU1PJ3 3ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKTmrKIN07AnGcI 9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9 aQcw9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgL L/r1R40BZEnuBWgmQEybjqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpb jVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPlfmh+xl4WtR0zGu24I4KbMQm3 lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIAOw== --0__=4EBBF2B9DFA5BFCE8f9e8a93df938690918c4EBBF2B9DFA5BFCE--

1 0

Re: (ITS#6404) tests return success on failure
by h.b.furuseth＠usit.uio.no 01 Feb '11

01 Feb '11

Reopening this ITS. tests/scripts/test038-retcode rev 1.9 can be imported to RE24, it's a mislabeled fix for this. I would commit the following fix for test020-proxycache, except I'd like to know why the test deliberately does 'exit 0' on some failures. 'exit 0' #1-4 are OK, but I do not understand the next 5 of them from: rev 1.34 (hyc) ITS#6152 add tests for cache refresh and Bind caching rev 1.35 (hyc) ITS#6152 test pwdModify If nothing else, these success exits should first give a message which clarifies that the condition which caused the exit is not a bug. As in hunk #1 below. Index: test020-proxycache --- test020-proxycache 4 Jan 2011 23:43:43 -0000 1.40 +++ test020-proxycache 1 Feb 2011 09:39:19 -0000 @@ -153,5 +153,5 @@ RC=$? if test $RC != 0 ; then - echo "Debug messages unavailable, test aborted..." + echo "Debug messages unavailable, remaining test skipped" test $KILLSERVERS != no && kill -HUP $KILLPIDS && wait exit 0 @@ -257,5 +257,5 @@ echo "ldapsearch should have failed!" test $KILLSERVERS != no && kill -HUP $KILLPIDS - exit $RC + exit 1 ;; 4) @@ -284,5 +284,5 @@ echo "ldapsearch should have failed!" test $KILLSERVERS != no && kill -HUP $KILLPIDS - exit $RC + exit 1 ;; 4) @@ -407,5 +407,5 @@ echo "ldapsearch should have failed!" test $KILLSERVERS != no && kill -HUP $KILLPIDS - exit $RC + exit 1 ;; 4) @@ -434,5 +434,5 @@ echo "ldapsearch should have failed!" test $KILLSERVERS != no && kill -HUP $KILLPIDS - exit $RC + exit 1 ;; 4) -- Hallvard

1 0

Re: (ITS#6755) ldapsearch crashes - double free or corruption (!prev): 0x0989f5f8
by hyc＠symas.com 01 Feb '11

01 Feb '11

hyc(a)symas.com wrote: > Howard Chu wrote: >> jgilmour(a)techsmog.com wrote: >>> Full_Name: Josh Gilmour >>> Version: ldapsearch 2.3.43 (Nov 29 2010 03:47:14) >>> OS: CentOS release 5.4 32bit >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (38.112.23.58) >>> >>> >>> I get a segfault when using the following command and applying a filter file. If >>> we remove the -f, the command runs properly. It doesn't seem to be a major >>> security issue (or one at all, I'm not sure), but it does seem to be a bug I >>> believe... >> >> OpenLDAP 2.3 is no longer supported. If you can reproduce this bug in a >> current release please followup with the relevant stack trace, otherwise this >> ITS will be closed. Currently I see no such symptom in 2.4.x. >> > Valgrind disagreed with me, the bug was still present in 2.4. Fixed in HEAD. > But the fix needs some more thought. I don't believe this combination of options actually makes any sense; we should probably just disallow it. -- -- 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#6818) back-meta: do not denormalize attrs without equality rule
by h.b.furuseth＠usit.uio.no 01 Feb '11

01 Feb '11

masarati(a)aero.polimi.it writes: > Subject: (ITS#6818) back-meta: do not denormalize attrs without equality rule Is this denormalizion a user-visible or internal matter? -- Hallvard

1 0

Re: (ITS#6755) ldapsearch crashes - double free or corruption (!prev): 0x0989f5f8
by hyc＠symas.com 31 Jan '11

31 Jan '11

Howard Chu wrote: > jgilmour(a)techsmog.com wrote: >> Full_Name: Josh Gilmour >> Version: ldapsearch 2.3.43 (Nov 29 2010 03:47:14) >> OS: CentOS release 5.4 32bit >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (38.112.23.58) >> >> >> I get a segfault when using the following command and applying a filter file. If >> we remove the -f, the command runs properly. It doesn't seem to be a major >> security issue (or one at all, I'm not sure), but it does seem to be a bug I >> believe... > > OpenLDAP 2.3 is no longer supported. If you can reproduce this bug in a > current release please followup with the relevant stack trace, otherwise this > ITS will be closed. Currently I see no such symptom in 2.4.x. > Valgrind disagreed with me, the bug was still present in 2.4. Fixed in HEAD. -- -- 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#6810) slapd crashes writing to bdb backend
by quanah＠zimbra.com 31 Jan '11

31 Jan '11

--On Friday, January 28, 2011 9:47 AM +0000 bruno_haleblian(a)carrefour.com wrote: > Full_Name: Bruno HALEBLIAN > Version: 2.4.23 > OS: RHEL 5.5/64 bits > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (92.243.12.111) > > > Hello, > I'm stuck with "random" slapd crashes, my slapd has been tested > successfully in read mode but since I run updates, I get several crashes > a day, with no BDB corruption (recover and restart OK) but I can't let > this go to production stage. > > Here's the first core stack I caught, I'll send more if I meet different > ones. > > Thanks for your help. Hi Bruno, What type of filesystem is BDB located on? I.e., NFS, ext3, SAN, etc. Also, what version of BDB are you using from Oracle? Can you provide your configuration file/cn=config directory (minus any passwords)? Thanks, Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6816) Patch - Mozilla NSS - documentation changes
by quanah＠zimbra.com 31 Jan '11

31 Jan '11

--On Monday, January 31, 2011 9:04 PM +0000 hyc(a)symas.com wrote: > rmeggins(a)redhat.com wrote: >> Full_Name: Rich Megginson >> Version: 2.4.23 (current CVS HEAD) >> OS: RHEL6 >> URL: >> ftp://ftp.openldap.org/incoming/openldap-2.4.23-add-moznss-to-docs-20110 >> 130.patch Submission from: (NULL) (76.113.111.209) >> >> >> This adds documentation for Mozilla NSS. Man page TLS settings and >> directives, and Admin Guide. I tested the man pages, but I wasn't sure >> how to generate the docs from the .sdf files - hopefully they will work >> ok without extensive changes. > > Thanks, just needed some minor touch up. With this in place I've decided > we're ready to advertise support for Mozilla NSS now, so I've rolled in > the configure.in patch (from ITS#5698) into RE24. technically, ITS#5696, if anyone is tracking this bug. :P --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6816) Patch - Mozilla NSS - documentation changes
by hyc＠symas.com 31 Jan '11

31 Jan '11

rmeggins(a)redhat.com wrote: > Full_Name: Rich Megginson > Version: 2.4.23 (current CVS HEAD) > OS: RHEL6 > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-add-moznss-to-docs-20110130… > Submission from: (NULL) (76.113.111.209) > > > This adds documentation for Mozilla NSS. Man page TLS settings and directives, > and Admin Guide. I tested the man pages, but I wasn't sure how to generate the > docs from the .sdf files - hopefully they will work ok without extensive > changes. Thanks, just needed some minor touch up. With this in place I've decided we're ready to advertise support for Mozilla NSS now, so I've rolled in the configure.in patch (from ITS#5698) into RE24. > These patch files are 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, Rich Megginson 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. -- -- 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

(ITS#6818) back-meta: do not denormalize attrs without equality rule
by masarati＠aero.polimi.it 31 Jan '11

31 Jan '11

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2.40.14.92) Submitted by: ando A fix is coming. p.

1 0

(ITS#6817) idassert-bind with SASL issues
by masarati＠aero.polimi.it 31 Jan '11

31 Jan '11

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2.40.14.92) Submitted by: ando When idassert-bind is configured to use SASL bind, an "authcID" needs to be provided, while the "binddn" is not needed. However, if a "binddn" is not provided as well, in some cases the proxiedAuthz control may be used incorrectly. The need to configure the "binddn" is not documented, so this ITS is minimally addressed by documenting this requirement. If the "binddn" is provided, everything works as expected, with the only minor issue that the DN of the user as it is known to back-meta may not match the actual identity the "authcID" assumed on the remote server. The "right" way to address this problem consists in performing a "WhoAmI" (RFC 4532) right after the bind, or better use a "authorization identity control" (RFC 3829) along with the bind operation. Both approaches should be implemented, but they should not be used unless explicitly requested. p.

1 0

(ITS#6816) Patch - Mozilla NSS - documentation changes
by rmeggins＠redhat.com 31 Jan '11

31 Jan '11

Full_Name: Rich Megginson Version: 2.4.23 (current CVS HEAD) OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-add-moznss-to-docs-20110130… Submission from: (NULL) (76.113.111.209) This adds documentation for Mozilla NSS. Man page TLS settings and directives, and Admin Guide. I tested the man pages, but I wasn't sure how to generate the docs from the .sdf files - hopefully they will work ok without extensive changes. These patch files are 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, Rich Megginson 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

Re: (ITS#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth
by subbarao＠computer.org 31 Jan '11

31 Jan '11

This is a multi-part message in MIME format. --------------090509020601080703090604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 01/28/2011 08:27 PM, Howard Chu wrote: >> I'm running into multiple problems here. The core problem seems to be >> that enabling ppolicy_forward_updates breaks the chaining overlay such that >> it binds anonymously instead of with SASL EXTERNAL. > > That's because your authz-regexp is wrong. You mapped "cn=localhost" but > when using SASL EXTERNAL, the user's DN is the complete certificate DN. > In your case, "cn=localhost,o=OpenLDAP,st=Some-State,c=US" > > The reason this didn't break replication is because in this test, > everything has anonymous read access so the consumer was able to pull > what it needed. Hmm, I'm not quite seeing what you're saying here. For example, in slapd.1.log, *before* ppolicy_forward_updates (olcPPolicyForwardUpdates) is enabled, I can see the certificate being mapped exactly as I expect it: ===== ==> rewrite_context_apply [depth=1] res={0,'cn=localhost,dc=example,dc=com'} [rw] authid: "cn=localhost,o=openldap,st=some-state,c=us" -> "cn=localhost,dc=example,dc=com" [...] <==slap_sasl2dn: Converted SASL name to cn=localhost,dc=example,dc=com slap_sasl_getdn: dn:id converted to cn=localhost,dc=example,dc=com SASL Canonicalize [conn=1004]: slapAuthcDN="cn=localhost,dc=example,dc=com" SASL proxy authorize [conn=1004]: authcid="cn=localhost,o=openldap,st=some-state,c=us" authzid="cn=localhost,o=openldap,st=some-state,c=us" conn=1004 op=1 BIND authcid="cn=localhost,o=openldap,st=some-state,c=us" authzid="cn=localhost,o=openldap,st=some-state,c=us" SASL Authorize [conn=1004]: proxy authorization allowed authzDN="" send_ldap_sasl: err=0 len=-1 conn=1004 op=1 BIND dn="cn=localhost,dc=example,dc=com" mech=EXTERNAL sasl_ssf=0 ssf=256 do_bind: SASL/EXTERNAL bind: dn="cn=localhost,dc=example,dc=com" sasl_ssf=0 ===== Based on this, I'm assuming that my authz-regexp is behaving as I'm intending -- looking for a certificate with "cn=localhost" anywhere in the subject DN, and mapping that to the DN cn=localhost,dc=example,dc=com in the directory. It's only *after* olcPPolicyForwardUpdates is enabled that the SASL EXTERNAL authentication stops working. Can you help me understand the disconnect between what I'm seeing and what you're saying? > I didn't get this far because your test certificate is now expired. I > guess I can substitute some other certs and look at it again, but I > think the core issue is your misconfigured authz-regexp. I have updated the expiration date on the certificate and have attached it to this message. > Better to rename your scripts when you modify one of our existing ones. > E.g. test999-xxxxxx and just create new data files instead of modifying > ours. Ok, will keep this in mind. Thanks, -Kartik --------------090509020601080703090604 Content-Type: text/plain; name="localhost.crt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="localhost.crt" -----BEGIN CERTIFICATE----- MIICCTCCAXICCQC1gKCIQ2we4DANBgkqhkiG9w0BAQUFADBJMQswCQYDVQQGEwJV UzETMBEGA1UECBMKU29tZS1TdGF0ZTERMA8GA1UEChMIT3BlbkxEQVAxEjAQBgNV BAMTCWxvY2FsaG9zdDAeFw0xMTAxMzExNjE1NTdaFw0xMjAxMzExNjE1NTdaMEkx CzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpTb21lLVN0YXRlMREwDwYDVQQKEwhPcGVu TERBUDESMBAGA1UEAxMJbG9jYWxob3N0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQCqZU3fA/o/y5gHXxm0JpdMoV64LAOIPgcZTHv4+OkVjoW2gMHT8AMerJzk Cr07y1JjfeqV1c7sZl6+aqC3H+HLs0cCtXFKPFY9FmoehO9KBksDaH5o2f7h104r s/xg2cNTDy1dFFJUzMWQIc8TU7+GpjS3gP0/9gNlIyiLdio9LwIDAQABMA0GCSqG SIb3DQEBBQUAA4GBAGFeVSjX4ZjLmrU7oob4CyoWO2ekeVyldWLjVOUCyeSMae3n I1/kQ5AbGrJdtQQeLyRhIQKUM2a1AqjPLW1QKPXHnHnbsnzuWmC2C9fIw1C3o0yZ UBsxlqoA7K486qeyAb6bUO5X2JD2rOng+HL/pgKlo9h8dW23tWj4CEUMepOh -----END CERTIFICATE----- --------------090509020601080703090604--

1 0

Re: (ITS#6806) Invalid ldapadd crashes openldap with ndb backend
by anderson＠vailsys.com 31 Jan '11

31 Jan '11

I thought I had attached the backtrace when I opened this, sorry. Here is the backtrack from 2.4.23. Compile Options: ./configure --enable-ndb --enable-passwd --enable-modules --enable-slp --enable-crypt --enable-overlays --enable-dynamic --enable-syslog --enable-debug --enable-auditlog --disable-cleartext --enable-wrappers --enable-ppolicy mysql-cluster-gpl-7.1.9a binary distribution from oracle. Line 339 in NdbTransaction.cpp didn't refer to a file that I saw. Let me know if anything else is needed. #0 NdbTransaction::execute (this=0x7fa1ae235659, aTypeOfExec=NdbTransaction::Rollback, abortOption=NdbOperation::DefaultAbortOption, forceSend=0) at NdbTransaction.cpp:339 339 NdbTransaction.cpp: No such file or directory. in NdbTransaction.cpp (gdb) bt #0 NdbTransaction::execute (this=0x7fa1ae235659, aTypeOfExec=NdbTransaction::Rollback, abortOption=NdbOperation::DefaultAbortOption, forceSend=0) at NdbTransaction.cpp:339 #1 0x00000000004f8608 in ndb_back_add () #2 0x000000000043ce34 in fe_op_add () #3 0x000000000043d695 in do_add () #4 0x0000000000435dd9 in ?? () #5 0x000000000043662d in ?? () #6 0x00007fa1b0f43538 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #7 0x00007fa1af7729ca in start_thread () from /lib/libpthread.so.0 #8 0x00007fa1ae27a70d in clone () from /lib/libc.so.6 #9 0x0000000000000000 in ?? () > As always, when you get a core dump, post the gdb backtrace of the dump. Use > the most recent release version, and make sure you use a non-optimized debug > build with all debug symbols intact. All of these instructions are written on > the page where you submit new Issues. >

1 0

Re: (ITS#6684) Patch for autogroup overlay
by moenoel＠informatik.uni-bremen.de 31 Jan '11

31 Jan '11

Am 29.01.2011 21:10, schrieb hyc(a)symas.com: > moenoel(a)informatik.uni-bremen.de wrote: >>> 1) it should simply be comparing the AttributeDescription pointers >>> 2) since the "memberof" attribute is actually configurable in the memberof >>> overlay, there's no guarantee that this is the correct attribute to be looking >>> for. It should also be configurable in your patch. >>> >>> You're using strcasecmp, but your inputs are already normalized values. You >>> should just use ber_bvcmp. >>> >> >> Since I am also interested in this, I took some time to make a new >> patch. I took Norberts original patch, applied it to a current checkout >> from HEAD and tried to fix the issues mentioned by Howard. My initial >> tests are looking good. >> >> My C skills are rather mediocre, though, so I hope I didn't slaughter >> the thing :-) >> >> http://www.informatik.uni-bremen.de/~moenoel/ldap/christian-manal-autogroup… > > This patch looks pretty good. There are only one or two minor issues with it, > which I will clean up. (E.g., config actions require no mutexes; slapd is > always single-threaded when processing config changes.) > Great, thanks!

1 0

ITS#6815
by masarati＠aero.polimi.it 30 Jan '11

30 Jan '11

> This request is spotted by some ldap clients that I have that every > 30seconds do a dummy ldap search only to keep alive their connection > to the ldap server. These searches are frequent and I have many of > these clients in my deploy, so my accesslog become full of not > significant entries. For this specific purpose, your clients could perform an operation that is not logged; for example, search the rootDSE. p.

1 0

(ITS#6815) Feature Request: Accesslog filter
by marco.pizzoli＠gmail.com 30 Jan '11

30 Jan '11

Full_Name: Marco Pizzoli Version: ALL OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.41.84.11) Hi, this is a feature request. I would like to have accesslog writing to his db only ldap operations that match some sort of filter, or, in particular, to not to log searches that matches a specific pattern. This request is spotted by some ldap clients that I have that every 30seconds do a dummy ldap search only to keep alive their connection to the ldap server. These searches are frequent and I have many of these clients in my deploy, so my accesslog become full of not significant entries. Thanks in advance Marco Pizzoli

1 0

Re: (ITS#5733) tainted connection
by richton＠nbcs.rutgers.edu 30 Jan '11

30 Jan '11

On Sat, 29 Jan 2011, Howard Chu wrote: > Are people still running into this? Seems like not. Time to close this > issue? I haven't seen it in a while. Closing seems reasonable.

1 0

Re: (ITS#5733) tainted connection
by hyc＠symas.com 29 Jan '11

29 Jan '11

richton(a)nbcs.rutgers.edu wrote: > I saw this three times in testing of HEAD. One backtrace and -d -1: > > https://www.nbcs.rutgers.edu/~richton/test039-bt-200906200640.txt > https://www.nbcs.rutgers.edu/~richton/test039-slapdlog-200906200640.txt > > > These are under libumem with transaction logging enabled. All malloc/free > for a given block can be retrieved, in theory... Are people still running into this? Seems like not. Time to close this 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#6749) Shut up "configure monitor database to enable"
by h.b.furuseth＠usit.uio.no 29 Jan '11

29 Jan '11

masarati(a)aero.polimi.it writes: >> Please don't give the "configure monitor database to enable" message >> by default. >> >> Either just remove it, or better, stop cn=config from adding a default >> olcMonitoring: TRUE attribute to olcDatabase objects. (The flag value >> can still default to True if the attribute is absent.) Then you can >> give the message if the _admin_ has explicitly asked for monitoring, >> instead of if slapd has asked for it. > > I disagree; it is not cn=config that defaults database monitoring to TRUE; > actually, it's back-bdb/back-hdb that sets its own monitoring to TRUE as > soon as back-monitor support is compiled and the specific backend > monitoring is successfully initilized. If the admin put 'olcMonitoring: TRUE' in slapd.d but did not include database monitor, that would be poor user config. I'm fine with having bdb set the internal default flag value to TRUE. My protest in that context is against slapd - be it back-bdb or back-config which is to blame - writing the default value to the cn=config LDIF even though the admin never mentioned monitoring. This means that neither the TRUE value of the internal flag nor the presence of the attribute is an indication that the admin asked for monitoring (i.e. set the flag) but forgot to add database monitor. > Maybe this warning can be demoted to LDAP_DEBUG_CONFIG instead of > LDAP_DEBUG_ANY. Yes. Maybe slapd should nag the admin more about bad config, but if so there are plenty of other things which are more important than this and should get a chance to nag the admin before this particular flag gets to do it. IIRC the only other thing which gets to do that now is BDB without DB_CONFIG - which makes sense since that's an entire non-OpenLDAP subsystem which has not been configured. But also: > I understand that one could presume that the lack of database monitor > in the configuration indicates that monitoring is not desired; this > warning, however, tries to address a typical configuration error, when > admins just forget to configure it. No, this is a broken slapd default. It should not be an admin error to not mention a feature he does not want and does not need to know about. And if slapd does nag anyone about it, it should nag admins who do mention either database monitor or the flag, not admins who do not. So slapd should be quiet if it set the flag internally and the admin does not include database monitor. Thus my suggestion to set the flag internally by default but only nag the admin if it was set in cn=config. Unless olcMonitoring:TRUE is a drain on performance or something so it really ought to be off when the data is not used anyway. An alternative (and a change in behavior from now) if you really want this warning, would be to always default monitoring to off. That'll surprise existing users, so the cn=monitor objects could contain some text 'monitoring off for this database, set olcMonitoring to enable'. Personally I don't think a warning is worth such a change in behavior, but then I don't like the warning anyway:-) -- Hallvard

1 0

Re: (ITS#6811) Patch - Mozilla NSS - disable pkcs11 fork checking for the software token
by hyc＠symas.com 29 Jan '11

29 Jan '11

richm(a)stanfordalumni.org wrote: > The NSS_STRICT_NOFORK environment variable is documented here: > https://developer.mozilla.org/en/NSS_reference/NSS_environment_variables > > Note that if a user really wants the strict pkcs11 behavior, the user > can set the variable to "1" or some other non-empty value (other than > "DISABLED"). > > If you think further documentation is required, I would be happy to > update the Admin Guide, FAQ-o-matic, man pages, etc. That looks fine. Most of our docs were written specifically to OpenSSL but we've added one or two references to GnuTLS since then. I would start by adding to the FAQ-o-Matic: http://www.openldap.org/faq/data/cache/196.html I guess we could update this to mention the availability of GnuTLS and MozNSS support and perhaps a discussion of their pros and cons. (Though in all honesty I cannot think of any pros for using GnuTLS. I would use PolarSSL instead but that's not what the Debian folks asked for...) Hm, this entire FAQ page is far out of date. If you want to add some MozNSS info here go ahead, I'll take a pass at the rest of the page later. -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs