906846 – During Migration - If Schema is unavailable migration fails

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 906846 - During Migration - If Schema is unavailable migration fails

Summary: During Migration - If Schema is unavailable migration fails

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 6
Classification:	Red Hat
Component:	ipa
Sub Component:
Version:	6.4
Hardware:	Unspecified
OS:	Unspecified
Priority:	urgent
Severity:	high
Target Milestone:	rc
Target Release:	---
Assignee:	Martin Kosek
QA Contact:	Namita Soman
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:	908400 910538 910665
TreeView+	depends on / blocked

Reported:	2013-02-01 16:50 UTC by Dmitri Pal
Modified:	2013-11-21 20:49 UTC (History)
CC List:	4 users (show)
Fixed In Version:	ipa-3.0.0-26.el6
Doc Type:	Bug Fix
Doc Text:	Identity Management attempts to retrieve the LDAP schema from the remote server during migration. Previously, such an attempt failed when migrating from an OpenLDAP server. With this update, Identity Management also looks in cn=subschema and migrations from OpenLDAP servers no longer fail.
Clone Of:
Clones:	910538 910665 (view as bug list)
Environment:
Last Closed:	2013-11-21 20:49:31 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Product Errata	RHBA-2013:1651	0	normal	SHIPPED_LIVE	ipa bug fix and enhancement update	2013-11-21 00:39:40 UTC

Description Dmitri Pal 2013-02-01 16:50:31 UTC

This bug is created as a clone of upstream ticket:
https://fedorahosted.org/freeipa/ticket/3372

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

Comment 1 Martin Kosek 2013-02-04 11:36:13 UTC

Fixed upstream:

master: 959b276e7d10f80269568c6d340e59d664fc5d42
ipa-3-1: 2b491acb4ad4d6880cabff02b474d6885af8242b
ipa-3-0: dd499c559c960f8c01287bcfe28c158e3780daa4

Comment 5 Jenny Severance 2013-02-12 16:43:17 UTC

Please add steps to reproduce / verify this issue.  How to make schema unavailable?  This bug also needs to be cloned for inclusion in RHEL 7.0

Comment 6 Martin Kosek 2013-02-13 07:52:11 UTC

