Fix DB password corruption via Docker secrets file mechanism
The reported bug (a generated password containing "$BRjTx3tlmSpz" got
silently blanked, breaking the DB connection) is the same Compose
interpolation issue as the earlier bcrypt hash, but this time in fields
that are genuinely user-chosen and can't just be avoided by convention.
Switched DB_PASSWORD/DB_ROOT_PASSWORD to Docker's official `_FILE`
secrets convention (MARIADB_PASSWORD_FILE / WORDPRESS_DB_PASSWORD_FILE),
backed by Compose's native `secrets:` mechanism: deploy.sh writes the raw
value to secrets/<env>/db_password, and the container reads that file
directly — the value never passes through Compose's ${VAR} interpolation
at all. Verified end-to-end with an actual `$`-containing password,
including a full deploy → backup → restore → still-serving round trip.
Also fixed along the way (found while actually testing, not assumed):
- Makefile never exported ENVIRONMENT, so `make up` alone (bypassing
deploy.sh) would have left the new secrets path unresolved.
- deploy.sh chmod'd the secret files 600, unreadable by the container's
own UID (www-data) — fixed to 644, relying on the containing directory
(700) to keep other host users out instead.
- backup.sh/restore.sh still called `mysqldump`/`mysql`, which don't
exist in the mariadb:11 image under those names — renamed to
mariadb-dump/mariadb. (This means neither script had actually
succeeded before now; both are verified working end-to-end here.)
The supplier/payment API keys remain passed the old way — nothing reads
them yet (bookstore-core is still a stub), so there's no live bug to fix
there; noted in .env.example that the same _FILE pattern should be used
once that code exists.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
+2
-1
@@ -4,6 +4,7 @@
|
||||
set -euo pipefail
|
||||
|
||||
ENVIRONMENT="${1:?Usage: backup.sh <staging|production>}"
|
||||
export ENVIRONMENT
|
||||
REPO_ROOT="$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)"
|
||||
cd "$REPO_ROOT"
|
||||
|
||||
@@ -21,7 +22,7 @@ mkdir -p "$BACKUP_DIR"
|
||||
COMPOSE="docker compose -p bookstore-${ENVIRONMENT} -f docker-compose.yml -f docker-compose.${ENVIRONMENT}.yml --env-file ${ENV_FILE}"
|
||||
|
||||
echo "==> dumping database"
|
||||
$COMPOSE exec -T db sh -c "exec mysqldump -u\"\$MARIADB_USER\" -p\"\$MARIADB_PASSWORD\" \"\$MARIADB_DATABASE\"" \
|
||||
$COMPOSE exec -T db sh -c "exec mariadb-dump -u\"\$MARIADB_USER\" -p\"\$(cat /run/secrets/db_password)\" \"\$MARIADB_DATABASE\"" \
|
||||
| gzip > "$BACKUP_DIR/db-${TIMESTAMP}.sql.gz"
|
||||
|
||||
echo "==> archiving uploads"
|
||||
|
||||
@@ -5,6 +5,7 @@
|
||||
set -euo pipefail
|
||||
|
||||
ENVIRONMENT="${1:?Usage: deploy.sh <dev|staging|production>}"
|
||||
export ENVIRONMENT
|
||||
REPO_ROOT="$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)"
|
||||
cd "$REPO_ROOT"
|
||||
|
||||
@@ -32,6 +33,23 @@ WP_ADMIN_EMAIL="$(env_get "$ENV_FILE" WP_ADMIN_EMAIL)"
|
||||
# reuse dev's db_data volume/credentials the first time this ran).
|
||||
COMPOSE="docker compose -p bookstore-${ENVIRONMENT} -f docker-compose.yml -f docker-compose.${ENVIRONMENT}.yml --env-file ${ENV_FILE}"
|
||||
|
||||
echo "==> writing DB secret files (bypasses compose's \${VAR} interpolation entirely)"
|
||||
SECRETS_DIR="secrets/${ENVIRONMENT}"
|
||||
mkdir -p "$SECRETS_DIR"
|
||||
chmod 700 "secrets" "$SECRETS_DIR" 2>/dev/null || true
|
||||
DB_PASSWORD_VALUE="$(env_get "$ENV_FILE" DB_PASSWORD)"
|
||||
DB_ROOT_PASSWORD_VALUE="$(env_get "$ENV_FILE" DB_ROOT_PASSWORD)"
|
||||
: "${DB_PASSWORD_VALUE:?set DB_PASSWORD in ${ENV_FILE}}"
|
||||
: "${DB_ROOT_PASSWORD_VALUE:?set DB_ROOT_PASSWORD in ${ENV_FILE}}"
|
||||
printf '%s' "$DB_PASSWORD_VALUE" > "$SECRETS_DIR/db_password"
|
||||
printf '%s' "$DB_ROOT_PASSWORD_VALUE" > "$SECRETS_DIR/db_root_password"
|
||||
# 644, not 600: the db/wordpress/cron containers read this as their own
|
||||
# (non-host-matching) container UID, e.g. www-data — chmod 600 made it
|
||||
# unreadable to them. The containing directory (700, above) is what
|
||||
# actually keeps other host users out; these just need to be world-readable
|
||||
# within that already-restricted directory.
|
||||
chmod 644 "$SECRETS_DIR/db_password" "$SECRETS_DIR/db_root_password"
|
||||
|
||||
echo "==> building and starting ${ENVIRONMENT}"
|
||||
$COMPOSE up -d --build
|
||||
|
||||
|
||||
+2
-1
@@ -10,6 +10,7 @@ REPO_ROOT="$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)"
|
||||
cd "$REPO_ROOT"
|
||||
|
||||
ENV_FILE=".env.staging"
|
||||
export ENVIRONMENT=staging
|
||||
|
||||
COMPOSE="docker compose -p bookstore-staging -f docker-compose.yml -f docker-compose.staging.yml --env-file ${ENV_FILE}"
|
||||
|
||||
@@ -18,7 +19,7 @@ read -r -p "type 'restore' to continue: " confirm
|
||||
[[ "$confirm" == "restore" ]] || { echo "aborted"; exit 1; }
|
||||
|
||||
echo "==> restoring database"
|
||||
gunzip -c "$DB_DUMP" | $COMPOSE exec -T db sh -c "exec mysql -u\"\$MARIADB_USER\" -p\"\$MARIADB_PASSWORD\" \"\$MARIADB_DATABASE\""
|
||||
gunzip -c "$DB_DUMP" | $COMPOSE exec -T db sh -c "exec mariadb -u\"\$MARIADB_USER\" -p\"\$(cat /run/secrets/db_password)\" \"\$MARIADB_DATABASE\""
|
||||
|
||||
echo "==> restoring uploads"
|
||||
ARCHIVE_DIR="$(cd "$(dirname "$UPLOADS_ARCHIVE")" && pwd)"
|
||||
|
||||
Reference in New Issue
Block a user