Answer-file keys#

wheelhouse-install --answers FILE installs a machine without a keyboard. The file is KEY=VALUE lines; anything that is not one of the keys below is ignored, and so is any line that does not match ^[A-Z_]+=. It is also the format a cloud-config seed is converted into before the installer ever sees it, so this table is the ground truth for both.

Re-derive the accepted list:

grep '^ANSWER_KEYS=' packaging/wheelhouse-install

DISK=sda
HOSTNAME=edge
TIMEZONE=Europe/Berlin
WAN_IFACE=eth0
WAN_ADDRESSING=dhcp
LAN_IFACE=eth1
LAN_ADDRESS=192.0.2.1/24
LAN_DHCP=yes
FIREWALL=yes
NAT=yes
ADMIN_PASSWORD=…
CONSOLE_PASSWORD=…
REBOOT=yes

sudo wheelhouse-install --answers answers.conf

Every key#

DISK is required, and ADMIN_PASSWORD and CONSOLE_PASSWORD are required together. Missing any of them is a one-line refusal on stderr and exit 1.

The two console accounts#

The installer sets up two, with the same password:

One password for both, so an operator has one thing to remember and cannot be locked out of the recovery account.

ON_ERROR#

Combined with the once-per-boot rule, this is what stops a failing seed from erasing the same disk on every restart. See Where the installer looks for a seed.

Payloads: file, or HTTPS URL#

CONFIG_COMMANDS, CONFIG and SSH_KEYS each take a local path or a URL. Plain http:// and ftp:// are refused unless the machine was booted with wheelhouse.insecure=1 on the kernel command line:

refusing to fetch config.commands over plain http: use https, or boot with
wheelhouse.insecure=1 if this network is trusted

That switch is deliberately not an answer-file key. A seed that arrived over the network must not be able to declare that the network it arrived over is trustworthy; only the person at the keyboard, on the kernel command line, can say that.

CONFIG_COMMANDS and CONFIG are applied to the live configuration after the passwords are set, so a restored firewall can be as closed as you like without locking the installer out of the agent. A loaded whole configuration replaces everything, including the two console accounts — so the installer writes them again afterwards, because a box whose login screens name an account the configuration does not have is the worst kind of wrong.

Seeing the commands before running them#

--commands prints the set lines a set of answers produces and stops. It changes nothing, needs no root, and does not need to be running from a live image:

wheelhouse-install --answers answers.conf --commands

That is how to check a seed before booting a machine with it.

What the installer does with a WAN and no firewall#

Unchecking the firewall with a WAN present is a deliberate answer, and the summary screen says what it costs in those words: REACHABLE - port 8443 answers the internet. With the firewall on, the same line reads blocked, or blocked, except from <MGMT_SOURCE>.

Where it logs#

/var/log/wheelhouse-install.log, on the live system. Under --answers every log line also goes to stderr, so a seeded install narrates itself on the console.

See also#

• Seed cloud-config keys — the YAML form, and which key each one becomes.
• Where the installer looks for a seed
• wheelhouse-seed.py — builds the medium.
• opnsense-import.py — writes CONFIG_COMMANDS.
• Files and directories — the installer's runtime files.
• Ports and listeners — what the firewall answer decides.
• Unattended install
• Installer screens — the same answers, asked by hand.

Checked against#

packaging/wheelhouse-install (ANSWER_KEYS, read_answers, resolve_disk, disk_has_install, fetch_payload, apply_config, build_commands, wan_ui_summary), packaging/seed-to-answers.py, packaging/README.md, docs/unattended-install.md.