Skip to content

Powered by Grav

Host control files & INI reference

Host control files & INI reference

The complete operator reference for BOA's four-layer config: the host .cnf files, the empty boolean marker files, the tenant-editable INI, and what wins.

BOA's configuration is a four-layer stack, narrowest-scope-wins. From the root operator's side the two load-bearing surfaces are the host .cnf files (/root/.barracuda.cnf host-wide, /root/.${USER}.octopus.cnf per instance) and a large set of empty boolean marker files whose existence toggles behaviour. Below those sit the per-platform and per-site INI files that a tenant can edit without root.

This topic is the complete operator reference for all of it:

  • every marker
  • every _VAR
  • the relocation of the operator-toggle markers from /root to /etc/boa
  • the precedence rules that decide who wins

Two structural facts to keep in front of you:

  • Empty markers are booleans. A .<feature>.cnf file is on when it exists, off when it is missing — content is irrelevant. touch to enable, rm to disable. Each table below shows the exact path the live reader checks, which for the migrated set is /etc/boa/, not /root/.
  • .cnf is bash, INI is parsed Drupal-side. .barracuda.cnf / .octopus.cnf are sourced as bash on barracuda/octopus upgrade passes (plus a few read by per-minute cron); the INI templates are read by the PHP global includes on a ~60 s opcache TTL. That difference in refresh timing is why tenants do quick adjustments in INI and host policy lives in .cnf.

The pages below cover the marker system as a whole, the two host .cnf references, the tenant-editable INI layers and their precedence, the module support matrix, and the XTRAS install-mode tokens.

See the Reference appendix for the consolidated variable and command tables, and Discontinued features for control variables and markers dropped from the stack.

© 2026 BOA Documentation. All rights reserved.