Für jede Anforderung ein Plugin zu installieren, scheint in GLPI die naheliegende Lösung - bis zum Tag des Upgrades, an dem die Hälfte davon nicht mehr startet. Nach Jahren im Betrieb von GLPI-Umgebungen unserer Kunden haben wir gelernt: Der Engpass ist selten ein schlechtes Plugin, sondern die Summe aus einem Dutzend einzelner Plugins, jedes mit eigenem Release-Zyklus, eigenen Abhängigkeiten und eigenem Maintainer. Dieser Leitfaden zeigt, wie Sie Erweiterungen auswählen und kombinieren, ohne in den "Plugin-Sprawl" zu geraten, wo der modulare Ansatz von NexTool passt - und, ehrlich gesagt, wo er nicht nötig ist.
Problemfall "Plugin-Sprawl"
Jedes Plugin im GLPI-Ökosystem ist ein eigenes Projekt: eigener Maintainer, eigenes Repository, eigener Release-Rhythmus. Dies ist eine Stärke der Open-Source-Community, wird aber zur Belastung, wenn sich ein Dutzend davon in derselben Umgebung ansammelt. Die Symptome, die wir am häufigsten sehen:
- Kompatibilität nicht im Takt mit dem Core - GLPI veröffentlicht eine Major-Version, und jedes Plugin braucht ein eigenes Update, um mitzuziehen. Es genügt, dass eines nicht portiert wurde, und die ganze Umgebung hängt beim Upgrade fest.
- Konflikte zwischen Plugins - zwei Plugins, die denselben Hook überschreiben, konkurrierendes CSS einschleusen oder dieselbe Route registrieren. Symptome zeigen sich meist weit entfernt von der Ursache.
- Implizite Abhängigkeiten - ein Plugin, das nur funktioniert, wenn ein anderes installiert ist, ohne dass dies dokumentiert ist. Wird ausgerechnet dieses deaktiviert, fällt eine Funktion aus, die niemand damit in Verbindung brachte.
- Vervielfachter Wartungsaufwand - jedes Plugin ist ein zu verfolgendes Changelog, eine CVE, die beobachtet werden muss, und ein "Läuft es nach dem nächsten Update noch?" in jedem Wartungsfenster.
Zuallererst: Erfassen Sie, was Sie bereits haben
Vor jedem Upgrade - und bevor ein weiteres Plugin installiert wird - erfassen wir als Erstes, was installiert ist und in welchem Zustand. Die Abfrage, die wir direkt in der Datenbank ausführen:
-- Inventario dos plugins instalados no GLPI e o estado de cada um.
-- state = 1 significa ativado; os demais estados merecem atencao antes do upgrade.
SELECT directory AS plugin,
name,
version,
state
FROM glpi_plugins
ORDER BY state, directory;Für jede Zeile, die erscheint, drei Fragen: Wer pflegt es, in welchem Release-Rhythmus, und was bricht, wenn es beim nächsten Upgrade nicht mitzieht? Ein Plugin, zu dem niemand antworten kann, ist ein Kandidat, der vor dem Wartungsfenster entfernt werden sollte, nicht währenddessen.
Die drei Ansätze im Vergleich
Nicht jede Anforderung verlangt dieselbe Antwort. Die Tabelle fasst den Trade-off zusammen, eine Lücke mit einem einzelnen Community-Plugin, mit einem NexTool-Modul oder mit einer bereits nativen Funktion von GLPI 11 zu schließen:
| Kriterium | Einzelnes Community-Plugin | NexTool-Modul | Native Funktion von GLPI 11 |
|---|---|---|---|
| Abhängigkeiten | Eine pro Plugin, oft implizit | Ein einziges Basis-Plugin; Module gemeinsam getestet | Keine - Teil des Core |
| Update / Upgrade | Jedes Plugin in seinem eigenen Rhythmus; ein verspätetes blockiert jedes Upgrade | Ein Paket zum Aktualisieren, Kompatibilität vom Anbieter getestet | Wird zusammen mit GLPI aktualisiert |
| Konflikte | Reales Risiko zwischen Plugins verschiedener Maintainer | Geringer: Die Module werden gemeinsam getestet. Bugs werden dadurch nicht ausgeschlossen - die Verantwortung liegt aber an einer Stelle | Keine - es ist der Core selbst |
| Versionsabdeckung | Variiert je Plugin; für Ihre Version gibt es es eventuell nicht | Die Basis läuft auf GLPI 10 und 11; jedes Modul gibt an, auf welchen Versionen es läuft (mehrere sind exklusiv für 11) | Folgt der installierten Version |
| Support | Community / Freiwillige, ohne SLA | Ein einziger Anbieter mit Support-Kanal | Offizielle Roadmap des GLPI-Projekts |
| Anbieterabhängigkeit | Gering - offener Code, Sie können ihn forken und pflegen | Hoch - Roadmap, Preis und Fortbestand hängen von einem einzigen Unternehmen ab | Vom GLPI-Projekt selbst |
| Wartungskurve | Wächst mit der Anzahl der Plugins | Flach - eine Stelle, die verfolgt werden muss | Minimal, aber auf den Funktionsumfang des Core beschränkt |
So funktioniert der modulare Ansatz
Die Alternative besteht nicht darin, auf Funktionen zu verzichten - sondern die Zahl unabhängiger Dinge zu reduzieren, die verwaltet werden müssen. NexTool kehrt die Logik um: Statt N Plugins gibt es ein einziges (kostenloses) Basis-Plugin, welches Module beherbergt, die bei Bedarf aktiviert werden.
- Ein einziger Installationspunkt - Sie installieren und aktualisieren nur ein Basis-Plugin; die Module leben darin, ohne dass jedes ein separates Paket im Marketplace ist.
- Aktivieren Sie nur, was Sie nutzen - der Katalog umfasst KI, Kommunikation, Dokumente, Sicherheit, Automatisierung und mehr; Sie schalten Modul für Modul nach Bedarf ein, ohne Ballast mitzuschleppen.
- Keine Abhängigkeitsverwaltung zwischen Modulen - die Kompatibilität untereinander liegt in der Verantwortung eines einzigen Anbieters und wird bei jedem Release gemeinsam getestet.
- Ein wachsender Katalog - neue Module kommen hinzu, ohne eine neue Plugin-Installation zu erfordern; sie erscheinen in der Modulansicht des bereits installierten Plugins.
- Kostenlose Basis - Basis-Plugin und ein großer Teil der Module sind FREE; die lizenzierten liegen am selben Ort, und Sie zahlen nur für tatsächlich aktivierte Module.
Was wir im Betrieb gelernt haben
Bei einem Kunden mit mehr als 15 einzelnen Plugins hat ein kleineres GLPI-Upgrade die Hälfte davon lahmgelegt: Die Umgebung startete, aber vier Plugins blieben im Status "zu aktualisieren" und verschwanden aus dem Menü. Was niemand erwartet hatte: Ein Reporting-Plugin hing von einer Tabelle ab, die ein anderes Plugin anlegte - wer Letzteres deaktivierte, legte damit Ersteres stillschweigend lahm. Wir brauchten ein ganzes Wartungsfenster, nur um herauszufinden, welches Plugin welches blockierte. Seitdem behandeln wir jedes neue Plugin als Wartungsschuld, nicht als kostenlose Funktion. Der häufige Fehler - den wir selbst schon gemacht haben - ist, ein Plugin für einen einzigen Bericht zu installieren und es zwei Jahre lang installiert zu vergessen, bis es der Grund ist, warum ein Upgrade nicht abgeschlossen werden kann.
Für wen geeignet (und wann NICHT)
Der modulare Ansatz glänzt, wenn Sie mehrere zusammenhängende Funktionen benötigen - KI im Ticket, Benachrichtigung per WhatsApp, Serviceauftrag als PDF, Genehmigungsworkflow - und einen einzigen Anbieter wollen, der für Kompatibilität und Support verantwortlich ist. Wenn Ihr Betrieb von knappen Wartungsfenstern lebt und sich kein Upgrade leisten kann, welches ein verwaistes Plugin blockiert, lohnt sich die Zentralisierung.
Seien Sie aber auch beim Gegenteil ehrlich: Wenn ein einzelnes Community-Plugin Ihre einzige Anforderung bereits gut löst, installieren Sie es und machen Sie weiter - es gibt keinen Grund, ein Basis-Plugin einzuführen, um nur ein Modul einzuschalten. Und vor allem: Schauen Sie zuerst, was GLPI bereits nativ kann. Natives Inventar (GLPI Inventory, seit GLPI 10) ersetzt in den meisten Fällen früheres FusionInventory; Formulare und benutzerdefinierte Objekte, für die man FormCreator und GenericObject brauchte, wurden in GLPI 11 in den Core übernommen. Nicht alles braucht ein Plugin, und schon gar nicht NexTool: Das beste Plugin ist meist das, das Sie nicht installieren müssen.
Es gibt außerdem einen Trade-off, den die Zentralisierung nicht löst, sondern nur verlagert: Wer Funktionen bei einem einzigen Anbieter bündelt, bündelt auch Risiken. Bei einzelnen Open-Source-Plugins können Sie forken und weitermachen, wenn der Maintainer sein Projekt aufgibt. Bei einem proprietären Hub hängen Roadmap, Preis und Fortbestand von einem einzigen Unternehmen ab. Dies ist kein Grund, den Ansatz zu verwerfen - aber ein Grund, den Anbieter so zu bewerten wie jeden anderen: Release-Historie, Support-Kanal und was mit Ihren Daten passiert, wenn Sie wechseln möchten.
So aktivieren Sie ein Modul
- Installieren Sie das NexTool-Basis-Plugin wie jedes andere GLPI-Plugin: entpacken Sie es nach
plugins/, dann installieren und aktivieren Sie es unter Einrichten > Plugins. - Gehen Sie im Menü zu Einrichten > NexTool > Module.
- Suchen Sie Ihr gewünschtes Modul im Katalog, prüfen Sie die unterstützten GLPI-Versionen und klicken Sie auf aktivieren.
- Öffnen Sie die Ansicht konfigurieren des Moduls und passen Sie die Parameter an (API-Schlüssel, Kanäle, Profile, je nach Bedarf).
- Wiederholen Sie dies für jedes Modul. Kein Schritt erfordert, das Basis-Plugin neu zu installieren oder Abhängigkeiten von Hand aufzulösen.
Kompatibilität
Das NexTool-Basis-Plugin ist kostenlos und läuft sowohl auf GLPI 10 als auch auf GLPI 11. Die Kompatibilität der Module wird jedoch Modul für Modul angegeben: Ein Teil des Katalogs ist versionsübergreifend und läuft auf beiden, während ein großer Teil der neueren Module exklusiv für GLPI 11 ist, weil sie auf Funktionen aufsetzen, die es nur dort gibt. Der Katalog zeigt die unterstützten Versionen jedes Moduls, und die Aktivierung wird mit einer klaren Meldung blockiert, wenn die Umgebung nicht kompatibel ist - Sie erfahren es vor der Installation, nicht mitten im Upgrade.
In der Praxis, für alle, die von 10 auf 11 migrieren: Prüfen Sie im Katalog, welche der von Ihnen genutzten Module versionsübergreifend sind. Es ist dieselbe Bestandsaufnahme, die dieser Beitrag für jedes Plugin empfiehlt - mit dem Unterschied, dass die Information hier an einer Stelle liegt und nicht über ein Dutzend Repositories verstreut ist.
Wenn Ihr Betrieb an dem Punkt angekommen ist, an dem die Verwaltung von Plugins zu einer eigenen Aufgabe geworden ist, lohnt sich ein Blick auf NexTool als modularen Hub - oder sprechen Sie mit dem Team, um zu klären, ob Ihr Fall Zentralisierung verlangt oder ob der Core bereits genügt.
Geprüft vom Team der NexTool Solutions.
