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 1848726

Summary: dsctl might fail if the actual instance name starts with "slapd-" (eg: slapd-slapd-test ).
Product: Red Hat Enterprise Linux 8 Reporter: Têko Mihinto <tmihinto>
Component: 389-ds-baseAssignee: mreynolds
Status: CLOSED DUPLICATE QA Contact: RHDS QE <ds-qe-bugs>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 8.2CC: lkrispen, spichugi, tbordaz, vashirov
Target Milestone: rcFlags: pm-rhel: mirror+
Target Release: 8.0   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-06-18 21:11:40 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 Têko Mihinto 2020-06-18 20:19:40 UTC
Description of problem:
If a full instance name contains more than a single occurrence of "-slapd",
some dsctl commands fail

Version-Release number of selected component (if applicable):
# cat /etc/redhat-release
Red Hat Enterprise Linux release 8.2 (Ootpa)
#
# rpm -qa | grep 389-ds-base
389-ds-base-1.4.2.12-2.module+el8dsrv+6428+6e54c518.x86_64
389-ds-base-libs-1.4.2.12-2.module+el8dsrv+6428+6e54c518.x86_64
#

How reproducible:
Always

Steps to Reproduce:
1. Create an instance with a name that starts with "slapd-"
Use dscreate since the Console seems to fail to create such instance.

# ls -l /etc/dirsrv/ | grep "slapd-slapd"
drwxrwx---. 3 dirsrv dirsrv 4096 Jun 18 16:19 slapd-slapd-issue
drwxrwx---. 3 dirsrv dirsrv 4096 Jun 18 15:55 slapd-slapd_test
#

2. Run a dsctl command:
# dsctl -v slapd-issue status
DEBUG: The 389 Directory Server Administration Tool
DEBUG: Inspired by works of: ITS, The University of Adelaide
DEBUG: Called with: Namespace(func=<function instance_status at 0x7fd5d22df510>, instance='slapd-issue', json=False, list=False, remove_all=False, verbose=True)
DEBUG: list instance not found in /etc/dirsrv/slapd-issue/dse.ldif: issue

ERROR: No such instance 'slapd-issue'
ERROR: Unable to access instance information. Are you running as the correct user? (usually dirsrv or root)
#

3. Using the full instance identifier ( slapd-<INSTANCE_NAME> ) works:
# dsctl  slapd-slapd-issue status
Instance "slapd-issue" is running
#


Actual results:
* dsctl commands fail
* the RHDS Console fails to load the instance

Expected results:
dsctl should handle the case where there are multiple "slapd-" occurrences in the server identifier.

Additional info:

While users might quickly spot out the issue with the debug message ( dsctl -v ) and use the full identifier,
the Console failure to load such instances might be more elusive.
Excerpt of the Console log:
=================================================
CMD: loadInstanceList: Load the instance list select ==> dsctl -l -j    tools.jsx:58
CMD: setServerId: Test if instance is running  ==> dsctl -j slapd-issue status

Uncaught SyntaxError: Unexpected end of JSON input
    at JSON.parse (<anonymous>)
    at Function.<anonymous> (ds.jsx:208)
    at s (cockpit.js:979)
    at cockpit.js:991
    at n (cockpit.js:897)
=================================================

Comment 1 Têko Mihinto 2020-06-18 20:25:54 UTC
Sorry, just found this is similar to bug https://bugzilla.redhat.com/show_bug.cgi?id=1779216

Feel free to close as a duplicate and re-open 1779216 ( which was supposed to be already fixed in 1.4.2.4-7 )

Regards,
Têko.

Comment 2 mreynolds 2020-06-18 21:11:40 UTC
This was just fixed upstream via https://bugzilla.redhat.com/show_bug.cgi?id=1806573 for 8.3.  IF you want this backported to RHEL 8.2 please add GSSAproved to the other bug.  I also fixed the dsctl error handling via https://bugzilla.redhat.com/show_bug.cgi?id=1751224

I will close this as duplicate....

*** This bug has been marked as a duplicate of bug 1806573 ***