http://chrislea.com/2009/09/09/easy-python-2-6-django-on-centos-5/

However, I run x86_64, and the RPMs are only in the i386 flavor. Thus I had to rebuild them, also, I use mod_wsgi instead of mod_python to run Django.

Thus, below is my YUM repository containing all of the x86_64 flavors of the RPMs, as well as the SRPMs. I had to make some changes to some of them, as well as updating Python to 2.6.5 (from 2.6.2).

Further, I had to compile many dependencies for our Django application. Hopefully this will be useful to someone!

http://dagobah.ftphosting.net/yum/

* Update 5/27/2010 *

The easiest way to install Python 2.6, if you have a CentOS 5.4 or 5.5 system is to simply install from my repository. To do that, you can install the repository like so:

# wget http://dagobah.ftphosting.net/yum/smartfile.repo -O /etc/yum.repos.d/smartfile.repo

Then you can use YUM to install python26 package:

# yum install python26

To get a list of available packages, do:

# yum list *python26*

If you need to install a python module that I have not already packaged, just do it as normal, except use the python26 binary…

# python26 setup.py install

Similarly, whenever you wish to use python 2.6, just use the following command or shebang.

# python26 /path/to/script.py

#!/usr/env python26

import os, sys ...

* Update 6/22/2010 *

Just a small update to show how to build additional python libraries for use with python26. I generally do it like this.

# python26 setup.py bdist_rpm --spec-only
# python26 setup.py sdist

At this point you have your source tarball and .spec file. You can edit the .spec file to put python26- into the package name, and replace the python commands with python26 commands. Ensure your source tarball is where rpm expects to find it, then build your RPM.

# rpmbuild -ba ????.spec

Some packages will require more fiddling, it just depends on how complex they are, but for the majority of packages, this is all I had to do.

The first problem I ran into with this setup is the nfsserver OCF resource agent that comes with Heartbeat is not suitable. This is because it works by stopping/starting the nfs server via it’s init script. For my situation, NFS will always be running, I just want to add/remove exports on failover.

Adding and removing exports is fairly easy under Linux, you use the exportfs command:

$ exportfs -o rw,sync,mp 192.168.1.0/24:/mnt/fs/to/export

The options correspond to those you would place into /etc/exports, and the rest is the host:/path portion, also as it would go into /etc/exports. To remove an export, you specify the following:

$ exportfs -u 192.168.1.0/24:/mnt/fs/to/export

Therefore what I needed was an OCF RA that managed NFS exports using exportfs. I wrote one and it is available here.

However there are two remaining issues.

The first is that when you export a file system via NFS, a unique fsid is generated for that file system. The client machines that mount the exported file system use this id to generate handles to directories/files. This fsid is generated using the major/minor of the device being exported. This is a problem for me, as the device being exported is a DRBD volume with LVM on top of it. This means that when the LVM OCF RA fails over the LVM volgroup, the major/minor will change. In fact, the first device on my system had a minor of 4. This was true of both nodes. If a resource migrates, it receives the minor 4, as the existing volgroup already occupies 4. This means that the fsid will change for the exported file system and all client file handles are stale after failover.

To fix this, each exported file system needs a unique fsid option passed to exportfs:

$ exportfs -o rw,sync,mp,fsid=1 192.168.1.0/24:/mnt/fs/to/export

Note that fsid=0 has special meaning in NFSv4, so avoid it unless you read the docs and understand it’s special use. I have taken care of this in my RA by generating a random fsid in case one is not already assigned. This random fsid is then written to the DRBD device, and used on the other node when the file system is exported. This way the fsid is both unique and persistent (remains same on other node after failover).

The other problem is that the /var/lib/nfs/rmtab file needs to be synchronized. This file contains the clients whom have mounted the exported file system. Again, I handle this in my RA by saving the relevant rmtab entries onto the DRBD device, and restoring them to the other node’s rmtab file. I also remove these entries from the node on which the resource is stopped.

This gives me a smooth failover of NFS from one node to the other and back again. To use my RA, simply install it onto your cluster nodes at:

/usr/lib/ocf/resources.d/custom/exportfs

Then you can create a resource using that RA, it requires three parameters.

1. exportfs_dir – the directory to export.
2. exportfs_clientspec – the client specification to export to (i.e. 192.168.1.0/24).
3. exportfs_options – the options as you would specify in /etc/exports.

