NexTool Solutions

Eine Migration von GLPI 10 auf GLPI 11 scheitert fast nie am Befehl für das Datenbank-Update - sondern an dem, was davor und danach kommt. Dieser Leitfaden fasst den Fahrplan zusammen, den wir im Betrieb bei Kunden anwenden: wo es wirklich bricht, wie Sie jeden Schritt absichern und wie Sie zurückkehren, wenn etwas schiefgeht.

Zuallererst: Warum die Migration Methode erfordert

Die Migration von 10 auf 11 ändert das Datenbankschema unumkehrbar und ersetzt die komplette Präsentationsschicht (jetzt auf Basis von Symfony und Twig). Es ist kein "Dateien austauschen und starten". Die beiden Punkte, die am häufigsten ungeplante Ausfallzeiten verursachen, sind inkompatible Plugins, die während des Updates aktiv sind, und die auf dem Server installierte PHP-Version. Behandeln Sie die Migration als kleines Projekt, mit Wartungsfenster und Rollback-Plan, nicht als Hotfix. Planen Sie auch, den Benutzern mitzuteilen, dass die Oberfläche von 11 optisch anders aussieht als die von 10 - ein großer Teil der Tickets nach der Migration stammt von Menschen, die sich im neuen Layout nicht zurechtfinden, nicht von echten Bugs.

Checkliste vor der Migration

• Vollständiges Backup der Datenbank (mysqldump) sowie der Konfigurations- und Datenverzeichnisse.
• Auf der letzten Minor-Version von GLPI 10 (neueste 10.0.x) sein, bevor Sie auf 11 springen.
• PHP 8.1+ installiert und in der richtigen Version für CLI und FPM aktiv.
• Bestandsaufnahme der Plugins mit dem Kompatibilitätsstatus jedes einzelnen unter GLPI 11.
• Abnahmeumgebung mit einer realen Kopie der Datenbank, um die Migration zu proben.

Plugins: Was sich in GLPI 11 ändert

1. Vollständiges (und getestetes) Backup

Ein Backup, welches Sie nie wiederhergestellt haben, ist kein Backup, sondern eine Hoffnung. Erstellen Sie es und prüfen Sie mindestens die Dateigröße:

# Banco de dados
mysqldump -u root -p --single-transaction glpi > /backup/glpi_pre_migration.sql

# Arquivos (config, dados e plugins)
tar -czf /backup/glpi_files_pre_migration.tar.gz /var/www/glpi /etc/glpi /var/lib/glpi

2. Inkompatible Plugins deaktivieren

Gehen Sie in GLPI 10 zu Einrichten > Plugins und deaktivieren Sie alle, für die es keine Version für 11 gibt. Entfernen Sie die Verzeichnisse der inkompatiblen. Dieser Schritt ist nicht optional: Er ist die Ursache Nr. 1 für Fehler beim Update-Befehl.

3. GLPI-Dateien aktualisieren

cd /tmp
wget https://github.com/glpi-project/glpi/releases/download/11.0.0/glpi-11.0.0.tgz
tar -xzf glpi-11.0.0.tgz

# Substituir arquivos preservando config, dados e plugins
rsync -av --delete /tmp/glpi/ /var/www/glpi/ --exclude plugins/ --exclude marketplace/
chown -R www-data:www-data /var/www/glpi

Laden Sie immer das neueste stabile Release der Linie 11.x herunter, nicht unbedingt 11.0.0.

4. Datenbankmigration ausführen

php /var/www/glpi/bin/console db:update --no-interaction

Dieser Befehl wendet alle Schemamigrationen an. Verfolgen Sie die gesamte Ausgabe - jeder Fehler muss behoben werden, bevor Sie fortfahren, nie ignoriert.

5. Cache und Sitzungen leeren

php /var/www/glpi/bin/console cache:clear
rm -rf /var/lib/glpi/_sessions/*

6. Prüfung nach der Migration

• Anmeldung funktioniert, und die Version unter Einrichten > Allgemein zeigt 11.x.
• Tickets, Assets und Benutzer sind vorhanden und stimmen mit den erwarteten Summen überein.
• Ein neues Ticket lässt sich von Anfang bis Ende erstellen.
• Logs ohne wiederkehrende Fehler nach einigen Minuten Nutzung.
• Reaktivieren und aktualisieren Sie die kompatiblen Plugins einzeln und testen Sie nach jedem.

Was wir im Betrieb gelernt haben

In der Praxis scheitert die Migration selten am db:update selbst. Sie scheitert danach: ein inkompatibles Plugin, welches aktiv geblieben ist und die Oberfläche mit Fehler 500 lahmlegt, ein PHP im FPM, welches auf eine Version zeigt, die GLPI 11 nicht akzeptiert (während die CLI bereits auf 8.1 ist), oder ein Kunde, der eine Minor-Version von 10 übersprungen hat und mit einem nicht passenden Schema beim Update-Befehl ankommt. Deshalb aktualisiert unser Fahrplan immer zuerst auf die letzte 10.0.x, validiert, und springt erst dann auf 11 - und reaktiviert die Plugins einzeln, nie alle auf einmal, denn wenn etwas bricht, müssen Sie genau wissen, welches Plugin verantwortlich war.

Die häufigste Falle

Der klassische Fehler ist die Annahme, dass Formulare aus FormCreator von selbst in die nativen Formulare von GLPI 11 migriert werden. Sie werden es nicht: Ein Plugin wird entfernt, aber die Formulare, die es angelegt hat, müssen im neuen Core manuell neu erstellt werden. Erfassen Sie den Bestand an FormCreator-Formularen, bevor Sie ein Plugin entfernen, sonst entdecken Sie den Verlust erst in Produktion, wenn Benutzer sich beschweren, dass ein Formular verschwunden ist. Der zweithäufigste Fehler ist, db:update mit noch aktivem inkompatiblem Plugin auszuführen: Die Konsole versucht, ein Plugin zu laden, stößt auf eine API, die es nicht mehr gibt, und bricht mitten in der Migration ab.

Rollback: wenn etwas schiefgeht

Da die Schemaänderung unumkehrbar ist, bedeutet Rollback nicht "rückgängig machen" - sondern einen früheren Zustand wiederherstellen. Deshalb ist ein getestetes Backup aus Schritt 1 nicht verhandelbar:

# Restaurar arquivos
tar -xzf /backup/glpi_files_pre_migration.tar.gz -C /

# Restaurar banco
mysql -u root -p glpi < /backup/glpi_pre_migration.sql

Diese Wiederherstellung vor dem realen Wartungsfenster in der Abnahmeumgebung zu proben, unterscheidet einen Schrecken von einem Vorfall.

Nächster Schritt

Erkunden Sie nach der Migration die nativen Formulare und die übrigen Neuerungen von GLPI 11, und führen Sie die unverzichtbaren Plugins wieder ein. Um den Core zu erweitern, ohne Plugins anzuhäufen, die bei der nächsten Major-Version brechen, bündelt NexTool Dutzende Module in einem einzigen Plugin, mit Versionen für 10 und 11. Brauchen Sie Unterstützung bei der Migration? Sprechen Sie mit dem Team.

Geprüft vom Team der NexTool Solutions.