Comment 22 for bug 14929

Revision history for this message
In , Steve Langasek (vorlon) wrote : Re: Bug#302629: slapd: Unstable upgrade (2.1 -> 2.2) failures

On Mon, Apr 18, 2005 at 11:41:48AM +0200, Torsten Landschoff wrote:
> > 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

> > > > 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?

> 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!

Well, I understood that they were coming from his existing directory because
that's how they had been input?

> > 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.

Would be nice, but I don't think there is such a thing in Debian yet. In
the meantime, here are the attributeTypes in the Debian-provided schemas
that use syntax 1.3.6.1.4.1.1466.115.121.1.27:

mailPreferenceOption
uidNumber
gidNumber
shadowLastChange
shadowMin
shadowMax
shadowWarning
shadowInactive
shadowExpire
shadowFlag
ipServicePort
ipServiceProtocol
ipProtocolNumber
oncRpcNumber

There are of course plenty of other schemas that will use this common
syntax; it's used by both krb5-kdc and samba schemas that I have on hand.

--
Steve Langasek
postmodern programmer