|
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.patchAs a follow up, here is a design / example document http://www.port389.org/docs/389ds/design/dsadm-dsconf.htmlthanks 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 389managedsmanage 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 thelistError: no connectionconnect ldap://localhostpassword: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@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/389-devel@xxxxxxxxxxxxxxxxxxxxxxx
