NexTool Solutions

Установка GLPI 11 на Linux проходит спокойно ровно до той строки, где вы выносите config/ и files/ из webroot, и установщик «перестаёт видеть» базу данных. Это пошаговая инструкция, которую мы используем при развёртывании GLPI для клиентов: реальные команды, два php.ini, которые действительно важны, файл, предотвращающий самую частую ошибку ручной установки, и чек-лист после установки, который приводит среду в законченный вид.

Прежде чем начать: рассчитайте сервер

GLPI 11 работает на классическом стеке LAMP: Apache (или Nginx) + PHP 8.1 или выше + MariaDB 10.5+ (или MySQL 8). В Debian 12 PHP по умолчанию — 8.2; в Ubuntu 24.04 LTS — 8.3, оба подходят. Реальная разница между пилотом и средой на сотни специалистов — это RAM и модель исполнения PHP (mod_php или PHP-FPM). Вот матрица, которую мы используем для расчёта:

1. Система, веб-сервер, PHP и расширения

Обновите систему и установите всё сразу. Расширения не являются опциональными: GLPI проверяет каждое из них на экране требований.

apt update && apt upgrade -y
apt install -y apache2 mariadb-server \
  php php-{mysql,curl,gd,intl,xml,mbstring,zip,bz2,ldap,apcu,bcmath} \
  libapache2-mod-php certbot python3-certbot-apache

Debian 13 (Trixie) и GLPI 11.0.11: мы протестировали в октябре 2026 г. с PHP 8.4 и MariaDB 11.8 — установка проходит до конца с двумя корректировками, уже включёнными в команду выше. Пакета php-imap в Debian 13 нет (PHP 8.4 убрал это расширение из ядра, а GLPI 11 оно не нужно). А расширение bcmath обязательно в GLPI 11: без php-bcmath команда db:install останавливается с ошибкой «bcmath extension is missing». Та же команда подходит для Debian 12 и Ubuntu 24.04.

Типичная ошибка здесь — забыть php-intl: установка пакетов проходит, но GLPI останавливается на проверке требований, а форматирование дат и интернационализация ломаются. php-ldap и php-imap нужны только если вы будете интегрировать Active Directory и сборщик почты, но установка сразу избавит от переустановки позже.

2. Два php.ini, которые имеют значение

Это момент, который отличает установку, которая «работает», от той, что работает и по ночам. PHP хранит отдельные настройки для каждого SAPI: Apache читает /etc/php/8.2/apache2/php.ini, но cron GLPI запускается из командной строки и читает /etc/php/8.2/cli/php.ini. Настройте оба с одинаковыми значениями:

memory_limit = 256M
upload_max_filesize = 20M
post_max_size = 20M
max_execution_time = 300
max_input_vars = 5000
session.cookie_httponly = On
date.timezone = America/Sao_Paulo
; lembre-se: este mesmo arquivo existe em .../cli/php.ini

В ходе сопровождения причина номер один для «автоматические действия перестали работать» почти никогда не системный cron: это memory_limit 128M в php.ini для CLI, который обрывает синхронизацию инвентаризации или массовую отправку уведомлений, тогда как у Apache уже стояло 256M, и никто ничего не подозревал. Отредактируйте оба файла.

3. MariaDB, база данных и часовой пояс

Выполните mysql_secure_installation и создайте базу данных с utf8mb4 (от этого зависят диакритические знаки и эмодзи):

mysql -u root -p

CREATE DATABASE glpi CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'glpi'@'localhost' IDENTIFIED BY 'SuaSenhaForte';
GRANT ALL PRIVILEGES ON glpi.* TO 'glpi'@'localhost';
FLUSH PRIVILEGES;

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

# Load the time zone tables; without this the timezone selector stays empty
mariadb-tzinfo-to-sql /usr/share/zoneinfo | mysql -u root mysql
mysql -u root -e "GRANT SELECT ON mysql.time_zone_name TO 'glpi'@'localhost'; FLUSH PRIVILEGES;"

4. Вынесите config, files и logs из webroot — и сообщите GLPI, куда они переехали

Скачайте GLPI 11 и распакуйте:

cd /tmp
wget https://github.com/glpi-project/glpi/releases/download/11.0.11/glpi-11.0.11.tgz
tar -xzf glpi-11.0.11.tgz -C /var/www/
chown -R www-data:www-data /var/www/glpi

