v1.8.0

Added

• Traefik's timeouts on the HTTPS entry point can be set from .env.
  TRAEFIK_READ_TIMEOUT, TRAEFIK_WRITE_TIMEOUT and TRAEFIK_IDLE_TIMEOUT
  default to Traefik's own values (60s, 0s, 180s), so nothing changes unless
  you set them. Traefik reads its static configuration from one source, here
  the command in the compose file, and an override file can only replace that
  command whole; a variable is the way to tune it and keep taking updates.
  The same change was asked for in the Keycloak template, and every template in the fleet gets it at once.

v1.7.8

Fixed

• Webmail no longer carries its own Traefik router. It had the same
  Host() rule as front's router and no priority, so Traefik chose between
  them at every start; when it chose webmail, /admin/ and /sso/login
  answered 302 to Roundcube's sso.php and then 404 for as long as the stack
  ran. Front serves /webmail itself, with the single sign-on, which is the
  only route Mailu documents. Found by the clean-machine drill, which saw it
  on roughly one cold start in three, and confirmed by reading the two
  routers side by side.

• mailu-restore-data.sh restarts front after the data is back, as a
  precaution: front resolves admin and imap once at start, and the two
  are stopped and started together by the restore. The clean-machine drill saw
  /admin/ answer through webmail after a restore, then saw the same on a
  fresh start with no restore at all, so the restart is not a fix for that;
  the cold-start fault is still open and the drill stays red until it is
  understood.

Changed

• ghcr.io/mailu/webmail:2024.06.58 moved to ghcr.io/mailu/webmail:2024.06.59. The freshness check reported the lag; the deploy job booted the stack on the new image before this landed.
• ghcr.io/mailu/radicale:2024.06.58 moved to ghcr.io/mailu/radicale:2024.06.59. The freshness check reported the lag; the deploy job booted the stack on the new image before this landed.
• ghcr.io/mailu/postfix:2024.06.58 moved to ghcr.io/mailu/postfix:2024.06.59. The freshness check reported the lag; the deploy job booted the stack on the new image before this landed.
• ghcr.io/mailu/unbound:2024.06.58 moved to ghcr.io/mailu/unbound:2024.06.59. The freshness check reported the lag; the deploy job booted the stack on the new image before this landed.
• ghcr.io/mailu/oletools:2024.06.58 moved to ghcr.io/mailu/oletools:2024.06.59. The freshness check reported the lag; the deploy job booted the stack on the new image before this landed.
• ghcr.io/mailu/dovecot:2024.06.58 moved to ghcr.io/mailu/dovecot:2024.06.59. The freshness check reported the lag; the deploy job booted the stack on the new image before this landed.
• ghcr.io/mailu/nginx:2024.06.58 moved to ghcr.io/mailu/nginx:2024.06.59. The freshness check reported the lag; the deploy job booted the stack on the new image before this landed.
• ghcr.io/mailu/fetchmail:2024.06.58 moved to ghcr.io/mailu/fetchmail:2024.06.59. The freshness check reported the lag; the deploy job booted the stack on the new image before this landed.
• ghcr.io/mailu/rspamd:2024.06.58 moved to ghcr.io/mailu/rspamd:2024.06.59. The freshness check reported the lag; the deploy job booted the stack on the new image before this landed.
• ghcr.io/mailu/admin:2024.06.58 moved to ghcr.io/mailu/admin:2024.06.59. The freshness check reported the lag; the deploy job booted the stack on the new image before this landed.

v1.7.7

Fixed

• The restore merged instead of restoring, and CI never ran it. It
  unpacked the archive over the live data, and tar does not delete, so files
  created after the backup survived the restore. The end-to-end test did the
  clearing itself, which is how it passed while the shipped script merged. The
  script also carried the compose project, the backup directory and both
  backup names as literals. It now takes every path and name from the running
  backups container, accepts the timestamp as an argument, stops every service
  that writes what it restores, clears what the archive holds while keeping
  what the archive leaves out on purpose, and starts the services again
  whatever happens. CI runs it.

Changed

• The freshness check has its own workflow, Pin Freshness. It ran inside Deployment Verification, whose badge is the one at the top of this README. Across the fleet, nine red runs in ten were a pin one version behind - which the fleet's triage moves within the day - and a reader cannot tell that from a stack that does not boot. The badge now says whether the stack boots. The job itself is unchanged.

