You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ambari.apache.org by "David F. Quiroga (JIRA)" <ji...@apache.org> on 2018/05/22 05:35:00 UTC
[jira] [Resolved] (AMBARI-23866) Kerberos Service Check failure due
to kinit failure on random node
[ https://issues.apache.org/jira/browse/AMBARI-23866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David F. Quiroga resolved AMBARI-23866.
---------------------------------------
Resolution: Implemented
Fix Version/s: 2.7.0
Pull request merged into trunk.
Would make note of Robert's comment
{quote}Maybe a future enhancement will be to add properties so a user can adjust the number to retries and the timeout value between retries.
{quote}
> Kerberos Service Check failure due to kinit failure on random node
> ------------------------------------------------------------------
>
> Key: AMBARI-23866
> URL: https://issues.apache.org/jira/browse/AMBARI-23866
> Project: Ambari
> Issue Type: Improvement
> Affects Versions: 2.5.2
> Environment: Multiple Kerberos Domain Controllers across multiple data centers for single realm.
> Reporter: David F. Quiroga
> Assignee: David F. Quiroga
> Priority: Minor
> Labels: pull-request-available
> Fix For: 2.7.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> We were seeing Kerberos Service checks failures in Ambari. Specifically it would fail during the first run of the day, succeed on the second, then fail on the next but succeed if run again and so forth.
> Reviewing the operation log, it showed kinit failure from random node(s)
> {{kinit: Client XXXX not found in Kerberos database while getting initial credentials}}
> Since AMBARI-9852
> {quote}The service check must perform the following steps:
> 1.Create a unique principal in the relevant KDC (server)
> 2.Test that the principal can be used to authenticate via kinit (agent)
> 3.Destroy the principal (server)
> {quote}
> Which is a very good check of services.
> So what is happening...
> In our environment we have multiple Kerberos Domain Controllers across multiple data centers all providing the same realm.
> The creation of a unique principal occurs at a single KDC and is propagated to the others.
> The agents were testing the principal at different KDC, i.e. before it had a change to propagate. This is why the second service check would succeed.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)