[DOCS] TLS-DB nis2: verità topologia (fpm→host SOCKET) + tentativo socket→TCP fallito su path fpm
CONTEXT/runbook aggiornati con le conclusioni 2026-06-10 sera: - L'app HTTP (php-fpm) usa il MySQL HOST via UNIX SOCKET (localhost), NON il container (la "scoperta container" precedente era basata sul path CLI = falso positivo). - TLS su socket non si applica e rompe (outage rientrato: rm flag + USR2). - Switch socket→TCP via vault-net (172.30.0.1): CLI(root) OK ma fpm(www-data) esce con source=gateway → masquerade → 135.x → 1045. Switch NON eseguito (sarebbe outage). - Lezione: validare SEMPRE sul path fpm reale (diag servito da php-fpm), mai CLI/docker exec. - Pre-equip codice resta committato e inerte (flag OFF); attivabile quando il path TCP fpm sarà grantabile (bind 172.21 in finestra con restart MySQL). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
DevEnv nis2-agile
co-authored by
Claude Opus 4.8
Claude Opus 4.8
parent
4d89b1e04b
commit
d98d52ed58
@@ -2,6 +2,40 @@
|
||||
|
||||
> Il 2026-05-29 ci sono state DUE sessioni: **pomeriggio** e **mattina** (TRPG). Il 2026-05-30 sessione lunga: gap competitivi P1/P2/P3 + connettori + review multi-agente + fix.
|
||||
|
||||
## 2026-06-10 — TLS-DB pre-equip (VIGILE) + SCOPERTA split DB host/container
|
||||
|
||||
> Task da CLAUDE.md (cima, "VIGILE 2026-06-10"): pre-equip PHP-PDO/CA per TLS-in-transito DB, gated default-OFF, **senza** enforce (l'`ALTER USER` è di VIGILE). Eseguito con precisione chirurgica + 2 agenti background di review.
|
||||
|
||||
### Fatto (commit `4d89b1e`)
|
||||
- **`application/config/database.php`** → `Database::sslOptions()`: TLS gated (env `DB_SSL=true` **o** flag-file `application/config/.db_ssl_on`), **DEFAULT OFF**. `PDO::MYSQL_ATTR_SSL_CA` + `VERIFY_SERVER_CERT=false`. **Fail-safe**: CA assente → resta in chiaro + `error_log` (un VERIFY=false senza CA in mysqlnd connette IN CHIARO silenziosamente — doc §11). Merge con `+` (preserva chiavi-intere PDO, §14).
|
||||
- **Verificato locale** (no DB): `php -l` + reflection test → OFF ⇒ `base + [] === base` (**inerzia provata**, zero regressione); ON+CA-mancante ⇒ `[]`; ON+CA ⇒ chiavi `1009`/`1014`.
|
||||
- **2 agenti background**: (a) censimento connessioni → **runtime `application/` coperto 100%** da `Database::getInstance()` (0 raw PDO); 9 `new PDO` raw solo in NON-prod (`simulate-*.php` come root → ininfluenti; `scripts/import-feedback-to-nexus.php:112/114` cross-DB e `public/test-runner.php:529` da gestire prima dell'enforce SE usano nis2_user). (b) review adversariale → **SICURO default-OFF, nessun bug**.
|
||||
- `.gitignore`: `application/config/.db_ssl_on` + `db-ca.pem`. Runbook completo: **`docs/TLS_DB_PREEQUIP_NIS2.md`**.
|
||||
|
||||
### 🔴 SCOPERTA CRITICA: split DB host vs container (confermata da VIGILE)
|
||||
- La recon (`docker exec nis2-app php -r 'Database::getInstance...'`) ha rivelato: **l'app nis2 usa il DB CONTAINER** (`DB_HOST=db → 172.21.0.4`, server `fd63ec13e889`, **MySQL 8.0.45**), **NON il MySQL host** (8.0.46). Questo **CORREGGE la memoria `project_db_topology`** (diceva "host"). `Ssl_version=[]` (chiaro), `nis2_user@%`.
|
||||
- **VIGILE ha confermato lo split + fixato**: il cron `sso-password-sync` aggiornava le **copie host MORTE** di `nis2_agile_db` (+ lg231/wms) mentre le app usano i container → password SSO non arrivavano. Fixato (sync sul container reale via `docker exec`). taxai resta su host (la sua app usa davvero l'host). trpg/sustainai intatti.
|
||||
- **Conseguenza sul mio lavoro 2026-05-29**: migrazioni **020/021/022** erano state applicate via `mysql -h localhost` = copia host morta → **mancanti nel container** → v1.7.0 NON funzionava in prod. **VIGILE le ha ri-applicate al container** (backup+idempotenti) → verificato `assets.relevance_score`/`incidents.nis2_incident_type`/`incident_pir` ✅. Schema v1.7.0 ora corretto in prod.
|
||||
- ⚠️ Per il TLS: **CA + `ALTER USER nis2_user@% REQUIRE SSL` vanno sul CONTAINER `db`** (non host). Comandi corretti nel runbook.
|
||||
|
||||
### Aperti (in mano a VIGILE — DB = solo Agile)
|
||||
1. **Benassati/org129**: assente nel container (host id=4, SSO #232); membership org129=0 sia host sia container. Stato voluto comunicato: **super_admin (NO declassare)** + **org_admin membro org 129** nel CONTAINER, SSO-linked. NB `add-agile-user.php` crea i nuovi come `org_admin` → NON usarlo as-is per lui; probabile gap provisioning SSO nel container. VIGILE inserisce da contesto `DB_HOST=db`.
|
||||
2. **Riconciliazione migrazioni 023→036**: applicate (sessioni 05-30/05-31) via `mysql -h localhost` = path host → **da verificare/ri-applicare sul container** come 020-022. Sentinelle per-migrazione fornite a VIGILE (tabella `docs/TLS_DB_PREEQUIP_NIS2.md` + chat). Offerto script SQL unico di reconciliation (information_schema) — da generare se richiesto.
|
||||
3. **Enforce TLS**: di VIGILE, con 3-sì, dopo CA distribuito sul container + verifica sul path reale (`Ssl_version=TLSv1.3`, lezione §16 "no test sintetici").
|
||||
|
||||
### Accesso
|
||||
Chiave SSH effimera in `.ssh-temp/` (rigenerata dall'utente, validità ~3h). Devenv NON raggiunge il DB prod direttamente: solo via SSH host (`root@172.18.0.1` o `135.181.149.254`). Push Gitea bloccato sul token (`git-login` interattivo) — commit locali, push a cura host/VIGILE.
|
||||
|
||||
### 🔴🔴 AGGIORNAMENTO SERA — la "scoperta container" era SBAGLIATA; verità: fpm→HOST via SOCKET
|
||||
> Le conclusioni "container DB" qui sopra sono **superate**. Verificato col **path fpm reale** (diag PDO servito da php-fpm, NON `docker exec` che è CLI):
|
||||
- **L'app HTTP (php-fpm/www-data) usa il MySQL HOST `dfm-dev` (8.0.46) via UNIX SOCKET** (`localhost`, env non propagato ai worker). Lo schema v1.7.0 **è presente sul host** (le migrazioni 020/021/022 del 29/5 via `mysql -h localhost` erano sul DB GIUSTO). Il `docker exec nis2-app php` (`DB_HOST=db`→container 8.0.45) è solo il path **CLI**, secondario. Memoria `project_db_topology` **ri-corretta** (fpm→host socket; CLI→container).
|
||||
- **OUTAGE causato + risolto**: VIGILE ha attivato CA+flag+`REQUIRE SSL` (sul container) → ma **TLS su UNIX socket non si applica e ROMPE** (`[2002] Cannot connect to MySQL using SSL`) → app giù (login 500). **Fix**: `rm application/config/.db_ssl_on` + `kill -USR2 1` → ripristino. VIGILE poi: **NIS2 🔵 escluso dall'enforce (caso socket), container revertito a baseline, app verde**.
|
||||
- **Tentativo switch socket→TCP (per allinearlo agli altri)**: VIGILE ha aperto un path TCP via **vault-net** (`172.30.0.1`, host MySQL già in ascolto lì) + grant `nis2_user@'172.30.%'`. **MA il path fpm reale FALLISCE**: prova affiancata 3+3 → **CLI** (root) `getsockname=172.30.0.9` → `nis2_user@172.30.0.9` OK; **fpm** (www-data) `getsockname=**172.30.0.1**` → MySQL vede **135.181.149.254** (IP pubblico) → **1045**. Causa probabile: **policy-routing/NAT per-uid** (www-data instradato via gateway). Il collaudo "OK" di VIGILE era **CLI = falso positivo**. → **switch NON eseguito** (sarebbe outage). Palla a VIGILE: grant `@'135.181.149.254'` (quick) o fix routing per-uid; poi ri-probo da **fpm** prima di switchare.
|
||||
- **Stato finale**: app **verde** (socket clear), pre-equip TLS **inerte** (flag OFF), `db-ca.pem` presente ma inerte. Patch codice committato (`4d89b1e`), corretto e pronto; **non attivabile finché l'app è su socket / il TCP fpm non è grantabile**.
|
||||
- ⚠️ **Lezione ricorrente della sera**: validare SEMPRE sul path **fpm reale** (diag servito da php-fpm: login/business), **mai** `docker exec`/CLI né `/health` — CLI e fpm divergono (DB_HOST, source IP, opcache).
|
||||
|
||||
---
|
||||
|
||||
## 2026-06-01 — Modulo Gap Analysis ACN + review + landing (prod v1.13.0, ahead 0)
|
||||
|
||||
> ⚠️ EMAIL ancora DISABILITATE (`EMAIL_SENDING_ENABLED=false`, solo dati demo). Vedi sezione 2026-05-31 + memoria `project_email_killswitch`.
|
||||
|
||||
Reference in New Issue
Block a user