Ganglia Installation

Ok, I will save you a lot of trouble by telling you right now that, at the time of writing this blog you should compile your own RPM from the tarball available on sourceforge with the following statment:

rpmbuild -ta --target=x86_64,no_arch ./ganglia-3.1.7.tar.gz

You will need some extra binaries from EPEL on your machine in order to compile the RPM, including expat-devel, apr-devel, libconfuse-devel, rpm-build, and some others depending on your base CentOS 5 install.

Take these RPMs, and distribute them to all of the nodes in your cluster, or puppet it up for those that are savvy enough now to do so. Careful of the rpm provider, as there is a bug in it for now with already installed RPMs.

For a node:

rpm -i libganglia-3.1.7-YOUARCH.rpm ganglia-gmond-3.1.7-YOURARCH.rpm ganglia-gmond-modules-python-3.1.7-YOURARCH.rpm

For the front-end:

rpm -i libganglia-3.1.7-YOURARCH.rpm ganglia-gmetad-3.1.7-YOURARCH.rpm ganglia-web-3.1.7-noarch.rpm

Configure your /etc/ganglia/gmetad.conf with a *single* new data_source line for all of your nodes in the cluster, start your services and you are off to the races.

Trust me when I say that installing from the current yum repositories (base and EPEL) is a complete and total waste of your time.

Puppet to Manage Your Hadoop Cluster

Ok, I'm sure everyone has heard about how important it is to have a configuration management system up and running for your Hadoop cluster. This can't be understated enough. I have 4 machines right now, and I already HATE copying files manually between the different machines.

That said, everywhere I go, Puppet seems to be the utility of choice for this task.
http://www.puppetlabs.com

Again, I'm using CentOS (version 5.5 at the time of this writing), so you should download the RPM packages (common, client, and server) from puppetlabs and install from there.

Depending on what else you have done to this system, you may not have a repository configured that has rubygems(-stomp) available via YUM. If you get the following error, then refer to the next section, otherwise skip on down a few lines:

No package rubygems available.

In order to get the rubygems-stomp dependency out of the way, perform the following steps excerpt from http://www.threedrunkensysadsonthe.net/2010/04/mcollective-on-centos/

Enable ELFF

rpm -Uvh http://download.elff.bravenet.com/5/i386/elff-release-5-3.noarch.rpm

Install ruby and dependencies

yum -y install rubygems rubygem-stomp

A great start is to read the configuration docs:
http://docs.puppetlabs.com/guides/configuring.html

Active Directory/LDAP and Pig

So, in order to connect the Staging server to our Active Directory for user authentication, I simply used LikeWise-Open, which can be downloaded, and easily installed from http://www.likewise.com/download/index.php

Running the CLI utility was a breeze and only requires a Domain Admin account and a reboot to succeed.

I'm going to assume that the machine you are attempting to get this going on has Sun's Java 6. I have u22 x64 installed from the rpm I downloaded from sun.com.

Now we can log in with our LDAP accounts. Great, but we have no permissions. What next?

Fortunately for me, Hive worked straight away, and was automatically connecting to the cluster's HDFS. So I'm good there. Created a table and it showed up in Hue under the proper user/group.

BTW, use Hue for all of your HDFS exploration tasks, it is so much easier than typing 'hadoop fs -ls /', and then 'hadoop fs -ls /' to find your way through the tree!

To get Pig to run successfully in such a limited user account on linux, we need to set JAVA_HOME with the following lines, but where?

JAVA_HOME=/usr/java/latest
export JAVA_HOME

Adding this line to each user's ~/.bash_profile or ~/.bashrc doesn't take automatically because when an LDAP user logs in, they are not going to be running BASH (assuming you are running CentOS 5x). We need to have this export set globally, so simply add the above two lines to /etc/profile (anywhere). Have an LDAP user log in again and make sure that it works.

You *could* also set up each user to have /bin/bash as its default bash by adding them to the /etc/passwd file, but this does not scale well with the increase in the number of users that *will* be accessing the system.

OINK OINK!!