setup/questions.sh: Auto-detect headless mode when no terminal is available

[robertpopa22]

Problem

Running sudo mailinabox via SSH without a PTY (e.g., from automation scripts, paramiko, Ansible, or cron) fails with:

Error opening terminal: unknown

This happens because dialog (ncurses) is called in setup/questions.sh when NONINTERACTIVE is not set, and dialog requires a terminal.

Workaround: Setting NONINTERACTIVE=1 sudo mailinabox works, but this is not documented and not intuitive — especially for reconfiguration scenarios where all settings are already in the env file.

Expected Behavior

When running sudo mailinabox without a terminal attached (no PTY), the script should automatically detect this and either:

1. Set NONINTERACTIVE=1 automatically, or
2. Print a helpful error message suggesting NONINTERACTIVE=1

Proposed Fix

In setup/questions.sh, add terminal detection at the top:

# Auto-detect headless mode when no terminal is available
if [ -z "${NONINTERACTIVE:-}" ] && ! [ -t 0 ]; then
    # No terminal attached (SSH without PTY, cron, pipe, automation)
    # dialog can't work without a terminal, so auto-set NONINTERACTIVE
    export NONINTERACTIVE=1
    echo "Notice: No terminal detected, running in non-interactive mode."
    echo "To force interactive mode, run with: script -qc 'sudo mailinabox' /dev/null"
fi

[ -t 0 ] checks if stdin is a terminal. If not (SSH without PTY, cron job, pipe), it automatically enables non-interactive mode and prints a notice.

Use Case

This is especially relevant for:

• Automation: Ansible, Puppet, scripts managing MiaB remotely
• IP migration: When changing PUBLIC_IP in mailinabox.env and re-running sudo mailinabox via SSH automation
• CI/CD: Automated testing or deployment pipelines

Environment

• Mail-in-a-Box v74
• Ubuntu 22.04.5 LTS
• Running via Python paramiko SSH (no PTY allocated)

[robertpopa22]

Additional context: Full migration scenario

We encountered this while migrating a MiaB v74 instance from a direct public IP (on eth0) to a 1:1 NAT setup through our firewall (UDM Pro), where the server only has an internal IP (10.x) and the public IP is handled via DNAT/SNAT.

Steps that triggered the issue:

1. Changed default route from eth0 (direct ISP) to eth1 (internal, via firewall NAT)
2. Set PUBLIC_IP=82.79.229.146 in /home/user-data/mailinabox.env
3. Disabled eth0 (removed old public IP)
4. Ran sudo mailinabox via SSH (paramiko, no PTY) → "Error opening terminal: unknown"

Additional issue discovered: bind9 SERVFAIL after network change

After changing the default route/interface, bind9 (recursive DNS on 127.0.0.1) started returning SERVFAIL for some domains (e.g., api.launchpad.net) while others worked fine (google.com). This caused add-apt-repository to fail during the MiaB setup.

Root cause: DNSSEC validation failures on stale cached records after the network path changed.

Fix: Added forwarders { 8.8.8.8; 8.8.4.4; }; and increased max-recursion-queries to 200 in /etc/bind/named.conf.options, then rndc flush && systemctl restart bind9.

This might be worth documenting — when MiaB's IP/network changes, bind9 may need a cache flush before sudo mailinabox can succeed.

Working command

NONINTERACTIVE=1 sudo -E mailinabox

This worked perfectly once DNS was fixed. The NONINTERACTIVE flag should really be auto-detected as proposed in the issue description.