GLPI в эксплуатации: обновления, бэкапы, безопасность и вебхуки

Почему GLPI нельзя поставить и забыть

За последний цикл статей я подробно разобрал, как выбрать GLPI, как развернуть его на VPS и как поднять автоинвентаризацию Windows-парка через GPO. Логично, что читатели, у которых система уже крутится в проде, задают следующий вопрос: а что с ней делать дальше? Ответ короткий и неприятный для любителей философии «поставил и забыл»: GLPI — это не мебель, это живой сервис, за которым нужно ухаживать. И если у вас нет внутреннего регламента сопровождения, то рано или поздно вы получите либо потерянные заявки, либо взломанный портал, либо БД, которую некуда откатить.

Давайте честно посмотрим, что такое типовая клиентская инсталляция глазами злоумышленника. Это публично доступный веб-портал на PHP, который смотрит наружу 24 часа в сутки. К нему прикручена аутентификация через LDAP или Active Directory — то есть за формой логина стоят реальные доменные учётные записи сотрудников компании. Для атакующего это идеальная мишень: один пробитый пароль сервис-инженера или одна незакрытая уязвимость в движке — и человек оказывается внутри с доступом к внутренней документации, спискам оборудования, IP-адресам, контактам и, потенциально, к доменным кредам. Портал заявок — это входная дверь во внутреннюю кухню компании, и относиться к ней надо соответственно.

GLPI как продукт с открытым кодом и огромной базой инсталляций периодически попадает в сводки эксплуатируемых уязвимостей. Это нормально и даже хорошо — значит, у проекта есть аудит и активное сообщество, которое находит и чинит дыры. Плохо другое: исторически в старых версиях всплывали SQL-инъекции, а через сторонние плагины из маркетплейса не раз прилетал риск удалённого выполнения кода. Ключевое слово здесь — «старых версиях» и «сторонние плагины». Подавляющее большинство инцидентов происходит не потому, что GLPI дырявый, а потому, что администратор годами не обновлял инсталляцию и накатил десяток непроверенных расширений.

Теперь про модель ответственности. Когда мы в ITfresh берём клиента на аутсорсинг, его GLPI становится нашей зоной ответственности целиком — от свободного места на диске до свежести патчей безопасности. Клиент не должен думать, вышло ли обновление и не пора ли проверить бэкап. Он платит за то, чтобы об этом думали мы. Именно поэтому у нас есть внутренний регламент сопровождения, который я и хочу разложить в этой статье по полочкам: как обновляться без страха, что бэкапить и как проверять восстановимость, как захарденить инсталляцию, как мониторить её здоровье и как мы с помощью нативных вебхуков GLPI 11 избавились от ручного дублирования заявок в Telegram. Всё, что ниже — это не теория из документации, а то, что мы реально делаем руками на клиентских серверах в дата-центре МТС.

Оговорюсь сразу: регламент — это не про бюрократию ради галочки. Это про предсказуемость. Когда у инженера есть чек-лист, он не забудет проверить статус cron после обновления и не оставит бэкап на том же диске, что и боевая база. Регламент превращает «надеюсь, всё хорошо» в «я проверил по пунктам, всё хорошо». Разница между этими двумя состояниями — это и есть разница между зрелым аутсорсингом и разовым сисадмином-эникейщиком.

Регламент обновлений

Обновление — самая частая операция в сопровождении GLPI и одновременно та, которой боятся сильнее всего. Страх иррациональный: если делать всё по порядку и иметь под рукой свежий бэкап, откатиться можно за пару минут. Мы разделяем обновления на два принципиально разных класса — минорные внутри текущей ветки и мажорные с переходом между ветками — и подходим к ним по-разному.

Минорные апдейты ветки 11.0.x

Это рутина. Выход версии вида 11.0.x относительно предыдущей 11.0.y почти всегда безопасен: меняется мелочь, чинятся баги и дыры, схема БД либо не трогается, либо мигрирует автоматически без сюрпризов. Такое обновление мы делаем в заранее оговорённое сервисное окно — обычно ранним утром буднего дня, когда заявки почти не создаются, но до начала рабочего дня ещё есть запас.

Порядок действий предельно механический. Сначала снапшот виртуалки на гипервизоре плюс свежий дамп базы — это наша страховка на случай, если что-то пойдёт не так. Затем распаковываем новый релиз поверх кода (или переключаем симлинк на новую директорию, если разложено по версиям), сохраняя каталоги config/, files/ и marketplace/. После этого запускаем миграцию через консоль:

php bin/console database:update
php bin/console cache:clear

