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.

Inventory history: bpd-004, bpi-055, af-040, au-011

HHVM

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

Inventory history: rtfm-019

Chive DB-manager

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

Inventory history: lo8-277, lo8-323

Drupal 6 support

Legacy Drupal 6 platforms. Dropped: D6 is EOL upstream.

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).

Default Compass / Ruby Gems install

BOA no longer installs Compass Tools or default Ruby gems. Still possible via per-user RVM — see Section 10 node-npm-ruby-gems.

Inventory history: bpd-027, lo8-329

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 Aegir 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), and 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), and 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.

Inventory history: bpi-044, bpi-064

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. 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.

Inventory history: bpd-007, bpi-044, lo8-342

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), and, 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.

Inventory history: bpi-050

hosting_tasks_extra legacy Aegir UI tasks

The hosting_tasks_extra module now exposes exactly two site tasks in the Aegir 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). 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, and the BOA-specific Run health check. 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 Aegir'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.

Inventory history: au-013, au-022

Mutable / live-Git platforms

Aegir 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.

Inventory history: au-013