GLPI: open-source Service Desk и учёт ИТ-активов на своём сервере

Glpi установка становится критическим этапом для российских компаний, стремящихся заменить зарубежные Service Desk-решения на отечественные или open-source аналоги в рамках импортозамещения. Размещение данных в собственном контуре обеспечивает соответствие требованиям 152-ФЗ и независимость от внешних вендоров.

Система GLPI, разрабатываемая компанией Teclib’, объединяет функционал обработки инцидентов, управления заявками и настройки SLA с возможностями автоматизированной инвентаризации ИТ-активов. Такой подход позволяет закрыть две задачи одновременно: организовать службу поддержки и вести учёт оборудования без закупки отдельных лицензий.

GLPI — это open-source-решение для управления ИТ-услугами (IT Service Management), которое разрабатывает компания Teclib’. В отличие от большинства бесплатных «тикетниц», GLPI одновременно закрывает две задачи: Service Desk с заявками и SLA — и инвентаризацию ИТ-активов с собственной CMDB. На наших проектах мы ставим GLPI там, где заказчик хочет уйти от Excel-таблиц с серийниками и одновременно перестать платить за облачный helpdesk.

Helpdesk-модуль обрабатывает инциденты и запросы, позволяет собрать каталог услуг через настраиваемые формы и зафиксировать SLA на типы заявок. На практике это значит, что у нас в одной системе живёт и «не работает почта», и «нужен новый ноутбук», и «согласование доступа к 1С» — с разной маршрутизацией и разным временем реакции. Каталог форм мы используем как точку входа для пользователей вместо абстрактной «общей очереди».

Вторая половина продукта — учёт активов и CMDB. GLPI ведёт оборудование, ПО и связи между ними, поддерживает динамическую инвентаризацию, которая в фичелисте обозначена как agentless. Дополнительно система умеет сканировать сети и собирать данные по SNMP, что закрывает учёт принтеров, коммутаторов и точек доступа. У нас был опыт, когда клиент годами вёл сетевое оборудование в текстовом файле — после переезда в GLPI исчезла привычная проблема «где этот коммутатор физически стоит».

Поверх этого есть финансовый блок: бюджеты, поставщики, лицензии и расходы централизуются в одном интерфейсе. Для среднего бизнеса это удобно — вместо отдельной таблицы по лицензиям Microsoft и отдельной по антивирусу всё лежит привязанным к активам.

Отдельные модули закрывают сопредельные задачи: управление мобильными приложениями и устройствами (MAM/MDM), управление антивирусом и оповещения по безопасности. По нашему опыту, MDM-возможности GLPI заменяют отдельный продукт не во всех сценариях, но как реестр корпоративных телефонов с базовой политикой — работают предсказуемо. В сумме GLPI 11 — это не «ещё одна тикетница», а связка Service Desk + CMDB + финансовый учёт в одном веб-интерфейсе.

Прямой ответ: GLPI — это open-source-продукт европейской компании Teclib’, и в Едином реестре российского ПО Минцифры он не числится. Поэтому формально GLPI не подходит госзаказчикам и субъектам КИИ, где закупка обязана идти через реестровое ПО. Для коммерческого сектора, который не связан 44-ФЗ и не относится к субъектам КИИ, ограничение неактуально — GLPI ставится как обычное свободное ПО на свой сервер.

На рынке Service Desk до 2022 года стандартом де-факто были Naumen Service Desk, ManageEngine ServiceDesk Plus, JIRA Service Management, BMC Helix. Лицензии западных продуктов перестали продаваться в РФ, продление вызывает вопросы, а российские альтернативы из реестра — это коммерческие продукты с подпиской на пользователя. GLPI закрывает ту же функциональную нишу — заявки, SLA, CMDB, формы каталога услуг — без лицензионных платежей и с размещением данных в собственном контуре заказчика.

Для 152-ФЗ это удобно: персональные данные сотрудников и пользователей остаются на сервере заказчика, никакая «облачная» обработка третьим лицом не возникает. Мы на наших проектах разворачиваем GLPI в инфраструктуре заказчика — на физическом сервере в его серверной либо в виртуальной машине в его контуре, без выхода во внешнее облако. Это снимает значительную часть вопросов по обработке ПДн внутри тикет-системы.

Сравнение по задачам выглядит так:

