hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wei-Chiu Chuang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-13597) Switch KMS from Tomcat to Jetty
Date Thu, 08 Dec 2016 11:53:58 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-13597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15731992#comment-15731992

Wei-Chiu Chuang commented on HADOOP-13597:

Hi [~jzhuge] thanks for working on this big patch!

* 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.
* It seems the KMS server is not Kerberized. You might want to construct a HttpServer2 object
with extra options to enable Kerberos:
new HttpServer2.Builder().setSecurityEnabled(true)
* When KMSWebServer starts/stops, it should print corresponding message using {{StringUtils.startupShutdownMessage}}.
This will make supporters' life easier.
* 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.
* 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.
* 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?
* 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.

> 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

To unsubscribe, e-mail: common-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-issues-help@hadoop.apache.org

View raw message