openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#6652) accesslog anomaly in db drop/re-import
by h.b.furuseth＠usit.uio.no 01 Feb '11

01 Feb '11

masarati(a)aero.polimi.it writes: > Sorry, I overlooked part of your message. And I was too tired to read it right too:-) Need to get the right branch at least. I was thinking of the version at shown at cvsweb, which showed that one first. -- Hallvard

1 0

Re: (ITS#6652) accesslog anomaly in db drop/re-import
by h.b.furuseth＠usit.uio.no 01 Feb '11

01 Feb '11

marco.pizzoli(a)gmail.com writes: > I downloaded the HEAD repository, compiled and tried the import. Same > problem on the same line. > (...) > Had I downloaded the wrong repository? Probably not, but you can check CVS/Root - it should contain :pserver:anonymous@cvs.OpenLDAP.org:/repo/OpenLDAP However, try again now. The public CVS repository it is regularly synced with the main repository, but you may have updated from it before the patch reached it. > I went to see the version of the source accesslog.c and saw this line on top > of it: > /* accesslog.c - log operations for audit/history purposes */ > /* $OpenLDAP: pkg/ldap/servers/slapd/overlays/accesslog.c,v 1.37.2.34 * > 2011/01/26* 23:23:34 quanah Exp $ */ That from the release branch, which has not merged this patch. HEAD is the main branch used for development, currently with accesslog 1.115. -- Hallvard

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, > I downloaded the HEAD repository, compiled and tried the import. Same > problem on the same line. > > I went to see the version of the source accesslog.c and saw this line on top > of it: > /* accesslog.c - log operations for audit/history purposes */ > /* $OpenLDAP: pkg/ldap/servers/slapd/overlays/accesslog.c,v 1.37.2.34 * > 2011/01/26* 23:23:34 quanah Exp $ */ > > Had I downloaded the wrong repository? Sorry, I overlooked part of your message. Yes, you appear to be using the wrong repository. My commit resulted in accesslog.c 1.115. p.

1 0

Re: ITS#6815
by marco.pizzoli＠gmail.com 01 Feb '11

01 Feb '11

--001636e0a68c56af9b049b3a400d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, yes but not all my clients are so flexible. A helpful usage, in my deploy, would be in populating a database with only BIND operations. By now this is not possible. Thanks Marco Pizzoli On Sun, Jan 30, 2011 at 9:12 PM, <masarati(a)aero.polimi.it> wrote: > > 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 i= s > not logged; for example, search the rootDSE. > > p. > > --=20 _________________________________________ Non =E8 forte chi non cade, ma chi cadendo ha la forza di rialzarsi. Jim Morrison --001636e0a68c56af9b049b3a400d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, yes but not all my clients are so flexible. A helpful usage,= in my deploy, would be in populating a database with only BIND operations.= By now this is not possible. Thanks =A0=A0=A0=A0=A0 Marco Pizzol= i <div class=3D"gmail_quote">On Sun, Jan 30, 2011 at 9:12 PM, <<a href=3D"mailto:masarati@aero.polimi.it">masarati(a)aero.polimi.it<= /a>> wrote: <blockquote class=3D"gmail_quote" style=3D"margin:= 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left= : 1ex;"> > This request is spotted by some ldap clients that I have that every<br= > > 30seconds do a dummy ldap search only to keep alive their connection<b= r> > 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<= br> not logged; for example, search the rootDSE. 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> --001636e0a68c56af9b049b3a400d--

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, > I downloaded the HEAD repository, compiled and tried the import. Same > problem on the same line. The fix in HEAD fixes the writing of the accesslog entry; you need to try it with a new search on a fresh database, then a slapcat, then a slapadd. Old databases and LDIFs are corrupted and need to be fixed otherwise (e.g. ldapmodify->replace of the reqAttr without the empty value, which is invalid per LDAPString syntax. p.

1 0

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

01 Feb '11

--000e0cd29c8c87a456049b38f23c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, I downloaded the HEAD repository, compiled and tried the import. Same problem on the same line. I went to see the version of the source accesslog.c and saw this line on to= p of it: /* accesslog.c - log operations for audit/history purposes */ /* $OpenLDAP: pkg/ldap/servers/slapd/overlays/accesslog.c,v 1.37.2.34 * 2011/01/26* 23:23:34 quanah Exp $ */ Had I downloaded the wrong repository? Thanks Marco Pizzoli On Tue, Feb 1, 2011 at 1:10 PM, Pierangelo Masarati <masarati(a)aero.polimi.i= t > wrote: > Marco Pizzoli wrote: > >> Hi, >> the (same?) problem arises again. >> >> I downloaded the upgraded source, created a new accesslog and today trie= d >> to >> 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 >> > > A fix is in HEAD (ITS#6819); more is coming. Please test. Thanks, p. > --=20 _________________________________________ Non =E8 forte chi non cade, ma chi cadendo ha la forza di rialzarsi. Jim Morrison --000e0cd29c8c87a456049b38f23c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, I downloaded the HEAD repository, compiled and tried the import. Sam= e problem on the same line. I went to see the version of the source = accesslog.c and saw this line on top of it: /* accesslog.c - log operati= ons for audit/history purposes */ /* $OpenLDAP: pkg/ldap/servers/slapd/overlays/accesslog.c,v 1.37.2.34 20= 11/01/26 23:23:34 quanah Exp $ */ Had I downloaded the wrong rep= ository? Thanks =A0=A0=A0=A0=A0 Marco Pizzoli <div cla= ss=3D"gmail_quote"> On Tue, Feb 1, 2011 at 1:10 PM, Pierangelo Masarati <<= a href=3D"mailto:masarati@aero.polimi.it">masarati(a)aero.polimi.it</a>></= span> wrote: <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt = 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div><div></div><div class=3D"h5">Marco Pizzoli wrote: <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> 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=3Dl= og03,dc=3D <a href=3D"http://mycorp.it" target=3D"_blank">mycorp.it</a>" -l dump_= ldap_dblog_20110201.ldif .### =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 17.14% eta 01h17m elapsed =A0 =A0 = =A0 =A0 =A015m56s 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) _### =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 17.14% eta 01h17m elapsed =A0 =A0 = =A0 =A0 =A015m56s spd 330.0 k/s Closing DB... The corrupted entry is: dn: reqStart=3D20110128141509.000004Z,cn=3Dlog03,dc=3D<a href=3D"http://myc= orp.it" target=3D"_blank">mycorp.it</a> objectClass: auditSearch structuralObjectClass: auditSearch reqStart: 20110128141509.000004Z reqEnd: 20110128141510.000000Z reqType: search reqSession: 6521 reqAuthzID: cn=3DManager,dc=3Dmyregion,dc=3D<a href=3D"http://mycorp.it" ta= rget=3D"_blank">mycorp.it</a> reqDN: uid=3Dpe1748,ou=3DPeople,dc=3Dmyregion,dc=3D<a href=3D"http://mycorp= .it" target=3D"_blank">mycorp.it</a> 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=3D<a href=3D"http://mycorp.it" tar= get=3D"_blank">mycorp.it</a> createTimestamp: 20110128141510Z entryCSN: 20110128141510.000116Z#000000#003#000000 modifiersName: cn=3DManager,cn=3Dlog03,dc=3D<a href=3D"http://mycorp.it" ta= rget=3D"_blank">mycorp.it</a> modifyTimestamp: 20110128141510Z </blockquote> </div></div> A fix is in HEAD (ITS#6819); more is coming. =A0Please test. =A0Thanks, p.<= br> </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> --000e0cd29c8c87a456049b38f23c--

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 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

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