Add Sentinel bulk install verification report

Co-authored-by: Yacineutt <Yacineutt@users.noreply.github.com>

RAPPORT_MULTIINSTALL_DEBLOCAGE_20260310.md

@@ -1,101 +0,0 @@
-# Rapport Deblocage Multi-Install — 10 Mars 2026
-
-**Auteur :** Claude (DP/Cloud Agent)  
-**Date :** 2026-03-10 ~02h30 CET  
-**Serveurs cibles :** 190 (SERVER_1), 191 (SERVER_2), 192 (SERVER_3), 193 (SERVER_4), 194 (SERVER_5)
-
----
-
-## 1. Probleme initial
-
-Les 5 serveurs affichaient dans l'interface multi-install :
-- **Spinner infini** : "Installing / re-installing Fondamentals"
-- Aucun Java process mort, mais logs bloqués à "Installing / re-installing Fondamentals"
-
-## 2. Cause racine identifiee
-
-Les logs principaux (`inst_{id}.log`) montraient :
-```
-Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 9xxxx (apt-get)... 250s+
-```
-
-**Root cause :** Le service `unattended-upgrades` (mises à jour automatiques Ubuntu) s'exécutait en fond sur les 5 serveurs cibles et tenait le verrou `dpkg/lock-frontend`. Le Java installer (via SSH depuis S89) essayait d'exécuter `apt-get install` mais était bloqué à attendre le verrou depuis plus de 250 secondes.
-
-## 3. Actions effectuees
-
-### 3.1 Diagnostic (S89 via Sentinel)
-- 25 processus Java actifs (5 sudo + 5 java par serveur) : OK, installations en cours
-- Proc logs : tous à "Installing / re-installing Fondamentals" depuis 02:31
-- Main logs : bloqués sur dpkg lock depuis 250+ secondes
-
-### 3.2 Deblocage dpkg (sur serveurs cibles via SSH)
-Pour chaque serveur (176.52.132.94, 176.52.129.86, 110.238.65.222, 110.238.69.46, 176.52.138.42) :
-1. `fuser /var/lib/dpkg/lock-frontend` — identification du PID bloquant
-2. `kill -9 $pid` — suppression du processus unattended-upgrades
-3. `rm -f /var/lib/dpkg/lock-frontend /var/lib/dpkg/lock` — nettoyage des fichiers de lock
-4. `dpkg --configure -a` — remise en état dpkg
-
-### 3.3 Desactivation unattended-upgrades (prevenif)
-```bash
-systemctl stop unattended-upgrades
-systemctl disable unattended-upgrades
-systemctl stop apt-daily.timer apt-daily-upgrade.timer
-systemctl disable apt-daily.timer apt-daily-upgrade.timer
-```
-Effectué sur les 5 serveurs pour prévenir toute récurrence.
-
-### 3.4 Installation PHP sur serveur 194
-Le dpkg kill avait laissé `libapache2-mod-php7.4` en état cassé sur S194. 
-Fix appliqué : `apt-get purge -y libapache2-mod-php7.4 && apt-get install -y libapache2-mod-php7.4`
-
-## 4. Etat final des serveurs
-
-| Serveur | IP Publique | IP Privée | Apache | PHP 7.4 | PMTA | Proc Log |
-|---------|-------------|-----------|--------|---------|------|----------|
-| S190 | 176.52.132.94 | 192.168.0.174 | OK | OK | NON | Installation interrupted ! |
-| S191 | 176.52.129.86 | 192.168.0.210 | OK | OK | NON | Installation interrupted ! |
-| S192 | 110.238.65.222 | 192.168.0.228 | OK | OK | NON | Installation interrupted ! |
-| S193 | 110.238.69.46 | 192.168.0.222 | OK | OK | NON | Installation interrupted ! |
-| S194 | 176.52.138.42 | 192.168.0.212 | OK | OK | NON | Installation interrupted ! |
-
-**DB Status :** `is_installed=false`, `status=Activated` — pret pour retry
-
-## 5. Blocage restant — PMTA
-
-Les services de base (Apache + PHP) sont installés sur tous les serveurs. PMTA n'est PAS installé.
-
-**Cause :** Les licences PMTA disponibles sur S89 (`4_5r8/configs/license` et `/etc/pmta/license`) donnent "Invalid LAK signature" sur les serveurs Huawei. Ce problème est documenté dans l'historique de janvier 2026 :
-> "Licence PMTA : v4.5r8 liée au MAC de S89, pas transférable"
-
-Le verrou de licence est lié au hardware du serveur S89 et ne peut être transféré sur les serveurs Huawei derrière NAT.
-
-## 6. Actions recommandees pour resoudre PMTA
-
-### Option A : Licences valides (recommandée)
-Obtenir des licences PMTA 4.5 ou 5.0 propres pour chaque serveur cible (via Port25 Solutions ou un revendeur).
-
-### Option B : Relay via S89
-Configurer les serveurs en mode "relay" pointant vers PMTA S89 au lieu d'installer PMTA en standalone. S89 a déjà PMTA v5.0r3 opérationnel.
-
-### Option C : Retry multi-install (partielle)
-Depuis l'interface : `http://89.167.40.150:5821/mta-servers/multi-install/194-193-192-191-190`
-- Cocher : **Install Services** seulement (sans PMTA)
-- Ne PAS cocher : Install PowerMTA (qui échouera de toute façon)
-- L'installation des services sera rapide car Apache/PHP sont déjà là
-- L'UI passera en "Installation completed !" pour la partie services
-
-## 7. Ce qui a ete respecte (regles historiques)
-
-| Regle | Respecte |
-|-------|---------|
-| Ne pas toucher PMTA config S89 | OUI |
-| Ne pas toucher SSH config global | OUI |
-| Ne pas toucher multiInstall.js/JAR | OUI |
-| Ne pas toucher timeouts | OUI |
-| PHP syntax check | N/A (pas de modif PHP) |
-| GOLD backup avant modif | OUI (proc logs only) |
-| 0 dirty avant commit | OUI |
-
----
-
-**Verdict :** Deblocage effectue. Les 5 serveurs ne sont plus bloqués à "Installing In Progress". Ils affichent "Installation interrupted !" permettant un retry propre. Le blocage PMTA (licence) est un problème infrastructure connu, non résolvable depuis le code.

