Kerberized Hortonworks Hadoop集群中无法通过CLI启动Apache Hive

Alright, let's dig into this issue—since Beeline runs fine but the Hive CLI throws that GSS initiate failure when connecting to the metastore, we can narrow down the problem to how the hive user authenticates directly to the metastore. Here's what to check and fix step by step:

1. Verify the Hive User's Kerberos Ticket #

First, when you switch to the hive user with su - hive, make sure that user has a valid Kerberos Ticket Granting Ticket (TGT) to authenticate against the metastore:

• Run this command to fetch a valid ticket (replace YOUR_KERBEROS_REALM with your actual realm, like EXAMPLE.COM):

  kinit -kt /etc/security/keytabs/hive.service.keytab hive/$(hostname -f)@YOUR_KERBEROS_REALM
  

• Confirm the ticket was issued successfully with:

  klist
  

  You should see an entry for the hive/your-hostname@YOUR_REALM principal. If not, double-check the keytab path and realm name. For convenience, add this kinit command to the hive user's ~/.bashrc so it runs automatically when you switch to the user.

2. Validate Metastore Kerberos Configuration #

Next, confirm your hive-site.xml has the correct Kerberos settings for the metastore:

• Ensure these properties are set properly:

  <property>
    <name>hive.metastore.kerberos.principal</name>
    <value>hive/_HOST@YOUR_KERBEROS_REALM</value>
  </property>
  <property>
    <name>hive.metastore.kerberos.keytab.file</name>
    <value>/etc/security/keytabs/hive.service.keytab</value>
  </property>
  <property>
    <name>hive.metastore.sasl.enabled</name>
    <value>true</value>
  </property>
  

• The _HOST placeholder should auto-resolve to your metastore host's fully qualified domain name (FQDN)—make sure this matches what hostname -f returns on hdpm1.
• Check keytab permissions: it should be owned by the hive user/group with strict access (chmod 400 /etc/security/keytabs/hive.service.keytab).

3. Fix Hostname Resolution Issues #

Kerberos is picky about hostname matching, so bad DNS or /etc/hosts entries often trigger GSS initiate failures:

• Run hostname -f to get your host's FQDN—this must exactly match the hostname in the metastore's Kerberos principal.
• Verify forward and reverse DNS resolution:

  # Forward lookup: confirm FQDN maps to correct IP
  nslookup $(hostname -f)
  # Reverse lookup: confirm IP maps back to FQDN
  nslookup $(hostname -i)
  

• If DNS is unreliable, add an entry in /etc/hosts for your FQDN and IP (ensure all cluster nodes can resolve this correctly).

4. Check Metastore URI and Service Status #

• Ensure the hive.metastore.uris property in hive-site.xml uses the metastore host's FQDN (not an IP or short hostname):

  <property>
    <name>hive.metastore.uris</name>
    <value>thrift://hdpm1.your-domain.com:9083</value>
  </property>
  

• Confirm the metastore service is running:

  sudo systemctl status hive-metastore
  # Or check via Ambari if you're using it to manage the cluster
  

• Test connectivity to the metastore port:

  telnet hdpm1.your-domain.com 9083
  

  If this fails, start the metastore service first with sudo systemctl start hive-metastore.

5. Quick Isolation Test #

If you've checked all the above, try this quick test to rule out credential issues:

1. As the hive user, run the kinit command from step 1 to get a valid ticket.
2. Start the metastore manually (in case the service didn't pick up the right credentials):

   hive --service metastore
   

3. In a new terminal, switch back to the hive user, run klist to confirm the ticket is valid, then launch the Hive CLI again.

内容的提问来源于stack exchange，提问作者user9314128