Hosting module suite map

omega8cc/hosting is a suite of Drupal 7 modules — one root framework module (hosting) plus nineteen top-level submodule directories — that defines Aegir's node types (server, platform, site, client, task, package) and the admin UI over them. It is the frontend half of the two-surface backend API: the hooks it exposes live in six *.api.php files (root + five submodules), and its task nodes drive the Provision backend across the round-trip on the topic chapter. This page is the module-by-module map — which module owns what, which *.api.php it carries, and which of the nineteen BOA actually enables versus which ship dormant. The frontend hook contracts (bodies, invocation points) are the Hosting API leaf; this page is the index into them.

Two authorities decide "enabled", and they disagree with the on-disk module count on purpose:

• hostmaster.info dependencies[] (hostmaster.info:23-37) — the D7 install-profile manifest Drupal enables at INIT. This is the source of truth for "on by default", not the presence of a directory in the hosting/ tree.
• _satellite_child_b_aegir_ui_enhance() (satellite.sh.inc:6120) and the Master analog — the BOA post-install drush @hostmaster en … pass that enables the golden-tier and satellite modules the .info manifest does not list. Adding a module to existing instances always means an en call here, never just a .info edit (the manifest fires only at INIT).

The root hosting module

hosting/hosting.module (~47 KB) is the framework every submodule dependencies[] = hosting against. It owns:

• Task dispatch + queue registry — hosting_queues() (hosting.module:822), hosting_get_queues() and the queue-frequency admin form; the dispatch mechanics live in hosting.queues.inc.
• Node-graph glue — breadcrumbs, _hosting_node_link(), the CTools features-export layer (hosting.features.inc, ~19 KB) that lets the Aegir config ship as a Feature.
• The framework hook surface — hosting/hosting.api.php (below), the suite's largest *.api.php.
• Front-end assets — hosting.css, hosting.js.

hosting.info declares no dependencies[] of its own; it is the base every other suite module sits on.

The six *.api.php hook surfaces

Six *.api.php hook-documentation files ship across the suite — one in the root hosting module and one in each of five submodules (task, alias, quota, server, site). Each is the canonical stub reference for that module's hooks — implemented frontend-side as <yourmodule>_<hook>() and invoked with module_invoke_all() / drupal_alter() at the cited points. Line numbers are the stub definitions at HEAD.

Note the split of the task hooks across two files: the lifecycle hooks (hook_hosting_TASK_OBJECT_context_options, hook_post_hosting_TASK_TYPE_task, the rollback and dangerous-task hooks) are in the root hosting.api.php, while the task-type declaration hooks (hook_hosting_tasks, the per-type form callbacks) are in hosting_task.api.php. Declaring a new task type touches both.

The remaining fourteen submodules (19 minus the five that carry an .api.php) ship no *.api.php — extend them through the root suite hooks (hook_hosting_feature, the TASK_TYPE/TASK_OBJECT family) or the standard D7 hook_nodeapi/hook_form_alter surface.

Enabled-by-default — the Aegir core tier

hostmaster.info:23-37 enables these fifteen at INIT (module machine name ← directory):

Two of the fifteen — hosting_le and hosting_tasks_extra — are not in the hosting/ tree at all; they resolve from separately-bundled projects the make chain places under modules/aegir/. The .info manifest names them because Drupal enables by machine name regardless of where the code came from.

Nginx submodules enabled at runtime, not by the manifest. hosting_nginx (web_server/nginx/), hosting_ssl (web_server/ssl/) and hosting_nginx_ssl (web_server/nginx/ssl/) are not in dependencies[]. hostmaster_install() enables them itself when the server context reports http_service_type === 'nginx' (always true on BOA) — see the Hostmaster frontend internals leaf. On disk they are submodules of hosting_web_server, hence the web_server/nginx/… nesting.

Golden contrib enabled at INIT. hostmaster.info:40-41 also enables hosting_platform_composer_git and hosting_platform_git (D7 contrib in the Aegir tier). The Drupal-core and D7-contrib tiers of the manifest (:10-20, :44-55) are covered on the Hostmaster frontend internals leaf.

Enabled-by-default — BOA satellite / golden tier

