Remote management & config-as-data

Este conteúdo não está disponível em sua língua ainda.

NGBackup lets you manage every daemon’s configuration over the authenticated console — the same connection you already use for run, restore and status. No SSH, no logging into each host, no editing .conf files by hand. The Web and Desktop consoles are thin clients over these verbs.

All of them are .-prefixed (dot) commands. The read verbs return JSON directly; the rest return a standard JSON envelope ({"result":"ok",…}).

Read configuration

Read any daemon’s live config as JSON, with secrets blanked as ***REDACTED***:

.dirjson                         # the whole Director config
.dirjson resource=Job            # only Job resources
.dirjson resource=Client name=fd1
.sdjson storage=File1            # a Storage daemon's config (proxied to it)
.fdjson client=server-fd         # a File daemon's config (proxied to it)

You get the same JSON the backup-*json tools produce — enough to drive a config editor for all three daemon types without touching the hosts.

Validate before applying

Dry-run a proposed Director config — full syntax and the cross-resource checks the daemon runs at boot (exactly one Director, no duplicate names, required directives). Nothing is written:

.validate-config data=<base64 of the full config text>

Returns valid:true with a resource summary, or valid:false with the stage (parse / semantic) and error.

Write configuration

Director — live, atomic and rollback-safe. The daemon validates, backs up the live file, atomically replaces it, reloads, and auto-rolls back if the reload rejects it:

.reconfigure data=<base64 of the full new config text>

Storage / File daemon — proxied to the agent, which validates and persists the new config but does not hot-apply it (a live device swap mid-job is unsafe). It takes effect on the next restart:

.reconfigure storage=File1 data=<base64>
.reconfigure client=server-fd data=<base64>

Deleting a resource — .reconfigure always replaces the whole config; to remove one block without round-tripping the full text, use the structured delete. It rides the same validate + atomic-write + reload + rollback pipeline, so a deletion that breaks cross-references (a Job pointing at the deleted Client) is rejected before anything is written:

.config-delete resource=client name=old-laptop-fd

Any resource kind except director can be deleted; the name match is case-insensitive. The reply carries "deleted":{"resource":…,"name":…} plus the post-reload summary.

Restart

Ask an agent to restart. The daemon acknowledges the command, exits cleanly, and the service manager restarts the unit — no extra privileges or sudo/polkit grants are needed. The Director then health-probes it until it answers status again:

.restart storage=File1
.restart client=server-fd

The Storage daemon refuses while jobs are active — retry when idle.

Config-as-data — versioned, reversible config

Beyond editing the file, NGBackup can keep the Director’s configuration as versioned revisions in the catalog, making the .conf a generated artifact. Each revision stores every resource as raw text plus a JSON view.

Verb	What it does
`.config-import`	Seed revision 1 from the live config file (active).
`.config-commit data=<base64> note="…"`	Store a proposed config as a new inactive revision (returns its id).
`.config-activate revision=N`	Assemble revision N and apply it through the same safe pipeline as `.reconfigure`, then mark it active.
`.config-history`	List revisions, newest first.
`.config-show [revision=N]`	A revision’s resources as JSON (default: active).
`.config-diff from=N to=M`	The assembled text of two revisions, for a diff view.
`.config-drift`	Does the live `.conf` still match the active revision? Catches hand-edits.

This works for Storage and File daemons too — add storage=NAME or client=NAME to any of these. The Director holds each agent’s config as versioned revisions and pushes an activated revision to the agent.

Security model

Mutations require a secure session. .reconfigure, .restart and the mutating .config-* verbs are refused over plain TCP — connect the console over TLS / TLS-PSK (the password-derived PSK is mutual authentication; no client certificate needed). A refusal returns {"result":"error","stage":"insecure"}.
Console ACLs apply — a named Console{} needs the verb in its CommandACL.
Secrets are redacted on read — the read verbs never return existing passwords or keys. To set a secret, you write it (and see Secrets & encrypted config).
Every mutation is audited server-side (who, when, what, result, config SHA-256).