Conversation
| private static final String CLIENT_PREFIX = FLUO_PREFIX + ".client"; | ||
|
|
||
| /** | ||
| * @since 1.2.0 |
| /** | ||
| * @since 1.2.0 | ||
| */ | ||
| public static final String CLIENT_KERBEROS = CLIENT_PREFIX + ".kerberos"; |
There was a problem hiding this comment.
Since this is only used for HDFS and not for zookeeper or accumulo, I think the prop name should be CLIENT_HDFS_KERBEROS = CLIENT_PREFIX + ".hdfs.kerberos"
…rberos" to ".hdfs.kerberos".
ctubbsii
left a comment
ctubbsii
left a comment
There was a problem hiding this comment.
I'm not a big fan of the Hadoop code bleeding into Fluo's tooling.
If there's any way we can avoid putting UGI stuff in Fluo, and instead be a bit more passive, I think I'd prefer that... but I don't know how much support UGI has for passive configuration without the calling application being explicitly aware of the Kerberos settings.
Ideally, UGI would respect standard Kerberos environment variables, or more likely, standard JAAS configuration, and the user can simply set up the appropriate Kerberos environment that the HDFS client library will use... without us needing to provide any explicit configuration for it to pass through.
| * @param keytab Keytab path. | ||
| * @since 1.3.0 | ||
| */ | ||
| public void loginWithKerberos(final String realm, final String keytab) { |
There was a problem hiding this comment.
As far as I can tell, this only enables authentication to HDFS using HDFS client-side authentication features. The name should indicate hdfsLoginWithKerberos or some other indication. At the very least, the Javadoc should indicate that this is HDFS authentication.
There was a problem hiding this comment.
As we notice, just the jar copy process demanded kerberos authentication. All other components were able to retrieve the tokens from environment. But I agree with you. Fluo should work using the environment authentication.
I'll try other approaches. For while if someone want to use Fluo on kerberos this could help.
There was a problem hiding this comment.
Oh, interesting. I'm surprised other components worked from the environment, but this did not. I wonder why. Did you try fluo-yarn? Also, do you know if this change allows it to work with Accumulo with Kerberos tokens? Or did you only try Accumulo using regular PasswordTokens?
There was a problem hiding this comment.
Another possible way to fix this would be to ensure we use hadoop config from the classpath and document that.
There was a problem hiding this comment.
Yes! Our Accumulo is kerberized too. We have no problem with. We didn’t tried fluo-yarn yet on this environment. We can try.
|
It seems like a user should be able to do the following with the current code. If this does not work, need to determine why. kinit user@realm
fluo init app fluo-app.properties
kdestroy |
|
I'm back! I'm going to check if this is enough. Sorry by the delay! |
|
Welcome back Alan.
…On Tue, Jul 10, 2018, 8:04 AM alancamillo ***@***.***> wrote:
I'm back! I'm going to check if this is enough. Sorry by the delay!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#1030 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/Acg-LE0bdRVMcfVbjZ4GcJqJ_qww_g_Oks5uFMJpgaJpZM4S8F9d>
.
|
glad to hear it. |
5 participants
Applying the contribution of @muschneider. We are working in a kerberized cluster where we tested this code. I'll try provide a docker with Kerberos to test this feature.