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:
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 4.1.1466. 115.121. 1.27:
the meantime, here are the attributeTypes in the Debian-provided schemas
that use syntax 1.3.6.1.
mailPreferenceO ption
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