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 1175277 - Data replication not working as expected after data restore from full backup
Summary: Data replication not working as expected after data restore from full backup
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipa
Version: 7.1
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: rc
: ---
Assignee: IPA Maintainers
QA Contact: Namita Soman
URL:
Whiteboard:
: 1182568 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-12-17 12:36 UTC by Kaleem
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:
Environment:
Last Closed: 2015-03-05 10:19:00 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
cotains replica's dirsrv's error log and console output of master (16.00 KB, text/plain)
2014-12-17 12:36 UTC, Kaleem 		no flags Details
console output (26.85 KB, text/plain)
2015-01-28 07:53 UTC, Kaleem 		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 Kaleem 2014-12-17 12:36:51 UTC 
Created attachment 970085 [details]
cotains replica's dirsrv's error log and console output of master

Description of problem:
I tried following scenario

Data restore from full backup on Master
=======================================
(1)Added one user(masteruser1) on Master and one user (replicauser1)on Replica before backup and expecting these two users available after data restore from full backup.
(2)Took full ipa backup
(3)Deleted users added in step(1). Expecting these deleted users to be available after restore
(4)Added one more user(masteruser2) on Master and one more user (replicauser2)on Replica after backup and expecting these two users not available after data restore from full backup.
(5)Restored data from full backup on Master.

After restoration i was expecting users added in step(1) available But i found user added on master before backup (masteruser1) and user added on replica after backup (replicauser2). 

Version-Release number of selected component (if applicable):
[root@dhcp207-214 ~]# rpm -q ipa-server
ipa-server-4.1.0-12.el7.x86_64
[root@dhcp207-214 ~]# 

How reproducible:
Always

Steps to reproduce.
 - Mentioned in description.

Actual results:
Users added on replica before backup not available after data restore from full backup

Expected results:
Users added on master and replica before backup should be available after data restore from full backup

Additional info:
(1)Please refer the attachment for replica's dirsrv's errors log and console output of master
Comment 2 Kaleem 2015-01-05 15:45:55 UTC 
Also found this behaviour in following scenario also

- Full restore from full backup
Comment 3 Martin Kosek 2015-01-05 16:09:55 UTC 
Upstream ticket:
https://fedorahosted.org/freeipa/ticket/4822
Comment 5 thierry bordaz 2015-01-09 09:52:57 UTC 
Hi Kaleem,

Would you provide the access/errors logs and config (dse.ldif) of both master and replica ?

Also in the attachment you said 'users after reinitializing the replication on Replica(first attempt) :' What does it mean ?

Thanks
thierry
Comment 7 thierry bordaz 2015-01-12 10:27:09 UTC 
Hello Kaleem,

The logs do not contain 'replicauser[12]' or 'masteruser[12]'. I can only find a 'testuser1' in the logs. 

Would it be possible that you reproduce the problem and then provide the logs and config?

If possible enable replication logging on replica/master before the retry
MOD (cn=config, nsslapd-errorlog-level: 8192).


Thanks for you help Kaleem
Comment 8 Kaleem 2015-01-12 13:48:42 UTC 
Provided machines for debugging on which issue found. Users added through automated scripts are different.
Comment 9 thierry bordaz 2015-01-13 14:45:15 UTC 
The problem is that once the master is recovered, replication master<-->replica gets broken. BEFORE the replica can get the chance to send all old updates (DEL testuser1, DEL testuser2, ADD testuser3, ADD testuser4), the DNA plugin triggers internal modifications. One of the modification (I ignore if there are others modifications) is the ADD of the entry: dnaHostname=master.testrelm.test+dnaPortNum=389,cn=posix-ids,cn=dna,cn=ipa
 ,cn=etc,dc=testrelm,dc=test.

This modification hit the bug https://fedorahosted.org/389/ticket/47986. 
This intenal MOD on master has a CSN that is unknown from the replica. So the replica can not update the supplier.