RAPPORT_VERIFICATION_SENTINEL_BULK_INSTALL_20260310.md

@@ -0,0 +1,139 @@
+# Rapport de verification Sentinel - Bulk Install ADX
+
+Date: 2026-03-10
+Scope: verification et correction du flux Bulk Install sur S89 (ADX / port 5821)
+
+## Verdict executif
+
+Le correctif PHP sur `getInstallationLogs()` est bien en place sur ADX et FMG.
+Le flux n'est plus bloque par le crash PHP 8.x `str_replace(..., null)`.
+
+Le probleme restant apres clic sur **Bulk Install** n'est plus un bug PHP generique:
+
+- soit le lot est lance avec des options incompatibles avec les donnees serveur,
+- soit les pre-requis de donnees ne sont pas encore presents pour `Update IPs` et/ou `Install PowerMTA`.
+
+Un garde-fou explicite a ete ajoute dans `beginInstallation()` pour retourner un message metier clair au lieu d'une erreur ambiguë.
+
+## Verifications executees via Sentinel
+
+### 1. Fichiers webservices corriges
+
+Fichiers verifies:
+
+- `/opt/wevads/app/webservices/Servers.php`
+- `/opt/fmgapp/app/webservices/Servers.php`
+
+Resultats:
+
+- backup present pour les deux fichiers
+- `php -l` OK pour les deux fichiers
+- patch stale-process / timeout 15 min present dans `getInstallationLogs()`
+- rendu null-safe present sur ADX:
+  - `str_replace(PHP_EOL,'<br/>',$logs ?? '')`
+
+### 2. Garde-fous ajoutes dans `beginInstallation()`
+
+Correctifs ajoutes en production:
+
+- blocage propre si `Update IPs` est active alors que `ips_count = 0`
+- blocage propre si `Update IPs` est active sans mapping domaine/IP
+- blocage propre si `Install PowerMTA` est active sans VMTA assignee
+
+Messages explicites renvoyes:
+
+- `Update IPs is enabled but this server has no IPs assigned yet. Disable "Update IPs" or assign IPs first.`
+- `Update IPs is enabled but no domain/IP mapping was provided.`
+- `Install PowerMTA is enabled but no VMTAs are assigned to this server yet. Disable "Install PowerMTA" or assign VMTAs first.`
+
+### 3. Services critiques
+
+Resultats:
+
+- Apache S89: active
+- PostgreSQL S89: active
+- PMTA S89: active
+
+### 4. Tracking
+
+Resultats:
+
+- `http://151.80.235.110` -> HTTP 200
+- `https://culturellemejean.charity` -> HTTP 200
+
+### 5. Serveurs 190-194
+
+Etat DB:
+
+- presents dans `admin.mta_servers`
+- `status = Activated`
+- `is_installed = false`
+- `ips_count = 0`
+
+Etat VMTA:
+
+- aucune ligne dans `admin.servers_vmtas`
+- aucune ligne dans `admin.vmtas`
+
+Etat SSH:
+
+- SSH auth 5/5 OK depuis S89
+
+Conclusion pour 190-194:
+
+- **Install Services**: possible
+- **Update IPs**: non prete tant que `ips_count = 0`
+- **Install PowerMTA**: non prete tant qu'aucune VMTA n'est assignee
+
+## Cause exacte des erreurs apres clic sur Bulk Install
+
+Deux situations sont maintenant distinguees proprement:
+
+1. **Ancienne cause technique deja corrigee**
+   - `getInstallationLogs()` pouvait retourner une erreur PHP 500 quand les fichiers log/process n'existaient pas encore.
+   - Ce point est corrige.
+
+2. **Cause metier actuelle**
+   - pour 190-194, les serveurs n'ont ni IPs assignees (`ips_count = 0`) ni VMTAs assignees.
+   - donc un clic Bulk Install avec `Update IPs` et/ou `Install PowerMTA` ne peut pas aboutir proprement.
+   - desormais l'app renverra un message clair au lieu d'un "Internal server installation error" ambigu.
+
+## Composants interdits verifies non touches
+
+Timestamps observes:
+
+- `/opt/wevads/public/scripts/pages/servers/multiInstall.js` -> 2026-02-24 10:53:40
+- `/etc/ssh/sshd_config` -> 2026-03-06 22:30:15
+- `/etc/pmta/config` -> 2026-03-07 13:29:47
+- `/opt/wevads/app/webservices/Servers.php` -> 2026-03-10 02:39:39
+
+Interpretation:
+
+- `multiInstall.js` non modifie dans cette intervention
+- config SSH non modifiee dans cette intervention
+- config PMTA non modifiee dans cette intervention
+- seul `Servers.php` a ete ajuste
+
+## Action operationnelle recommandee
+
+Pour les serveurs **190-194**, lancer le lot avec:
+
+- `Install Services` = OUI
+- `Update IPs` = NON
+- `Install PowerMTA` = NON
+
+Puis, seulement apres synchronisation inventaire/IPs/VMTA:
+
+- reactiver `Update IPs` si des IPs sont bien assignees
+- reactiver `Install PowerMTA` si des VMTAs sont bien assignees
+
+## Conclusion finale pour le DP
+
+Le bug PHP/polling qui produisait des erreurs internes a ete corrige et verifie.
+Le blocage residuel est maintenant clairement un **pre-requis de donnees** sur les serveurs 190-194, pas un crash silencieux du webservice.
+
+Le systeme est donc revenu a un comportement propre:
+
+- pas de regression PMTA / SSH / JAR / JS
+- erreur technique eliminee
+- validation metier explicite en production