[
https://issues.apache.org/jira/browse/HDFS-3059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14960014#comment-14960014
]
Xiao Chen commented on HDFS-3059:
---------------------------------
Thanks Yongjun for the comments. Attached patch 06 addressed your suggestions.
{quote}
3. Would you please explain why the following comments? maybe add the
explanation as an addition to the comment.
{quote}
This is added because I met the same NPE described when running
secondarynamenode (2NN). Running a command like {{hdfs secondarynamenode
-checkpoint}} with kerberos enabled will fail with the same NPE thrown. The
cause is that 2NN web server is needed when starting as a daemon, to show
status/metrics etc., which needs to get credentials. When running from shell,
the environment doesn't have the credentials and prompts for password. When the
password is not correct, {{getPassword}} sets the password to null, causing the
NPE. Note that clients are't supposed to know the password, but we should
definitely allow them to checkpoint. Since the metrics etc. are not needed when
running 2NN from shell, I think it makes sense to not start the web server at
all.
I have updated the comments like below, to give more information.
{code}
// The web server is only needed when starting SNN as a daemon,
// and not needed if called from shell command. Starting the web server
// from shell may fail when getting credentials, if the environment is not
// set up for it, which is most of the case.
{code}
> ssl-server.xml causes NullPointer
> ---------------------------------
>
> Key: HDFS-3059
> URL: https://issues.apache.org/jira/browse/HDFS-3059
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: datanode, security
> Affects Versions: 2.7.1
> Environment: in core-site.xml:
> {code:xml}
> <property>
> <name>hadoop.security.authentication</name>
> <value>kerberos</value>
> </property>
> <property>
> <name>hadoop.security.authorization</name>
> <value>true</value>
> </property>
> {code}
> in hdfs-site.xml:
> {code:xml}
> <property>
> <name>dfs.https.server.keystore.resource</name>
> <value>/etc/hadoop/conf/ssl-server.xml</value>
> </property>
> <property>
> <name>dfs.https.enable</name>
> <value>true</value>
> </property>
> <property>
> ...other security props
> </property>
> {code}
> Reporter: Evert Lammerts
> Assignee: Xiao Chen
> Priority: Minor
> Labels: BB2015-05-TBR
> Attachments: HDFS-3059.02.patch, HDFS-3059.03.patch,
> HDFS-3059.04.patch, HDFS-3059.05.patch, HDFS-3059.06.patch, HDFS-3059.patch,
> HDFS-3059.patch.2
>
>
> If ssl is enabled (dfs.https.enable) but ssl-server.xml is not available, a
> DN will crash during startup while setting up an SSL socket with a
> NullPointerException:
> {noformat}12/03/07 17:08:36 DEBUG security.Krb5AndCertsSslSocketConnector:
> useKerb = false, useCerts = true
> jetty.ssl.password : jetty.ssl.keypassword : 12/03/07 17:08:36 INFO
> mortbay.log: jetty-6.1.26.cloudera.1
> 12/03/07 17:08:36 INFO mortbay.log: Started
> [email protected]:1006
> 12/03/07 17:08:36 DEBUG security.Krb5AndCertsSslSocketConnector: Creating new
> KrbServerSocket for: 0.0.0.0
> 12/03/07 17:08:36 WARN mortbay.log: java.lang.NullPointerException
> 12/03/07 17:08:36 WARN mortbay.log: failed
> [email protected]:50475: java.io.IOException:
> !JsseListener: java.lang.NullPointerException
> 12/03/07 17:08:36 WARN mortbay.log: failed Server@604788d5:
> java.io.IOException: !JsseListener: java.lang.NullPointerException
> 12/03/07 17:08:36 INFO mortbay.log: Stopped
> [email protected]:50475
> 12/03/07 17:08:36 INFO mortbay.log: Stopped
> [email protected]:1006
> 12/03/07 17:08:37 INFO datanode.DataNode: Waiting for threadgroup to exit,
> active threads is 0{noformat}
> The same happens if I set an absolute path to an existing
> dfs.https.server.keystore.resource - in this case the file cannot be found
> but not even a WARN is given.
> Since in dfs.https.server.keystore.resource we know we need to have 4
> properties specified (ssl.server.truststore.location,
> ssl.server.keystore.location, ssl.server.keystore.password, and
> ssl.server.keystore.keypassword) we should check if they are set and throw an
> IOException if they are not.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
