Skip to main content

Historical Impala Setup on RHEL 6 with Kerberos (Impala 0.3 Era)

By Anonymous
Struggling with delivery, architecture alignment, or platform stability?

I help teams fix systemic engineering issues: processes, architecture, and clarity.
→ See how I work with teams.


This is a historical walkthrough from the early Impala 0.3 beta days, showing how Impala was installed manually on RHEL 6, wired to Hive/HDFS configs, integrated with Kerberos using service principals and keytabs, and started via simple scripts. Treat it as a reference for understanding Impala’s components and legacy Kerberos patterns, not as a modern installation guide.

Note (2025): The commands, package names and versions in this article describe an Impala 0.3 beta setup on RHEL/CentOS 6 with Oracle JDK 6 and Cloudera’s early repos. Modern Impala deployments use different packaging, Java versions and security defaults. Use this only for maintaining or understanding legacy CDH-era clusters.

What Impala is (in this historical context)

Impala provides fast, interactive SQL directly on data stored in Apache Hadoop, primarily HDFS and HBase. It reuses:

  • The Hive Metastore and table metadata
  • Hive-compatible SQL syntax
  • ODBC/JDBC drivers and UI components (e.g. Hue Beeswax in early days)

This made it possible to run both batch-oriented Hive queries and low-latency Impala queries on the same data, using a shared schema and security model.

Historical install outline on RHEL/CentOS 6

In 2013, you could either build Impala from source or install beta packages from Cloudera’s repository on RHEL/CentOS 6. A minimal example repo file looked like: 

# /etc/yum.repos.d/impala.repo
[cloudera-impala]
name=Impala
baseurl=http://beta.cloudera.com/impala/redhat/6/x86_64/impala/0/
gpgkey=http://beta.cloudera.com/impala/redhat/6/x86_64/impala/RPM-GPG-KEY-cloudera
gpgcheck=1

After adding the repo you would install Impala and dependencies: 

yum install -y \
  impala impala-shell \
  cyrus-sasl-devel cyrus-sasl-gssapi \
  gcc-c++ gcc \
  python-setuptools

easy_install sasl

The early beta builds required a recent Oracle JDK alongside the cluster (for example jdk-6u37-linux-x64-rpm.bin). Because the Impala RPMs would also pull in OpenJDK, you had to point the system to the Oracle JDK using the alternatives mechanism: 

alternatives --install /usr/bin/java java \
  /usr/java/latest/jre/bin/java 20000
alternatives --install /usr/bin/javaws javaws \
  /usr/java/latest/jre/bin/javaws 20000

A quick check confirmed the expected JDK version: 

java -version
java version "1.6.0_37"
Java(TM) SE Runtime Environment (build 1.6.0_37-b06)
Java HotSpot(TM) 64-Bit Server VM (build 20.12-b01, mixed mode)

Checking native libraries for impalad

Impala’s daemon impalad links against several native libraries (JVM, HDFS, etc.). If any were missing from the standard library paths, you would see unresolved symbols in ldd output: 

ldd /usr/lib/impala/sbin/impalad

A typical workaround was to create symlinks into /usr/lib64/: 

ln -s /usr/java/jdk1.6.0_37/jre/lib/amd64/server/libjvm.so /usr/lib64/libjvm.so
ln -s /usr/java/jdk1.6.0_37/jre/lib/amd64/libjsig.so          /usr/lib64/libjsig.so
ln -s /usr/lib/impala/lib/libhdfs.so.0.0.0                    /usr/lib64/libhdfs.so.0.0.0

Once ldd showed all libraries resolved, Impala’s native components could start correctly.

Configuring Impala

Impala reuses the existing Hadoop and Hive configuration. In a simple setup you would copy the core Hadoop and Hive configs into Impala’s configuration directory: 

# Example IMPALA_HOME
IMPALA_HOME=/usr/lib/impala

cp /etc/hadoop/conf/core-site.xml  $IMPALA_HOME/conf/
cp /etc/hadoop/conf/hdfs-site.xml  $IMPALA_HOME/conf/
cp /etc/hive/conf/hive-site.xml    $IMPALA_HOME/conf/

Additionally, you needed a log4j.properties in $IMPALA_HOME/conf/: 

log.threshold=INFO
main.logger=FA
impala.root.logger=${log.threshold},${main.logger}

