osTicket на сервере: частые ошибки и решения

MAATRIX

osTicket — одна из немногих open-source тикет-систем, которую реально держат в проде годами: PHP + MySQL, никакой магии, всё чинится руками. Но именно поэтому при переезде на свой сервер вылезает целый набор классических граблей — от белого экрана после установки до тикетов, которые не создаются из входящей почты. Разбираем самые частые поломки и как их закрыть без танцев с бубном.

Белый экран или 500 ошибка после установки

Первое, с чем сталкиваются почти все: после распаковки архива и запуска установщика вместо формы — белая страница или общий Internal Server Error без деталей. osTicket по умолчанию прячет ошибки PHP от пользователя, и это правильно для продакшена, но мешает диагностике.

Первым делом включите вывод ошибок временно, через php.ini или прямо в .htaccess, если используете Apache:

php_flag display_errors on
php_value error_reporting E_ALL

Если сервер на Nginx + PHP-FPM, ошибки смотрите в логах напрямую:

tail -f /var/log/php8.2-fpm.log
tail -f /var/log/nginx/error.log

В 90% случаев причина — отсутствующее PHP-расширение. osTicket требует конкретный набор:

apt install php8.2-fpm php8.2-mysql php8.2-mbstring php8.2-gd \
  php8.2-imap php8.2-intl php8.2-xml php8.2-curl php8.2-zip
systemctl restart php8.2-fpm

Особое внимание на php-imap — без него не соберётся модуль работы с почтовыми ящиками, а установщик может просто упасть на середине без внятного сообщения. Если у вас Nginx, а не связка Apache + mod_php, убедитесь, что конфиг правильно проксирует .php в FPM-сокет — иначе браузер вместо выполнения кода начнёт скачивать .php-файлы как есть.

Установщик не видит config.php или зависает на шаге проверки

Установщик osTicket на определённом шаге просит создать пустой include/ost-config.php и выставить на него права записи — многие про это забывают или делают наоборот, забывают снять права после установки.

touch /var/www/osticket/include/ost-config.php
chmod 666 /var/www/osticket/include/ost-config.php
chown www-data:www-data /var/www/osticket/include/ost-config.php

После успешной установки права обязательно откатите обратно — файл с учётными данными БД с правами 666 в проде это дыра, а не мелочь:

chmod 644 /var/www/osticket/include/ost-config.php

Если установщик зависает именно на шаге подключения к базе — почти всегда дело в неверном хосте MySQL. На большинстве VPS с локальной БД нужно указывать localhost, а не 127.0.0.1 (или наоборот) — это зависит от того, слушает ли MySQL Unix-сокет или TCP. Проверить можно так:

mysql -h localhost -u osticket_user -p osticket_db -e "SELECT 1;"
mysql -h 127.0.0.1 -u osticket_user -p osticket_db -e "SELECT 1;"

Какой вариант отработал — тот и используйте в форме установки. Если у вас база на отдельном сервере или в контейнере, читайте общий разбор ошибок MySQL на сервере — часть проблем с подключением там уже разобрана.

Ошибка "Access denied" или проблемы с правами MySQL-пользователя

osTicket создаёт довольно много таблиц и активно пишет в базу, поэтому пользователю БД нужны полные права именно на свою базу — не на *.*, это лишнее, но и не урезанные до SELECT.

CREATE DATABASE osticket_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'osticket_user'@'localhost' IDENTIFIED BY 'СложныйПароль123!';
GRANT ALL PRIVILEGES ON osticket_db.* TO 'osticket_user'@'localhost';
FLUSH PRIVILEGES;

Важный нюанс — кодировка. Если база создана в latin1 или utf8 (без mb4), при попытке сохранить тикет с эмодзи или кириллицей в некоторых полях можно словить Incorrect string value. Проверить кодировку существующей базы:

mysql -u root -p -e "SELECT default_character_set_name FROM information_schema.SCHEMATA WHERE schema_name = 'osticket_db';"

Если там не utf8mb4 — конвертация задним числом возможна, но рискованна на живых данных. Проще пересоздать базу с правильной кодировкой при установке и один раз сделать нормальный бэкап MySQL перед миграцией, чем потом чистить кракозябры в тикетах.

Письма не создают тикеты, хотя почта приходит

Это самая частая жалоба после того, как система уже работает: клиенты пишут на support@ваш-домен, письмо реально приходит на сервер, но в osTicket тикет не появляется. Причин обычно три.

Первая — не настроен или не запускается cron для опроса почтовых ящиков. osTicket не слушает почту в реальном времени через IMAP push, а периодически опрашивает ящик через api/cron.php. Без крона входящие письма просто копятся непрочитанными.

crontab -e -u www-data

