NexTool Solutions

Wir haben eine Kopie eines GLPI 11.0.11 zweimal auf 12.0.0 aktualisiert: in Docker mit dem offiziellen Image und unter Debian 13 mit dem .tgz-Paket. Die Datenbankmigration dauerte in beiden Fällen etwa 5 Sekunden. Die Arbeit kam davor und danach: MariaDB 10.6 wurde abgelehnt, die Plugins wurden ausgesetzt, die Kategorien der Wissensdatenbank wurden zu Artikeln, die Techniker und Benutzer nicht öffnen können, und der Webhook hörte aus zwei verschiedenen Gründen auf zu senden. Dieser Leitfaden zeigt beide Wege Schritt für Schritt und die Korrektur jedes Problems in der Reihenfolge, in der es auftrat.

Sie überlegen noch, ob jetzt der richtige Zeitpunkt für ein Update ist? Lesen Sie zuerst GLPI 12 ist erschienen: was sich ändert, Anforderungen und wann Sie aktualisieren sollten.

Was wir getestet haben

Wir haben ein Wegwerf-GLPI 11.0.11 mit fiktiven Daten der Firma Acme aufgesetzt: 120 Tickets mit Folgeaktionen und 40 Aufgaben, ein SLA, 9 Artikel der Wissensdatenbank in 4 Kategorien mit unterschiedlichen Berechtigungen, ein Webhook zu einem internen Server und drei Community-Plugins (Fields, Tag und Data Injection) mit Daten. Wir haben ein Backup erstellt und auf 12.0.0 aktualisiert. Danach haben wir dasselbe Backup auf einem Debian 13 wiederhergestellt und den Update-Vorgang mit dem .tgz-Paket wiederholt.

Bevor Sie beginnen: Anforderungen

Zwei Details, die der Test gezeigt hat:

• PHP 8.2 gibt keine Warnung aus, sondern einen Syntaxfehler. Die Konsole von GLPI 12 kommt gar nicht bis zur Prüfung der Anforderungen: Sie bricht mit einem „Parse error“ in einer Datei von GLPI selbst ab. Debian 12 und Ubuntu 22.04 bringen PHP 8.2 oder älter mit. Debian 13 (PHP 8.4) und Ubuntu 24.04 (PHP 8.3) erfüllen die Anforderungen mit den Standardpaketen. Das offizielle Docker-Image enthält bereits PHP 8.5.
• Prüfen Sie vor allem anderen die Datenbank. Führen Sie php bin/console system:check_requirements mit dem neuen Code aus, der auf Ihre Datenbank zeigt. Bei unserem MariaDB 10.6 war die Antwort eindeutig: Version nicht unterstützt, Minimum 10.11.

Schritt 0: Backup (Datenbank, Dateien und der Schlüssel)

Erstellen Sie drei Kopien, bevor Sie irgendetwas anfassen: die Datenbank, den Dateiordner und den Konfigurationsordner. Im Konfigurationsordner liegt glpicrypt.key. Ohne diese Datei lassen sich die von GLPI gespeicherten Passwörter (E-Mail-Empfänger, LDAP, Proxy, Webhook-Secrets) nicht mehr entschlüsseln.

mariadb-dump --single-transaction --routines -u root -p glpi | gzip > glpi11-$(date +%F).sql.gz
tar czf glpi11-arquivos-$(date +%F).tgz /etc/glpi /var/lib/glpi/files /var/www/glpi/marketplace

In Docker mit dem offiziellen Image liegt alles im unter /var/glpi eingehängten Volume (config, files, marketplace und logs): Kopieren Sie den gesamten Inhalt des Volumes. In unserem Test dauerte der Dump 5 Sekunden und die Kopie des Volumes 8,5.

Weg 1: Docker mit dem offiziellen Image

Das offizielle Image (glpi/glpi) aktualisiert die Datenbank selbstständig, wenn es mit einer neuen Version startet. Es genügt, den Tag zu ändern und den Container zu starten: Es gibt keine Bestätigung. Deshalb erfolgt die Sicherung vor dem Tag-Wechsel, niemals danach. Wenn Sie das Update lieber manuell ausführen möchten, starten Sie mit GLPI_SKIP_AUTOUPDATE=true und verwenden Sie den Befehl aus Weg 2.

