[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: OpenLDAP 2.4.10 Import Errors

Thanks for your help here.....I am gradually learning.

The original server had the setting "schemacheck off" in slapd.conf.  I
discovered that the variable wasn't supported in 2.4 and commented it
out, but now I understand what it actually does.

I have updated several objectclasses in core.schema (probably bad
practice) and I can now successfully import most entries.  I need to add
some brand new objectclasses to finally fix things, which I am working
on now.  Thanks you for your help.


Please consider the environment... Do you need to print this email?

-----Original Message-----
From: Hallvard Breien Furuseth [mailto:h.b.furuseth@usit.uio.no] 
Sent: 03 October 2008 12:40
To: Lydon, Mark
Cc: openldap-technical@openldap.org
Subject: RE: OpenLDAP 2.4.10 Import Errors

Lydon, Mark writes:
> Thanks for this.  Having studied the standard schema files, there 
> seems to be no definition for the 'name' attribute (there is one entry

> that is commented out, if I uncomment it out LDAP complains about 
> duplicate
> attributes) - is it somehow "built-in" to the system?

Yes, it's hardcoded in the C source.  That's why it's commented out.

> I can't even add the attributes manually via the browser - I see error

> in the slapd log saying; ntry (o=ATT,dc=npr), attribute 
> 'openscheduledreports' not allowed entry failed schema check: 
> attribute 'openscheduledreports' not allowed
> conn=1 op=7 RESULT tag=103 err=65 text=attribute
> not allowed

err=65 is objectClassViolation (see in rfc4511).  The LDAP entry's
objectClass attribute does not contain an object class which allows
attribute 'openscheduledreports' to be included in the entry.  I.e. the
attribute is listed as a 'MUST' or 'MAY' attribute in the object class
definition in the schema.

If you don't know what I'm talking about, you had better read up on LDAP
a bit.  E.g.:

Looking again at the schema you posted, there is no object class there
which allows the 'openscheduledreports' attribute.  OTOH there are
object classes with the same names as the attributes.  Maybe that's a
special hack on your old server which allows those attributes to be
included.  If so I guess the schema will need to be hacked anyway.

> I'm not really sure what you mean about UTF-8 and Latin-1.... looking 
> at the LDIF export file I see data like this for the problem 
> attributes;
> (...)

That's not valid LDIF format - but perhaps your mailer reformatted it or
something.  Anyway, it looks like a non-empty 7-bit (ASCII) string,
which should be fine for an attribute which inherits 'name's syntax.

I suggest you post a whole LDIF entry, not just the attribute, so we can
see what object classes etc are there.  And base64-encode it or post
just an URL to where it can be found, so your mailer doesn't munge it.
Remove personal info and passwords you do not want to post though...