[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: OpenLDAP 2.4

[please keep replies on the list]

Allan E. Johannesen wrote:
>>>>>> "ando" == Pierangelo Masarati <ando@sys-net.it> writes:
>> Allan E. Johannesen wrote:
>>> Hmmm.  Looking at the code as I type this, perhaps the only evil one is the
>>> one with colons and the "0x" hex field.  If I change
>>> entryCSN: 2002120818:17:53Z#0x0061#0#0000
> ando> This really looks evil.  I think that assert needs to be relaxed into a
> ando> run-time error, but I don't really see how that data could have made it
> ando> into your database.  The old syntax should be allowed, as far as I can
> ando> remember.  In any case, slapadd should tell you exactly what entry
> ando> couldn't be imported, you should be able to check what the offending
> ando> entryCSN looks like.
> I don't think it's "evil", but simply "old".

I think it's evil because I don't recall the CSN syntax ever being like

> Unless I was typing in my sleep,
> I never put any CSN into the database.

I'm not blaming you.

>  Some version of slapd must have done it.

Well, unless you imported that data from some other DSA, I agree it had
to be slapd at some point.

> I looked at what 2.4.6 does with "old", but "not THAT old", CSNs,

That's my point: "THAT old" should not be, that's the reason of that
assert: make sure only known formats get there during CSN handling
development.  Of course, in production a run-time error would be better,
since one can never know how and why garbage gets there.

In any case, I believe rewriting those CSNs according to either old or
new format should solve your problem.  Of course, if entryCSN's like
that surface again, there must be some piece of software that generates
them.  In that case, further investigation will be required.


Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
Office:  +39 02 23998309
Mobile:  +39 333 4963172
Email:   pierangelo.masarati@sys-net.it