1. Aktualisieren Sie bei Bedarf MariaDB. Mit MariaDB 10.6 beendete sich der Container von GLPI 12 mit Code 128. Das Log meldete fehlende Anforderungen und schrieb direkt danach einen erschreckenden Satz: „GLPI is not installed... Starting installation“. Installiert wurde nichts. Die Datenbank blieb unverändert auf Version 11.0.11, mit den 120 Tickets. Sie hat lediglich die Anforderungsprüfung nicht bestanden. Der Wechsel von MariaDB 10.6 auf 10.11 dauerte 22 Sekunden mit der Variablen für automatische Upgrades des MariaDB-Images. Starten Sie zuerst nur die Datenbank (docker compose up -d db) und prüfen Sie die Logausgabe, bevor Sie fortfahren:

services:
  db:
    image: mariadb:10.11          # was 10.6
    environment:
      MARIADB_AUTO_UPGRADE: "1"   # runs mariadb-upgrade on startup
  glpi:
    image: glpi/glpi:12.0.0       # was 11.0.11 (step 2)
    volumes:
      - glpi-data:/var/glpi

2. Ändern Sie den Tag und starten Sie. docker compose up -d. Das Log zeigt „GLPI is installed, and auto-update is enabled. Starting update...“ und anschließend die Willkommensnachricht. Im Test vergingen 17 Sekunden vom up bis zur Willkommensnachricht im Log.

3. Prüfen Sie. docker compose exec glpi bin/console db:check sollte „Database schema is OK“ melden.

Weg 2: Linux mit dem .tgz-Paket

Die folgenden Befehle folgen dem Layout unseres Installationsleitfadens für GLPI 11 unter Debian und Ubuntu: Code in /var/www/glpi, Konfiguration in /etc/glpi und Dateien in /var/lib/glpi/files.

cd /var/www/glpi && sudo -u www-data php bin/console maintenance:enable
cd /var/www && mv glpi glpi-11-antigo
wget https://github.com/glpi-project/glpi/releases/download/12.0.0/glpi-12.0.0.tgz
tar xzf glpi-12.0.0.tgz
cp glpi-11-antigo/inc/downstream.php glpi/inc/                  # if present
cp glpi-11-antigo/config/local_define.php glpi/config/ 2>/dev/null  # if present
cp -a glpi-11-antigo/marketplace/. glpi/marketplace/
chown -R www-data:www-data glpi
cd glpi
sudo -u www-data php bin/console system:check_requirements
sudo -u www-data php bin/console database:update
sudo -u www-data php bin/console maintenance:disable

Die Datei, an die niemand denkt: inc/downstream.php. Sie teilt GLPI mit, dass die Konfiguration in /etc/glpi liegt. Sie befindet sich im Code-Ordner und verschwindet daher, wenn Sie den Ordner austauschen. Im Test antwortete database:update ohne sie mit „Unable to connect to database“. Die Meldung nennt nicht den eigentlichen Grund: GLPI hat die Konfiguration am falschen Ort gesucht. Nachdem die Datei zurückkopiert war, lief die Aktualisierung sofort durch. Dasselbe gilt für config/local_define.php, falls Sie diese Datei verwenden.

Wenn Ihr GLPI config und files innerhalb von /var/www/glpi speichert, kopieren Sie auch config/ und files/ aus dem alten Ordner. So war es unter Debian 13 (PHP 8.4): Die Migration dauerte 5 Sekunden und db:check lief fehlerfrei durch.

Wenn die Datenbankaktualisierung fehlschlägt

Am 3. November beschrieb ein Thread im GLPI-Forum ein Update von 11.0.8 auf 12.0.1 unter Debian 13, das hängen blieb: Die Dateien waren kopiert, Eigentümer und Berechtigungen angepasst, dann meldete maintenance:disable einen Fehler und die Datenbankaktualisierung schlug fehl. Diesen Fall haben wir nicht nachgestellt. Eine Antwort im Thread nannte eine wahrscheinliche Ursache, und der Migrationscode bestätigt, dass sie möglich ist: In 11 akzeptiert die Tabelle, die Artikel mit Kategorien der Wissensdatenbank verknüpft, dasselbe Paar aus Artikel und Kategorie mehrfach; die Tabelle, die sie in 12 ersetzt, nicht. Eine einzige doppelte Verknüpfung reicht, um die Migration zu stoppen. Spielen Sie das Backup von 11 zurück (die Migration kann mittendrin abgebrochen sein) und suchen Sie nach Duplikaten:

SELECT knowbaseitems_id, knowbaseitemcategories_id, COUNT(*) AS n
FROM glpi_knowbaseitems_knowbaseitemcategories
GROUP BY knowbaseitems_id, knowbaseitemcategories_id
HAVING n > 1;

