Discontinued features

Features BOA no longer ships. This page exists so the project history stays discoverable and operators searching for old terms find the explanation rather than dead links.

Simple Cluster

BOA Simple Cluster (Percona XtraDB Cluster + Galera + ProxySQL). Dropped: simple-cluster never scaled beyond single-node bare-metal demos.

HHVM

HipHop Virtual Machine as an alternative PHP runtime. Dropped: upstream Facebook discontinued HHVM in 2019; PHP 8.x + JIT closed the perf gap.

Dedicated-IP SSL proxy (remote SSL add-on)

Serving a site's HTTPS from a certificate bound to a dedicated IP address — including the deprecated remote-proxy SSL add-on Omega8.cc offered, where the dedicated IP lived on a separate proxy host. Replaced by built-in Let's Encrypt.

A dedicated IP still configured on the same server keeps working, because Ægir's HTTPS vhosts listen on the wildcard * ($ssl_listen_ipv4 = "*", vhost_ssl.tpl.php:48), so any active host IP can serve the vhost's cert. But a dedicated IP that lived on a different, remote system can no longer be used: it is not managed by Ægir, and BOA does not offer dedicated IP addresses with Let's Encrypt. Migrate such sites onto the built-in LE support instead — see SSL operations.

Chive DB-manager

Chive web-based MySQL UI. Replaced by Adminer + sqlbuddy under nginxsql*.conf (see DB GUI tools).

Hourly hot DB backups (Percona XtraBackup)

_HOURLY_DB_BACKUPS=YES enabled hourly hot backups of the whole database server with Percona XtraBackup (innobackupex): once an hour it wrote a complete, consistent snapshot of every hosted database into /data/disk/arch/hourly/ — timestamped archives alongside a latest pointer. It was opt-in (default NO), and its restore path was whole-server only — the copy-back procedure recovered all databases at once as a last-resort disaster recovery, with no reliable way to restore a single database.

Retired: the variable no longer has any consumer in BOA. The nightly per-database mydumper dumps under /data/disk/arch/sql/ are the local restore layer now — and unlike the hourly hot copy they restore per database — while multiback and its per-tenant mybackup front archive those dumps off-site. Together they cover what the hourly hot backups guarded against.

d7security_client module

The d7security_client contrib module for Drupal 7. Removed in BOA-5.9.3: dropped from o_contrib_seven and Hostmaster (see Modules for the removal note).

RVM (per-user Ruby Version Manager)

The old per-user RVM mechanism for installing Ruby and Compass Tools is gone — barracuda upgrade purges any leftover ~/.rvm from accounts. It was replaced by a single source-built system Ruby, distributed per account under /opt/user/gems/.

Compass / Ruby Gems themselves are not discontinued. They remain available as the CSS xtra (Ruby plus the Compass gem toolchain, built from source), activated per account by the ~/static/control/compass.info control file, for both the main and client SSH accounts. Node.js / NPM is the separate NPM xtra — gated by an extra /root/.allow.node.lshell.cnf opt-in and intended for single-tenant hosts only, since npm install runs upstream post-install hooks as the tenant user. See XTRAS list for both.

xboa (cross-host migration tool)

The xboa root-side cross-host migration tool. Renamed and superseded by xoct: there is no xboa binary or fetch entry in BOA any more (BOA.sh.txt fetches only xoct and xmass, and ships xcopy).

xoct is the functional successor — it delegates the Ægir DB hostname replacement and post-import task queue to renameaegirhost (a thorough 5-pass rename) and dropped the old hardcoded internal-account email exclusion so it works correctly when driven by xmass.

If muscle memory still types xboa, create a personal symlink: ln -sfn /opt/local/bin/xoct /opt/local/bin/xboa. See Cross-host migration.

remote_import / hosting_remote_import (single-site remote migration)

The manual single-site remote-migration flow built on the remote_import Provision extension and the hosting_remote_import Hostmaster module. What is retired is the end-to-end manual procedure, because the Provision remote_import backend extension is gone — it survives only in removal/cleanup lists (satellite.sh.inc:5571), never in an install list.

