Graphite for RHEL 5.7

November 1, 2011 – 8:14 pm

Graphite install for RHEL 5.7 from scratch.

Official Graphite documentation is at http://graphite.readthedocs.org/

export PATH=/usr/bin:/bin:/usr/sbin:/sbin
mkdir -p /graphite/src
cd /graphite/src

# Download Python 2.7.x source from python.org
# Unpackage

cd Python-2.7.2
./configure --prefix=/graphite
make
make install
cd ..

# Now make sure you get your python before RHEL's

export PATH=/graphite/bin:$PATH

# Download Django 1.x source from django.org
# Unpackage

cd Django-1.3
python setup.py install
cd ..

# Download django-tagging from http://code.google.com/p/django-tagging/
# Unpackage

cd django-tagging-0.3.1
python setup.py install
cd ..

# Download Twisted 11.x source here from http://twistedmatrix.com/
# Unpackage

cd Twisted-11.0.0
python setup.py install
cd ..

# Download setuptools from http://pypi.python.org/pypi/setuptools
# Unpackage

cd setuptools-0.6c11
python setup.py install
cd ..

# Download pip from http://pypi.python.org/pypi/pip
# Unpackage

cd pip-1.0.2
python setup.py install
cd ..

# Now you have to build the Cairo graphics library, as RHEL's
# is too old for py2cairo's needs.

# Start with pixman, a dependency for building cairo!

# Download pixman from http://www.cairographics.org/releases/
# Unpackage

cd pixman-0.22.2
./configure --prefix=/graphite
make
make install

# Download cairo from http://www.cairographics.org/releases/
# Unpackage

cd cairo-1.10.2
# Make sure we find our shit and don't have runtime linker problems
export LDFLAGS="-L/graphite/lib -Xlinker -rpath -Xlinker /graphite/lib"
# PKG_CONFIG_PATH is set below so pixman is found
export PKG_CONFIG_PATH=/graphite/lib/pkgconfig
# Turn off all the X shit and gobject since RHEL glib2 is too old
./configure --prefix=/graphite --without-x --enable-xlib=no \
    --enable-xlib-xrender=no --enable-xcb-shm=no --enable-qt=no \
    --enable-gl=no --enable-gobject=no
make
make install

# Download Pycairo (aka py2cairo) from http://www.cairographics.org/pycairo/
# Unpackage

# Had to add these to LDFLAGS or ./waf configure bombs on Python.h test
# due to not including them when it should be in its test
export LDFLAGS="$LDFLAGS -lm -ldl -lutil"
cd py2cairo-1.10.0
./waf configure --prefix=/graphite
./waf build
./waf install
cd ..

# Download carbon, whisper, and graphite-web from
# https://launchpad.net/graphite
# Unpackage

cd whisper-0.9.9
python setup.py install
cd ..

cd carbon-0.9.9
python setup.py install
cd ..

cd graphite-web-0.9.9
./check-dependencies.py # Ignore WARNINGs as you see fit
python setup.py install
cd ..

Explaining Syslog to RH Support

November 1, 2011 – 1:06 pm

Were my expectations too high?

Support, what RHEL service is logging this?  rhnsd?  yum-updatesd?
It should show the process name in the syslog output.  Please fix?

Oct 27 10:00:04 rcf-monitor : 4 updates available

Response:

I think that rfc-monitor is likely a third-party service of some sort. I haven’t been able to find any mention of it internally or any package or file with that name on RHN. So I don’t think that’s yum or rhnsd talking. 

Support,

Syslog logs the hostname.  rcf-monitor is the hostname.

Proper syslogging looks like this, where you will note
"ntpd" as the service responsible for generating the
syslog line.

Nov  1 03:52:51 rcf-monitor ntpd[27018]: message here...

twm Shirt

August 26, 2011 – 10:18 pm

Paying homage to the classic Tab/Tom’s Window Manager, it’s the twm shirt, available with no markup in cost toward my wallet.

Designed by yours truly. If you’d like to do something else with the design, here it is in multiple formats, and I’d love to hear if you liked it.

Adjusting a PostgreSQL Sequence

August 8, 2011 – 3:58 pm

I recently had the unfortunate task at work of copying most of a production PostgreSQL database to a development server. The whole database would have been simple. It’s the “most of” part that made things messy. At any rate, I ended up in a position where I needed to make various incorrect “sequence” definitions match their respective tables. For example, the maximum id in table principals was 18133 and the sequence used for that primary key was currently at, well, 1.

I’d never ever delved into this sort of thing before (I had to look up what a PostgreSQL sequence was) as I’m not a DBA by trade. I also won’t likely have to do this again for quite some time, so here are my notes:

Query the last value for the sequence (well call this SEQLAST below, and assume it returned 3):

SELECT last_value FROM mytable_sequence;

Query for the largest id (our primary key, we’ll call this LARGESTID below and assume it returned 18133):

SELECT id FROM mytable ORDER BY id DESC;

If SEQLAST and LARGESTID match, you’re all set. If they don’t, you need to adjust mytable_sequence so that the next primary key issued is LARGESTID + 1 for mytable. You do this with the setval sequence function.

SELECT setval('mytable_sequence', 18133);

This reads as, “Set the last value of mytable_sequence to 18133 and increment before handing out the next number when nextval() is called for this sequence.” The incrementing is implied, though you could also specify the clearer and functionally equivalent statement via:

SELECT setval('mytable_sequence', 18133, true);

You could also specify “Set the next value of mytable_sequence to 18134 and do not increment before handing out the next number when nextval() is called for this sequence.”

SELECT setval('mytable_sequence', 18134, false);

Reference: Google Search: site:postgresql.org postgresql setval

The First InterOp

August 7, 2011 – 4:08 pm

I wasn’t aware of this and thought it was cool.

From The Robustness Principle Reconsidered:

The original InterOp conference was intended to allow vendors with Network File System (NFS) implementations to test interoperability and ultimately demonstrate publicly that they could interoperate. The first 11 days were limited to a small number of engineers so they could get together in one room and actually make their stuff work together. When they walked into the room, the vendors worked mostly against only their own systems and possibly Sun’s (since as the original developer of NFS, Sun had the reference implementation at the time). Long nights were devoted to battles over ambiguities in the specification. At the end of those 11 days the doors were thrown open to customers, at which point most (but not all) of the systems worked against every other system. By the end of that session the NFS protocol was much better understood, many bugs had been fixed, and the standard was improved. This is an inevitable path for implementation-driven standards.