darkvex/bareos-webui repository overview

⁠bareos

Container images for running Bareos⁠ components with Docker and Docker Compose.

⁠Images

module	build	ubuntu size	alpine size	pull
Director
Storage Daemon
Client/File Daemon
Web UI
API

Weekly image builds run from GitHub Actions. Ubuntu images are built for linux/amd64 only. Alpine architecture coverage varies by Bareos version — linux/amd64 is always available, and linux/arm64/v8 is available for every Alpine version:

amd64 installs Bareos straight from Alpine's official community repository. arm64/v8 for Bareos 23/24/25 installs a package built by this repo's bareos-alpine-packages/ pipeline; see bareos-alpine-packages/README.md for details.

⁠Supported Tags

bareos-director:

bareos-client, bareos-storage, and bareos-webui:

bareos-api:

The currently published api/23-alpine through api/25-alpine images are built from python:3.14-alpine and install the bareos-restapi PyPI package pinned to that Bareos version; only the latest version (currently 24) also gets the bare 24, alpine, and latest tags.

The api/22-alpine directory is present in the source tree but not built or published: that bareos-restapi release pulls in a pydantic version its model code can't parse (fails on import with PydanticSchemaGenerationError), while 23+ import cleanly.

⁠Deprecated Tags

Bareos 22 has been dropped from active maintenance. The tags below remain published and pullable exactly as they are today, but will not be rebuilt, re-tagged, or patched for new CVEs. Use Bareos 23, 24, or 25 for actively maintained images.

⁠Version Support

