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 1176995 - IPA replica missing data after master upgraded
Summary: IPA replica missing data after master upgraded
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipa
Version: 7.1
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: rc
: ---
Assignee: IPA Maintainers
QA Contact: Namita Soman
URL:
Whiteboard:
Depends On: 1183655
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-12-23 17:15 UTC by Scott Poore
Modified: 2015-03-05 10:19 UTC (History)
6 users (show)

Fixed In Version: ipa-4.1.0-16.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1183655 (view as bug list)
Environment:
Last Closed: 2015-03-05 10:19:12 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
dirsrv logs from RHEL7.1 master (8.54 MB, text/plain)
2014-12-23 17:19 UTC, Scott Poore 		no flags Details
dirsrv logs from RHEL7.0 replica (11.88 MB, text/plain)
2014-12-23 17:27 UTC, Scott Poore 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:0442 0 normal SHIPPED_LIVE Moderate: ipa security, bug fix, and enhancement update 2015-03-05 14:50:39 UTC

Description Scott Poore 2014-12-23 17:15:31 UTC 
Description of problem:

In an IPA RHEL7 environment, I'm seeing data missing from replica after master is upgraded from 7.0 to 7.1.

After upgade, DNS data is missing:

[root@vm2 ~]# ipa dnszone-find
----------------------------
Number of entries returned 0
----------------------------

As is host data:

[root@vm2 ~]# ipa host-find
---------------
0 hosts matched
---------------
----------------------------
Number of entries returned 0
----------------------------

During (or right after)

I even tried using copy-schema-to-ca.py after the upgrade but, that didn't work:

[root@vm2 ~]# python /root/copy-schema-to-ca.py
ipa         : WARNING  Could not install /etc/dirsrv/slapd-PKI-IPA//schema/60kerberos.ldif: [Errno 2] No such file or directory:
'/etc/dirsrv/slapd-PKI-IPA//schema/60kerberos.ldif'
Traceback (most recent call last):
  File "/root/copy-schema-to-ca.py", line 91, in <module>
    main()
  File "/root/copy-schema-to-ca.py", line 85, in main
    add_ca_schema()
  File "/root/copy-schema-to-ca.py", line 66, in add_ca_schema
    os.chmod(target_fname, 0440)    # read access for dirsrv user/group
OSError: [Errno 2] No such file or directory: '/etc/dirsrv/slapd-PKI-IPA//schema/60kerberos.ldif'

Similar to bug #1167964 but, I don't know if it's the same.

Version-Release number of selected component (if applicable):
On RHEL7.1 Master:
ipa-server-4.1.0-13.el7.x86_64
389-ds-base-1.3.3.1-10.el7.x86_64

On RHEL7.0 Replica:
ipa-server-3.3.3-28.el7.x86_64
389-ds-base-1.3.1.6-25.el7.x86_64

How reproducible:
always

Steps to Reproduce:
1.  install RHEL7.0 master and replica with dns support
2.  point master yum configs to RHEL7.1 repos
3.  yum -y update ipa-server sssd  # on master
4.  ipa dnszone-find # on replica

Actual results:
nothing returned as shown above.

Expected results:
shows configured DNS zones.

Additional info:
Will attach dirsrv logs shortly.
Comment 1 Scott Poore 2014-12-23 17:19:18 UTC 
Created attachment 972458 [details]
dirsrv logs from RHEL7.1 master
Comment 2 Scott Poore 2014-12-23 17:27:15 UTC 
Created attachment 972460 [details]
dirsrv logs from RHEL7.0 replica
Comment 4 Martin Kosek 2015-01-05 16:18:45 UTC 
I see lot of replication errors. Thierry, can you please advise?
Comment 5 thierry bordaz 2015-01-05 16:25:19 UTC 
May I access the faulty instance to check the error logs/config ?
Comment 6 thierry bordaz 2015-01-06 17:43:56 UTC 
	The failures are related to schema migration IPA 3.3.3 -> 4.1.

	The logs shows 2 differents unexpected behavior:

		- After update of the master, the master detects some schema definitions that
		  it needs to learn.
		  It successfully learn them, then concludes the master schema is now a superset of the consumer
		  schema. So it decides to send its schema to the consumer. But for some reason the consumer
		  closed the connection. So the master does not send its schema.

		  This occurs twice 23/Dec/2014:09:12:10 and 23/Dec/2014:09:12:12
		  the logs from the masters are