If you provide an fsid in the exportfs_options param, that value will be honored, the random fsid is only generated when fsid is absent.

This seems to work perfectly on my cluster running CentOS 5.4, I tested using an Ubuntu 9.10 client.

** Update **

I posted a new version of the OCF RA. The problem being that it was only backing up rmtab when the resource is being stopped. Needless to say, this only covers the graceful failover scenario, if the service dies, the backup is never made. I have remedied this by spawning a process that continually backs up rmtab. This process is then killed when the resource is stopped. This should cover resource failures as well as graceful failovers.

** Update **

I have sent the RA to the linux-ha-dev mailing list for inclusion into heartbeat. I still have some code review items to finish, but I am close to wrapping that up. You can see the discussion at the URL below…

http://lists.linux-ha.org/pipermail/linux-ha-dev/2010-March/017244.html

Also, the updated version of the script (named exportfs) is in the Heartbeat mercurial repository below.

http://hg.linbit.com/florian/linux-ha/agents/

* Update 5/21/2010 *

This is now available in the official repository:

hg init
hg clone http://hg.linux-ha.org/agents/heartbeat/exportfs

I use a build machine, which happens to be a Xen VM. I needed to build the kernel module for a non-Xen machine. While the documentation at DRBD is very helpful, it does not cover this scenario, so I will do so here. The documentation I used is below.

http://www.drbd.org/users-guide/s-build-rpm.html

You are going to want to use the second option, where the make process creates .spec files for you and you then use the rpmbuild command to build the actual RPMs.

The rub is that you must edit the .spec file to point it to the correct kernel, on CentOS, you can obtain the necessary files by installing kernel-devel (or kernel-xen-devel if you want to build the xen flavor of the kernel module).

yum -y install kernel-devel

Then edit the .spec file and modify the kernelversion and kdir %defines.

# "uname -r" output of the kernel to build for, the running one
# if none was specified with "--define 'kernelversion '"
# PLEASE: provide both (correctly) or none!!
%{!?kernelversion: %{expand: %%define kernelversion 2.6.18-164.11.1.el5}}
%{!?kdir: %{expand: %%define kdir /usr/src/kernels/2.6.18-164.11.1.el5-x86_64}}

The version must match that of the kernel-devel package you installed. The path must also, you can find the path easily by using the following command:

 rpm -q --list kernel-devel | head

After that, you can build the RPM for your target kernel (not the running kernel).

rpmbuild -bb drbd-km.spec

http://rsmarketing.com/pgp/

This script is very useful, however, I prefer to use GPG over the PGP command line tool. Also, this script is based on the outdated v1.92 of the original formmail.pl script from Matt’s Script Archive.

So, I merged in the changes from v1.93, made the script work with GPG and also fixed a couple of perl warnings while I was at it. The updated script is available below.

http://ben.timby.com/pub/pgpformmail.pl.txt

response['Content-Disposition'] = 'attachment; filename=Espanél.txt'

Then you will get an exception from Django when it tries to encode the headers as ASCII. The Content-Disposition header must be fully ASCII, and there is no standard way to encode i18n characters into this header. At least none that browser vendors all implement. The solution is actually quite simple, it involves removing the header altogether and putting the filename into the URL. The browser will cherry-pick the filename from the URL if the Content-Disposition header does not provide one, thus:

http://mysite.com/download/path/to/Espanél.txt

Will get you the result you want. You can configure the URL like so in urls.py:

    (r'^download(?P<path>.*)$', 'project.app.views.download'),

Which will invoke project.app.views.download function and pass it the full path as a parameter. Your view can then do the following.

def download(request, path):
    bytes = os.path.size(path)
    download = file(path, 'r')
    response = HttpResponse(download.read())
    response['Content-Disposition'] = 'attachment;'
    response['Content-Length'] = bytes
    return response

First of all, you need mysql-server-5.1, so install it:

# sudo apt-get install mysql-server-5.1

And it’s sources:

# apt-get source mysql-server-5.1

Then you need to get the sphinx tarball, extract it and then copy the mysqlse directory into the storage/ directory within the mysql source directory.

# wget http://www.sphinxsearch.com/downloads/sphinx-0.9.8.1.tar.gz
# tar xzf sphinx-0.9.8.1.tar.gz
# cd mysql-dfsg-5.1-5.1.31/
# cp -R ../../sphinx-0.9.8.1/mysqlse storage/sphinx

