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.
Regards,
Mark
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
'openscheduledreports'
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.: http://en.wikipedia.org/wiki/Ldap#Directory_structure http://en.wikipedia.org/wiki/Ldap#Schema
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...
-- Hallvard