On 08/21/2016 07:56 PM, William Brown wrote:
On Sun, 2016-08-21 at 19:44 -0600, Rich Megginson wrote:
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"?
Yeah, those could work.
- 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.
Not with systemd we don't. systemd + selinux has broken that for a stack
of our products, and at the moment, we are publishing release notes that
these don't work in certain cases. And rightly so, ds should not have
the rights to touch system services in the way we were doing, it's a
huge security risk.
To make it work we need to do dbus and polkit magic, and the amount of
motivation I have to give about this problem is low, especially when
tools like ansible do it for us, much better.
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.
Not really. An admin will know "okay, if I want to start stop services I
write action: service state=enabled dirsrv@instance". They will also
know "well I want to reconfigure plugins on DS, I use conf389/dsconf".
Anything that is yum, systemd command, etc. is ansible. Anything about
installing an instance or 389 specific we do.
I think that is an arbitrary line of demarcation. ansible can be used
for a lot more than that.
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.
Yep, this is a future goal of this work ....
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.
I think you already summarised it above with the openshift discussion,
of oadm vs oc.
At the same time, there is also "all in one tools".
Being a past sysadmin myself, I prefer the former.
- 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".
Yep, this is how it's designed. It still needs more polish, but this is
the way I designed it.
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).
Yeah, I agree. In the db2ldif case, I would say, you call adm389/dsadm
db2ldif, it checks if the server is running or not. If running, add the
task. If not, call ns-slapd with the right options.
Saying this, in a way I'm not a fan of this also. Because we are doing
behind the scenes magic, rather than simple, implicit tasks. What
happens if someone crons this? What happens? We lose the intent of the
admin in some cases.
I think the principle should be "make it simple to do the easy things -
make it possible to do the difficult things". In this case, if I am an
admin running a cli, I think it should "do the right thing". If I'm
setting up a cron job, I should be able to force it to use offline mode
or whatever - it is easy to keep track of extra cli arguments if I'm
automating something vs. running interactively on the command line.
So perhaps again, the dsadm/dsconf distinction is good here.
We can have dsadm always does the "offline" variant, and we can have a
similar command is dsconf that runs the online task.
I don't think that's the right distinction.
--
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