Команда database:update сама определит, нужно ли трогать схему, и аккуратно накатит изменения. По завершении заходим в веб-интерфейс, открываем страницу состояния и убеждаемся, что GLPI видит правильную версию, cron живой, а базовые операции — создание тестовой заявки, поиск, открытие актива — работают.

Двадцать минут на инженера — и инсталляция снова на актуальном патче безопасности. Именно потому, что процедура короткая и отрепетированная, мы не боимся делать её часто. Страх обновлений рождается из редкости: если накатывать раз в год, каждый раз будет казаться прыжком в неизвестность.

Мажорные обновления (10 → 11)

Переход между ветками — совсем другая история, и относиться к нему надо как к проекту, а не как к рутинной операции. Одиннадцатая ветка принесла новый интерфейс, интегрированный в ядро конструктор форм (то, что раньше жило в плагине Formcreator), нативную двухфакторную аутентификацию, нативные вебхуки и подросшие требования к окружению — PHP 8.2 и выше, свежая MariaDB, документ-рут теперь указывает на каталог public/. Всё это ломает часть старых привычек и старых плагинов.

Наш порядок мажорного обновления такой. Сначала внимательно читаем список breaking changes официального релиза — не по диагонали, а с карандашом, отмечая, что именно затронет конкретную клиентскую инсталляцию. Затем поднимаем тестовую копию: разворачиваем клон боевой БД на отдельной машине и прогоняем на нём миграцию целиком, от начала до конца. Только увидев, что копия успешно поднялась и работает, мы планируем обновление боевого сервера. Отдельный и самый болезненный этап — ревизия плагинов: часть из них в новой ветке не нужна, потому что функциональность переехала в ядро, часть ещё не портирована авторами, а часть придётся заменить аналогом.

Практический вывод: перед мажорным прыжком составьте список своих плагинов и напротив каждого честно напишите его судьбу. Инсталляция, которая тянет за собой пяток неподдерживаемых расширений, — главная причина, по которой люди застревают на старой ветке годами. Меньше плагинов — легче обновляться, и это прямая инвестиция в безопасность.

Подписка на анонсы безопасности

Чтобы не узнавать о критических дырах из новостей о взломе, мы подписаны на официальные каналы проекта: анонсы релизов, GitHub-репозиторий (releases и security advisories) и рассылку. Как только выходит релиз с пометкой о фиксе безопасности, у нас внутри поднимается задача, а SLA на её выполнение зависит от критичности: обычный багфикс — в ближайшее сервисное окно, критический фикс RCE — вне очереди, тем же днём. Информированность — это половина харденинга: нельзя закрыть дыру, о которой ты не знаешь.

Бэкапы, которые реально восстанавливаются

Бэкап, который никто ни разу не разворачивал, — это не бэкап, а самоуспокоение. Я видел слишком много инсталляций, где годами исправно крутился ночной дамп базы, а в момент аварии выяснялось, что восстановить рабочую систему из него невозможно. Поэтому у нас в регламенте бэкап описан не как «делаем дамп», а как «умеем восстановить всё целиком за понятное время». Разница принципиальная.

Что именно мы бэкапим

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

• База данных — mysqldump всей схемы GLPI. Здесь живут заявки, активы, пользователи, связи, история. Сердце системы.
• Каталог files/ — все вложения к заявкам, загруженные документы, сгенерированные PDF, кеши. Без него база будет ссылаться на несуществующие файлы, и половина тикетов откроется с битыми вложениями.
• Каталог config/ — конфигурация подключения к БД, ключи шифрования, локальные настройки. Именно ключом из config/ расшифровываются пароли, хранящиеся в базе (например, пароль сервисной LDAP-учётки). Восстановите базу без родного config/ — и получите нерасшифровываемые секреты.
• Каталог marketplace/ (или plugins/) — установленные плагины и их данные. Иначе после восстановления система не поднимется, ругаясь на отсутствующие расширения.

Наш скрипт

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

#!/bin/bash
set -euo pipefail
DEST=/backup/glpi
STAMP=$(date +%F)
mysqldump --single-transaction --quick glpidb | gzip > "$DEST/db-$STAMP.sql.gz"
tar czf "$DEST/files-$STAMP.tar.gz" -C /var/www/glpi files config marketplace
# ротация: держим 14 дней
find "$DEST" -name '*.gz' -mtime +14 -delete
# выгрузка на второй сервер / в S3
rclone copy "$DEST" remote:glpi-backup-$STAMP

Ключевые детали: --single-transaction снимает консистентный дамп без блокировки таблиц на рабочей системе, gzip экономит место в разы, ротация в 14 дней не даёт бэкапам съесть диск, а последняя строка — самое важное — уносит копию прочь с сервера, на второй хост или в объектное хранилище S3. Копия, лежащая рядом с оригиналом, спасает только от «случайно удалил заявку», но не от «сгорел сервер» или «зашифровал шифровальщик».

