Mailing-List: contact dev-help@ambari.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ambari.apache.org
Date: Thu, 27 Nov 2014 15:36:12 +0000 (UTC)
From: "Hadoop QA (JIRA)" <jira@apache.org>
To: dev@ambari.apache.org
Message-ID: <JIRA.12755616.1416068976000.35313.1417102572622@Atlassian.JIRA>
In-Reply-To: <JIRA.12755616.1416068976000@Atlassian.JIRA>
References: <JIRA.12755616.1416068976000@Atlassian.JIRA>
 <JIRA.12755616.1416068976328@arcas>
Subject: [jira] [Commented] (AMBARI-8343) Components should indicate
 Security State (via ambari-agent)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/AMBARI-8343?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D142=
27755#comment-14227755 ]=20

Hadoop QA commented on AMBARI-8343:
-----------------------------------

{color:green}+1 overall{color}.  Here are the results of testing the latest=
 attachment=20
  http://issues.apache.org/jira/secure/attachment/12684063/AMBARI-8343_01.p=
atch
  against trunk revision .

    {color:green}+1 @author{color}.  The patch does not contain any @author=
 tags.

    {color:green}+1 tests included{color}.  The patch appears to include 2 =
new or modified test files.

    {color:green}+1 javac{color}.  The applied patch does not increase the =
total number of javac compiler warnings.

    {color:green}+1 release audit{color}.  The applied patch does not incre=
ase the total number of release audit warnings.

    {color:green}+1 core tests{color}.  The patch passed unit tests in .

Test results: https://builds.apache.org/job/Ambari-trunk-test-patch/770//te=
stReport/
Console output: https://builds.apache.org/job/Ambari-trunk-test-patch/770//=
console

This message is automatically generated.

> Components should indicate Security State (via ambari-agent)
> ------------------------------------------------------------
>
>                 Key: AMBARI-8343
>                 URL: https://issues.apache.org/jira/browse/AMBARI-8343
>             Project: Ambari
>          Issue Type: New Feature
>          Components: ambari-agent
>    Affects Versions: 2.0.0
>            Reporter: Robert Levas
>            Assignee: Robert Levas
>            Priority: Critical
>              Labels: kerberos, states
>             Fix For: 2.0.0
>
>         Attachments: AMBARI-8343_01.patch
>
>
> In order to properly handle the automated installation or removal of a se=
curity infrastructure (like Kerberos) in the cluster, Ambari needs to know =
whether each component on the hosts of the cluster is properly _secured_ or=
 not.  This information may be compared with data on the Ambari server to h=
elp determine what steps should be taken to ensure the cluster is in the co=
rrect _secured_ state.
> To do this, the current and desired component security state is maintaine=
d in the Ambari database.  The Ambari server will update the desired state =
details according to whether the cluster is to be secured or not and whethe=
r the relevant service has enough metadata to be secured.  If the desired a=
nd actual security state details do not match, the Ambari server will take =
the necessary steps to work towards synchronization.=20
> In order for a component to indicate its security status, a new property =
needs to be returned in the {{STATUS_COMMAND}} response message (from the A=
mbari agent).  This property should be named =E2=80=98securityState=E2=80=
=99 and should have one of the following values:
> * {{UNKNOWN}} - Indicates that it is not known whether the service or com=
ponent is secured or not
> * {{UNSECURED}} - Indicates service or component is not or should not be =
secured
> * {{SECURED_KERBEROS}} - Indicates component is or should be secured usin=
g Kerberos
> * {{ERROR}} - Indicates the component is not secured due to an error cond=
ition
> To properly set this state value, a call needs to be executed per compone=
nt querying for its specific state.  Due to the differences on how each com=
ponent is secured and how it may be determined if security is setup what ty=
pe is configured, and working is it properly, it is necessary for each comp=
onent to have its own logic for determining this state. Therefore the ambar=
i-agent process will need to call into the component=E2=80=99s configured (=
lifecycle) script and wait for its response - not unlike how it determines =
whether the component is up and running.
> After the infrastructure is in place, each service definition needs to be=
 updated to implement the new security status check function.  The function=
 should perform the following steps:
> * Determine if security is enabled or disabled
> ** If disabled, return "UNSECURED"
> ** If enabled, determine what type of security is enabled
> *** If Kerberos is configured
> **** Perform tests (kinit?, ping KDC?) to determine if the configuration =
appears to be working
> ***** If working, return =E2=80=9CSECURED_KERBEROS=E2=80=9D
> ***** If not working, return =E2=80=9CERROR=E2=80=9D
> *** Else, return "UNKNOWN"
> If no function is available, the Ambari agent should return =E2=80=9CUNKN=
OWN=E2=80=9D.
> On the Ambari server, the {{org.apache.ambari.server.agent.HeartBeatHandl=
er}} class needs to be updated to set the security state of the relevant co=
mponent, as indicated from the {{STATUS_COMMAND}} response.  This should be=
 done {{org.apache.ambari.server.agent.HeartBeatHandler#processStatusReport=
s}} method, by calling the relavant ServiceComponentHost=E2=80=99s setSecur=
ityState method.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)