Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1175277 - Data replication not working as expected after data restore from full backup
Data replication not working as expected after data restore from full backup
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipa (Show other bugs)
7.1
Unspecified Unspecified
high Severity unspecified
: rc
: ---
Assigned To: IPA Maintainers
Namita Soman
: TestBlocker
: 1182568 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2014-12-17 07:36 EST by Kaleem
Modified: 2015-03-05 05:19 EST (History)
6 users (show)

See Also:
Fixed In Version: ipa-4.1.0-16.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-03-05 05:19:00 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
cotains replica's dirsrv's error log and console output of master (16.00 KB, text/plain)
2014-12-17 07:36 EST, Kaleem
no flags Details
console output (26.85 KB, text/plain)
2015-01-28 02:53 EST, Kaleem
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:0442 normal SHIPPED_LIVE Moderate: ipa security, bug fix, and enhancement update 2015-03-05 09:50:39 EST

  None (edit)
Description Kaleem 2014-12-17 07:36:51 EST
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 10:45:55 EST
Also found this behaviour in following scenario also

- Full restore from full backup
Comment 3 Martin Kosek 2015-01-05 11:09:55 EST
Upstream ticket:
https://fedorahosted.org/freeipa/ticket/4822
Comment 5 thierry bordaz 2015-01-09 04:52:57 EST
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 05:27:09 EST
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 08:48:42 EST
Provided machines for debugging on which issue found. Users added through automated scripts are different.
Comment 9 thierry bordaz 2015-01-13 09:45:15 EST
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 12 Jan Cholasta 2015-01-15 09:37:19 EST
*** Bug 1182568 has been marked as a duplicate of this bug. ***
Comment 13 Jan Cholasta 2015-01-15 09:38:03 EST
A regression was found in the fix.
Comment 16 Kaleem 2015-01-28 02:51:49 EST
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@testrelm.test
  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@testrelm.test
  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@testrelm.test
  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@testrelm.test
  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 02:53:00 EST
Created attachment 985004 [details]
console output
Comment 19 errata-xmlrpc 2015-03-05 05:19:00 EST
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.