[23/Dec/2014:08:35:09 -0600] - 389-Directory/1.3.1.6 B2014.093.1750 starting up
...
[23/Dec/2014:09:11:40 -0600] - slapd stopped.

	<< here update took place >>
[23/Dec/2014:09:11:42 -0600] - 389-Directory/1.3.3.1 B2014.351.2355 starting up

	<<here supplier detects it needs to send its schema
          First it compares the oc/at >>
[23/Dec/2014:09:11:43 -0600] schema - Attribute nsds5ReplicaPreciseTombstonePurging is not allowed in 'nsDS5Replica' of the remote consumer schema
[23/Dec/2014:09:11:43 -0600] schema - Attribute nstombstonecsn is not allowed in 'nsTombstone' of the remote consumer schema
[23/Dec/2014:09:11:43 -0600] schema - Attribute nsds5ReplicaFlowControlWindow is not allowed in 'nsDS5ReplicationAgreement' of the remote consumer schema 
...
[23/Dec/2014:09:11:43 -0600] schema - Attribute mail is no longer 'required' in 'mailGroup' of the remote consumer schema but is now 'allowed'
[23/Dec/2014:09:11:43 -0600] schema - Attribute mail is not allowed in 'mailGroup' of the remote consumer schema
[23/Dec/2014:09:11:43 -0600] schema - Do not check if this OBJECTCLASS is missing on local/remote schema [printer-uri or printer-uri-oid]
[23/Dec/2014:09:11:43 -0600] schema - Attribute ipaUniqueID is not required in 'ipaSudoCmdGrp' of the remote consumer schema

...
	<< First comparison says that the consumer schema > supplier schema
	   because attributes are multivalued on consumer >>
[23/Dec/2014:09:12:09 -0600] schema - local supplier schema attribute [ipaMaxUsernameLength] is not "single-valued"
..
[23/Dec/2014:09:12:09 -0600] schema - local supplier schema attribute [krbPwdPolicyReference] is not "single-valued"
[23/Dec/2014:09:12:09 -0600] schema - Remote krbPwdPolicyReference schema attributetypes is a superset of the received one.

	<< supplier is learning missing definitions >>
[23/Dec/2014:09:12:09 -0600] schema - supplier takes attributetypes: ( 2.16.840.1.113719.1.301.4.36.1 NAME 'krbPwdPolicyReference'  EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'user defined' )
...
[23/Dec/2014:09:12:09 -0600] schema - MOD[31] add (attributetypes): ( 2.16.840.1.113730.3.8.1.9 NAME 'ipaMaxUsernameLength'  EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 X-ORIGIN 'user defined' )
[23/Dec/2014:09:12:10 -0600] NSMMReplicationPlugin - [S] Schema agmt="cn=meTovm2.testrelm.test" (vm2:389) must not be overwritten (set replication log for additional info)


	<<As the first update failed (consumer > supplier) it retries immediately 
	  as the supplier may have learned all the required definitions>>
[23/Dec/2014:09:12:10 -0600] schema - Attribute nsds5ReplicaPreciseTombstonePurging is not allowed in 'nsDS5Replica' of the remote consumer schema
...
[23/Dec/2014:09:12:10 -0600] schema - Attribute ipaUniqueID is not required in 'ipaSudoCmdGrp' of the remote consumer schema
[23/Dec/2014:09:12:10 -0600] NSMMReplicationPlugin - Schema checking successful: ok to push the schema (agmt="cn=meTovm2.testrelm.test" (vm2:389))

		<< Too bad the schema was not sent >>
