[
https://issues.apache.org/jira/browse/MESOS-1966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Till Toenshoff updated MESOS-1966:
----------------------------------
Description:
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}} ).
was:
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 implemenation. 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).
> 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)
