francesco/termanager2
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

++ HANDOFF: PHP 8.3.36 in produzione e sulla demo, variabile provvisoria tolta

Browse Source 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
Francesco Picone
2026-10-21 18:50:17 +02:00
parent 726af6d5c3
commit 635982bf90
1 changed files with 42 additions and 31 deletions
Download Patch File Download Diff File Expand all files Collapse all files

73
HANDOFF.md
View File

@@ -10,16 +10,15 @@ Ultimo aggiornamento: **21 ottobre 2026** — si riprende da [Stato attuale](#st
## Stato attuale ## Stato attuale
**⚠️ 21 ottobre 2026 — PHP da aggiornare.** Produzione e demo girano su PHP **✅ 21 ottobre 2026 — PHP 8.3.36 su produzione e demo** (CVE-2026-109618/109619,
8.3.35, vulnerabile a CVE-2026-109618/109619 (esecuzione di codice da remoto). esecuzione di codice da remoto), con la mitigazione nel `php.ini`. Vedi
Il Dockerfile ora richiede la 8.3.36, che esce alle 14:00 UTC del 21/10; nel
frattempo c'è una mitigazione nel `php.ini`. Vedi
[Sicurezza: PHP](#sicurezza-php-cve-2026-109618--cve-2026-109619-21-ottobre-2026). [Sicurezza: PHP](#sicurezza-php-cve-2026-109618--cve-2026-109619-21-ottobre-2026).
**Produzione** (`main` → compose `termanager2-core-production`) in esercizio **Produzione** (`main` → compose `termanager2-core-production`) in esercizio
su Dokploy dal 19 ottobre 2026. Ultimo rilascio: `d3314a9` (proclamatori senza su Dokploy dal 19 ottobre 2026. Ultimo rilascio: `1ddb973` del 21/10, ore
contatti, il link si copia o si condivide). Backup fatti prima dei rilasci in 18:48 (solo la correzione di PHP sopra il rilascio del 19/10: proclamatori
`/etc/dokploy/termanager2-backups/` sul server. senza contatti, il link si copia o si condivide). Backup fatti prima dei
rilasci in `/etc/dokploy/termanager2-backups/` sul server.
**Demo** (`dev` → compose `termanager2-core-demo`, **Demo** (`dev` → compose `termanager2-core-demo`,
`demo-termanager.pyconetwork.it`): avanti di una ventina di commit, tutti `demo-termanager.pyconetwork.it`): avanti di una ventina di commit, tutti
@@ -153,35 +152,47 @@ Il progetto girava su 8.3.35.
php-fpm (USR2): si perde quando il container viene ricreato, e da lì vale il php-fpm (USR2): si perde quando il container viene ricreato, e da lì vale il
`php.ini` dell'immagine. *Stato dell'applicazione ai container: vedi `php.ini` dell'immagine. *Stato dell'applicazione ai container: vedi
sotto, aggiornato a ogni passo.* sotto, aggiornato a ogni passo.*
- Da fare quando `php:8.3.36-fpm` è su Docker Hub: test sulla 8.3.36, poi - **Scelta dell'utente (21/10): in produzione solo la correzione di PHP.** I
deploy di demo e produzione (vedi [Stato attuale](#stato-attuale)). Finché due commit di sicurezza sono andati su `main` con un cherry-pick (`eb756ad`
restano su 8.3.35 sono esposte. **Scelta dell'utente (21/10): in e `1ddb973`, sopra `d3314a9`); gruppi di servizio e lavori dal 20 ottobre
produzione solo la correzione di PHP.** I due commit di sicurezza (`db5772d` restano sulla demo, da rilasciare un altro giorno. Ora `main` e `dev`
e la mitigazione nel `php.ini`) vanno su `main` con un cherry-pick (branch divergono: per portare `dev` in produzione servirà un merge (i cherry-pick
locale `rilascio-php`, sopra `d3314a9`); gruppi di servizio e lavori del 20 sono già in `dev`, conflitti attesi solo in HANDOFF).
ottobre restano sulla demo, da rilasciare un altro giorno. Dopo il rilascio - **Rilascio fatto il 21/10.** Su Docker Hub il tag `php:8.3.36-fpm` è
`main` e `dev` divergono: per portare `dev` in produzione servirà un merge comparso alle 15:38 UTC ma vuoto: l'immagine per amd64 (il server) è
(i cherry-pick sono già in `dev`, conflitti attesi solo in HANDOFF). arrivata alle 16:41 UTC. Una build prima di quell'ora fallisce con "no
match for platform in manifest": per sapere se si può costruire va
controllata l'architettura, non solo il nome del tag. Poi, nell'ordine:
1. test della versione di produzione su 8.3.36: 524 PHP + 13 JS verdi;
2. backup della produzione (`prod-20261021-164333`: database, 78 MB di
`storage/app`, conteggi);
3. demo: tolta la variabile provvisoria `PHP_VERSION=8.3.35` (vedi sotto) e
ricostruita: PHP 8.3.36, così si è visto che senza variabile la build
prende la versione del Dockerfile;
4. `main` = `1ddb973`, deploy della produzione alle 16:48 UTC (uno solo:
l'autodeploy non è partito, lanciato a mano).
Verifica in produzione: PHP 8.3.36, `session.upload_progress.enabled` Off e
`session.use_strict_mode` On (dal `php.ini` dell'immagine), nessuna
migrazione in sospeso, conteggi identici al backup (274 territori, 1130
assegnazioni di cui 77 aperte, 111 proclamatori, 4 utenti, 1251 righe di
log, 35 migrazioni), login 200, container sani, nessun errore nei log.
- Il passaggio di consegne di quella sessione (`HANDOFF-chat.md`) sta nella - Il passaggio di consegne di quella sessione (`HANDOFF-chat.md`) sta nella
cartella del progetto ma non nel repository (escluso in `.git/info/exclude`): cartella del progetto ma non nel repository (escluso in `.git/info/exclude`):
contiene dettagli dell'infrastruttura. contiene dettagli dell'infrastruttura.
**⚠️ Demo costruita con PHP 8.3.35 in via provvisoria (21/10, 14:40 UTC).** **Demo costruita per qualche ora con PHP 8.3.35 (21/10, dalle 14:40 alle
L'utente ha chiesto il deploy della demo prima che uscisse `php:8.3.36-fpm`: 16:44 UTC).** L'utente aveva chiesto il deploy della demo prima che uscisse
nelle variabili d'ambiente del compose della demo in Dokploy c'è `php:8.3.36-fpm`: nelle variabili d'ambiente del compose della demo in
`PHP_VERSION=8.3.35` (con un commento "TOGLIERE subito dopo"), che il Dokploy era stata messa `PHP_VERSION=8.3.35`, che il `docker-compose.yml`
`docker-compose.yml` passa al Dockerfile. La mitigazione ora sta passa al Dockerfile. **Tolta alle 16:44 UTC** e demo ricostruita su 8.3.36;
nell'immagine (`php.ini`). **Appena c'è la 8.3.36: togliere quella variabile nell'env della demo e della produzione non c'è più nessuna `PHP_VERSION`. Se
e rifare il deploy della demo**, altrimenti resta su 8.3.35 anche dopo la servisse di nuovo, va tolta subito dopo, altrimenti la demo resta indietro.
patch. In produzione questa via non si usa.
Stato al 21/10, 11:00 UTC circa: mitigazione nel `php.ini` del repository Prima della patch (21/10, 11:00 UTC circa) la mitigazione era stata
(su `dev` e nel branch di rilascio, non ancora deployabile finché manca **applicata anche ai container in esecuzione** di demo e produzione, ancora
l'immagine 8.3.36) e **applicata ai container in esecuzione** di demo e su 8.3.35 (`conf.d/zz-mitigazione-cve-2026-109618.ini`, php-fpm ricaricato).
produzione, entrambi ancora su PHP 8.3.35: php-fpm ricaricato (processi di Con la ricostruzione quei file sono spariti, come previsto: ora vale il
lavoro nuovi, stesso master), `php-fpm -i` riporta `php.ini` dell'immagine, con gli stessi valori.
`session.upload_progress.enabled => Off` e `session.use_strict_mode => On`,
login 200 su entrambi.
### Password del sorvegliante dal pannello Utenti (21 ottobre 2026, solo su dev) ### Password del sorvegliante dal pannello Utenti (21 ottobre 2026, solo su dev)