hadoop-common-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Evert Lammerts <Evert.Lamme...@sara.nl>
Subject FW: NullPointer during startup & debugging DN
Date Wed, 29 Feb 2012 10:20:48 GMT
Cross-posting with common-user, since there's only little activity on hdfs-user these last
days.

Evert


> Hi list,
>
> I'm having trouble starting up a DN (0.20.2) with Kerberos
> authentication and SSL enabled - I'm getting a NullPointerException
> during startup and the daemon exists. It's a bit hard to debug this
> problem, no idea how I'd do this from within Eclipse for example. Can I
> do this with jdb?
>
> Some background (also see relevant snippets from debug output, hdfs-
> site, core-site and ssl-server attached):
>
> 12/02/21 11:24:11 DEBUG security.Krb5AndCertsSslSocketConnector:
> useKerb = false, useCerts = true jetty.ssl.password :
> jetty.ssl.keypassword : 12/02/21 11:24:11 INFO mortbay.log: jetty-
> 6.1.26.cloudera.1
> 12/02/21 11:24:11 INFO mortbay.log: Started SelectChannelConnector@p-
> worker02.alley.sara.nl:1006
> 12/02/21 11:24:11 DEBUG security.Krb5AndCertsSslSocketConnector:
> Creating new KrbServerSocket for: p-worker02.alley.sara.nl
> 12/02/21 11:24:11 WARN mortbay.log: java.lang.NullPointerException
> 12/02/21 11:24:11 WARN mortbay.log: failed
> Krb5AndCertsSslSocketConnector@p-worker02.alley.sara.nl:50475:
> java.io.IOException: !JsseListener: java.lang.NullPointerException
>
> I'm a bit surprised that useKrb is set to false in
> Krb5AndCertsSslSocketConnector, but looking at
> org.apache.hadoop.hdfs.server.datanode.DataNode is see that it calls
> this.infoServer.addSslListener(secInfoSocAddr, sslConf,
> needClientAuth), which sets needKrbAuth to false. I guess this is on
> purpose then, and the values in core-site are just ignored here.
>
> The NullPointer seems to occur at
> org.apache.hadoop.security.Krb5AndCertsSslSocketConnector, in
> newServerSocket(). useCerts is true, and I see a call
> (SSLServerSocket)super.newServerSocket(host, port, backlog). I think
> things might go wrong here.
>
> This is probably due to some missing configuration. I have not set
> dfs.https.need.client.auth, and it defaults to false so I have not
> included a ssl-client.xml configuration file or key- and truststores
> for clients. I wouldn't mind doing that, but I'm not sure why I need a
> keystore for clients -  I guess the framework checks for DN-to-user
> mappings, it shouldn't need user keys.
>
> Any help is much appreciated!
>
> Evert


Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message