paul/picpeak
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity

feat(restore): docker-logs visibility + ADMIN_CREDENTIALS.txt restore notice

Browse Source 
Two nice-to-haves from the PR #596 review.

1. Install-from-backup logging mirrors to stdout
   The winston logger writes to /app/logs/combined.log and may not
   tee to stdout. Operators tailing `docker logs picpeak-beta-backend`
   after a `compose up` saw the migration sweep + npm notice and
   nothing about the restore. Three key events now also fire through
   `console.log` with a `[install-from-backup] ` prefix:
     - "trigger file detected → <manifest>"
     - "starting restore from <manifest>"
     - "restore completed successfully" / "FAILED — <reason>"
   Plus the "skipping — existing data" branch.
   docker-logs surface now tells the restore story without requiring
   an `exec into the container` step.

2. ADMIN_CREDENTIALS.txt flags stale creds when restore is queued
   Migration 001 detects a pending `RESTORE_ON_INSTALL` file BEFORE
   writing the fresh-install credentials file. If a trigger will fire
   on the next boot, the file now opens with a clear warning:

     ⚠️  RESTORE_ON_INSTALL TRIGGER DETECTED ⚠️
     These credentials are temporary. An install-from-backup run is
     queued to fire on the next server start, which will REPLACE
     this admin row with the one from the backup. After the restore
     completes, log in with your ORIGINAL pre-disaster credentials
     — not the ones below. If the restore fails for some reason,
     the credentials below remain valid as a fallback recovery path.

   Doesn't skip the file (so a failed restore still has the fallback
   credentials), just annotates it. Closes the maintainer's "stale
   junk credentials" observation.
This commit is contained in:
Luca
2026-06-01 21:52:38 +02:00
parent a23fa3bb12
commit 3322a1d998
2 changed files with 41 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
backend/migrations/core/001_init.js
+25 -2
View File
@@ -33,11 +33,34 @@ exports.up = async function(knex) {
// Try to save credentials to file, but don't fail if we can't
const dataDir = path.join(__dirname, '..', '..', 'data');
const setupInfoPath = path.join(dataDir, 'ADMIN_CREDENTIALS.txt');
// Detect a pending install-from-backup trigger. If one exists,
// these credentials are about to be obsoleted by the restore —
// the backup's admin row replaces this fresh-install one a few
// seconds from now. We still write the file (in case the
// restore fails and the fresh admin is the only way in) but
// annotate the top so admins reading the file after restore
// don't waste time trying credentials that no longer exist.
// Flagged on PR #596 review.
const fsSync = require('fs');
const backupRoot = process.env.BACKUP_ROOT || '/backup';
const triggerWillFire = fsSync.existsSync(path.join(backupRoot, 'RESTORE_ON_INSTALL'))
|| fsSync.existsSync(path.join(backupRoot, 'RESTORE_ON_INSTALL.txt'));
const restoreNotice = triggerWillFire ? `
⚠️ RESTORE_ON_INSTALL TRIGGER DETECTED ⚠️
These credentials are temporary. An install-from-backup run is queued
to fire on the next server start, which will REPLACE this admin row
with the one from the backup. After the restore completes, log in
with your ORIGINAL pre-disaster credentials — not the ones below.
If the restore fails for some reason, the credentials below remain
valid as a fallback recovery path.
` : '';
const setupInfo = `
========================================
PicPeak Admin Credentials
========================================
========================================${restoreNotice}
Your admin account has been created with these credentials: