28 августа 2026 года на форуме HestiaCP появился разбор неприятного обновления: сервер на Ubuntu 22.04.5 перевели с HestiaCP 1.9.9 сразу на 1.10.4, после чего Roundcube перестал работать на всех почтовых доменах. Вместо формы входа пользователи видели общую ошибку, а журналы Apache, Nginx и самого Roundcube не содержали полезных записей.

Первый заметный след нашёлся не в журналах веб-сервера, а в отчёте об обновлении HestiaCP: там была строка об ошибке при обновлении Roundcube до версии 1.7.3. В том же обсуждении другой администратор столкнулся с конфликтом зависимостей Composer, а после восстановления Roundcube обнаружил ещё один слой проблемы — остатки старой установки RainLoop.

Это не доказывает, что HestiaCP 1.10.4 ломает Roundcube на каждом сервере. Кейс показывает другое: обновление панели управления затрагивает не только её интерфейс. Меняются PHP-зависимости, шаблоны веб-сервера, права на файлы, структура каталогов и связанные приложения. На сервере, который несколько лет обновлялся поверх существующей установки, эти изменения могут столкнуться с накопленными модификациями.

Что именно произошло в обсуждаемом случае

В теме смешались два похожих, но разных сценария.

• На первом сервере обновление выполнялось с HestiaCP 1.9.9 до 1.10.4. Roundcube перестал открываться на всех доменах, стандартные журналы оказались пустыми, а отчёт обновления указывал на ошибку установки Roundcube 1.7.3.
• На втором сервере переход выполнялся с HestiaCP 1.9.6 до 1.10.4. Composer не мог согласовать требования новой версии Guzzle с зафиксированной старой версией symfony/deprecation-contracts. После замены устаревшего описания зависимостей и повторного запуска Composer Roundcube заработал.
• Затем на втором сервере проявилась отдельная проблема RainLoop: его каталог данных был связан с устаревшим расположением, которое конфликтовало с более новыми ограничениями PHP-сервиса.

Единой подтверждённой причины для первого сервера в теме не установили. Поэтому команды из форума нельзя воспринимать как универсальный рецепт. На одном узле достаточно восстановить штатные зависимости, на другом проблема будет в шаблоне Nginx, версии PHP CLI, правах, старом webmail или неудачно завершившемся пакетном обновлении.

Почему панель открылась, а обновление всё равно нельзя считать успешным

Работающий интерфейс HestiaCP проверяет только один слой системы. Отдельно нужно подтвердить состояние:

• Roundcube и другого установленного webmail;
• SMTP, IMAP и почтовых очередей;
• Nginx, Apache и используемых версий PHP-FPM;
• сайтов, баз данных и фоновых заданий;
• DNS, SSL, резервного копирования и шаблонов доменов;
• Composer-зависимостей панели и пользовательских приложений.

В ветке HestiaCP 1.10 появилась поддержка Roundcube 1.7 и менялся процесс его установки и обновления. У самого Roundcube 1.7 изменилось ожидаемое расположение публичной части: веб-сервер должен направлять запросы в каталог public_html. Если на сервере сохранился старый или изменённый вручную шаблон webmail, новая версия приложения и прежний document root могут разойтись.

Конфликт Composer работает похожим образом. Обновление приносит новые требования, но на сервере остаются старые composer.json, composer.lock или вручную зафиксированные версии пакетов. В результате панель обновляется, а зависимое приложение остаётся в промежуточном состоянии.

Что проверить до обновления HestiaCP

1. Снять технический инвентарь

До любых изменений нужно записать текущие версии и нестандартные элементы системы. Минимальная безопасная проверка выглядит так:

v-list-sys-info
php -v
systemctl --failed
df -h
df -i
dpkg -l | grep -E 'hestia|roundcube|snappymail|rainloop|php'
find /var/lib/roundcube -maxdepth 1 -name 'composer*' -ls

Дополнительно проверьте:

• какой PHP используется в командной строке и какой обслуживает webmail;
• есть ли RainLoop, SnappyMail или остатки предыдущих webmail-клиентов;
• менялись ли шаблоны Nginx, Apache и почтовых доменов;
• есть ли символические ссылки из /var/lib в старые каталоги;
• отличаются ли рабочие файлы Composer от штатных файлов текущего пакета;
• достаточно ли свободного места и inode для распаковки и обновления зависимостей;
• не осталось ли незавершённых операций APT или dpkg.

Особенно внимательно нужно относиться к серверам, которые пропустили несколько выпусков панели. Обновление с 1.9.x на 1.10.x включает больше изменений, чем установка одного сервисного патча.

2. Повторить обновление на staging

Тестовый стенд нужен не для проверки чистой установки HestiaCP. Его задача — воспроизвести накопленное состояние конкретного сервера.

Лучший вариант — развернуть копию виртуальной машины или восстановить резервную копию на отдельном VPS с той же версией ОС. Клон необходимо изолировать: не публиковать его с прежним IP и hostname, заблокировать исходящий SMTP и не подключать к рабочему DNS. Иначе тестовая копия может начать отправлять письма, обрабатывать задания или отвечать как второй production-сервер.