v1.7.6

Security

• traefik:3.7 was rebuilt upstream; the pin moved from sha256:1c32e7c36820… to sha256:24841fe2de73…. Same version, same tag, a rebuilt base image — the usual shape of a security fix in a base layer.
• clamav/clamav-debian:1.4 was rebuilt upstream; the pin moved from sha256:2463487b9370… to sha256:b12ef8fefddb…. Same version, same tag, a rebuilt base image — the usual shape of a security fix in a base layer.

Upgrading

git pull (or ./update.sh), then docker compose up -d. Containers on a refreshed image are recreated; data volumes and .env are untouched. This release was cut by fleet triage after the deploy job booted the stack on the refreshed images.

Full history in CHANGELOG.md.

v1.7.5

Security

• redis:7.4 was rebuilt upstream; the pin moved from sha256:71da9275c5f3… to sha256:c6eabf748fc7…. Same version, same tag, a rebuilt base image — the usual shape of a security fix in a base layer.

Upgrading

git pull (or ./update.sh), then docker compose up -d. Containers on a refreshed image are recreated; data volumes and .env are untouched. This release was cut by fleet triage after the deploy job booted the stack on the refreshed images.

Full history in CHANGELOG.md.

v1.7.4

Security

• traefik:3.7 was rebuilt upstream; the pin moved from sha256:f86a2cab1b5c… to sha256:1c32e7c36820…. Same version, same tag, a rebuilt base image — the usual shape of a security fix in a base layer.

Upgrading

git pull (or ./update.sh), then docker compose up -d. Containers on a refreshed image are recreated; data volumes and .env are untouched. This release was cut by fleet triage after the deploy job booted the stack on the refreshed images.

Full history in CHANGELOG.md.

v1.7.3

Security

• clamav/clamav-debian:1.4 was rebuilt upstream; the pin moved from sha256:6a7d6f2d6539… to sha256:2463487b9370…. Same version, same tag, a rebuilt base image — the usual shape of a security fix in a base layer.

Upgrading

git pull (or ./update.sh), then docker compose up -d. Containers on a refreshed image are recreated; data volumes and .env are untouched. This release was cut by fleet triage after the deploy job booted the stack on the refreshed images.

Full history in CHANGELOG.md.

v1.7.2

Changed

• update.sh names any new required variable before it moves. An update can add a required variable; docker compose up used to stop on it after the checkout, with the tree already on the new tag. The script now lists the variables that appeared in .env.example since your version and refuses, before anything has moved, when a required one is not in your .env. Names only, never values.

Upgrading

git pull (or ./update.sh). Nothing running changes: this release adds or extends the update script and touches no image pin.

Full history in CHANGELOG.md.

v1.7.1

Fixed

• Six of the fourteen pinned images were never compared against the
  registry. The freshness job iterated a list of variable names written by
  hand, and FETCHMAIL, FTS_ATTACHMENTS, OLETOOLS, REDIS, RESOLVER
  and WEBDAV were not on it. Every one is a digest pin, so the tag it names
  can be repushed under the same version and nothing would say so. One of them
  follows apache/tika:latest-full, a tag that moves by design, frozen at a
  digest nobody was watching. All six are current as of today, which is luck
  rather than a result.

Changed

• The job enumerates the pins out of the compose file instead of naming
  them. A pin that exists is a pin that is watched, and a list cannot fall
  behind the file it describes. An image built from source is skipped rather
  than looked up under a name no registry serves.

Upgrading

Nothing to do on a running server: this release changes CI only. git pull picks it up.

Full history in CHANGELOG.md.

v1.7.0

Fixed

• A backup interrupted halfway no longer looks like a good one. The loop
  already renamed a failed dump to .failed so nothing would restore from it,
  but that rename only runs if the shell lives long enough to reach it. Stop
  the container mid-dump and it does not: the truncated file keeps the name a
  finished backup would have, and it is the newest one, which is exactly what
  the restore script and the end-to-end test pick. Every backup is now written
  to <name>.partial and renamed only after the dump succeeds, so the real
  name never exists unless the file behind it is complete. Verified by killing
  a dump in flight: before, the restore path selected a file that failed
  gzip -t; after, it finds nothing to select.