[
https://issues.apache.org/jira/browse/HADOOP-13597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15732830#comment-15732830
]
John Zhuge commented on HADOOP-13597:
-------------------------------------
Thanks [~jojochuang] for the review !
bq. There's one bit that might cause confusion in deployment. The fact that
keystore password could come from either environment variable, from
configuration file or credential files (via Configuration#getPassword) make me
feel a bit uneasy. If the password comes from a credential file, it will also
need to ProviderUtils.excludeIncompatibleCredentialProviders in order to trim
credential files on HdfsFileSystems.
Very good point! I will engage wider discussion. As a precaution, I could
revert to the existing KMS approach which does not consult credential provider
and file a separate JIRA to integrate with credential provider.
bq. It seems the KMS server is not Kerberized. You might want to construct a
HttpServer2 object with extra options to enable Kerberos:
KMS uses {{KMSAuthenticationFilter}} specified in web.xml instead of the
generic {{AuthenticationFilter}} by HttpServer2.
bq. When KMSWebServer starts/stops, it should print corresponding message using
StringUtils.startupShutdownMessage. This will make supporters' life easier.
Will do.
bq. I think you can not assume the admin user is user.name=kms when accessing
the servlets such as jmx, loglevel, etc. Also, need to make sure access
permission is guarded properly accessing these servlets.
Don't think existing KMS supports admin user. Will add this feature.
bq. I am not sure how existing KMS handles truststore and its password, but I
think you might be missing something in the new KMS when handling truststore
and its password.
Truststore password is obsoleted by HADOOP-13864.
bq. The keystore password comes from configuration key
hadoop.security.keystore.java-keystore-provider.password-file. If I understand
ConfigRedact correctly it doesn't seem to redact this specific configuration
key to me. Could you double check?
This key is for the password file, not password, so it does not have to be
redacted.
bq. In Configuration#getPasswordString, please print name if there's an
IOException to log. Also, should it catch IOException and return null? If it
looks for a password but is unable to, would it be easier to let the exception
be thrown? It could be a troubleshooting nightmare I imagine.
Good point. {{getPasswordString}} seems unnecessary. Remove it.
> Switch KMS from Tomcat to Jetty
> -------------------------------
>
> Key: HADOOP-13597
> URL: https://issues.apache.org/jira/browse/HADOOP-13597
> Project: Hadoop Common
> Issue Type: New Feature
> Components: kms
> Affects Versions: 2.6.0
> Reporter: John Zhuge
> Assignee: John Zhuge
> Attachments: HADOOP-13597.001.patch, HADOOP-13597.002.patch,
> HADOOP-13597.003.patch
>
>
> The Tomcat 6 we are using will reach EOL at the end of 2017. While there are
> other good options, I would propose switching to {{Jetty 9}} for the
> following reasons:
> * Easier migration. Both Tomcat and Jetty are based on {{Servlet
> Containers}}, so we don't have change client code that much. It would require
> more work to switch to {{JAX-RS}}.
> * Well established.
> * Good performance and scalability.
> Other alternatives:
> * Jersey + Grizzly
> * Tomcat 8
> Your opinions will be greatly appreciated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