For some reason, I could not configure mysql, it was missing the Docs/ directory, so I nabbed the tarball from MySQL and extracted Docs into my debian MySQL source tree.

# wget http://mysql.he.net/Downloads/MySQL-5.1/mysql-5.1.37.tar.gz
# tar xzvf mysql-5.1.48.tar.gz --wildcards '*/Docs/*' --strip=1 -C mysql-dfsg-5.1-5.1.41/

Now configure and make it, do NOT use the –with-plugins=sphinx switch for configure, I found a tutorial online that said to, but reading the help for ./configure –help reveals that this option will statically link the plugin into the mysqld executable. We want the plugin to be built dynamically. Also, you can do a simple make if you like, but I like to redirect the make output to a log file so I have record of any errors that may occur. I pulled most of the configure flags from the debian/rules file in the sources. These must match what the original mysqld was built with for the plugin to align correctly with the mysqld we installed above. You may also need to install some pre-requisites.

# sudo apt-get install automake autoconf libtool
# BUILD/autorun.sh
# ./configure   --prefix=/usr \
                --exec-prefix=/usr \
                --libexecdir=/usr/sbin \
                --datadir=/usr/share \
                --localstatedir=/var/lib/mysql \
                --includedir=/usr/include \
                --infodir=/usr/share/info \
                --mandir=/usr/share/man \
                --enable-thread-safe-client \
                --enable-local-infile \
                --with-pstack \
                --with-fast-mutexes \
                --with-big-tables \
                --with-unix-socket-path=/var/run/mysqld/mysqld.sock \
                --with-mysqld-user=mysql \
                --with-libwrap \
                --with-ssl \
                --without-docs \
                --with-extra-charsets=all \
                --with-embedded-server \
                --with-embedded-privilege-control
# make >&1 | tee build.log

You can optionally view sphinx specific build output by opening another terminal and tailing build.log

# tail -f build.log | grep sphinx

*snore*

Then install the plugin into your mysqld installed via apt.

# sudo mkdir /var/lib/mysql/plugins
# sudo cp storage/sphinx/libs/ha_sphinx.so* /var/lib/mysql/plugins/
# sudo chown -R mysql:mysql /var/lib/mysql/plugins
# sudo vi /etc/mysql/my.cnf
--
plugin_dir      = /var/lib/mysql/plugins
--

Ubuntu Intrepid uses apparmor to limit what binaries can be executed/loaded, so we have to tell apparmor about our new plugins directory:

# sudo vi /etc/apparmor.d/usr.sbin.mysqld
--
/var/lib/mysql/plugins/* mr,
--
# sudo /etc/init.d/apparmor restart
# sudo /etc/init.d/mysql restart

Now install the plugin into mysql.

# mysql -u root -p
INSTALL PLUGIN sphinx SONAME 'ha_sphinx.so';
Query OK, 0 rows affected (0.00 sec)

http://wiki.centos.org/HowTos/Xen/InstallingCentOSDomU

After installation, you are urged to use bootloader=”/usr/bin/pygrub”

However, trying to start the domU results in the error “Error: Disk
isn’t accessible”. A google search turns up speculation that this is
somehow pygrub’s fault, however, if one runs pygrub /dev/drbd0, it
works as expected.

The problem is in the xm utility, it attempts to resolve the disk name
(drbd0) into a device name (/dev/drbd0) by using the disk type (drbd).
However, it does not recognize the type drbd, so it fails to do so.
Attached is a patch that simply treats a drbd disk like phy and
returns “/dev/%s” % “drbd0″.

I realize that a resource (drbd0) may actually use a different device
node than /dev/drbd0, however, resolving this would require parsing
the drbd.conf file and also using the current host name to locate the
correct “on” section. I figure this patch is good enough to work for
most folks.

Here is the patch.

http://ben.timby.com/pub/azw-0.2.zip

The problem is that if you add/delete rules involving CLUSTERIP, eventually the kernel will panic. I could reproduce this every time by doing ’service iptables restart’. The box would then panic when ‘Applying iptables firewall rules:’. After some investigation, I found a patch for the problem and compiled my own kernel module.

• patch
• preparing kernel sources.
• compiling a kernel module.

Now CLUSTERIP is very stable. I plan to configure heartbeat to resize the cluster when a node fails. I will post my experience here as another follow up.