log4j.rootLogger=${impala.root.logger}
log.dir=/var/log/impala
log.file=impalad.INFO

log4j.appender.FA=org.apache.log4j.FileAppender
log4j.appender.FA.File=${log.dir}/${log.file}
log4j.appender.FA.layout=org.apache.log4j.PatternLayout
log4j.appender.FA.layout.ConversionPattern=%p%d{MMdd HH:mm:ss.SSS'000'} %t %c] %m%n

log4j.appender.console=org.apache.log4j.ConsoleAppender
log4j.appender.console.target=System.err
log4j.appender.console.layout=org.apache.log4j.PatternLayout
log4j.appender.console.layout.ConversionPattern=%d{yy/MM/dd HH:mm:ss} %p %c{2}: %m%n

A typical directory listing for /usr/lib/impala/conf looked like: 

ll /usr/lib/impala/conf/
total 24
-rw-r--r-- 1 root   root   1243 Dec 10 14:59 core-site.xml
-rw-r--r-- 1 root   root   4596 Sep  2 09:35 hdfs-site.xml
-rw-r--r-- 1 root   root   1157 Dec 10 10:36 hive-site.xml
-rw------- 1 impala impala  594 Dec 11 12:29 impala.keytab
-rw-r--r-- 1 root   root    647 Dec 11 12:31 log4j.properties

You would then sync this directory to all Impala nodes. To confirm the home directory used by the impala user: 

echo ~impala

Kerberos integration (historical pattern)

In a Kerberos-secured cluster, Impala runs with a service principal and keytab. One nuance with RHEL KDC packages at the time was that principals got a default renew_lifetime of zero: tickets were “renewable” in theory but could not actually be renewed.

To fix that, you had to adjust the krbtgt principal and the Impala service principal to have a non-zero max renew lifetime: 

kadmin.local: modprinc -maxrenewlife 1day krbtgt/ALO.ALT@ALO.ALT

kadmin.local: addprinc -randkey -maxrenewlife 1day +allow_renewable \
  impala/hadoop1.alo.alt@ALO.ALT

Next, export the keytab and place it into $IMPALA_HOME/conf: 

kadmin.local: xst -norandkey \
  -k impala.keytab \
  impala/hadoop1.alo.alt@ALO.ALT \
  HTTP/hadoop1.alo.alt@ALO.ALT

mv impala.keytab /usr/lib/impala/conf/impala.keytab
chown impala:impala /usr/lib/impala/conf/impala.keytab
chmod 600 /usr/lib/impala/conf/impala.keytab

To obtain a renewable ticket for the impala service: 

sudo -u impala kinit -r 1day \
  -k -t /usr/lib/impala/conf/impala.keytab \
  impala/hadoop1.alo.alt@ALO.ALT

Starting statestored and impalad (legacy script)

Before proper service scripts were integrated, a simple start script could wire together environment variables, Kerberos tickets and the Impala daemons: 

CONF=/usr/lib/impala/conf
USER=impala
PWD=$(echo ~$USER)
HOST=$(hostname)
REALM=ALO.ALT

export GLOG_minloglevel=0
export GLOG_logbuflevel=-1
export GLOG_log_dir=/var/log/impala
export GLOG_max_log_size=200

mkdir -p /var/log/impala
chown -R impala: /var/log/impala

# Obtain a fresh ticket for the impala service
sudo -u impala kinit -r 1day -k -t "$CONF/$USER.keytab" "$USER/$HOST@$REALM"

# Start statestored
statestored \
  -state_store_port=24000 \
  -enable_webserver=true \
  -webserver_port=25010 \
  -log_filename=impala-state-store \
  -principal="$USER/$HOST@$REALM" \
  -keytab_file="$CONF/impala.keytab" &

# Start impalad
impalad \
  -state_store_host=hadoop1.alo.alt \
  -nn=hadoop1.alo.alt \
  -nn_port=9000 \
  -hostname=hadoop1.alo.alt \
  -ipaddress=192.168.56.101 \
  -enable_webserver=true \
  -webserver_port=25000 \
  -principal="$USER/$HOST@$REALM" \
  -keytab_file="$CONF/impala.keytab" \
  -kerberos_ticket_life=36000 \
  -log_filename=impala &

