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.
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.
cn=schema
Candidate patch for openldap migration fix 0001-Fix-migration-for-openldap-DS.patch
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).
attachment freeipa-mkosek-359-allow-extra-whitespaces-in-attr-params.patch
Patch freeipa-mkosek-359-allow-extra-whitespaces-in-attr-params.patch sent for review
Final version of the patch I used freeipa-mkosek-358-fix-migration-for-openldap-ds.patch
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
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=906846
Metadata Update from @tsunamie: - Issue assigned to mkosek - Issue set to the milestone: FreeIPA 3.2 - 2013/02
Login to comment on this ticket.