[23/Dec/2014:09:12:10 -0600] NSMMReplicationPlugin - agmt="cn=meTovm2.testrelm.test" (vm2:389): Disconnected from the consumer
[23/Dec/2014:09:12:10 -0600] NSMMReplicationPlugin - agmt="cn=meTovm2.testrelm.test" (vm2:389): Warning: unable to replicate schema: rc=2

		<<next replication session >>
[23/Dec/2014:09:12:11 -0600] schema - Attribute nsds5ReplicaPreciseTombstonePurging is not allowed in 'nsDS5Replica' of the remote consumer schema
...
[23/Dec/2014:09:12:11 -0600] schema - Attribute ipaUniqueID is not required in 'ipaSudoCmdGrp' of the remote consumer schema
[23/Dec/2014:09:12:12 -0600] NSMMReplicationPlugin - Schema checking successful: ok to push the schema (agmt="cn=meTovm2.testrelm.test" (vm2:389))
[23/Dec/2014:09:12:12 -0600] NSMMReplicationPlugin - agmt="cn=meTovm2.testrelm.test" (vm2:389): Disconnected from the consumer
[23/Dec/2014:09:12:12 -0600] NSMMReplicationPlugin - agmt="cn=meTovm2.testrelm.test" (vm2:389): Warning: unable to replicate schema: rc=2
[23/Dec/2014:09:12:12 -0600] NSMMReplicationPlugin - agmt="cn=meTovm2.testrelm.test" (vm2:389): Consumer failed to replay change (uniqueid (null), CSN (null)): Can't contact LDAP server(-1). Will retry later.
?

		Except the two failures due to connection close, the behavior looks normal. The master is learning the missing definitions


		- The after 23/Dec/2014:09:12:12, the schema checking behaved differently.
		  It states that the ipatokenTOTP definition on the consumer is now a superset of the master
		  definition. So it does not update the consumer.
		  I would expect the master to learn what is missing but it fails.
		  I do not know why it fails
[23/Dec/2014:09:12:17 -0600] schema - Remote ipatokenTOTP schema objectclasses is a superset of the received one.
[23/Dec/2014:09:12:17 -0600] NSMMReplicationPlugin - [S] Schema agmt="cn=meTovm2.testrelm.test" (vm2:389) must not be overwritten (set replication log for additional info)
[23/Dec/2014:09:12:17 -0600] schema - Remote ipatokenTOTP schema objectclasses is a superset of the received one.
[23/Dec/2014:09:12:18 -0600] NSMMReplicationPlugin - [S] Schema agmt="cn=meTovm2.testrelm.test" (vm2:389) must not be overwritten (set replication log for additional info)
[23/Dec/2014:09:12:21 -0600] schema - Remote ipatokenTOTP schema objectclasses is a superset of the received one.
[23/Dec/2014:09:12:21 -0600] NSMMReplicationPlugin - [S] Schema agmt="cn=meTovm2.testrelm.test" (vm2:389) must not be overwritten (set replication log for additional info)
[23/Dec/2014:09:12:21 -0600] schema - Remote ipatokenTOTP schema objectclasses is a superset of the received one.
[23/Dec/2014:09:12:21 -0600] NSMMReplicationPlugin - [S] Schema agmt="cn=meTovm2.testrelm.test" (vm2:389) must not be overwritten (set replication log for additional info)
[23/Dec/2014:09:12:30 -0600] schema - Remote ipatokenTOTP schema objectclasses is a superset of the received one.
[23/Dec/2014:09:12:30 -0600] NSMMReplicationPlugin - [S] Schema agmt="cn=meTovm2.testrelm.test" (vm2:389) must not be overwritten (set replication log for additional info)
[23/Dec/2014:09:12:30 -0600] schema - Remote ipatokenTOTP schema objectclasses is a superset of the received one.
[23/Dec/2014:09:12:30 -0600] NSMMReplicationPlugin - [S] Schema agmt="cn=meTovm2.testrelm.test" (vm2:389) must not be overwritten (set replication log for additional info)
[23/Dec/2014:09:12:39 -0600] schema - Remote ipatokenTOTP schema objectclasses is a superset of the received one.
[23/Dec/2014:09:12:39 -0600] NSMMReplicationPlugin - [S] Schema agmt="cn=meTovm2.testrelm.test" (vm2:389) must not be overwritten (set replication log for additional info)
[23/Dec/2014:09:12:39 -0600] schema - Remote ipatokenTOTP schema objectclasses is a superset of the received one.
[23/Dec/2014:09:12:39 -0600] NSMMReplicationPlugin - [S] Schema agmt="cn=meTovm2.testrelm.test" (vm2:389) must not be overwritten (set replication log for additional info)


		- Can I access the tests machines ? Else I will try to reproduce locally to understand the failures