В целях безопасности чувствительные данные не должны находиться внутри webroot. Перенесите их:

mkdir -p /etc/glpi /var/lib/glpi/files /var/log/glpi
mv /var/www/glpi/config/* /etc/glpi/
mv /var/www/glpi/files/*  /var/lib/glpi/files/
chown -R www-data:www-data /etc/glpi /var/lib/glpi /var/log/glpi

Вот самая частая ошибка ручной установки: перенести каталоги и не сообщить GLPI, куда они переехали. В результате установщик заново создаёт config/ и files/ внутри webroot, вы закрываете права не там, где нужно, и остаётесь уязвимы. Правильный способ — создать inc/downstream.php: он читается и Apache, и CLI, поэтому решает вопрос и для веба, и для cron сразу:

<?php // /var/www/glpi/inc/downstream.php
define('GLPI_CONFIG_DIR', '/etc/glpi');
define('GLPI_VAR_DIR',    '/var/lib/glpi/files');
define('GLPI_LOG_DIR',    '/var/log/glpi');

5. Virtual host, HTTPS и DocumentRoot в public/

DocumentRoot указывает на /var/www/glpi/public, а не на корень установки: это обязательно начиная с GLPI 10 и именно это не позволяет отдавать config и files через веб.

<VirtualHost *:80>
    ServerName glpi.cliente.com.br
    DocumentRoot /var/www/glpi/public   # never /var/www/glpi

    <Directory /var/www/glpi/public>
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

a2ensite glpi.conf && a2enmod rewrite
a2dissite 000-default.conf
systemctl reload apache2
certbot --apache -d glpi.cliente.com.br

6. Установите через командную строку и настройте cron

Когда downstream.php на месте, db:install сразу записывает config_db.php в /etc/glpi — экспортировать никакие переменные не нужно:

php /var/www/glpi/bin/console db:install \
  --db-host=localhost --db-name=glpi \
  --db-user=glpi --db-password='SuaSenhaForte' \
  --default-language=pt_BR --no-interaction

GLPI обрабатывает уведомления, инвентаризацию и автоматические действия с помощью внешнего cron. Запланируйте его на каждую минуту — GLPI сам решает, что запускать при каждом срабатывании, в зависимости от периодичности каждой задачи:

echo "* * * * * www-data /usr/bin/php /var/www/glpi/front/cron.php &>/dev/null" > /etc/cron.d/glpi

Затем в Настройки > Автоматические действия переключите режим выполнения на CLI. Если оставить внутренний режим (запуск при обращении пользователя), задачи пропадают ночью и в выходные — именно тогда, когда вы хотите, чтобы работали инвентаризация и резервное копирование.

7. После установки: чек-лист, который завершает настройку среды

1. Удалите установщик: rm /var/www/glpi/install/install.php. Внимание: каждое обновление заново создаёт этот файл — удаляйте его снова после каждого обновления.
2. Смените пароли четырёх стандартных пользователей: glpi, tech, normal и post-only.
3. Настройте SMTP в Настройки > Уведомления и отправьте тестовое письмо.
4. Убедитесь, что установщик недоступен и что cron отработал:

# Is the installer still reachable? (expected: 404)
curl -s -o /dev/null -w "%{http_code}\n" https://glpi.cliente.com.br/install/install.php

-- Is the external cron running? (lastrun should be recent)
SELECT name, state, lastrun FROM glpi_crontasks ORDER BY lastrun DESC LIMIT 5;

Что мы проверяем, принимая GLPI от другой команды

Когда мы берём на сопровождение среду, установленную другой командой, диагностика всегда сводится к одной и той же тройке: есть ли inc/downstream.php или сосуществуют два каталога config (один рабочий и один «призрак», который кто-то редактирует без результата)? Совпадает ли memory_limit для CLI с тем, что у Apache? И работает ли режим автоматических действий через CLI или привязан к обращениям пользователей? Эти три пункта объясняют большинство обращений «GLPI тормозит» и «уведомления не приходят», которые мы получаем, — и ни один из них не проявляется в установке, проверенной только кликами по интерфейсу в рабочее время.

Нужен GLPI 11, развёрнутый и сопровождаемый с такой же строгостью, без унаследованного долга установки? Узнайте о сопровождении сред GLPI от NexTool.

Проверено командой NexTool Solutions.