On 08/21/2016 05:28 PM, William Brown wrote:
On Fri, 2016-08-19 at 11:21 +0200, Ludwig Krispenz wrote:
Hi William,
On 08/19/2016 02:22 AM, William Brown wrote:
On Wed, 2016-08-17 at 14:53 +1000, William Brown wrote:
https://fedorahosted.org/389/ticket/48951
https://fedorahosted.org/389/attachment/ticket/48951/0001-Ticket-48951-dsadm-and-dsconf-base-files.patch
https://fedorahosted.org/389/attachment/ticket/48951/0002-Ticket-48951-dsadm-and-dsconf-refactor-installer-cod.patch
https://fedorahosted.org/389/attachment/ticket/48951/0003-Ticket-48951-dsadm-and-dsconf-Installer-options-mana.patch
https://fedorahosted.org/389/attachment/ticket/48951/0004-Ticket-48951-dsadm-and-dsconf-Ability-to-unit-test-t.patch
https://fedorahosted.org/389/attachment/ticket/48951/0005-Ticket-48951-dsadm-and-dsconf-Backend-management-and.patch
As a follow up, here is a design / example document
http://www.port389.org/docs/389ds/design/dsadm-dsconf.html
thanks for this work, it is looking great and is something we were
really missing.
But of course I have some comments (and I know I am late).
- The naming dsadm and dsconf, and the split of tasks between them, is
the same as in Sun/Oracle DSEE, and even if there is probably no legal
restriction to use them; I'd prefer to have own names for our own tools.
Fair enough. There is nothing saying these names are stuck in stone
right now so if we have better ideas we can change it.
I will however say that any command name, should not start with numbers
(ie 389), and that it should generally be fast to type, easy to remember
and less than 8 chars long if possible.
What about "adm389" and "conf389"?
- I'm not convinced of splitting the tasks into two utilities, you will
have different actions and options for the different
resources/subcommands anyway, so you could have one for all.
The issue is around connection to the server, and whether it needs to be
made or not. The command in the code is:
dsadm:
command:
action
dsconf:
connect to DS
command
action
So dsconf takes advantage of all the commands being remote, so it shares
common connection code. If we were to make the tools "one" we would need
to make a decorator or something to repeat this, and there are some
other issues there with the way that the argparse library works.
I think this is an arbitrary distinction - needing a connection or not -
but other projects use similar "admin client" vs. "more general use
client" e.g. OpenShift has "oadm" vs. "oc". If this is a pattern that
admins are used to, we just need to be consistent in applying that pattern.
Also, I think, the goal should be to make all actions available local
and remote, the start/stop/install should be possible remotely via rsh
or another mechanism as long as the utilities are available on the
target machine, so I propose one dsmanage or 389manage
dsmanage is an okay name but, remote start stop is not an easy task.
At that point, you are looking at needing to ssh, manage the acceptance
of keys, you have to know the remote server ds prefix, you need to ssh
as root (bad) or manage sudo (annoying).
We already have the ability to remote stop/start/restart the server,
with admin server at least.
You need to potentially manage
selinux, systemd etc. It gets really complicated, really fast, and at
that point I'm going to turn around and say "no, just use ansible if you
want to remote manage things".
Lets keep these tools simple as we can, and let things like ansible
which is designed for remote tasks, do their job.
Right, but it will take a lot of work to determine what should be done
in ansible vs. specialized tool.
A better strategy is that we can potentially write a lib389 ansible
module in the future allowing us to playbook tasks for DS.....
I would like to see ansible playbooks for 389. Ansible is python, so we
can leverage python-ldap/lib389 instead of having to fork/exec
ldapsearch/ldapmodify.
This is why I kept them separate, because I wanted to have simple,
isolated domains in the commands for actions, that let us know clearly
what we are doing. It's still an open discussion though.
If this is a common patterns that admins are used to, then we should
consider it.
- could this be made interactive ? run the command, providing some or
none options and then have a shell like env
dsmanage
>>> help
...... connect
...... create-xxxxx
>>> connect -h ....
....... replica-enable ....
In the current form, no. However, the way I have written it, we should
be able to pretty easily replace the command line framework on front and
drop in something that does allow interactive commands like this. I was
thinking:
https://github.com/Datera/configshell
This is already in EL, as it's part of the targetcli application.
Think MVC - just make sure you can change the View. I tried to do this
with setup-ds.pl - make it possible to "plug in" a different "UI".
I would rather not have the
list
Error: no connection
connect ldap://localhost
password:
list
.....
Because now there are two states to every command, one connected, one
not. Much, much easier for us to develop and reason about if we make
connection part of the shell startup, so every command just "knows" it's
connected, and errors from that point really are errors.
We have this problem today - admins don't know if they are supposed to
use db2ldif, or db2ldif.pl - I think it would be better to have a single
command that tried to "do the right thing" e.g. try to connect and use
online methods, fallback to offline. Online would try to use the
highest grade security possible (local host would use unix domain
socket, remote would use client cert -> kerberos -> TLS -> plain) - or
something like that. There should be command line options to force
(e.g. --no-fallback).
--
389-devel mailing list
389-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org
--
389-devel mailing list
389-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org
