RackTables: a PHP and MySQL cabinet for racks, servers and IP addresses

A cabinet, not a monitoring system

RackTables presents itself as a datacenter management solution, and the repository topics narrow that to dcim and ipam, datacenter infrastructure management and IP address management. So the question it answers is what physical and logical assets exist, where they are, and how they are connected, not how they are performing. The README is a welcome rather than a description: it thanks you for selecting RackTables as your datacenter management solution and points you at the project website for documentation and feedback. The README itself is almost entirely installation instructions, which is a fair signal about what kind of software this is. It is a database with a web front end, aimed at the person who has to answer questions like which server owns this IP address, or which rack a machine is in, without grepping spreadsheets.

PHP on a web server, MySQL or MariaDB behind it

The architecture is two-tier and unremarkable in the best way. RackTables uses a web-server with PHP for the front end, where PHP 7.0 is the minimum required version, 7.1 is the minimum tested version and 7.3 is the recommended version, and a MySQL or MariaDB server version 5 or later for the back end. The most commonly used web server for RackTables is Apache httpd, though the installation notes cover nginx as well. The practical consequence is that deploying it is a job of configuring an existing web stack rather than learning a new one, and the data ends up in a database you can query with the tools you already have. The version numbers in the README are the first thing to look at, because a PHP 7.0 floor and a 7.3 recommendation are both well behind current releases, and the distribution tables reflect a period when those were current.

The install tables read like a time capsule

The installation section is a series of per-distribution tables, and the versions they mention date the document precisely. The MySQL or MariaDB table covers Debian 11-12, Ubuntu 20.04, 22.04 and 24.04, RHEL 7 and FreeBSD 10, with the command for each. There is a separate step to enable Unicode in the database, where Debian and Ubuntu need no action because they come configured for UTF-8 by default, while on RHEL 7 you add a character-set-server=utf8 line to the [server] section of /etc/my.cnf.d/server.cnf and restart mysqld. The PHP and Apache section installs apache2-bin, libapache2-mod-php, php-gd, php-mysql, php-mbstring, php-bcmath, php-json and php-snmp on Debian and Ubuntu. The RHEL 7 row goes through subscription-manager to enable the rhscl repository and installs httpd24 with a list of rh-php70 packages. Two numbered subsections are marked no longer applies, which tells you the document accreted rather than being rewritten.

Unpack, point a DocumentRoot at wwwroot, and run the installer

The sequence is straightforward. You unpack the tar.gz or zip archive to a directory of your choice and configure Apache httpd to use the wwwroot subdirectory as a new DocumentRoot, or alternatively symlinks to wwwroot or even to index.php from an existing DocumentRoot are possible and often advisable, with a pointer to README.Fedora. Then you open the configured RackTables URL and you are prompted to configure and initialize the application. The distribution table that follows maps the Apache httpd UID and GID to the MySQL or MariaDB socket path, with www-data:www-data on Debian and the Ubuntu releases and /run/mysqld/mysqld.sock on the newer ones, and /var/run/mysqld/mysqld.sock on Ubuntu 20.04. Getting those two values right is what determines whether the installer can create its schema, so it is the part of the setup to check first when the browser step hangs. On Debian and Ubuntu the database and the web stack are two commands:

apt-get install mariadb-server
apt-get install apache2-bin libapache2-mod-php php-gd php-mysql php-mbstring php-bcmath php-json php-snmp && systemctl restart apache2

The FreeBSD path adds one security step: when prompted, set permissions on secret.php with chown www:www and chmod 400 on the file.

Upgrading means replacing files but keeping two directories

The upgrade procedure is where a self-hosted PHP application either earns trust or loses it, and RackTables is unusually clear here. Step zero is to back up your database and check the release notes before actually starting. Then you remove all existing files except the configuration, which is the inc/secret.php file, and local plugins in the plugins/ directory. You put the contents of the new archive into the place. Then you open the RackTables page in a browser, and the software will detect a version mismatch and display a message telling you to log in as admin to finish the upgrade. You do that, and report any errors to the bug tracker or the mailing list. The key insight is that the two things that survive an upgrade are the database, which you back up yourself, and secret.php, which holds whatever local configuration the instance accumulated. The repository layout matches this, with a plugins/ directory and a wwwroot/ directory that holds the application.

Gateways and plugins are the extension points

Two directories in the repository tell you how the project is meant to grow. The gateways/ directory sits alongside scripts/, and the Makefile installs them together as helpers into the script directory, stripping the .git directories out of the copies. The plugins/ directory is the local extension point that survives an upgrade, which means a site-specific behaviour goes there rather than into the core files. The wwwroot/ directory holds the actual application, and the Makefile splits it into three installed pieces: static assets, the inc/ application library and the index.php entry point, with a configurable prefix defaulting to /usr/local and a shared-deploy option so the filesystem can be split across locations. The Makefile also installs the COPYING, ChangeLog, LICENSE and README.md files as documentation. For an adopter this means the extension story is plugins and gateways, not patches to the core, which is the arrangement that makes the file-replacement upgrade procedure safe.

A GPL project with a quiet release history in this repository

The licence is GPL-2.0, with COPYING and LICENSE files at the root. That is worth pausing on for internal deployment: a copyleft licence on a self-hosted application is a different question from a permissively licensed library you link against, and your legal team should look at it rather than assume. On maintenance, the picture needs reading carefully. The repository is not archived and the last push was on 2026-06-26. There are no GitHub releases in this repository, and the release notes section in the README is short and historical, with the most recent entry covering the upgrade to 0.22.0 and the note that the minimum supported PHP version is 7.0 as of that release. The README points at the project website for documentation and feedback, so the current documentation and release notes live upstream rather than here. The repository is described as the current development repository, which tells you it is the trunk and not a mirror of a stable branch.

Editorial conclusion

Adopt RackTables if you run a small or mid-sized datacenter and want a rack, server and IP inventory that a web browser can query, with the data in a MySQL database you control. Do not adopt it if you need an API-first platform, a modern UI, or a change log that reflects recent work, because the last push was on 2026-06-26 and the release notes in the README stop at version 0.22.0. Before you commit, read the upstream documentation on racktables.org, plan the upgrade path around backing up the database, and check whether the PHP version floor still matches your distribution.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. Project website
4. RackTables/racktables on GitHub
5. README