Sending diagnostics

When something is wrong with the panel itself, whoever looks into it always asks for roughly the same things: what doctor says, what is in the configuration, what is unhealthy right now, which tasks were running, which versions the servers are on, and what the log says. That was six separate commands and six rounds of copy-and-paste — and the pasting is where it goes wrong, because a log line can easily contain a connection string with a password in it.

Since this round it is one command.

corecp-panel support bundle --config /etc/corecp-panel/panel.yaml

You get one .tar.gz, readable by root only, holding the doctor report, the configuration, what is unhealthy now, the recent tasks, the server list, the last audit entries and the panel's own log.

Everything about one report

If you have a support ID out of an error message (see The support ID on an error message), pass it along. The bundle then also carries the audit entries and the log lines of exactly that request:

corecp-panel support bundle --config /etc/corecp-panel/panel.yaml \
    --request-id Rk5t2wQfMz0 --out /root/support-Rk5t2wQfMz0.tar.gz

What is not in it

Two layers see to that, and the second is the important one.

The first layer removes what looks like a secret — a private key, an address with a password in it, a token, a field called password, token or secret. Wherever something was removed a marker is left, such as [redacted:named-value], so you can see that something was there. Two things are deliberately kept: certificates (they are public, and "which certificate is on this machine" is precisely the question) and paths to secrets — secret_key_file: /etc/corecp-panel/secret.key is not a key but a signpost, and without it nobody can see where the panel is looking.

The second layer asks a different question: is any of this machine's actual material in here? It reads the key files the configuration points at — the database connection, the master key, the fleet key, the relay password — and looks for exactly those bytes. It does not have to guess what a secret looks like, because it is holding them. That is the difference from a check that marks its own work: that one would report "clean" over a secret in a shape nobody had written a rule for.

If that second layer finds something, the file is not written. You are told which file it was in and which key material it was — never the value itself. The bundle is assembled in memory and only reaches the disk once the test has passed, because a file that briefly existed with a key in it is a file that is by now in somebody's backup.

Checking it before you send it

corecp-panel support verify /root/support-Rk5t2wQfMz0.tar.gz \
    --config /etc/corecp-panel/panel.yaml

This runs the same test on the file you are about to send, rather than on the promise that the machine that wrote it checked it. Inside the bundle, manifest.json records what was removed and what was searched for — including key files that were not readable by whoever ran the command. That last part is visible on purpose: a check whose coverage you cannot see is a check you cannot weigh.

Why there is no button in the panel

What goes into the bundle is the panel's own state: its configuration, its log, its audit trail. Anybody with a shell on that machine can already read all of it. Anybody with only an administrator password cannot — and should not acquire the ability by pressing a button.

See also

• The support ID on an error message — where the identifier comes from.
• If the panel goes down — the scenario where the machine itself is gone.