openldap-bugs January 2011

openldap-bugs@openldap.org

36 participants
177 discussions

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

02 Jan '11

>> 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. Spotted (and fixed) the bug in the enconding part of control values. It shouldnow be fixed. Please test and report. p.

1 0

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

02 Jan '11

> 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 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=log,dc=mycorp.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=4907) > - 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=20100913065628.000008Z,cn=log,dc=mycorp.it > objectClass: auditSearch > structuralObjectClass: auditSearch > reqStart: 20100913065628.000008Z > reqEnd: 20100913065628.000009Z > reqType: search > reqSession: 1129 > reqAuthzID: > cn=syncrepl-ldap04,ou=utenze_tecniche_openldap,ou=Gestori,dc=mycorp.it > reqControls: {0}{1.3.6.1.4.1.4203.1.9.1.1 controlValue > "30440K0103043M7269643N > 3030332M7369643N3030342M63736O3N32303130303931333036353130362O3932343735355K2 > 330303030303023303033233030303030300001PP"} > reqControls: {1}{2.16.840.1.113730.3.4.2 criticality TRUE} > reqDN: dc=mycorp.it > reqResult: 0 > reqScope: base > reqDerefAliases: never > reqAttrsOnly: TRUE > reqFilter: (objectclass=*) > reqAttr: 1.1 > reqEntries: 0 > reqTimeLimit: -1 > reqSizeLimit: 1 > entryUUID: 2beb0bd0-ba32-4a00-93da-748ef2177cc7 > creatorsName: cn=Manager,cn=log,dc=mycorp.it > createTimestamp: 20100913065628Z > entryCSN: 20100913065628.167225Z#000000#003#000000 > modifiersName: cn=Manager,cn=log,dc=mycorp.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 my > deployment, which is in mirrormode(=true). > 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=log,dc=mycorp.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=3099715) > * 4.70% eta 01h07m elapsed 03m20s spd 979.8 > k/s > Closing DB... > --- END > > The "corrupted" entry is this one: > > --- BEGIN > dn: reqStart=20100913093021.000000Z,cn=log,dc=mycorp.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=pe1597,ou=People,dc=mycorp.it > reqResult: 0 > reqVersion: 3 > reqMethod: SIMPLE > entryUUID: 192cbddf-4b5c-431d-a92e-c2f84fa4b7be > creatorsName: cn=Manager,cn=log,dc=mycorp.it > createTimestamp: 20100913093021Z > entryCSN: 20100913093021.411398Z#000000#003#000000 > modifiersName: cn=Manager,cn=log,dc=mycorp.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.

1 0

Re: (ITS#6749) Shut up "configure monitor database to enable"
by masarati＠aero.polimi.it 02 Jan '11

02 Jan '11

> Full_Name: Hallvard B Furuseth > Version: 2.4.23 > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > 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. Maybe this warning can be demoted to LDAP_DEBUG_CONFIG instead of LDAP_DEBUG_ANY. 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. p.

1 0

Re: (ITS#6700) memberOf overlay does not handle MODRDN correctly
by masarati＠aero.polimi.it 01 Jan '11

01 Jan '11

> raphael.ouazana(a)linagora.com wrote: > >> When using memberOf overlay, a MODRDN request on a member does not >> update >> correctly the matching group, even if the memberof-refint option is set >> to >> true. >> >> In my little understanding, memberof_value_modify calls >> op->o_bd->be_modify >> which calls back the overlay code, and finally never reach the backend. > > Guess what, modrdn is the only operation test052 does not check :( > WOrking at it. Thanks, p. Fixed in HEAD; please test and report. Please note that test052 and the corresponding expected output data have been modified to check modrdn. p.

1 0

(ITS#6765) Server-side support of "Verify Credentials" extop
by masarati＠aero.polimi.it 01 Jan '11

01 Jan '11

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2.40.10.16) Submitted by: ando Added module in contrib/slapd-modules/vc/; no spec yet, simply mimicking the companion of what is currently implemented in libraries/libldap/vc.c. The current code should support SASL; untested yet, since the client does not implement SASL support yet. p.

1 0

(ITS#6764) ber_flatten() should return -1 on unmatched "{" "}"
by masarati＠aero.polimi.it 01 Jan '11

01 Jan '11

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2.40.10.16) Submitted by: ando also per <draft-ietf-ldapext-ldap-c-api>. p.

1 0

Re: (ITS#6758) Cleaning up SlapReply usage
by hyc＠symas.com 31 Dec '10

31 Dec '10

h.b.furuseth(a)usit.uio.no wrote: > Mostly done with the easily spotted cases. Hopefully HEAD's code > stayed valid through my commits. Need to think some more for the > rest. The decisions with greater chance of breaking things > remain, like ITS#6763. > > Other issues: > > * hyc, please have a look at slapd/bconfig.c 1.419. If I have > gotten things wrong, that one summarizes my mistakes nicely:-) I think you're over-paranoid. config_build_entry() is only called by internal plumbing and the SlapReply here never gets sent to send_ldap_result(). It's only passed in because be_add() expects one; the contents are mostly irrelevant. (Aside from rs_err) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs January 2011