NexTool Solutions

Мы дважды обновили копию GLPI 11.0.11 до 12.0.0: в Docker с официальным образом и на Debian 13 с пакетом .tgz. Миграция базы данных в обоих случаях заняла около 5 секунд. Сложности возникли до и после: MariaDB 10.6 была отвергнута, плагины оказались приостановлены, категории базы знаний превратились в статьи, которые не могут открыть ни специалисты, ни пользователи, а веб-хук перестал отправлять запросы, причём по двум разным причинам. В этом руководстве — пошаговая инструкция для обоих вариантов и исправление каждой проблемы в том порядке, в каком они появлялись.

Ещё решаете, пора ли обновляться? Сначала прочитайте Вышел GLPI 12: что меняется, требования и когда обновляться.

Что мы тестировали

Мы развернули одноразовый GLPI 11.0.11 с вымышленными данными компании Acme: 120 заявок с комментариями и 40 задач, один SLA, 9 статей базы знаний в 4 категориях с разными правами, веб-хук на внутренний сервер и три плагина сообщества (Fields, Tag и Data Injection) с данными. Мы сделали резервную копию и обновились до 12.0.0. Затем восстановили ту же резервную копию на Debian 13 и повторили обновление через пакет .tgz.

Перед началом: требования

Две детали, которые показал тест:

• PHP 8.2 выдаёт не предупреждение, а синтаксическую ошибку. Консоль GLPI 12 даже не доходит до проверки требований: она останавливается с "Parse error" в файле самого GLPI. Debian 12 и Ubuntu 22.04 поставляются с PHP 8.2 или более старым. Debian 13 (PHP 8.4) и Ubuntu 24.04 (PHP 8.3) подходят со стандартными пакетами. Официальный образ Docker уже содержит PHP 8.5.
• Прежде всего проверьте базу данных. Запустите php bin/console system:check_requirements с новым кодом, указывающим на вашу базу. На нашей MariaDB 10.6 ответ был однозначным: версия не поддерживается, минимум 10.11.

Шаг 0: резервная копия (база данных, файлы и ключ)

Прежде чем что-либо трогать, сделайте три копии: базы данных, папки файлов и папки конфигурации. В папке конфигурации лежит glpicrypt.key. Без него пароли, сохранённые GLPI (сборщик почты, LDAP, прокси, секреты веб-хуков), больше не расшифровываются.

mariadb-dump --single-transaction --routines -u root -p glpi | gzip > glpi11-$(date +%F).sql.gz
tar czf glpi11-arquivos-$(date +%F).tgz /etc/glpi /var/lib/glpi/files /var/www/glpi/marketplace

В Docker с официальным образом всё хранится в томе, смонтированном в /var/glpi (config, files, marketplace и logs): скопируйте том целиком. В нашем тесте дамп занял 5 секунд, а копирование тома — 8,5.

Вариант 1: Docker с официальным образом

Официальный образ (glpi/glpi) обновляет базу данных самостоятельно, когда запускается с новой версией. Достаточно сменить тег и запустить контейнер: подтверждения не запрашивается. Поэтому резервная копия делается до смены тега, а не после. Если вы предпочитаете запускать обновление вручную, запустите контейнер с GLPI_SKIP_AUTOUPDATE=true и используйте команду из варианта 2.

1. При необходимости обновите MariaDB. С MariaDB 10.6 контейнер GLPI 12 завершился с кодом 128. В журнале появилось предупреждение о неудовлетворённых требованиях, а сразу за ним — пугающая фраза: "GLPI is not installed... Starting installation". На самом деле он ничего не установил. База данных осталась нетронутой, в версии 11.0.11, со всеми 120 заявками. Он просто не прошёл проверку требований. Переход с MariaDB 10.6 на 10.11 занял 22 секунды благодаря переменной автоматического обновления в образе MariaDB. Сначала запустите только базу данных (docker compose up -d db) и проверьте журнал, прежде чем продолжать:

services:
  db:
    image: mariadb:10.11          # era 10.6
    environment:
      MARIADB_AUTO_UPGRADE: "1"   # roda o mariadb-upgrade ao subir
  glpi:
    image: glpi/glpi:12.0.0       # era 11.0.11 (passo 2)
    volumes:
      - glpi-data:/var/glpi

2. Смените тег и запустите. docker compose up -d. В журнале появится "GLPI is installed, and auto-update is enabled. Starting update...", а затем приветственное сообщение. В тесте от up до приветственного сообщения в журнале прошло 17 секунд.

3. Проверьте. docker compose exec glpi bin/console db:check должна ответить "Database schema is OK".

Вариант 2: Linux с пакетом .tgz

Команды ниже соответствуют структуре из нашего руководства по установке GLPI 11 на Debian и Ubuntu: код в /var/www/glpi, конфигурация в /etc/glpi, файлы в /var/lib/glpi/files.