Comment 7 thierry bordaz 2015-01-08 20:04:07 UTC 
I was able to reproduce the problem, learning phase, attempt to send the schema that fails. Then failing to update the consumer schema because of a new definition of ipatokenTOTP

08/Jan/2015:13:08:15 -0500] schema - Remote ipatokenTOTP schema objectclasses is a superset of the received one.
[08/Jan/2015:13:08:15 -0500] NSMMReplicationPlugin - [S] Schema agmt="cn=meTovm-052.idm.lab.bos.redhat.com" (vm-052:389) must not be overwritten (set replication log for additional info)
[08/Jan/2015:13:08:17 -0500] schema - Remote ipatokenTOTP schema objectclasses is a superset of the received one.
[08/Jan/2015:13:08:17 -0500] NSMMReplicationPlugin - [S] Schema agmt="cn=meTovm-052.idm.lab.bos.redhat.com" (vm-052:389) must not be overwritten (set replication log for additional info)
[08/Jan/2015:13:08:17 -0500] schema - Remote ipatokenTOTP schema objectclasses is a superset of the received one.
[08/Jan/2015:13:08:18 -0500] NSMMReplicationPlugin - [S] Schema agmt="cn=meTovm-052.idm.lab.bos.redhat.com" (vm-052:389) must not be overwritten (set replication log for additional info)
[08/Jan/2015:13:08:20 -0500] schema - Remote ipatokenTOTP schema objectclasses is a superset of the received one.
[08/Jan/2015:13:08:21 -0500] NSMMReplicationPlugin - [S] Schema agmt="cn=meTovm-052.idm.lab.bos.redhat.com" (vm-052:389) must not be overwritten (set replication log for additional info)
[08/Jan/2015:13:08:21 -0500] schema - Remote ipatokenTOTP schema objectclasses is a superset of the received one.
[08/Jan/2015:13:08:21 -0500] NSMMReplicationPlugin - [S] Schema agmt="cn=meTovm-052.idm.lab.bos.redhat.com" (vm-052:389) must not be overwritten (set replication log for additional info)
[08/Jan/2015:13:08:52 -0500] schema - Remote ipatokenTOTP schema objectclasses is a superset of the received one.
[08/Jan/2015:13:08:52 -0500] NSMMReplicationPlugin - [S] Schema agmt="cn=meTovm-052.idm.lab.bos.redhat.com" (vm-052:389) must not be overwritten (set replication log for additional info)
[08/Jan/2015:13:08:53 -0500] schema - Remote ipatokenTOTP schema objectclasses is a superset of the received one.
[08/Jan/2015:13:08:53 -0500] NSMMReplicationPlugin - [S] Schema agmt="cn=meTovm-052.idm.lab.bos.redhat.com" (vm-052:389) must not be overwritten (set replication log for additional info)
[08/Jan/2015:13:13:55 -0500] schema - Remote ipatokenTOTP schema objectclasses is a superset of the received one.
[08/Jan/2015:13:13:55 -0500] NSMMReplicationPlugin - [S] Schema agmt="cn=meTovm-052.idm.lab.bos.redhat.com" (vm-052:389) must not be overwritten (set replication log for additional info)
[08/Jan/2015:13:13:56 -0500] schema - Remote ipatokenTOTP schema objectclasses is a superset of the received one.
[08/Jan/2015:13:13:56 -0500] NSMMReplicationPlugin - [S] Schema agmt="cn=meTovm-052.idm.lab.bos.redhat.com" (vm-052:389) must not be overwritten (set replication log for additional info)
[08/Jan/2015:13:13:58 -0500] schema - Remote ipatokenTOTP schema objectclasses is a superset of the received one.
[08/Jan/2015:13:13:58 -0500] NSMMReplicationPlugin - [S] Schema agmt="cn=meTovm-052.idm.lab.bos.redhat.com" (vm-052:389) must not be overwritten (set replication log for additional info)
[08/Jan/2015:13:13:58 -0500] schema - Remote ipatokenTOTP schema objectclasses is a superset of the received one.
[08/Jan/2015:13:13:58 -0500] NSMMReplicationPlugin - [S] Schema agmt="cn=meTovm-052.idm.lab.bos.redhat.com" (vm-052:389) must not be overwritten (set replication log for additional info)

