Die Migration von FusionInventory zu GLPI Agent bedeutet nicht, einen Agenten zu deinstallieren und den anderen zu installieren. Beim Betrieb von GLPI-Flotten, den NexTool für B2B-Kunden übernimmt, entscheidet über die Migration vor allem eines: die Verknüpfung des Assets zu schützen. Jeder Rechner, der den Agenten gewechselt hat, muss weiterhin im selben Datensatz in GLPI landen, ohne zum Duplikat zu werden. Dieser Beitrag zeigt, wie wir diesen Massenwechsel planen und durchführen, vom Einlieferungspunkt bis zur Prüfung, die jede Welle abschließt.
Was sich wirklich ändert: der Einlieferungspunkt
FusionInventory Agent belieferte GLPI über das Plugin FusionInventory mit eigenem Endpoint. GLPI Agent beliefert das native Inventar des Core, das unter /front/inventory.php empfängt. Während des Übergangs existieren also zwei verschiedene Einlieferungswege auf demselben Server. Der Agent ist nur eine Hälfte der Geschichte: Die andere Hälfte ist, dass der Server nicht mehr vom Plugin abhängt. Deshalb ist die Reihenfolge wichtig - zuerst wird die Flotte migriert und erst danach das Plugin FusionInventory deaktiviert und deinstalliert, nie umgekehrt. Wer das Plugin entfernt, bevor die Flotte migriert ist, kappt den Datenweg der Agenten, welche noch nicht gewechselt haben.
Eine gute Nachricht für alle, die Funktionsverluste fürchten: GLPI Agent behält dieselben Tasks wie FusionInventory (Inventory, NetDiscovery, NetInventory, Deploy, ESX, Collect und RemoteInventory). Netzwerkerkennung und Deploy gehen beim Wechsel nicht verloren; es ändern sich Binärdatei und Lieferpunkt, nicht der Funktionsumfang.
Ein reales Risiko: doppelte Assets (und warum sie entstehen)
Hier kommt ein Detail, welches erst sichtbar wird, wenn Sie so etwas in Produktion betreiben. Jeder Agent trägt eine deviceid (etwa hostname-2026-07-02-10-30-00). Bei einer Neuinstallation von GLPI Agent wird eine neue deviceid erzeugt. Dadurch entsteht ein neuer Agenten-Datensatz in GLPI - aber es sollte kein neuer Computer entstehen, weil ein Asset über Importregeln nach Seriennummer und UUID zugeordnet wird, nicht über eine deviceid.
Im Betrieb sind es fast nie physische Desktops, die dupliziert werden: Sie haben eine Seriennummer ab Werk und werden einwandfrei zugeordnet. Dupliziert werden VMs. Eine virtuelle Maschine mit leerer Seriennummer oder mit einer aus einer Vorlage geklonten UUID entgeht der Zuordnung über Seriennummer/UUID und wird bei jedem Wechsel einer deviceid zu einem neuen Asset. Deshalb prüfen wir vor der ersten Welle die Importregeln und stellen ein Fallback-Kriterium sicher, welches für VMs funktioniert (Name + Domain), zusätzlich zur Seriennummer. Diese Prüfung zu überspringen, ist der teuerste Fehler der Migration: Sie bemerken ein Problem erst, wenn sich ein Inventar verdoppelt hat.
Reale Konfiguration von GLPI Agent
Herzstück der Migration ist die Konfigurationsdatei. Unter Linux liegt sie in /etc/glpi-agent/agent.cfg (mit conf.d/ für Overrides). Ein Wert server zeigt direkt auf ein natives Inventar, und mit einer tag leiten wir ein Asset per Regel in die richtige Einheit des Kunden:
# /etc/glpi-agent/agent.cfg (substitui o agent.cfg antigo do FusionInventory)
server = https://glpi.cliente.com/front/inventory.php
tag = matriz-sp # roteia o ativo para a entidade certa via regra
delaytime = 3600 # janela aleatoria ate o 1o envio (evita pico simultaneo)
httpd-trust = 127.0.0.1, 10.20.0.0/24 # IPs que podem forcar execucao remota
httpd-port = 62354
no-ssl-check = 0 # 1 apenas se o certificado do GLPI for interno/self-signed
logger = File
logfile = /var/log/glpi-agent.logUnter Windows erfolgt ein Massen-Rollout per GPO oder Verwaltungswerkzeug mit stillem MSI. Dieselbe tag und derselbe server wie in einer Linux-Datei werden als Eigenschaften des Installers übergeben:
:: 1) Desinstalar o FusionInventory Agent (GUID na chave Uninstall do registro)
msiexec /x "{GUID-DO-FUSIONINVENTORY-AGENT}" /quiet /norestart
:: 2) Instalar o GLPI Agent apontando para o inventario NATIVO do GLPI
msiexec /i GLPI-Agent-1.11-x64.msi /quiet /norestart ^
SERVER="https://glpi.cliente.com/front/inventory.php" ^
TAG="matriz-sp" RUNNOW=1 ADD_FIREWALL_EXCEPTION=1Die Eigenschaft RUNNOW=1 erzwingt einen Versand direkt nach der Installation, was den Validierungszyklus einer Welle verkürzt: Sie warten nicht auf den nächsten geplanten Lauf, um ein Asset ankommen zu sehen. Und ADD_FIREWALL_EXCEPTION=1 gibt den lokalen Port 62354 frei, über den wir später eine Ausführung aus der Ferne erzwingen (nützlich, wenn sich ein Los nicht gemeldet hat).
Migration in Wellen, nicht als Big Bang
Die ganze Flotte auf einmal umzustellen, ist ein sicherer Weg, ein Wochenende zu verlieren. Unser Ablauf:
- Importregeln prüfen - Zuordnung über Seriennummer/UUID mit Fallback Name+Domain für VMs. Dieser Schritt verhindert Duplikate.
- Aktives natives Inventar bestätigen - der Server muss unter
/front/inventory.phpempfangen, bevor ein neuer Agent dorthin zeigt. - Pilotwelle - 5 % bis 10 % der Flotte, segmentiert nach Standort-
tag. Vor dem Weitermachen wird bestätigt, dass es null Duplikate gibt. - Rollout nach Losen - GPO/Ansible entfernt FusionInventory und installiert GLPI Agent. Jedes Los wird vor dem nächsten geprüft.
- Erst am Ende - wenn 100 % migriert sind, wird das Plugin FusionInventory auf dem Server deaktiviert und deinstalliert.
FusionInventory Agent vs. GLPI Agent
| Aspekt | FusionInventory Agent | GLPI Agent |
|---|---|---|
| Pflege | Community, keine neuen Releases | Offiziell von Teclib, aktive Releases |
| Einlieferung in GLPI | Plugin FusionInventory (eigener Endpoint) | Natives Inventar (/front/inventory.php) |
| GLPI 11 | Nicht unterstützt | Unterstützt |
| Tasks (Discovery, Deploy, ESX) | Ja | Ja (gleicher Umfang) |
| Lokale Schnittstelle | Port 62354 | Port 62354 |
| Konfiguration | agent.cfg | agent.cfg + conf.d/ |
Prüfung: was wir vor dem Abschluss einer Welle kontrollieren
Keine Welle ist abgeschlossen, nur weil ein Agent installiert wurde. Der erste Test ist, einen Versand zu erzwingen und die Rückmeldung direkt auf dem Host zu lesen:
# Forcar um envio e acompanhar em modo debug (Linux)
glpi-agent --force --debug
# Status local do agente (porta padrao 62354)
curl -s http://localhost:62354/statusAuf Serverseite ist ein Sicherheitsnetz eine Abfrage, die die gesamte Flotte nach einem klassischen Symptom einer missglückten Migration durchsucht - zwei Assets mit derselben Seriennummer:
-- Ativos com o mesmo serial: candidatos a duplicata pos-migracao
SELECT serial, COUNT(*) AS total, GROUP_CONCAT(id) AS ids
FROM glpi_computers
WHERE is_deleted = 0 AND serial <> ''
GROUP BY serial
HAVING total > 1
ORDER BY total DESC;Liefert diese Abfrage nach einer Pilotwelle kein Ergebnis, stimmen die Importregeln, und ein Rollout kann schneller voranschreiten. Liefert sie Zeilen, halten wir an: Jetzt muss eine Regel angepasst werden, statt weitere Agenten zu installieren. Außerdem prüfen wir in der Agentenliste von GLPI, ob sich ein „letzter Kontakt“ aktualisiert - ein Agent, der installiert wurde, sich aber innerhalb von 24 Stunden nicht meldet, hat meist ein internes SSL ohne no-ssl-check oder eine Firewall, die ausgehenden Verkehr blockiert.
Eine Migration einer Inventarflotte ist ein Projekt: Sie umfasst Prüfung von Regeln, Pilot, kontrollierten Rollout und eine objektive Kontrolle, dass nichts dupliziert wurde. Wenn Sie GLPI mit FusionInventory betreiben und ohne Überraschungen zu GLPI Agent wechseln möchten, ist genau diese Arbeit unser Fach bei NexTool. Sprechen Sie mit uns über Projekte und Implementierung Ihrer GLPI-Umgebung.
Geprüft vom Team von NexTool Solutions.
