Generate a support bundle

When you open a support request, the fastest way to get help is to send a support bundle — a single ZIP the server assembles for you containing everything needed to troubleshoot: build info, redacted configuration, fleet and pipeline state, config-as-code git status, storage stats, deployment environment, and recent server logs. Secrets are removed before the file is written, so you can share it without hand-scrubbing.

Generate one

1. Open Settings → Support.

2. Choose how much to redact:

   • Standard — masks tokens, passwords, keys, and credentials. This is the default and is right for most cases. Standard does not mask IP addresses at all.

   • Strict — also masks opaque values (long keys and hashes) and IP addresses.

     Masking is partial, not removal: for both IPv4 and IPv6 the first group is kept and the rest is replaced, so 203.0.113.42 becomes 203.x.x.x and 2001:db8::1 becomes 2001:x:x:x:x:x:x:x — a zone id is masked along with the rest too. It applies wherever the address appears — on its own, inside a URL, in a host:port pair, or in the middle of a log line. For example, http://10.154.15.227:8080 becomes http://10.x.x.x:8080, and http://[2001:db8::1]:8080 becomes http://[2001:x:x:x:x:x:x:x]:8080.

     Two shapes sit outside that rule:

     • An address with no leading group, like ::1, is masked outright as •••••••• — a retained fragment would assert a locality that does not exist.
     • An IPv4-mapped address keeps the IPv4 mask, since it is an IPv4 address wearing a ::ffff: wrapper: ::ffff:10.0.0.1 becomes ::ffff:10.x.x.x.

     The server’s own URL, and the probe addresses in diagnostics/connectivity.json, are still included rather than redacted — but an IP literal inside them is masked the same way as anywhere else.

3. Decide whether to include recent logs and, if so, how far back (1 hour to 3 days). Logs are the most useful part of a bundle for diagnosing a live issue, so leave this on unless you have a reason not to.

4. Select Generate & download bundle. The server builds the ZIP and your browser downloads it as linkmesh-support-<version>-<timestamp>.zip.

Note

Generating a bundle requires the support bundle permission. Administrators have it by default; if the button is disabled, ask an administrator to generate the bundle or grant you the permission.

What’s inside

Open the ZIP to see exactly what you’re about to send. Alongside the diagnostic files it contains two things worth reading first:

• README.txt — a plain-language explanation of what was collected and how it was redacted.
• manifest.json — an index listing every file included, every field that was masked (redactedPaths), and any section that couldn’t be collected.

Secrets are replaced with ••••••••. Live-capture telemetry samples are never included, at any redaction level.

Caution

Redaction removes known secrets automatically, but it can’t understand every custom field. In regulated or air-gapped environments, open the bundle and review it before sending — manifest.json → redactedPaths shows you exactly what was masked.

Send it to support

Attach the ZIP to a ticket in the OpenSight Customer Portal — that’s the one support channel for LinkMesh. See LinkMesh support for hours, first-response times, and what to include alongside the bundle.

Because the bundle already captures your server’s state at the moment you generated it, you usually won’t need to answer a round of follow-up questions about versions, configuration, or fleet health — it’s all in the file.

Tip

Generate the bundle while the problem is happening, with logs included and a window that covers when the issue started. A bundle captured after a restart may have lost the logs that explain the failure.

Related

• Troubleshooting — work through the symptom-led checks first; many issues resolve without a ticket
• Enrollment troubleshooting — the most common class of problem a bundle gets opened for
• Monitor the server — the health signals to check before and after