p24-infra Docs

incident-2026-07-08-w3-login-broken-admin-password-desync

4 min read

Incident: W3 Login Broken — MongoDB Admin Password Desync — 2026-07-08

PoleWartość
IDINCIDENT-2026-07-08-002
PlatformaW3 (w3.pinbox24.com)
SevernośćP0 — logowanie całkowicie niedostępne
StatusRESOLVED (Part A) / Part B (migracja na w3_app) — STAGED, deploy zaplanowany po 17:00
Wykryto2026-07-08T08:38Z
Root cause ustalony2026-07-08T08:58Z
Hotfix wdrożony2026-07-08T09:05Z
Zweryfikowano2026-07-08T09:05Z (realny użytkownik zalogowany, luk.gaw2@gmail.com)
GH Issueradieu/p24-infra#3060 (OPEN — Part B zamknie)

Symptom

Użytkownik zgłosił: nie może zalogować się do w3.pinbox24.com. POST /api/auth wisiał bez odpowiedzi (timeout), /api/i18n/langs zwracał HTTP 422.

Oś czasu

Czas (UTC)Zdarzenie
~07:14v32-prod force-recreate (deploy patchy persistent-patches/) — env plik backend-environment.env też dotknięty w tym oknie
~08:00 (szacunkowo)Rotacja MONGODB_RS0_ADMIN_PASSWORD na rs0 (bms-2/bms-3) — notatka w rotation logu zakładała “Pinbox24 w3/w4 unaffected — use dedicated w3_app/w4_app users”
08:38Pierwsze MongoError: Authentication failed w PM2 logu v32-prod
08:56Sesja Claude rozpoczyna diagnostykę na prośbę użytkownika (“check why i cant login into w3”)
08:58Root cause potwierdzony: MONGODB_URL/PMONGODB_URL w backend-environment.env łączą się jako admin/authSource=admin (nie w3_app — znany dług #3060), a wdrożone hasło jest nieaktualne
09:00Zweryfikowano: aktualne mongodb_rs0_admin_password z SOPS poprawnie autoryzuje się na rs0 — problem jest tylko w desynchronizacji pliku na bms-1
09:02Backup backend-environment.env, patch MONGODB_URL+PMONGODB_URL poprawnym hasłem (URL-encoded), force-recreate v32-prod
09:05Mongoose connected, POST /api/auth 200, realny użytkownik zalogowany i przegląda oferty — Part A RESOLVED (~27 min przestoju)
09:06–09:15Part B: utworzono/zaktualizowano dedykowanego użytkownika MongoDB w3_app (readWrite na w3_db), nowe 32-znakowe hasło CSPRNG zapisane w secrets/bms-servers.env.sops jako W3_APP_MONGODB_PASSWORD, zweryfikowano db.auth('w3_app', ...) → OK. Nie wdrożono jeszcze na bms-1 — użytkownik poprosił o przełączenie env + restart kontenera dopiero po 17:00 (poza godzinami szczytu)

Root cause

Bezpośrednia przyczyna

v32-prod na bms-1 łączy się z MongoDB jako user admin (nie dedykowany w3_app) — to jest znany, nierozwiązany dług z issue #3060. Gdy hasło admina rs0 zostało zrotowane, rotacja nie zaktualizowała backend-environment.env na bms-1, bo notatka w rotation logu błędnie zakładała że W3 używa w3_app i jest nią nietknięta.

Głębsza przyczyna — wzorzec się powtarza

To już drugi incydent tego typu (patrz incident-2026-07-01-w3-upload-broken.md — root cause tamtego incydentu to też rotacja mongodb_rs0_admin_password wymuszająca force-recreate W3). Dopóki W3 dzieli konto admin z resztą infrastruktury, każda przyszła rotacja hasła admina rs0 ma szansę złamać W3, jeśli deployment na bms-1 nie zostanie ręcznie zsynchronizowany w tym samym oknie.

Zmienione pliki / kontenery (Part A — hotfix)

Uwaga (#4985): ścieżka /root/builds/pn3C9eHo/... poniżej jest zapisem stanu z 2026-07-08 i celowo pozostaje niezmieniona. Aktualny, autorytatywny katalog build W3 (per zadanie sync-pinbox24-w3 w .github/workflows/secrets-sync.yml) to /home/gitlab-runner/builds/eZQeLfuJe/0/pinbox24/p24-v-3.2 — nie edytuj katalogu pn3C9eHo przy zmianach produkcyjnych.

KontenerPlikZmianaBackup
v32-prod na bms-1/root/builds/pn3C9eHo/0/pinbox24/p24-v-3.2/backend-environment.envMONGODB_URL + PMONGODB_URL: stare (nieaktualne) hasło admina → aktualne hasło z SOPS mongodb_rs0_admin_password (URL-encoded)backend-environment.env.bak.<timestamp> na bms-1

Zmiany przygotowane, jeszcze niewdrożone (Part B — długoterminowy fix)

ZasóbZmianaStatus
MongoDB rs0, w3_dbUser w3_app (readWrite) — hasło zmienione na nowe 32-char CSPRNG✅ utworzony/zaktualizowany, db.auth() zweryfikowany OK
secrets/bms-servers.env.sopsNowy klucz W3_APP_MONGODB_PASSWORD✅ zapisany, canary OK
bms-1 backend-environment.envMONGODB_URL/PMONGODB_URL: admin/authSource=admin → w3_app/authSource=w3_db⏳ NIE wdrożone — zaplanowane po 17:00 (2026-07-08), na prośbę użytkownika

Weryfikacja fix (Part A)

PM2 log v32-prod 09:05 UTC:
Mongoose connecting
Mongoose connected
Mongoose connection opened
connect to Mongo.
POST /api/auth 200 25601 - 76.178 ms
GET /api/profile/contactData 200 715 - 47.463 ms   Auth user (email: luk.gaw2@gmail.com, userId: 5aa625303be58b5aee67792a)
GET /api/i18n/langs 200 2084 - 39.748 ms

HTTP: https://api.w3.pinbox24.com/api/i18n/langs → 200

Długoterminowy fix

Part B (przygotowany, deploy po 17:00 dzisiaj): przełączyć v32-prod na dedykowanego użytkownika w3_app zamiast dzielonego admin, tak aby przyszłe rotacje hasła admina rs0 nie mogły już złamać logowania W3. Zamyka #3060.

Kroki do wykonania po 17:00 (ten sam wzorzec co Part A hotfix, ale docelowe dane logowania):

  1. Backup backend-environment.env
  2. Patch MONGODB_URL/PMONGODB_URL → mongodb://w3_app:<encoded>@145.239.133.104,51.68.155.224/w3_db?replicaSet=rs0&authSource=w3_db
  3. docker-compose up -d --force-recreate backend
  4. Weryfikacja: /api/i18n/langs → 200, PM2 log „Mongoose connected”, brak „Authentication failed”
  5. Jeśli regresja — rollback do konfiguracji admin (Part A, już potwierdzona jako działająca) z backupu
  6. Po potwierdzeniu: zamknąć #3060, zaktualizować docs/playbooks/pinbox24-w3-operations.md (tabela Secrets/Credentials + Known issues)

Rollback

Part A (już wdrożone): backup backend-environment.env.bak.<timestamp> na bms-1 sprzed patcha.

Part B (jeśli po wdrożeniu wystąpi regresja): przywrócić plik env z backupu sprzed Part B (utworzonym tuż przed patchem po 17:00) i force-recreate — wraca się do działającej konfiguracji admin z Part A.

Lekcje

  1. Rotation runbooks muszą weryfikować rzeczywistą konfigurację, nie zakładać jej. Notatka “w3/w4 unaffected — use dedicated app users” w rotation logu była nieaktualna/błędna względem stanu faktycznego na serwerze — to spowodowało desynchronizację.
  2. To już 2. wystąpienie tego wzorca (patrz incident-2026-07-01-w3-upload-broken.md). Part B (migracja na w3_app) jest jedynym sposobem, żeby to się nie powtórzyło.
  3. Windows→Linux pipe encoding — piping wieloliniowego skryptu mongosh przez ssh ... "mongosh --quiet" bez wymuszenia $OutputEncoding = UTF8Encoding($false) powodował MongoServerError: Error preflighting UTF-8 conversion po stronie serwera. Ustawienie UTF-8 output encoding przed pipe rozwiązuje problem — dodać do playbooków używających tego wzorca zamiast tymczasowych plików + scp.
  4. PowerShell tool state nie przenosi się między wywołaniami — zmienne $env:* ustawione w jednym wywołaniu PowerShell znikają w następnym. Operacje multi-step z sekretami (generuj hasło → użyj → zapisz do SOPS) muszą być w jednym wywołaniu.
  5. Monitoring gap — brak alertu na MongoError: Authentication failed w PM2 logach W3/W4. Dodać log-based alert (Mezmo?) dla tego wzorca, żeby wykrywać przed zgłoszeniem użytkownika.

Graph View

Backlinks