Чиним BitrixVM после ручных правок конфигов

Как на самом деле устроена BitrixVM

Половина проблем начинается с того, что администратор считает BitrixVM обычным сервером с nginx и Apache. Формально так и есть, но конфигурация здесь не написана руками, а сгенерирована. Запрос идёт по цепочке:

• nginx принимает 443 и отдаёт статику
• Динамику он проксирует на Apache — но не «на localhost», а на конкретный порт конкретного виртхоста: 8888, 8887 и так далее
• Каждому сайту соответствует свой виртхост Apache со своим DocumentRoot в /home/bitrix/www или /home/bitrix/ext_www/<домен>
• Список сайтов и их ролей хранится отдельно — в реестре, с которым работает меню BitrixVM

Ключевая деталь: в мультисайтовой конфигурации один сайт держит ядро, а остальные ссылаются на него симлинками. Каталог `bitrix` и каталог загрузок у них общие, база тоже одна. Именно поэтому сломанная маршрутизация даёт такой обманчивый симптом — об этом дальше.

Состояние BitrixVM живёт в двух местах сразу: в конфигах nginx и Apache и в реестре сайтов, по которому меню строит своё представление о машине. Меню меняет оба. Ручной `sed` — только первое. С этого расхождения и начинается вся история.

Симптом: портал открывается, но показывает чужой сайт

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

# Куда nginx на самом деле шлёт динамику для этого домена
grep -r 'proxyserver' /etc/nginx/bx/site_available/ | grep portal

# bx_ext_ssl_portal.example.ru.conf:
#   set $proxyserver "http://127.0.0.1:8888";   ← виртхост ДРУГОГО сайта

# А на каком порту слушает виртхост самого портала
grep -A2 'VirtualHost' /etc/httpd/bx/conf/bx_ext_portal.example.ru.conf
# <VirtualHost 127.0.0.1:8887>
#   DocumentRoot /home/bitrix/ext_www/portal.example.ru

То есть HTTPS-запросы к порталу уходили на виртхост магазина. А поскольку ядро в такой конфигурации общее, авторизация при этом честно работала — что и сбивало с толку. Ломался не вход, а то, чей `DocumentRoot` обслуживает запрос.

Причина рассинхрона типовая: администратор чинил «502 Bad Gateway», создавал и удалял виртхосты на портах 8080, 8888, 8887, 8895, а конфиг nginx правил отдельным `sed`. В какой-то момент Apache уехал на новый порт, а nginx остался на старом.

Порядок диагностики

Прежде чем что-то менять, стоит выписать реальную картину: какие сайты есть, кто из них держит ядро, какой домен на какой порт и в какой каталог ведёт. На это уходит десять минут, и оно экономит часы.

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

Как чинить, чтобы не уронить работающее

Правильный путь — меню BitrixVM: оно меняет и конфиги, и реестр, то есть не создаёт нового расхождения. Точечную правку конфига руками мы применяем только когда меню недоступно или его действие шире, чем нужно, — и тогда обязательно с бэкапом.

# 1. Снимок конфигов целиком — точка отката на всю сессию
tar czf /root/etc-backup-$(date +%Y%m%d_%H%M%S).tgz \
  /etc/nginx /etc/httpd /etc/ansible /etc/php.d /etc/cron.d

# 2. Бэкап конкретного файла рядом с ним
cp bx_ext_ssl_portal.example.ru.conf{,.bak-$(date +%Y%m%d_%H%M%S)}

# 3. Правка
sed -i 's|8888|8887|' bx_ext_ssl_portal.example.ru.conf

# 4. Проверка ДО применения — иначе reload положит все сайты сразу
nginx -t

# 5. Мягкое применение: текущие соединения не рвутся
systemctl reload nginx

Шаг с `nginx -t` пропускают чаще всего, а он здесь важнее остальных: на этой машине один nginx обслуживает все сайты, и синтаксическая ошибка в одном конфиге уронит вообще всё.

Что ломают тем же способом

Рассинхрон маршрутизации оказался не единственным следом ручной работы. Все остальные находки — того же происхождения: действие выполнено мимо штатного механизма, поэтому система о нём не знает.

• Сертификат выпускали вручную через certbot и dehydrated вместо меню. Текущий ещё валиден, но задание на автопродление не создано — сертификат просто истечёт в тихий день
• swap отключили, пересоздали и прописали в fstab UUID корневого раздела. Итог: swap нет вообще, а запись в fstab выглядит правдоподобно
• Параметр ядра для гибернации правили дважды, хотя без рабочего раздела подкачки он ни на что не влияет
• В реестре остался сайт, у которого нет каталога с ядром, — меню на нём показывает ошибку и мешает штатным операциям
• После прерванного обновления ядра осталась папка-двойник модуля на 211 МБ, из-за которой вход в админку падал с фатальной ошибкой

# Проверка, которая занимает секунду и ловит «мнимый» swap
swapon --show          # пусто — значит swap нет, что бы ни было в fstab
free -h | grep -i swap # Swap: 0B 0B 0B

# Сверяем UUID из fstab с реальными разделами
grep swap /etc/fstab
blkid | grep -E 'sda[0-9]'
# если UUID из fstab совпадает с корневым разделом — запись битая

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

Что забрать себе

• В BitrixVM конфиги генерируемые. Меняете через меню — и конфиги, и реестр остаются согласованными; правите руками — расходятся
• Симптом «сайт показывает чужое содержимое» на мультисайте почти всегда означает не поломку CMS, а неверный порт в проксировании
• Общее ядро маскирует проблему: авторизация и часть страниц продолжают работать, поэтому диагноз ставят неверно
• Перед любой правкой — снимок конфигов, после правки — проверка синтаксиса, только потом мягкое применение
• Сертификаты, swap и обновления ядра ломаются тихо. Их состояние проверяется тремя короткими командами, и это стоит делать при приёмке любого чужого сервера

И главное: разбирать такую машину нужно с описи, а не с правок. Пока не выписано, какой домен куда ведёт и кто держит ядро, любая правка — это ещё один слой поверх чужих экспериментов.