Beyond the .info manifest, BOA clones a set of golden and satellite projects at branch 5.x-${tree} (master.sh.inc:580-588, satellite.sh.inc:3159-3167) — these live outside the hosting/ tree, in their own omega8cc repos, kept in lock-step with BOA — and enables the frontend halves inside _satellite_child_b_aegir_ui_enhance() (satellite.sh.inc:6120). Most fire in the module en block (:6139-6159); hosting_le / hosting_le_vhost / hosting_custom_settings are enabled in later branches of the same function (:6282-6294, :6391-6395):

The hosting_tasks_extra project (below) also carries three modules BOA enables from inside its tree — fix_ownership, fix_permissions, hosting_http_basic_auth (satellite.sh.inc:6140-6152). hosting_remote_import is cloned but not enabled by the .info manifest; do not present it as a core hosting/-suite module — it exists only as a separate satellite repo.

Ship-disabled — present in the tree, never enabled

These submodule directories exist in omega8cc/hosting but appear in neither hostmaster.info nor any drush @hostmaster en call in the BOA stack (grep -rn "en hosting_signup\|en hosting_quota\|en hosting_subdirs" lib/functions/ returns nothing):

hosting_queued — the dormant daemon

hosting_queued (queued/) is Aegir's optional long-running task daemon (hosting_queued.drush.inc, an init script, and a .plist). BOA does not use it. BOA drains the queue from cron instead. The master queue runner (/var/xdrago/runner.sh) iterates the per-account run-* scripts under /var/xdrago (_runner_action(), runner.sh:121) and bashes each; those child runners are what invoke @hostmaster hosting-dispatch (manage_ltd_users.sh:1041) — the real hosting-dispatch drush command (hosting.drush.inc:20, implemented in dispatch.hosting.inc). Before dispatch the runner calls _enable_master_cron() (runner.sh:27, unconditionally in the non-wait branch, :222) to keep the master Aegir crontab un-parked. There is no hook_hosting_queued_process hook anywhere in the suite — do not document one; the only hosting_queued_* symbols are the …_process_started / …_process_lifetime timestamp variables. Queue-driver mechanics and the dispatch cadence are the topic chapter's task round-trip; the queue-declaration hook contract is on Hosting API.

Where the task queue sits

The queue system is three modules, not one, and each hook_hosting_queues() implementation (hosting_task.module, hosting_cron.module, hosting_task_gc.module) contributes exactly one queue — so BOA runs three queues, all cron-driven, none via the hosting_queued daemon:

hosting_queues() (hosting.module:822) renders the queue index UI; hosting.queues.inc holds the dispatch loop and the cron-command wiring. For the frontend hook you implement to add a queue — hook_hosting_queues() (hosting.api.php:138) — and the TASK_TYPE form/lifecycle hooks that hang a task on the tasks queue, go to Hosting API. The backend command each task node ultimately invokes is on Provision API. This map deliberately stops at "which module owns the queue"; the operator-facing dispatch/semaphore mechanics are out of scope for this guide.

Pedagogical + integration directories

• example/ — three reference modules for learning to extend Aegir: hosting_example (example/example_service/, machine name from hosting_example.info) demonstrates a new frontend service type; hosting_server_data (example/server_data/) attaches per-server custom data; hosting_site_data (example/site_data/) attaches per-site custom data. All three declare package = Hosting Examples and are not enabled by BOA. (Note the directory-vs-machine-name mismatch: example/example_service/ → hosting_example.) Read these plus Extending Aegir before writing an extension.
• includes/views/ — Drupal Views integration; the field handlers (includes/views/handlers/hosting_field_handler_interval.inc, hosting_field_handler_status.inc) expose the Aegir node types to Views. Not a standalone module — code loaded by the suite; it powers the default Aegir listings.

Deprecated — do not enable

• hosting_web_cluster (web_cluster/) + hosting_web_pack (web_pack/) — the upstream master/slave web-cluster modules. They ship in the fork but BOA does not enable them and does not support the topology. Graded discontinued: Discontinued features.

hosting_tasks_extra — BOA's task-set governor

omega8cc/hosting_tasks_extra is not part of the hosting/ tree — it is its own repo, cloned and re-pulled on the same 5.x-${tree} branch as the rest of the stack (master.sh.inc:588, satellite.sh.inc:3167), so its task set always matches the running BOA release, and enabled against @hostmaster on every install/upgrade pass (satellite.sh.inc:6150; the module itself sits in the .info manifest, hostmaster.info:36). Its BOA-facing job is to prune the Aegir task-button set to what BOA supports and add a few BOA-specific tasks:

