On Fri, 2013-02-22 at 08:25 -0800, Alejandro Abdelnur wrote:
Hi Alejandro,
> Clément, any luck?
Unfortunately I have not been able to find some free time to test your
proposal today. I will most likely not be able to do it before the end
of next week. I will report the outcome of the test on the
Clément, any luck?
On Thu, Feb 21, 2013 at 9:35 AM, Alejandro Abdelnur wrote:
> Hi Clément,
>
> The HADOOP_USER_NAME trick will work only in a non-secure cluster where
> you can be whoever you want just by setting that property. it will not work
> in a secure setup.
>
> The JavaAction has the sa
Hi Clément,
The HADOOP_USER_NAME trick will work only in a non-secure cluster where you
can be whoever you want just by setting that property. it will not work in
a secure setup.
The JavaAction has the same limitation as the shell action (the shell
action is a specialized java action that just la
On 2013-02-21 18:01, Alejandro Abdelnur wrote:
Thanks Alejandro,
Oozie provides MR and Pig actions that propagate the user identity
correctly. If you are using a shell action your shell action ends up
running as the Unix user running the task, in an unsecure cluster is
typically the mapred user
Clément,
Oozie provides MR and Pig actions that propagate the user identity
correctly. If you are using a shell action your shell action ends up
running as the Unix user running the task, in an unsecure cluster is
typically the mapred user, in a secure cluster is the same user that
submitted the j
Hi all,
I'm currently troubleshooting an issue involving tasks ran under the
default mapred account rather the user account and would greatly
appreciate any help or suggestion.
The guilty action can be summarized like that:
- The workflow contains a shell action
- The shell action starts
