Bug 2217641
| Summary: | dsconf replication status fails with 'Invalid credentials' while trying to reuse initial credentials. [11.8.0z] | |||
|---|---|---|---|---|
| Product: | Red Hat Directory Server | Reporter: | Têko Mihinto <tmihinto> | |
| Component: | 389-ds-base | Assignee: | Simon Pichugin <spichugi> | |
| Status: | CLOSED ERRATA | QA Contact: | LDAP QA Team <idm-ds-qe-bugs> | |
| Severity: | high | Docs Contact: | Evgenia Martynyuk <emartyny> | |
| Priority: | high | |||
| Version: | 11.7 | CC: | bsmejkal, idm-ds-dev-bugs, musoni, spichugi, tbordaz, vashirov | |
| Target Milestone: | --- | Keywords: | Triaged, ZStream | |
| Target Release: | dirsrv-11.8 | |||
| Hardware: | x86_64 | |||
| OS: | Linux | |||
| Whiteboard: | sync-to-jira | |||
| Fixed In Version: | redhat-ds-11-8090020231206112255.91529cd0 | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 2251260 (view as bug list) | Environment: | ||
| Last Closed: | 2024-01-09 09:05:56 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: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 2251260 | |||
Fixed upstream. Build tested: 389-ds-base-1.4.3.37-8.module+el8dsrv+20865+9b2054cd.x86_64
dsconf now asks for a Bind DN and password instead of assuming the same credentials:
dsconf -D "cn=Directory Manager" ldap://localhost:1389 replication status --suffix "dc=example,dc=com"
Enter password for cn=Directory Manager on ldap://localhost:1389:
Enter bind DN for the replicated suffix (dc=example,dc=com) on localhost:2389 : cn=Directory Manager
Enter password for (cn=Directory Manager) to the replicated suffix (dc=example,dc=com) on localhost:2389 :
{'agmt-name': ['me_1to2'], 'replica': ['localhost:2389'], 'replica-enabled': ['on'], 'update-in-progress': ['FALSE'], 'last-update-start': ['20231218104514Z'], 'last-update-end': ['20231218104514Z'], 'number-changes-sent': ['0'], 'number-changes-skipped': ['unavailable'], 'last-update-status': ['Error (0) Replica acquired successfully: Incremental update succeeded'], 'last-init-start': ['20231218104512Z'], 'last-init-end': ['20231218104514Z'], 'last-init-status': ['Error (0) Total update succeeded'], 'reap-active': ['0'], 'replication-status': ['Not in Synchronization: supplier (Unknown) consumer (Unknown) State (green) Reason (error (0) replica acquired successfully: incremental update succeeded)'], 'replication-lag-time': ['unavailable']}
# dsconf -D "cn=Directory Manager" ldap://localhost:1389 repl-agmt status --suffix "dc=example,dc=com" me_1to2
Enter password for cn=Directory Manager on ldap://localhost:1389:
Enter bind DN for the replicated suffix (dc=example,dc=com) on localhost:2389 : cn=Directory Manager
Enter password for (cn=Directory Manager) to the replicated suffix (dc=example,dc=com) on localhost:2389 :
Status For Agreement: "me_1to2" (localhost:2389)
Replica Enabled: on
Update In Progress: FALSE
Last Update Start: 20231218104514Z
Last Update End: 20231218104514Z
Number Of Changes Sent: 0
Number Of Changes Skipped: None
Last Update Status: Error (0) Replica acquired successfully: Incremental update succeeded
Last Init Start: 20231218104512Z
Last Init End: 20231218104514Z
Last Init Status: Error (0) Total update succeeded
Reap Active: 0
Replication Status: Not in Synchronization: supplier (Unknown) consumer (Unknown) State (green) Reason (error (0) replica acquired successfully: incremental update succeeded)
Replication Lag Time: unavailable
Marking as VERIFIED.
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 (redhat-ds:11 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/RHBA-2024:0088 |
Description of problem: dsconf replication status is failing with 'Invalid credentials' when: * Connecting as "cn=Directory Manager" ( haven't tried with a regular user yet ). and * The password of the Directory Manager is not identical on servers: $ dsconf -D "cn=Directory Manager" ldap://localhost:5389 replication status --suffix "dc=example,dc=com" Enter password for cn=Directory Manager on ldap://localhost:5389: Error: Unable to get lag time: {'msgtype': 97, 'msgid': 1, 'result': 49, 'desc': 'Invalid credentials', 'ctrls': []} $ Version-Release number of selected component (if applicable): $ cat /etc/redhat-release Red Hat Enterprise Linux release 8.8 (Ootpa) $ $ rpm -qa 389-ds* 389-ds-base-1.4.3.31-11.module+el8dsrv+17815+4f95348d.x86_64 389-ds-base-libs-1.4.3.31-11.module+el8dsrv+17815+4f95348d.x86_64 $ How reproducible: Always. Steps to Reproduce: 1. Create 2 RHDS instances 2. Do not use identical passwords for the Directory Manager 3. Enable replication and create a simple "Supplier ==> Consumer" topology 4. Run the "dsconf replication status" command Actual results: The command fails with 'Invalid credentials' errors. Expected results: Working commands Additional info: The command works fine if the Directory Manager's password is the same on both servers: $ dsconf -D "cn=Directory Manager" ldap://localhost:5389 replication status --suffix "dc=example,dc=com" Enter password for cn=Directory Manager on ldap://localhost:5389: {'agmt-name': ['test_to_alps1'], 'replica': ['XXX:1389'], 'replica-enabled': ['on'], 'update-in-progress': ['FALSE'], 'last-update-start': ['20230626185732Z'], 'last-update-end': ['20230626185732Z'], 'number-changes-sent': ['5000:7/0 '], 'number-changes-skipped': ['unavailable'], 'last-update-status': ['Error (0) Replica acquired successfully: Incremental update succeeded'], 'last-init-start': ['20230626183157Z'], 'last-init-end': ['20230626183204Z'], 'last-init-status': ['Error (0) Total update succeeded'], 'reap-active': ['0'], 'replication-status': ['In Synchronization'], 'replication-lag-time': ['00:00:00']} $