• Two surviving site tasks at HEAD: Flush all caches and Rebuild registry, both now version-aware. On D8+ they route through Provision's shared _provision_drupal_rebuild_d8plus() helper (platform/provision_drupal.drush.inc:665) — drush cr via the site-local Drush on D10+, Aegir Drush 8 cache-rebuild on D8/D9 — instead of the D7-only registry/--fire-bazooka path.
• Retired from the UI (backend verbs still work from the CLI, buttons gone): Run drush cron (attack-surface removal), Run db updates (wrong-workflow guard), plus Update translations, Revert features, Update features, the server-level Flush Drush cache, and the BOA Run health check.
• Carries three enabled sub-modules inside its tree — fix_ownership, fix_permissions, hosting_http_basic_auth — enabled by the same post-install en pass. hosting_http_basic_auth's backend half (http_basic_auth.drush.inc) is the canonical paired-extension example on the Provision API leaf.

The task types it declares/hides are hook_hosting_tasks() (hosting_task.api.php:42) implementations — the same surface any task-adding module uses, documented on Hosting API.

On-disk layout after install

The make chain places the whole suite under the Hostmaster profile (paths and the make-chain detail are on Hostmaster frontend internals):

profiles/hostmaster/modules/aegir/
  hosting/                 hosting_alias/    hosting_client/
  hosting_clone/           hosting_cron/     hosting_db_server/
  hosting_le/              hosting_migrate/  hosting_package/
  hosting_platform/        hosting_server/   hosting_site/
  hosting_task/            hosting_tasks_extra/  hosting_web_server/
  aegir_objects/           hosting_civicrm/  hosting_deploy/   …

The web_server/nginx* and web_server/ssl submodules live inside hosting_web_server/, and the golden/satellite projects (aegir_objects, hosting_civicrm, …) sit beside the core tier — all under modules/aegir/. The sites/all/* tree is intentionally empty; extend by adding a hosting_* module to the make chain and the enable pass, never by dropping code into sites/all.

Maintainer contract

• "Enabled" is the .info manifest + the BOA en pass, not the directory list. Nineteen submodule dirs exist (plus the root hosting); the manifest enables fifteen (two from separate repos), the BOA post-install pass adds the golden/satellite tier, and four dirs (signup, quota, subdirs, queued) ship dormant.
• New task type = both api files. hook_hosting_tasks() in hosting_task.api.php for the type/form; the TASK_OBJECT/TASK_TYPE lifecycle + post_hosting_* hooks in the root hosting.api.php.
• New module for existing instances needs an en call. Add it to _satellite_child_b_aegir_ui_enhance() and the Master path; the .info manifest only fires at INIT, so a manifest-only add reaches fleet installs never.
• hosting_le / hosting_tasks_extra are separate repos. They are enabled by machine name but resolve from their own projects; keep them on the 5.x-${tree} clone list, not in the hosting/ tree.
• No hosting_queued daemon on BOA. The queue is cron-driven; there is no hook_hosting_queued_process.
• Master/satellite build duplication is deliberate — the clone/enable logic exists twice (master.sh.inc / satellite.sh.inc); fix both copies. See code style & conventions.
• PHP 5.6 floor applies to every .module / .inc / hook implementation in the suite — syntax and runtime both (see the topic chapter).

Related

• Aegir backend APIs (topic chapter) — the task round-trip these modules drive, and the two-surface API model.
• Hostmaster frontend internals — the install profile that bundles every module here, the make chain, and on-disk paths.
• Hosting API — the frontend hook contracts (hook_hosting_feature, hook_hosting_queues, the TASK_TYPE/TASK_OBJECT family) this map indexes.
• Provision API — the backend command each task node invokes, and the http_basic_auth paired-extension example.
• Extending Aegir: contexts, hooks, module pairs — the end-to-end paired-module pattern; start from example/ plus this leaf.
• Variables and Commands — consolidated _VAR and CLI tables.
• Discontinued features — where hosting_web_cluster / hosting_web_pack land.