Добавьте строку (частота раз в минуту — нормальная практика):

* * * * * php /var/www/osticket/api/cron.php > /dev/null 2>&1

Если крон уже стоит, но не срабатывает — проверьте общие причины в статье про ошибки cron-задач на сервере: часто дело в неверном пользователе или в PATH, который в cron-окружении отличается от интерактивной сессии.

Вторая причина — расширение php-imap не установлено или не включено в php.ini для CLI-версии PHP (крон запускается не через FPM, а через CLI, и там может быть отдельный конфиг):

php -m | grep -i imap

Если пусто — проверьте /etc/php/8.2/cli/php.ini, а не только fpm/php.ini, и перезапустите сервис.

Третья — неверные настройки самого email-аккаунта в админке osTicket (Admin Panel → Emails → редактируем ящик → Diagnostic). Там же можно нажать «Fetch/Poll Mailbox» вручную и увидеть точную ошибку соединения — обычно это неверный порт IMAP/SSL или бан от почтового провайдера за частые обращения. Если письма не уходят и в обратную сторону (уведомления клиентам), проверьте общую настройку почтового сервера Postfix — часто это не проблема osTicket, а то, что сам сервер отправки не настроен или письма улетают в спам у получателя.

Не работают вложения или ошибка "file size limit"

osTicket по умолчанию ограничивает размер загружаемых файлов на уровне своих настроек (Admin → Settings → Attachments), но эта настройка бессильна, если PHP сам режет запрос раньше. Проверьте три параметра в php.ini — они должны быть согласованы между собой:

upload_max_filesize = 25M
post_max_size = 30M
max_execution_time = 60
memory_limit = 256M

Важно: post_max_size должен быть больше upload_max_filesize, иначе форма будет обрезать данные ещё до того, как PHP успеет вернуть внятную ошибку про размер файла — пользователь просто увидит пустую отправку формы.

Второй частый источник проблем с вложениями — если файлы хранятся не в базе, а на диске (Admin → Settings → Attachments → Storage Type = "Web server's file system"), директория attachments/ должна быть доступна для записи процессу PHP:

chown -R www-data:www-data /var/www/osticket/attachments
chmod -R 755 /var/www/osticket/attachments

Если сервер начал возвращать ошибку записи только после переноса на новый VPS — почти наверняка забыли перенести саму директорию с вложениями вместе с базой, а не только дамп MySQL.

Медленная работа при росте базы тикетов

osTicket неплохо держит несколько тысяч тикетов на скромном VPS, но по мере роста базы (обычно после 20-30 тысяч тикетов и активных агентов) начинает тормозить список тикетов и поиск. Тут два практичных шага.

Первое — включить и настроить кэш opcache для PHP, если ещё не включён:

opcache.enable=1
opcache.memory_consumption=128
opcache.max_accelerated_files=10000
opcache.revalidate_freq=60

Второе — регулярно чистить таблицы логов и сессий, которые растут быстрее всего и обычно не индексированы под тяжёлые SELECT:

DELETE FROM ost_syslog WHERE created < DATE_SUB(NOW(), INTERVAL 30 DAY);

Перед такими операциями обязательно снимите свежий бэкап — не полагайтесь на то, что «вроде всё работает», DELETE по логам не откатывается штатными средствами osTicket. Если проект живёт за Nginx, дополнительно проверьте, не упирается ли статика (CSS/JS/иконки агентской панели) в отсутствие кэширования на уровне Nginx — это дешёвый выигрыш по скорости загрузки без вмешательства в саму osTicket.

SSL-сертификат и проблемы с редиректом на HTTPS

osTicket сам не занимается TLS — это зона ответственности веб-сервера, но частая ошибка именно в связке с ним: после выпуска сертификата через Let's Encrypt агентская панель начинает бесконечно редиректить (ERR_TOO_MANY_REDIRECTS) или ругается на "insecure form submission".

Обычно причина в том, что в include/ost-config.php осталась запись со старым протоколом или в базе (таблица ost_config, ключ helpdesk_url) сохранён http:// вместо https:// после переезда на защищённое соединение. Проверить и поправить:

SELECT * FROM ost_config WHERE `key` = 'helpdesk_url';
UPDATE ost_config SET value = 'https://support.ваш-домен.ru' WHERE `key` = 'helpdesk_url';

Если сам сертификат не выпускается или Certbot падает с ошибкой — это уже не про osTicket, а про общие грабли выпуска Let's Encrypt, они разобраны отдельно в статье про частые ошибки Let's Encrypt на сервере. После получения сертификата не забудьте настроить его автопродление через cron или systemd-таймер — просроченный сертификат на тикет-системе поддержки выглядит особенно неловко перед клиентами.

Частые вопросы