Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
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 918708

Summary: RUV is not getting updated for both Master and consumer
Product: Red Hat Enterprise Linux 7 Reporter: Nathan Kinder <nkinder>
Component: 389-ds-baseAssignee: Rich Megginson <rmeggins>
Status: CLOSED CURRENTRELEASE QA Contact: Sankar Ramalingam <sramling>
Severity: unspecified Docs Contact:
Priority: medium    
Version: 7.0CC: jgalipea, mreynolds, nhosoi
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 389-ds-base-1.3.1.2-1.el7 Doc Type: Bug Fix
Doc Text:
Cause: Changing a replica type to another type. E.g. Master -> Hub Consequence: The replication RUV is updated correctly after making this change. Fix: When the replica type is changed the replication RUV gets updated, the changelog RUV is cleaned, and the replication agreements are notified. Result: The replication RUV reflects the correct replication settings
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-06-13 10:18:40 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Nathan Kinder 2013-03-06 18:15:52 UTC
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/389/ticket/532

Hi,

Ruv is not getting updated properly when changing the replica role from the Admin server GUI. Please find the reproducer details below.

Reproducer:
===========
Step-1:  Create two instances named as INST1 and INST2
Step-2: Register the above two instances with the Admin server 
Step-3:  Assign the Hub role to INST1 from the admin server GUI. Configuration tab -> replication -> userRoot -> enable the replication and assign the HUB role  -> Save
Step-4:  Assign the consumer role to INST2 from the admin server GUI. Configuration tab -> replication -> userRoot -> enable the replication and assign the consumer role -> Save
Step-5:  Change the role for INST1 from Hub to Master from Admin Server GUI. Configuarion tab-> replication  -> userRoot > enable the Single Master check box and provide the appropriate replica id -> Save
 
Check the RUV

RUV:
=====
  dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=asiapacific,dc=hpqcorp,dc=net
objectClass: top
objectClass: nsTombstone
objectClass: extensibleobject
nsds50ruv: {replicageneration} 50b5024c0000ffff0000
dc: asiapacific
=====

Step-6: Create a replication agreement between the INST1 and INST2. Checked the RUV.There is no change here in the RUV

RUV:
=====
  dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=asiapacific,dc=hpqcorp,dc=net
objectClass: top
objectClass: nsTombstone
objectClass: extensibleobject
nsds50ruv: {replicageneration} 50b5024c0000ffff0000
dc: asiapacific
=====

Step-7: Add an entry to the INST1 and check the RUV

RUV in INST1:
======
dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=asiapacific,dc=hpqcorp,dc=net
objectClass: top
objectClass: nsTombstone
objectClass: extensibleobject
nsds50ruv: {replicageneration} 50b5024c0000ffff0000
nsds50ruv: {replica 65535 ldap://dirsrv12.asiapacific.hpqcorp.net:2
389} 50b506150000ffff0000 50b506150000ffff0000
dc: asiapacific
nsruvReplicaLastModified: {replica 65535 ldap://dirsrv12.asiapacifi
c.hpqcorp.net:2389} 50b50615

As you can see here, RUV in the INST1 which is a supplier is having the replica id 65535 even after given a proper id during role change and below in the INST2  RUV  which is a consumer here it’s max CSN is not getting updated in the RUV. Could you please give your insight to this problem?. Please note that it is being reproduced in the latest version of 389 directory server i.e. 1.2.15


RUV in INST2:
========
dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=asiapacific,dc=hpqcorp,d
c=net
objectClass: top
objectClass: nsTombstone
objectClass: extensibleobject
nsds50ruv: {replicageneration} 50b5024c0000ffff0000
nsds50ruv: {replica 65535 ldap://dirsrv12.asiapacific.hpqcorp.net:2
389} 50b506150000ffff0000
dc: asiapacific
nsruvReplicaLastModified: {replica 65535 ldap://dirsrv12.asiapacifi
c.hpqcorp.net:2389} 50b50616

Comment 1 Rich Megginson 2013-10-01 23:26:46 UTC
moving all ON_QA bugs to MODIFIED in order to add them to the errata (can't add bugs in the ON_QA state to an errata).  When the errata is created, the bugs should be automatically moved back to ON_QA.

Comment 3 Sankar Ramalingam 2014-02-25 14:56:07 UTC
Admin console related bugs cannot be verified with RHEL7 release, since its not supported. 

The clone of this bug will be verified in RHEL7.1 release. For RHEL7 release, marking the bug as verified as Sanity only.

Build tested - 389-ds-base-1.3.1.6-19.el7.x86_64

Comment 4 Ludek Smid 2014-06-13 10:18:40 UTC
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.