Hello all!
In the process of upgrading slapd from 2.2.6 to 2.4.9 (ubuntu 6.06 to 8.04), I get the following error when trying to import the LDIF dump from the old server:
# slapadd -b "o=Company Name,c=CH" -l dump.from.2.2.6.ldif slapadd: dn="o=Company Name,c=CH" (line=1): (65) no structural object class provided (same result if I skip the -b "o=Company Name,c=CH")
slapd.conf has not been altered during the upgrade and contains: [...] include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema [...] database bdb suffix "O=Company Name, C=CH" checkpoint 512 30 directory "/var/lib/ldap" rootdn "cn=root, O=Company Name, C=CH" rootpw XXX index objectClass eq [...]
The first entry in the LDIF dump is: dn: o=Company Name,c=CH objectClass: top entryUUID: ... creatorsName: cn=root,o=Company Name,c=CH modifiersName: cn=root,o=Company Name,c=CH createTimestamp: 20071214103903Z modifyTimestamp: 20071214103903Z entryCSN: 20071214103903Z#000001#00#000000
(This directory contains only x.509 CRLs and certificates.)
From the error I assumed that for some reason the "top" objectclass was not correctly defined. In core.schema I found the following new entry from RFC2256, which was commented out:
#objectclass ( 2.5.6.0 NAME 'top' # DESC 'RFC2256: top of the superclass chain' # ABSTRACT # MUST objectClass )
After uncommenting, though, the error is:
slapadd -b "o=Company Name,c=CH" -l dump.from.2.2.6.ldif /etc/ldap/schema/core.schema: line 366 objectclass: Duplicate objectClass: "2.5.6.0" slapadd: bad configuration file!
Yet, no other schema file contains any definition for 2.5.6.0, so I assume that it's compiled into slapd.
This leaves me stuck, scratching my head, and extremely grateful for any hint on where to look further.
Thank you all
krgds /markus
Markus, The first error you got I think is likely the problem. I would not recommend changing the schemas that are packaged with openldap. I know that the definition you are talking about is commented out but I am still able to add instances of those objectclasses.
The first error is saying that none of the objectclasses in your first entry are defined as structural. You need to have 1 structural objectclass per ldap entry. I think if you changed your first entry to be the following it will successfully add.
dn: o=Company Name,c=CH objectClass: organization o: Company Name objectClass: top entryUUID: ... creatorsName: cn=root,o=Company Name,c=CH modifiersName: cn=root,o=Company Name,c=CH createTimestamp: 20071214103903Z modifyTimestamp: 20071214103903Z entryCSN: 20071214103903Z#000001#00#000000
--Kris
-----Original Message----- From: openldap-software-bounces+kris.burton=acision.com@OpenLDAP.org [mailto:openldap-software-bounces+kris.burton=acision.com@OpenLDAP.org] On Behalf Of Markus Wernig Sent: Wednesday, December 10, 2008 7:11 AM To: openldap-software@openldap.org Subject: Unable do slapadd a LDIF dump from slapd 2.2.6 to slapd 2.4.9
Hello all!
In the process of upgrading slapd from 2.2.6 to 2.4.9 (ubuntu 6.06 to 8.04), I get the following error when trying to import the LDIF dump from the old server:
# slapadd -b "o=Company Name,c=CH" -l dump.from.2.2.6.ldif slapadd: dn="o=Company Name,c=CH" (line=1): (65) no structural object class provided (same result if I skip the -b "o=Company Name,c=CH")
slapd.conf has not been altered during the upgrade and contains: [...] include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema [...] database bdb suffix "O=Company Name, C=CH" checkpoint 512 30 directory "/var/lib/ldap" rootdn "cn=root, O=Company Name, C=CH" rootpw XXX index objectClass eq [...]
The first entry in the LDIF dump is: dn: o=Company Name,c=CH objectClass: top entryUUID: ... creatorsName: cn=root,o=Company Name,c=CH modifiersName: cn=root,o=Company Name,c=CH createTimestamp: 20071214103903Z modifyTimestamp: 20071214103903Z entryCSN: 20071214103903Z#000001#00#000000
(This directory contains only x.509 CRLs and certificates.)
From the error I assumed that for some reason the "top" objectclass was not correctly defined. In core.schema I found the following new entry from RFC2256, which was commented out:
#objectclass ( 2.5.6.0 NAME 'top' # DESC 'RFC2256: top of the superclass chain' # ABSTRACT # MUST objectClass )
After uncommenting, though, the error is:
slapadd -b "o=Company Name,c=CH" -l dump.from.2.2.6.ldif /etc/ldap/schema/core.schema: line 366 objectclass: Duplicate objectClass: "2.5.6.0" slapadd: bad configuration file!
Yet, no other schema file contains any definition for 2.5.6.0, so I assume that it's compiled into slapd.
This leaves me stuck, scratching my head, and extremely grateful for any hint on where to look further.
Thank you all
krgds /markus
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
On Wed, Dec 10, 2008 at 01:10:35PM +0100, Markus Wernig wrote:
# slapadd -b "o=Company Name,c=CH" -l dump.from.2.2.6.ldif slapadd: dn="o=Company Name,c=CH" (line=1): (65) no structural object class provided (same result if I skip the -b "o=Company Name,c=CH")
The first entry in the LDIF dump is: dn: o=Company Name,c=CH objectClass: top entryUUID: ... creatorsName: cn=root,o=Company Name,c=CH modifiersName: cn=root,o=Company Name,c=CH createTimestamp: 20071214103903Z modifyTimestamp: 20071214103903Z entryCSN: 20071214103903Z#000001#00#000000
The problem is in the entry, but the error message you get is perhaps less helpful than it might be. Ignoring the operational attributes, you have this:
dn: o=Company Name,c=CH objectClass: top
The problem is that 'top' only permits 'objectclass' attributes. Nothing there permits (or defines) the 'o' attribute, but you must have one because it is used in the DN.
This would work:
dn: o=Company Name,c=CH objectClass: top objectClass: organization o: Company Name
How did you generate the LDIF file that you are importing? It seems to be lacking some vital information.
Andrew
Hi Andrew, all!
Yes, this works. slapadd even adds the "o: Company Name" automatically. Thank you all for the great help.
Strangely enough, the LDIF dump was created from a working server (ver. 2.2.6) by "slapcat -l filename.ldif". The directory was fully functional there.
krgds /markus
Andrew Findlay wrote:
This would work:
dn: o=Company Name,c=CH objectClass: top objectClass: organization o: Company Name
How did you generate the LDIF file that you are importing? It seems to be lacking some vital information.
--On Thursday, December 11, 2008 1:08 PM +0100 Markus Wernig listener@wernig.net wrote:
Hi Andrew, all!
Yes, this works. slapadd even adds the "o: Company Name" automatically. Thank you all for the great help.
Strangely enough, the LDIF dump was created from a working server (ver. 2.2.6) by "slapcat -l filename.ldif". The directory was fully functional there.
That's because OpenLDAP 2.2 wasn't as strict as it should have been.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Markus Wernig listener@wernig.net writes:
Hello all!
In the process of upgrading slapd from 2.2.6 to 2.4.9 (ubuntu 6.06 to 8.04), I get the following error when trying to import the LDIF dump from the old server:
# slapadd -b "o=Company Name,c=CH" -l dump.from.2.2.6.ldif slapadd: dn="o=Company Name,c=CH" (line=1): (65) no structural object class provided (same result if I skip the -b "o=Company Name,c=CH")
The first entry in the LDIF dump is: dn: o=Company Name,c=CH objectClass: top entryUUID: ... creatorsName: cn=root,o=Company Name,c=CH modifiersName: cn=root,o=Company Name,c=CH createTimestamp: 20071214103903Z modifyTimestamp: 20071214103903Z entryCSN: 20071214103903Z#000001#00#000000
The object class organization is missing, and in addition, the organization attribute. The entry should read
dn: o=Company Name,c=CH o: Company Name objectClass: organization <additional operational attributes>
-Dieter
openldap-software@openldap.org
-
Andrew Findlay -
Burton, Kris - Acision -
Dieter Kluenter -
Markus Wernig -
Quanah Gibson-Mount