Ежеквартальный тест восстановления

Раз в квартал мы берём свежий бэкап клиента и разворачиваем его с нуля на чистой виртуалке: ставим PHP и MariaDB, заливаем дамп, распаковываем файловые каталоги, прописываем config/ и проверяем, что система поднялась, заявки на месте, вложения открываются, вход работает. Это единственный способ узнать заранее, а не в момент катастрофы, что бэкап рабочий и что мы помним всю процедуру восстановления. Заодно проверяется, за сколько времени реально поднять систему — это наш фактический RTO, а не цифра из договора.

Типовая ошибка

Повторю ещё раз, потому что это встречается чаще всего: бэкап на том же VPS, где живёт боевая система, — это не бэкап. Диск умирает целиком вместе с бэкапами, шифровальщик доберётся и до них, случайное rm -rf заденет всё разом. Копия обязана физически покидать сервер. У нас это второй сервер в другом сегменте плюс S3-хранилище — два независимых адреса, чтобы одна авария не забрала обе копии.

Харденинг инсталляции

Харденинг — это набор мер, которые превращают инсталляцию из «работает» в «работает и не пробивается за пять минут». По отдельности каждая мелочь кажется необязательной, но вместе они поднимают стоимость атаки настолько, что автоматизированные боты и скучающие скрипт-кидди уходят искать цель полегче. Пройдусь по тому, что мы включаем на каждом клиентском GLPI.

Двухфакторная аутентификация (TOTP)

Одиннадцатая ветка принесла нативную двухфакторную аутентификацию по TOTP — теперь не нужны сторонние плагины. Настраивается она гибко: глобально, по профилю, по группе или индивидуально, и — что важно — её можно сделать обязательной. Мы принудительно включаем 2FA как минимум для всех, у кого есть административные права: супер-админы, инженеры техподдержки, любые учётки с доступом к настройкам. Одного пароля для админки в 2026 году категорически мало. Пользователь заводит приложение-аутентификатор, сканирует QR, и дальше вход в привилегированную учётку требует одноразовый код. Для рядовых пользователей портала 2FA обычно оставляем опциональной, чтобы не создавать трения там, где риск невелик.

Разделение админки и портала по доступу

Здесь важная архитектурная мысль: портал заявок и админ-панель — это разные уровни доверия, хотя технически один сервис. Портал должен быть доступен сотрудникам отовсюду — в этом весь смысл, человек создаёт заявку из дома, из командировки, с телефона. А вот доступ к административной части и к формам логина с полными правами мы ограничиваем по IP или заводим за VPN. Реализуется это на уровне веб-сервера или файрвола: привилегированные URL и подсети админов — из белого списка, остальным туда путь закрыт. Атакующий из интернета видит портал, но не видит двери в администрирование.

fail2ban и лимиты PHP

Форма логина GLPI — магнит для перебора паролей. Мы ставим fail2ban с фильтром на логи неудачных входов: несколько провалов подряд с одного адреса — и он летит в бан на заданное время. Это отсекает автоматизированный брутфорс. Параллельно закручиваем PHP: разумные лимиты на размер загрузки и время выполнения, отключение опасных функций, актуальная версия интерпретатора. Каждая закрытая мелочь — минус один вектор.

Права и профили

Здесь две отдельные боли. Первая — сервисная учётка для связки с Active Directory должна быть только для чтения. GLPI нужно лишь читать пользователей и группы из каталога; давать ему учётку с правами записи в AD — значит на ровном месте раздувать последствия компрометации. Read-only и точка.

Вторая боль — профили доступа внутри самого GLPI. Классическая дыра: рядовой пользователь портала по недосмотру видит чужие заявки. Настройка профилей должна гарантировать, что автор заявки видит свои обращения и, максимум, обращения своей группы, но не чужие. Мы регулярно ревизуем профили и права: кто что видит, у кого какие полномочия, не осталось ли забытых админских учёток от уволившихся. Права имеют свойство накапливаться и разъезжаться — их надо периодически подстригать.

Чистка files/ от сирот

Со временем в каталоге files/ накапливаются осиротевшие документы — вложения от удалённых заявок, временные файлы, следы отвалившихся плагинов. Это и лишний объём в бэкапах, и потенциальная свалка, куда через дыру в плагине можно залить что-нибудь исполняемое. Периодическая ревизия и чистка files/ держит файловое хранилище в порядке и уменьшает поверхность атаки.

Мониторинг здоровья GLPI

