Wazuh Update 4.9.2 → 4.10.4: Upgrade-Prozess und gescheiterter 4.11.2-Versuch
Wazuh Update 4.9.2 → 4.10.4: Upgrade-Prozess und gescheiterter 4.11.2-Versuch
Inhaltsverzeichnis
Ausgangslage
Das Wazuh SIEM auf matzka.cloud lief seit der initialen Inbetriebnahme im Februar 2026 auf Version 4.9.2. Im Juni 2026 standen zwei neue Releases bereit: 4.10.4 und 4.11.2. Ziel war ein direktes Update auf die aktuellste verfügbare Version.
| Komponente | Vorher | Nachher |
|---|---|---|
| wazuh-manager | 4.9.2 | 4.10.4 |
| wazuh-indexer (OpenSearch) | 4.9.2 | 4.10.4 |
| wazuh-dashboard | 4.9.2 | 4.10.4 |
| wazuh-agent (Host) | 4.9.2 | 4.10.4 |
Update auf 4.10.4
Docker-Images aktualisieren
Der erste Schritt war das direkte Upgrade von 4.9.2 auf 4.10.4. Dazu wurden die
Image-Tags in der docker-compose.yml geändert und die Container neu
gestartet:
cd /opt/docker/security/single-node
# Neue Images laden
docker compose pull
# Stack neu starten
docker compose down
docker compose up -d
Host-Agent aktualisieren
Der Wazuh-Agent läuft als systemd-Service direkt auf dem Host (nicht im Container) und muss separat aktualisiert werden. Dabei ist es entscheidend, dass die Agent-Version mit der Manager-Version übereinstimmt:
# Aktuelle Version prüfen
/var/ossec/bin/wazuh-control info
# Agent-Paket aktualisieren
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | apt-key add -
apt-get install wazuh-agent=4.10.4-1
# Agent neu starten
systemctl restart wazuh-agent
apt-get upgrade
ohne fixierte Version aktualisieren. Immer explizit wazuh-agent=4.x.x-1
angeben, um unbeabsichtigte Versionssprünge zu vermeiden.
Verifizierung
Nach dem Neustart kurz warten und alle Container-Status prüfen:
docker compose ps
# Erwartete Ausgabe:
# wazuh-manager healthy
# wazuh-indexer healthy
# wazuh-dashboard healthy
# wazuh-exporter healthy
Agent-Verbindung im Manager bestätigen:
docker exec wazuh-manager /var/ossec/bin/agent_control -i 001
# Agent 001 muss als "Active" erscheinen mit Version 4.10.4
Versuch: 4.11.2 — und warum er scheiterte
Da 4.10.4 reibungslos lief, wurde direkt ein weiteres Upgrade auf 4.11.2
versucht. Das Image-Tag in der docker-compose.yml wurde geändert und der
Stack neu gestartet.
Der wazuh-indexer (OpenSearch) startete nicht. Im Log erschien dieser Fehler:
ERROR Could not load codec 'Lucene912'. Did you forget to add lucene-backward-codecs.jar?
org.apache.lucene.index.CorruptIndexException: Unknown codec: 'Lucene912'
Ursache: OpenSearch / Lucene Codec-Inkompatibilität
Das Problem liegt in der Versionshistorie von OpenSearch:
- Wazuh 4.10.4 schreibt Indexer-Daten mit Lucene 9.12 (OpenSearch 2.17.x)
- Wazuh 4.11.2 verwendet eine OpenSearch-Version, die nur bis Lucene 9.5 rückwärtskompatibel ist
- Der neue Indexer kann die von 4.10.4 geschriebenen Segmente nicht lesen
| Version | OpenSearch | Lucene | Rückwärtskompatibel bis |
|---|---|---|---|
| Wazuh 4.10.4 | 2.17.x | 9.12 | — |
| Wazuh 4.11.2 | 2.x (älter) | 9.x | bis Lucene 9.5 ❌ |
Warum kein einfacher Fix?
Theoretisch gibt es zwei Auswege: alle Wazuh-Indizes löschen (Verlust der Security-History) oder einen vollständigen Re-Index. Beides ist für ein Produktions-SIEM nicht akzeptabel. Der saubere Weg ist, auf einen Wazuh-4.11.x-Release zu warten, der mit OpenSearch 2.17.x kompatibel ist.
Rollback auf 4.10.4
Da der wazuh-indexer nicht startete, war ein Rollback notwendig. Der Container hatte noch keine Daten geschrieben — der Start schlug vor der Initialisierung fehl. Deshalb war der Rollback trivial:
# Image-Tags wieder auf 4.10.4 setzen und neu starten
docker compose down
# docker-compose.yml: alle Tags auf 4.10.4 geändert
docker compose up -d
Ergebnis
Das Update auf 4.10.4 war erfolgreich und problemlos. Das direkte Weiterspringen auf 4.11.2 scheiterte an einer OpenSearch/Lucene-Inkompatibilität.
| Schritt | Ergebnis |
|---|---|
| 4.9.2 → 4.10.4 (Docker + Agent) | ✅ Erfolgreich |
| 4.10.4 → 4.11.2 | ❌ Lucene-Codec-Fehler, Rollback |
| Rollback auf 4.10.4 | ✅ Sofort, kein Datenverlust |
Für das Update auf 4.11.x ist ein Wazuh-Release abzuwarten, der OpenSearch in einer mit Lucene 9.12 aufwärtskompatiblen Version mitbringt — oder ein separater Migrationspfad über einen frischen Indexer wird notwendig.