Let's say you want to build some 32-bit binaries for distribution but only have a 64-bit OS. You could try to set your build system up to make 32-bit builds, but if your build system is as complicated as ours is that sounds likely to go wrong. What if we just set up a 32-bit chroot? On Debian/Ubuntu this isn't very hard because this is how they generally build packages, and debootstrap and schroot can do most of the work for you. On CentOS/RHEL this is much more annoying, and I can't find anyone out there who has documented how to do this. So I figured I should at least write up what I did, in case someone (or me) later is trying to do the same thing:

# setarch is a command that lets you make uname lie and say it's 32-bit
sudo yum install setarch

CHROOT_DIR=/var/chroot/centos_i386
sudo mkdir -p $CHROOT_DIR
sudo mkdir -p $CHROOT_DIR/var/lib/rpm

# If there's a release since 5.10, you should update this url.
CENTOS_RPM_URL="http://mirror.centos.org/centos/5/os/i386/CentOS/"
CENTOS_RPM_NAME="centos-release-5-10.el5.centos.i386.rpm"
wget "$CENTOS_RPM_URL$CENTOS_RPM_NAME"

# When running on a 64-bit system, rpm will install 64-bit packages
# even if you set $arch and $basearch like you're supposed to.
# To force it to install 32-bit packages inside our chroot we have to
# change /etc/rpm/platform.  While this is changed, don't run any
# other system commands or they will get the architecture wrong.  I
# don't know why rpm doesn't use uname like everything else; then we
# could just use setarch.  For more details see this discussion.
sudo cp /etc/rpm/platform /etc/rpm/platform.real
echo i686-redhat-linux | sudo tee /etc/rpm/platform
sudo rpm --rebuilddb --root=$CHROOT_DIR
sudo rpm --root=$CHROOT_DIR --nodeps -i $CENTOS_RPM_NAME
sudo yum --installroot=$CHROOT_DIR/ update
sudo yum --installroot=$CHROOT_DIR/ install -y rpm-build yum
sudo mv /etc/rpm/platform.real  /etc/rpm/platform

# The base system is now installed on our chroot, and we've put the
# platform file back.

# Copying over resolv.conf makes networking work in the chroot.
$ sudo cp /etc/resolv.conf $CHROOT_DIR/etc/resolv.conf

# If you're setting up a chroot for security purposes, these next
# steps are a bad idea.  I'm just using chroot for a build environment
# so this is fine.  The users and groups within the chroot will be the
# same as the ones outside, with the same passwords, and sudo will work.
$ pushd $CHROOT_DIR/etc
$ sudo rm group passwd
$ for x in passwd shadow group gshadow hosts sudoers; do sudo ln /etc/$x; done
$ popd

# These mounts you'll need to do again on every reboot.  There's
# probably also a way to do this with /etc/fstab.
$ sudo mount -t proc proc $CHROOT_DIR/proc
$ sudo mount -t sysfs none $CHROOT_DIR/sys
$ sudo mount --bind /dev $CHROOT_DIR/dev
$ sudo mount -t tmpfs tmpfs $CHROOT_DIR/dev/shm

# Enter the chroot!
$ sudo setarch i386 /usr/sbin/chroot $CHROOT_DIR/ /bin/bash -l

# A few things to do now that we're in our chroot for the first time.
# First, delete any rpm database files.  Otherwise you'll get errors
# about them being corrput.  I think this is fine; as far as I can
# tell they just get regenerated when they're needed.
$ rm /var/lib/rpm/__db.00*

# Install sudo, which isn't in the base install.
$ yum install sudo

# Switch to yourself.
$ su yourusername

# Now make yourself a homedir and go there:
$ sudo mkdir $HOME
$ sudo chown $USER $HOME
$ cd ~

# Give yourself a prompt that reminds you you're in the chroot.
$ echo 'PS1='"'"'(32bit) \u@\h:\w\$ '"'" >> ~/.bashrc

# Things are set up now.
$ exit

# Whenever you want to get back into the chroot, just run:
$ sudo setarch i386 /usr/sbin/chroot $CHROOT_DIR/ /bin/bash -l
$ su yourusername