Hi Mikhail, Could you please explain how we can track all the kill requests for a job? Is there any feature available in hadoop stack for this? Or do we need to track this in OS layer by capturing the signals?
Thanks, Pandeesh On Jul 31, 2013 12:03 AM, "Mikhail Antonov" <olorinb...@gmail.com> wrote: > In addition to using job's ACLs you could have more brutal schema. Track > all requests to kill the jobs, and if any request is coming from the user > who should't be trying to kill this particular job, then ssh from the > script to his client machine and forcibly reboot it :) > > > 2013/7/30 Edward Capriolo <edlinuxg...@gmail.com> > >> Honestly tell your users to stop being jerks. People know if they kill my >> query there is going to be hell to pay :) >> >> >> On Tue, Jul 30, 2013 at 2:25 PM, Vinod Kumar Vavilapalli < >> vino...@apache.org> wrote: >> >>> >>> You need to set up Job ACLs. See >>> http://hadoop.apache.org/docs/stable/mapred_tutorial.html#Job+Authorization >>> . >>> >>> It is a per job configuration, you can provide with defaults. If the job >>> owner wishes to give others access, he/she can do so. >>> >>> Thanks, >>> +Vinod Kumar Vavilapalli >>> Hortonworks Inc. >>> http://hortonworks.com/ >>> >>> On Jul 30, 2013, at 11:21 AM, Murat Odabasi wrote: >>> >>> Hi there, >>> >>> I am trying to introduce some sort of security to prevent different >>> people using the cluster from interfering with each other's jobs. >>> >>> Following the instructions at >>> http://hadoop.apache.org/docs/stable/cluster_setup.html and >>> >>> https://www.inkling.com/read/hadoop-definitive-guide-tom-white-3rd/chapter-9/security >>> , this is what I put in my mapred-site.xml: >>> >>> <property> >>> <name>mapred.task.tracker.task-controller</name> >>> <value>org.apache.hadoop.mapred.LinuxTaskController</value> >>> </property> >>> >>> <property> >>> <name>mapred.acls.enabled</name> >>> <value>true</value> >>> </property> >>> >>> I can see the configuration parameters in the job configuration when I >>> run a hive query, but the users are still able to kill each other's >>> jobs. >>> >>> Any ideas about what I may be missing? >>> Any alternative approaches I can adopt? >>> >>> Thanks. >>> >>> >>> >> > > > -- > Thanks, > Michael Antonov >
