[
https://issues.apache.org/jira/browse/MESOS-1966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14179806#comment-14179806
]
Till Toenshoff commented on MESOS-1966:
---------------------------------------
There are some implications on variant 3 that I think are not perfectly cleared
out yet. Right now, the user has to supply the full path to the module library
(or it has to be part of ldconfig's search path). Did we already decide where
modules are being installed? We would need to make sure that modules are
installed into the standard ldconfig-reachable path for option 3 to work out of
the box, no?
> Integrate the Authenticator module
> ----------------------------------
>
> Key: MESOS-1966
> URL: https://issues.apache.org/jira/browse/MESOS-1966
> Project: Mesos
> Issue Type: Improvement
> Components: modules
> Reporter: Till Toenshoff
> Assignee: Till Toenshoff
>
> There are some options we quickly need to decide upon:
> 1. Keep the currently existing authenticator {{sasl/authenticator.hpp}}
> within {{libmesos}} as a default implementation. Add the {{--authenticators}}
> flag to the master and if the user selects {{crammd5}}, use the linked in,
> default implementation. If the user selects a different name e.g.
> {{org_apache_mesos_authenticator_pam}}, the master will try to load a module
> with that name and use its implementation. This is somewhat similar to what
> Kapil has done with the Isolator module integration.
> 2. Make the currently existing authenticator become a module and thereby
> remove it from libmesos. Add the {{--authenticators}} flag to the master and
> ask the user to supply a module as well ( {{--modules}} ).
> 3. Mixture of 1. and 2. Difference to 2. would be that we load the
> authenticator module implicitly (without the user supplying the {{--modules}}
> flag) as soon as he has enabled any kind of authentication (
> {{--authenticate_slaves}} / {{--authenticate_frameworks}} ).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
