[
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:
{code}
new HttpServer2.Builder().setSecurityEnabled(true)
.setUsernameConfKey(PRINCIPAL)
.setKeytabConfKey(KEYTAB);
{code}
* 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
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
