#3372 During Migration - If Schema is unavailable migration fails
Closed: Fixed None Opened 11 years ago by tsunamie.

When trying to migrate data from ldap using the following command.

ipa migrate-ds --bind-dn="cn=admin,dc=example,dc=com" --user-container="ou=ib,dc=example,dc=com" --group-container="ou=groups,ou=live,dc=example,dc=com" ldaps://ldap1.example.com:636

I get the following error

ipa: DEBUG: stderr=
ipa: DEBUG: Caught fault 4203 from server http://fedoraipaserver.test.example.com/ipa/xml: uri=ldaps://ldap1.example.com:636: Unable to retrieve LDAP schema: No such object: 
ipa: DEBUG: Destroyed connection context.xmlclient
ipa: ERROR: uri=ldaps://ldap1.example.com:636: Unable to retrieve LDAP schema: No such object:

This apparently is due to a check of the ldap schema before migrating the data.

Not sure how this should be fixed

Regards

John


@(#) $OpenLDAP: slapd 2.4.23 (Jul 31 2012 10:47:00) $
mockbuild@x86-001.build.bos.redhat.com:/builddir/build/BUILD/openldap-2.4.23/openldap-2.4.23/build-servers/servers/slapd

Note: in openldap the schema is also not available on the place we assume it to be: http://www.openldap.org/doc/admin24/slapdconf2.html

I managed to deploy a testing openldap server instance and the schema even is indeed available in different DN and also in different attributes:

# ldapsearch -Y EXTERNAL -H ldapi:/// -b "cn=schema,cn=config" -s base olcObjectClasses
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
# extended LDIF
#
# LDAPv3
# base <cn=schema,cn=config> with scope baseObject
# filter: (objectclass=*)
# requesting: olcObjectClasses 
#

# schema, config
dn: cn=schema,cn=config
olcObjectClasses: ( 2.5.6.0 NAME 'top' DESC 'top of the superclass chain' ABST
 RACT MUST objectClass )
olcObjectClasses: ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject' DESC 
 'RFC4512: extensible object' SUP top AUXILIARY )
olcObjectClasses: ( 2.5.6.1 NAME 'alias' DESC 'RFC4512: an alias' SUP top STRU
 CTURAL MUST aliasedObjectName )
olcObjectClasses: ( 2.16.840.1.113730.3.2.6 NAME 'referral' DESC 'namedref: na
 med subordinate referral' SUP top STRUCTURAL MUST ref )
olcObjectClasses: ( 1.3.6.1.4.1.4203.1.4.1 NAME ( 'OpenLDAProotDSE' 'LDAProotD
 SE' ) DESC 'OpenLDAP Root DSE object' SUP top STRUCTURAL MAY cn )
olcObjectClasses: ( 2.5.17.0 NAME 'subentry' DESC 'RFC3672: subentry' SUP top 
 STRUCTURAL MUST ( cn $ subtreeSpecification ) )
...

I think the best approach here would be indeed to not try to read or process the external schema as it may indeed have much different structure that what we would expect.

You may ignore the excerpt above, this was caused by my low experience with openldap. This was just an internal representation of the scheme in openldap, public schema tree is available in cn=subschema.

I have a candidate patch which fallbacks to cn=subschema when cn=schema cannot be found. I chose this approach in favor of skipping the schema because we do some automatic encoding (like DN encoding) based on attribute OID which we then require in our plugins - so the schema is needed if we do not want to do bigger LDAP encoding refactoring ATM.

FYI: this patch helped tsunamie to avoid server internal errors with when running migrate-ds against a remote openldap database (at least from what I know from our late debugging session).

Patch freeipa-mkosek-359-allow-extra-whitespaces-in-attr-params.patch sent for review

As per discussion with rcritten, moving to Feb bucket.

Patch 358 pushed, the issue that patch 359 was trying to fix will be fixed in scope of ticket #3368.

master: 959b276[[BR]]
ipa-3-1: 2b491ac[[BR]]
ipa-3-0: dd499c5

Metadata Update from @tsunamie:
- Issue assigned to mkosek
- Issue set to the milestone: FreeIPA 3.2 - 2013/02

7 years ago

Login to comment on this ticket.

Metadata