[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 that.
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.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Pierangelo Masarati wrote:
[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 that.
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.
It looks like that format was used in OpenLDAP 2.1, which would agree with the 2002 timestamp in it.
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.
I had forgotten we had CSNs back in OL 2.1; they were never actually relied on by anything else until OL 2.2...
openldap-software@openldap.org
-
Howard Chu -
Pierangelo Masarati