root/ubuntu-post-install
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Fix vaultwarden SMTP false-positive and mattermost DB password mismatch

Browse Source 
vaultwarden: SMTP_PORT defaulted to "587" and SMTP_SECURITY was a
hardcoded "starttls" literal in the .env template, written
unconditionally regardless of whether SMTP_HOST was ever provided.
Confirmed live: skipping SMTP entirely (blank SMTP_HOST) still wrote
real values for those two, and Vaultwarden reads that as "some SMTP
config is present," refusing to start ("Both SMTP_HOST and SMTP_FROM
need to be set") even with host/from genuinely blank. Both now stay
empty unless SMTP_HOST is actually set.

mattermost: DB_PASS/MM_SECRET were only reused from the existing .env
when MODE=update — a "fresh" reinstall always generated a new
POSTGRES_PASSWORD. Confirmed live: choosing fresh after removing only
the mattermost app container (not the whole directory) regenerates the
password in .env while db/'s existing Postgres data still enforces the
OLD one from its first init (the entrypoint skips re-init on existing
data), causing "password authentication failed for user mattermost" on
every start. Whether db/ already has real data is what actually
determines whether the old password is still live, not which reinstall
mode was chosen — reuse the existing secrets whenever db/ is non-empty,
regardless of MODE.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01H4k6J1qXXyYxhGEgnJaMvn
This commit is contained in:
Claude
2026-08-11 03:22:53 +00:00
parent e01440aef6
commit 74628f3736
2 changed files with 28 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files
services/mattermost.sh
+15 -6
View File
@@ -322,13 +322,22 @@ install_mattermost() {
ensure_docker_dir_ownership "$DIR"
cd "$DIR" || return 1
# Reuse existing secrets on update — Postgres's volume keeps the password
# from its first init, so overwriting .env with a fresh one locks
# Mattermost out of its own database. Confirmed this was previously
# unconditional (regenerated every single rerun, silently breaking the DB
# connection) — fixed here as part of adding proper update detection.
# Reuse existing secrets whenever the Postgres data volume already has
# real data in it — not just when MODE=update. Confirmed live: picking
# "fresh" after removing only the mattermost APP container (docker rm,
# not the whole ~/docker/mattermost directory) regenerates
# POSTGRES_PASSWORD in a new .env while db/ still holds the OLD
# password baked in from its first init (postgres:15-alpine's
# entrypoint skips re-initializing an existing data directory, so the
# old credential is still the one actually enforced) — "password
# authentication failed for user mattermost" on every start
# afterward. Whether the data volume already has real data in it is
# what actually determines whether the old password is still live,
# not which reinstall mode was chosen.
local DB_PASS="" MM_SECRET=""
if [ "$MODE" = "update" ]; then
local _db_has_data=false
[ -d db ] && [ -n "$(ls -A db 2>/dev/null)" ] && _db_has_data=true
if [ "$MODE" = "update" ] || [ "$_db_has_data" = true ]; then
DB_PASS="$(grep '^POSTGRES_PASSWORD=' .env 2>/dev/null | cut -d= -f2-)"
[ "$_HAD_EMBEDDED_COTURN" = true ] && MM_SECRET="$(grep '^COTURN_SECRET=' .env 2>/dev/null | cut -d= -f2-)"
fi