Support bundle

One archive holding this box’s control-plane state — the sixteen audit logs, every domain’s configuration, WireGuard drift, service liveness and the revision index — collected in a single pass so a support engineer can diagnose from it offline.

Ready.

This archive is privileged. Treat it exactly as you would a configuration backup: encrypt it in transit and delete it once the incident closes. It contains:

  • Every username ever submitted to this box, including failed sign-ins. Usernames are never redacted, so a password mistyped into the username field is in the archive.
  • The management source IP of every operator session.
  • /var/log/authlog unredacted — the Viewer tab masks this file; the archive does not, and nothing clamps its content at write time because it is base-OS sshd/su/doas output.
  • An inventory of which secrets exist for which peers. The values are not included, but the references embed WireGuard peer public keys, BGP neighbour addresses and IPsec EAP usernames.
  • Alert channel names, mail recipients, and whether each channel carries a bearer token. The webhook URL itself is removed from every archive — for Slack, Discord and Teams that URL is the posting credential, so it is not something to send off the box. Note the archive records nothing about whether a channel had a URL at all.
  • On a box whose DNS, DHCP or BGP configuration has not been adopted, the raw unbound.conf / dhcpd.conf / bgpd.conf bodies, filtered only by length.
  • The declared management network, firewall table entries and rule comments, and the paths (not contents) of IPsec key files.
  • The head of this boot’s kernel message buffer (system/dmesg_boot.json): the full hardware inventory — device serial numbers, CPU and board identifiers, and NIC MAC addresses with their device models, including interfaces the ARP table never shows.
  • The persisted boot order, each daemon’s boot self-check record, and the drift manifest’s own load verdict (system/host_facts.json).

Not included: OgmaProtect’s own private keys of any kind (WireGuard, IPsec, TLS), the user database or any of its siblings, the last-good configuration tree, /etc/ssl/private, capability keys, core-dump contents, rotated .gz log history, and packet captures. Note the raw third-party config bodies above are only partly filtered for secrets — a brownfield dhcpd.conf or unbound.conf can carry TSIG keys that nothing in this product redacts. The bgpd.conf and ospfd.conf bodies do have their key-bearing directives redacted, but that is a triage courtesy rather than a security control: a key held in a file the configuration includes is not covered.

What this bundle cannot tell you. Reading these first will save an incident:

  • Why the interface is slow. Nothing here measures the web tier. The manifest’s per-source timings are this box’s internal round trips only — they exclude the web server, the CGI layer and the browser, which is every layer between you and the box.
  • What the interfaces were called before the previous boot. system/dmesg_boot.json is this boot’s snapshot, clamped from the head — if its truncated flag is set, the later attach lines are absent. A boot-drift audit line is only in its log section while it is within the tail clamp; on a long-lived boot read the structured record in system/host_facts.json instead.
  • Why a service failed to start at boot. Service liveness is a point-in-time probe taken during collection; the boot order and each daemon’s boot self-check verdict are in system/host_facts.json, but no boot-time console output is captured.
  • Anything older than the current log generation. Rotated history is not carried, and in a long incident the causal line is often the oldest one. Check the manifest’s truncation flags before concluding a log is complete.
  • Why a failover did or did not happen. CARP, pfsync, tunnel and PPPoE are not collected at all. WireGuard is the only per-interface drift domain carried — each domain’s own drift verdict (firewall, DNS, DHCP, routing, IPsec, time, identity, certificate) is in its section.

Six collections per hour, per account — shared by everyone signed in as the same user, and a separate budget from the Audit export tab. A collection refused before it starts — unconfirmed, or an apply already running — does not use one up; one refused because the box could not accept the job does.

Collecting takes the configuration-apply lock for as long as it runs. While it does, a restore, firewall apply or routing change is refused with “another apply is in progress” — and if one of those is already running, your collection is refused the same way. Neither queues; press Collect again.

Downloading removes your copy from the web tree immediately. The original stays on the box, readable only by root, and is deleted about an hour after it was collected. Downloads have their own budget of twenty per hour, per account.

This tab always produces a partial archive — 39 sections against the console’s 41. Config-integrity and schema-state can only be read from the machine’s own console, so they are reported as omitted here. This is permanent and does not depend on your account: no role can reach those two sections, because they are root-console operations with no signed-in equivalent. For the complete 41-section artifact, run ogmaprotectctl support-bundle --out <path> on the box.

A vendor support identity gets a narrower archive still — 37 sections. An account holding the ogma-support role collects a deliberately reduced artifact, and this is a property of the role rather than of anything you choose here. It gains the fifteen per-daemon audit logs, which that role cannot read anywhere else in the interface. It loses the authentication log logs/authlog.json and the restore-status section, and every archive it collects has the alert channels’ webhook URLs and the raw unbound.conf, dhcpd.conf, bgpd.conf and ospfd.conf previews removed. Each affected section lists what was removed, by name, in MANIFEST.

The webhook URL is removed from every archive, including this one and the console’s. Whether a channel carries a bearer token is still reported; whether it had a URL is not, so an empty-looking channel and a webhook-bearing one read alike. Everything else on the list above still rides the archive as before.

If you granted ogma-support to a vendor, delete that account when the engagement ends. The role has no expiry: it stays live, and able to collect this archive, until it is revoked or the account is removed. See /etc/examples/ogmaprotect/README.recovery.

Nothing is collected until you press Collect. Collection usually finishes well inside a minute; it can take longer if a daemon is slow to answer.

Collecting a support bundle requires JavaScript.