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 1807773

Summary: dsctl healthcheck : typo in DSREPLLE0002 Lint error suggested resolution commands
Product: Red Hat Enterprise Linux 8 Reporter: sgouvern
Component: 389-ds-baseAssignee: mreynolds
Status: CLOSED ERRATA QA Contact: RHDS QE <ds-qe-bugs>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 8.2CC: pasik, spichugi, tbordaz, vashirov
Target Milestone: rcFlags: pm-rhel: mirror+
Target Release: 8.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 389-ds-base-1.4.3.8-4.module+el8.3.0+7193+dfd1e8ad Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-11-04 03:07:44 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description sgouvern 2020-02-27 08:55:09 UTC
Description of problem:
 Lint Error: DSREPLLE0002 proposed resolution suggests an invalid command: 
# dsconf slapd-master1  repl-conflict remove <DN of conflict entry>
should be
# dsconf slapd-master1  repl-conflict delete <DN of conflict entry>

Version-Release number of selected component (if applicable):
389-ds-base-1.4.2.8-2.module+el8dsrv+5809+6657a82a.x86_64

How reproducible:
Get conditions to have the Lint Error: DSREPLLE0002 - Presence of conflict entries - reported by dsctl healthcheck


Steps to Reproduce:
1. Run py.test : # DEBUGGING=True py.test -v ds/dirsrvtests/tests/suites/replication/conflict_resolve_test.py::TestTwoMasters::test_add_modrdn
2. Restart master1 and master2
3. Run # dsctl master1 healthcheck

Actual results:
[1] DS Lint Error: DSREPLLE0002
--------------------------------------------------------------------------------
Severity: LOW
Affects:
 -- Replication
 -- Conflict Entries

...

Resolution:
-----------
While conflict entries are expected to occur in an MMR environment, they
should be resolved.  In regards to conflict entries there is always the original/counterpart
entry that has a normal DN, and then the conflict version of that entry.  Technically both
entries are valid, you as the administrator, needs to decide which entry you want to keep.
First examine/compare both entries to determine which one you want to keep or remove.  You
can use the CLI tool "dsconf" to resolve the conflict.  Here is an example:

    List the conflict entries:

        # dsconf slapd-master1  repl-conflict list dc=example,dc=com

    Examine conflict entry and its counterpart entry:

        # dsconf slapd-master1  repl-conflict compare <DN of conflict entry>

    Remove conflict entry and keep only the original/counterpart entry:

        # dsconf slapd-master1  repl-conflict remove <DN of conflict entry>
...


Expected results:
The latest lines should be :

Remove conflict entry and keep only the original/counterpart entry:

        # dsconf slapd-master1  repl-conflict delete <DN of conflict entry>

Additional info:
Running the suggested command issues error :
# dsconf slapd-master1  repl-conflict remove nsuniqueid=8c977c03-593811ea-a450fe0b-b6f9d4f2+uid=test_user_1007,cn=test_container,dc=example,dc=com
usage: dsconf instance repl-conflict [-h]
                                     {list,compare,delete,swap,convert,list-glue,delete-glue,convert-glue}
                                     ...
dsconf instance repl-conflict: error: invalid choice: 'remove' (choose from 'list', 'compare', 'delete', 'swap', 'convert', 'list-glue', 'delete-glue', 'convert-glue')

while the following with 'delete' works
# dsconf slapd-master1  repl-conflict delete nsuniqueid=8c977c03-593811ea-a450fe0b-b6f9d4f2+uid=test_user_1007,cn=test_container,dc=example,dc=com

Comment 4 sgouvern 2020-06-09 11:37:07 UTC
With build 389-ds-base-1.4.3.8-3.module+el8.3.0+6935+6f68b788.x86_64, the error is still there :


[1] DS Lint Error: DSREPLLE0002
--------------------------------------------------------------------------------
Severity: LOW 
Affects:
 -- Replication
 -- Conflict Entries

Details:
-----------
There were 4 conflict entries found under the replication suffix "dc=example,dc=com".

