Configuration tracker

The configuration tracker (also called NCM — network configuration management) backs up, versions and diffs the running configuration of every device you point it at. It captures a config over whatever the box speaks — SSH, Telnet, SCP/SFTP or HTTP(S) — stores each capture as a content-hashed snapshot, and flags drift the moment a capture stops matching the version you marked as the baseline.

Because Taranac is already your AAA server, the tracker does two things a standalone backup tool structurally cannot: it can log in with a just-in-time password nobody ever sees, and — for any change — it can tell you who typed it, resolved from TACACS+/RADIUS accounting.

config-tracker · core-sw01

v1 v2 v3 init baseline drift

interface Gi0/1

- ip access-group 10 in

+ ip access-group 42 in

who typed it j.doe conf t · ip access-group 42 in

The tracker is a small set of objects that reference each other. You build the reusable parts once (sources, recipes, scrub sets, credentials, collectors) and then a tracked config ties them to one device.

Object	What it is
Tracked config	The unit you watch: a name, one source, an optional recipe override, and the device address(es) to collect from. It carries the version history and the baseline.
Source	The connection — a transport (SSH/Telnet/SCP/SFTP/HTTP/HTTPS), a target host, a port, a credential and the collector that reaches it. One source can feed many tracked configs.
Recipe	What to fetch — an ordered set of CLI commands, a single HTTP request, or a remote file path. Carries the netmiko driver and points at a scrub set.
Scrub set	Ordered rules applied to a capture before it is stored: strip volatile lines and mask secrets so no plaintext password is ever written to a snapshot.
Snapshot	One immutable, content-hashed capture. Identical captures are de-duplicated; a changed one cuts a new version (v1, v2, …).
Baseline	The snapshot you declare “known-good.” When the latest capture’s content hash stops matching it, the config is drifted.
Credential	A vault entry the source authenticates with — a stored secret, or a just-in-time account Taranac mints and rotates itself.
Collector	The reachability domain that does the collecting: the built-in embedded collector for the single-site case, or a dial-out standalone collector for segmented and remote networks.

1. A collection run fires — either the scheduled sweep (the job interval is the cadence) or an operator’s Collect now.
2. For each enabled tracked config, the collector opens the source connection, runs the recipe, and pulls the raw config.
3. The scrub set strips volatile lines and masks secrets; Taranac hashes the result.
4. If the hash matches the latest snapshot, nothing is stored (unchanged). If it differs, a new version is cut (changed) and, where a device address is known, the change is correlated to who was logged in during that window.
5. If the config has a baseline and the new hash differs from it, the config’s status flips to drifted; subscribers get a change notification email.

• Just-in-time credentials. A tracked config can authenticate with a credential Taranac owns rather than one you store: at collection time it mints a strong, 32-character password on a managed local account, logs in with it, and rotates it away once the work drains. Nobody — no human, no log, no API response — ever sees it. See Credentials & the vault.
• Who typed what. Open any change and the AAA activity view shows who logged into that box, which commands they ran and the session accounting — scoped to the window between the two config versions. Per-command attribution needs TACACS+; a RADIUS-only device still gives you who-logged-in and session accounting. See Snapshots, diff & drift.
• Collect over anything. SSH/Telnet for CLI gear, SCP/SFTP for boxes that hand you a file, and HTTP(S) for API-driven platforms — where a custom recipe carries its own request (path, headers, body), so you can track essentially any endpoint a device exposes. See Tracked configs & transports.

The tracker is the Configuration Tracker section of the admin console:

• Configs — the tracked configs, their status and version history.
• Collection Runs — a journal of scheduled sweeps and on-demand collects.
• Settings → Sources / Credentials / Recipes / Scrub Sets — the reusable building blocks.

Collectors live one level out, under Settings → System → Collectors, because a collector is a platform-wide reachability primitive shared with the rest of Taranac — not something specific to one tracked config.

The Configs list: each tracked config with its source, baseline, derived status, last-changed version and last-checked time.

You want to…	Use
Keep a versioned backup of every switch/router config	A tracked config per device (or bulk-onboard a whole pool)
Know the instant a config drifts from a known-good state	A baseline + drift status
See who made a change, not just what changed	AAA activity on the diff
Never store a device password in a config file again	A just-in-time credential
Collect from a segmented or remote site the core can’t reach	A standalone collector
Track an API-driven platform with no CLI	An HTTP recipe

• Tracked configs & transports — sources, transports and the config you watch.
• Recipes & scrub sets — what to fetch, and cleaning it before storage.
• Snapshots, diff & drift — versioning, the baseline, diffs and AAA activity.
• Credentials & the vault — the encrypted vault and just-in-time logins.
• Collectors — embedded vs standalone, health and enrollment.
• Deploy a standalone collector — the operator guide.
• Bulk onboarding — track a whole address pool at once.
• Change alerts & safe deletion — notifications, drift alerts and reference protection.