Re: New DS CLI design

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Viktor, hi William,

I recently played with the dscreate command and wanted to share my thoughts, impressions, and improvement suggestions:

I really like the tool and the way it works. It's simple to use and easy to understand. Also from the docs perspective: It's much easier to document than an interactive installer. The whole installation documentation should be easier to understand. We show the minimal (required) config file and list all optional parameters with a detailed description. Even for beginners, this should be easy to use.

However, there are a few things I think which should be improved:


On 24.05.2018 09:57, Viktor Ashirov wrote:
I also would really love to get back interactive installer. Installation
from the template is nice, but it has its own issues.
For example, dscreate provides only 2 actions: show an example INI file
and load INF file. Are these two files different? Anyway, let's try to
run
$ dscreate example
...
Here's the wall of text
...

This should be more helpful and at least provide a hint, that this
output should be redirected to a file, since later it will be loaded by
'fromfile' subcommand.

I also didn't understand the "example" subcommand at the beginning and that I have to redirect the output to a file. And I don't like the name of the "fromfile" option.

How about changing these keywords into -- options and renaming them:

# dscreate --help
--create-template (-c) file_name    Creates an example .inf template
                                    file with all parameters you
                                    can use.
--create-instance (-f) file_name    Sets up a new instance based
                                    on the parameters specified in
                                    the provided .inf file.

As you see, I would change the unclear "example" + redirect procedure into an option which automatically write the output into the file.

By the way, the generated template file should have 600 permissions. Users might edit this file and use it and it can contain the password in clear text.



Anyway, let's look at the file. It's very nice documented! Look at all
the options! Some of them are uncommented, that must be required
parameters. But ports are commented, are they not required? Maybe
something else I should change?

I was also unsure about this. How about commenting out all parameters and dscreate will complain if a mandatory parameter is missing.

Additionally, I would change the descriptions and highlight which parameters are mandatory. For example:

[slapd]
# instance_name (string) [REQUIRED]: Sets the name of the instance.
# Note that you cannot change the name of an instance after the
# installation. Default: localhost
; instance_name = localhost

# root_password (string) [REQUIRED]: Sets the password for the account
# specified in the root_dn parameter. You can either set the password
# in clear text or a hash generated by the pwdhash utility using your
# preferred password storage scheme. If this parameter is not set,
# the dscreate command prompts for the password.
; root_password = directory_manager_password

# port (integer) [optional]: Sets the TCP port for LDAP connections.
# Default: 389
; port = 389
...

By the way, I plan to create an appendix in the Installation Guide which explains these parameters. If you want, we can use these descriptions in the generated template and man page.



> And the DM's password is in a plain text. Can I pass hashed value
> here? Can I be asked for the password so that it won't be sitting
> in the template on a filesystem for ages until> someone discovers this template?

Good argument. I would suggest that if the root_password parameter is not set, dscreate prompts for the password. Of course, this should be made clear in the description in the template (see above).

Regarding encrypted password I suggest that the user could either set the password in clear text or provide the output of "pwdhash". For example:
root_password: {PBKDF2_SHA256}AAAgAKj74/94qAfBREHNfq98z....




Let's change port at least to something else and run dscreate.
# dscreate fromfile localhost.ini
READY: Preparing installation for localhost
READY: Beginning installation for localhost
Job for dirsrv@localhost.service failed because the control process exited with error code.
See "systemctl status dirsrv@localhost.service" and "journalctl -xe" for details.
Error: Command '['/usr/bin/systemctl', 'start', 'dirsrv@localhost']' returned non-zero exit status 1.
FAIL: Command failed. See output for details.

I also discovered this SELinux problem when I added a second instance. :-)

My suggestions:
1) Automatically run the SELinux command to allow this port.
2) Alternatively, if SELinux is enabled, print the command to enable it manually and do not try to start the service. I would do this even in permissive mode, because one day the admin switches to enforcing and then the service fails to start.





Now, I think it would be nice to have something like this in addition to
the unattended install, instead of having unattended mode as the only
way to create an instance.

DS> instance create --name=master1 --fqdn=server.example.com --port=1389 --secure-port=1636 --suffix=dc=example,dc=com --password=
or
# ds instance create --name=master1 --fqdn=server.example.com --port=1389 --secure-port=1636 --suffix=dc=example,dc=com
Enter Directory Manager's password:
...

How about allowing to use all of the inf file parameters as -- options. For example:

# dscreate --root_dn="cn=Directory Manager" --root_password="Secr3t" --instance_name=example ...




By the way, why are there different sections in the inf file (general and slapd)?


Regards,
Marc





--
Marc Muehlfeld
Senior Technical Writer, Customer Content Services

Red Hat GmbH
Technopark II,
Werner-von-Siemens-Ring 14
85630 Grasbrunn
Germany

Email: mmuehlfeld@xxxxxxxxxx
_______________________________________________________________________________
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham,
Michael O'Neill, Eric Shander
_______________________________________________
389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-devel@xxxxxxxxxxxxxxxxxxxxxxx/message/3C322KLYOO7E22LJOI27QYKV4S4LVQJF/




[Index of Archives]     [Fedora Directory Announce]     [Fedora Users]     [Older Fedora Users Mail]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Devel Java]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Review]     [Fedora Art]     [Fedora Music]     [Fedora Packaging]     [CentOS]     [Fedora SELinux]     [Big List of Linux Books]     [KDE Users]     [Fedora Art]     [Fedora Docs]

  Powered by Linux