On Thu, 2018-05-24 at 11:11 +0200, Marc Muehlfeld wrote:
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.
The whole design is actually
inf -> 3 dicts -> installer.
So the "interactive" was *always* a goal, and the whole design exists
to facitilate it. All you have to do is ask the questions, populate the
dicts then boom, you have a DS!
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.
hyphenated options are really hard to type and should be avoided, but I
like the name "template".
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.
Good point!
> 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.
The commented ones are "defaults that you don't need to touch".
The "uncommented" ones are "required" fields.
I actually planned to remove the commented out values (or a subset)
like being able to change the install paths, because it just breaks too
much (selinux policy for example).
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.
Can we open an issue about this?
> 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....
You can pass it hashes, that design is already supported.
> 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(a)localhost.service failed because the control process
> exited with error code.
> See "systemctl status dirsrv(a)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.
This is a good suggestion, and possible.
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.
But we don't know WHAT the failure really was. Maybe it wasn't selinux.
Maybe it was something else. We have to just let the admin investigate
here sadly. I don't think that's on us. We can enable the ports
automatically, but automatically trying to "solve" the issue is too
hard.
> 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 ...
If these could be auto-generated, yes. If not, too much work to keep
these "in sync".
By the way, why are there different sections in the inf file
(general
and slapd)?
They control different parts of the configuration process and have
different validation controls applied. It roughly translates to the
dictionary concepts beneath it.
Regards,
Marc
--
--
Sincerely,
William