The frontend hosting_remote_import module still ships: it is cloned into every Hostmaster platform on install and upgrade (master.sh.inc:586, satellite.sh.inc:3165), but is not enabled by default — it carries no en pass, so it lies dormant like signup/quota and can still be turned on with drush @hostmaster en hosting_remote_import -y. Without the Provision backend, however, the historical manual flow no longer completes.

The supported cross-host paths are now:

• xoct — move one account
• xcopy — copy one account, source stays live
• xmass — whole host

See Cross-host migration.

Migrated-account direct-SQL fixups (post-merge surgery)

BOA used to try to repair imported/exported (migrated/merged) Octopus instances with direct SQL and sed, in three places:

• xoct/xcopy import — hardcoded-node-ID drush sqlq REPLACE/UPDATE/DELETE statements against hostmaster's hosting_context, hosting_package, node, node_revision, hosting_site, hosting_platform and users_roles tables, plus a ghost/empty-platform delete loop whose missing-sites/all test misread every valid Composer Drupal 8+ platform as a ghost and deleted valid platforms.
• the Octopus satellite installer — the same hardcoded-node-ID SQL blocks plus greedy sed "Pre-Fix" rewrites of hostmaster.alias.drushrc.php.
• the nightly run — a one-shot UPDATE hosting_context SET name='hostmaster' plus forcing site_readonly = 0 on imported instances every night.

Removed (post-5.10.3): these predate renameaegirhost, and on long-lived instances whose node IDs no longer matched the hardcoded assumptions they caused hostmaster drift rather than curing it. xoct import now delegates the rename and re-import to renameaegirhost (xoct:614) — see the xboa section above for the delegation mechanics.

The retired one-shot markers (post-merge-fix.pid, hmpathfix.pid, hosting_context.pid, readonlymode_fix.info) need no operator action — nothing reads them any more; routine hygiene archives leftover post-merge-fix.pid/hmpathfix.pid to src/ and ages out the rom-fix.info state markers, and any remaining leftovers are inert.

Do not expect BOA to auto-rewrite hostmaster contexts or aliases after a migration any more — run renameaegirhost for hostname/topology changes. The removal is scoped to the migrated-account fixup family: benign hosting_task queue-hygiene sqlq lines remain in xoct/xcopy. See Cross-host migration.

Drupalgeddon daily hacked-site detector

The optional daily Drupalgeddon (SA-CORE-2014-005) hacked-core detection that the nightly maintenance run performed on Drupal 7 sites — together with its alert emails and automatic site-shutdown behaviour — was removed (post-5.10.3): the check was long optional and false-positive-prone.

While it ran, the check temporarily enabled Drupal's core update module — the Drupalgeddon extension needed it to suppress extra false positives — which in turn produced Drupal's own update-status notification emails to the site admin address wherever those notices were enabled. That secondary mail is gone along with the check.

Both opt-in control files are retired fleet-wide; the upgrade path deletes the global /root/.force.drupalgeddon.cnf and every per-account ~/static/control/drupalgeddon.info (BOA.sh.txt:1212-1213).

The drupalgeddon Drush extension itself is still installed (cloned into ~/.drush/usr/drupalgeddon) and symlinked into limited-shell users' ~/usr/, so an operator or client can still run it by hand — BOA no longer runs it, emails about it, or disables sites based on its findings.

Perl monitor scripts (monitor/check *.pl)

