Pular para o conteúdo

Change alerts & safe deletion

The tracker tells you when something changes and stops you breaking things by accident. Two things to understand here: the notifications it raises (which come from two separate systems), and the reference checks that guard deletions.

It’s worth being precise, because they carry different events through different channels.

Change notifications — email, per config

Section titled “Change notifications — email, per config”

When a tracked config changes (a new version is cut), Taranac emails the people who subscribed to that config. Subscriptions are by recipient group: you attach one or more user groups to a config (on its detail page, under Change notifications), and every member gets an email — in their own language.

  • A scheduled capture that changes a config is coalesced into a digest (default window ~15 minutes) so a big sweep sends one email per group, not a storm.
  • An on-demand Collect now that changes a config sends an immediate single-config email.
  • A preview never notifies.

Delivery is email/SMTP, so it needs SMTP configured; the queue is durable (it survives restarts and HA failover without double-sending) and retries transient SMTP failures.

Alert-center problems — drift, offline, failed

Section titled “Alert-center problems — drift, offline, failed”

Three tracker conditions are raised as problems in Taranac’s alert center, each de-duplicated so a persistent condition is one open problem, not a repeating one:

ProblemFires whenScope
Drift detectedA new capture’s hash diverges from the config’s baseline.Per tracked config. Can be turned off globally.
Collector offlineA collector stops reporting in.Per collector (rolls up the configs it serves).
Collection failedA config’s scheduled collections fail repeatedly (a run of consecutive failures).Per tracked config; on-demand failures don’t escalate. The newest failure class (auth / transient / partial) is in the title.

These resolve themselves when the condition clears — the baseline matches again, the collector reports back, or a collection succeeds. How the alert center then delivers them (email, etc.) is configured there, independently of the per-config change emails above.

Safe deletion — references / “where used”

Section titled “Safe deletion — references / “where used””

Every reusable object shows a Used by count, and the tracker won’t let you delete something still in use in a way that would break a dependent object. Try to delete one and Taranac runs a reference check: if anything blocks, the delete is refused and you’re shown exactly what’s referencing it.

Deleting a…Is blocked while…Otherwise
SourceAny tracked config uses it
CollectorAny source or tracked-config address uses itThe default (embedded) collector can never be deleted
Network objectAny source targets it
Scrub setAny recipe references it
Local account (used by a JIT credential)A JIT credential or a live lease binds it
Recipe(not blocked)Configs using it revert to the default recipe; the change is recorded
Credential(not blocked)Sources using it are simply left credential-less; any live JIT lease is rotated first

The “Used by” drawer lists the blocking references (and any that would auto-resolve) so you can detach or reassign them first, then delete.

Tell the network team when a firewall config changes. Add their user group as a recipient on that config’s Change notifications. They’ll get an immediate email on a Collect now change and a digest for scheduled changes.

Get paged when a config drifts. Leave drift alerts on (they’re on by default) and wire the alert center to your channel of choice. Drift raises one problem per config until you re-baseline or the config matches again.

Retire a recipe safely. Check its Used by count first; deleting it reverts dependent configs to the default recipe (recorded in the audit log) rather than breaking them.

ConcernBehaviour
Config-changed emailPer-config recipient groups; digest for scheduled changes, immediate for on-demand; SMTP-delivered.
Drift alertAlert-center problem per config; on by default; globally toggleable.
Collector-offline alertAlert-center problem per collector; from the periodic offline scan.
Collection-failed alertAlert-center problem per config; escalates on consecutive scheduled failures only.
Reference blocksource, collector, network object, scrub set, and a JIT local account block deletion while referenced; recipe and credential don’t (they detach cleanly).
  • Alerts — the alert center that carries drift / offline / failed problems.
  • Snapshots, diff & drift — what “changed” and “drifted” mean.
  • Collectors — the offline condition behind the collector alert.
  • Users & groups — the groups you subscribe to change notifications.
  • Audit & syslog — where deletes and reverts are recorded.