cd /var/www/glpi && sudo -u www-data php bin/console maintenance:enable
cd /var/www && mv glpi glpi-11-antigo
wget https://github.com/glpi-project/glpi/releases/download/12.0.0/glpi-12.0.0.tgz
tar xzf glpi-12.0.0.tgz
cp glpi-11-antigo/inc/downstream.php glpi/inc/                  # se existir
cp glpi-11-antigo/config/local_define.php glpi/config/ 2>/dev/null  # se existir
cp -a glpi-11-antigo/marketplace/. glpi/marketplace/
chown -R www-data:www-data glpi
cd glpi
sudo -u www-data php bin/console system:check_requirements
sudo -u www-data php bin/console database:update
sudo -u www-data php bin/console maintenance:disable

Файл, о котором никто не помнит: inc/downstream.php. Именно он сообщает GLPI, что конфигурация находится в /etc/glpi. Он лежит внутри папки с кодом, поэтому пропадает, когда вы заменяете папку. В тесте без него database:update ответила "Unable to connect to database". Сообщение не называет настоящую причину: GLPI искал конфигурацию не там. Когда файл скопировали обратно, обновление сразу прошло. То же относится к config/local_define.php, если вы его используете.

Если ваш GLPI хранит config и files внутри /var/www/glpi, скопируйте из старой папки также config/ и files/. Так было на Debian 13 (PHP 8.4): миграция заняла 5 секунд, а db:check прошла чисто.

Если обновление базы данных не удалось

3 ноября на форуме GLPI описали обновление с 11.0.8 до 12.0.1 на Debian 13, которое застряло: файлы скопировали, владельца и права настроили, затем maintenance:disable выдала ошибку, и обновление базы данных не прошло. Мы этот случай не воспроизводили. В одном из ответов в теме указали вероятную причину, и код миграции подтверждает, что она возможна: в 11 таблица, которая связывает статьи с категориями базы знаний, допускает повтор одной и той же пары статья/категория, а таблица, которая заменяет её в 12, — нет. Одной дублирующейся связи достаточно, чтобы остановить миграцию. Восстановите резервную копию 11 (миграция могла остановиться на полпути) и найдите дубликаты:

SELECT knowbaseitems_id, knowbaseitemcategories_id, COUNT(*) AS n
FROM glpi_knowbaseitems_knowbaseitemcategories
GROUP BY knowbaseitems_id, knowbaseitemcategories_id
HAVING n > 1;

Если запрос вернул строки, удалите копии и оставьте одну связь на каждую пару. Статья останется в своей категории:

DELETE l1 FROM glpi_knowbaseitems_knowbaseitemcategories l1
JOIN glpi_knowbaseitems_knowbaseitemcategories l2
  ON l1.knowbaseitems_id = l2.knowbaseitems_id
 AND l1.knowbaseitemcategories_id = l2.knowbaseitemcategories_id
 AND l1.id > l2.id;

Если запрос вернул пустой результат, причина в другом. Проверьте, что папка файлов и папка конфигурации (в нашей схеме — /var/lib/glpi/files и /etc/glpi) принадлежат www-data, выполните system:check_requirements и прочитайте php-errors.log в папке _log каталога файлов, а также журнал ошибок веб-сервера. Запустите database:update из командной строки — так ошибка будет выведена на экран, — и только после этого maintenance:disable.

После миграции: что сломалось и как это исправить

1. Плагины приостанавливаются (а команда вывода списка об этом не сообщает)

После обновления GLPI 12 приостанавливает выполнение всех плагинов. plugin:list по-прежнему показывала все три как "Enabled". Но параметр plugins_execution_mode имел значение "suspended_by_update", и ни один плагин не работал. Чтобы снять приостановку:

php bin/console plugin:resume_execution

При снятии приостановки GLPI проверил версии и отключил все три ("Installed / not activated"). Версии для 11 допускают максимум GLPI 11.0.99, а версии для 12 требуют минимум 12.0.0. Иными словами: обновить эти плагины раньше GLPI нельзя. Сначала GLPI, потом плагины:

Для каждого: замените папку в marketplace/ новой версией и выполните plugin:install и plugin:activate. Данные сохранились: 5 значений поля «Центр затрат» из Fields и 10 меток Tag остались на месте. Прежде чем назначать дату, проверьте, что для всех ваших плагинов уже есть версия под 12 (как выбирать плагины, не блокируя обновление).

2. Категории базы знаний превращаются в статьи без видимости