На staging следует повторить тот же путь обновления, который запланирован для production. После этого проверяются:

• вход в Roundcube минимум для двух пользователей на разных доменах;
• открытие папок, создание черновика и отправка тестового письма;
• авторизация по IMAP и SMTP;
• работа сайтов на каждой используемой версии PHP;
• панель HestiaCP и операции с тестовым доменом;
• cron, резервное копирование и восстановление тестового объекта;
• журналы обновления, PHP-FPM, systemd и почтовых сервисов.

Если staging собран как новая чистая машина, а production обновляется с многолетней историей, такой тест почти ничего не доказывает.

3. Подготовить и backup, и snapshot

Это разные инструменты.

• Backup HestiaCP нужен для восстановления пользователей, доменов, почты, баз данных и других данных. Копия должна находиться вне обновляемого сервера.
• Snapshot или образ виртуальной машины фиксирует состояние ОС, пакетов и системных конфигураций. Он позволяет быстрее вернуть сервер к состоянию до обновления.

Наличие архива ещё не означает, что восстановление сработает. До окна обслуживания нужно проверить доступ к копии и восстановить хотя бы один тестовый объект. Для snapshot следует заранее убедиться, что есть доступ к панели провайдера или гипервизору и понятен порядок возврата.

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

Если snapshot недоступен, например на bare-metal, готовят образ диска или параллельный сервер для возврата сервиса. Отсутствие кнопки Snapshot не делает обновление без плана отката безопасным.

Как проверить сервер после обновления

Сначала полностью прочитайте отчёт установщика. Строка об успешном завершении панели не отменяет предупреждения, появившиеся во время обновления Roundcube, Composer или шаблонов.

Дальше выполняется короткий smoke test:

1. Открыть панель HestiaCP и проверить отсутствие зависших задач.
2. Войти в Roundcube через два разных почтовых домена.
3. Отправить письмо наружу и принять ответное письмо.
4. Проверить IMAP и SMTP через отдельный почтовый клиент.
5. Посмотреть очередь Exim и состояние Dovecot.
6. Открыть сайты с разными версиями PHP и проверить подключение к базам.
7. Проверить cron, SSL, DNS и создание резервной копии.
8. Повторно просмотреть журналы через несколько минут после тестов.

Отказ Roundcube сам по себе ещё не означает потерю писем. Roundcube — это веб-клиент. Если Exim, Dovecot, IMAP и SMTP работают, пользователи могут временно подключиться через настольный или мобильный почтовый клиент. Но это обходной путь, а не подтверждение успешного обновления.

Когда прекращать диагностику и откатываться

Критерии отката задаются до начала работ. Например:

• не работает SMTP, IMAP или доступ к почтовым ящикам;
• webmail недоступен сразу на нескольких доменах;
• Composer оставил приложение с несогласованными зависимостями;
• пакетный менеджер или скрипт обновления завершился с ошибкой;
• панель не может корректно сохранить или пересобрать домен;
• причина не найдена за заранее выделенное время диагностики.

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

После отката нужно повторить тот же smoke test. Возврат снимка нельзя считать завершением, пока снова не проверены webmail, IMAP, SMTP, очередь писем, сайты и базы данных.

Когда legacy-сервер лучше мигрировать, а не продолжать ремонтировать

Возраст сервера сам по себе ничего не решает. Legacy-системой его делает накопленный дрейф:

• несколько поколений webmail установлены одновременно;
• сохранились старые каталоги, symlink и шаблоны;
• Composer-зависимости жёстко закреплены на устаревших версиях;
• PHP, ОС или база данных близки к окончанию поддержки;
• системные файлы менялись вручную и изменения не документировались;
• предыдущие обновления уже требовали ручного ремонта;
• восстановление из backup никогда не проверялось.

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

Обслуживаемый перенос строится иначе:

1. Зафиксировать пользователей, домены, ящики, базы, версии PHP, cron и локальные изменения.
2. Развернуть новый сервер на поддерживаемой ОС и актуальной HestiaCP.
3. Выполнить предварительный перенос сайтов, баз и почты.
4. Проверить сервисы через тестовый DNS или локальные записи.
5. Согласовать окно, финальную синхронизацию и порядок переключения DNS и MX.
6. После переключения проверить доставку почты, TLS, сайты, задания и мониторинг.
7. Сохранить старый сервер как ограниченную точку возврата, не допуская одновременной записи на два узла.

Если production-сервер с HestiaCP обслуживает сайты и рабочую почту, обновление стоит проводить как отдельное инфраструктурное изменение. HSTQ может выполнить предварительный аудит, подготовить staging, согласовать backup, snapshot и критерии отката, а при сильном накопленном дрейфе — провести миграцию на новый VPS или выделенный сервер. Состав работ и допустимый простой фиксируются после обследования текущей системы.