Browse configuration

The config console verb opens a read-only, interactive browser for the Director’s configured resources — over the authenticated console wire, with no SSH or file access to the server. It’s part of NGBackup‘s management plane: an operator (or the Desktop Console) can inspect what a remote Director is running without logging into the host.

Browse is read-only; editing is config set

The interactive browser never modifies anything. Single-directive edits go through the config set subcommand below — a validated, atomic, audited write with automatic rollback. Whole-file replacement remains available via the management-plane .reconfigure command.

Using it

Type config at the console prompt to enter the browser. It is a multi-turn session (like run, restore, and status); . cancels at any point.

*config
Configured resource kinds:
  1: Director (1)
  2: Job (4)
  3: Client (1)
  4: Storage (1)
  5: Pool (1)
  6: Schedule (2)
  7: Content (3)
  8: Catalog (1)
  9: Messages (1)
Select a kind (1-9), or `.` to cancel:
config> 2
The defined Job resources are:
  0: Back
  1: BackupEtc
  2: BackupBig
  3: RestoreFiles
  4: AccJob
config> 1

Picking a resource prints its directives and resolved references — the same output as show job=BackupEtc — and then offers an edit prompt:

Edit BackupEtc? Enter <Directive> = <value>, or 0 to go back:

Entering <Directive> = <value> applies the change through the same validated pipeline as config set (secure session required — over plain TCP the edit is refused while browsing keeps working), shows the result plus the re-rendered resource, and re-prompts so edits can be chained. 0 (or back/Enter) returns to the resource list; . exits at any point.

Only resource kinds that actually have a configured resource appear in the menu, each with its count.

One-shot form

config <kind>=NAME is a non-interactive alias for show <kind>=NAME (and bare config in a script context behaves like show all), so the same data is scriptable:

*config job=BackupEtc

Editing: config set

config set <kind>=<NAME> <Directive>=<value> changes one directive of one resource through the structured pipeline: the on-disk config is parsed, the directive applied, the whole file re-serialized, validated by re-parsing, written atomically (temp file → fsync → rename, preserving permissions), and the Director reloaded. If the reload fails, the previous config is restored automatically and the error reported.

*config set client=localhost-fd FileRetention=45 days
2000 OK config set: client `localhost-fd` FileRetention = 45 days
  (backup: backup-dir.conf.bak-cfgset-20260609-193041; note: comments in the
  file are not preserved by structured edits)
2000 OK reload (live snapshot + schedules + retention + TLS + catalog index hot-swapped)

Remote Storage Daemon edits: config set sd=NAME

Prefixing sd=<storage-name> targets a remote SD’s configuration over the authenticated wire: the Director fetches the SD’s raw config, applies the directive, re-serializes, validates, and pushes it back; the SD re-validates and persists atomically with a timestamped backup. SD edits are persist-only — the reply says so explicitly, and the change takes effect after .restart storage=NAME (a live device swap mid-job would be unsafe).

*config set sd=File1 device=FileDev1 MaximumConcurrentJobs=4
2000 OK config set: sd=File1 device `FileDev1` MaximumConcurrentJobs = 4 —
  validated + persisted on the SD … NOT applied live: run `.restart storage=File1` to apply.

Sealed @secret: references in the SD’s file are preserved verbatim; the same rules apply (unknown directives list the allowed table, Name renames are refused, multi-valued directives such as an Autochanger’s Device list are replaced as a whole), plus both daemons write audit lines.

Remote File Daemon edits: config set fd=NAME

Prefixing fd=<client-name> targets a remote FD’s (client daemon’s) configuration the same way: the Director fetches the FD’s raw config over the authenticated wire, applies a text-level edit (comments and the operator’s layout survive verbatim; sealed @secret: references stay opaque), validates the result against the FD grammar, and pushes it back; the FD persists atomically with a timestamped backup. Like SD edits, FD edits are persist-only — apply with .restart client=NAME.

*config set fd=web01-fd filedaemon=web01-fd MaximumConcurrentJobs=8
2000 OK config set fd=web01-fd filedaemon=web01-fd MaximumConcurrentJobs=<set> —
  persisted on the FD; applies on the next FD restart (`.restart client=web01-fd`)

A FileDaemon {} block without a Name directive (single-daemon configs) matches whatever name you pass. Renames and @include layouts are refused, as everywhere.

FileSet include lists: IncludeFile with =, +=, -=

The FileSet (content=) Include File list — a nested block other directives can’t reach — has dedicated list grammar:

*config set content=WebSet IncludeFile=/srv/www,/etc/nginx   # replace the whole list
*config set content=WebSet IncludeFile+=/var/log/nginx       # append (duplicate-safe)
*config set content=WebSet IncludeFile-=/etc/nginx           # remove

Edits land in the fileset’s first Include { … } block; its Options { … } sub-blocks and other directives are preserved untouched. +=/-= apply to IncludeFile only — any other directive refuses them with a typed error.

Multi-valued directives: whole-list replacement

Setting a multi-valued directive (Device, Storage, ACL families, TlsAllowedCn, Metrics, AuditEvents, PkiMasterKey, PluginOptions, Base, …) replaces the entire list. The value is comma-separated; quote an element to keep a comma inside it:

*config set sd=File1 autochanger=Library1 Device=FileDev1,FileDev2,FileDev3
*config set console=ops-console ClientAcl="lab client",ws01-fd

A single element yields a one-element list — a second config set never appends. An empty value is refused: explicit list clearing is not supported via config set; edit the file directly. Compound multi-valued rows keep their own grammar and remain file-only: a Schedule’s Run lines and Messages destination rows (Mail = target = classes) are refused with a compound multi-valued directive error.

Requirements and caveats

• Secure session required — config set is refused over a plain-TCP console; connect with TLS / TLS-PSK (the default backup-console build uses TLS-PSK).
• A timestamped backup (<conf>.bak-cfgset-<ts>) of the previous file is written beside the config before every change, and an audit line is appended to reconfigure-audit.log.
• Comments are not preserved — structured edits regenerate the file from the parsed configuration. Hand-written comments are lost (the backup retains them). Sealed @secret: references are preserved verbatim — plaintext secrets never touch the file.
• @include configs are refused — v1 supports single-file configurations only; edit included files directly and reload.
• Unknown directives are rejected with the resource’s allowed-directive list; Name (rename) is refused. Simple multi-valued directives are replaced as a whole list (comma-separated, quote-aware); compound rows (Schedule.Run, Messages destinations) remain file-only.

Relationship to the management plane

config reads the live, parsed configuration the Director is currently running. For the machine-readable form the Desktop Console consumes, see the .dirjson / .sdjson dot-commands; for applying a new configuration remotely, see .reconfigure on the management plane page.