Не делайте ставку на GLPI, если заказчик участвует в госзакупках с требованием реестрового ПО — мы сталкивались с тем, что после внедрения отдел закупок возвращал решение на доработку именно по этому критерию. Для частной компании, которой нужен Service Desk на своих серверах без лицензионных счетов, glpi установка — рабочий путь к импортозамещению без перехода на платную подписку.

GLPI — это веб-приложение на PHP, которое работает с реляционной базой MySQL или MariaDB и отдаётся пользователям через веб-сервер. Минимальный набор компонентов: Linux-сервер, PHP с набором расширений, СУБД MariaDB или MySQL и веб-сервер Apache либо Nginx. Конкретные минимальные версии PHP и СУБД зависят от версии GLPI — для GLPI 11 актуальные требования всегда нужно сверять с разделом requirements в официальной документации, потому что они подтягиваются вместе с релизами.

На наших проектах для небольшой инсталляции (до нескольких сотен активов и десятков техников) мы закладываем виртуальную машину с 2–4 vCPU и 4–8 ГБ памяти, отдельным диском под базу и резервным копированием. Для нагрузок выше — несколько тысяч активов, активная инвентаризация агентами, плагины отчётности — память и диск масштабируются. Точные цифры мы не зашиваем в шаблон: для GLPI скорость диска под MariaDB и настройки PHP-OPcache важнее числа ядер CPU.

Из обязательного на стороне ОС:

– актуальное LTS-ядро дистрибутива (Debian, Ubuntu, AlmaLinux, Rocky, РЕД ОС, Astra Linux Common Edition) — мы используем те же сборки, на которых работает остальная инфраструктура заказчика; – PHP с расширениями для работы с MySQL, XML, GD, intl, mbstring, curl, ldap, zip — конкретный список обновляется в документации GLPI; – MariaDB или MySQL с правом создать отдельную базу и пользователя под GLPI; – веб-сервер с поддержкой PHP-FPM (Nginx) или mod_php (Apache); – TLS-сертификат — внутренний из своего PKI либо ACME-сертификат, если сервер доступен из интернета.

По нашему опыту, типичные грабли на этапе подготовки сервера три. Первая — забытое расширение PHP: установщик GLPI ругается уже на этапе проверки окружения, не критично, но добавляет ходок «доустановить пакет — перезапустить сервис». Вторая — слишком жёсткие лимиты PHP (memory_limit, upload_max_filesize, post_max_size): импорт инвентаря и вложения в заявках упираются именно в них. Третья — SELinux/AppArmor в режиме enforcing с дефолтными политиками: веб-сервер не может писать в каталоги GLPI, и интерфейс отдаёт ошибки прав доступа.

Не делайте glpi установка на сервер без отдельного дискового тома под /var/lib/mysql и без расписания бэкапов БД. Мы видели случай, когда после года эксплуатации база заняла основной раздел, веб-интерфейс встал, а единственный «бэкап» был снимком виртуальной машины полугодовой давности — восстановление активов пришлось вести вручную по бумажным актам.

Прямой ответ: glpi установка сводится к подготовке LAMP/LEMP-стека, разворачиванию архива GLPI в каталог веб-сервера, созданию базы данных и прохождению веб-инсталлятора в браузере. Ниже — последовательность, которую мы используем на типовых внедрениях GLPI 11 на Debian-подобных дистрибутивах. Команды демонстрационные — конкретные имена пакетов и параметры конфигов проверяйте под свой дистрибутив и версию GLPI.

Шаг 1. Ставим веб-сервер, PHP и СУБД. Список пакетов берём из документации к текущей версии GLPI — там перечислены требуемые расширения PHP.

Шаг 2. Создаём базу и пользователя под GLPI. Пароль формируем длинным и храним в менеджере секретов, а не в README репозитория.

Шаг 3. Скачиваем актуальный релиз GLPI с официальной страницы загрузки и распаковываем в каталог веб-сервера. Версию подставляйте из официального источника — мы не зашиваем её в скрипты, чтобы не привязываться к конкретной сборке.

Шаг 4. Конфигурируем виртуальный хост Apache (или server-блок Nginx + PHP-FPM) с DocumentRoot на /var/www/glpi/public. Закрываем доступ к служебным каталогам, как описано в документации GLPI: вынесение files/ и config/ за пределы DocumentRoot — обязательная практика безопасности.

