Administration

Support and diagnostics

Collect what DFIRe support needs, watch the logs as they happen, and check that both containers match.

Which tool to reach for

Settings → Support is where superusers generate a support package and tail the application logs. It covers anything DFIRe can see about itself.

When DFIRe cannot see the problem, because a container will not start or the interface is unreachable, use the host collector instead. It runs on the host and works with the application down.

The support package

A plain zip holding what support needs to understand your installation:

  • Application logs from the backend, the task worker and the Slack listener.
  • System information: versions, platform, database and Redis health, uptime.
  • Migration state and installed package versions.
  • Your configuration, with secrets masked or left out.
  • License state and when the license server was last reached.
  • An audit log excerpt, over a window you choose.
  • Background task state: failed tasks, schedules, queue depth.
  • Backup inventory and database size statistics.

It carries no attachment data. Every file in it appears in its manifest.json. It is an ordinary zip, so you can open it and see exactly what you are about to send.

Inspect the archive before you send it. DFIRe masks secrets where it knows to look, which covers configuration, headers and connection strings. That cannot be guaranteed complete. A secret that ended up somewhere unexpected, such as an error message or a line from a third-party library, can survive into the archive.

The audit excerpt is the one part that can carry case text, because it records who changed what, including old and new values. Choose Do not include if audit data must not leave your installation. The package is then built without it, and the manifest records that you excluded it rather than that something failed.

From the web interface

  1. Open Settings → Support

    The tab is visible to superusers.

  2. Choose the audit log window

    Seven days is the default and usually enough. Widen it to 14, 30 or 90 days when the problem started earlier, or choose Do not include.

  3. Generate the package

    It builds on the server and downloads through your browser. Nothing stays on the server afterwards, and each generation reaches the audit log.

From the command line

When the interface is unreachable but the backend still runs:

docker compose exec -T backend python manage.py support_package
docker compose cp backend:<printed path> .

The command prints the path of the finished zip inside the container.

The host collector

When the backend is down, nothing inside DFIRe can report on it. The host collector gathers what Docker knows from outside the application. That makes it the right tool for a container that will not start, or a stack that never comes up.

Download it once and run it from the installation directory:

curl -fsSL https://dfire.fi/dfire-support.sh -o dfire-support.sh
chmod +x dfire-support.sh
./dfire-support.sh

It needs no more permission than docker compose already has. Set DFIRE_INSTALL_DIR to run it from elsewhere, or DFIRE_COMPOSE_FILE to override which Compose file it finds.

It collects the container overview and Compose structure, the logs of every service, container state, and basic host facts. If the backend happens to be up, it also generates the application support package and folds it into the same archive, so one file covers both. The result is a dfire_support_host_ archive in the installation directory, and the script prints its full path.

Inspect this archive too. The collector never reads .env, limits Compose output to service and image names, and restricts container inspection to state fields. It masks common credential patterns from container logs, such as authorization headers, connection-string passwords and NAME=value pairs. Container logs are otherwise raw service output, so list the contents before sending:

tar -tzf dfire_support_host_<timestamp>.tgz

The live log viewer

The Application logs card on the Support tab tails the backend, the task worker and the Slack listener. New lines appear within a couple of seconds.

  • Errors show in red and warnings in amber, so problems stand out as you scroll.
  • Filter by minimum level, such as errors only, or by any text.
  • Pause freezes the view while you read and Resume catches up. The view follows the newest lines unless you scroll up.
  • Download log saves the log file as it stands on disk, and the download reaches the audit log.

The viewer reads the application processes only. For anything at the container or host level, use the host collector.

Checking the container versions

DFIRe ships as two containers and both report their version. You can read them in My Profile and on Settings → License & Updates, backend and frontend side by side.

If the two run different releases, because an update pulled one image and not the other, both places show a warning telling you to bring them to the same release. A mismatch is a common cause of missing features or a broken interface straight after an upgrade, so check here first when something looks wrong. See Updating DFIRe for the procedure.

← Analytics Slack and Jira →