You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@mesos.apache.org by Sivaram Kannan <si...@gmail.com> on 2015/03/05 18:06:15 UTC
Who is the user in Mesos Authorization ACL definition?
Hi,
The user that is defined as part of Mesos's Authorization ACL, which user
is it? Taking marathon framework as example, the users defined as part of
run_tasks principal, is it the user that is used to run marathon executable
or the unix user available in the mesos-slave's?
Documentation in http://mesos.apache.org/documentation/latest/authorization/
does not seems to be clear on that. Can someone clarify?
Thanks,
./Siva.
Re: Who is the user in Mesos Authorization ACL definition?
Posted by Vinod Kone <vi...@apache.org>.
I think you are confusing 'principals' with 'users'. Principal is an
identifier for the framework (think of it as username). User is the unix
user that a task will run as on the *slave*.
So, whatever users you want to run the tasks as, make sure that they exist
on the Mesos slave host (or docker container in which the slave runs).
You will get TASK_LOST (or TASK_ERROR since 0.22.0) if there are
authorization errors. TASK_FAILED has nothing do with authorization; it is
generated by the slave.
On Mon, Mar 9, 2015 at 4:36 AM, Sivaram Kannan <si...@gmail.com> wrote:
>
> Hi,
>
> I apologize for bombarding with so many emails on the same issue. So, I
> modified the acl.json as below.
>
> 1. I was able to launch the framework with authentication as users devel1
> and devel2.
> 2. I was able to launch a task as user devel1
> 3. I get TASK_LOST when I try to launch task with the framework registered
> as devel2.
> 4. In the same config, if I change the run_tasks => users to devel, the
> task fails with the error described in the previous email. As far as I
> understand, an error in run_tasks users, does not give TASK_LOST, but a
> TASK_FAILED. But a mismatch in principals between register_frameworks and
> run_tasks gives a TASK_LOST.
>
> Does the above makes sense? Please correct me if I am wrong.
>
>
> "permissive": false,
> "register_frameworks": [
> {
> "principals": { "values": [ "devel1", "devel2" ] },
> "roles": { "values": [ "apps", "dev-ops" ] }
> },
> {
> "principals": { "type": "NONE" },
> "roles": { "values": [ "apps", "dev-ops" ] }
> }
> ],
> "run_tasks": [
> {
> "principals": { "values": [ "devel1" ] },
> "users": { "values": [ "root" ] }
> },
> {
> "principals": { "values": [ "marathon" ] },
> "users": { "type": "NONE" } } ]
> }
>
> Thanks,
> ./Siva.
>
> On Mon, Mar 9, 2015 at 3:57 PM, Sivaram Kannan <si...@gmail.com>
> wrote:
>
>>
>> Hi Vinod,
>>
>> The users in below run_tasks definition - does it refer to unix users in
>> the machine where the framework is run or the unix users in the mesos-slave
>> machine. I think the fact that I run all softwares (mesos-master,
>> mesos-slave, marathon) as docker containers is of significance and reason
>> for the below failure.
>>
>> "run_tasks": [
>> {
>> "principals": {
>> "values": [
>> "marathon"
>> ]
>> },
>> "users": {
>> "values": [
>> "devel"
>> ]
>> }
>> },
>> {
>> "principals": {
>> "values": [
>> "marathon"
>> ]
>> },
>> "users": {
>> "type": "NONE"
>> }
>> }
>> ]
>>
>> When I start the marathon, I start with the flag --mesos_user=devel and
>> while bringing up mesos-slave I bring up with the flag
>> --switch_user=true(which I think anyway is default). When I try to launch a
>> task this is what I am getting
>>
>> Marathon Log:
>>
>> 0.10; rv:38.0) Gecko/20100101 Firefox/38.0"
>> (mesosphere.chaos.http.ChaosRequestLog:15)
>> [2015-03-06 06:04:04,057] INFO Received status update for task
>> busybox.9777a963-c3c6-11e4-a31a-56847afe9799: TASK_FAILED (Abnormal
>> executor termination) (mesosphere.marathon.MarathonScheduler:165)
>> [2015-03-06 06:04:04,063] INFO Task launch delay for [/busybox] is now
>> [43] seconds (mesosphere.util.RateLimiter:34)
>> [2015-03-06 06:04:04,068] INFO Task
>> busybox.9777a963-c3c6-11e4-a31a-56847afe9799 expunged and removed from
>> TaskTracker (mesosphere.marathon.tasks.TaskTracker:101)
>> [2015-03-06 06:04:04,068] INFO Sending event notification.
>> (mesosphere.marathon.MarathonScheduler:274)
>>
>> Mesos-Slave Log:
>>
>> Mar 06 06:06:03 node-0800279564ad sh[27684]: E0306 06:06:03.898473 13
>> slave.cpp:2787] Container '9835da8c-a844-4d53-a7f7-4a5e6e808a9b' for
>> executor 'busybox.d4ef22c6-c3c6-11e4-a31a-56847afe9799' of framework
>> '20150306-054714-24707342-5050-1-0000' failed to start: Failed to create
>> container: Failed to chown: Failed to get user information for 'devel':
>> Success
>> Mar 06 06:06:03 node-0800279564ad sh[27684]: E0306 06:06:03.900068 13
>> slave.cpp:2882] Termination of executor
>> 'busybox.d4ef22c6-c3c6-11e4-a31a-56847afe9799' of framework
>> '20150306-054714-24707342-5050-1-0000' failed: Unknown container:
>> 9835da8c-a844-4d53-a7f7-4a5e6e808a9b
>> Mar 06 06:06:03 node-0800279564ad sh[27684]: E0306 06:06:03.905900 13
>> slave.cpp:3134] Failed to unmonitor container for executor
>> busybox.d4ef22c6-c3c6-11e4-a31a-56847afe9799 of framework
>> 20150306-054714-24707342-5050-1-0000: Not monitored
>>
>> Could the failure be related to me running the mesos-slave as container
>> here?
>>
>> Thanks,
>> ./Siva.
>>
>> On Mon, Mar 9, 2015 at 10:51 AM, Sivaram Kannan <si...@gmail.com>
>> wrote:
>>
>>>
>>> Hi Vinod,
>>>
>>> Thanks, I got it. I guess I did not understand the relationship between
>>> principals defined in authentication and in authorization. I re-read the
>>> authentication and credentials flag, it is not clear from them that the
>>> principals defined in authorization should match them to work correctly. If
>>> I could, will change the documentation to be more clear and submit a PR.
>>>
>>> Thanks,
>>> ./Siva.
>>>
>>> On Mon, Mar 9, 2015 at 2:18 AM, Vinod Kone <vi...@apache.org> wrote:
>>>
>>>> The principal used for authenticating the framework is the same
>>>> principal used to authorize the framework too. So you need to use
>>>> 'marathon' in your credentials too. In other words, when you start the
>>>> framework the Credential.principal should be the same as
>>>> FrameworkInfo.principal (Mesos master will validate this).
>>>>
>>>> On Sun, Mar 8, 2015 at 10:48 AM, Sivaram Kannan <si...@gmail.com>
>>>> wrote:
>>>>
>>>>> I0308 17:41:14.876610 6 master.cpp:1342] Authorizing framework
>>>>> principal 'user1' to receive offers for role 'apps'
>>>>>
>>>>
>>>> As you can see from this line, the master is trying to authorize
>>>> principal 'user1' and not 'marathon'.
>>>>
>>>
>>>
>>>
>>> --
>>> ever tried. ever failed. no matter.
>>> try again. fail again. fail better.
>>> -- Samuel Beckett
>>>
>>
>>
>>
>> --
>> ever tried. ever failed. no matter.
>> try again. fail again. fail better.
>> -- Samuel Beckett
>>
>
>
>
> --
> ever tried. ever failed. no matter.
> try again. fail again. fail better.
> -- Samuel Beckett
>
Re: Who is the user in Mesos Authorization ACL definition?
Posted by Sivaram Kannan <si...@gmail.com>.
Thanks a lot for the patient explanation both of you - Vinod and Mark. You
are right, I got confused with the terminology. I got what I wanted out of
ACL in my environment.
Thanks again and I really appreciate it.
./Siva.
On Tue, Mar 10, 2015 at 4:30 AM, Michael Park <mc...@gmail.com> wrote:
> On 9 March 2015 at 07:36, Sivaram Kannan <si...@gmail.com> wrote:
>
>>
>> Hi,
>>
>> I apologize for bombarding with so many emails on the same issue. So, I
>> modified the acl.json as below.
>>
>> 1. I was able to launch the framework with authentication as users devel1
>> and devel2.
>>
>
> Just so that our terminologies match here, you were able to *register*
> frameworks *authenticated* as *principals* *devel1* and *devel2.*
>
> Your ACL specifies *devel1* and *devel2* can register under *apps* and
> *dev-ops* roles, so as long as the frameworks registered under those
> roles, the success here makes sense.
>
>
>> 2. I was able to launch a task as user devel1
>>
>
> I agree with Vinod that maybe the point of confusion is regarding *principal
> *vs *user* for *run_tasks*. To reiterate, *principal* is essentially a
> username for Mesos to authenticate the framework, and *user* is the unix
> user under which the task will run. Your ACL specifies that *principal*
> *devel1* can launch tasks as *user* *root*. So you shouldn't be able to
> launch a task as user *devel1*, but rather launch a task as user* root* with
> the framework registered as principal=*devel1*. If this is not the case,
> something's wrong.
>
>
>> 3. I get TASK_LOST when I try to launch task with the framework
>> registered as devel2.
>>
>
> This is correct. Vinod already covered this point. In short, framework
> registered as *devel2* is not permitted to run anything based on your ACL
> since none of the specified cases match and "permissive" is set to false.
>
>
>> 4. In the same config, if I change the run_tasks => users to devel, the
>> task fails with the error described in the previous email. As far as I
>> understand, an error in run_tasks users, does not give TASK_LOST, but a
>> TASK_FAILED.
>>
>
> I'm not sure what you mean by "an error in run_tasks users". The error you
> get in this case is because you don't have a *devel* user available in
> the environment you're launching the task. The relevant line in the error
> message that illustrate this is:
>
> Mar 06 06:06:03 node-0800279564ad sh[27684]: E0306 06:06:03.898473 13
>> slave.cpp:2787] Container '9835da8c-a844-4d53-a7f7-4a5e6e808a9b' for
>> executor 'busybox.d4ef22c6-c3c6-11e4-a31a-56847afe9799' of framework
>> '20150306-054714-24707342-5050-1-0000' failed to start: Failed to create
>> container: Failed to chown: *Failed to get user information for 'devel'*:
>> Success
>
>
> This is indeed a *TASK_FAILED*, since authorization succeeded, but the
> task failed to launch.
>
>
>> But a mismatch in principals between register_frameworks and run_tasks
>> gives a TASK_LOST.
>>
>
> It's not clear exactly what you mean by "a *mismatch* in principals
> between register_frameworks and run_tasks". If you mean that all principals
> under register_frameworks should have a matching portion in run_tasks,
> that's not quite correct. For example, you modified the ACL to be:
>
> {
>> "permissive": false,
>> "register_frameworks": [
>> {
>> "principals": { "values": [ "devel1", "devel2" ] },
>> "roles": { "values": [ "apps", "dev-ops" ] }
>> },
>> {
>> "principals": { "type": "NONE" },
>> "roles": { "values": [ "apps", "dev-ops" ] }
>> }
>> ],
>> "run_tasks": [
>> {
>> "principals": { "values": [ "devel1", *"devel2"* ] },
>> "users": { "values": [ "root" ] }
>> },
>
> {
>> "principals": { "values": [ "marathon" ] },
>> "users": { "type": "NONE" }
>> }
>> ]
>> }
>
>
> If we attempt to launch a task as user "mpark" with the framework
> registered as "devel2" (or "devel1"), we'll get continue to get the
> *TASK_LOST* message because it fails at the *authorization* phase.
>
>
>> Does the above makes sense? Please correct me if I am wrong.
>>
>
> I hope my explanation above made sense!
>
>
>>
>> "permissive": false,
>> "register_frameworks": [
>> {
>> "principals": { "values": [ "devel1", "devel2" ] },
>> "roles": { "values": [ "apps", "dev-ops" ] }
>> },
>> {
>> "principals": { "type": "NONE" },
>> "roles": { "values": [ "apps", "dev-ops" ] }
>> }
>> ],
>> "run_tasks": [
>> {
>> "principals": { "values": [ "devel1" ] },
>> "users": { "values": [ "root" ] }
>> },
>> {
>> "principals": { "values": [ "marathon" ] },
>> "users": { "type": "NONE" } } ]
>> }
>>
>> Thanks,
>> ./Siva.
>>
>
> Thanks,
>
> MPark.
>
>
>> On Mon, Mar 9, 2015 at 3:57 PM, Sivaram Kannan <si...@gmail.com>
>> wrote:
>>
>>>
>>> Hi Vinod,
>>>
>>> The users in below run_tasks definition - does it refer to unix users in
>>> the machine where the framework is run or the unix users in the mesos-slave
>>> machine. I think the fact that I run all softwares (mesos-master,
>>> mesos-slave, marathon) as docker containers is of significance and reason
>>> for the below failure.
>>>
>>> "run_tasks": [
>>> {
>>> "principals": {
>>> "values": [
>>> "marathon"
>>> ]
>>> },
>>> "users": {
>>> "values": [
>>> "devel"
>>> ]
>>> }
>>> },
>>> {
>>> "principals": {
>>> "values": [
>>> "marathon"
>>> ]
>>> },
>>> "users": {
>>> "type": "NONE"
>>> }
>>> }
>>> ]
>>>
>>> When I start the marathon, I start with the flag --mesos_user=devel and
>>> while bringing up mesos-slave I bring up with the flag
>>> --switch_user=true(which I think anyway is default). When I try to launch a
>>> task this is what I am getting
>>>
>>> Marathon Log:
>>>
>>> 0.10; rv:38.0) Gecko/20100101 Firefox/38.0"
>>> (mesosphere.chaos.http.ChaosRequestLog:15)
>>> [2015-03-06 06:04:04,057] INFO Received status update for task
>>> busybox.9777a963-c3c6-11e4-a31a-56847afe9799: TASK_FAILED (Abnormal
>>> executor termination) (mesosphere.marathon.MarathonScheduler:165)
>>> [2015-03-06 06:04:04,063] INFO Task launch delay for [/busybox] is now
>>> [43] seconds (mesosphere.util.RateLimiter:34)
>>> [2015-03-06 06:04:04,068] INFO Task
>>> busybox.9777a963-c3c6-11e4-a31a-56847afe9799 expunged and removed from
>>> TaskTracker (mesosphere.marathon.tasks.TaskTracker:101)
>>> [2015-03-06 06:04:04,068] INFO Sending event notification.
>>> (mesosphere.marathon.MarathonScheduler:274)
>>>
>>> Mesos-Slave Log:
>>>
>>> Mar 06 06:06:03 node-0800279564ad sh[27684]: E0306 06:06:03.898473 13
>>> slave.cpp:2787] Container '9835da8c-a844-4d53-a7f7-4a5e6e808a9b' for
>>> executor 'busybox.d4ef22c6-c3c6-11e4-a31a-56847afe9799' of framework
>>> '20150306-054714-24707342-5050-1-0000' failed to start: Failed to create
>>> container: Failed to chown: Failed to get user information for 'devel':
>>> Success
>>> Mar 06 06:06:03 node-0800279564ad sh[27684]: E0306 06:06:03.900068 13
>>> slave.cpp:2882] Termination of executor
>>> 'busybox.d4ef22c6-c3c6-11e4-a31a-56847afe9799' of framework
>>> '20150306-054714-24707342-5050-1-0000' failed: Unknown container:
>>> 9835da8c-a844-4d53-a7f7-4a5e6e808a9b
>>> Mar 06 06:06:03 node-0800279564ad sh[27684]: E0306 06:06:03.905900 13
>>> slave.cpp:3134] Failed to unmonitor container for executor
>>> busybox.d4ef22c6-c3c6-11e4-a31a-56847afe9799 of framework
>>> 20150306-054714-24707342-5050-1-0000: Not monitored
>>>
>>> Could the failure be related to me running the mesos-slave as container
>>> here?
>>>
>>> Thanks,
>>> ./Siva.
>>>
>>> On Mon, Mar 9, 2015 at 10:51 AM, Sivaram Kannan <si...@gmail.com>
>>> wrote:
>>>
>>>>
>>>> Hi Vinod,
>>>>
>>>> Thanks, I got it. I guess I did not understand the relationship between
>>>> principals defined in authentication and in authorization. I re-read the
>>>> authentication and credentials flag, it is not clear from them that the
>>>> principals defined in authorization should match them to work correctly. If
>>>> I could, will change the documentation to be more clear and submit a PR.
>>>>
>>>> Thanks,
>>>> ./Siva.
>>>>
>>>> On Mon, Mar 9, 2015 at 2:18 AM, Vinod Kone <vi...@apache.org>
>>>> wrote:
>>>>
>>>>> The principal used for authenticating the framework is the same
>>>>> principal used to authorize the framework too. So you need to use
>>>>> 'marathon' in your credentials too. In other words, when you start the
>>>>> framework the Credential.principal should be the same as
>>>>> FrameworkInfo.principal (Mesos master will validate this).
>>>>>
>>>>> On Sun, Mar 8, 2015 at 10:48 AM, Sivaram Kannan <si...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> I0308 17:41:14.876610 6 master.cpp:1342] Authorizing framework
>>>>>> principal 'user1' to receive offers for role 'apps'
>>>>>>
>>>>>
>>>>> As you can see from this line, the master is trying to authorize
>>>>> principal 'user1' and not 'marathon'.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> ever tried. ever failed. no matter.
>>>> try again. fail again. fail better.
>>>> -- Samuel Beckett
>>>>
>>>
>>>
>>>
>>> --
>>> ever tried. ever failed. no matter.
>>> try again. fail again. fail better.
>>> -- Samuel Beckett
>>>
>>
>>
>>
>> --
>> ever tried. ever failed. no matter.
>> try again. fail again. fail better.
>> -- Samuel Beckett
>>
>
>
--
ever tried. ever failed. no matter.
try again. fail again. fail better.
-- Samuel Beckett
Re: Who is the user in Mesos Authorization ACL definition?
Posted by Michael Park <mc...@gmail.com>.
On 9 March 2015 at 07:36, Sivaram Kannan <si...@gmail.com> wrote:
>
> Hi,
>
> I apologize for bombarding with so many emails on the same issue. So, I
> modified the acl.json as below.
>
> 1. I was able to launch the framework with authentication as users devel1
> and devel2.
>
Just so that our terminologies match here, you were able to *register*
frameworks *authenticated* as *principals* *devel1* and *devel2.*
Your ACL specifies *devel1* and *devel2* can register under *apps* and
*dev-ops* roles, so as long as the frameworks registered under those roles,
the success here makes sense.
> 2. I was able to launch a task as user devel1
>
I agree with Vinod that maybe the point of confusion is regarding *principal
*vs *user* for *run_tasks*. To reiterate, *principal* is essentially a
username for Mesos to authenticate the framework, and *user* is the unix
user under which the task will run. Your ACL specifies that *principal*
*devel1* can launch tasks as *user* *root*. So you shouldn't be able to
launch a task as user *devel1*, but rather launch a task as user* root* with
the framework registered as principal=*devel1*. If this is not the case,
something's wrong.
> 3. I get TASK_LOST when I try to launch task with the framework registered
> as devel2.
>
This is correct. Vinod already covered this point. In short, framework
registered as *devel2* is not permitted to run anything based on your ACL
since none of the specified cases match and "permissive" is set to false.
> 4. In the same config, if I change the run_tasks => users to devel, the
> task fails with the error described in the previous email. As far as I
> understand, an error in run_tasks users, does not give TASK_LOST, but a
> TASK_FAILED.
>
I'm not sure what you mean by "an error in run_tasks users". The error you
get in this case is because you don't have a *devel* user available in the
environment you're launching the task. The relevant line in the error
message that illustrate this is:
Mar 06 06:06:03 node-0800279564ad sh[27684]: E0306 06:06:03.898473 13
> slave.cpp:2787] Container '9835da8c-a844-4d53-a7f7-4a5e6e808a9b' for
> executor 'busybox.d4ef22c6-c3c6-11e4-a31a-56847afe9799' of framework
> '20150306-054714-24707342-5050-1-0000' failed to start: Failed to create
> container: Failed to chown: *Failed to get user information for 'devel'*:
> Success
This is indeed a *TASK_FAILED*, since authorization succeeded, but the task
failed to launch.
> But a mismatch in principals between register_frameworks and run_tasks
> gives a TASK_LOST.
>
It's not clear exactly what you mean by "a *mismatch* in principals between
register_frameworks and run_tasks". If you mean that all principals under
register_frameworks should have a matching portion in run_tasks, that's not
quite correct. For example, you modified the ACL to be:
{
> "permissive": false,
> "register_frameworks": [
> {
> "principals": { "values": [ "devel1", "devel2" ] },
> "roles": { "values": [ "apps", "dev-ops" ] }
> },
> {
> "principals": { "type": "NONE" },
> "roles": { "values": [ "apps", "dev-ops" ] }
> }
> ],
> "run_tasks": [
> {
> "principals": { "values": [ "devel1", *"devel2"* ] },
> "users": { "values": [ "root" ] }
> },
{
> "principals": { "values": [ "marathon" ] },
> "users": { "type": "NONE" }
> }
> ]
> }
If we attempt to launch a task as user "mpark" with the framework
registered as "devel2" (or "devel1"), we'll get continue to get the
*TASK_LOST* message because it fails at the *authorization* phase.
> Does the above makes sense? Please correct me if I am wrong.
>
I hope my explanation above made sense!
>
> "permissive": false,
> "register_frameworks": [
> {
> "principals": { "values": [ "devel1", "devel2" ] },
> "roles": { "values": [ "apps", "dev-ops" ] }
> },
> {
> "principals": { "type": "NONE" },
> "roles": { "values": [ "apps", "dev-ops" ] }
> }
> ],
> "run_tasks": [
> {
> "principals": { "values": [ "devel1" ] },
> "users": { "values": [ "root" ] }
> },
> {
> "principals": { "values": [ "marathon" ] },
> "users": { "type": "NONE" } } ]
> }
>
> Thanks,
> ./Siva.
>
Thanks,
MPark.
> On Mon, Mar 9, 2015 at 3:57 PM, Sivaram Kannan <si...@gmail.com>
> wrote:
>
>>
>> Hi Vinod,
>>
>> The users in below run_tasks definition - does it refer to unix users in
>> the machine where the framework is run or the unix users in the mesos-slave
>> machine. I think the fact that I run all softwares (mesos-master,
>> mesos-slave, marathon) as docker containers is of significance and reason
>> for the below failure.
>>
>> "run_tasks": [
>> {
>> "principals": {
>> "values": [
>> "marathon"
>> ]
>> },
>> "users": {
>> "values": [
>> "devel"
>> ]
>> }
>> },
>> {
>> "principals": {
>> "values": [
>> "marathon"
>> ]
>> },
>> "users": {
>> "type": "NONE"
>> }
>> }
>> ]
>>
>> When I start the marathon, I start with the flag --mesos_user=devel and
>> while bringing up mesos-slave I bring up with the flag
>> --switch_user=true(which I think anyway is default). When I try to launch a
>> task this is what I am getting
>>
>> Marathon Log:
>>
>> 0.10; rv:38.0) Gecko/20100101 Firefox/38.0"
>> (mesosphere.chaos.http.ChaosRequestLog:15)
>> [2015-03-06 06:04:04,057] INFO Received status update for task
>> busybox.9777a963-c3c6-11e4-a31a-56847afe9799: TASK_FAILED (Abnormal
>> executor termination) (mesosphere.marathon.MarathonScheduler:165)
>> [2015-03-06 06:04:04,063] INFO Task launch delay for [/busybox] is now
>> [43] seconds (mesosphere.util.RateLimiter:34)
>> [2015-03-06 06:04:04,068] INFO Task
>> busybox.9777a963-c3c6-11e4-a31a-56847afe9799 expunged and removed from
>> TaskTracker (mesosphere.marathon.tasks.TaskTracker:101)
>> [2015-03-06 06:04:04,068] INFO Sending event notification.
>> (mesosphere.marathon.MarathonScheduler:274)
>>
>> Mesos-Slave Log:
>>
>> Mar 06 06:06:03 node-0800279564ad sh[27684]: E0306 06:06:03.898473 13
>> slave.cpp:2787] Container '9835da8c-a844-4d53-a7f7-4a5e6e808a9b' for
>> executor 'busybox.d4ef22c6-c3c6-11e4-a31a-56847afe9799' of framework
>> '20150306-054714-24707342-5050-1-0000' failed to start: Failed to create
>> container: Failed to chown: Failed to get user information for 'devel':
>> Success
>> Mar 06 06:06:03 node-0800279564ad sh[27684]: E0306 06:06:03.900068 13
>> slave.cpp:2882] Termination of executor
>> 'busybox.d4ef22c6-c3c6-11e4-a31a-56847afe9799' of framework
>> '20150306-054714-24707342-5050-1-0000' failed: Unknown container:
>> 9835da8c-a844-4d53-a7f7-4a5e6e808a9b
>> Mar 06 06:06:03 node-0800279564ad sh[27684]: E0306 06:06:03.905900 13
>> slave.cpp:3134] Failed to unmonitor container for executor
>> busybox.d4ef22c6-c3c6-11e4-a31a-56847afe9799 of framework
>> 20150306-054714-24707342-5050-1-0000: Not monitored
>>
>> Could the failure be related to me running the mesos-slave as container
>> here?
>>
>> Thanks,
>> ./Siva.
>>
>> On Mon, Mar 9, 2015 at 10:51 AM, Sivaram Kannan <si...@gmail.com>
>> wrote:
>>
>>>
>>> Hi Vinod,
>>>
>>> Thanks, I got it. I guess I did not understand the relationship between
>>> principals defined in authentication and in authorization. I re-read the
>>> authentication and credentials flag, it is not clear from them that the
>>> principals defined in authorization should match them to work correctly. If
>>> I could, will change the documentation to be more clear and submit a PR.
>>>
>>> Thanks,
>>> ./Siva.
>>>
>>> On Mon, Mar 9, 2015 at 2:18 AM, Vinod Kone <vi...@apache.org> wrote:
>>>
>>>> The principal used for authenticating the framework is the same
>>>> principal used to authorize the framework too. So you need to use
>>>> 'marathon' in your credentials too. In other words, when you start the
>>>> framework the Credential.principal should be the same as
>>>> FrameworkInfo.principal (Mesos master will validate this).
>>>>
>>>> On Sun, Mar 8, 2015 at 10:48 AM, Sivaram Kannan <si...@gmail.com>
>>>> wrote:
>>>>
>>>>> I0308 17:41:14.876610 6 master.cpp:1342] Authorizing framework
>>>>> principal 'user1' to receive offers for role 'apps'
>>>>>
>>>>
>>>> As you can see from this line, the master is trying to authorize
>>>> principal 'user1' and not 'marathon'.
>>>>
>>>
>>>
>>>
>>> --
>>> ever tried. ever failed. no matter.
>>> try again. fail again. fail better.
>>> -- Samuel Beckett
>>>
>>
>>
>>
>> --
>> ever tried. ever failed. no matter.
>> try again. fail again. fail better.
>> -- Samuel Beckett
>>
>
>
>
> --
> ever tried. ever failed. no matter.
> try again. fail again. fail better.
> -- Samuel Beckett
>
Re: Who is the user in Mesos Authorization ACL definition?
Posted by Sivaram Kannan <si...@gmail.com>.
Hi,
I apologize for bombarding with so many emails on the same issue. So, I
modified the acl.json as below.
1. I was able to launch the framework with authentication as users devel1
and devel2.
2. I was able to launch a task as user devel1
3. I get TASK_LOST when I try to launch task with the framework registered
as devel2.
4. In the same config, if I change the run_tasks => users to devel, the
task fails with the error described in the previous email. As far as I
understand, an error in run_tasks users, does not give TASK_LOST, but a
TASK_FAILED. But a mismatch in principals between register_frameworks and
run_tasks gives a TASK_LOST.
Does the above makes sense? Please correct me if I am wrong.
"permissive": false,
"register_frameworks": [
{
"principals": { "values": [ "devel1", "devel2" ] },
"roles": { "values": [ "apps", "dev-ops" ] }
},
{
"principals": { "type": "NONE" },
"roles": { "values": [ "apps", "dev-ops" ] }
}
],
"run_tasks": [
{
"principals": { "values": [ "devel1" ] },
"users": { "values": [ "root" ] }
},
{
"principals": { "values": [ "marathon" ] },
"users": { "type": "NONE" } } ]
}
Thanks,
./Siva.
On Mon, Mar 9, 2015 at 3:57 PM, Sivaram Kannan <si...@gmail.com> wrote:
>
> Hi Vinod,
>
> The users in below run_tasks definition - does it refer to unix users in
> the machine where the framework is run or the unix users in the mesos-slave
> machine. I think the fact that I run all softwares (mesos-master,
> mesos-slave, marathon) as docker containers is of significance and reason
> for the below failure.
>
> "run_tasks": [
> {
> "principals": {
> "values": [
> "marathon"
> ]
> },
> "users": {
> "values": [
> "devel"
> ]
> }
> },
> {
> "principals": {
> "values": [
> "marathon"
> ]
> },
> "users": {
> "type": "NONE"
> }
> }
> ]
>
> When I start the marathon, I start with the flag --mesos_user=devel and
> while bringing up mesos-slave I bring up with the flag
> --switch_user=true(which I think anyway is default). When I try to launch a
> task this is what I am getting
>
> Marathon Log:
>
> 0.10; rv:38.0) Gecko/20100101 Firefox/38.0"
> (mesosphere.chaos.http.ChaosRequestLog:15)
> [2015-03-06 06:04:04,057] INFO Received status update for task
> busybox.9777a963-c3c6-11e4-a31a-56847afe9799: TASK_FAILED (Abnormal
> executor termination) (mesosphere.marathon.MarathonScheduler:165)
> [2015-03-06 06:04:04,063] INFO Task launch delay for [/busybox] is now
> [43] seconds (mesosphere.util.RateLimiter:34)
> [2015-03-06 06:04:04,068] INFO Task
> busybox.9777a963-c3c6-11e4-a31a-56847afe9799 expunged and removed from
> TaskTracker (mesosphere.marathon.tasks.TaskTracker:101)
> [2015-03-06 06:04:04,068] INFO Sending event notification.
> (mesosphere.marathon.MarathonScheduler:274)
>
> Mesos-Slave Log:
>
> Mar 06 06:06:03 node-0800279564ad sh[27684]: E0306 06:06:03.898473 13
> slave.cpp:2787] Container '9835da8c-a844-4d53-a7f7-4a5e6e808a9b' for
> executor 'busybox.d4ef22c6-c3c6-11e4-a31a-56847afe9799' of framework
> '20150306-054714-24707342-5050-1-0000' failed to start: Failed to create
> container: Failed to chown: Failed to get user information for 'devel':
> Success
> Mar 06 06:06:03 node-0800279564ad sh[27684]: E0306 06:06:03.900068 13
> slave.cpp:2882] Termination of executor
> 'busybox.d4ef22c6-c3c6-11e4-a31a-56847afe9799' of framework
> '20150306-054714-24707342-5050-1-0000' failed: Unknown container:
> 9835da8c-a844-4d53-a7f7-4a5e6e808a9b
> Mar 06 06:06:03 node-0800279564ad sh[27684]: E0306 06:06:03.905900 13
> slave.cpp:3134] Failed to unmonitor container for executor
> busybox.d4ef22c6-c3c6-11e4-a31a-56847afe9799 of framework
> 20150306-054714-24707342-5050-1-0000: Not monitored
>
> Could the failure be related to me running the mesos-slave as container
> here?
>
> Thanks,
> ./Siva.
>
> On Mon, Mar 9, 2015 at 10:51 AM, Sivaram Kannan <si...@gmail.com>
> wrote:
>
>>
>> Hi Vinod,
>>
>> Thanks, I got it. I guess I did not understand the relationship between
>> principals defined in authentication and in authorization. I re-read the
>> authentication and credentials flag, it is not clear from them that the
>> principals defined in authorization should match them to work correctly. If
>> I could, will change the documentation to be more clear and submit a PR.
>>
>> Thanks,
>> ./Siva.
>>
>> On Mon, Mar 9, 2015 at 2:18 AM, Vinod Kone <vi...@apache.org> wrote:
>>
>>> The principal used for authenticating the framework is the same
>>> principal used to authorize the framework too. So you need to use
>>> 'marathon' in your credentials too. In other words, when you start the
>>> framework the Credential.principal should be the same as
>>> FrameworkInfo.principal (Mesos master will validate this).
>>>
>>> On Sun, Mar 8, 2015 at 10:48 AM, Sivaram Kannan <si...@gmail.com>
>>> wrote:
>>>
>>>> I0308 17:41:14.876610 6 master.cpp:1342] Authorizing framework
>>>> principal 'user1' to receive offers for role 'apps'
>>>>
>>>
>>> As you can see from this line, the master is trying to authorize
>>> principal 'user1' and not 'marathon'.
>>>
>>
>>
>>
>> --
>> ever tried. ever failed. no matter.
>> try again. fail again. fail better.
>> -- Samuel Beckett
>>
>
>
>
> --
> ever tried. ever failed. no matter.
> try again. fail again. fail better.
> -- Samuel Beckett
>
--
ever tried. ever failed. no matter.
try again. fail again. fail better.
-- Samuel Beckett
Re: Who is the user in Mesos Authorization ACL definition?
Posted by Sivaram Kannan <si...@gmail.com>.
Hi Vinod,
The users in below run_tasks definition - does it refer to unix users in
the machine where the framework is run or the unix users in the mesos-slave
machine. I think the fact that I run all softwares (mesos-master,
mesos-slave, marathon) as docker containers is of significance and reason
for the below failure.
"run_tasks": [
{
"principals": {
"values": [
"marathon"
]
},
"users": {
"values": [
"devel"
]
}
},
{
"principals": {
"values": [
"marathon"
]
},
"users": {
"type": "NONE"
}
}
]
When I start the marathon, I start with the flag --mesos_user=devel and
while bringing up mesos-slave I bring up with the flag
--switch_user=true(which I think anyway is default). When I try to launch a
task this is what I am getting
Marathon Log:
0.10; rv:38.0) Gecko/20100101 Firefox/38.0"
(mesosphere.chaos.http.ChaosRequestLog:15)
[2015-03-06 06:04:04,057] INFO Received status update for task
busybox.9777a963-c3c6-11e4-a31a-56847afe9799: TASK_FAILED (Abnormal
executor termination) (mesosphere.marathon.MarathonScheduler:165)
[2015-03-06 06:04:04,063] INFO Task launch delay for [/busybox] is now [43]
seconds (mesosphere.util.RateLimiter:34)
[2015-03-06 06:04:04,068] INFO Task
busybox.9777a963-c3c6-11e4-a31a-56847afe9799 expunged and removed from
TaskTracker (mesosphere.marathon.tasks.TaskTracker:101)
[2015-03-06 06:04:04,068] INFO Sending event notification.
(mesosphere.marathon.MarathonScheduler:274)
Mesos-Slave Log:
Mar 06 06:06:03 node-0800279564ad sh[27684]: E0306 06:06:03.898473 13
slave.cpp:2787] Container '9835da8c-a844-4d53-a7f7-4a5e6e808a9b' for
executor 'busybox.d4ef22c6-c3c6-11e4-a31a-56847afe9799' of framework
'20150306-054714-24707342-5050-1-0000' failed to start: Failed to create
container: Failed to chown: Failed to get user information for 'devel':
Success
Mar 06 06:06:03 node-0800279564ad sh[27684]: E0306 06:06:03.900068 13
slave.cpp:2882] Termination of executor
'busybox.d4ef22c6-c3c6-11e4-a31a-56847afe9799' of framework
'20150306-054714-24707342-5050-1-0000' failed: Unknown container:
9835da8c-a844-4d53-a7f7-4a5e6e808a9b
Mar 06 06:06:03 node-0800279564ad sh[27684]: E0306 06:06:03.905900 13
slave.cpp:3134] Failed to unmonitor container for executor
busybox.d4ef22c6-c3c6-11e4-a31a-56847afe9799 of framework
20150306-054714-24707342-5050-1-0000: Not monitored
Could the failure be related to me running the mesos-slave as container
here?
Thanks,
./Siva.
On Mon, Mar 9, 2015 at 10:51 AM, Sivaram Kannan <si...@gmail.com> wrote:
>
> Hi Vinod,
>
> Thanks, I got it. I guess I did not understand the relationship between
> principals defined in authentication and in authorization. I re-read the
> authentication and credentials flag, it is not clear from them that the
> principals defined in authorization should match them to work correctly. If
> I could, will change the documentation to be more clear and submit a PR.
>
> Thanks,
> ./Siva.
>
> On Mon, Mar 9, 2015 at 2:18 AM, Vinod Kone <vi...@apache.org> wrote:
>
>> The principal used for authenticating the framework is the same principal
>> used to authorize the framework too. So you need to use 'marathon' in your
>> credentials too. In other words, when you start the framework the
>> Credential.principal should be the same as FrameworkInfo.principal (Mesos
>> master will validate this).
>>
>> On Sun, Mar 8, 2015 at 10:48 AM, Sivaram Kannan <si...@gmail.com>
>> wrote:
>>
>>> I0308 17:41:14.876610 6 master.cpp:1342] Authorizing framework
>>> principal 'user1' to receive offers for role 'apps'
>>>
>>
>> As you can see from this line, the master is trying to authorize
>> principal 'user1' and not 'marathon'.
>>
>
>
>
> --
> ever tried. ever failed. no matter.
> try again. fail again. fail better.
> -- Samuel Beckett
>
--
ever tried. ever failed. no matter.
try again. fail again. fail better.
-- Samuel Beckett
Re: Who is the user in Mesos Authorization ACL definition?
Posted by Sivaram Kannan <si...@gmail.com>.
Hi Vinod,
Thanks, I got it. I guess I did not understand the relationship between
principals defined in authentication and in authorization. I re-read the
authentication and credentials flag, it is not clear from them that the
principals defined in authorization should match them to work correctly. If
I could, will change the documentation to be more clear and submit a PR.
Thanks,
./Siva.
On Mon, Mar 9, 2015 at 2:18 AM, Vinod Kone <vi...@apache.org> wrote:
> The principal used for authenticating the framework is the same principal
> used to authorize the framework too. So you need to use 'marathon' in your
> credentials too. In other words, when you start the framework the
> Credential.principal should be the same as FrameworkInfo.principal (Mesos
> master will validate this).
>
> On Sun, Mar 8, 2015 at 10:48 AM, Sivaram Kannan <si...@gmail.com>
> wrote:
>
>> I0308 17:41:14.876610 6 master.cpp:1342] Authorizing framework
>> principal 'user1' to receive offers for role 'apps'
>>
>
> As you can see from this line, the master is trying to authorize principal
> 'user1' and not 'marathon'.
>
--
ever tried. ever failed. no matter.
try again. fail again. fail better.
-- Samuel Beckett
Re: Who is the user in Mesos Authorization ACL definition?
Posted by Vinod Kone <vi...@apache.org>.
The principal used for authenticating the framework is the same principal
used to authorize the framework too. So you need to use 'marathon' in your
credentials too. In other words, when you start the framework the
Credential.principal should be the same as FrameworkInfo.principal (Mesos
master will validate this).
On Sun, Mar 8, 2015 at 10:48 AM, Sivaram Kannan <si...@gmail.com> wrote:
> I0308 17:41:14.876610 6 master.cpp:1342] Authorizing framework
> principal 'user1' to receive offers for role 'apps'
>
As you can see from this line, the master is trying to authorize principal
'user1' and not 'marathon'.
Re: Who is the user in Mesos Authorization ACL definition?
Posted by Sivaram Kannan <si...@gmail.com>.
Hi,
There was a mistake in the acl.json i sent earlier. But even after
correcting it I am getting the same error. Let me explain. The intention
for defining the acl.json is to have a
1. Only principals marathon with roles apps,dev-ops should be able to
register framework with mesos
2. Only principal marathon with users root,devel should be able to
run_tasks.
3. I am also using --credentials flag to authenticate users with the same
name devel. Sorry it was not clear earlier since both user used in
run_tasks and authencation principal are same. Now to make it clear I have
made the authentication principal as user1.
The below json was written. I looked at the examples at
http://mesos.apache.org/documentation/latest/authorization/ to write this.
"register_frameworks": [
{
"principals": {
"values": [
"marathon"
]
},
"roles": {
"values": [
"apps",
"dev-ops"
]
}
},
{
"principals": {
"type": "NONE"
},
"roles": {
"values": [
"apps",
"dev-ops"
]
}
}
],
"permissive": false,
"run_tasks": [
{
"principals": {
"values": [
"marathon"
]
},
"users": {
"values": [
"root",
"montana"
]
}
},
{
"principals": {
"values": [
"marathon"
]
},
"users": {
"type": "NONE"
}
}
]
Mesos-Master log
I0308 17:41:14.862144 12 authenticator.hpp:166] Creating new server SASL
connection
I0308 17:41:14.863014 8 authenticator.hpp:272] Received SASL
authentication start
I0308 17:41:14.864115 8 authenticator.hpp:394] Authentication requires
more steps
I0308 17:41:14.864646 7 authenticator.hpp:300] Received SASL
authentication step
I0308 17:41:14.864787 7 authenticator.hpp:386] Authentication success
I0308 17:41:14.865087 7 master.cpp:3959] Successfully authenticated
principal 'user1' at
scheduler-bc8241e0-3b70-433a-8389-e091c301228a@192.168.1.106:9090
I0308 17:41:14.876425 6 master.cpp:1383] Received registration request
for framework 'marathon' at
scheduler-bc8241e0-3b70-433a-8389-e091c301228a@192.168.1.106:9090
I0308 17:41:14.876610 6 master.cpp:1342] Authorizing framework
principal 'user1' to receive offers for role 'apps'
I0308 17:41:14.876829 6 master.cpp:1402] Refusing registration of
framework 'marathon' at
scheduler-bc8241e0-3b70-433a-8389-e091c301228a@192.168.1.106:9090: Not
authorized to use role 'apps'
Marathon log:
I0308 17:41:14.860546 43 authenticatee.hpp:133] Creating new client SASL
connection
I0308 17:41:14.862584 42 authenticatee.hpp:224] Received SASL
authentication mechanisms: CRAM-MD5
I0308 17:41:14.862704 42 authenticatee.hpp:250] Attempting to
authenticate with mechanism 'CRAM-MD5'
I0308 17:41:14.864399 39 authenticatee.hpp:270] Received SASL
authentication step
I0308 17:41:14.875982 45 authenticatee.hpp:310] Authentication success
I0308 17:41:14.876098 45 sched.cpp:358] Successfully authenticated with
master master@192.168.1.106:5050
I0308 17:41:14.877272 46 sched.cpp:736] Got error 'Not authorized to use
role 'apps''
I0308 17:41:14.878365 46 sched.cpp:1320] Asked to abort the driver
[2015-03-08 17:41:14,878] WARN Error: Not authorized to use role 'apps'
(mesosphere.marathon.MarathonScheduler:258)
[2015-03-08 17:41:14,880] FATAL Committing suicide
(mesosphere.marathon.MarathonScheduler:263)
I0308 17:41:14.880939 46 sched.cpp:777] Aborting framework ''
Thanks,
./Siva.
On Sun, Mar 8, 2015 at 10:28 PM, Vinod Kone <vi...@apache.org> wrote:
> First, note that "permissive" flag applies to all ACLs
> (register_frameworks and run_tasks in your case), irrespective of where in
> the JSON it is defined.
>
> Without the premissive =false tag, the framework gets registered and any
>> role other than apps or dev-ops gets rejected by mesos-master. But when I
>> have the permissive=false set for run_tasks, I get the following error when
>> start the marathon
>>
>>
> Does framework get rejected for *any* role (with permissive as "true")?
> From the ACLs, it looks like "marathon" role would be rejected. Any other
> role should be accepted. Can you show me an example?
>
> Authorization is not working at all if I have permissive=false defined.
>> Just to summarize other things I have tried, 1) removing the permissive tag
>> make the framework registration to go through, 2) removing the principals
>> type NONE results in the same error. What am I missing here??
>>
>
> From the log, it looks like you were trying principal as "devel" and role
> as "apps", which I would expect to be rejected based on your ACLs (none of
> the ACLs match and permissive is "false"). What do you mean by
> authorization is not working at all? Have you tried principal as "marathon"
> and roles as "apps"? That should work.
>
>
>
--
ever tried. ever failed. no matter.
try again. fail again. fail better.
-- Samuel Beckett
Re: Who is the user in Mesos Authorization ACL definition?
Posted by Vinod Kone <vi...@apache.org>.
First, note that "permissive" flag applies to all ACLs (register_frameworks
and run_tasks in your case), irrespective of where in the JSON it is
defined.
Without the premissive =false tag, the framework gets registered and any
> role other than apps or dev-ops gets rejected by mesos-master. But when I
> have the permissive=false set for run_tasks, I get the following error when
> start the marathon
>
>
Does framework get rejected for *any* role (with permissive as "true")?
>From the ACLs, it looks like "marathon" role would be rejected. Any other
role should be accepted. Can you show me an example?
Authorization is not working at all if I have permissive=false defined.
> Just to summarize other things I have tried, 1) removing the permissive tag
> make the framework registration to go through, 2) removing the principals
> type NONE results in the same error. What am I missing here??
>
>From the log, it looks like you were trying principal as "devel" and role
as "apps", which I would expect to be rejected based on your ACLs (none of
the ACLs match and permissive is "false"). What do you mean by
authorization is not working at all? Have you tried principal as "marathon"
and roles as "apps"? That should work.
Re: Who is the user in Mesos Authorization ACL definition?
Posted by Sivaram Kannan <si...@gmail.com>.
Hi,
I got in to a different problem when I defined permissive = false in the
acl.json. Following is the acl.json i have defined. I have defined
permissive: false above run_tasks.
{
"register_frameworks": [
{
"principals": {
"values": [
"marathon"
]
},
"roles": {
"values": [
"apps",
"dev-ops"
]
}
},
{
"principals": {
"type": "NONE"
},
"roles": {
"values": [
"marathon"
]
}
}
],
"permissive": false,
"run_tasks": [
{
"principals": {
"values": [
"marathon"
]
},
"users": {
"values": [
"root",
"devel"
]
}
},
{
"principals": {
"values": [
"marathon"
]
},
"users": {
"type": "NONE"
}
}
]
}
Without the premissive =false tag, the framework gets registered and any
role other than apps or dev-ops gets rejected by mesos-master. But when I
have the permissive=false set for run_tasks, I get the following error when
start the marathon
<mesos-master log>
I0308 14:56:51.991261 14 master.cpp:3901] Authenticating
scheduler-91f0e9fb-5d13-4874-ae7f-3a05cca7d13e@192.168.1.106:9090
I0308 14:56:51.992118 14 master.cpp:3912] Using default CRAM-MD5
authenticator
I0308 14:56:51.992384 14 authenticator.hpp:166] Creating new server SASL
connection
I0308 14:56:51.993505 8 authenticator.hpp:272] Received SASL
authentication start
I0308 14:56:51.993590 8 authenticator.hpp:394] Authentication requires
more steps
I0308 14:56:51.995046 8 authenticator.hpp:300] Received SASL
authentication step
I0308 14:56:51.995201 8 authenticator.hpp:386] Authentication success
I0308 14:56:51.995379 8 master.cpp:3959] Successfully authenticated
principal 'devel' at
scheduler-91f0e9fb-5d13-4874-ae7f-3a05cca7d13e@192.168.1.106:9090
I0308 14:56:51.996145 8 master.cpp:1520] Received re-registration
request from framework 20150307-044244-1778493632-5050-1-0000 (marathon) at
scheduler-91f0e9fb-5d13-4874-ae7f-3a05cca7d13e@192.168.1.106:9090
I0308 14:56:51.997325 8 master.cpp:1342] Authorizing framework
principal 'devel' to receive offers for role 'apps'
I0308 14:56:51.997428 8 master.cpp:1542] Refusing re-registration of
framework 20150307-044244-1778493632-5050-1-0000 (marathon) at
scheduler-91f0e9fb-5d13-4874-ae7f-3a05cca7d13e@192.168.1.106:9090: Not
authorized to use role 'apps'
<marathon log>
I0308 14:56:51.990717 47 authenticatee.hpp:133] Creating new client SASL
connection
I0308 14:56:51.992751 48 authenticatee.hpp:224] Received SASL
authentication mechanisms: CRAM-MD5
I0308 14:56:51.992869 48 authenticatee.hpp:250] Attempting to
authenticate with mechanism 'CRAM-MD5'
I0308 14:56:51.994890 51 authenticatee.hpp:270] Received SASL
authentication step
I0308 14:56:51.995720 49 authenticatee.hpp:310] Authentication success
I0308 14:56:51.995867 49 sched.cpp:358] Successfully authenticated with
master master@192.168.1.106:5050
I0308 14:56:51.997730 50 sched.cpp:736] Got error 'Not authorized to use
role 'apps''
I0308 14:56:51.997869 50 sched.cpp:1320] Asked to abort the driver
[2015-03-08 14:56:51,998] WARN Error: Not authorized to use role 'apps'
(mesosphere.marathon.MarathonScheduler:258)
Authorization is not working at all if I have permissive=false defined.
Just to summarize other things I have tried, 1) removing the permissive tag
make the framework registration to go through, 2) removing the principals
type NONE results in the same error. What am I missing here??
Thanks,
./Siva.
On Fri, Mar 6, 2015 at 10:44 PM, Sivaram Kannan <si...@gmail.com> wrote:
>
> Awesome. Thanks Vinod. Let me try that.
>
> On Fri, Mar 6, 2015 at 10:08 PM, Vinod Kone <vi...@apache.org> wrote:
>
>> Quoting form the documentation
>> <http://mesos.apache.org/documentation/latest/authorization/>:
>>
>> "
>>
>> There are couple of important things to note:
>>
>> 1.
>>
>> ACLs are matched in the order that they are setup. In other words,
>> the first matching ACL determines whether a request is authorized or not.
>> 2.
>>
>> If none of the specified ACLs match the given request, whether the
>> request is authorized or not is defined by ACLs.permissive field. By
>> default this is “true” i.e., a non-matching request is authorized.
>>
>>
>> "
>>
>> So in your case, since the user doesn't match "user1" and "permissive" is
>> not set (default), the request is authorized.
>>
>> If you only want your framework to run tasks as "user1", add
>> '"permissive" = false' to your ACLs JSON.
>>
>> HTH,
>>
>>
>> On Fri, Mar 6, 2015 at 2:32 AM, Sivaram Kannan <si...@gmail.com>
>> wrote:
>>
>>>
>>> Just to make it more clear, I want to understand in which scenario would
>>> the task authorization will fail and framework gets a TASK_LOST error. I
>>> would greatly appreciate If you could give an example what I should change
>>> in the acl.json and the master or slave to get the TASK_LOST errror.
>>>
>>> Version of Mesos: 0.21.1 and marathon v0.7.7-SNAPSHOT. All of them are
>>> being run as docker containers.
>>>
>>> Thanks,
>>> ./Siva.
>>>
>>> On Fri, Mar 6, 2015 at 2:36 PM, Sivaram Kannan <si...@gmail.com>
>>> wrote:
>>>
>>>>
>>>> Guess I don't understand then. Let me give some tests I ran for
>>>> understanding ACL, but am not clear which unix users is this. Assume I have
>>>> two nodes.
>>>>
>>>> Node1 - runs Mesos-master and marathon
>>>> Node2 - runs mesos-slave
>>>>
>>>> Both the above nodes have an users named devel and root.
>>>>
>>>> Test1: I started the mesos-master with the following acl.json
>>>>
>>>> "run_tasks": [
>>>> {
>>>> "principals": {
>>>> "values": [
>>>> "marathon"
>>>> ]
>>>> },
>>>> "users": {
>>>> "values": [
>>>> "root",
>>>> "devel"
>>>> ]
>>>> }
>>>> },
>>>> {
>>>> "principals": {
>>>> "values": [
>>>> "marathon"
>>>> ]
>>>> },
>>>> "users": {
>>>> "type": "NONE"
>>>> }
>>>> }
>>>> ]
>>>>
>>>> I was able to launch the tasks from the marathon. Now I modified the
>>>> acl.json as follow and relaunched the mesos-master. In this I wanted to
>>>> make the task fail and see the error
>>>>
>>>> "principals": {
>>>> "values": [
>>>> "marathon"
>>>> ]
>>>> },
>>>> "users": {
>>>> "values": [
>>>> "user1"
>>>> ]
>>>> }
>>>>
>>>>
>>>> Even now I am able to launch the tasks from the marathon instance. So,
>>>> can you please tell me which nodes unix user does values under "users" tag
>>>> refers to? Am I making anything wrong in the way I am using run_tasks??
>>>>
>>>> Thanks,
>>>> ./Siva
>>>>
>>>> On Thu, Mar 5, 2015 at 11:35 PM, Vinod Kone <vi...@apache.org>
>>>> wrote:
>>>>
>>>>> I'm not very familiar with Marathon, but the 'user' in the 'run_tasks'
>>>>> ACL is the unix user that the executor/run process runs as. This user is
>>>>> set by frameworks by setting 'CommandInfo.user'.
>>>>>
>>>>> On Thu, Mar 5, 2015 at 9:06 AM, Sivaram Kannan <si...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> The user that is defined as part of Mesos's Authorization ACL, which
>>>>>> user is it? Taking marathon framework as example, the users defined as part
>>>>>> of run_tasks principal, is it the user that is used to run marathon
>>>>>> executable or the unix user available in the mesos-slave's?
>>>>>>
>>>>>> Documentation in
>>>>>> http://mesos.apache.org/documentation/latest/authorization/ does not
>>>>>> seems to be clear on that. Can someone clarify?
>>>>>>
>>>>>> Thanks,
>>>>>> ./Siva.
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> ever tried. ever failed. no matter.
>>>> try again. fail again. fail better.
>>>> -- Samuel Beckett
>>>>
>>>
>>>
>>>
>>> --
>>> ever tried. ever failed. no matter.
>>> try again. fail again. fail better.
>>> -- Samuel Beckett
>>>
>>
>>
>
>
> --
> ever tried. ever failed. no matter.
> try again. fail again. fail better.
> -- Samuel Beckett
>
--
ever tried. ever failed. no matter.
try again. fail again. fail better.
-- Samuel Beckett
Re: Who is the user in Mesos Authorization ACL definition?
Posted by Sivaram Kannan <si...@gmail.com>.
Awesome. Thanks Vinod. Let me try that.
On Fri, Mar 6, 2015 at 10:08 PM, Vinod Kone <vi...@apache.org> wrote:
> Quoting form the documentation
> <http://mesos.apache.org/documentation/latest/authorization/>:
>
> "
>
> There are couple of important things to note:
>
> 1.
>
> ACLs are matched in the order that they are setup. In other words, the
> first matching ACL determines whether a request is authorized or not.
> 2.
>
> If none of the specified ACLs match the given request, whether the
> request is authorized or not is defined by ACLs.permissive field. By
> default this is “true” i.e., a non-matching request is authorized.
>
>
> "
>
> So in your case, since the user doesn't match "user1" and "permissive" is
> not set (default), the request is authorized.
>
> If you only want your framework to run tasks as "user1", add '"permissive"
> = false' to your ACLs JSON.
>
> HTH,
>
>
> On Fri, Mar 6, 2015 at 2:32 AM, Sivaram Kannan <si...@gmail.com>
> wrote:
>
>>
>> Just to make it more clear, I want to understand in which scenario would
>> the task authorization will fail and framework gets a TASK_LOST error. I
>> would greatly appreciate If you could give an example what I should change
>> in the acl.json and the master or slave to get the TASK_LOST errror.
>>
>> Version of Mesos: 0.21.1 and marathon v0.7.7-SNAPSHOT. All of them are
>> being run as docker containers.
>>
>> Thanks,
>> ./Siva.
>>
>> On Fri, Mar 6, 2015 at 2:36 PM, Sivaram Kannan <si...@gmail.com>
>> wrote:
>>
>>>
>>> Guess I don't understand then. Let me give some tests I ran for
>>> understanding ACL, but am not clear which unix users is this. Assume I have
>>> two nodes.
>>>
>>> Node1 - runs Mesos-master and marathon
>>> Node2 - runs mesos-slave
>>>
>>> Both the above nodes have an users named devel and root.
>>>
>>> Test1: I started the mesos-master with the following acl.json
>>>
>>> "run_tasks": [
>>> {
>>> "principals": {
>>> "values": [
>>> "marathon"
>>> ]
>>> },
>>> "users": {
>>> "values": [
>>> "root",
>>> "devel"
>>> ]
>>> }
>>> },
>>> {
>>> "principals": {
>>> "values": [
>>> "marathon"
>>> ]
>>> },
>>> "users": {
>>> "type": "NONE"
>>> }
>>> }
>>> ]
>>>
>>> I was able to launch the tasks from the marathon. Now I modified the
>>> acl.json as follow and relaunched the mesos-master. In this I wanted to
>>> make the task fail and see the error
>>>
>>> "principals": {
>>> "values": [
>>> "marathon"
>>> ]
>>> },
>>> "users": {
>>> "values": [
>>> "user1"
>>> ]
>>> }
>>>
>>>
>>> Even now I am able to launch the tasks from the marathon instance. So,
>>> can you please tell me which nodes unix user does values under "users" tag
>>> refers to? Am I making anything wrong in the way I am using run_tasks??
>>>
>>> Thanks,
>>> ./Siva
>>>
>>> On Thu, Mar 5, 2015 at 11:35 PM, Vinod Kone <vi...@apache.org>
>>> wrote:
>>>
>>>> I'm not very familiar with Marathon, but the 'user' in the 'run_tasks'
>>>> ACL is the unix user that the executor/run process runs as. This user is
>>>> set by frameworks by setting 'CommandInfo.user'.
>>>>
>>>> On Thu, Mar 5, 2015 at 9:06 AM, Sivaram Kannan <si...@gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> The user that is defined as part of Mesos's Authorization ACL, which
>>>>> user is it? Taking marathon framework as example, the users defined as part
>>>>> of run_tasks principal, is it the user that is used to run marathon
>>>>> executable or the unix user available in the mesos-slave's?
>>>>>
>>>>> Documentation in
>>>>> http://mesos.apache.org/documentation/latest/authorization/ does not
>>>>> seems to be clear on that. Can someone clarify?
>>>>>
>>>>> Thanks,
>>>>> ./Siva.
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> ever tried. ever failed. no matter.
>>> try again. fail again. fail better.
>>> -- Samuel Beckett
>>>
>>
>>
>>
>> --
>> ever tried. ever failed. no matter.
>> try again. fail again. fail better.
>> -- Samuel Beckett
>>
>
>
--
ever tried. ever failed. no matter.
try again. fail again. fail better.
-- Samuel Beckett
Re: Who is the user in Mesos Authorization ACL definition?
Posted by Vinod Kone <vi...@apache.org>.
Quoting form the documentation
<http://mesos.apache.org/documentation/latest/authorization/>:
"
There are couple of important things to note:
1.
ACLs are matched in the order that they are setup. In other words, the
first matching ACL determines whether a request is authorized or not.
2.
If none of the specified ACLs match the given request, whether the
request is authorized or not is defined by ACLs.permissive field. By
default this is “true” i.e., a non-matching request is authorized.
"
So in your case, since the user doesn't match "user1" and "permissive" is
not set (default), the request is authorized.
If you only want your framework to run tasks as "user1", add '"permissive"
= false' to your ACLs JSON.
HTH,
On Fri, Mar 6, 2015 at 2:32 AM, Sivaram Kannan <si...@gmail.com> wrote:
>
> Just to make it more clear, I want to understand in which scenario would
> the task authorization will fail and framework gets a TASK_LOST error. I
> would greatly appreciate If you could give an example what I should change
> in the acl.json and the master or slave to get the TASK_LOST errror.
>
> Version of Mesos: 0.21.1 and marathon v0.7.7-SNAPSHOT. All of them are
> being run as docker containers.
>
> Thanks,
> ./Siva.
>
> On Fri, Mar 6, 2015 at 2:36 PM, Sivaram Kannan <si...@gmail.com>
> wrote:
>
>>
>> Guess I don't understand then. Let me give some tests I ran for
>> understanding ACL, but am not clear which unix users is this. Assume I have
>> two nodes.
>>
>> Node1 - runs Mesos-master and marathon
>> Node2 - runs mesos-slave
>>
>> Both the above nodes have an users named devel and root.
>>
>> Test1: I started the mesos-master with the following acl.json
>>
>> "run_tasks": [
>> {
>> "principals": {
>> "values": [
>> "marathon"
>> ]
>> },
>> "users": {
>> "values": [
>> "root",
>> "devel"
>> ]
>> }
>> },
>> {
>> "principals": {
>> "values": [
>> "marathon"
>> ]
>> },
>> "users": {
>> "type": "NONE"
>> }
>> }
>> ]
>>
>> I was able to launch the tasks from the marathon. Now I modified the
>> acl.json as follow and relaunched the mesos-master. In this I wanted to
>> make the task fail and see the error
>>
>> "principals": {
>> "values": [
>> "marathon"
>> ]
>> },
>> "users": {
>> "values": [
>> "user1"
>> ]
>> }
>>
>>
>> Even now I am able to launch the tasks from the marathon instance. So,
>> can you please tell me which nodes unix user does values under "users" tag
>> refers to? Am I making anything wrong in the way I am using run_tasks??
>>
>> Thanks,
>> ./Siva
>>
>> On Thu, Mar 5, 2015 at 11:35 PM, Vinod Kone <vi...@apache.org> wrote:
>>
>>> I'm not very familiar with Marathon, but the 'user' in the 'run_tasks'
>>> ACL is the unix user that the executor/run process runs as. This user is
>>> set by frameworks by setting 'CommandInfo.user'.
>>>
>>> On Thu, Mar 5, 2015 at 9:06 AM, Sivaram Kannan <si...@gmail.com>
>>> wrote:
>>>
>>>>
>>>> Hi,
>>>>
>>>> The user that is defined as part of Mesos's Authorization ACL, which
>>>> user is it? Taking marathon framework as example, the users defined as part
>>>> of run_tasks principal, is it the user that is used to run marathon
>>>> executable or the unix user available in the mesos-slave's?
>>>>
>>>> Documentation in
>>>> http://mesos.apache.org/documentation/latest/authorization/ does not
>>>> seems to be clear on that. Can someone clarify?
>>>>
>>>> Thanks,
>>>> ./Siva.
>>>>
>>>>
>>>
>>
>>
>> --
>> ever tried. ever failed. no matter.
>> try again. fail again. fail better.
>> -- Samuel Beckett
>>
>
>
>
> --
> ever tried. ever failed. no matter.
> try again. fail again. fail better.
> -- Samuel Beckett
>
Re: Who is the user in Mesos Authorization ACL definition?
Posted by Sivaram Kannan <si...@gmail.com>.
Just to make it more clear, I want to understand in which scenario would
the task authorization will fail and framework gets a TASK_LOST error. I
would greatly appreciate If you could give an example what I should change
in the acl.json and the master or slave to get the TASK_LOST errror.
Version of Mesos: 0.21.1 and marathon v0.7.7-SNAPSHOT. All of them are
being run as docker containers.
Thanks,
./Siva.
On Fri, Mar 6, 2015 at 2:36 PM, Sivaram Kannan <si...@gmail.com> wrote:
>
> Guess I don't understand then. Let me give some tests I ran for
> understanding ACL, but am not clear which unix users is this. Assume I have
> two nodes.
>
> Node1 - runs Mesos-master and marathon
> Node2 - runs mesos-slave
>
> Both the above nodes have an users named devel and root.
>
> Test1: I started the mesos-master with the following acl.json
>
> "run_tasks": [
> {
> "principals": {
> "values": [
> "marathon"
> ]
> },
> "users": {
> "values": [
> "root",
> "devel"
> ]
> }
> },
> {
> "principals": {
> "values": [
> "marathon"
> ]
> },
> "users": {
> "type": "NONE"
> }
> }
> ]
>
> I was able to launch the tasks from the marathon. Now I modified the
> acl.json as follow and relaunched the mesos-master. In this I wanted to
> make the task fail and see the error
>
> "principals": {
> "values": [
> "marathon"
> ]
> },
> "users": {
> "values": [
> "user1"
> ]
> }
>
>
> Even now I am able to launch the tasks from the marathon instance. So, can
> you please tell me which nodes unix user does values under "users" tag
> refers to? Am I making anything wrong in the way I am using run_tasks??
>
> Thanks,
> ./Siva
>
> On Thu, Mar 5, 2015 at 11:35 PM, Vinod Kone <vi...@apache.org> wrote:
>
>> I'm not very familiar with Marathon, but the 'user' in the 'run_tasks'
>> ACL is the unix user that the executor/run process runs as. This user is
>> set by frameworks by setting 'CommandInfo.user'.
>>
>> On Thu, Mar 5, 2015 at 9:06 AM, Sivaram Kannan <si...@gmail.com>
>> wrote:
>>
>>>
>>> Hi,
>>>
>>> The user that is defined as part of Mesos's Authorization ACL, which
>>> user is it? Taking marathon framework as example, the users defined as part
>>> of run_tasks principal, is it the user that is used to run marathon
>>> executable or the unix user available in the mesos-slave's?
>>>
>>> Documentation in
>>> http://mesos.apache.org/documentation/latest/authorization/ does not
>>> seems to be clear on that. Can someone clarify?
>>>
>>> Thanks,
>>> ./Siva.
>>>
>>>
>>
>
>
> --
> ever tried. ever failed. no matter.
> try again. fail again. fail better.
> -- Samuel Beckett
>
--
ever tried. ever failed. no matter.
try again. fail again. fail better.
-- Samuel Beckett
Re: Who is the user in Mesos Authorization ACL definition?
Posted by Sivaram Kannan <si...@gmail.com>.
Guess I don't understand then. Let me give some tests I ran for
understanding ACL, but am not clear which unix users is this. Assume I have
two nodes.
Node1 - runs Mesos-master and marathon
Node2 - runs mesos-slave
Both the above nodes have an users named devel and root.
Test1: I started the mesos-master with the following acl.json
"run_tasks": [
{
"principals": {
"values": [
"marathon"
]
},
"users": {
"values": [
"root",
"devel"
]
}
},
{
"principals": {
"values": [
"marathon"
]
},
"users": {
"type": "NONE"
}
}
]
I was able to launch the tasks from the marathon. Now I modified the
acl.json as follow and relaunched the mesos-master. In this I wanted to
make the task fail and see the error
"principals": {
"values": [
"marathon"
]
},
"users": {
"values": [
"user1"
]
}
Even now I am able to launch the tasks from the marathon instance. So, can
you please tell me which nodes unix user does values under "users" tag
refers to? Am I making anything wrong in the way I am using run_tasks??
Thanks,
./Siva
On Thu, Mar 5, 2015 at 11:35 PM, Vinod Kone <vi...@apache.org> wrote:
> I'm not very familiar with Marathon, but the 'user' in the 'run_tasks' ACL
> is the unix user that the executor/run process runs as. This user is set by
> frameworks by setting 'CommandInfo.user'.
>
> On Thu, Mar 5, 2015 at 9:06 AM, Sivaram Kannan <si...@gmail.com>
> wrote:
>
>>
>> Hi,
>>
>> The user that is defined as part of Mesos's Authorization ACL, which user
>> is it? Taking marathon framework as example, the users defined as part of
>> run_tasks principal, is it the user that is used to run marathon executable
>> or the unix user available in the mesos-slave's?
>>
>> Documentation in
>> http://mesos.apache.org/documentation/latest/authorization/ does not
>> seems to be clear on that. Can someone clarify?
>>
>> Thanks,
>> ./Siva.
>>
>>
>
--
ever tried. ever failed. no matter.
try again. fail again. fail better.
-- Samuel Beckett
Re: Who is the user in Mesos Authorization ACL definition?
Posted by Vinod Kone <vi...@apache.org>.
I'm not very familiar with Marathon, but the 'user' in the 'run_tasks' ACL
is the unix user that the executor/run process runs as. This user is set by
frameworks by setting 'CommandInfo.user'.
On Thu, Mar 5, 2015 at 9:06 AM, Sivaram Kannan <si...@gmail.com> wrote:
>
> Hi,
>
> The user that is defined as part of Mesos's Authorization ACL, which user
> is it? Taking marathon framework as example, the users defined as part of
> run_tasks principal, is it the user that is used to run marathon executable
> or the unix user available in the mesos-slave's?
>
> Documentation in
> http://mesos.apache.org/documentation/latest/authorization/ does not
> seems to be clear on that. Can someone clarify?
>
> Thanks,
> ./Siva.
>
>