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 1654116 - dsctl related issues
Summary: dsctl related issues
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: 389-ds-base
Version: 8.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 8.0
Assignee: mreynolds
QA Contact: RHDS QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-11-28 04:51 UTC by Akshay Adhikari
Modified: 2019-11-23 22:38 UTC (History)
9 users (show)

Fixed In Version: 389-ds-base-1.4.0.20-1.module+el8+2553+e9a4c637
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-06-14 01:31:33 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Akshay Adhikari 2018-11-28 04:51:04 UTC 
Description of problem:
No option to remove the instance with the leftover directory. (eg:
slapd-{instance_name}.removed)

Version-Release number of selected component (if applicable):

389-ds-base-1.4.0.19-2.module+el8+1+36e60e1d.x86_64

How reproducible:

Every time

Steps to Reproduce:
1. dsctl <instance_name> remove --doit OR dsctl --remove-all

Actual results:
1. dsctl  --remove-all
Are you sure you want to remove all the Directory Server instances? (Yes/no): Yes
Removing instance: slapd-DS
Removed /etc/systemd/system/multi-user.target.wants/dirsrv.
All instances have been successfully removed
[root@dell-r730-001-guest18 ~]# ll /etc/dirsrv/
config/           schema/           slapd-DS.removed/ ssca/ 

2. [root@dell-r730-001-guest18 ~]# dsctl DS remove --do-it

About to remove instance (DS)!
If this is not what you want, press ctrl-c now ...
        
5 ...
4 ...
3 ...
2 ...
1 ...
Removing instance ...
Removed /etc/systemd/system/multi-user.target.wants/dirsrv.
Completed instance removal
[root@dell-r730-001-guest18 ~]# ll /etc/dirsrv/
config/           schema/           slapd-DS.removed/ ssca/             
     

Expected results:
There should be an option to remove the instance with slapd-{instance_name}.removed directory

Additional info:
Comment 1 Anuj Borah 2018-11-28 06:02:13 UTC 
Description of problem:
Instances are not getting removed . (eg: dsctl -v --remove-all)

Version-Release number of selected component (if applicable):

389-ds-base-1.4.0.19-2.module+el8+1+36e60e1d.x86_64

How reproducible:

Happens sometimes .

Steps to Reproduce:
1. dsctl --remove-all

Actual results:
[root@server-rhel8 ds]# dsctl -v --remove-all
DEBUG: The 389 Directory Server Administration Tool
DEBUG: Inspired by works of: ITS, The University of Adelaide
DEBUG: Called with: Namespace(instance=False, json=False, list=False, remove_all=None, verbose=True)
Are you sure you want to remove all the Directory Server instances? (Yes/no): yes
Aborted removal of all instances

Expected results:
1. dsctl  --remove-all
Are you sure you want to remove all the Directory Server instances? (Yes/no): Yes
Removing instance: slapd-DS
Removed /etc/systemd/system/multi-user.target.wants/dirsrv.
Comment 2 Marc Sauton 2018-11-28 18:46:18 UTC 
eventual option for the impatient who does not want to have to wait, of course as we have a count down....... :
dsctl remove --do-it-now
Comment 3 Marc Sauton 2018-11-28 19:05:00 UTC 
dsctl start
dsctl restart

the errors log starts with either
[28/Nov/2018:13:55:50.467417812 -0500] - INFO - slapd_extract_cert - CA CERT NAME: Self-Signed-CA
or
[28/Nov/2018:13:55:50.493081062 -0500] - INFO - main - 389-Directory/1.4.0.191 B2018.331.227 starting up

is it possible to always have the "info main starting up" line always *first* as a very clear start of activity in the log?
Comment 4 Marc Sauton 2018-11-28 20:16:54 UTC 
bz 1654438 - dsctl db2index creates NO backup files
https://bugzilla.redhat.com/1654438
Comment 5 mreynolds 2018-11-28 20:37:49 UTC 
(In reply to Anuj Borah from comment #1)
> Description of problem:
> Instances are not getting removed . (eg: dsctl -v --remove-all)
> 
> Version-Release number of selected component (if applicable):
> 
> 389-ds-base-1.4.0.19-2.module+el8+1+36e60e1d.x86_64
> 
> How reproducible:
> 
> Happens sometimes .
> 
> Steps to Reproduce:
> 1. dsctl --remove-all
> 
> Actual results:
> [root@server-rhel8 ds]# dsctl -v --remove-all
> DEBUG: The 389 Directory Server Administration Tool
> DEBUG: Inspired by works of: ITS, The University of Adelaide
> DEBUG: Called with: Namespace(instance=False, json=False, list=False,
> remove_all=None, verbose=True)
> Are you sure you want to remove all the Directory Server instances?
> (Yes/no): yes
> Aborted removal of all instances
> 
> Expected results:
> 1. dsctl  --remove-all
> Are you sure you want to remove all the Directory Server instances?
> (Yes/no): Yes
> Removing instance: slapd-DS
> Removed /etc/systemd/system/multi-user.target.wants/dirsrv.


You are supposed to type "Yes", not "yes".  And yes that is on purpose to use the uppercase letter.  I suppose this can be confusing, I will make it clearer what you have to type in the confirmation message.
Comment 6 mreynolds 2018-11-28 20:40:52 UTC 
(In reply to Marc Sauton from comment #3)
> dsctl start
> dsctl restart
> 
> the errors log starts with either
> [28/Nov/2018:13:55:50.467417812 -0500] - INFO - slapd_extract_cert - CA CERT
> NAME: Self-Signed-CA
> or
> [28/Nov/2018:13:55:50.493081062 -0500] - INFO - main -
> 389-Directory/1.4.0.191 B2018.331.227 starting up
> 
> is it possible to always have the "info main starting up" line always
> *first* as a very clear start of activity in the log?

Maybe it could be changed.  That's all in the core server though and has nothing to do with the CLI tools.  If you really want the server startup logging order changed then file a new bug.
Comment 8 Akshay Adhikari 2018-12-20 07:53:48 UTC 
Build tested: 389-ds-base-1.4.0.20-1.module+el8+2+e85010b4.x86_64

[root@server-rhel8 dirsrv]# dsctl --remove-all 
Are you sure you want to remove all the Directory Server instances?  Enter "Yes" to continue: Yes
Removing instance: slapd-test
Removed /etc/systemd/system/multi-user.target.wants/dirsrv.
All instances have been successfully removed

Clear confirmation message.
Note You need to log in before you can comment on or make changes to this bug.