Шаг 5. Открываем сайт в браузере и проходим веб-инсталлятор: проверка окружения → подключение к БД → создание схемы → завершение. Установщик создаёт стандартные учётные записи (glpi, tech, normal, post-only). Сразу меняем им пароли и удаляем файл install/install.php, как требует мастер установки.

Шаг 6. Включаем cron GLPI отдельным заданием от пользователя www-data, иначе фоновые задачи (уведомления, синхронизации, очистка) не будут отрабатывать. Альтернативно подключаем системный systemd-timer.

Не делайте «быструю» установку под root и без TLS: мы разбирали инциденты, где админ выкладывал GLPI на корпоративный VPN-сегмент по HTTP, и через год в логах находились следы внешних сканеров, нащупавших порт.

После веб-инсталлятора GLPI выглядит «пустым»: один админ, дефолтные категории и ни одной заявки. Первое, что мы делаем на наших проектах — приводим в порядок организационную структуру и аутентификацию. В Setup → Authentication подключаем LDAP/AD: пользователи логинятся доменными учётными данными, локальные учётки остаются только для админа и сервисных интеграций. По нашему опыту, без LDAP пользователи плодят локальные пароли, и через полгода в базе нерабочих учёток больше, чем активных.

Сущности (Entities) в GLPI — это иерархия организаций, под которую подгоняются права. Для одного юрлица обычно достаточно корневой сущности и пары дочерних под филиалы. Профили (Profiles) определяют, что видит роль: техник, наблюдатель, менеджер, конечный пользователь. Мы стараемся не плодить кастомные профили, пока не появилось внятное требование — стандартных хватает в 90% случаев.

Дальше настраиваем модель работы с заявками. В Setup → Dropdowns заводим категории ITIL: инцидент vs запрос на обслуживание, типы оборудования, причины обращений. В Helpdesk-форме оставляем минимально нужный набор полей — длинная форма гарантированно отпугнёт пользователей и они вернутся к звонкам.

SLA настраивается на уровне сущности и привязывается к типу заявки и приоритету. Мы обычно начинаем с двух уровней: рабочее время реакции на обычные обращения и сокращённое — на критичные сервисы. Эскалации (Escalations) в GLPI настраиваются на превышение TTR/TTO с автоматическим повышением приоритета или назначением группы — это сразу даёт прозрачность отчётов «сколько заявок ушло за SLA».

Сбор заявок из почты — обязательный модуль. В Setup → Receivers подключаем почтовый ящик по IMAP/IMAPS, указываем, в какую сущность и категорию по умолчанию падают входящие письма. На наших внедрениях мы заводим отдельный ящик support@… и почтовый ящик it@…, оба собираются в одну очередь, но с разной маркировкой. Уведомления о статусах заявок настраиваем в Setup → Notifications с шаблонами на русском.

Каталог форм (Service Catalog) — это то, ради чего часть заказчиков и переходит на GLPI. Делаем форму «Заявка на доступ», «Новый сотрудник», «Заявка на технику» — каждая со своими полями и маршрутом согласования. Это снимает 60–70% «свободных» обращений, потому что у пользователя в самообслуживании есть конкретные кнопки на типовые сценарии.

Не делайте всё сразу: мы видели, как админ за выходные настраивал десятки правил эскалации и SLA, после чего ни одна заявка не попадала тому, кому должна. Лучше двигаться итерациями: базовые категории → SLA → почта → каталог форм, проверяя поведение на тестовых заявках.

GLPI Agent — это клиентское приложение для автоматического сбора инвентарных данных с рабочих станций и серверов и передачи их в GLPI. В фичелисте продукта инвентаризация описана как dynamic inventory (agentless), но на практике для полноценного сбора данных с конкретного хоста — серийник материнской платы, модель диска, установленное ПО, список патчей — нужен именно агент. Agentless-режим работает по сети через SNMP и подходит для сетевого оборудования; для ПК и серверов мы ставим GLPI Agent.

Агент кроссплатформенный — есть сборки под Windows, Linux, macOS. На Windows мы разворачиваем через групповые политики или через систему распространения ПО, на Linux — через штатный пакетный менеджер или MSI/RPM/DEB-пакеты с сайта проекта. На стороне сервера в GLPI включается inventory-плагин (в новых версиях GLPI 11 он входит в ядро), указывается URL точки приёма данных, агент конфигурируется на этот URL.

Минимальная конфигурация агента на Linux выглядит так:

Тег (--tag) — наша рабочая практика для разделения парка по площадкам, проектам, юрлицам. По нему потом строятся отчёты и фильтруются активы. Запуск агента ставится по расписанию: на Windows — служба, на Linux — systemd-таймер. Мы не используем «ручной» запуск, потому что инвентарь должен собираться без участия пользователя и без «забывания».

Для сетевого оборудования настраиваем отдельный агент в режиме сетевого сканера: ему даются диапазоны IP и SNMP-сообщества, он опрашивает коммутаторы, маршрутизаторы, принтеры, точки доступа и грузит данные в GLPI. На наших проектах один такой агент-«сборщик» закрывает целиком сегмент сети филиала.

После того как агенты заработали, в Assets появляются автоматически наполняемые карточки. Связь активов с заявками — главная польза: при создании тикета техник видит конфигурацию железа без переспрашивания пользователя. Финансовый блок подвязывает к этим активам стоимость покупки, поставщика и срок гарантии — и инвентаризация перестаёт быть «отдельной таблицей».

Не делайте инвентаризацию без правил дедупликации: мы сталкивались с ситуацией, когда один и тот же ноутбук после переустановки ОС попадал в GLPI как новый актив, и за полгода парк «вырос» в полтора раза. В правилах импорта (Rules → Inventory) обязательно настраиваются ключи сопоставления — серийник, UUID, MAC — иначе чистоту базы потом приходится восстанавливать руками.

GLPI поставляется с английским и французским интерфейсом из коробки, русская локализация подключается в профиле пользователя или глобально в Setup → General. Перевод поддерживается сообществом, в типовых разделах (заявки, активы, настройки) он полный; в новых модулях иногда встречаются непереведённые строки, и тогда мы либо оставляем их в оригинале, либо дополняем перевод в собственном .po-файле и кладём в каталог локалей. Для пользователей-неайтишников русский интерфейс — обязательное условие приёмки, мы это закладываем в чек-лист сдачи.

Экосистема плагинов закрывает то, чего не хватает в ядре. На наших внедрениях стабильно ставятся пять-шесть штук, остальное — по запросу:

– Formcreator — конструктор форм самообслуживания, расширяет штатный каталог сервисов более гибкой валидацией и сценариями согласования; – More Reporting / Reports — расширенные отчёты поверх стандартных по заявкам, SLA, активам; – Fields — добавление кастомных полей к любым сущностям без правки кода; – Behaviours — тонкая настройка поведения тикетов (запрет закрытия без решения, обязательные поля, лог изменений); – DataInjection — массовый импорт активов и пользователей из CSV; – Webhooks / Genericobject — интеграции с внешними системами и собственные типы объектов.

Плагины ставятся через каталог GLPI Marketplace либо вручную: распаковка в plugins/, включение в интерфейсе. Совместимость с конкретной версией ядра — главный риск: после мажорного обновления GLPI 11 часть сторонних плагинов нуждается в обновлении, и до выхода патча модуль может быть нерабочим. На наших проектах перед обновлением мы обязательно прогоняем «генеральную репетицию» на тестовом стенде с тем же набором плагинов, что в проде.

Отдельный класс задач — интеграции. GLPI заявлен как продукт, который «легко стыкуется с разными инструментами», и на практике мы подключаем его к Active Directory для аутентификации и импорта пользователей, к корпоративным мессенджерам через webhook-плагины для уведомлений о новых заявках, к мониторингу (Zabbix, Prometheus Alertmanager) для автоматического создания инцидентов из срабатываний. С мониторингом особенно полезно: критичные алерты сами создают тикет с привязкой к активу из CMDB, без участия дежурного.

Безопасность плагинов мы держим под контролем: ставим только те, что есть в официальном Marketplace или в репозиториях разработчиков с активной поддержкой. Сторонние «архивы с форумов» в продакшен не идут. Не делайте установку плагина «на боевую» без проверки на стенде — мы один раз нарвались на плагин, который при включении начинал тяжёлый миграционный скрипт по базе и положил веб-интерфейс на сорок минут в рабочее время. С тех пор любое расширение функциональности — сначала стенд, потом окно обслуживания.

Ответы на часто задаваемые вопросы по теме статьи.

Константин Тютюнник — ведущий инженер IT For Prof. Специализируется на внедрении open-source решений для управления ИТ-инфраструктурой. Имеет опыт развёртывания GLPI в компаниях с парком более 1000 устройств, уделяя особое внимание автоматизации инвентаризации и интеграции с мониторингом.