Resolution:
-----------
While conflict entries are expected to occur in an MMR environment, they
should be resolved.  In regards to conflict entries there is always the original/counterpart
entry that has a normal DN, and then the conflict version of that entry.  Technically both
entries are valid, you as the administrator, needs to decide which entry you want to keep.
First examine/compare both entries to determine which one you want to keep or remove.  You
can use the CLI tool "dsconf" to resolve the conflict.  Here is an example:

    List the conflict entries:

        # dsconf slapd-master1  repl-conflict list dc=example,dc=com

    Examine conflict entry and its counterpart entry:

        # dsconf slapd-master1  repl-conflict compare <DN of conflict entry>

    Remove conflict entry and keep only the original/counterpart entry:

        # dsconf slapd-master1  repl-conflict remove <DN of conflict entry>                 <<<<

    Replace the original/counterpart entry with the conflict entry:

        # dsconf slapd-master1  repl-conflict swap <DN of conflict entry>




# dsconf slapd-master1  repl-conflict remove nsuniqueid=7b283a89-aa2411ea-8f28f009-b3e2346c+uid=test_user_1007,cn=test_container,dc=example,dc=com
usage: dsconf instance repl-conflict [-h]
                                     {list,compare,delete,swap,convert,list-glue,delete-glue,convert-glue}
                                     ...
dsconf instance repl-conflict: error: invalid choice: 'remove' (choose from 'list', 'compare', 'delete', 'swap', 'convert', 'list-glue', 'delete-glue', 'convert-glue')


*remove* still needs to be replaced to *delete*

-> reassigning as Failed QA

Comment 5 mreynolds 2020-06-22 22:20:14 UTC
This ended up getting fixed in BZ#1843567

Comment 6 sgouvern 2020-07-08 12:42:12 UTC
With 389-ds-base-libs-1.4.3.8-4.module+el8.3.0+7193+dfd1e8ad.x86_64:

[root@ci-vm-10-0-139-5 upstream]# dsctl master1 healthcheck
Enter Bind DN: cn=directory manager
Enter password for cn=directory manager on master1: 
Beginning lint report, this could take a while ...
Checking config:hr_timestamp ...
Checking config:passwordscheme ...
Checking backends:userroot:mappingtree ...
Checking backends:userroot:search ...
Checking backends:userroot:virt_attrs ...
Checking encryption:check_tls_version ...
Checking fschecks:file_perms ...
Checking refint:attr_indexes ...
Checking refint:update_delay ...
Checking monitor-disk-space:disk_space ...
Checking replication:agmts_status ...
Checking replication:conflicts ...
Checking changelog:cl_trimming ...
Checking dseldif:nsstate ...
Checking ssl:certificate_expiration ...
Checking logs:notes ...
Healthcheck complete.
2 Issues found!  Generating report ...


[1] DS Lint Error: DSREPLLE0002
--------------------------------------------------------------------------------
Severity: LOW 
Affects:
 -- Replication
 -- Conflict Entries

Details:
-----------
There were 4 conflict entries found under the replication suffix "dc=example,dc=com".

Resolution:
-----------
While conflict entries are expected to occur in an MMR environment, they
should be resolved.  In regards to conflict entries there is always the original/counterpart
entry that has a normal DN, and then the conflict version of that entry.  Technically both
entries are valid, you as the administrator, needs to decide which entry you want to keep.
First examine/compare both entries to determine which one you want to keep or remove.  You
can use the CLI tool "dsconf" to resolve the conflict.  Here is an example:

    List the conflict entries:

        # dsconf slapd-master1  repl-conflict list dc=example,dc=com

    Examine conflict entry and its counterpart entry:

        # dsconf slapd-master1  repl-conflict compare <DN of conflict entry>

    Remove conflict entry and keep only the original/counterpart entry:

        # dsconf slapd-master1  repl-conflict delete <DN of conflict entry>

    Replace the original/counterpart entry with the conflict entry:

        # dsconf slapd-master1  repl-conflict swap <DN of conflict entry>


=> 'remove' has been replaced by 'delete' in # dsconf slapd-master1  repl-conflict delete <DN of conflict entry>
marking as Veriied

Comment 9 errata-xmlrpc 2020-11-04 03:07:44 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 (389-ds:1.4 bug fix and enhancement update), 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://access.redhat.com/errata/RHEA-2020:4695