A practical guide to setting up a chroot environment for testing on CentOS

Spinning up a quick chroot jail on a CentOS workstation lets you isolate risky binaries, replicate a customer's broken configuration, or validate a package upgrade without contaminating the host. The technique works especially well when you need to reproduce a bug that only shows up under a specific glibc or library combination, and it costs nothing more than a folder of files and a few bind mounts. For Australian sysadmins working from Brisbane or Perth, it also offers a tidy way to rehearse change windows before pushing to production kit sitting in a Sydney colocation rack.

Before you begin, make sure the host runs CentOS 7 or 8 with yum available, that you have sudo access, and that you can reach a local or AARNet-connected mirror. The whole process takes around fifteen minutes if your package cache is warm, and the result is a reusable sandbox you can throw away and rebuild in seconds.

Prerequisites and workspace setup

Start by creating a working directory somewhere with at least a gigabyte free. Many local shops standardise on /opt/sandbox for this kind of testing because it keeps the jail away from application data and aligns with the Essential Eight maturity goals promoted by the Australian Cyber Security Centre. Install the packages you will need on the host side first, including yum-utils, which provides the yumdownloader command that pulls RPMs without forcing a permanent install.

sudo mkdir -p /opt/sandbox/centos-test
sudo yum install -y yum-utils bash coreutils

While you are here, double-check the architecture. Mixing x86_64 and aarch64 binaries in the same jail is a common trip-up, especially on labs built around leftover Mac mini hardware. Run uname -m on the host and stick with packages from the matching base repository.

Constructing the minimal root filesystem

A chroot only needs a handful of directories and files to feel like a working Linux system. The trick is to populate them with binaries and shared libraries that match the CentOS release you intend to mimic. yumdownloader --resolve does the heavy lifting by calculating dependencies and fetching every required RPM into a single folder.

cd /opt/sandbox/centos-test
sudo yumdownloader --installroot=/opt/sandbox/centos-test --releasever=8 --resolve bash coreutils yum dnf

Once the downloads finish, extract each RPM into the target tree. The rpm2cpio piped through cpio -idmv pattern works even when you cannot install yum directly into the jail, which is helpful when you are behind a corporate proxy that filters NBN traffic or a Telstra-managed link. You can also use rpm --root /opt/sandbox/centos-test -ivh *.rpm if a working rpm binary is already available inside.

Mounting virtual filesystems for the jail

A bare chroot without /proc, /sys and /dev behaves strangely. Commands that read process information, query hardware, or check mount points will return empty or misleading results, which can mask the very bugs you are trying to reproduce. Bind-mounting the host's virtual filesystems into the jail restores enough realism for most troubleshooting tasks without compromising host security.

sudo mount -o bind /proc /opt/sandbox/centos-test/proc
sudo mount -o bind /sys /opt/sandbox/centos-test/sys
sudo mount -o bind /dev /opt/sandbox/centos-test/dev
sudo cp /etc/resolv.conf /opt/sandbox/centos-test/etc/

The resolv.conf copy matters when you intend to reach external mirrors from inside the jail. Australian sites that route through aarNet.edu.au or local mirrors at mirror.aarnet.edu.au will resolve correctly as long as the nameserver entries survive. Without this step, dnf inside the jail will hang trying to reach the nearest baseurl.

Executing and troubleshooting inside the jail

Enter the sandbox with sudo chroot /opt/sandbox/centos-test /bin/bash. From here, the prompt looks identical to a normal CentOS session, but the filesystem tree is sealed off. You can install additional packages with dnf, recompile a service against an older glibc, or run a suspect binary to see what it actually does. This is a tidy place to rehearse web server configuration tweaks, since misconfigured Nginx directives will fail inside the jail instead of taking down the host.

If a command fails with "No such file or directory" yet the file is plainly visible, you are almost certainly missing a shared library. ldd /usr/bin/yourbinary inside the jail lists what is missing, and copying the required .so from the host's /usr/lib64 or /lib64 into the matching path inside the sandbox usually fixes it. Keep notes on what you added so you can rebuild the environment deterministically next time.

Tearing down safely

When you finish a session, leave the chroot cleanly so the host's mount table does not leak. The simplest routine is to exit the shell, then unmount the virtual filesystems in reverse order before removing the working tree. Avoid rm -rf while the bind mounts are still attached, as you may end up deleting files from the host's real /proc or /sys.

sudo umount /opt/sandbox/centos-test/proc
sudo umount /opt/sandbox/centos-test/sys
sudo umount /opt/sandbox/centos-test/dev
sudo rm -rf /opt/sandbox/centos-test

Once the unmounts succeed, decide whether to keep the sandbox or discard it. If you intend to keep it around for next time, snapshot the directory with tar -czpf centos-test-template.tar.gz -C /opt/sandbox centos-test before removing the working tree. Storing that tarball in your usual artefact repository means the next test cycle starts from a known-good baseline.

The approach rewards repetition: once the routine is scripted, future reproductions run identically whether you are working from a Melbourne office at 9am AEST, a home lab in Adelaide after hours, or a remote desk in Hobart. Keep the script, keep the template, and you can rebuild a clean chroot in under a minute whenever an odd bug lands on your desk.