A fix is under implementation to remove the RUV from the backup ldif.
This because a recovered master should not be updated with updates more recent than the backup.
Comment 10 Jan Cholasta 2015-01-13 16:59:46 UTC 
Fixed upstream
master:
https://fedorahosted.org/freeipa/changeset/05e6adecb51b93e9b9d2326df4eabee90c3dfe72
ipa-4-1:
https://fedorahosted.org/freeipa/changeset/eb7917026d418a6d6a1e7a24a19097065df10497
Comment 12 Jan Cholasta 2015-01-15 14:37:19 UTC 
*** Bug 1182568 has been marked as a duplicate of this bug. ***
Comment 13 Jan Cholasta 2015-01-15 14:38:03 UTC 
A regression was found in the fix.
Comment 14 Martin Kosek 2015-01-21 07:32:52 UTC 
Regression fixed upstream
master:
https://fedorahosted.org/freeipa/changeset/4994cd1d8dde69d94130894ca86aa8a11fb590bf
ipa-4-1:
https://fedorahosted.org/freeipa/changeset/85599416ae4a0cc83b8e0669e686740dd2a10ea2
Comment 16 Kaleem 2015-01-28 07:51:49 UTC 
Verified.

IPA Version:
============
[root@master ~]# rpm -q ipa-server
ipa-server-4.1.0-16.el7.x86_64
[root@master ~]# 


[root@master ~]# ipa-restore -p xxxxxxxx --data -U /var/lib/ipa/backup/ipa-data-2015-01-28-15-42-55/
Preparing restore from /var/lib/ipa/backup/ipa-data-2015-01-28-15-42-55/ on master.testrelm.test
Performing DATA restore from DATA backup
Each master will individually need to be re-initialized or
re-created from this one. The replication agreements on
masters running IPA 3.1 or earlier will need to be manually
re-enabled. See the man page for details.
Disabling all replication.
Disabling replication agreement on dhcp207-58.testrelm.test to master.testrelm.test
Stopping Directory Server
Restoring from userRoot in TESTRELM-TEST
Restoring from ipaca in TESTRELM-TEST
Starting Directory Server
The ipa-restore command was successful
[root@master ~]# ipa user-find
---------------
3 users matched
---------------
  User login: admin
  Last name: Administrator
  Home directory: /home/admin
  Login shell: /bin/bash
  UID: 381600000
  GID: 381600000
  Account disabled: False
  Password: True
  Kerberos keys available: True

  User login: testuser1
  First name: testuser1
  Last name: testuser1
  Home directory: /home/testuser1
  Login shell: /bin/sh
  Email address: testuser1
  UID: 381600001
  GID: 381600001
  Account disabled: False
  Password: True
  Kerberos keys available: True

  User login: testuser2
  First name: testuser2
  Last name: testuser2
  Home directory: /home/testuser2
  Login shell: /bin/sh
  Email address: testuser2
  UID: 381700500
  GID: 381700500
  Account disabled: False
  Password: True
  Kerberos keys available: True
----------------------------
Number of entries returned 3
----------------------------
[root@master ~]# sleep 300
[root@master ~]# ipa user-find
---------------
3 users matched
---------------
  User login: admin
  Last name: Administrator
  Home directory: /home/admin
  Login shell: /bin/bash
  UID: 381600000
  GID: 381600000
  Account disabled: False
  Password: True
  Kerberos keys available: True

  User login: testuser1
  First name: testuser1
  Last name: testuser1
  Home directory: /home/testuser1
  Login shell: /bin/sh
  Email address: testuser1
  UID: 381600001
  GID: 381600001
  Account disabled: False
  Password: True
  Kerberos keys available: True

  User login: testuser2
  First name: testuser2
  Last name: testuser2
  Home directory: /home/testuser2
  Login shell: /bin/sh
  Email address: testuser2
  UID: 381700500
  GID: 381700500
  Account disabled: False
  Password: True
  Kerberos keys available: True
----------------------------
Number of entries returned 3
-----------------


Please find the attached console output of Master/Replica.
Comment 17 Kaleem 2015-01-28 07:53:00 UTC 
Created attachment 985004 [details]
console output
Comment 19 errata-xmlrpc 2015-03-05 10:19:00 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.