OTOBO

OTOBO Docker–Update – Version sicher upgraden ​

Ein regelmäßiges Upgrade Ihrer OTOBO‑Installation stellt sicher, dass Sie neue Features, Sicherheits‑Patch­es und Bugfixes sofort nutzen können. Diese Anleitung erklärt, wie Sie in wenigen Schritten eine Docker‑basierte OTOBO‑Instanz auf das gewünschte Release bringen.

Voraussetzungen ​

  • Eine bestehende OTOBO‑Installation mit Docker & Docker Compose
  • SSH‑Zugriff auf den Host
  • Backup Ihrer wichtigen Daten (Docker‑Volumes für /opt/otobo, Datenbank, Elasticsearch‑Index)
  • Gewünschte Zielversion, z. B. 11.0.10 oder 10.1.8

Schritt 1: Docker‑Compose‑Konfiguration aktualisieren ​

  1. In das Verzeichnis Ihres OTOBO‑Docker‑Projekts wechseln:

    bash
    cd /opt/otobo-docker

  2. Neue Git‑Tags abrufen und auf das gewünschte Release wechseln:

    bash
    git fetch --tags
git checkout rel-11_0_10    # Beispiel für Version 11.0.10

  3. Falls nötig, Ihre .env anpassen, z. B.:

    ini
    OTOBO_IMAGE=rotheross/otobo:11.0.10
OTOBO_IMAGE_ELASTICSEARCH=elasticsearch:8.8.2
OTOBO_IMAGE_NGINX=nginx:1.23-alpine

Schritt 2: Neue Docker‑Images holen ​

bash
docker-compose pull

Schritt 3: Containers stoppen und aktualisieren ​

  1. Alte Container stoppen (Volumes bleiben erhalten):

    bash
    docker-compose down

  2. Code‑Volume auf die neue Version migrieren:

    bash
    docker-compose run --rm web copy_otobo_next

  3. Container mit neuer Software starten:

    bash
    docker-compose up -d

Schritt 4: OTOBO‑internes Update durchführen ​

  1. Update‑Tasks ausführen:

    bash
    docker-compose exec web entrypoint.sh do_update_tasks

  2. Optional: Datenbank‑Migrationsskript für Haupt‑Releases (z. B. 10.1→11.0):

    bash
    docker exec -it otobo_web_1 perl scripts/DBUpdate-to-11.0.pl

  3. Update‑Log prüfen:

    bash
    docker-compose exec web cat /opt/otobo/var/log/update.log

Schritt 5: Abschluss & Kontrolle ​

  • Status prüfen: docker-compose ps zeigt an, ob alle Container laufen
  • Login testen: Stellen Sie sicher, dass Agenten und Kunden sich anmelden können
  • Kurztest: Erstellen Sie ein Ticket, versenden Sie E‑Mails und prüfen Sie Kern­funktionen

Verfügbare OTOBO‑Versionen ​

Haupt‑ und Neben‑Releases (Auswahl):

  • 11.0.10: Bietet interne Verbesserungen und aktualisierte Docker‑Tags für stabile Deployments.
  • 11.0.9: Schließt eine kritische Sicherheitslücke (CVE-2025-43926) und optimiert das Ticket‑Suchmodul.
  • 11.0.8: Verstärkte Passwort-Hashing-Algorithmen und verbesserte Zwei‑Faktor‑Authentifizierung.
  • 11.0.7: Diverse Bugfixes, u. a. Korrekturen bei Checkbox‑Darstellung und Artikel‑Links.
  • 11.0.6: Wichtige Sicherheitsupdates gegen JavaScript‑Injektion und Umstellung auf CKEditor 5.
  • 11.0.5: Layout‑Optimierungen für CKEditor 5 und verbesserte Übersetzung von Services.
  • 11.0.4: Erweitertes Übersetzungssystem und optimierte Docker‑Quickstart‑Skripte.
  • 11.0.3: Behebt Datenbankfehler beim Ticket‑Merge und Probleme mit dynamischen Feldern.
  • 11.0.2: Automatisches Laden von ITSM‑Repos und bessere Upgrade‑Erkennung für Core‑Pakete.
  • 11.0.1: Neue dynamische Feld‑Funktionen und ein High‑Contrast‑Skin für bessere Barrierefreiheit.
  • 11.0.0‑beta3: Umstellung auf HTML::Scrubber für sichereres Safety()‑Verhalten.
  • 11.0.0‑beta2: Verfeinerte dynamische Referenzfelder und Integration neuer Core‑Pakete.
  • 10.1.8: Sicherheitsfix für XSS in AdminCustomerUser und robuste HTTP‑Header‑Validierung.
  • 10.1.7: Verbesserte Kalenderdarstellung und stabileres Elasticsearch‑Handling.
  • 10.1.6: Schließt eine SQL‑Injection in TicketSearch und optimiert Terminbenachrichtigungen.
  • 10.1.5: Verhindert Code‑Injection in ACLs und aktualisiert wichtige JavaScript‑Bibliotheken.
  • 10.1.4: Korrigiert Lücken bei LDAP‑Synchronisation und verbessert Massenaktualisierungen.
  • 10.1.3: Verhindert Server‑Side‑Calls im Admin-Interface und schließt XSS‑Lücken.
  • 10.1.2: Fehlerbehebungen im DynamicFieldDatabase-Modul für beständige Suche.
  • 10.1.1: Erweiterter Kunden‑Dashboard und verbesserte Elasticsearch‑Selbstheilung.

Hinweis: Für Haupt‑Versionssprünge (z. B. 10.1 → 11.0) immer erst Minor‑Upgrade (10.1) durchführen, dann Major‑Upgrade (11.0).