With this script in place, starting Impala meant launching the statestore and at least one impalad with Kerberos authentication enabled.

Web UIs and metrics

Once running, both services exposed simple web UIs with metrics:

  • Statestore: http://<statestore-server>:25010
  • Impalad: http://<impala-server>:25000

Both endpoints provided basic monitoring pages and a /metrics endpoint that could be scraped for statistics.

Using impala-shell with Kerberos

On Kerberos-enabled clusters, impala-shell uses Kerberos tickets for authentication. The process was:

  1. Install Python SASL on the client host, for example via easy_install sasl.
  2. Obtain a Kerberos ticket for your user account (kinit).
  3. Run impala-shell with the -k option.

Example session:

[~]$ impala-shell -k
Using service name 'impala' for kerberos
Welcome to the Impala shell. Press TAB twice to see a list of available commands.

Copyright (c) 2012 Cloudera, Inc. All rights reserved.

(Build version: Impala v0.3 (3cb725b) built on Fri Nov 23 13:51:59 PST 2012)
[Not connected] > connect hadoop1:21000
[hadoop1:21000] > show tables;
hbase_test
hbase_test2
hivetest1
hivetest2
[hadoop1:21000] >

Today this is mainly interesting as a snapshot of how early Impala clusters were brought up and secured, but the overall concepts—service principals, keytabs, ticket renewal and client-side SASL—remain relevant in modern Kerberized data platforms.

Related guides:

If you need help with distributed systems, backend engineering, or data platforms, check my Services.

Labels:

Most read articles

Building a Model-Agnostic Multi-Agent System with OpenClaw

By
Over one week we rebuilt our AI stack around OpenClaw’s multi-agent architecture to avoid provider lock-in and stop wasting premium tokens. By aligning models to tasks, diversifying fallbacks across providers, enforcing minimal tool access, and switching to memory-first workflows with ephemeral sessions, we reduced token usage per task by about 70% and cut our monthly bill by 77% while improving operational resilience. How We Achieved 77% Cost Reduction and Provider Independence Over the past week, we rebuilt our AI infrastructure around OpenClaw’s multi-agent architecture. The result was a 77% cost reduction , provider independence , and a delegation system that routes work to the most cost-effective model for each job. Below is the technical journey of optimizing a 7-agent squad with OpenClaw. The Challenge: Model Provider Lock-In We started with a simple problem: our entire squad defaulted to a single model provider. This created three issues: Cost inefficiency beca...
Read more

BacNet => MQTT in Production: The Real Cost of Bridging BACnet to MQTT at Scale

By
bacnet2mqtt looks simple in a README and expensive in production. Once BACnet polling, reconnection behavior, stale state, and MQTT publishing collide, teams discover they are not deploying a lightweight adapter but operating infrastructure. This article breaks down where bacnet2mqtt works, where it becomes a bottleneck, and which production patterns reduce the operational damage before incidents, backlogs, and silent data loss turn a building integration into a long-running engineering problem. I inherited a building controls integration problem 18 months ago. Three office floors. 217 BACnet sensors covering temperature, occupancy, and HVAC actuators. The data was trapped inside the building automation network while the business wanted analytics, reporting, and compliance visibility in the data platform. The obvious answer looked easy enough: deploy bacnet2mqtt, bridge BACnet into MQTT, and push the stream into the lakehouse stack. The repository made it sound like a w...
Read more

Get Apache Flume 1.3.x running on Windows

By Anonymous
Since we found an increasing interest in the flume community to get Apache Flume running on Windows systems again, I spent some time to figure out how we can reach that. Finally, the good news - Apache Flume runs on Windows. You need some tweaks to get them running. Prerequisites Build system: maven 3x, git, jdk1.6.x, WinRAR (or similar program) Apache Flume agent: jdk1.6.x, WinRAR (or similar program), Ultraedit++ or similar texteditor Tweak the Windows build box 1. Download and install JDK 1.6x from Oracle 2. Set the environment variables    => Start - type " env " into the search box, select " E dit system environment variables ", click Environment Variables, Select " New " from the " Systems variables " box, type " JAVA_HOME " into " variable name " and the path to your JDK installation into "Variable value" (Example:  C:\Program Files (x86)\Java\jdk1.6.0_33 ) 3. Download maven from Apache 4. Set...
Read more