Comment 25 for bug 14929

Message-ID: <email address hidden>
Date: Mon, 18 Apr 2005 01:56:17 -0700
From: Steve Langasek <email address hidden>
To: Torsten Landschoff <email address hidden>, <email address hidden>
Cc: Richard A Nelson <email address hidden>
Subject: Re: Bug#302629: slapd: Unstable upgrade (2.1 -> 2.2) failures

--L6iaP+gRLNZHKoI4
Content-Type: multipart/mixed; boundary="z6Eq5LdranGa6ru8"
Content-Disposition: inline

--z6Eq5LdranGa6ru8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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:=20
> > - directory dc=3Dcavein,dc=3Dorg... slapadd: could not parse entry
> > (line=3D316) 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? =20

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

Cheers,
--=20
Steve Langasek
postmodern programmer

--z6Eq5LdranGa6ru8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="openldap2.2-302629.patch"
Content-Transfer-Encoding: quoted-printable

Index: debian/fix_ldif
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- debian/fix_ldif (revision 516)
+++ debian/fix_ldif (working copy)
@@ -361,7 +361,13 @@
 }
=20
 #
-# Check required attributes.
+# Check required attributes, and fix up known attributes for which the
+# syntax has changed
+# Bad hack: the "fix up" should be replaced by something which knows
+# about schemas and can fix all instances for all attributes of the
+# relevant attribute syntax (1.3.6.1.4.1.1466.115.121.1.27). For now,
+# we only check the most commonly affected attributes, which we also
+# happen to know are SINGLE-VALUE.
 #
 sub checkattrs
 {
@@ -386,6 +392,10 @@
      print STDERR "\n\n";
  }
     }
+ ${$entries{$dn}{'uidnumber'}}[0] =3D 0)
+ if (${$entries{$dn}{'uidnumber'}}[0] eq '0000');
+ ${$entries{$dn}{'gidnumber'}}[0] =3D 0)
+ if (${$entries{$dn}{'gidnumber'}}[0] eq '0000');
 }
=20
 #

--z6Eq5LdranGa6ru8--

--L6iaP+gRLNZHKoI4
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFCY3YxKN6ufymYLloRAoZ6AJ9jdGCiyWZ2H4Ouambw1QeWsut0lgCfS69E
DSRx9iB3fGDbly8FCbh9zYk=
=x0wb
-----END PGP SIGNATURE-----

--L6iaP+gRLNZHKoI4--