(In reply to comment #5)
> Please add steps to reproduce / verify this issue.  How to make schema
> unavailable?  This bug also needs to be cloned for inclusion in RHEL 7.0

We used to read LDAP schema only from "cn=schema" DN, its presence can be verified with for example this ldapsearch:

# ldapsearch -h $HOST -D "cn=Directory Manager" -W -x -b cn=schema objectClasses attributeTypes

This applies both for local LDAP operations like standard ipa commands and also for migration which can read from remote LDAP which may not be 389-ds.

This lead to a missing schema error when running "ipa migrate-ds" command for openldap LDAP server which has a schema in different DN: "cn=subschema".

To reproduce:
1. On one VM, configure an openldap server with some users and groups
2. On other VM, configure IPA server: ipa-server-install
3. Enable migration mode: ipa config-mod --enable-migration=TRUE
4. Run migration: ipa migrate-ds ldap://$HOST_WITH_OPENLDAP_SERVER ...

Without this fix, this command always crashes with schema error.

Comment 7 Martin Kosek 2013-02-13 07:52:30 UTC

Cloning for RHEL 7.0...

Comment 9 Namita Soman 2013-08-28 18:34:48 UTC

Verified using ipa-server-3.0.0-33.el6.x86_64.
Followed steps from bz 908400

[root@qe-blade-03 ~]# yum -y install openldap-servers openldap-clients
Loaded plugins: product-id, security, subscription-manager
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
beaker-Server                                            | 3.9 kB     00:00     
beaker-debuginfo                                         | 2.9 kB     00:00     
beaker-harness                                           | 1.2 kB     00:00     
beaker-optional                                          | 3.7 kB     00:00     
beaker-optional-debuginfo                                | 2.9 kB     00:00     
beaker-tasks                                             | 1.2 kB     00:00     
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package openldap-clients.x86_64 0:2.4.23-32.el6_4.1 will be installed
---> Package openldap-servers.x86_64 0:2.4.23-32.el6_4.1 will be installed
--> Processing Dependency: libltdl.so.7()(64bit) for package: openldap-servers-2.4.23-32.el6_4.1.x86_64
--> Running transaction check
---> Package libtool-ltdl.x86_64 0:2.2.6-15.5.el6 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package              Arch       Version                Repository         Size
================================================================================
Installing:
 openldap-clients     x86_64     2.4.23-32.el6_4.1      beaker-Server     164 k
 openldap-servers     x86_64     2.4.23-32.el6_4.1      beaker-Server     2.0 M
Installing for dependencies:
 libtool-ltdl         x86_64     2.2.6-15.5.el6         beaker-Server      43 k

Transaction Summary
================================================================================
Install       3 Package(s)

Total download size: 2.2 M
Installed size: 5.0 M
Downloading Packages:
(1/3): libtool-ltdl-2.2.6-15.5.el6.x86_64.rpm            |  43 kB     00:00     
(2/3): openldap-clients-2.4.23-32.el6_4.1.x86_64.rpm     | 164 kB     00:00     
(3/3): openldap-servers-2.4.23-32.el6_4.1.x86_64.rpm     | 2.0 MB     00:00     
--------------------------------------------------------------------------------
Total                                           6.8 MB/s | 2.2 MB     00:00     
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
  Installing : libtool-ltdl-2.2.6-15.5.el6.x86_64                           1/3 
  Installing : openldap-servers-2.4.23-32.el6_4.1.x86_64                    2/3 
  Installing : openldap-clients-2.4.23-32.el6_4.1.x86_64                                                                    3/3 
  Verifying  : openldap-servers-2.4.23-32.el6_4.1.x86_64                                                                    1/3 
  Verifying  : libtool-ltdl-2.2.6-15.5.el6.x86_64                                                                           2/3 
  Verifying  : openldap-clients-2.4.23-32.el6_4.1.x86_64                                                                    3/3 

Installed:
  openldap-clients.x86_64 0:2.4.23-32.el6_4.1                    openldap-servers.x86_64 0:2.4.23-32.el6_4.1                   

Dependency Installed:
  libtool-ltdl.x86_64 0:2.2.6-15.5.el6                                                                                          

Complete!



[root@qe-blade-03 ~]# service iptables stop


[root@qe-blade-03 ~]# service slapd start
Starting slapd: [  OK  ]


[root@qe-blade-03 ~]# service slapd stop
Stopping slapd: [  OK  ]


[root@qe-blade-03 ~]# rm -rf /etc/openldap/slapd.d/*


[root@qe-blade-03 ~]# rm -rf /var/lib/ldap/*


[root@qe-blade-03 ~]# cp /usr/share/openldap-servers/DB_CONFIG.example /var/lib/ldap/DB_CONFIG


[root@qe-blade-03 ~]# cp /usr/share/openldap-servers/slapd.conf.obsolete /etc/openldap/slapd.example.conf


[root@qe-blade-03 ~]# sed -i "s/my-domain/example/g" /etc/openldap/slapd.example.conf


[root@qe-blade-03 ~]# hostname
qe-blade-03.idm.lab.bos.redhat.com


[root@qe-blade-03 ~]# hostname qe-blade-03.example.com


[root@qe-blade-03 ~]# hostname
qe-blade-03.example.com


[root@qe-blade-03 ~]# vim /etc/hosts


[root@qe-blade-03 ~]# sed -i "s/Manager/admin/g"   /etc/openldap/slapd.example.conf


[root@qe-blade-03 ~]# echo -e "rootpw\t\t$(slappasswd -s <PASSWORD>)" >> /etc/openldap/slapd.example.conf


[root@qe-blade-03 ~]# echo "" | slapadd -f /etc/openldap/slapd.example.conf
The first database does not allow slapadd; using the first available one (2)


[root@qe-blade-03 ~]# slaptest -f /etc/openldap/slapd.example.conf -F /etc/openldap/slapd.d
config file testing succeeded


[root@qe-blade-03 ~]#  cd /etc/openldap


[root@qe-blade-03 openldap]# cat > example.com.ldif <<EOF
> # Root entry
> dn: dc=example,dc=com
> objectclass: dcObject
> objectclass: organization
> o: Example Company
> dc: example
> EOF


[root@qe-blade-03 openldap]# cat > admin.example.com.ldif <<EOF
> # Admin DN
> dn: cn=admin,dc=example,dc=com
> objectclass: organizationalRole
> cn: admin
> EOF


[root@qe-blade-03 openldap]# cat > users.example.com.ldif <<EOF
> # Base DN for users
> dn: ou=users,dc=example,dc=com
> objectclass: top
> objectclass: organizationalUnit
> ou: users
> EOF


[root@qe-blade-03 openldap]# cat > groups.example.com.ldif <<EOF
> # Base DN for groups
> dn: ou=groups,dc=example,dc=com
> objectclass: top
> objectclass: organizationalUnit
> ou: groups
> EOF


[root@qe-blade-03 openldap]# slapadd -l example.com.ldif
The first database does not allow slapadd; using the first available one (2)
_#################### 100.00% eta   none elapsed            none fast!         
Closing DB...


[root@qe-blade-03 openldap]#  slapadd -l  admin.example.com.ldif
The first database does not allow slapadd; using the first available one (2)
_#################### 100.00% eta   none elapsed            none fast!         
Closing DB...


[root@qe-blade-03 openldap]# slapadd -l  users.example.com.ldif
The first database does not allow slapadd; using the first available one (2)
_#################### 100.00% eta   none elapsed            none fast!         
Closing DB...


[root@qe-blade-03 openldap]# slapadd -l groups.example.com.ldif
The first database does not allow slapadd; using the first available one (2)
_#################### 100.00% eta   none elapsed            none fast!         
Closing DB...


[root@qe-blade-03 openldap]# chown -R ldap:ldap /var/lib/ldap


[root@qe-blade-03 openldap]# chown -R ldap:ldap /etc/openldap/slapd.d


[root@qe-blade-03 openldap]# service slapd restart
Stopping slapd: [FAILED]
Starting slapd: [  OK  ]


[root@qe-blade-03 openldap]# ldapsearch -x -D 'cn=admin,dc=example,dc=com' -b 'dc=example,dc=com' -w <PASSWORD>
# extended LDIF
#
# LDAPv3
# base <dc=example,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# example.com
dn: dc=example,dc=com
objectClass: dcObject
objectClass: organization
o: Example Company
dc: example

# admin, example.com
dn: cn=admin,dc=example,dc=com
objectClass: organizationalRole
cn: admin

# users, example.com
dn: ou=users,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: users

# groups, example.com
dn: ou=groups,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: groups

# search result
search: 2
result: 0 Success

# numResponses: 5
# numEntries: 4


[root@qe-blade-03 openldap]# ldapadd -x -D 'cn=admin,dc=example,dc=com' -w <PASSWORD> << EOF
> dn: uid=tuser1,ou=users,dc=example,dc=com
> uidNumber: 100161
> gidNumber: 100161
> objectclass: posixAccount
> homeDirectory: /home/tuser1
> uid: Test_User1
> objectClass: top
> objectClass: person
> objectClass: organizationalPerson
> objectClass: inetOrgPerson
> ou: users
> cn: Test User1
> sn: User1
> EOF
adding new entry "uid=tuser1,ou=users,dc=example,dc=com"


[root@qe-blade-03 openldap]# ldapadd -x -D 'cn=admin,dc=example,dc=com' -w <PASSWORD> <<EOF
> dn: cn=tgroup2,ou=groups,dc=example,dc=com
> objectClass: top
> objectClass: groupOfNames
> member: uid=tuser1,ou=users,dc=example,dc=com
> EOF
adding new entry "cn=tgroup2,ou=groups,dc=example,dc=com"


ON IPA SERVER ::
[root@mgmt6 ~]# kinit admin
Password for admin: 


[root@mgmt6 ~]#  ipa config-mod --enable-migration=TRUE
  Maximum username length: 32
  Home directory base: /home
  Default shell: /bin/sh
  Default users group: ipausers
  Default e-mail domain: testrelm.com
  Search time limit: 2
  Search size limit: 100
  User search fields: uid,givenname,sn,telephonenumber,ou,title
  Group search fields: cn,description
  Enable migration mode: TRUE
  Certificate Subject base: O=TESTRELM.COM
  Password Expiration Notification (days): 4
  Password plugin features: AllowNThash
  SELinux user map order: guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023
  Default SELinux user: unconfined_u:s0-s0:c0.c1023
  Default PAC types: MS-PAC



[root@mgmt6 ~]# ipa migrate-ds --user-container="ou=users,dc=example,dc=com" --group-container="ou=groups,dc=example,dc=com" --bind-dn="cn=admin,dc=example,dc=com" --with-compat ldap://qe-blade-03.example.com
Password: 
-----------
migrate-ds:
-----------
Migrated:
  user: tuser1
  group: tgroup2
Failed user:
Failed group:
----------
Passwords have been migrated in pre-hashed format.
IPA is unable to generate Kerberos keys unless provided
with clear text passwords. All migrated users need to
login at https://your.domain/ipa/migration/ before they
can use their Kerberos accounts.

Comment 11 errata-xmlrpc 2013-11-21 20:49:31 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1651.html

Note You need to log in before you can comment on or make changes to this bug.