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:


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@DS.service.
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@DS.service.
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@DS.service.

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@DS.service.


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@test.service.
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.