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 > krb5andcertssslsocketconnec...@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