Сопровождать систему вслепую нельзя. Между «всё хорошо» и «у клиента вторые сутки не создаются уведомления, а мы не в курсе» стоит мониторинг. У GLPI есть несколько встроенных индикаторов здоровья, которые грех не завести в систему наблюдения. Расскажу, за чем следим мы.

Cron-задачи GLPI как индикатор. Внутренний планировщик GLPI (GLPI Cron) гоняет автоматические задачи: рассылку уведомлений, закрытие просроченных, обслуживание. Если планировщик встал, снаружи это часто незаметно — портал работает, заявки создаются, но что-то тихо ломается. Самый показательный симптом — распухшая очередь queuednotification: письма-уведомления копятся и не уходят, потому что задача рассылки не отрабатывает. Пользователи не понимают, почему им не приходят оповещения о заявках. Мы мониторим факт свежего запуска ключевых cron-задач и длину очереди уведомлений — рост очереди сверх порога поднимает алерт.

Статус агентов инвентаризации. Встроенная инвентаризация опирается на GLPI Agent, установленные на рабочих станциях. Если агент перестал отчитываться, данные по этой машине тихо устаревают. Мы отслеживаем агентов, которые не выходили на связь дольше 14 дней: обычно это признак того, что машину вывели из эксплуатации, либо агент отвалился и его надо чинить. И то и другое — повод разобраться, а не молча копить устаревшие записи.

Свободное место на диске. Банально, но именно нехватка места чаще всего роняет базу и ломает бэкапы. Растут вложения в files/, пухнет таблица логов, накапливаются дампы. Порог по свободному месту — обязательный алерт: предупреждение заранее, а не постфактум, когда MariaDB уже отказалась писать.

Внешняя HTTP-проба портала. Все внутренние метрики бесполезны, если сам портал недоступен снаружи. Поэтому из внешней точки мониторинга мы дёргаем страницу входа GLPI и проверяем код ответа и время отклика. Проба видит ровно то, что видит пользователь: если портал лёг, отвалился TLS-сертификат или сервис завис, мы узнаём об этом за минуты, а не из звонка клиента.

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

Вебхуки GLPI 11 на практике

Это моя любимая часть регламента, потому что здесь новая версия реально изменила нашу жизнь. Раньше, чтобы вытащить событие из GLPI во внешний мир — например, чтобы дежурный инженер мгновенно узнал о критичной заявке, — приходилось городить костыли: ставить плагины сомнительной свежести, парсить исходящую почту GLPI или дёргать базу по расписанию. Всё это хрупко, тормозит и ломается на очередном обновлении.

Одиннадцатая ветка принесла нативные вебхуки: GLPI теперь умеет сам отправлять HTTP-запрос на заданный адрес при наступлении события. Это открывает прямую и надёжную интеграцию с чат-ботами, мессенджерами и любыми тикет-системами — без плагинов и парсинга. Событие происходит внутри GLPI, и он тут же стучится к вам по HTTP с полезной нагрузкой. Просто, быстро, поддерживается ядром.

Наш кейс: критичная заявка → Telegram за секунды

Задача была простая и вечная: когда прилетает заявка с высоким приоритетом, дежурный должен узнать об этом немедленно, а не когда в следующий раз откроет почту или зайдёт в GLPI. Решение на нативных вебхуках получилось изящным. В GLPI настраивается вебхук на событие создания заявки с высоким приоритетом. При срабатывании GLPI шлёт HTTP-запрос на наш маленький микросервис — буквально около пятидесяти строк кода. Микросервис принимает полезную нагрузку, проверяет подпись, вытаскивает из неё номер заявки, тему и заявителя, форматирует человекочитаемое сообщение и отправляет его в Telegram-чат дежурных через Bot API. От создания заявки до всплывающего уведомления на телефоне инженера проходят секунды.

# псевдокод микросервиса-приёмника (~50 строк)
@app.post("/glpi-hook")
def hook(req):
    verify_signature(req.headers["X-Signature"], req.body)  # HMAC
    d = req.json()
    text = f"🔴 Заявка #{d['id']}: {d['name']}\n"
    text += f"Приоритет: высокий\nЗаявитель: {d['requester']}"
    telegram_send(CHAT_DUTY, text)
    return 200

Разбор конфигурации

Настройка вебхука в GLPI сводится к трём вещам, и понимание их снимает всю магию:

