Миграция с FusionInventory на GLPI Agent — это не «удалить один и установить другой». При сопровождении парков GLPI, которые NexTool обслуживает для B2B-клиентов, исход миграции на самом деле определяет защита привязки актива: нужно гарантировать, что каждая машина, сменившая агента, продолжит попадать в ту же запись в GLPI и не превратится в дубликат. В этой статье показано, как мы планируем и выполняем такую массовую замену — от точки приёма данных до проверки, которая закрывает каждую волну.
Что меняется на самом деле: точка приёма данных
FusionInventory Agent передавал данные в GLPI через плагин FusionInventory с собственной конечной точкой. GLPI Agent передаёт их во встроенную инвентаризацию ядра, которая принимает данные по адресу /front/inventory.php. Во время перехода на одном сервере сосуществуют два разных пути приёма данных. Агент — лишь половина истории: вторая половина — избавить сервер от зависимости от плагина. Поэтому порядок важен: сначала мигрируют парк и только потом отключают и удаляют плагин FusionInventory, никогда не наоборот. Удаление плагина до завершения миграции парка обрывает поток данных от агентов, которые ещё не заменены.
Хорошая новость для тех, кто боится потерять функциональность: GLPI Agent сохраняет те же задачи (tasks), что и FusionInventory (Inventory, NetDiscovery, NetInventory, Deploy, ESX, Collect и RemoteInventory). Ни сетевое обнаружение, ни развёртывание при замене не теряются; меняются бинарный файл и точка доставки, а не набор возможностей.
Реальный риск: дублирование активов (и почему оно происходит)
Вот деталь, которая проявляется, только когда вы делаете это в продуктиве. У каждого агента есть deviceid (что-то вроде hostname-2026-07-02-10-30-00). При установке GLPI Agent с нуля генерируется новый deviceid. Это создаёт в GLPI новую запись агента — но не должно создавать новый компьютер, потому что сопоставление актива выполняется правилами импорта по серийному номеру и UUID, а не по deviceid.
На практике дублируются почти никогда не физические рабочие станции: у них есть заводской серийный номер, и они идеально сопоставляются. Дублируются виртуальные машины. ВМ с пустым серийным номером или с UUID, клонированным из шаблона, ускользает от сопоставления по серийному номеру/UUID и становится новым активом при каждой смене deviceid. Поэтому перед первой волной мы проверяем правила импорта и обеспечиваем резервный критерий, работающий для ВМ (имя + домен), помимо серийного номера. Пропустить эту проверку — самая дорогая ошибка миграции: вы обнаруживаете проблему, когда инвентаризация удвоилась в размере.
Реальная конфигурация GLPI Agent
Сердце миграции — файл конфигурации. В Linux он находится в /etc/glpi-agent/agent.cfg (с conf.d/ для переопределений). Параметр server указывает прямо на встроенную инвентаризацию, а tag мы используем, чтобы через правило направлять актив в нужную организацию клиента:
# /etc/glpi-agent/agent.cfg (replaces the old FusionInventory agent.cfg)
server = https://glpi.client.com/front/inventory.php
tag = hq-sp # routes the asset to the right entity via a rule
delaytime = 3600 # random window before the 1st send (avoids a spike)
httpd-trust = 127.0.0.1, 10.20.0.0/24 # IPs allowed to force a remote run
httpd-port = 62354
no-ssl-check = 0 # 1 only if the GLPI certificate is internal/self-signed
logger = File
logfile = /var/log/glpi-agent.logВ Windows массовое развёртывание выполняется через GPO или средство управления, с тихой установкой MSI. Те же tag и server, что и в файле для Linux, передаются как свойства установщика:
:: 1) Uninstall the FusionInventory Agent (GUID in the registry Uninstall key)
msiexec /x "{GUID-OF-THE-FUSIONINVENTORY-AGENT}" /quiet /norestart
:: 2) Install GLPI Agent pointing at the NATIVE GLPI inventory
msiexec /i GLPI-Agent-1.11-x64.msi /quiet /norestart ^
SERVER="https://glpi.client.com/front/inventory.php" ^
TAG="hq-sp" RUNNOW=1 ADD_FIREWALL_EXCEPTION=1Свойство RUNNOW=1 принудительно запускает отправку сразу после установки, что сокращает цикл проверки волны: не нужно ждать следующего запуска по расписанию, чтобы увидеть, как приходит актив. А ADD_FIREWALL_EXCEPTION=1 открывает локальный порт 62354, через который мы позже принудительно запускаем выполнение удалённо (полезно, когда какая-то партия не отчиталась).
Миграция волнами, а не «большим взрывом»
Заменить весь парк за один раз — верный способ потерять выходные. Процесс, которым мы пользуемся:
- Проверить правила импорта — сопоставление по серийному номеру/UUID с резервным вариантом «имя + домен» для ВМ. Именно этот шаг предотвращает дубликаты.
- Убедиться, что встроенная инвентаризация включена — сервер должен принимать данные по адресу
/front/inventory.phpдо того, как туда будет направлен хоть один новый агент. - Пилотная волна — 5–10% парка, с сегментацией по
tagплощадки. Перед продолжением проверяется отсутствие дубликатов. - Развёртывание партиями — GPO/Ansible удаляет FusionInventory и устанавливает GLPI Agent. Каждая партия проверяется перед следующей.
- Только в конце — при 100% миграции плагин FusionInventory отключается и удаляется с сервера.
FusionInventory Agent и GLPI Agent
| Аспект | FusionInventory Agent | GLPI Agent |
|---|---|---|
| Поддержка | Сообщество, новых релизов нет | Официально Teclib, активные релизы |
| Приём данных в GLPI | Плагин FusionInventory (собственная конечная точка) | Встроенная инвентаризация (/front/inventory.php) |
| GLPI 11 | Не поддерживается | Поддерживается |
| Задачи (discovery, deploy, ESX) | Да | Да (тот же набор) |
| Локальный интерфейс | Порт 62354 | Порт 62354 |
| Конфигурация | agent.cfg | agent.cfg + conf.d/ |
Проверка: что мы контролируем перед закрытием волны
Ни одна волна не закрывается только потому, что агент установился. Первая проверка — принудительно запустить отправку и прочитать ответ прямо на хосте:
# Force a send and follow it in debug mode (Linux)
glpi-agent --force --debug
# Local agent status (default port 62354)
curl -s http://localhost:62354/statusНа стороне сервера страховкой служит запрос, который проходит по всему парку в поисках классического симптома неудачной миграции — двух активов с одинаковым серийным номером:
-- Assets with the same serial: post-migration duplicate candidates
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;Если после пилотной волны этот запрос возвращает пустой результат, правила импорта настроены верно и развёртывание можно ускорять. Если возвращаются строки, мы останавливаемся: пора исправлять правило, а не ставить новые агенты. Мы также проверяем в списке агентов GLPI, обновляется ли «последний контакт»: агент, который установился, но не отчитывается в течение 24 часов, обычно упирается во внутренний SSL без no-ssl-check или в межсетевой экран, блокирующий исходящие соединения.
Миграция парка инвентаризации — это проект: проверка правил, пилот, контролируемое развёртывание и объективная проверка того, что ничего не задублировалось. Если у вас GLPI с FusionInventory и нужно перейти на GLPI Agent без сюрпризов, именно эту работу выполняет NexTool. Свяжитесь с нами по поводу проектов и внедрения вашей среды GLPI.
Проверено командой NexTool Solutions.
