UTMStack v11.2.8 Community Edition — Procédures de déploiement pour lab PME Suisse. Installation VMware, Suricata, CrowdSec, SOAR, OPNsense.
⚠️ Mise à jour critique (29 juin 2026) : un incident terrain a révélé que la RAM recommandée à l’étape 6.7 (10 GB) bloque silencieusement le service d’auto-mise à jour d’UTMStack, créant une boucle d’échec invisible pendant des semaines. Voir la nouvelle section 10. RAM minimum réelle avant d’appliquer l’étape 6.7.
Créer une nouvelle VM dans VMware Workstation avec les paramètres suivants :
| Paramètre | Valeur |
|---|---|
| Système d’exploitation | Linux → Ubuntu 64-bit |
| RAM (installation) | 14336 MB — minimum requis par l’installateur |
| RAM (post-install) | 10240 MB — réduire après installation |
| vCPU | 1 socket × 4 cœurs |
| Disque | 150 GB SATA — thin provisioning |
| Firmware | UEFI |
| Réseau | Personnalisé (VMnet selon l’environnement) |
| Contrôleur I/O | LSI Logic (SCSI) |
| CD/DVD | SATA — pointer vers l’ISO UTMStack v11 |
⚠️ État du périphérique — DÉCOCHER « Connecté » sur la carte réseau avant de démarrer la VM.
[Help] apparaît en haut de l’écranQuand la carte réseau est connectée au démarrage, le serveur DHCP du réseau répond avant que l’installateur puisse configurer son environnement réseau interne, causant un conflit fatal dans le processus cloud-init d’autoinstall.
Démarrer avec la carte réseau déconnectée. L’installateur affiche alors l’écran de configuration réseau permettant de saisir une IP statique, puis on reconnecte la carte dans VMware pendant l’installation.
L’installateur détecte que la carte réseau est déconnectée et affiche : disabled — autoconfiguration failed.
ens33)| Champ | Exemple |
|---|---|
| Subnet | 192.168.1.0/24 |
| Address | 192.168.1.150 |
| Gateway | 192.168.1.254 |
| Name servers | 192.168.1.1, 8.8.8.8 |
| Search domains | mondomaine.local |
Pendant que l’installateur attend sur l’écran Network configuration :
ℹ️ Utiliser
Alt+Tabpour basculer entre VMware Settings et la console de la VM sans perdre le focus.
| Champ | Description |
|---|---|
| Your name | Nom complet (ex : Admin UTMStack) |
| Your server’s name | Nom de la machine (ex : utmstack) |
| Pick a username | Identifiant SSH (ex : admin) |
| Choose a password | Mot de passe sudo — noter impérativement |
| Confirm your password | Confirmation |
ℹ️ Après le reboot, le CD-ROM peut être éjecté dans les paramètres VMware.
| Paramètre | Valeur |
|---|---|
| Hôte | IP statique configurée à l’étape 3.2 |
| Port | 22 |
| Utilisateur | Username saisi à l’étape 3.4 |
| Mot de passe | Password saisi à l’étape 3.4 |
Passer en root immédiatement après connexion :
sudo su
Environ 30 minutes après le début de l’installation, vérifier que tous les services UTMStack sont démarrés :
docker service ls
✅ utmstack_agentmanager 1/1
✅ utmstack_backend 1/1
✅ utmstack_event-processor-manager 1/1
✅ utmstack_event-processor-worker 1/1
✅ utmstack_frontend 1/1
✅ utmstack_node1 1/1 ← OpenSearch
✅ utmstack_postgres 1/1
✅ utmstack_user-auditor 1/1
✅ utmstack_web-pdf 1/1
❌ bash: docker: command not found
❌ Un ou plusieurs services à 0/1
❌ Aucun service listé
→ Lancer l’installateur manuellement (voir étape 5.1)
⚠️ Cette étape n’est nécessaire que si la vérification précédente indique une installation incomplète.
free -h # Vérifier RAM disponible (minimum 12 GB libres)
sudo su
cd /opt/utmstack
./installer
Suivi en parallèle (second terminal PuTTY) :
tail -f /var/log/utmstack/installer.log
| Message affiché | Signification |
|---|---|
| Generating Stack configuration… | Calcul de la distribution mémoire |
| Memory distribution successful | RAM suffisante — installation continue |
| Downloading images… | Téléchargement Docker (10–20 min) |
| Installing reverse proxy… | Configuration nginx |
| Initializing databases… | PostgreSQL + OpenSearch |
| Waiting for Backend to be ready… | Démarrage backend (2–3 min) |
| Generating Connection Key… | Génération token agents |
| Installation finished successfully. | Installation terminée ✔ |
Erreur fréquente — RAM insuffisante :
error balancing memory: insufficient memory: Available 7897MB < Total Minimum Required 11150MB
Solution : Power Off → augmenter à 14 GB dans VMware → relancer ./installer
ℹ️ Les étapes 6.4, 6.5 et 6.7 ne sont pas obligatoires si UTMStack dispose de 32 GB+. Les étapes 6.1, 6.2, 6.3 et 6.6 sont toujours recommandées.
apt update && apt upgrade -y
apt install unattended-upgrades -y
dpkg-reconfigure --priority=low unattended-upgrades
df -h /
lvextend -l +100%FREE /dev/mapper/ubuntu--vg-ubuntu--lv
resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv
df -h / # Résultat attendu : ~145 GB disponibles
sed -i 's/OPENSEARCH_JAVA_OPTS=-Xms[0-9]*m -Xmx[0-9]*m/OPENSEARCH_JAVA_OPTS=-Xms1024m -Xmx1024m/' \
/opt/utmstack/compose.yml
sed -i '/reservations:/{N;d;}' /opt/utmstack/compose.yml
export UTMSTACK_TAG=v11.2.8
docker stack deploy -c /opt/utmstack/compose.yml utmstack
docker service ls # Vérifier 1/1
⚠️ Voir impérativement la section 10 avant d’appliquer cette étape. 10 GB suffit au fonctionnement quotidien mais bloque silencieusement le service d’auto-mise à jour d’UTMStack.
| Port | Service | Usage |
|---|---|---|
| 443 / 10001 | Frontend | Interface web |
| 9000 | agentmanager | gRPC agents — contrôle |
| 9001 | agentmanager | HTTP agents |
| 50051 | event-processor-worker | gRPC — envoi logs agents |
| 8080 | event-processor-worker | HTTP |
| 8000 | event-processor-manager | HTTP |
| 7014 | Agent Windows | Réception syslog TCP/UDP |
| 7019 | Agent Windows | Suricata EVE JSON |
⚠️ Le port 7014 TCP doit être ouvert manuellement dans le Windows Firewall :
New-NetFirewallRule -DisplayName "UTMStack Syslog TCP 7014" -Direction Inbound -Protocol TCP -LocalPort 7014 -Action Allow
| Nom du snapshot | Moment |
|---|---|
| UTMStack-v11.2.8-clean-install | Après installation + optimisations, avant agents |
| UTMStack-v11.2.8-operational | Après connexion de tous les agents et validation syslog |
| UTMStack-before-update | Avant chaque mise à jour manuelle de version (voir section 10) |
⚠️ Ne jamais restaurer un backup PostgreSQL d’une version antérieure dans une installation v11.2.8.
| Accès | Valeur |
|---|---|
| Interface web | https://<IP configurée> |
| Username web | admin |
| Password web | Généré à l’installation — affiché en fin d’installateur |
| SSH user | Username saisi à l’étape 3.4 |
| SSH password | Password saisi à l’étape 3.4 |
| Admin interface | https://<IP>:9090 |
⚠️ Le mot de passe admin est généré automatiquement et affiché une seule fois à la fin de l’installation. Le noter immédiatement.
L’étape 6.7 recommandait de réduire la VM à 10 GB après l’installation initiale, pour économiser des ressources sur un lab où UTMStack partage l’hôte avec d’autres VMs. Cette recommandation reste valable pour le fonctionnement quotidien, mais elle cache un piège sérieux découvert après plusieurs semaines d’exploitation continue.
UTMStackComponentsUpdaterUTMStack embarque un service systemd, UTMStackComponentsUpdater, qui tourne en arrière-plan en permanence et vérifie périodiquement s’il existe une nouvelle version sur GitHub. S’il en trouve une, il tente automatiquement de télécharger les nouvelles images Docker et de redéployer la stack — sans aucune notification ni demande de confirmation.
Le problème : ce processus de mise à jour a besoin de faire tourner temporairement les anciens et les nouveaux conteneurs en parallèle pendant la transition, ce qui exige nettement plus de RAM que le fonctionnement normal.
Sur une VM réduite à 10 GB (conformément à l’étape 6.7), ce service échoue avec :
error balancing memory: insufficient memory: Available 9913MB < Total Minimum Required 11150MB. (System requires 12150MB)
Sans limite de tentatives, systemd relance ce service toutes les 2 minutes, indéfiniment, dès qu’une mise à jour est disponible. Sur un lab resté allumé 3 semaines sans interruption, ça représente plus de 14 500 tentatives échouées — entièrement invisibles dans l’interface UTMStack, et qui ne produisent aucune alerte.
⚠️ Risque concret observé en lab : si une opération de maintenance manuelle (redémarrage de service,
docker stack deploy) intervient pile au moment où ce cycle d’échec de l’updater tente sa propre opération de redéploiement, les deux processus entrent en collision sur le réseau overlay Docker Swarm. Résultat observé : DNS interne instable (server misbehaving), table de routage IPVS désynchronisée (no destination availableaffiché en boucle sur la console), et services applicatifs (notammentagentmanager, responsable du SOAR) qui crashent en boucle sans lien apparent avec la cause réelle. Le diagnostic de cet incident a nécessité une journée complète, alors que la cause racine était une simple limite de RAM insuffisante pour un service qu’on ne savait même pas actif.
| Recommandation | Étape 6.7 (obsolète) | Validé terrain |
|---|---|---|
| RAM en fonctionnement courant | 10 GB | 10 GB (reste valable) |
| RAM minimum pour que l’auto-updater réussisse | Non documenté | 12 GB minimum (12150 MB exactement) |
| RAM recommandée si l’auto-updater reste actif | Non documenté | 16 GB (marge de sécurité pour la transition ancien/nouveau conteneurs) |
Stratégie A — Garder le mode économique (10 GB), désactiver l’auto-updater
Recommandé si tu préfères gérer les mises à jour manuellement, à un moment choisi :
systemctl stop UTMStackComponentsUpdater
systemctl disable UTMStackComponentsUpdater
Pour mettre à jour manuellement quand tu le décides : remonter temporairement la VM à 16 GB, puis lancer l’installeur existant :
/opt/utmstack/installer --install
L’installeur détecte l’installation existante et propose la mise à jour. Une fois terminée et le système stabilisé, redescendre la VM à 10 GB (étape 6.7).
Stratégie B — Allouer durablement 16 GB à la VM
Recommandé si l’hôte dispose de la RAM nécessaire pour les autres VMs du lab en plus de celle-ci. Laisse l’auto-updater fonctionner normalement en arrière-plan, sans intervention.
systemctl status UTMStackComponentsUpdater --no-pager
journalctl -u UTMStackComponentsUpdater --no-pager | tail -20
Si tu vois un restart counter élevé (plusieurs centaines ou milliers) accompagné de error balancing memory, c’est le signe que ce piège est déjà actif sur ton installation — applique l’une des deux stratégies ci-dessus avant qu’une opération de maintenance ne déclenche le même type d’incident.
← Retour à l’index → Intégration Suricata