• Событие (триггер) — на что реагируем: создание заявки, смена статуса, назначение исполнителя, закрытие. Плюс фильтр-условие: не на любую заявку, а только на ту, что подходит под критерий (в нашем случае — высокий приоритет).
• Шаблон полезной нагрузки — какой JSON улетит на ваш адрес. Здесь вы сами собираете тело из полей заявки: id, заголовок, приоритет, заявитель, категория. Отдаёте ровно то, что нужно приёмнику, ничего лишнего.
• Подпись — GLPI подписывает запрос секретом (HMAC в заголовке), а приёмник эту подпись проверяет. Без неё ваш эндпоинт открыт всему интернету: кто угодно, узнав URL, сможет слать вам фальшивые уведомления. Подпись — обязательна, не пропускайте её.

Отдельно отмечу надёжность. Приёмник обязан быстро отвечать и не падать: если ваш эндпоинт отвалился, вы просто пропускаете уведомление, а заявка при этом спокойно живёт в GLPI. То есть вебхук — это приятное дополнение, а не единственный канал; сама заявка никуда не денется. Поэтому микросервис можно держать простым — сложную логику и гарантии доставки навешивают только там, где событие действительно критично терять нельзя.

Производительность на росте

Свежая инсталляция GLPI на скромной виртуалке с 4 ГБ памяти летает — пока в ней сотня активов и десяток заявок в день. Проблемы начинаются позже и подкрадываются незаметно. Расскажу, где именно GLPI упирается в потолок и что мы с этим делаем.

Первый триггер роста — сетевое обнаружение по SNMP. Стоит включить автоматический обход сети и опрос коммутаторов, принтеров, точек доступа — и объём данных подскакивает: появляются порты, VLAN, связи, история изменений по каждому устройству. Второй триггер — само время. За год-два-три копится история: каждое изменение заявки, каждый лог, каждая транзакция инвентаризации оседает в базе. Таблица glpi_logs имеет свойство раздуваться до неприличия и в какой-то момент начинает превышать по объёму все содержательные данные вместе взятые.

Симптомы упёршейся в потолок инсталляции знакомые: списки грузятся секундами, поиск задумывается, дашборды подтормаживают, ночной дамп идёт всё дольше. Когда 4 ГБ перестаёт хватать, мы делаем три вещи.

• Тюнинг innodb_buffer_pool_size. Это главный рычаг производительности MariaDB. Буферный пул — это оперативная память, в которой СУБД держит горячие данные и индексы. По умолчанию он крошечный. Мы поднимаем его так, чтобы рабочий набор GLPI помещался в память: на сервере, отданном под базу, это обычно 50–70% всей RAM. После этого запросы, которые раньше лезли на диск, начинают отдаваться из памяти — и списки, которые грузились три секунды, открываются мгновенно.
• Opcache для PHP. Включённый и правильно настроенный кеш опкодов избавляет PHP от перекомпиляции скриптов на каждый запрос. Для тяжёлого приложения вроде GLPI это ощутимая прибавка к отзывчивости веб-морды почти бесплатно.
• Чистка glpi_logs. В настройках GLPI есть управление временем жизни записей журнала. Мы задаём разумный срок хранения истории (не бесконечность) и позволяем системе подрезать старые логи. База худеет, дампы ускоряются, а информация за актуальный период остаётся на месте.

Главная мысль: производительность GLPI на росте — это управляемая история, а не приговор. Не нужно мигрировать на монструозный сервер при первых тормозах. Нужно понять, где узкое место (почти всегда это память под буферный пул СУБД и разбухшие логи), и точечно его расшить. Мы закладываем эту ревизию в регламент: раз в год смотрим на объём базы, динамику роста и запас по памяти, чтобы расширяться заранее, а не в авральном режиме под жалобы пользователей.

Чек-лист ежемесячного обслуживания

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

Сколько это времени? На отлаженной инсталляции ежемесячный проход занимает у инженера порядка часа: большая часть проверок либо уже автоматизирована мониторингом и лишь подтверждается глазами, либо делается быстро по накатанной. Раз в квартал добавляется тест восстановления — ещё час-полтора. Обновления идут отдельными короткими окнами по мере выхода релизов. Итого сопровождение одной клиентской системы — это несколько часов внимания в месяц, но именно эти несколько часов отделяют живой, безопасный и предсказуемый сервис от бомбы замедленного действия.

И здесь я подхожу к главному выводу всего цикла статей. GLPI — прекрасная бесплатная система, но «бесплатная» относится к лицензии на софт, а не к его эксплуатации. Реальная стоимость владения — это дисциплина сопровождения: вовремя обновить, проверить бэкап, закрутить гайки безопасности, поймать проблему раньше пользователя. Можно вести этот регламент самостоятельно — я специально расписал его так, чтобы им можно было пользоваться как инструкцией. А можно передать его тем, для кого это ежедневная рутина на десятках инсталляций.