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

MAATRIX

YunoHost обещает простоту: один установочный скрипт — и у вас своя почта, облако, мессенджер и десятки приложений под одним доменом. На практике первые несколько дней после установки уходят на борьбу с портами, DNS-записями и сертификатами, которые почему-то не хотят выпускаться. Если вы уже наступили на одну из этих граблей — вы не одиноки, и почти все проблемы решаются без переустановки с нуля.

Установка падает или конфликтует с уже настроенным сервером

Первая и самая частая ошибка — попытка поставить YunoHost на сервер, где уже что-то крутится. Установочный скрипт curl https://install.yunohost.org | bash рассчитан на чистый Debian 12 (bookworm) без предустановленного nginx, Apache, Postfix, Dovecot или любой другой панели вроде aaPanel или CyberPanel. Если на сервере уже слушают порты 80, 443, 25, 465, 587, 993, 995 — установка либо падает с ошибкой, либо ставится «поверх» и потом ломается непредсказуемо.

Проверить, что порты свободны, до установки:

ss -tulpn | grep -E ':(80|443|25|465|587|993|995)\b'

Если что-то отвечает — это не YunoHost, значит сервис нужно остановить и снести (systemctl stop nginx apache2 postfix dovecot, затем apt purge). Второй частый источник конфликта — облачные образы с предустановленным firewall-агентом хостера или Docker, который сам перезаписывает правила iptables. YunoHost использует собственный yunohost firewall, и если в системе уже стоит ufw или другой фаервол-менеджер, лучше отключить его перед установкой:

ufw disable
systemctl disable --now ufw

Если статья ложится на новый сервер — сначала посмотрите на разницу между панелью и голым сервером: YunoHost — это именно панель-дистрибутив, она ожидает единоличный контроль над системой, а не соседство с другими сервисами.

Домен добавлен, но сертификат Let's Encrypt не выпускается

Это, пожалуй, топ-1 жалоба новичков. Вы делаете yunohost domain add example.com, заходите в веб-интерфейс — а там красный крестик вместо зелёного замка. Причины обычно три:

1. Порт 80 недоступен снаружи. Let's Encrypt проверяет владение доменом через HTTP-01 challenge на порту 80. Если хостер блокирует входящий трафик на 80/443 по умолчанию (бывает у некоторых дешёвых тарифов) или у вас стоит внешний CDN/прокси, ACME-запрос не пройдёт.
2. DNS ещё не разошёлся. A-запись домена должна указывать на IP сервера, и распространение может занимать от нескольких минут до суток в зависимости от TTL старой записи.
3. CAA-запись запрещает Let's Encrypt. Если в зоне домена уже есть CAA-запись на другого удостоверяющего центра, letsencrypt.org нужно явно добавить в разрешённые.

Диагностика прямо из коробки:

yunohost domain cert-status example.com --full
dig +short A example.com
dig +short CAA example.com

После правки DNS форсируйте перевыпуск:

yunohost domain cert-renew example.com --force

Если YunoHost жалуется на «self-signed certificate» — это нормальное состояние сразу после установки, пока ACME-challenge не прошёл; паниковать не стоит, пока не пройдёт хотя бы 10–15 минут после правильной настройки DNS. Подробный разбор смежных ошибок Let's Encrypt (включая rate limit и просроченные сертификаты) — в статье про частые ошибки Let's Encrypt.

Почта уходит в никуда: блокировка 25 порта у провайдера

Отдельная головная боль YunoHost — встроенная почта на Postfix/Dovecot. Панель настраивает всё сама, но если исходящий SMTP (порт 25) заблокирован на уровне хостинг-провайдера, письма будут либо зависать в очереди, либо улетать с ошибкой Connection timed out. Это не баг YunoHost — так по умолчанию блокируют трафик многие дешёвые VPS-провайдеры, чтобы через их сети не рассылали спам.

Проверить блокировку можно так:

telnet smtp.gmail.com 25

Если соединение зависает и не устанавливается за разумное время — порт закрыт исходящим фаерволом хостера, и это нужно решать не на стороне сервера, а через провайдера: запрашивать разблокировку 25 порта или изначально брать сервер, где исходящий SMTP открыт по умолчанию (это стоит уточнять до покупки, а не после недели переписки с поддержкой).

Второй слой проблем — репутация. Даже с открытым портом 25 письма могут падать в спам или отбрасываться получателем, если:

• нет обратной PTR-записи (rDNS) на IP сервера, указывающей на домен почты;
• не совпадают SPF/DKIM/DMARC записи с тем, что реально предлагает выставить YunoHost.

YunoHost сам генерирует рекомендуемую DNS-зону командой:

yunohost domain dns suggest example.com

Возьмите её вывод целиком и внесите в DNS-панель регистратора домена — включая MX, SPF (v=spf1 ...), DKIM (mail._domainkey) и DMARC записи. PTR настраивается не в DNS домена, а в панели хостинг-провайдера — там, где вы арендовали IP.

Приложение не устанавливается или ломается после обновления

Каталог приложений YunoHost — это отдельный git-репозиторий с манифестами, и он может рассинхронизироваться с вашей локальной копией:

yunohost tools update
yunohost tools upgrade apps

Если конкретное приложение падает при установке с ошибкой вроде Installation failed, первым делом смотрите не в общий лог, а в лог именно этой операции:

yunohost app list
yunohost log list
yunohost log show <id_операции>

Частые причины падения:

• Не хватает диска. Многие приложения (Nextcloud, Discourse, GitLab) на этапе установки распаковывают архивы и требуют свободного места в 2–3 раза больше итогового размера. df -h перед установкой — обязательная привычка.
• Конфликт версии PHP/MySQL. Часть старых пакетов из каталога рассчитана на конкретную минорную версию, которая уже недоступна в репозиториях Debian — обновите каталог перед установкой.
• Занят поддомен или путь. Если приложение уже пробовали ставить и снесли неудачно, могли остаться хвосты в базе или nginx-конфиге. yunohost app remove <id> перед повторной попыткой снимает большинство таких проблем.

После крупного обновления самого YunoHost (yunohost tools upgrade system) полезно прогнать пересборку системных конфигов, если какой-то сервис отказывается стартовать:

yunohost tools regen-conf --force

Доступ в админку заблокирован или забыт пароль

С YunoHost 11+ логика входа изменилась: администратор — это обычный пользователь с правами в группе admins, а не отдельный служебный логин. Если пароль забыт или доступ потерян, восстановление делается через SSH или консоль хостера (важно иметь доступ хотя бы к одному из них до того, как понадобится):

yunohost user update admin_username --change-password

Если SSH тоже недоступен (например, забыт пароль root, а ключи не настроены), остаётся консоль восстановления через панель хостинг-провайдера (VNC/serial console) — зайти в систему локально и сбросить пароль стандартными средствами Linux. Поэтому первое, что стоит сделать сразу после установки YunoHost, — прописать SSH-ключ и сохранить его в менеджере паролей, а не полагаться только на веб-интерфейс.

Бэкапы создаются, но не восстанавливаются

yunohost backup create работает надёжно, а вот восстановление иногда преподносит сюрпризы. Архивы по умолчанию складываются в /home/yunohost.backup/archives/ и должны занимать заметно меньше места, чем «живая» система, — но на восстановление временно нужно почти вдвое больше свободного диска, потому что распаковка происходит рядом с существующими данными перед их заменой.

Типичные причины неудачного restore:

• Версия YunoHost не совпадает. Бэкап, снятый на старой версии, не всегда чисто разворачивается на новой — сначала обновите систему, потом восстанавливайте.
• Восстановление на другой домен. Часть приложений жёстко прописывает домен в конфигах при бэкапе; при переносе на новый домен нужно восстанавливать с явным указанием целевого домена через флаг, либо донастраивать вручную после.
• Не хватило места в момент restore — процесс обрывается на середине, оставляя систему в промежуточном состоянии. Перед восстановлением критичных бэкапов стоит проверить df -h и, если нужно, временно освободить место.

Проверяйте бэкапы регулярно тестовым восстановлением на отдельном сервере, а не только фактом «архив создался» — это единственный способ убедиться, что в критический момент восстановление действительно сработает.

Диагностика: как читать yunohost diagnosis и не паниковать зря

В админке и через CLI YunoHost выдаёт цветные предупреждения по категориям — basesystem, DNS-записи, порты, веб, почта, системные ресурсы:

yunohost diagnosis run
yunohost diagnosis show --issues

Не все предупреждения одинаково критичны. Жёлтые (warning) часто указывают на то, что можно улучшить, но не блокирует работу — например, отсутствие DNSSEC или необязательной DNS-записи. Красные (error) требуют внимания сразу — обычно это недоступный порт, неверная A-запись или неработающий сертификат. Логика простая: сначала чините всё красное, потом уже разбирайтесь с жёлтым по остаточному принципу.

Если диагностика регулярно показывает нестабильность по ресурсам (память, диск, CPU) — это обычно не ошибка конфигурации, а сигнал, что текущего сервера уже не хватает под набор установленных приложений: YunoHost с почтой, Nextcloud и парой SaaS-заменителей ощутимо прожорливее одиночного nginx.

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