Hi Vivek, Sounds like you got this correct to me. The part "callback" sounds a bit odd to me; there is no callback in that sense. You get a ticket to your session and then can work on Kerberized Hadoop with that. This is two separate steps on the commandline — not one workflow connected via callback.
What I described was the manual workflow to get a ticket. If you need to run batch jobs, like cron, it is best to use keytab files for that. I think, the Java API should be used best with keytab files. Kind regards, Daniel. > On 13 Mar 2016, at 09:44, Vivek Mishra <[email protected]> wrote: > > Hi Daniel, > Thanks for prompt response. So I need a standalone Kerberos java client first > for kinit purpose and then in callback I can use UserGroupInformation > =>loginfromKeytab and run map reduce job? > > Please let me know, if I understood correctly. > > PS: Via kinit command line I am able to access and run map reduce job but > struggling with java api. > > Sincerely, > -Vivek > > From: Daniel Schulz [mailto:[email protected]] > Sent: 13 March 2016 14:10 > To: Vivek Mishra <[email protected]> > Cc: Benoy Antony <[email protected]>; [email protected] > Subject: Re: Kerberos Hadoop access > > Hi Vivek, > > Benoy is right: when you log into your secured Hadoop cluster machine Y (raw > OS first) you need a Kerberos ticket from KDC from machine X first. > Therefore, your OS user needs a configured Kerberos client, gets a ticket > using kinit from X and assigns it to your session on Y. klist then displays > your ticket information and its validity on the commandline. Then, you are > able to work on Hadoop with your user for this time span. After it or when > doing the next login, you need a new Kerberos ticket doing the same thing. > > To destroy your Kerberos ticket simply issue kdestroy on the commandline. In > case of further questions, please feel free to reach out to us any time. > > Kind regards, Daniel. > > On 13 Mar 2016, at 09:26, Vivek Mishra <[email protected]> wrote: > > Hi Benoy, > Thanks for your response. Would > > You can also obtain kerberos tickets programatically using keytab. See > http://hadoopsecurity.org/wiki/How%20to%20access%20secure%20Hadoop%20cluster%20programmatically%20using%20keytab > > it also work from remote client machine? > > Shouldn’t it be like need to connect with remote KDC server first for kinit? > Here in my case, KDC is on machine X and secured hadoop cluster is on machine > Y. > > Please suggest. > > Sincerely, > -Vivek > > From: Benoy Antony [mailto:[email protected]] > Sent: 13 March 2016 02:43 > To: Vivek Mishra <[email protected]> > Cc: [email protected] > Subject: Re: Kerberos Hadoop access > > Hi Vivek, > > You need a kerberos ticket to interact with a secure Hadoop Cluster. To > obtain kerberos ticket , do a kinit. More kerberos command are here : > http://hadoopsecurity.org/wiki/Useful%20Kerberos%20Commands%20for%20a%20Hadoop%20User > > You can also obtain kerberos tickets programatically using keytab. See > http://hadoopsecurity.org/wiki/How%20to%20access%20secure%20Hadoop%20cluster%20programmatically%20using%20keytab > > Other than fetching a ticket, you do not need to change anything. > > A few useful "How Tos" for a secure Hadoop Cluster are here : > http://hadoopsecurity.org/wiki/How%20Tos > > Let me know if it solves your problem. > > thanks , > Benoy > > > > > On Sat, Mar 12, 2016 at 7:39 AM, Vivek Mishra <[email protected]> > wrote: > Hi, > Can anyone point me to a reference for running map reduce job or HDFS file > creation over Kerberos secured HDFS cluster( From remote client machine)? > Spent entire day with different tweaks using UserGroupInformation and > SecurityUtil. > > > > > > > > > > NOTE: This message may contain information that is confidential, proprietary, > privileged or otherwise protected by law. The message is intended solely for > the named addressee. If received in error, please destroy and notify the > sender. Any use of this email is prohibited when received in error. Impetus > does not represent, warrant and/or guarantee, that the integrity of this > communication has been maintained nor that the communication is free of > errors, virus, interception or interference. > > > > > > > > > NOTE: This message may contain information that is confidential, proprietary, > privileged or otherwise protected by law. The message is intended solely for > the named addressee. If received in error, please destroy and notify the > sender. Any use of this email is prohibited when received in error. Impetus > does not represent, warrant and/or guarantee, that the integrity of this > communication has been maintained nor that the communication is free of > errors, virus, interception or interference. > > > > > > > > NOTE: This message may contain information that is confidential, proprietary, > privileged or otherwise protected by law. The message is intended solely for > the named addressee. If received in error, please destroy and notify the > sender. Any use of this email is prohibited when received in error. Impetus > does not represent, warrant and/or guarantee, that the integrity of this > communication has been maintained nor that the communication is free of > errors, virus, interception or interference.