В GLPI 12 в базе знаний больше нет категорий: 4 категории превратились в 4 «родительские» статьи, а над ними была создана корневая статья ("Home"). 9 статей сохранили свои права. Но 4 статьи, бывшие категориями, остались без единого правила видимости. Мы проверили через API под специалистом и под пользователем Self-Service: оба получили ошибку 403 при открытии «Процедуры», «Сеть», «Wi-Fi» и «FAQ пользователя». Каждый по-прежнему открывал только те статьи, которые видел раньше.

Исправление: откройте каждую бывшую категорию и назначьте ей ту аудиторию, которая была у папки (организация, профиль или группа). В 12 статья наследует видимость вышестоящих статей. В тесте открытие доступа к бывшей категории «FAQ пользователя» для организации Acme позволило специалисту открыть папку и две статьи внутри неё, которые раньше давали 403. Для пользователя Self-Service нужен ещё один шаг: он видит только статьи с отметкой FAQ, а бывшие категории приходят без неё. С видимостью и отметкой FAQ папка появилась и у него. Сделайте это до того, как откроете систему для пользователей.

3. Веб-хук остановился: метод "post" в нижнем регистре

Веб-хук, созданный в GLPI 11, попал в очередь и завершился ошибкой. Журнал webhook.log показал причину: Invalid HTTP method "post", only uppercase letters are accepted. GLPI сохраняет метод в нижнем регистре, а HTTP-клиент в 12 принимает только верхний. Это затрагивает все веб-хуки, включая созданные в 12. Проблема зарегистрирована на GitHub GLPI (issue 25883), исправление предложено. Когда мы тестировали, 16 октября, исправления ещё не было ни в 12.0.0, ни в версии разработки 12.0.1.

Пока исправление не выйдет, обходной путь — перевести метод в верхний регистр прямо в базе данных (сделав резервную копию):

UPDATE glpi_webhooks SET http_method = UPPER(http_method);
UPDATE glpi_queuedwebhooks SET http_method = UPPER(http_method);

Если кто-то снова сохранит веб-хук через интерфейс, поле вернётся в нижний регистр. В этом случае повторите команду и следите за примечаниями к версиям 12.0.x: когда исправление войдёт в релиз, обходной путь больше не понадобится.

4. Затем — блокировка внутренней сети

После исправления метода ошибка сменилась: Host "glpiup-hook" is blocked. GLPI 12 по умолчанию блокирует запросы сервера к частным сетям (10.x, 172.16-31.x, 192.168.x). Это касается веб-хуков, внешних календарей, RSS-лент и подключения к GLPI Network. По умолчанию разрешены только запросы к агенту инвентаризации и к внешней аутентификации. Если ваш веб-хук указывает на n8n, ERP или API во внутренней сети, он перестанет работать.

Чтобы разрешить только необходимое, создайте файл config/local_define.php в папке с кодом GLPI:

<?php
define('GLPI_SERVERSIDE_URL_ALLOWED_PRIVATE_NETWORKS_CONTEXTS', [
    \Agent::class,    // padrão
    \Auth::class,     // padrão
    \Webhook::class,  // libera webhooks para a rede interna
]);

Подвох Docker: GLPI читает этот файл из /var/www/glpi/config/, который находится внутри образа, а не из тома /var/glpi/config. Помещённый в том, файл не подействовал. Смонтированный как отдельный файл — сработал:

    volumes:
      - glpi-data:/var/glpi
      - ./local_define.php:/var/www/glpi/config/local_define.php:ro

После этого оба веб-хука из очереди были доставлены со статусом 200. Чтобы настроить веб-хук с нуля, см. встроенные веб-хуки GLPI 11.

5. Предупреждение о документах

Миграция оставила в журнале warning_during_migration_to_12.0.0.log единственное предупреждение: "Rights have been given for document, you should review ACLs after update". GLPI выдал новые права на документы. Проверьте их в Администрирование > Профили, вкладка Управление > Документы, особенно в профилях конечных пользователей.

Чек-лист обновления

А что с модулями NexTool?

Плагин NexTool и 37 модулей работают в GLPI 11 и 12 в одной и той же версии. Поэтому, в отличие от плагинов выше, их можно обновить заранее, ещё на 11, в NexTool > Модули > Обновить все. После миграции они приостанавливаются, как и остальные плагины: выполните plugin:resume_execution и проверьте список в NexTool > Модули. Таблица по каждому модулю — в статье NexTool в GLPI 12: совместимость. Если вам нужна помощь в планировании или выполнении обновления, свяжитесь с нами.

Тест NexTool от 16 октября 2026 г. на одноразовой копии с вымышленными данными: официальный образ glpi/glpi с 11.0.11 до 12.0.0 (PHP 8.5), MariaDB с 10.6 до 10.11 и пакет .tgz на Debian 13 (PHP 8.4). По окончании среда была удалена. GLPI — зарегистрированная торговая марка Teclib'. NexTool не аффилирована с Teclib'.