> 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
>
>
|