Comment 19 for bug 14929

On Sat, Apr 02, 2005 at 04:36:49AM +0200, Torsten Landschoff wrote:
> > 2) error in parsing the saved ldif file:
> > Setting up slapd (2.2.23-1) ...
> > Enabling LDAPv2 support... already enabled.
> > Updating config access directives... done.
> > Moving old database directories to /var/backups:
> > Loading from /var/backups/slapd-2.1.30-3:
> > - directory dc=cavein,dc=org... slapadd: could not parse entry
> > (line=316) failed.

> That's quite known an issue. If you consider this grave, we can't put
> slapd 2.2 in Debian as 2.2 fails on a lot of 2.1 and even more of 2.0
> directories. I am working on a README type upgrade document which tells
> the user.

I think it's worth a lot to provide as smooth of an upgrade path as
possible, and leave the README for cases we can't reasonably handle. Can
this particular LDIF incompatibility be dealt with in fix_ldif?

> > Well, that was a helpful message (I know, not your fault) :)

> I think it is - at least you got the line number...

> > The issue seems to be that slapcat created the root entry like this:
> > uidNumber: 0000
> > gidNumber: 0000

> > but slapadd barfs on that, saying it is an invalid number! Changing
> > the 0000 to 0 for the user and group settings worked fine

> ... and another incompatibility.

It would be better if fix_ldif knew about schemas and could therefore know
which entries to automatically change; but even without that, we could
safely edit the LDIF for this when it's a known attrib like uidNumber or
gidNumber, couldn't we?

A naive patch for this might look like the one attached.

Cheers,
--
Steve Langasek
postmodern programmer