From a1387986eaf7a6e36741b0f689b5e9fb55133c1c Mon Sep 17 00:00:00 2001 From: michele Date: Sun, 24 May 2026 21:31:54 +0000 Subject: [PATCH] Stabilize node refresh maintenance flow --- app/Filament/Pages/Supporto/Modifiche.php | 4 ++ docs/support/AGGIORNAMENTI-STAGING-GIT.md | 20 +++++++ docs/support/BUG-RISOLTI-E-VALIDAZIONI.md | 8 +++ .../supporto/aggiornamento-launcher.blade.php | 60 ++++++++++++------- 4 files changed, 70 insertions(+), 22 deletions(-) diff --git a/app/Filament/Pages/Supporto/Modifiche.php b/app/Filament/Pages/Supporto/Modifiche.php index cc5b046..cdfa837 100644 --- a/app/Filament/Pages/Supporto/Modifiche.php +++ b/app/Filament/Pages/Supporto/Modifiche.php @@ -2058,6 +2058,10 @@ private function startNodeRefreshJob(bool $skipMaintenance = false, bool $skipCo : 'Flusso autonomo avviato: backup, maintenance con pagina 503 personalizzata, sync da Gitea, rebuild applicativo e riapertura nodo.')) ->success() ->send(); + + if (! $skipMaintenance && ! $skipComposer) { + $this->dispatch('supporto-update-enter-maintenance', url: request()->fullUrl(), delay: 1200); + } } private function loadManualSections(): void diff --git a/docs/support/AGGIORNAMENTI-STAGING-GIT.md b/docs/support/AGGIORNAMENTI-STAGING-GIT.md index 905b2f5..316159d 100644 --- a/docs/support/AGGIORNAMENTI-STAGING-GIT.md +++ b/docs/support/AGGIORNAMENTI-STAGING-GIT.md @@ -158,6 +158,26 @@ ## Emergenza: pagina Supporto > Modifiche in out-of-memory Per la manutenzione utente finale, il nodo deve servire una `503` dedicata con refresh automatico sulla stessa URL. In questo modo l utente vede solo il messaggio di aggiornamento e rientra da solo alla pagina richiesta quando il deploy termina, senza restare mischiato a pagine parziali o a tracce tecniche. +Se il refresh resta `behind 1` dopo il click, controllare subito `storage/app/support/generated/git-sync-last.json` e l ultimo log in `storage/app/support/update-jobs/*.log`: un caso reale verificato e stato `Permission denied` su `resources/views/errors/.503.blade.php` durante `rsync`. + +Controllo rapido permessi: + +```bash +ls -ld /var/www/netgescon/resources/views/errors +ls -l /var/www/netgescon/resources/views/errors/503.blade.php +``` + +Correzione minima sul nodo quando il processo web usa il gruppo `www-data`: + +```bash +chgrp www-data /var/www/netgescon/resources/views/errors +chmod 2775 /var/www/netgescon/resources/views/errors +chgrp www-data /var/www/netgescon/resources/views/errors/503.blade.php +chmod 664 /var/www/netgescon/resources/views/errors/503.blade.php +``` + +Dopo il riallineamento permessi: rilanciare `php artisan netgescon:git-sync --remote=origin --branch=main` o il pulsante UI e poi `php artisan optimize:clear`. + ## Rilascio operativo 2026-04-06 Questo e il blocco che puo essere aggiornato adesso con la procedura Git-first senza correzioni manuali extra su staging. diff --git a/docs/support/BUG-RISOLTI-E-VALIDAZIONI.md b/docs/support/BUG-RISOLTI-E-VALIDAZIONI.md index 6f41ea3..4a04c48 100644 --- a/docs/support/BUG-RISOLTI-E-VALIDAZIONI.md +++ b/docs/support/BUG-RISOLTI-E-VALIDAZIONI.md @@ -27,6 +27,14 @@ ### Supporto > Modifiche con `ProgramAclService` assente su nodo staging - Stato: [U] validato su `/var/www/netgescon` con service realmente assente; `App\Filament\Pages\Supporto\Modifiche::canAccess()` non genera piu eccezioni e ritorna correttamente `true` per un utente amministrativo. - Prevenzione: nelle pagine di supporto e deploy evitare dipendenze rigide da moduli opzionali o non ancora allineati sul nodo; il pannello di recupero deve sempre avere un percorso di fallback minimale. +### Refresh nodo bloccato da permessi deploy su `resources/views/errors` + +- Problema: il launcher aggiornamento nodo restava a `behind 1`, la `503` compariva solo per un attimo e la UI del launcher restava visibile con polling e pulsanti, costringendo a refresh manuali. +- Causa tecnica: `netgescon:git-sync` falliva nel passaggio `rsync` verso `/var/www/netgescon` con `Permission denied` su `resources/views/errors/.503.blade.php`; il repository sorgente arrivava al commit remoto ma il checkout applicativo non riceveva i file nuovi. +- Fix applicato: permessi riallineati su `/var/www/netgescon/resources/views/errors` e `503.blade.php` al gruppo `www-data`; il launcher ora forza anche una navigazione piena alla stessa URL quando parte il refresh con maintenance, cosi il browser mostra la `503` completa invece di restare nella UI Livewire. +- Stato: [U] validato su staging locale; `git-sync-last.json` torna `completed`, commit deploy e remoto risultano allineati (`cadb9a5` nel caso reale) e il nodo torna a `ahead 0 / behind 0`. +- Prevenzione: le directory che devono ricevere file nuovi via deploy web devono restare group-writable per il gruppo del processo PHP/web (`www-data` qui); quando una directory viene creata manualmente sul nodo, impostare subito gruppo coerente e bit setgid. + ### Ripristino bootstrap pannello admin - Problema: `AdminFilamentPanelProvider.php` era stato corrotto da una modifica incompleta e impediva il bootstrap corretto. diff --git a/resources/views/filament/pages/supporto/aggiornamento-launcher.blade.php b/resources/views/filament/pages/supporto/aggiornamento-launcher.blade.php index 7831d66..69fd1ca 100644 --- a/resources/views/filament/pages/supporto/aggiornamento-launcher.blade.php +++ b/resources/views/filament/pages/supporto/aggiornamento-launcher.blade.php @@ -1,16 +1,28 @@ + @php $supportUpdateAuthUser = auth()->user(); $supportCanRunUpdate = $supportUpdateAuthUser && method_exists($supportUpdateAuthUser, 'hasAnyRole') && $supportUpdateAuthUser->hasAnyRole(['super-admin', 'admin', 'amministratore']); + $supportUsesDaemon = config('distribution.update_executor', 'local') === 'daemon'; @endphp
-
Launcher esterno per update e sync Git
+
Launcher autonomo aggiornamento nodo
- Usa questa pagina per lanciare aggiornamenti senza restare dentro la pagina completa Modifiche mentre Livewire e i file vengono riallineati. Il flusso principale da Gitea ora blocca nuove richieste, crea il backup pre-update, aggiorna DB e ricostruisce l'app prima di riaprire il nodo. + Questa pagina espone un solo flusso operativo: aggiornamento autonomo del nodo da browser, senza accesso shell al sistema remoto. @if($supportUsesDaemon) Il pulsante accoda la richiesta a un daemon host Docker che esegue il refresh completo. @else Il job viene eseguito direttamente dall'applicazione. @endif
@@ -31,8 +43,8 @@
-
Refresh nodo da Gitea
-
Flusso consigliato per staging e nodi interni: backup, finestra protetta, sync Git, dipendenze, migrate e cache rebuild.
+
Aggiornamento remoto in sicurezza
+
Un solo pulsante, job asincrono e ripartenza automatica del nodo. Il recupero resta applicativo: log supporto, runtime errors e richieste help continuano a restare nel progetto.
@if(! $this->ticketAttachmentMetadataReady)
@@ -56,20 +68,8 @@
- - Aggiorna nodo completo da Gitea - - - Aggiorna staging da Gitea - - - Refresh di riserva senza maintenance - - - Recovery senza composer - - - Solo sync Git avanzata + + Aggiorna nodo automaticamente Aggiorna avanzamento refresh @@ -77,15 +77,31 @@
- Il pulsante Aggiorna staging da Gitea esegue il refresh completo del nodo: backup pre-update, maintenance mode per bloccare nuove operazioni utente, sync da Gitea, composer install, tentativo di build frontend se disponibile, migrate --force, pulizia cache, rebuild Blade e riapertura automatica del sistema. + Il pulsante Aggiorna nodo automaticamente esegue il refresh completo: backup pre-update solo se riattivato, maintenance mode con pagina 503 personalizzata, sync da Gitea, composer install, build frontend se disponibile, migrate --force, pulizia cache, rebuild Blade e riapertura automatica del sistema.
- Se la macchina remota fallisce su Maintenance mode non attivata, prima allinea il nodo con Solo sync Git avanzata e poi usa Refresh di riserva senza maintenance. E un percorso di recupero per nodi dove il blocco accessi Laravel non parte correttamente. + Se il job trova un errore, l esito resta tracciato in output completo, log supporto e runtime errors. Questo permette di diagnosticare e correggere il problema dal progetto, senza prendere il controllo del nodo remoto.
-
- Se il nodo e gia allineato ma il refresh fallisce su vendor/composer/autoload_classmap.php: Permission denied, usa Recovery senza composer. Serve solo per chiudere migrate e cache rebuild quando non stai installando nuove dipendenze PHP. + @if($supportUsesDaemon) +
+ Executor attivo: daemon host Docker. Il pannello accoda la richiesta, poi il runner host esegue docker/update-multisite.sh e aggiorna questo avanzamento senza shell manuale. +
+ @endif + +
+ Backup e continuita: l aggiornamento nasce per lavorare con backup automatico e copie su Drive quando abilitate, cosi il nodo resta semplice da installare in Docker e sicuro da aggiornare anche senza interventi manuali sul sistema. +
+ +
+
Passi pianificati dal launcher
+
    + @foreach($this->updatePlannedSteps as $plannedStep) +
  • {{ $plannedStep }}
    • + @endforeach +
  • Segnalazioni supporto, richieste help e errori runtime restano consultabili dalla suite Supporto dopo il refresh.
    • +
@if($this->updateInProgress)