Установка GLPI Agent — это лишь 20% работы. Станет ли инвентаризация источником надёжных данных, решает конфигурация на стороне сервера: включение инвентаризации, настройка cron, обработка дублирующихся серийных номеров и защита правил импорта. В этом руководстве описан путь, который мы используем в сопровождении клиентских инсталляций GLPI, с настройками, которые не дают CMDB заполниться призраками.
Шаг 0: включить инвентаризацию на сервере (шаг, который все пропускают)
Самая частая ошибка, которую мы встречаем, — агент корректно установлен на рабочих станциях, а инвентаризация в GLPI выключена. Без этого переключателя POST-запросы агентов попадают в endpoint, который ничего не обрабатывает, и поддержка часами винит файрвол. Прежде чем массово ставить агенты, проверьте на сервере:
- В Настройки > Общие > вкладка Инвентаризация отметьте Включить инвентаризацию.
- Проверьте нативный endpoint GLPI 10/11:
https://glpi.suaempresa.com/front/inventory.php(агент 1.x сам определяет этот путь по базовому URL). - В настройках инвентаризации проверьте параметры импорта: импорт компьютеров, мониторов, принтеров и компонентов в соответствии с политикой клиента.
Развёртывание GLPI Agent (Windows и Linux)
В Windows стандартом для GPO является тихая установка MSI. TAG — самый важный параметр, и им пользуются реже всего: именно по нему правила импорта направляют актив в нужную организацию и местоположение.
glpi-agent-1.x-x64.msi /qn SERVER=https://glpi.yourcompany.com TAG=branch-spВ Linux официальный установщик сам позаботится о зависимостях:
curl -sL https://raw.githubusercontent.com/glpi-project/glpi-agent/main/tools/linux-installer.sh | bash -s -- --server https://glpi.yourcompany.com --tag branch-spНезависимо от ОС поведение агента задаётся в файле конфигурации. Вот базовая конфигурация, которую мы стандартизировали:
# /etc/glpi-agent/agent.cfg (Linux)
# %ProgramFiles%\GLPI-Agent\etc\agent.cfg (Windows)
# Native GLPI 10/11 endpoint (the 1.x agent resolves /front/inventory.php):
server = https://glpi.yourcompany.com
# TAG used by the rules to route entity/location (e.g. branch):
tag = branch-sp
# Resend frequency in seconds (86400 = once a day):
delaytime = 86400
# Random window: avoids everyone reporting in the same login minute:
lazy = 1
# ONLY on an internal network with a self-signed certificate:
# no-ssl-check = 1Cron: гарантировать, что инвентаризация действительно обрабатывается
Здесь кроется классическая ловушка. По умолчанию автоматические действия GLPI работают в режиме GLPI (запускаются, когда кто-то перемещается по системе). Это непредсказуемо: в выходные, когда никто не залогинен, ничего не выполняется. Для надёжной инвентаризации, телеметрии и очередей переведите автоматические действия в режим CLI (внешний) и запланируйте cron операционной системы. В GLPI 11 точка входа — front/cron.php (консоль bin/console glpi:cron покрывает не всё):
# /etc/cron.d/glpi - processes GLPI automatic actions and queues
# Runs as the PHP user (apache/www-data), every 2 minutes:
*/2 * * * * apache /usr/bin/php /var/www/glpi/front/cron.php >/dev/null 2>&1Затем в Настройки > Автоматические действия откройте каждую нужную задачу и смените режим выполнения с GLPI на CLI. Без этого клиент жалуется на «устаревшую инвентаризацию», а причина вовсе не в агенте.
SNMP discovery: коммутаторы, маршрутизаторы и принтеры
Рабочие станции с агентом — простая часть. Сетевые устройства агент не запускают и зависят от SNMP. Работающая последовательность:
- Установите сетевые задачи на агенте-концентраторе (пакет
glpi-agent-task-networkв Linux; установщик для Windows уже включает модули SNMP). - Зарегистрируйте учётные данные SNMP (community v2c или v3) в Администрирование > Инвентаризация > Учётные данные SNMP.
- Задайте диапазоны IP для сканирования в Администрирование > Инвентаризация > Диапазоны IP.
- Запланируйте задачи Network discovery (обнаруживает, что есть в сети) и Network inventory (собирает подробности по уже обнаруженному).
Частая ошибка здесь — запланировать Network inventory, не запустив сначала discovery: без обнаруженного и классифицированного оборудования подробно инвентаризировать нечего.
Правила импорта и проблема дублирующихся серийных номеров
В сопровождении инсталляций с сотнями машин больше всего «призраков» в инвентаризации порождает не агент, а шаблонный серийный номер. Ноутбуки и собранные десктопы сообщают серийный номер To be filled by O.E.M., System Serial Number или 0000000000; виртуальные машины, клонированные из одного шаблона, несут ОДИН И ТОТ ЖЕ UUID. Если правило импорта сопоставляет по серийному номеру, GLPI привязывает все эти машины к ОДНОМУ активу или создаёт десятки дублей в каждом цикле инвентаризации. Мы решили стандартизировать два механизма у всех клиентов: во-первых, внести такие мусорные серийные номера и MAC-адреса во вкладку Чёрный список настроек инвентаризации, чтобы GLPI их игнорировал; во-вторых, добавить в правило импорта (Администрирование > Правила > Правила импорта и связывания оборудования) критерий по UUID помимо серийного номера. Частая ошибка — полагаться только на серийный номер и обнаружить ущерб через три месяца, когда CMDB раздута, а подсчёт лицензий ПО превышен из-за дублей.
Диагностика: SQL для поиска «молчащих» агентов
Когда клиент спрашивает «сколько машин перестали отчитываться?», интерфейс быстро не ответит. Этот запрос выводит агенты без связи более 7 дней — кандидатов на выключенную машину, переустановку образа или остановленную службу агента:
-- Agents with no contact for more than 7 days
SELECT a.name AS agent, a.last_contact, c.name AS computer
FROM glpi_agents a
LEFT JOIN glpi_computers c
ON c.id = a.items_id AND a.itemtype = 'Computer'
WHERE a.last_contact < (NOW() - INTERVAL 7 DAY)
ORDER BY a.last_contact ASC;Выполняйте через SQL-клиент в режиме только для чтения. Всплеск молчащих агентов обычно совпадает с изменением GPO, истёкшим сертификатом или новым правилом файрвола.
Матрица устранения неполадок на практике
| Симптом | Вероятная причина | Исправление |
|---|---|---|
| Агент не появляется в Администрирование > Инвентаризация | Инвентаризация выключена на сервере или неверный URL/порт | Включить в Настройки > Общие; проверить /front/inventory.php и файрвол 443/80 |
| POST возвращает 413 или инвентаризация обрезана | Низкие post_max_size / upload_max_filesize в PHP | Поднять до 20M или выше и перезапустить php-fpm; серверы с большим количеством ПО генерируют большой XML |
| Ошибка SSL в логе агента | Недоверенный самоподписанный сертификат | Установить CA на машину или no-ssl-check = 1 (только во внутренней сети) |
| Машины дублируются в каждом цикле | Шаблонный серийный номер или UUID клонированного шаблона | Чёрный список серийных номеров/MAC + критерий по UUID в правиле импорта |
| Сетевые устройства не инвентаризируются | Нет сетевой задачи или учётных данных SNMP | Установить glpi-agent-task-network; зарегистрировать учётные данные SNMP и диапазоны IP |
| Данные всегда устаревшие | Автоматические действия в режиме GLPI (не выполняются без трафика) | Перевести в режим CLI и запланировать front/cron.php в cron ОС |
От инвентаризации к жизненному циклу актива
Сбор данных — половина работы. Инвентаризация становится управлением, только когда поступающие данные классифицируются, стандартизируются и проверяются: правила импорта направляют организацию и категорию, словари нормализуют названия производителей и моделей, а журнал аудита фиксирует, когда актив появляется, меняет владельца или исчезает из инвентаризации. Именно эта цепочка отличает «установить GLPI Agent» от «поддерживать надёжную инвентаризацию».
Если ваша инвентаризация GLPI полна дублей, агенты пропадают, а сетевые устройства выпадают из карты, команда сопровождения GLPI NexTool пересмотрит правила импорта, настроит чёрный список и свяжет инвентаризацию с жизненным циклом активов. Обратитесь к нам по поводу сопровождения GLPI.
Проверено командой NexTool Solutions.