Continuing investigation
Comment 8 thierry bordaz 2015-01-09 15:49:52 UTC 
The problem comes from a change in ipatokenTOTP definition between 3.3.3 and 4.1.0.

1.3.3 definition:
objectClasses: ( 2.16.840.1.113730.3.8.16.2.2 
   NAME 'ipatokenTOTP' 
   DESC 'TOTP Token Type' 
   SUP ipaToken STRUCTURAL 
   MAY ( ipatokenOTPkey $ 
         ipatokenOTPalgorithm $ 
         ipatokenOTPdigits $ 
         ipatokenTOTPclockOffset $ 
         ipatokenTOTPtimeStep ) 

4.1.0
objectClasses: ( 2.16.840.1.113730.3.8.16.2.2 
   NAME 'ipatokenTOTP' 
   DESC 'TOTP Token Type' 
   SUP ipaToken STRUCTURAL 
   MUST ( ipatokenOTPkey $ 
          ipatokenOTPalgorithm $ 
          ipatokenOTPdigits $ 
          ipatokenTOTPclockOffset $ 
          ipatokenTOTPtimeStep ) 
   MAY ipatokenTOTPwatermark


I need to check debug deeper but I think
regarding the required attributes, 1.3.3 is a superset of 4.1.0
regarding the allowed  attributes 4.1.0 is a superset of 1.3.3

So I guess, 4.1.0 instance is not able to learn this definition AND also not able to send it to 1.3.3 instance
Comment 9 Petr Vobornik 2015-01-09 16:12:46 UTC 
FYI: the change described in comment 8 was introduced by https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=adcd373931c50d91550f6b74b191d08ecce5b137
Comment 10 Scott Poore 2015-01-09 19:04:39 UTC 
Thierry,

Looks like you've got the issue reproduced and no longer need me to provide machines?   If you do need me to provide machines, let me know again and I'll set that up.

Thanks,
Scott
Comment 11 Petr Vobornik 2015-01-12 15:19:09 UTC 
Upstream ticket:
https://fedorahosted.org/freeipa/ticket/4833
Comment 12 thierry bordaz 2015-01-15 17:43:02 UTC 
Scott,

Sorry for this late answer. Yes I reproduce the problem on my own VM and I am debugging them.

In terms of replication, both instance 'master' (4.1) and 'replica' (3.3) are 'suppliers'. At the beginning of a replication session, if the schema differs both 'suppliers' learns from the other the missing/extended schema definition.

At the end of this phase, I have supplier 3.3 having a schemaCSN this is higher than the supplier 4.1.
If we exclude the problem of the 'ipatokenOTP' (we can configure cn=replSchema,cn=config to ignore this problematic definition), the supplier 3.3 should contain a schema that is equivalent to 4.1 and so we should see the supplier 3.3 sending its schema to supplier 4.1.

Here there is a problem internal to DS. The supplier 3.3 detects it has to learn some definition, it does the internal MOD to update its schema BUT the schema is not updated. schema ldif files are not updated on supplier 3.3. I do not know why it happens. I will investigate this.

thanks
theirry
Comment 13 thierry bordaz 2015-01-16 14:09:18 UTC 
Actually there are 2 bugs one in IPA and one in DS.

The problem in IPA is that objectclass definition of ipatokenOTP in 4.1 was wrong.
Some allowed attributes in 3.3 became required in 4.1 and at the same time a new allowed attribute was added in 4.1.
So both 'master' and 'replica' were unable to send their schema.
At the same time, both were unable to learn the definition of the other.
https://fedorahosted.org/freeipa/ticket/4833 is opened for this issue.

An other bug exists in DS (https://fedorahosted.org/389/ticket/47988). During a replication session, a supplier checks if it can send its schema. If it can not, because the local schema is a subset of the remote schema, it learns the extra definitions.
The problem here is that it learns using (internal MOD) MOD-ADD. But if the local schema already contains the definition but the definition needs to be extended, it should rather do MOD-DEL (old definition) + MOD-ADD (new definition).

This bug does not create systematically an issue. The condition to create a replication issue is that the 'nsSchemaCSN' of superset schema, should be lower than the 'nsSchemaCSN' of the subset schema.
Comment 14 thierry bordaz 2015-01-19 08:23:01 UTC 
Finally there is a second bug in DS triggered by https://fedorahosted.org/389/ticket/47988

The suppliers detects its 'nsschemaCSN' is higher than the consumer. Before sending its schema it first checks that its own schema definitions are all superset of the consumer definitions. This was the case (after ignoring 'ipatokenOTP'). But for some reason it does not send its schema.

I think this is due to the consumer 'nsschemaCSN' that was also increased and became higher than the supplier 'ncschemaCSN'. When the supplier is ready to send its schema (because it checks successfully it is a superset of the consumer schema), it compare AGAIN its 'nsschemaCSN' with the consumer one. This time the consumer 'nsschemaCSN' is higher that the supplier, so the supplier does not send its schema.

The problem created by https://fedorahosted.org/389/ticket/47988 is that the replica is not able to extend its schema. So it is not able send its schema to the master.
Comment 18 Martin Kosek 2015-01-21 08:26:12 UTC 
FreeIPA part fixed upstream (the schema revert)

master:
https://fedorahosted.org/freeipa/changeset/fe4b3190e97679181d4d1349ad56e27ffe49dccd
ipa-4-1:
https://fedorahosted.org/freeipa/changeset/5b9902499b613af64919f4991f54ccac6708d365
ipa-4-0:
https://fedorahosted.org/freeipa/changeset/370a5b224910de479379673c3c9fc3242a5c8605

Note that the fix will be complete when the DS part is also fixed.
Comment 20 Scott Poore 2015-01-21 19:07:48 UTC 
Verified.

At the surface, the DNS and Host data is now visible.

Version ::

after master upgraded:
MASTER: ipa-server-4.1.0-16.el7.x86_64
REPLICA: ipa-server-3.3.3-28.el7.x86_64

Results ::


[root@vm2 ipa-upgrade]# ipa dnszone-find
  Zone name: 122.168.192.in-addr.arpa.
  Authoritative nameserver: vm1.testrelm.test.
  Administrator e-mail address: hostmaster.testrelm.test.
  SOA serial: 1421861795
  SOA refresh: 3600
  SOA retry: 900
  SOA expire: 1209600
  SOA minimum: 3600
  Active zone: TRUE
  Allow query: any;
  Allow transfer: none;

  Zone name: 171.168.192.in-addr.arpa.
  Authoritative nameserver: vm1.testrelm.test.
  Administrator e-mail address: ipaqar.redhat.com.
  SOA serial: 1421861795
  SOA refresh: 3600
  SOA retry: 900
  SOA expire: 1209600
  SOA minimum: 3600
  Active zone: TRUE
  Allow query: any;
  Allow transfer: none;

  Zone name: 172.168.192.in-addr.arpa.
  Authoritative nameserver: vm1.testrelm.test.
  Administrator e-mail address: ipaqar.redhat.com.
  SOA serial: 1421861796
  SOA refresh: 3600
  SOA retry: 900
  SOA expire: 1209600
  SOA minimum: 3600
  Active zone: TRUE
  Allow query: any;
  Allow transfer: none;

  Zone name: testrelm.test
  Authoritative nameserver: vm1.testrelm.test.
  Administrator e-mail address: hostmaster.testrelm.test.
  SOA serial: 1421861795
  SOA refresh: 3600
  SOA retry: 900
  SOA expire: 1209600
  SOA minimum: 3600
  Active zone: TRUE
  Allow query: any;
  Allow transfer: none;
----------------------------
Number of entries returned 4
----------------------------



[root@vm2 ipa-upgrade]# ipa host-find
---------------
8 hosts matched
---------------
  Host name: bank.testrelm.test
  Principal name: host/bank.testrelm.test
  Password: False
  Member of host-groups: calchostgroup
  Keytab: False
  Managed by: bank.testrelm.test

  Host name: ftp.testrelm.test
  Principal name: host/ftp.testrelm.test
  Password: False
  Member of host-groups: enghostgroup
  Member of netgroups: engnetgroup
  Keytab: False
  Managed by: ftp.testrelm.test

  Host name: newspaper.testrelm.test
  Principal name: host/newspaper.testrelm.test
  Class: test_string_1
  Password: False
  Member of host-groups: calchostgroup
  Keytab: False
  Managed by: newspaper.testrelm.test

  Host name: postoffice.testrelm.test
  Principal name: host/postoffice.testrelm.test
  Password: False
  Member of host-groups: calchostgroup
  Keytab: False
  Managed by: postoffice.testrelm.test

  Host name: vm1.testrelm.test
  Principal name: host/vm1.testrelm.test
  Password: False
  Keytab: True
  Managed by: vm1.testrelm.test
  SSH public key fingerprint: 09:08:0E:9C:B1:31:B4:9C:BA:9A:CB:A4:C7:59:38:C0 (ecdsa-sha2-nistp256),
                              3B:1D:A4:75:73:86:11:35:51:0D:2A:B6:18:17:0B:C8 (ssh-rsa)

  Host name: vm2.testrelm.test
  Principal name: host/vm2.testrelm.test
  Password: False
  Keytab: True
  Managed by: vm2.testrelm.test
  SSH public key fingerprint: 09:08:0E:9C:B1:31:B4:9C:BA:9A:CB:A4:C7:59:38:C0 (ecdsa-sha2-nistp256),
                              3B:1D:A4:75:73:86:11:35:51:0D:2A:B6:18:17:0B:C8 (ssh-rsa)

  Host name: vm3.testrelm.test
  Certificate: MIIEFzCCAv+gAwIBAgIBDjANBgkqhkiG9w0BAQsFADA4MRYwFAYDVQQKEw1URVNUUkVMTS5URVNUMR4wHAYDVQQDExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMTUwMTIxMTczMTA0WhcNMTcwMTIxMTczMTA0WjA0MRYwFAYDVQQKEw1URVNUUkVMTS5URVNUMRowGAYDVQQDExF2bTMudGVzdHJlbG0udGVzdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMWTYEOHYMLubj87GSFLsAr2IyQ1NLtNPezGSo8YVSXCvl9gGRPnNitEbBacWtOqL8zlujq2NBdRABFo+WG9zjuPaaUy4w7XHW4gg0CFk1Ztxmzkc3THLSc+EVepsbgfAVurh7dQm2VhWCb4HXin0w5Ds+SdnI4w1qRVP4EhRE0enUKjb5iZME/rIJkG7vyzoVMFIQzCzBfu2K4y1fV2MQwfp4G6fIP9mgjJEOYR/AVnQ0vUMPGVLGWja0pZIBPxFWyEArclraG/Stm8FV8YPoPktNnDDWlX5wgwKDyOD0Dtl6iWdO2P4edmMBY75gJaA3EWSws5Ckm0RiRqblt421sCAwEAAaOCAS4wggEqMB8GA1UdIwQYMBaAFK89591Il+qVyFfjLjbLvDi37VEyMD8GCCsGAQUFBwEBBDMwMTAvBggrBgEFBQcwAYYjaHR0cDovL2lwYS1jYS50ZXN0cmVsbS50ZXN0L2NhL29jc3AwDgYDVR0PAQH/BAQDAgTwMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjB4BgNVHR8EcTBvMG2gNaAzhjFodHRwOi8vaXBhLWNhLnRlc3RyZWxtLnRlc3QvaXBhL2NybC9NYXN0ZXJDUkwuYmluojSkMjAwMQ4wDAYDVQQKEwVpcGFjYTEeMBwGA1UEAxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB0GA1UdDgQWBBRqEAwg157h23iT6POnwykx2Y05QjANBgkqhkiG9w0BAQsFAAOCAQEAPAkbfj+ZroWOHTBLbOVrcnwI7fi/uVrC6EnY3YtjBKh9DyNFoxwxA0uEMUyccUD+zOQ1EkzlbrqamqqlrD3TCm7oxouYIx+DrtQ4vA51lGDuKl8h2fOugZuNSfEz2QV7O3MoPRTbk1to9nTiXnnsukGNuI5JO8Q2TJRFar9GmeZcTx+YT6kO1JQHzc8npFRXq2NGPlMOqTG7P7CMWSIzRpW7y+MxlQN+oHYW2CA6sysUDiCEPWBhEA1wgzKlms1IgvmjiOlHHlXRy+W95ewJ9XmYjbBgtscAxuEUibcKfDHYAWobwsGV/Q5altyKrlz91CDgzcuNuNKHCoCsBoEZWQ==
  Principal name: host/vm3.testrelm.test
  Password: False
  Keytab: True
  Managed by: vm3.testrelm.test
  Subject: CN=vm3.testrelm.test,O=TESTRELM.TEST
  Serial Number: 14
  Serial Number (hex): 0xE
  Issuer: CN=Certificate Authority,O=TESTRELM.TEST
  Not Before: Wed Jan 21 17:31:04 2015 UTC
  Not After: Sat Jan 21 17:31:04 2017 UTC
  Fingerprint (MD5): a5:d9:e5:b6:03:c3:3a:13:9c:c4:5b:98:72:10:6a:ed
  Fingerprint (SHA1): 51:28:86:70:12:51:e5:68:5d:51:f6:a2:ef:ed:d5:e0:c3:34:4e:54
  SSH public key fingerprint: 09:08:0E:9C:B1:31:B4:9C:BA:9A:CB:A4:C7:59:38:C0 (ecdsa-sha2-nistp256),
                              3B:1D:A4:75:73:86:11:35:51:0D:2A:B6:18:17:0B:C8 (ssh-rsa)

  Host name: web.testrelm.test
  Principal name: host/web.testrelm.test
  Password: False
  Member of host-groups: devhostgroup
  Member of netgroups: devnetgroup
  Keytab: False
  Managed by: web.testrelm.test
----------------------------
Number of entries returned 8
----------------------------
Comment 21 thierry bordaz 2015-01-22 09:36:33 UTC 

Fixing https://fedorahosted.org/freeipa/ticket/4833 was required to fix this bug but it is not sufficient. An other dynamic problem can prevent the schema to be correctly replicated. This is investigated under https://bugzilla.redhat.com/show_bug.cgi?id=1183655 (upstream https://fedorahosted.org/389/ticket/47988).

I am still working on https://fedorahosted.org/389/ticket/47988. 
I broke my  ipa test env and rebuilt a new one.
Comment 30 errata-xmlrpc 2015-03-05 10:19:12 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.

https://rhn.redhat.com/errata/RHSA-2015-0442.html
Note You need to log in before you can comment on or make changes to this bug.