The first-generation Perl host-monitor scripts are superseded by the bash monitor/check/*.sh fan-out (hackcheck.sh, hackftp.sh, sqlcheck.sh, escapecheck.sh, scan_nginx.sh, nginx.sh/nginx_guard.sh, java.sh and friends), and the old /var/xdrago/proc_num_ctrl.pl process guard by the _proc_control framework — see Process guards.

The upgrade path deletes any leftovers still present on long-lived boxes:

• /var/xdrago/proc_num_ctrl.pl, /var/xdrago/checksql.pl and monitor/check/{escapecheck,hackcheck,hackftp,sqlcheck}.pl (cleaned earlier, BOA.sh.txt:1312-1317)
• as of 5.10.3, scan_nginx.pl, locked_nginx.pl and locked_java.pl (BOA.sh.txt:1319-1321)

One Perl script remains in active service: segfault_alert.pl. No operator action needed.

hosting_tasks_extra legacy Ægir UI tasks

The hosting_tasks_extra module now exposes two everyday maintenance tasks in the Ægir control panel — Flush all caches and Rebuild registry (per the module's own task description, the latter recreates the Drupal 6/7 registry tables or, on Drupal 8+, rebuilds the compiled service container and flushes every cache) — plus the one-off Convert to utf8mb4 task offered on enabled Drupal sites (see Converting utf8 databases to utf8mb4).

Run drush cron (removed to close a potential attack vector) and Run db updates (should never be part of the normal workflow; exceptions belong on the command line) were retired from the UI earlier and stay retired. In the 5.10.3 window five more were hidden:

• Update translations
• Revert features
• Update features
• the server-level Flush Drush cache
• the BOA-specific Run health check

Run health check bundled a batch of Drush reports into one task log. It was built for the Drupal 6/7 era: on those sites its report leaned on the core Update (update-status) module — temporarily enabled for each run — to list pending module and security updates, alongside a status report, a pending-database-updates check and (on Drupal 7) a security-review pass. (On Drupal 8+ the same task merely ran the site's own pm:security, status and updatedb:status.) The Drupal 6/7 update-status machinery it was built around no longer works, so the button is gone. Everything it set out to answer is available inside Drupal itself, read as a site admin:

• Available updates — whether any installed module or theme has a release (above all a security release) you haven't applied yet.
• Status report — PHP and database versions, when cron last ran, and any warnings Drupal wants to raise.
• Pending database updates — after you update a module, Drupal tells you if it has database updates waiting to be applied.

These reports are read-only — they tell you something needs doing; acting on what they show is a separate, deliberate step you take through your normal Drush or deployment workflow.

The underlying backend Drush commands (provision-run_cron, provision-update_translations, provision-features_revert_all, provision-features_update_all, provision-flush_drush_cache, provision-site_health_check) still ship in the module's Drush backend and can be invoked directly from the command line — only the control-panel buttons are gone.

Site-level Git deployment (hosting_git)

Stock Ægir's hosting_git lets you attach a Git repository to an individual site — create-a-site-from-a-Git-URL, a deploy key, a Pull-Trigger webhook that auto-redeploys on push, a prescribed repo layout, and a versioned.settings.php trick.

BOA ships the hosting_git code (it is cloned into every Hostmaster platform on install/upgrade, master.sh.inc:584 / satellite.sh.inc:3163) but never enables it — there is no en hosting_git anywhere in the install or the weekly maintenance run, so the site-level repo, deploy key, pull webhook and versioned.settings.php are all inert.

What BOA enables instead is platform-level Git: hosting_platform_git and hosting_platform_composer_git are turned on at INIT (satellite.sh.inc:6176-6177). The BOA model is to build a codebase from a Git or Composer-Git source (or drop a checkout into ~/static/platforms/), register it as a new immutable platform, and migrate sites onto it — never a per-site pull.

Live-site development uses the .dev. preview URL plus the editable per-site files, not a site-attached repo — see Developing your site and Building a platform.

Mutable / live-Git platforms

Ægir documents building platforms as live, mutable Git checkouts you can git pull / composer update in place. BOA does the opposite: a deployed platform is frozen at the filesystem level.

_enable_chattr() sets chattr +i on /home/<user>/platforms/ and its contents (satellite.sh.inc:663-665), so in-place writes are physically blocked until a controlled upgrade lifts it with _disable_chattr(). Running Composer or Git against a platform that is already serving sites is unsupported and, on BOA, actively prevented.

The only supported way to update platform code is build-new-then-migrate: build a fresh platform beside the old one, migrate test sites, verify, migrate the live sites, then retire the old platform (see Site cloning & in-host migration). Platform creation from Git/Composer is fully supported — only mutating a deployed platform is not.

The one surviving piece of the old mutable-Git story is make_working_copy: a build-time flag that tells drush make to keep the .git metadata in a newly-built platform. It is a real per-platform option but it only affects what is retained at build time — it never confers mutability and BOA does not set it by default.