Martin Kosek wrote:
On 06/20/2013 09:29 AM, Petr Spacek wrote:
On 19.6.2013 20:56, Alexander Bokovoy wrote:
On Wed, 19 Jun 2013, Rob Crittenden wrote:
Tomas Babej wrote:
[big snip]
Providing new version which should address mentioned issues:
- advice plugins now inherit directly from Plugin, initial approach
via Method class was abandoned
- new Namespace api.Advice collects all the advice plugins
- tool renamed to ipa-advise to express a more general use case
Additional improvements:
- keywords are now generated out of Advice class's name, where
underscores are replaced by hyphens
- rewritten the example plugin in the docs, and provided more
information there
- instead of --setup option to provide configuration, ipa-advise
takes one positional argument
- renamed to ipa-advise
Concerns:
- man page might need more improvements
I'll craft a design page for plugin authors, might be useful, even if
the info is in the package docs.
-----------------------------------------------
Here's a little preview:
[tbabej@vm-001 ~]$ sudo ipa-advise fedora-authconfig
------------------------------------------------------------------------------------------------
Authconfig instructions for configuring Fedora 18/19 client with IPA
server without use of SSSD.
------------------------------------------------------------------------------------------------
/sbin/authconfig --enableldap --ldapserver=vm-001.idm.com
--enablerfc2307bis --enablekrb5
[tbabej@vm-001 ~]$ sudo ipa-advise fedora-authconfig4
invalid 'setup': No instructions are available for 'fedora_authconfig4'.
See the list of available configuration advices using the --list option.
[tbabej@vm-001 ~]$ sudo ipa-advise
-------------------------
List of available advices
-------------------------
fedora-authconfig : Authconfig instructions for configuring Fedora
18/19 client with IPA server without use of SSSD.
If it's just providing advise why does it need root access? Or is it
expected to provide advise based on current configuration?
Exactly. Getting ranges, configured trusts, etc. Not all of that
information may be available under non-privileged account, especially if
somebody would decide to plug in advices for backup or CA
handling/configuration of advanced features.
I think that ipa-advise should not require root access *implicitly*. It would
prevent lower-level admins from ipa-advise tool.
IMHO plugins should try to get required information and print an 'Insufficient
access rights, try it again as root/admin' error when appropriate.
As a result, basic 'advices' (like recommended client configuration) will be
accessible anybody and special 'advices' (something related to AD trusts etc.)
will be accessible only to admins.
+1
I think the reason why Tomas did it as root was that he can that autobind to
the DS. But he could easily operate in 2 modes, similarly to ipa-ldap-updater
and simply just auth wuth GSSAPI when he is not logged as a root.
Alternatively, add a requires_root on the plugin level so that some
plugins require root, others do not.
rob
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
