NexTool Solutions

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

Модель: событие, очередь и отправка

Уведомление проходит три этапа, и каждый ломается по-своему:

1. Событие — что-то происходит (новая заявка, комментарий, решение), и Уведомление сопоставляет событие с Шаблоном и получателями.
2. Очередь — сообщение записывается в таблицу glpi_queuednotifications, а не отправляется сразу.
3. Отправка — автоматическое действие queuednotification, запускаемое по cron, выгружает очередь через SMTP.

Запомните это разделение: большинство инцидентов, с которыми мы работаем, приходится на этап 3 (очередь растёт, и никто её не выгружает), а не на этап 1 (SMTP). Идеально настроенный SMTP без работающего cron — классический рецепт ситуации «я всё настроил, а ничего не приходит».

Базовая настройка SMTP

В разделе Настройка > Уведомления > Настройка почтовых уведомлений (Setup > Notifications) включите почтовые уведомления и заполните:

• Способ отправки: в большинстве случаев SMTP+TLS — избегайте mail() PHP в продуктиве.
• Сервер и порт: хост релея + 587 (STARTTLS) или 465 (SSL).
• Логин/пароль или OAuth: в зависимости от провайдера.
• Адрес администратора и отправителя: адрес, от имени которого релей имеет право отправлять, — именно эта деталь решает, дойдёт письмо или попадёт в спам.

Пароль хранится в зашифрованном виде (GLPIKey) в столбце smtp_passwd. Никогда не читайте его через SQL: он приходит зашифрованным и для диагностики бесполезен. Чтобы проверить остальную конфигурацию прямо в базе:

-- Sending configuration check (never read smtp_passwd: it is encrypted)
SELECT name, value
FROM glpi_configs
WHERE context = 'core'
  AND name IN ('smtp_mode','smtp_host','smtp_port','smtp_username',
               'smtp_check_certificate','admin_email','from_email',
               'notifications_mailing','use_notifications');

Если notifications_mailing равно 0, почтовые уведомления отключены глобально — никакие настройки SMTP не имеют значения, пока это не включено.

Выбор способа отправки

Вот матрица, по которой мы выбираем способ в зависимости от сценария:

Gmail и Microsoft 365 через OAuth 2.0

Gmail и Microsoft 365 заблокировали базовую аутентификацию (логин + пароль). Поддерживаемый путь — OAuth 2.0 (GLPI 10.0.7+). У провайдера вы регистрируете приложение (Google Cloud Console или Azure App Registrations), получаете Client ID и Client Secret, указываете redirect URI GLPI и выполняете авторизацию. В GLPI выберите способ SMTP+OAuth, укажите провайдера и вставьте учётные данные.

Ловушка, отнимающая больше всего времени в Microsoft 365: даже при правильном OAuth M365 по умолчанию отключает SMTP AUTH для почтового ящика. Пока он не включён, аутентификация проходит, а отправка не удаётся. Включите его для используемого ящика:

# Microsoft 365: enable SMTP AUTH on the mailbox used by OAuth (disabled by default)
Set-CASMailbox -Identity [email protected] -SmtpClientAuthenticationDisabled $false

В Gmail/Workspace область доступа — https://mail.google.com/, а в учётных записях Workspace администратору, возможно, придётся разрешить приложение. Учётные записи с 2FA пока принимают пароль приложения как запасной вариант, но Google постепенно выводит этот способ из употребления.

Очередь и cron: где действительно ломается

Вот деталь, которая проявляется только в эксплуатации. Автоматическое действие queuednotification может работать в двух режимах: GLPI (запуск при обращении к интерфейсу) или CLI (через внешний cron). В экземпляре с низким трафиком — у клиента, который пользуется GLPI только в рабочее время, — режим GLPI приводит к тому, что ночные уведомления уходят только тогда, когда кто-то утром открывает систему. Симптом приходит как «письмо с задержкой» или «не приходит». Решение, которое мы стандартизировали при сопровождении: все автоматические действия — в режиме CLI, а front/cron.php вызывается внешним cron каждую минуту.

# GLPI - drain the notification queue every minute (run as the web server user)
* * * * * www-data /usr/bin/php /var/www/glpi/front/cron.php >/dev/null 2>&1

# In Docker: fire the GLPI cron as the web server user (adjust name/path)
* * * * * root docker exec -u www-data glpi php /var/www/glpi/front/cron.php >/dev/null 2>&1

Чтобы проверить, выгружается ли очередь, посмотрите, что застряло без sent_time:

-- Notifications stuck in the queue (a full queue = cron is not draining it)
SELECT id, itemtype, recipient, create_time, send_time, sent_time, sent_try
FROM glpi_queuednotifications
WHERE sent_time IS NULL
ORDER BY send_time ASC
LIMIT 20;

Большая и растущая куча здесь при исправном SMTP почти всегда означает остановленный cron или режим GLPI. Отслеживать это можно и в интерфейсе: Администрирование > Очередь уведомлений.

Шаблоны и переменные

В разделе Настройка > Уведомления > Шаблоны уведомлений редактируется текст для каждого события. Переменные используют синтаксис ##...##:

<!-- "New ticket" template - HTML body with GLPI variables -->
<p>Hello ##ticket.author##,</p>
<p>Your ticket <strong>##ticket.id##</strong> has been registered:</p>
<ul>
  <li>Title: ##ticket.title##</li>
  <li>Priority: ##ticket.priority##</li>
  <li>Track it at: ##ticket.url##</li>
</ul>

У шаблона могут быть версии для разных языков; если версии на языке получателя нет, GLPI использует версию по умолчанию. Типичная ошибка — отредактировать только текст на португальском и удивляться, что специалист с профилем на английском получает старый шаблон.

Практические ловушки

Симптомы, которые мы видим чаще всего, и где искать причину каждого:

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

Не только почта

Почта асинхронна и конкурирует за внимание с остальным содержимым ящика. Чтобы специалист видел заявку в момент её изменения, почта — не лучший канал. Рассмотрите уведомления в реальном времени с модулем Smart Notify (колокольчик на панели навигации) или отправку в WhatsApp и Telegram для событий, которые не могут ждать следующего почтового цикла.

Если почта GLPI в вашей среде работает с перебоями — то приходит, то нет, — дело обычно в очереди и cron, а не в SMTP. NexTool занимается сопровождением GLPI с мониторингом очереди уведомлений и cron под контролем. Свяжитесь с нами по поводу поддержки и сопровождения GLPI.

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