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@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.
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
_______________________________________________
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/OCJZBJ45OZA3ZXBF4WNO4N4H2PSH5YYO/
