Sorry, but after a couple of hours head-scratching, I need some help from the experts. Environment: Mandriva Linux 2011_x64, OpenLDAP openldap-2.4.33 (also jxplorer). I'm trying to process a large LDIF file produced by Thunderbird. My slapd.conf file contains include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/openldap.schema include /usr/local/etc/openldap/schema/mozilla.schema include /usr/local/etc/openldap/schema/misc.schema
I've progresses to the point where two organizational units have been created, Personal and NCI. I get the error when processing the first person in the LDIF file:
dn: cn=Chris Smith,mail=chris.smith@ccb-insight.emv1.net,ou=Personal,dc=gemmills,dc=name objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson objectclass: mozillaAbPersonAlpha cn: Chris Smith mail: chris.smith@ccb-insight.emv1.net #modifytimestamp: 1314088910
The full error message is ldap_add: Invalid syntax (21) additional info: objectclass: value #4 invalid per syntax, which points to a problem with the mozillaABPersonAlpha object.
here is the log output: add objectclass: top person organizationalPerson inetOrgPerson mozillaAbPersonAlpha add cn: Chris Smith add mail: chris.smith@ccb-insight.emv1.net adding new entry "cn=Chris Smith,mail=chris.smith@ccb-insight.emv1.net,ou=Personal,dc=gemmills,dc=name"
I can't see why either of these attributes should give a problem. As a side issue: is it significant that KWrite doesn't colour the "objectclass: mozillaAbPersonAlpha" line in the LDIF file the same as the other objectclass lines? Your comments/help will be gratefully received. Graeme
On 09/03/13 17:34, Graeme Gemmill wrote: Please ignore the previous post on this topic - I think choosing dc=name was confusing things. I'm starting again. Graeme
Hi, I don't think dc=name is related to your schema problem. Probably object class mozillaAbPersonAlpha was not included in your schema files. Please provide /usr/local/etc/openldap/schema/mozilla.schema to check this.
Regards, Jochen.
Am 10.03.2013 18:43, schrieb Graeme Gemmill:
On 09/03/13 17:34, Graeme Gemmill wrote: Please ignore the previous post on this topic - I think choosing dc=name was confusing things. I'm starting again. Graeme
On 10/03/13 18:44, Keutel, Jochen (mlists) wrote:
Hi, I don't think dc=name is related to your schema problem. Probably object class mozillaAbPersonAlpha was not included in your schema files. Please provide /usr/local/etc/openldap/schema/mozilla.schema to check this.
Regards, Jochen.
Am 10.03.2013 18:43, schrieb Graeme Gemmill:
On 09/03/13 17:34, Graeme Gemmill wrote: Please ignore the previous post on this topic - I think choosing dc=name was confusing things. I'm starting again. Graeme
Jochen, Perhaps dc=name isn't significant, but as a programmer in a previous existence, I'm a bit wary of using what might be "reserved words". Mozilla.schema follows: # Mozilla: @VERSION@ # # mozillaAbPersonAlpha # # Created initial version --[[User:Standard8|Standard8]] 12:21, 5 Dec 2005 (PST) # Change fax to facsimileTelephoneNumber to reflect core.schema # ({{bug|327872}} --[[User:Standard8|Standard8]] 12:45, 11 Dec 2008 (PST) # # This file contains LDAPv3 schema for use with the Mozilla Address Book # and is intended to ...
# Depends upon # Definition of an X.500 Attribute Type and an Object Class to Hold # Uniform Resource Identifiers (URIs) [RFC2079], and A Summary of # the X.500(96) User Schema for use with LDAPv3 [RFC2256] (core.schema) # # The COSINE and Internet X.500 Schema [RFC1274] (cosine.schema) # # The InetOrgPerson Schema [RFC2798] (inetorgperson.schema)
# 1.3.6.1.4.1.13769.4.x - Mozilla AB 'Other' tab
attributetype ( 1.3.6.1.4.1.13769.4.1 NAME 'mozillaCustom1' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} SINGLE-VALUE )
attributetype ( 1.3.6.1.4.1.13769.4.2 NAME 'mozillaCustom2' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} SINGLE-VALUE )
attributetype ( 1.3.6.1.4.1.13769.4.3 NAME 'mozillaCustom3' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} SINGLE-VALUE )
attributetype ( 1.3.6.1.4.1.13769.4.4 NAME 'mozillaCustom4' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} SINGLE-VALUE )
# 1.3.6.1.4.1.13769.3.x - Mozilla AB 'Address' tab
attributetype ( 1.3.6.1.4.1.13769.3.1 NAME 'mozillaHomeStreet' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} SINGLE-VALUE )
attributetype ( 1.3.6.1.4.1.13769.3.2 NAME 'mozillaHomeStreet2' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} SINGLE-VALUE )
attributetype ( 1.3.6.1.4.1.13769.3.3 NAME 'mozillaHomeLocalityName' SUP name SINGLE-VALUE )
attributetype ( 1.3.6.1.4.1.13769.3.4 NAME 'mozillaHomeState' SUP name SINGLE-VALUE )
attributetype ( 1.3.6.1.4.1.13769.3.5 NAME 'mozillaHomePostalCode' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{40} SINGLE-VALUE )
attributetype ( 1.3.6.1.4.1.13769.3.6 NAME 'mozillaHomeCountryName' SUP name SINGLE-VALUE )
attributetype ( 1.3.6.1.4.1.13769.3.7 NAME 'mozillaHomeUrl' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} SINGLE-VALUE )
attributetype ( 1.3.6.1.4.1.13769.3.8 NAME 'mozillaWorkStreet2' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} SINGLE-VALUE )
attributetype ( 1.3.6.1.4.1.13769.3.9 NAME 'mozillaWorkUrl' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} SINGLE-VALUE )
# 1.3.6.1.4.1.13769.2.x - Mozilla AB 'Contact' tab
attributetype ( 1.3.6.1.4.1.13769.2.1 NAME ( 'mozillaNickname' 'xmozillanickname' ) SUP name )
attributetype ( 1.3.6.1.4.1.13769.2.2 NAME ( 'mozillaSecondEmail' 'xmozillasecondemail' ) EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} SINGLE-VALUE )
attributetype ( 1.3.6.1.4.1.13769.2.3 NAME ( 'mozillaUseHtmlMail' 'xmozillausehtmlmail' ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
# AOL Instant Messenger (AIM) Identity attributetype ( 1.3.6.1.4.1.13769.2.4 NAME ( 'nsAIMid' 'nscpaimscreenname' ) EQUALITY telephoneNumberMatch SUBSTR telephoneNumberSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
# 1.3.6.1.4.1.13769.9 - Mozilla AB objectclasses
# The mozillaAddressBookEntry object class is used to define entries # representing Cards in the Mozilla Address Book. The commonName attribute # is used for naming entries of this object class, but may not be unique. # department $
objectclass ( 1.3.6.1.4.1.13769.9.1 NAME 'mozillaAbPersonAlpha' SUP top AUXILIARY MUST ( cn ) MAY( c $ description $ displayName $ facsimileTelephoneNumber $ givenName $ homePhone $ l $ mail $ mobile $ mozillaCustom1 $ mozillaCustom2 $ mozillaCustom3 $ mozillaCustom4 $ mozillaHomeCountryName $ mozillaHomeLocalityName $ mozillaHomePostalCode $ mozillaHomeState $ mozillaHomeStreet $ mozillaHomeStreet2 $ mozillaHomeUrl $ mozillaNickname $ mozillaSecondEmail $ mozillaUseHtmlMail $ mozillaWorkStreet2 $ mozillaWorkUrl $ nsAIMid $ o $ ou $ pager $ postalCode $ postOfficeBox $ sn $ st $ street $ telephoneNumber $ title ) )
By the way, having done a bit of reading, I think the problem may be the lack of a cn: or sn: when processing an inetOrgPerson. Thanks for your interest. Graeme
Graeme Gemmill wrote:
On 10/03/13 18:44, Keutel, Jochen (mlists) wrote:
Hi, I don't think dc=name is related to your schema problem. Probably object class mozillaAbPersonAlpha was not included in your schema files. Please provide /usr/local/etc/openldap/schema/mozilla.schema to check this.
By the way, having done a bit of reading, I think the problem may be the lack of a cn: or sn: when processing an inetOrgPerson.
No. Lack of a required attribute would return Objectclass violation, not Invalid syntax. Most likely you have trailing whitespace or some other invisible character garbling the input.
SORTED: the problem was the presence on the dn: cn= line of the mail= attribute. I removed it from each line, and the LDIF file completed correctly. Since the data was prepared by exporting an LDIF file from Thunderbird, I'll have to raise a bug report with them. Can I be the first person to find this problem? Thanks for your comments Graeme
openldap-technical@openldap.org
-
Graeme Gemmill -
Howard Chu -
Keutel, Jochen (mlists)