Kommt eine Zeile zurück, löschen Sie die Kopien und behalten Sie eine Verknüpfung pro Paar. Der Artikel bleibt in seiner Kategorie:

DELETE l1 FROM glpi_knowbaseitems_knowbaseitemcategories l1
JOIN glpi_knowbaseitems_knowbaseitemcategories l2
  ON l1.knowbaseitems_id = l2.knowbaseitems_id
 AND l1.knowbaseitemcategories_id = l2.knowbaseitemcategories_id
 AND l1.id > l2.id;

Bleibt die Abfrage leer, liegt die Ursache woanders. Prüfen Sie, ob der Dateiordner und der Konfigurationsordner (in unserem Layout /var/lib/glpi/files und /etc/glpi) www-data gehören, führen Sie system:check_requirements aus und lesen Sie php-errors.log im Ordner _log des Dateiverzeichnisses sowie das Fehlerprotokoll des Webservers. Führen Sie database:update auf der Kommandozeile aus, die den Fehler auf dem Bildschirm anzeigt, und erst danach maintenance:disable.

Nach der Migration: was kaputtging und wie Sie es beheben

1. Die Plugins werden ausgesetzt (und der Listenbefehl verrät es nicht)

Nach dem Update setzt GLPI 12 die Ausführung aller Plugins aus. plugin:list zeigte alle drei weiterhin als „Enabled“ an. Die Einstellung plugins_execution_mode stand jedoch auf „suspended_by_update“, und kein Plugin lief. Zum Freigeben:

php bin/console plugin:resume_execution

Beim Freigeben prüfte GLPI die Versionen und deaktivierte alle drei („Installed / not activated“). Die Versionen für 11 akzeptieren höchstens GLPI 11.0.99, und die Versionen für 12 verlangen mindestens 12.0.0. Das heißt: Diese Plugins lassen sich nicht vor GLPI aktualisieren. Zuerst GLPI, danach die Plugins:

Für jedes Plugin: Ersetzen Sie den Ordner in marketplace/ durch die neue Version und führen Sie plugin:install und plugin:activate aus. Die Daten blieben erhalten: die 5 Werte des Fields-Feldes „Kostenstelle“ und die 10 Tags des Tag-Plugins waren weiterhin vorhanden. Bevor Sie einen Termin festlegen, prüfen Sie, ob alle Ihre Plugins bereits eine Version für 12 haben (wie Sie Plugins auswählen, ohne Ihr Upgrade zu blockieren).

2. Die Kategorien der Wissensdatenbank werden zu Artikeln ohne Sichtbarkeit

GLPI 12 hat keine Kategorien mehr in der Wissensdatenbank: Die 4 Kategorien wurden zu 4 „übergeordneten“ Artikeln, und darüber wurde ein Stammartikel („Home“) angelegt. Die 9 Artikel behielten ihre bisherigen Berechtigungen. Die 4 Artikel, die vorher Kategorien waren, hatten jedoch keinerlei Sichtbarkeitsregel. Wir haben über die API mit einem Techniker und einem Self-Service-Benutzer getestet: Beide erhielten den Fehler 403 beim Öffnen von „Verfahren“, „Netzwerk“, „WLAN“ und „Benutzer-FAQ“. Jeder konnte weiterhin nur die Artikel öffnen, die er vorher schon sah.

Korrektur: Öffnen Sie jede ehemalige Kategorie und geben Sie ihr die Zielgruppe, die der Ordner hatte (Einheit, Profil oder Gruppe). In 12 erbt ein Artikel die Sichtbarkeit der darüberliegenden Artikel. Im Test führte die Freigabe der ehemaligen Kategorie „Benutzer-FAQ“ für die Einheit Acme dazu, dass der Techniker den Ordner und die beiden Artikel darin öffnen konnte, die vorher 403 lieferten. Für den Self-Service-Benutzer gibt es einen zusätzlichen Schritt: Er sieht nur Artikel, die als FAQ markiert sind, und die ehemaligen Kategorien kommen ohne diese Markierung an. Mit Sichtbarkeit und FAQ-Markierung erschien der Ordner auch für ihn. Erledigen Sie dies, bevor Sie GLPI für die Benutzer freigeben.

3. Der Webhook stoppte: Methode „post“ in Kleinbuchstaben