Ubuntu images support linux/amd64 only. Bareos 23-25 Alpine images support linux/amd64 and linux/arm64/v8; linux/arm/v7 is no longer built. Both bundled compose examples use PostgreSQL 17. Catalog servers PostgreSQL 16, 17 and 18 are supported (the director's pg_dump is 18, except 23-alpine, whose Alpine 3.21 base only has the 17 client, so it supports 16 and 17 only).

Upstream barcus/bareos (the project this repo was forked from) still publishes Bareos 18–22 images (barcus/bareos-director:21-ubuntu, etc.) — a fallback if you need one of these versions, not a recommendation: its 20/21 tags were last pushed 2023-04-30 and its 22-alpine 2025-01-12, none of them have been rebuilt since, there's no 22-ubuntu there, and nothing for Bareos 16 or 17 exists anywhere, upstream included. Bareos removed the MySQL catalog backend upstream in version 21 — see Database Migration below for moving an existing MySQL catalog to PostgreSQL.

Bareos 23 removed the dbdriver directive from the catalog resource. If you are upgrading from Bareos 22 or older, remove any dbdriver = "postgresql" line from /etc/bareos/bareos-dir.d/catalog/MyCatalog.conf before starting the Director. Leaving it in place causes a fatal config error:

bareos-dir: CONFIG ERROR at lib/parse_conf_state_machine.cc:161
Config error: Keyword "dbdriver" not permitted in this resource.

Existing deployments: docker-compose-alpine-pgsql.yml (the default docker-compose.yml target) now pins Bareos 25 rather than 21. If you have an existing, volume-backed deployment from that file still running Bareos 21, pulling the new images and restarting will not auto-migrate your catalog config — the entrypoint's first-run sentinel file (/etc/bareos/bareos-config.control) only unpacks the bundled default config on a genuinely first run, so an existing /data/bareos/config/director volume keeps its Bareos 21 config as-is. You must manually apply any config changes required for the Bareos 21 → 25 jump yourself (including the dbdriver removal above, if not already done) before restarting the Director against the new image.

⁠Package Releases

download.bareos.org/current/ tracks the latest Bareos release and does not provide pinned 23 or 24 Ubuntu repositories. This repo builds pinned .deb packages from upstream Bareos release tags and publishes them as GitHub Release assets.

The Ubuntu 23/24 Dockerfiles consume the package release pkg/bareos-packages-v1:

See bareos-packages/README.md⁠ for local package builds and release publishing details.

⁠Setup

Bareos Director requires:

• PostgreSQL for supported current stacks
• SMTP relay or webhook notifications for reports

Bareos Web UI requires either its Ubuntu Apache image or, for Alpine stacks, the paired PHP-FPM service used by the compose file.

Bareos Client/File Daemon and Storage Daemon have no external service dependency beyond the Director connection.

⁠Requirements

• Docker⁠
• Docker Compose⁠

⁠Usage

Copy .env.dist to .env and set every *_PASSWORD before starting the stack — they ship empty and containers refuse to start until you do; see Secrets⁠ below.

cp .env.dist .env

The bundled postgres service requires POSTGRES_INITDB_ARGS=--encoding=SQL_ASCII (already set in the compose files) because the Bareos catalog schema needs that encoding — keep it if you customize the database service.

Start the default stack:

docker compose up -d

Or choose a compose file explicitly:

docker compose -f docker-compose-alpine-pgsql.yml up -d
docker compose -f docker-compose-ubuntu-pgsql.yml up -d

Available compose files:

The compose examples store data under /data/(bareos|pgsql).

Both example stacks run PostgreSQL 17. External or self-managed catalog servers may be PostgreSQL 16, 17 or 18 (23-alpine: 16 or 17 only; see above).

Note: PostgreSQL 18 images keep data in /var/lib/postgresql/18/docker, so mount the volume at /var/lib/postgresql instead of /var/lib/postgresql/data. Moving a setup to 18 therefore needs a volume-mount change plus a pg_upgrade or dump/restore, not just an image bump.

The Alpine compose files also run a php-fpm sidecar for the WebUI. In docker-compose-alpine-pgsql.yml it uses the darkvex/bareos-webui image itself, which ships PHP-FPM listening on port 9000, started with entrypoint: ["/usr/local/sbin/php-fpm"]. The third-party images (PostgreSQL, the SMTP relay and the metrics exporter) are pinned by digest.

The WebUI, REST API and metrics ports are published on 127.0.0.1 only, so the examples don't expose them to the network by default. Put a reverse proxy with TLS in front of them, or change the port mapping (for example 8080:9100 instead of 127.0.0.1:8080:9100) if you really need direct remote access. The storage daemon port 9103 stays published on all interfaces because file daemons on other hosts connect to it.

⁠Secrets

Every *_PASSWORD variable in .env.dist ships empty. On startup, each entrypoint refuses to run if a password it needs is empty, or still equals a retired example value that used to ship in .env.dist (e.g. ThisIsMySecretDBp4ssw0rd) — this catches .env files copied from an old version of this repo, not just unset variables.

Every *_PASSWORD also has a *_FILE variant for the Docker/Kubernetes secrets convention⁠ (the same one used by the official postgres/mysql images): point it at a file containing the password instead of setting the variable directly. Setting both the plain variable and its _FILE variant for the same password is rejected. The file's contents are read as-is (trailing newlines stripped); a file containing only a newline is treated as empty and rejected.

Supported *_FILE variables:

* DB_ADMIN_PASSWORD is only required when DB_INIT=true or DB_UPDATE=true (it's only used to connect as the PostgreSQL admin user for schema init/migration) — otherwise it can be left unset.

MYSQL_ADMIN_PASSWORD has no _FILE variant: the bareos-db-migration entrypoint never reads it directly, it's only forwarded by bareos-db-migration/docker-compose.yml to the official mysql image as MYSQL_ROOT_PASSWORD, which already supports MYSQL_ROOT_PASSWORD_FILE natively — pass that instead if you need file-based secrets there.

The bundled compose files (docker-compose-*.yml) still pass passwords as plain environment: variables, not Docker Compose secrets: — if you want secrets:-based wiring, adapt the compose files yourself; the entrypoints support either since _FILE just needs a readable file path.

Rotation caveat: entrypoints only write daemon configs on first run, gated by a sentinel file (/etc/bareos/bareos-config.control or equivalent). Changing a password in .env and restarting an already-initialized container does not rotate the password baked into that daemon's config — remove the sentinel file (or edit the config directly) to pick up a new value.

⁠Access

Web UI:

http://localhost:8080

Default user is admin; the password is BAREOS_WEBUI_PASSWORD.

Bareos console:

docker exec -it bareos-dir bconsole

On Bareos 24+ images, BAREOS_WEBUI_PASSWORD is also reused as the Director's own local console password (what bconsole above authenticates with) and its tray-monitor console — those bundled resources ship with an empty password that Bareos now rejects at startup, and there's no separate .env variable for them. Unlike the WebUI's console, which is ACL-restricted (denies .sql, configure, create, delete, purge, etc.), the Director's local console has no ACL — treat this password as a full-privilege credential, not just a WebUI login.

REST API docs:

http://localhost:8000/docs

Prometheus metrics:

http://localhost:9625/metrics

Metrics are provided by bareos_exporter⁠ and should be scraped by Prometheus⁠.

⁠Verifying Images

Images published from master are signed with cosign⁠ keyless signing through GitHub Actions OIDC, and carry an SPDX SBOM and a SLSA provenance attestation. Signatures are made on image digests, so resolve the tag first and verify the digest:

image=darkvex/bareos-director:25-alpine-pgsql
digest=$(docker buildx imagetools inspect "$image" --format '{{json .Manifest}}' | jq -r .digest)

cosign verify "darkvex/bareos-director@${digest}" \
  --certificate-identity-regexp '^https://github.com/dark-vex/bareos/\.github/workflows/ci-[a-z]+\.yml@refs/heads/master$' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

cosign verify-attestation --type spdxjson "darkvex/bareos-director@${digest}" \
  --new-bundle-format \
  --certificate-identity-regexp '^https://github.com/dark-vex/bareos/\.github/workflows/ci-[a-z]+\.yml@refs/heads/master$' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

Use --type slsaprovenance to verify the provenance attestation instead of the SBOM.

Attestations are published in the Sigstore bundle format⁠, linked via the OCI 1.1 subject field, so --new-bundle-format is required to verify them. Images published before this change still carry legacy-format attestations and must be verified by omitting that flag; this transition window lasts until the old attestation tags are cleaned up.

Re-attesting the same digest (e.g. a re-run after a transient CI failure) currently appends a new referrer rather than replacing the prior one for that predicate type, so a given digest's Accessories list can carry more than one SBOM or provenance attestation over time; cosign verify-attestation still succeeds against any of them, but deduplication is not yet handled and may need a follow-up cleanup pass.

⁠Database Migration

Bareos 21 and newer do not ship the MySQL catalog backend. To migrate an existing MySQL catalog, upgrade to Bareos 20 first, then copy the catalog into PostgreSQL. This repo's own bareos-db-migration/⁠ directory has Dockerfile source but no published image — CI has never built or pushed darkvex/bareos-db-migration — so its docker-compose.yml won't pull as shipped unless you build the image yourself first (docker build -t darkvex/bareos-db-migration bareos-db-migration/). Upstream barcus/bareos publishes a working, if stale (last updated 2022-03-01), barcus/bareos-db-migration:latest image with its own compose file — see barcus/bareos's bareos-db-migration/docker-compose.yml⁠ if you want something that pulls out of the box.

If the target PostgreSQL database is empty or does not exist, the migration tool creates it. Keep .env available with the required database passwords.

The same empty-by-default, refuse-on-placeholder behavior described in Secrets⁠ applies to the migration tool's password variables (MYSQL_DB_PASSWORD, PGSQL_DB_PASSWORD, PGSQL_ADMIN_PASSWORD, each with a matching _FILE variant).

⁠Building Images

Build a specific component/version:

docker build -t bareos-director:24-ubuntu director-pgsql/24-ubuntu
docker build -t bareos-storage:24-ubuntu storage/24-ubuntu
docker build -t bareos-client:24-ubuntu client/24-ubuntu
docker build -t bareos-webui:24-ubuntu webui/24-ubuntu
docker build -t bareos-api:24-alpine api/24-alpine

For Ubuntu 23/24 images, the package release assets must exist before the build can download them.

⁠Links

• Bareos documentation⁠
• director-pgsql⁠
• storage⁠
• client⁠
• webui⁠
• api⁠