Re: (ITS#6652) accesslog anomaly in db drop/re-import

[masarati@aero.polimi.it]

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