On Mon, Apr 18, 2005 at 01:56:17AM -0700, Steve Langasek wrote:
> 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
Yeah.
> this particular LDIF incompatibility be dealt with in fix_ldif?
In theory fix_ldif could be improved to handle all incompatibilities. If
we know them...
> > > The issue seems to be that slapcat created the root entry like this:
> > > uidNumber: 0000
> > > gidNumber: 0000
>=20
> > > but slapadd barfs on that, saying it is an invalid number! Changing
> > > the 0000 to 0 for the user and group settings worked fine
>=20
> > ... and another incompatibility.
>=20
> 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
I think we could. OTOH I'd rather find out where those "0000" values are
coming from. Or wtf "0000" is an invalid number. Crazy stuff!
> A naive patch for this might look like the one attached.
Yep, naive but might work. Not to mention that there might be other
integer fields which will go mad like this. I wonder if there is a perl
module with full schema parsing support which would make writing
something like this much easier.
Greetings
Torsten
--6TrnltStXW4iwmi0
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
Message-ID: <email address hidden>
Date: Mon, 18 Apr 2005 11:41:48 +0200
From: Torsten Landschoff <email address hidden>
To: Steve Langasek <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: Re: Bug#302629: slapd: Unstable upgrade (2.1 -> 2.2) failures
--6TrnltStXW4iwmi0 Disposition: inline Transfer- Encoding: quoted-printable
Content-Type: text/plain; charset=us-ascii
Content-
Content-
Hi Steve,=20
On Mon, Apr 18, 2005 at 01:56:17AM -0700, Steve Langasek wrote:
> 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
Yeah.
> this particular LDIF incompatibility be dealt with in fix_ldif?
In theory fix_ldif could be improved to handle all incompatibilities. If
we know them...
> > > The issue seems to be that slapcat created the root entry like this:
> > > uidNumber: 0000
> > > gidNumber: 0000
>=20
> > > but slapadd barfs on that, saying it is an invalid number! Changing
> > > the 0000 to 0 for the user and group settings worked fine
>=20
> > ... and another incompatibility.
>=20
> 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
I think we could. OTOH I'd rather find out where those "0000" values are
coming from. Or wtf "0000" is an invalid number. Crazy stuff!
> A naive patch for this might look like the one attached.
Yep, naive but might work. Not to mention that there might be other
integer fields which will go mad like this. I wonder if there is a perl
module with full schema parsing support which would make writing
something like this much easier.
Greetings
Torsten
--6TrnltStXW4iwmi0 pgp-signature; name="signature .asc" Description: Digital signature Disposition: inline
Content-Type: application/
Content-
Content-
-----BEGIN PGP SIGNATURE-----
HtVUb5EcRAm+ /AJ44t28EgeECeR b5bS8P+ SoAsHpLfwCeMuat yF6UOwg0=
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFCY4DcdQg
3dr4kIr1d2nnlWC
=GXzm
-----END PGP SIGNATURE-----
--6TrnltStXW4iw mi0--