PluginProfile resource

PluginProfile is an NGBackup File daemon resource (no stock Bacula equivalent) that hoists plugin sidecar configuration — DR endpoints, auth tokens, network maps — out of per-plugin files and into backup-fd.conf. The payoff is operational parity with every other FD directive: one place to audit, remote editing with config set fd=, secret redaction in .fdjson dumps, and a single reload / .restart client= to apply.

The Director stays plugin-agnostic — it never learns plugin-specific keys; they live as opaque Setting strings.

The resource is multi-instance (keyed by Name) and bound to one plugin (Plugin is the plugin command prefix).

Example

PluginProfile {
  Name = dr-pair-pve                            # required; the handle + map key
  Plugin = proxmox                              # required; the plugin command prefix
  Description = "DR endpoint for ERP"           # optional; cosmetic
  Setting = "pve_host=192.168.15.129"           # repeatable; quoted "key=value"
  Setting = "dr_host=dr.example.com"
  Setting = "dr_auth_token=@secret:dr-token"    # secret by key-name heuristic
  Setting = "network_map=vmbr0=vmbr1,10.0.0.0/24=10.9.0.0/24"
  SettingFile = "dr_auth_token=/etc/ngbackup/dr_token"  # read the value from a file
}

Directives

Name

Name = <string> — required. The handle and the map key.

Plugin

Plugin = <string> — required. The plugin command prefix this profile binds to, matched case-insensitively against the active plugin command.

Description

Description = <string> — optional, cosmetic; surfaced in dumps.

Setting

Setting = "<key>=<value>" — repeatable. A single plugin option. The value must be quoted so the embedded = and any commas survive byte-for-byte; the parser splits the quoted payload on the first =, so a value may itself contain = (e.g. network_map=vmbr0=vmbr1).

SettingFile

SettingFile = "<key>=<path>" — repeatable. Reads the value from path at parse time and always marks it secret. A missing or unreadable file is a hard parse error (fail-closed) — a credential must never silently resolve to empty.

Secret handling

Two complementary mechanisms keep credentials out of config dumps:

Secret-named inline keys. A Setting is flagged secret when its key contains any of token, secret, password, passwd, or key (case-insensitive substring). So dr_auth_token, api_key, db_password all flag.
SettingFile — always secret, and the dump emits a SourceFile so operators can audit where the value lives without exposing it.

In a .fdjson / .dirjson dump, every secret value is replaced with ***REDACTED***. The cleartext value is never written to a config dump. (Values delivered in-process to the plugin are the real values — redaction applies only to the dump that leaves the daemon, and resolved values are never logged.)

You may also point a Setting at the sealed secret store with Setting = "dr_auth_token=@secret:dr-token"; the FD’s existing load-time pass swaps in the sealed value before parse. SettingFile is the file-based alternative for sites that don’t run the sealed store. See Secrets & encrypted config.

How settings reach the plugin

At job start the FD resolves the PluginProfile whose Plugin equals the active plugin command prefix and delivers each Setting to the plugin as a bEventPluginOptions string of the exact form:

<plugin>: key=value

This reuses the existing PluginOptions path — no new plugin ABI. A plugin that already honours PluginOptions needs no code change; pointing its operators at a PluginProfile instead of a sidecar file is purely a config-side migration. When multiple profiles bind to one plugin, their settings compose in Name order (deterministic). A misconfigured or unparseable profile never blocks a backup — the job still runs with any FileDaemon-scope PluginOptions.

Remote editing

Edit a profile over the secure console without touching the host:

*config set fd=pve1-fd PluginProfile=dr-pair-pve Setting+="dr_host=dr.example.com"

Setting=<k=v> (replace) replaces the first Setting line — use for single-valued directives (Description, Plugin).
Setting+=<k=v> (append) adds a new Setting line without clobbering existing ones.
Setting-= (remove) is not supported for FD edits — edit the file directly and reconfigure.

The edited text is re-parsed for validation before it is pushed; a profile that fails to parse is never persisted. See config set.