On Mar 9, 2016, at 11:19 PM, Josh Elser <josh.el...@gmail.com<mailto:josh.el...@gmail.com>> wrote:
Aww, thanks for the kind words to close it out :). Glad to hear it's worked well for you. Just to share some Kerberos knowledge (and dispel any misinformation), any application which stops working after the default ticket lifetime is "doing it wrong" (tm). Like Steve pointed out, this is why renewals exist (often a dedicated thread running inside the application). Once you have a ticket, as long as you ask the KDC for a renewal before that original ticket expires, you can get a new one. Does renewal work past the expiry period? Generally, the default renewal period is defined as 24 hours, the default expiry period as days. My impression was that you could continually renew every renewal period during the expiry period, but ultimately would be required to obtain a new token at the 7 day mark: public static final String DFS_NAMENODE_DELEGATION_TOKEN_RENEW_INTERVAL_KEY = "dfs.namenode.delegation.token.renew-interval"; public static final long DFS_NAMENODE_DELEGATION_TOKEN_RENEW_INTERVAL_DEFAULT = 24*60*60*1000; // 1 day public static final String DFS_NAMENODE_DELEGATION_TOKEN_MAX_LIFETIME_KEY = "dfs.namenode.delegation.token.max-lifetime"; public static final long DFS_NAMENODE_DELEGATION_TOKEN_MAX_LIFETIME_DEFAULT = 7*24*60*60*1000; // 7 days Tim I wrote: Great! Thank you all. Regarding 0.50, it's been a while, but I recall back porting a couple of fixes to get my cluster up. IIRC, that was primarily related to kerberos fixes for instantiating the cluster. In 0.50 (+ the patches) accumulo and storm required a restart after 7 days. Barring that inconvenience, it worked great in a moderately sized production environment. Thanks again everyone. Tim On Mar 9, 2016 8:59 AM, "Jon Maron"<jma...@hortonworks.com<mailto:jma...@hortonworks.com>> wrote: On Mar 8, 2016, at 11:36 PM, Tim I<t...@timisrael.com<mailto:t...@timisrael.com>> wrote: Hi Josh, Basically anything with a kerberos ticket could no longer could communicate with anything else after 7 days due to the default config for the kerberos server : renew_lifetime = 7d The delegation token I believe was the reason for this since it didn't have access to the original service keytab. However, what I want to verify is if delegation tokens play any role in non-kerberized clusters and if there is anything else that might inhibit long running services in that environment. My suspicion is probably not. I'll continue testing. If anyone knows definitively, I'd love to hear about it. You are correct - delegation tokens should not play a role in a non-secure environment. What was the specific nature of the issues? i.e. which component ended up seeing the expiration issue? there has been work to resolve that issue since 0.50. Thanks! Tim On Mar 8, 2016 11:13 PM, "Josh Elser"<josh.el...@gmail.com<mailto:josh.el...@gmail.com>> wrote: Hi Tim, I wish I definitively knew the current state of things, but I don't anymore. I agree with your assessment though -- there should be no hard limit (the current docs state this as requirements too, http://slider.incubator.apache.org/docs/security.html). Was the 7-day expiration you referred to in the Slider app-master? Or the application Slider was running (e.g. HBase)? Tim I wrote: Hi all, My previous experience with Slider is in a Kerberized cluster using Slider 0.50.. It required me to restart the apps every 7 days (due to ticket expiration). Based on what I've read, I don't think there is anything preventing a non-Kerberized cluster from running apps indefinitely. Is that correct, or am I missing something? I'm currently using Hadoop 2.6.0 if it matters. Thanks, Tim
