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/
