You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ambari.apache.org by jun aoki <ju...@gmail.com> on 2016/02/11 02:00:39 UTC
Review Request 43465: Hdfs keytab for hawq service check on secured
cluster
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/43465/
-----------------------------------------------------------
Review request for Ambari.
Bugs: AMBARI-15001
https://issues.apache.org/jira/browse/AMBARI-15001
Repository: ambari
Description
-------
This is to add hdfs keytab for hawq nodes.
Currently HAWQ's service check fails due to data clean up after service check is completed and causes a false negative.
Diffs
-----
ambari-server/src/main/resources/common-services/HAWQ/2.0.0/kerberos.json cc11c15
Diff: https://reviews.apache.org/r/43465/diff/
Testing
-------
Locally teted.
Thanks,
jun aoki
Re: Review Request 43465: Hdfs keytab for hawq service check on
secured cluster
Posted by jun aoki <ju...@gmail.com>.
> On Feb. 11, 2016, 1:15 a.m., Robert Levas wrote:
> > ambari-server/src/main/resources/common-services/HAWQ/2.0.0/kerberos.json, line 31
> > <https://reviews.apache.org/r/43465/diff/1/?file=1240075#file1240075line31>
> >
> > This is an interesting principal name choice. Why not use a principal name that helps to identify is use. Like, `hawq@${realm}` or better yet something like `${hawq-env/hawk_user}@${realm}`.
>
> jun aoki wrote:
> I agree Robert. this should've been hawq/_HOST${realm}. Currently this is a HAWQ limitation (it won't take any other principal name) https://issues.apache.org/jira/browse/HAWQ-406
>
> Robert Levas wrote:
> Thanks for clarification, hopefully HAWQ is fixed soon since using `postgres` can be confusing an potentally problematic. My big issue with this is how the auth-to-local rules get generated. In this case, since no `local_username` property is set for the identity, a specific auth-to-local rule will not be created. Thus, the mapping will fall to the default rule with does a one-for-one mapping and will associate this identity with the local `postgres` account - which may or may not exist. This scenario happens with HDFS when it maps a Kerberos identity to a local user account. So maybe if there is a local user created for HAWQ (`hawq-env/hawq-user` maybe?) use that as the `local_username` for the identity. For example:
>
> ```
> {
> ...,
> "principal": {
> "value": "postgres@${realm}",
> "type" : "service",
> "local_username" : "${hawq-env/hawq-user}"
> },
> ...
> }
>
> ```
>
> Robert Levas wrote:
> Note: While creating the example. I noticed the descrepancy in the principal name. Technically the value should have been `postgres/_HOST@${realm}` or the type should have been `user`. This is noted in issues I just added to the review.
Robert, it has been a good opportunity for me to learn how kerberos.json, local_username and auth_to_local in core.xml work together. Thx!
I'm going to set ```"local_username" : "postgres"``` as currently hawq user is hardcoded due to its limitation and is not exposed to any configraution files.
- jun
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/43465/#review118794
-----------------------------------------------------------
On Feb. 11, 2016, 1 a.m., jun aoki wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/43465/
> -----------------------------------------------------------
>
> (Updated Feb. 11, 2016, 1 a.m.)
>
>
> Review request for Ambari.
>
>
> Bugs: AMBARI-15001
> https://issues.apache.org/jira/browse/AMBARI-15001
>
>
> Repository: ambari
>
>
> Description
> -------
>
> This is to add hdfs keytab for hawq nodes.
> Currently HAWQ's service check fails due to data clean up after service check is completed and causes a false negative.
>
>
> Diffs
> -----
>
> ambari-server/src/main/resources/common-services/HAWQ/2.0.0/kerberos.json cc11c15
>
> Diff: https://reviews.apache.org/r/43465/diff/
>
>
> Testing
> -------
>
> Locally teted.
>
>
> Thanks,
>
> jun aoki
>
>
Re: Review Request 43465: Hdfs keytab for hawq service check on
secured cluster
Posted by Robert Levas <rl...@hortonworks.com>.
> On Feb. 10, 2016, 8:15 p.m., Robert Levas wrote:
> > ambari-server/src/main/resources/common-services/HAWQ/2.0.0/kerberos.json, lines 5-8
> > <https://reviews.apache.org/r/43465/diff/1/?file=1240075#file1240075line5>
> >
> > Is this identity used by both the `HAWKMASTER` and `HAWQSTANDBY` components? If not, this block should be moved into the appropriate component since we want to use it sparingly. Esentially the `/HDFS/NAMENODE/hdfs` is the _root_ user for HDFS. So we need to becareful where it gets put.
>
> jun aoki wrote:
> @robert Levas, thank you for your comment and sharing the knowledge. hdfs identity is indeed used by both HAWQMASTER and HAWQSTANDBY, thus I drop this issue.
Thanks for the clarification.
> On Feb. 10, 2016, 8:15 p.m., Robert Levas wrote:
> > ambari-server/src/main/resources/common-services/HAWQ/2.0.0/kerberos.json, lines 27-53
> > <https://reviews.apache.org/r/43465/diff/1/?file=1240075#file1240075line27>
> >
> > This identitiy seems to be duplicated in both components. You should probably move this to the service level and reference it in the component if component-specific changes need to be made.
>
> jun aoki wrote:
> Robert, thank you for telling me this. I saw the duplicate but had no idea I could define once and refers to it.
> https://cwiki.apache.org/confluence/display/AMBARI/Automated+Kerberizaton#AutomatedKerberizaton-Service-levelIdentities for anybody who wants to know the detail of this.
Essentially you used the same mechanism when including the HDFS identity. :)
> On Feb. 10, 2016, 8:15 p.m., Robert Levas wrote:
> > ambari-server/src/main/resources/common-services/HAWQ/2.0.0/kerberos.json, line 31
> > <https://reviews.apache.org/r/43465/diff/1/?file=1240075#file1240075line31>
> >
> > This is an interesting principal name choice. Why not use a principal name that helps to identify is use. Like, `hawq@${realm}` or better yet something like `${hawq-env/hawk_user}@${realm}`.
>
> jun aoki wrote:
> I agree Robert. this should've been hawq/_HOST${realm}. Currently this is a HAWQ limitation (it won't take any other principal name) https://issues.apache.org/jira/browse/HAWQ-406
Thanks for clarification, hopefully HAWQ is fixed soon since using `postgres` can be confusing an potentally problematic. My big issue with this is how the auth-to-local rules get generated. In this case, since no `local_username` property is set for the identity, a specific auth-to-local rule will not be created. Thus, the mapping will fall to the default rule with does a one-for-one mapping and will associate this identity with the local `postgres` account - which may or may not exist. This scenario happens with HDFS when it maps a Kerberos identity to a local user account. So maybe if there is a local user created for HAWQ (`hawq-env/hawq-user` maybe?) use that as the `local_username` for the identity. For example:
```
{
...,
"principal": {
"value": "postgres@${realm}",
"type" : "service",
"local_username" : "${hawq-env/hawq-user}"
},
...
}
```
- Robert
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/43465/#review118794
-----------------------------------------------------------
On Feb. 10, 2016, 8 p.m., jun aoki wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/43465/
> -----------------------------------------------------------
>
> (Updated Feb. 10, 2016, 8 p.m.)
>
>
> Review request for Ambari.
>
>
> Bugs: AMBARI-15001
> https://issues.apache.org/jira/browse/AMBARI-15001
>
>
> Repository: ambari
>
>
> Description
> -------
>
> This is to add hdfs keytab for hawq nodes.
> Currently HAWQ's service check fails due to data clean up after service check is completed and causes a false negative.
>
>
> Diffs
> -----
>
> ambari-server/src/main/resources/common-services/HAWQ/2.0.0/kerberos.json cc11c15
>
> Diff: https://reviews.apache.org/r/43465/diff/
>
>
> Testing
> -------
>
> Locally teted.
>
>
> Thanks,
>
> jun aoki
>
>
Re: Review Request 43465: Hdfs keytab for hawq service check on
secured cluster
Posted by Robert Levas <rl...@hortonworks.com>.
> On Feb. 10, 2016, 8:15 p.m., Robert Levas wrote:
> > ambari-server/src/main/resources/common-services/HAWQ/2.0.0/kerberos.json, line 31
> > <https://reviews.apache.org/r/43465/diff/1/?file=1240075#file1240075line31>
> >
> > This is an interesting principal name choice. Why not use a principal name that helps to identify is use. Like, `hawq@${realm}` or better yet something like `${hawq-env/hawk_user}@${realm}`.
>
> jun aoki wrote:
> I agree Robert. this should've been hawq/_HOST${realm}. Currently this is a HAWQ limitation (it won't take any other principal name) https://issues.apache.org/jira/browse/HAWQ-406
>
> Robert Levas wrote:
> Thanks for clarification, hopefully HAWQ is fixed soon since using `postgres` can be confusing an potentally problematic. My big issue with this is how the auth-to-local rules get generated. In this case, since no `local_username` property is set for the identity, a specific auth-to-local rule will not be created. Thus, the mapping will fall to the default rule with does a one-for-one mapping and will associate this identity with the local `postgres` account - which may or may not exist. This scenario happens with HDFS when it maps a Kerberos identity to a local user account. So maybe if there is a local user created for HAWQ (`hawq-env/hawq-user` maybe?) use that as the `local_username` for the identity. For example:
>
> ```
> {
> ...,
> "principal": {
> "value": "postgres@${realm}",
> "type" : "service",
> "local_username" : "${hawq-env/hawq-user}"
> },
> ...
> }
>
> ```
Note: While creating the example. I noticed the descrepancy in the principal name. Technically the value should have been `postgres/_HOST@${realm}` or the type should have been `user`. This is noted in issues I just added to the review.
- Robert
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/43465/#review118794
-----------------------------------------------------------
On Feb. 10, 2016, 8 p.m., jun aoki wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/43465/
> -----------------------------------------------------------
>
> (Updated Feb. 10, 2016, 8 p.m.)
>
>
> Review request for Ambari.
>
>
> Bugs: AMBARI-15001
> https://issues.apache.org/jira/browse/AMBARI-15001
>
>
> Repository: ambari
>
>
> Description
> -------
>
> This is to add hdfs keytab for hawq nodes.
> Currently HAWQ's service check fails due to data clean up after service check is completed and causes a false negative.
>
>
> Diffs
> -----
>
> ambari-server/src/main/resources/common-services/HAWQ/2.0.0/kerberos.json cc11c15
>
> Diff: https://reviews.apache.org/r/43465/diff/
>
>
> Testing
> -------
>
> Locally teted.
>
>
> Thanks,
>
> jun aoki
>
>
Re: Review Request 43465: Hdfs keytab for hawq service check on
secured cluster
Posted by jun aoki <ju...@gmail.com>.
> On Feb. 11, 2016, 1:15 a.m., Robert Levas wrote:
> > ambari-server/src/main/resources/common-services/HAWQ/2.0.0/kerberos.json, line 31
> > <https://reviews.apache.org/r/43465/diff/1/?file=1240075#file1240075line31>
> >
> > This is an interesting principal name choice. Why not use a principal name that helps to identify is use. Like, `hawq@${realm}` or better yet something like `${hawq-env/hawk_user}@${realm}`.
>
> jun aoki wrote:
> I agree Robert. this should've been hawq/_HOST${realm}. Currently this is a HAWQ limitation (it won't take any other principal name) https://issues.apache.org/jira/browse/HAWQ-406
>
> Robert Levas wrote:
> Thanks for clarification, hopefully HAWQ is fixed soon since using `postgres` can be confusing an potentally problematic. My big issue with this is how the auth-to-local rules get generated. In this case, since no `local_username` property is set for the identity, a specific auth-to-local rule will not be created. Thus, the mapping will fall to the default rule with does a one-for-one mapping and will associate this identity with the local `postgres` account - which may or may not exist. This scenario happens with HDFS when it maps a Kerberos identity to a local user account. So maybe if there is a local user created for HAWQ (`hawq-env/hawq-user` maybe?) use that as the `local_username` for the identity. For example:
>
> ```
> {
> ...,
> "principal": {
> "value": "postgres@${realm}",
> "type" : "service",
> "local_username" : "${hawq-env/hawq-user}"
> },
> ...
> }
>
> ```
>
> Robert Levas wrote:
> Note: While creating the example. I noticed the descrepancy in the principal name. Technically the value should have been `postgres/_HOST@${realm}` or the type should have been `user`. This is noted in issues I just added to the review.
>
> jun aoki wrote:
> Robert, it has been a good opportunity for me to learn how kerberos.json, local_username and auth_to_local in core.xml work together. Thx!
>
> I'm going to set ```"local_username" : "postgres"``` as currently hawq user is hardcoded due to its limitation and is not exposed to any configraution files.
>
> Robert Levas wrote:
> If you are going to use the same name, then you don't _have_ to add the `local_username` property sinc the default auth-to-local rule will take care of that... though it wont hurt. My point was really that if may be necessary for the `postgres` user to be an account on the local host and that the enable Kerberos process will not create this.
Thta's right. DEFAULT of auth_to_local will take care of it so I Will not add loca_username. Our service definition scripts will add postgres user accordingly so I guess I'm good to go!
- jun
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/43465/#review118794
-----------------------------------------------------------
On Feb. 11, 2016, 1 a.m., jun aoki wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/43465/
> -----------------------------------------------------------
>
> (Updated Feb. 11, 2016, 1 a.m.)
>
>
> Review request for Ambari.
>
>
> Bugs: AMBARI-15001
> https://issues.apache.org/jira/browse/AMBARI-15001
>
>
> Repository: ambari
>
>
> Description
> -------
>
> This is to add hdfs keytab for hawq nodes.
> Currently HAWQ's service check fails due to data clean up after service check is completed and causes a false negative.
>
>
> Diffs
> -----
>
> ambari-server/src/main/resources/common-services/HAWQ/2.0.0/kerberos.json cc11c15
>
> Diff: https://reviews.apache.org/r/43465/diff/
>
>
> Testing
> -------
>
> Locally teted.
>
>
> Thanks,
>
> jun aoki
>
>
Re: Review Request 43465: Hdfs keytab for hawq service check on
secured cluster
Posted by jun aoki <ju...@gmail.com>.
> On Feb. 11, 2016, 1:15 a.m., Robert Levas wrote:
> > ambari-server/src/main/resources/common-services/HAWQ/2.0.0/kerberos.json, lines 27-53
> > <https://reviews.apache.org/r/43465/diff/1/?file=1240075#file1240075line27>
> >
> > This identitiy seems to be duplicated in both components. You should probably move this to the service level and reference it in the component if component-specific changes need to be made.
Robert, thank you for telling me this. I saw the duplicate but had no idea I could define once and refers to it.
https://cwiki.apache.org/confluence/display/AMBARI/Automated+Kerberizaton#AutomatedKerberizaton-Service-levelIdentities for anybody who wants to know the detail of this.
- jun
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/43465/#review118794
-----------------------------------------------------------
On Feb. 11, 2016, 1 a.m., jun aoki wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/43465/
> -----------------------------------------------------------
>
> (Updated Feb. 11, 2016, 1 a.m.)
>
>
> Review request for Ambari.
>
>
> Bugs: AMBARI-15001
> https://issues.apache.org/jira/browse/AMBARI-15001
>
>
> Repository: ambari
>
>
> Description
> -------
>
> This is to add hdfs keytab for hawq nodes.
> Currently HAWQ's service check fails due to data clean up after service check is completed and causes a false negative.
>
>
> Diffs
> -----
>
> ambari-server/src/main/resources/common-services/HAWQ/2.0.0/kerberos.json cc11c15
>
> Diff: https://reviews.apache.org/r/43465/diff/
>
>
> Testing
> -------
>
> Locally teted.
>
>
> Thanks,
>
> jun aoki
>
>
Re: Review Request 43465: Hdfs keytab for hawq service check on
secured cluster
Posted by Robert Levas <rl...@hortonworks.com>.
> On Feb. 10, 2016, 8:15 p.m., Robert Levas wrote:
> > ambari-server/src/main/resources/common-services/HAWQ/2.0.0/kerberos.json, line 31
> > <https://reviews.apache.org/r/43465/diff/1/?file=1240075#file1240075line31>
> >
> > This is an interesting principal name choice. Why not use a principal name that helps to identify is use. Like, `hawq@${realm}` or better yet something like `${hawq-env/hawk_user}@${realm}`.
>
> jun aoki wrote:
> I agree Robert. this should've been hawq/_HOST${realm}. Currently this is a HAWQ limitation (it won't take any other principal name) https://issues.apache.org/jira/browse/HAWQ-406
>
> Robert Levas wrote:
> Thanks for clarification, hopefully HAWQ is fixed soon since using `postgres` can be confusing an potentally problematic. My big issue with this is how the auth-to-local rules get generated. In this case, since no `local_username` property is set for the identity, a specific auth-to-local rule will not be created. Thus, the mapping will fall to the default rule with does a one-for-one mapping and will associate this identity with the local `postgres` account - which may or may not exist. This scenario happens with HDFS when it maps a Kerberos identity to a local user account. So maybe if there is a local user created for HAWQ (`hawq-env/hawq-user` maybe?) use that as the `local_username` for the identity. For example:
>
> ```
> {
> ...,
> "principal": {
> "value": "postgres@${realm}",
> "type" : "service",
> "local_username" : "${hawq-env/hawq-user}"
> },
> ...
> }
>
> ```
>
> Robert Levas wrote:
> Note: While creating the example. I noticed the descrepancy in the principal name. Technically the value should have been `postgres/_HOST@${realm}` or the type should have been `user`. This is noted in issues I just added to the review.
>
> jun aoki wrote:
> Robert, it has been a good opportunity for me to learn how kerberos.json, local_username and auth_to_local in core.xml work together. Thx!
>
> I'm going to set ```"local_username" : "postgres"``` as currently hawq user is hardcoded due to its limitation and is not exposed to any configraution files.
If you are going to use the same name, then you don't _have_ to add the `local_username` property sinc the default auth-to-local rule will take care of that... though it wont hurt. My point was really that if may be necessary for the `postgres` user to be an account on the local host and that the enable Kerberos process will not create this.
- Robert
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/43465/#review118794
-----------------------------------------------------------
On Feb. 10, 2016, 8 p.m., jun aoki wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/43465/
> -----------------------------------------------------------
>
> (Updated Feb. 10, 2016, 8 p.m.)
>
>
> Review request for Ambari.
>
>
> Bugs: AMBARI-15001
> https://issues.apache.org/jira/browse/AMBARI-15001
>
>
> Repository: ambari
>
>
> Description
> -------
>
> This is to add hdfs keytab for hawq nodes.
> Currently HAWQ's service check fails due to data clean up after service check is completed and causes a false negative.
>
>
> Diffs
> -----
>
> ambari-server/src/main/resources/common-services/HAWQ/2.0.0/kerberos.json cc11c15
>
> Diff: https://reviews.apache.org/r/43465/diff/
>
>
> Testing
> -------
>
> Locally teted.
>
>
> Thanks,
>
> jun aoki
>
>
Re: Review Request 43465: Hdfs keytab for hawq service check on
secured cluster
Posted by jun aoki <ju...@gmail.com>.
> On Feb. 11, 2016, 1:15 a.m., Robert Levas wrote:
> > ambari-server/src/main/resources/common-services/HAWQ/2.0.0/kerberos.json, lines 5-8
> > <https://reviews.apache.org/r/43465/diff/1/?file=1240075#file1240075line5>
> >
> > Is this identity used by both the `HAWKMASTER` and `HAWQSTANDBY` components? If not, this block should be moved into the appropriate component since we want to use it sparingly. Esentially the `/HDFS/NAMENODE/hdfs` is the _root_ user for HDFS. So we need to becareful where it gets put.
@robert Levas, thank you for your comment and sharing the knowledge. hdfs identity is indeed used by both HAWQMASTER and HAWQSTANDBY, thus I drop this issue.
> On Feb. 11, 2016, 1:15 a.m., Robert Levas wrote:
> > ambari-server/src/main/resources/common-services/HAWQ/2.0.0/kerberos.json, line 31
> > <https://reviews.apache.org/r/43465/diff/1/?file=1240075#file1240075line31>
> >
> > This is an interesting principal name choice. Why not use a principal name that helps to identify is use. Like, `hawq@${realm}` or better yet something like `${hawq-env/hawk_user}@${realm}`.
I agree Robert. this should've been hawq/_HOST${realm}. Currently this is a HAWQ limitation (it won't take any other principal name) https://issues.apache.org/jira/browse/HAWQ-406
- jun
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/43465/#review118794
-----------------------------------------------------------
On Feb. 11, 2016, 1 a.m., jun aoki wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/43465/
> -----------------------------------------------------------
>
> (Updated Feb. 11, 2016, 1 a.m.)
>
>
> Review request for Ambari.
>
>
> Bugs: AMBARI-15001
> https://issues.apache.org/jira/browse/AMBARI-15001
>
>
> Repository: ambari
>
>
> Description
> -------
>
> This is to add hdfs keytab for hawq nodes.
> Currently HAWQ's service check fails due to data clean up after service check is completed and causes a false negative.
>
>
> Diffs
> -----
>
> ambari-server/src/main/resources/common-services/HAWQ/2.0.0/kerberos.json cc11c15
>
> Diff: https://reviews.apache.org/r/43465/diff/
>
>
> Testing
> -------
>
> Locally teted.
>
>
> Thanks,
>
> jun aoki
>
>
Re: Review Request 43465: Hdfs keytab for hawq service check on
secured cluster
Posted by Robert Levas <rl...@hortonworks.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/43465/#review118794
-----------------------------------------------------------
ambari-server/src/main/resources/common-services/HAWQ/2.0.0/kerberos.json (lines 5 - 8)
<https://reviews.apache.org/r/43465/#comment180095>
Is this identity used by both the `HAWKMASTER` and `HAWQSTANDBY` components? If not, this block should be moved into the appropriate component since we want to use it sparingly. Esentially the `/HDFS/NAMENODE/hdfs` is the _root_ user for HDFS. So we need to becareful where it gets put.
ambari-server/src/main/resources/common-services/HAWQ/2.0.0/kerberos.json (lines 27 - 44)
<https://reviews.apache.org/r/43465/#comment180096>
This identitiy seems to be duplicated in both components. You should probably move this to the service level and reference it in the component if component-specific changes need to be made.
ambari-server/src/main/resources/common-services/HAWQ/2.0.0/kerberos.json (line 31)
<https://reviews.apache.org/r/43465/#comment180097>
This is an interesting principal name choice. Why not use a principal name that helps to identify is use. Like, `hawq@${realm}` or better yet something like `${hawq-env/hawk_user}@${realm}`.
- Robert Levas
On Feb. 10, 2016, 8 p.m., jun aoki wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/43465/
> -----------------------------------------------------------
>
> (Updated Feb. 10, 2016, 8 p.m.)
>
>
> Review request for Ambari.
>
>
> Bugs: AMBARI-15001
> https://issues.apache.org/jira/browse/AMBARI-15001
>
>
> Repository: ambari
>
>
> Description
> -------
>
> This is to add hdfs keytab for hawq nodes.
> Currently HAWQ's service check fails due to data clean up after service check is completed and causes a false negative.
>
>
> Diffs
> -----
>
> ambari-server/src/main/resources/common-services/HAWQ/2.0.0/kerberos.json cc11c15
>
> Diff: https://reviews.apache.org/r/43465/diff/
>
>
> Testing
> -------
>
> Locally teted.
>
>
> Thanks,
>
> jun aoki
>
>
Re: Review Request 43465: Hdfs keytab for hawq service check on
secured cluster
Posted by jun aoki <ju...@gmail.com>.
> On Feb. 12, 2016, 2:30 p.m., Robert Levas wrote:
> > ambari-server/src/main/resources/common-services/HAWQ/2.0.0/kerberos.json, lines 30-31
> > <https://reviews.apache.org/r/43465/diff/1/?file=1240075#file1240075line30>
> >
> > The principal is declared as a *service*, however the princial name does not include the FQDN of the host the service. This is typically a bad practice. So if this identitiy is really a service-level identitiy, the principal name should be changed to `postgres/_HOST@@{realm}` or the `type` should be changed to `user`.
Thank you for pointing that out. will fix this as well. (Chaning it to "user" as there is the HAWQ limitation stated at Feb. 12, 2016, 12:27 a.m. )
- jun
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/43465/#review119016
-----------------------------------------------------------
On Feb. 11, 2016, 1 a.m., jun aoki wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/43465/
> -----------------------------------------------------------
>
> (Updated Feb. 11, 2016, 1 a.m.)
>
>
> Review request for Ambari.
>
>
> Bugs: AMBARI-15001
> https://issues.apache.org/jira/browse/AMBARI-15001
>
>
> Repository: ambari
>
>
> Description
> -------
>
> This is to add hdfs keytab for hawq nodes.
> Currently HAWQ's service check fails due to data clean up after service check is completed and causes a false negative.
>
>
> Diffs
> -----
>
> ambari-server/src/main/resources/common-services/HAWQ/2.0.0/kerberos.json cc11c15
>
> Diff: https://reviews.apache.org/r/43465/diff/
>
>
> Testing
> -------
>
> Locally teted.
>
>
> Thanks,
>
> jun aoki
>
>
Re: Review Request 43465: Hdfs keytab for hawq service check on
secured cluster
Posted by Robert Levas <rl...@hortonworks.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/43465/#review119016
-----------------------------------------------------------
ambari-server/src/main/resources/common-services/HAWQ/2.0.0/kerberos.json (lines 30 - 31)
<https://reviews.apache.org/r/43465/#comment180313>
The principal is declared as a *service*, however the princial name does not include the FQDN of the host the service. This is typically a bad practice. So if this identitiy is really a service-level identitiy, the principal name should be changed to `postgres/_HOST@@{realm}` or the `type` should be changed to `user`.
ambari-server/src/main/resources/common-services/HAWQ/2.0.0/kerberos.json (lines 52 - 53)
<https://reviews.apache.org/r/43465/#comment180314>
Same service vs user identity issues mentioned above.
- Robert Levas
On Feb. 10, 2016, 8 p.m., jun aoki wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/43465/
> -----------------------------------------------------------
>
> (Updated Feb. 10, 2016, 8 p.m.)
>
>
> Review request for Ambari.
>
>
> Bugs: AMBARI-15001
> https://issues.apache.org/jira/browse/AMBARI-15001
>
>
> Repository: ambari
>
>
> Description
> -------
>
> This is to add hdfs keytab for hawq nodes.
> Currently HAWQ's service check fails due to data clean up after service check is completed and causes a false negative.
>
>
> Diffs
> -----
>
> ambari-server/src/main/resources/common-services/HAWQ/2.0.0/kerberos.json cc11c15
>
> Diff: https://reviews.apache.org/r/43465/diff/
>
>
> Testing
> -------
>
> Locally teted.
>
>
> Thanks,
>
> jun aoki
>
>
Re: Review Request 43465: Hdfs keytab for hawq service check on
secured cluster
Posted by Robert Levas <rl...@hortonworks.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/43465/#review119455
-----------------------------------------------------------
Ship it!
Ship It!
- Robert Levas
On Feb. 16, 2016, 9:34 p.m., jun aoki wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/43465/
> -----------------------------------------------------------
>
> (Updated Feb. 16, 2016, 9:34 p.m.)
>
>
> Review request for Ambari.
>
>
> Bugs: AMBARI-15001
> https://issues.apache.org/jira/browse/AMBARI-15001
>
>
> Repository: ambari
>
>
> Description
> -------
>
> This is to add hdfs keytab for hawq nodes.
> Currently HAWQ's service check fails due to data clean up after service check is completed and causes a false negative.
>
>
> Diffs
> -----
>
> ambari-server/src/main/resources/common-services/HAWQ/2.0.0/kerberos.json cc11c15
>
> Diff: https://reviews.apache.org/r/43465/diff/
>
>
> Testing
> -------
>
> Locally teted.
>
>
> Thanks,
>
> jun aoki
>
>
Re: Review Request 43465: Hdfs keytab for hawq service check on
secured cluster
Posted by jun aoki <ju...@gmail.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/43465/
-----------------------------------------------------------
(Updated Feb. 17, 2016, 2:34 a.m.)
Review request for Ambari.
Bugs: AMBARI-15001
https://issues.apache.org/jira/browse/AMBARI-15001
Repository: ambari
Description
-------
This is to add hdfs keytab for hawq nodes.
Currently HAWQ's service check fails due to data clean up after service check is completed and causes a false negative.
Diffs (updated)
-----
ambari-server/src/main/resources/common-services/HAWQ/2.0.0/kerberos.json cc11c15
Diff: https://reviews.apache.org/r/43465/diff/
Testing
-------
Locally teted.
Thanks,
jun aoki
Re: Review Request 43465: Hdfs keytab for hawq service check on
secured cluster
Posted by jun aoki <ju...@gmail.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/43465/#review118791
-----------------------------------------------------------
ambari-server/src/main/resources/common-services/HAWQ/2.0.0/kerberos.json (line 7)
<https://reviews.apache.org/r/43465/#comment180094>
Essentially this is the line added to the original code.
The rest is to have a better structure.
- jun aoki
On Feb. 11, 2016, 1 a.m., jun aoki wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/43465/
> -----------------------------------------------------------
>
> (Updated Feb. 11, 2016, 1 a.m.)
>
>
> Review request for Ambari.
>
>
> Bugs: AMBARI-15001
> https://issues.apache.org/jira/browse/AMBARI-15001
>
>
> Repository: ambari
>
>
> Description
> -------
>
> This is to add hdfs keytab for hawq nodes.
> Currently HAWQ's service check fails due to data clean up after service check is completed and causes a false negative.
>
>
> Diffs
> -----
>
> ambari-server/src/main/resources/common-services/HAWQ/2.0.0/kerberos.json cc11c15
>
> Diff: https://reviews.apache.org/r/43465/diff/
>
>
> Testing
> -------
>
> Locally teted.
>
>
> Thanks,
>
> jun aoki
>
>