Der in GLPI 11 erstellte Webhook landete in der Warteschlange und schlug fehl. Das Log webhook.log zeigte die Ursache: Invalid HTTP method "post", only uppercase letters are accepted. GLPI speichert die Methode in Kleinbuchstaben, und der HTTP-Client von 12 akzeptiert nur Großbuchstaben. Das betrifft jeden Webhook, auch die in 12 erstellten. Das Problem ist im GitHub von GLPI erfasst (Issue 25883), mit einer vorgeschlagenen Korrektur. Als wir am 16. Oktober getestet haben, war die Korrektur weder in 12.0.0 noch in der Entwicklungsversion von 12.0.1 enthalten.

Bis die Korrektur erscheint, besteht die Umgehung darin, die Methode direkt in der Datenbank in Großbuchstaben umzuwandeln (mit Backup):

UPDATE glpi_webhooks SET http_method = UPPER(http_method);
UPDATE glpi_queuedwebhooks SET http_method = UPPER(http_method);

Wenn jemand den Webhook erneut über die Oberfläche speichert, wechselt der Feldinhalt wieder zu Kleinbuchstaben. Wiederholen Sie den Befehl in diesem Fall und prüfen Sie die Release Notes der Versionen 12.0.x: Sobald die Korrektur enthalten ist, ist die Umgehung nicht mehr nötig.

4. Danach: die Sperre für interne Netzwerke

Mit korrigierter Methode änderte sich der Fehler: Host "glpiup-hook" is blocked. GLPI 12 blockiert standardmäßig serverseitige Aufrufe in private Netzwerke (10.x, 172.16-31.x, 192.168.x). Das gilt für Webhooks, externe Kalender, RSS-Feeds und die Verbindung zu GLPI Network. Standardmäßig sind nur die Aufrufe an den Inventar-Agenten und an die externe Authentifizierung freigegeben. Wenn Ihr Webhook auf ein n8n, ein ERP oder eine API im internen Netzwerk zeigt, wird er stoppen.

Um nur Notwendiges freizugeben, legen Sie die Datei config/local_define.php im Code-Ordner von GLPI an:

<?php
define('GLPI_SERVERSIDE_URL_ALLOWED_PRIVATE_NETWORKS_CONTEXTS', [
    \Agent::class,    // default
    \Auth::class,     // default
    \Webhook::class,  // allows webhooks to the internal network
]);

Docker-Falle: GLPI liest diese Datei in /var/www/glpi/config/, das sich im Image befindet, und nicht im Volume /var/glpi/config. Im Volume abgelegt, hatte die Datei keine Wirkung. Als Datei eingehängt, funktionierte es:

    volumes:
      - glpi-data:/var/glpi
      - ./local_define.php:/var/www/glpi/config/local_define.php:ro

Danach wurden die beiden Webhooks aus der Warteschlange mit Status 200 zugestellt. Wie Sie einen Webhook von Grund auf konfigurieren, lesen Sie unter native Webhooks in GLPI 11.

5. Die Warnung zu Dokumenten

Die Migration hinterließ eine einzige Warnung im Log warning_during_migration_to_12.0.0.log: „Rights have been given for document, you should review ACLs after update“. GLPI hat neue Berechtigungen für Dokumente vergeben. Prüfen Sie diese unter Verwaltung > Profile, Reiter Verwaltung > Dokumente, vor allem bei den Profilen für Endbenutzer.

Update-Checkliste

Und die NexTool-Module?

Das NexTool-Plugin und die 37 Module laufen unter GLPI 11 und 12 mit derselben Version. Anders als die oben genannten Plugins können Sie sie daher vorher aktualisieren, noch unter 11, unter NexTool > Module > Alle aktualisieren. Nach der Migration werden sie wie die anderen Plugins ausgesetzt: Führen Sie plugin:resume_execution aus und prüfen Sie die Liste unter NexTool > Module. Die Tabelle Modul für Modul finden Sie unter NexTool unter GLPI 12: Kompatibilität. Wenn Sie Unterstützung bei der Planung oder Durchführung des Updates wünschen, sprechen Sie uns an.

Test von NexTool am 16. Oktober 2026 auf einer Wegwerfkopie mit fiktiven Daten: offizielles Image glpi/glpi 11.0.11 auf 12.0.0 (PHP 8.5), MariaDB 10.6 auf 10.11 und .tgz-Paket unter Debian 13 (PHP 8.4). Die Umgebung wurde am Ende gelöscht. GLPI ist eine eingetragene Marke von Teclib'. NexTool ist nicht mit Teclib' verbunden.