Lydon, Mark writes:
Thanks for this. Having studied the standard schema files, there
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
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'
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....
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...