"TSocket read 0 bytes" using Hue+Impala+Kerberos on CDH5.0.1

[#1]

First of all, I want to configuring Kerberos for Impala only, instead of the whole cluster. Is this possible? If not I should redo everything and please ignore the following.

CDH was installed using Parcels. Impala+Kerberos configuration was OK, following
http://www.cloudera.com/content/cloudera/en/documentation/cdh5/v5-0-0/Impala/Installing-and-Using-Im...

All steps were done except proxy server. I also configured HTTP SPNEGO on Chrome and Firefox, but got no "Authorization:" response header using Hue.

For configuring Hue to connect to Impala, I followed steps 1-3, and 5-7 of
http://www.cloudera.com/content/cloudera/en/documentation/cdh5/v5-0-0/CDH5-Security-Guide/cdh5sg_hue...

(actually steps 5-7 were the default values)

Step 4 seemed incorrect. Instead of following it, I've configured hue_safety_valve.ini as

[desktop]

[[kerberos]]
# Path to Hue's Kerberos keytab file
hue_keytab=/etc/hue/hue.keytab
# Kerberos principal name for Hue
hue_principal=hue/hue_hostname.mydomain.com@MYREALM.com
# add kinit path for non root users
kinit_path=/usr/bin/kinit

[impala]
impala_principal=impala/hue_hostname.mydomain.com@MYREALM.com
impersonation_enabled=False
server_host=hue_hostname.mydomain.com

[beeswax]
hive_server_host=hue_hostname.mydomain.com

(I have impalad running on hue_hostname.mydomain.com... Actually do I really need to use ## , or it denotes comment??)

Hue "/impala" page showed error message "TSocket read 0 bytes". In /var/log/hue/runcpserver.log, messages like the following were found:

[03/Nov/2014 21:53:34 -0800] connectionpool INFO Starting new HTTP connection (1): hue_hostname.mydomain.com
[03/Nov/2014 21:53:34 -0800] connectionpool INFO Starting new HTTP connection (1): hue_hostname.mydomain.com
[03/Nov/2014 21:53:34 -0800] connectionpool INFO Starting new HTTP connection (1): hue_hostname.mydomain.com
[03/Nov/2014 21:53:34 -0800] hive_server2_lib INFO use_sasl=False, mechanism=GSSAPI, kerberos_principal_short_name=impala, impersonation_enabled=False
[03/Nov/2014 21:53:34 -0800] thrift_util INFO return from get_client
[03/Nov/2014 21:53:34 -0800] thrift_util INFO Thrift exception; retrying: TSocket read 0 bytes
[03/Nov/2014 21:53:34 -0800] thrift_util INFO Thrift exception; retrying: TSocket read 0 bytes
[03/Nov/2014 21:53:34 -0800] thrift_util WARNING Out of retries for thrift call: GetSchemas
[03/Nov/2014 21:53:34 -0800] thrift_util INFO Thrift saw a transport exception: TSocket read 0 bytes
[03/Nov/2014 21:53:44 -0800] access INFO 192.168.12.34 admin - "GET /desktop/debug/check_config HTTP/1.1"
[03/Nov/2014 21:53:44 -0800] connectionpool INFO Starting new HTTP connection (1): hue_hostname.mydomain.com
[03/Nov/2014 21:53:44 -0800] connectionpool INFO Starting new HTTP connection (1): hue_hostname.mydomain.com
[03/Nov/2014 21:53:44 -0800] access INFO 192.168.12.34 admin - "GET /jobbrowser/ HTTP/1.1"
[03/Nov/2014 21:53:45 -0800] thrift_util INFO Thrift exception; retrying: TSocket read 0 bytes
[03/Nov/2014 21:53:45 -0800] thrift_util INFO Thrift exception; retrying: TSocket read 0 bytes
[03/Nov/2014 21:53:45 -0800] thrift_util WARNING Out of retries for thrift call: GetSchemas
[03/Nov/2014 21:53:45 -0800] thrift_util INFO Thrift saw a transport exception: TSocket read 0 bytes

(192.168.12.34 is IP address of hue_hostname.mydomain.com. Web access were using IP address)

It seems quite obvious that Hue failed to connect to Impala. And I think besides impala_principal, Hue need something more to connect (something like a password, keytab, kerberos cache???). But the documentation seems included nothing similar. What am I missing?

[#2 · Accepted solution]

AFAIK, about Kerberos, all the services should use it or not, you can't
just have only Impala use it.

Hue needs a Kerberos ticket too that way it can authenticate with Impala.

Romain

[#3]

Then I will complete enabling Kerberos for whole cluster first. Thanks.

[#4]

As a follow up, I configured Hadoop Security within Cloudera Manager following http://www.cloudera.com/content/cloudera/en/documentation/cloudera-manager/v5-0-0/Configuring-Hadoop...

Things seems OK.

The biggest problem I faced when configuring Security in CM was I attempted a non-default realm. This triggered a bug and so that the configuration failed, as speciifed in step 6.

I found no such warning in http://www.cloudera.com/content/cloudera/en/documentation/cdh5/v5-0-0/CDH5-Security-Guide/CDH5-Secur... (or I overlooked). Wondering whether this caused my original failure.