twooeyandClaude Sonnet 5
3876a6ba30
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>
51 lines
1.7 KiB
Bash
51 lines
1.7 KiB
Bash
# Copy this to .env.dev / .env.staging / .env.production and fill in real
|
|
# values for that environment. The filled-in files are gitignored — never
|
|
# commit them. Same code everywhere; only these values differ (see
|
|
# design doc §01, Environments & deployment).
|
|
#
|
|
# CAVEAT for the API keys below (DB_PASSWORD/DB_ROOT_PASSWORD are exempt —
|
|
# deploy.sh writes those into secrets/<env>/ files that bypass this
|
|
# entirely): docker compose passes these into containers via ${VAR}
|
|
# interpolation, which will silently mangle a value containing `$` followed
|
|
# by a letter (it tries to resolve it as another variable and blanks it out
|
|
# if unset). Avoid `$` in these specific values, or double it ($$) if you
|
|
# must use one — this bit us for real with a generated password once.
|
|
|
|
# --- Site ---
|
|
# (WP_ENVIRONMENT_TYPE is NOT set here — it's hardcoded per environment in
|
|
# docker-compose.{dev,staging,production}.yml so it can't go stale.)
|
|
SITE_DOMAIN=staging.example.com
|
|
SITE_URL=https://staging.example.com
|
|
SITE_TITLE="Bookstore (staging)"
|
|
|
|
# --- WordPress admin bootstrap (used only on first install) ---
|
|
WP_ADMIN_USER=admin
|
|
WP_ADMIN_PASSWORD=changeme
|
|
WP_ADMIN_EMAIL=admin@example.com
|
|
|
|
# --- Database ---
|
|
DB_NAME=bookstore
|
|
DB_USER=bookstore
|
|
DB_PASSWORD=changeme
|
|
DB_ROOT_PASSWORD=changeme
|
|
WP_TABLE_PREFIX=wp_
|
|
|
|
# --- Backups (deploy/backup.sh) ---
|
|
BACKUP_DIR=./backups
|
|
BACKUP_REMOTE=
|
|
BACKUP_RETENTION_DAYS=14
|
|
|
|
# --- Supplier adapters (design doc §04) ---
|
|
# staging: gutenberg_test production: booksrun,ingram
|
|
ACTIVE_SUPPLIER_ADAPTERS=gutenberg_test
|
|
BOOKSRUN_API_KEY=
|
|
INGRAM_API_KEY=
|
|
INGRAM_ACCOUNT_ID=
|
|
|
|
# --- Payments (Helcim) ---
|
|
HELCIM_API_TOKEN=
|
|
HELCIM_ACCOUNT_ID=
|
|
|
|
# --- Marketing ---
|
|
MAILERLITE_API_KEY=
|