Перейти к содержимому
BXWiki

Обновления в закрытом контуре - прокси, пакет, ручная установка

Сервер в закрытом контуре не достаёт до серверов обновлений, и страница обновлений заканчивается таймаутом. Разбираем два рабочих пути: прокси для системы обновлений и пакет, собранный под конкретный набор модулей.

Решение

Проверяем доступ с самого сервера

Проверяем соединение тем же способом, что и платформа:

Окно терминала
php -r '$s = @fsockopen("www.1c-bitrix.ru", 443, $e, $m, 5); var_dump((bool) $s, $m);'
curl -sI --max-time 5 https://www.1c-bitrix.ru/ | head -1
getent hosts www.1c-bitrix.ru     # имя и маршрут проверяем по отдельности
# закрытый контур виден по таймауту, а не по внятному отказу соединения

Успех curl тут ничего не доказывает. Он читает системные переменные прокси, а сокет-функции ядра их не читают. Сообщение о таймауте с кодом 110 говорит о закрытом исходящем порте, а не о поломке сайта.

Смотрим, куда именно ходит система обновлений:

SELECT NAME, VALUE FROM b_option
 WHERE MODULE_ID = 'main' AND NAME LIKE 'update%';
-- адрес сервера обновлений лежит в опции update_site
-- единственное верное значение здесь - www.1c-bitrix.ru

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

Настраиваем прокси для системы обновлений

Проверяем прокси от имени пользователя сайта:

Окно терминала
sudo -u bitrix curl -sI -x http://10.0.0.1:3128 --max-time 5 \
     https://www.1c-bitrix.ru/ | head -1
sudo -u bitrix curl -sI -x http://10.0.0.1:3128 --max-time 5 \
     https://marketplace.1c-bitrix.ru/ | head -1
# обновления и решения маркетплейса живут на разных именах

Адрес прокси, порт и пароль заполняют в настройках главного модуля, в разделе обновления системы. Правка /etc/profile и конфигов nginx на это не влияет: наружу ходит код сайта, а не консоль администратора.

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

Собираем пакет, когда прокси не дают

Снимаем список модулей с версиями для заявки:

Окно терминала
for f in bitrix/modules/*/install/version.php; do
    printf '%-22s %s\n' "$(basename "$(dirname "$(dirname "$f")")")" \
        "$(grep -oE '[0-9]+\.[0-9]+\.[0-9]+' "$f" | head -1)"
done
# редакция и набор модулей у каждой копии свои
# ключ этой копии лежит отдельным файлом bitrix/license_key.php

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

Ставим пакет руками и проверяем результат

Кладём архив в каталог обновлений от пользователя сайта:

Окно терминала
install -o bitrix -g bitrix -m 644 update_archive.gz bitrix/updates/
ls -l bitrix/updates/ | head -3
tail -20 bitrix/modules/updater.log   # шаги обновления пишутся сюда

Дальше архив разбирает страница обновлений в админке. Она распаковывает его в каталоги вида update_m<метка времени> и накатывает шаги по очереди. Чужой владелец файла или неполная загрузка дают ошибку [UUGZA06] о неверном формате и [CL02] о распаковке пакета.

Сверяем версии модулей после установки:

use Bitrix\Main\ModuleManager;


foreach (ModuleManager::getInstalledModules() as $module) {
    printf("%-22s %s\n", $module['ID'], ModuleManager::getVersion($module['ID']));
}
// версии обязаны совпасть с заявленными в собранном пакете

Установка проходит одним разом и наружу не обращается. Отложенный SQL из шапки админки выполняем руками, потому что тяжёлые запросы платформа откладывает сама. Кэш опкода сбрасываем перезапуском PHP-FPM: иначе страница обновлений сообщает о ненайденном классе.

Что в отрыве от сети обновить не выйдет

Решения маркетплейса приезжают со своего сервера, отдельного от сервера обновлений. Разрешения на одно имя для них не хватает: решение ставят загрузкой его архива руками.

Окружение обновляется не отсюда вообще: пакеты сервера, ветку PHP и базу переключают из консольного меню /root/menu.sh. Оно тянет их из репозиториев операционной системы, а для них нужно своё зеркало внутри контура.

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

Типичные проблемы

fsockopen(): unable to connect to www.1c-bitrix.ru:80.

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

UPSD01: пустой ответ от сервера обновлений.

Соединение через шлюз или прокси не устанавливается, хотя сайт при этом работает. Аутентификация прокси по адресу выдана прежней машине и на новую не распространяется.

Модули обновляются, а маркетплейс пуст.

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

[UUGZA06] Неверный формат файла update_archive.gz.

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

ERROR_WRONG_CODE при следующем обновлении.

Пакет поставили и на публичную копию, и на копию для разработки сразу. Обновляют одну установку, а второй ставят маркер «Установка для разработки».

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

Сайт работает, а обновиться не может. Куда смотреть?

Проверить соединение с сервером обновлений прямо с машины сайта: сначала имя через getent hosts, потом порт сокет-функцией. Браузер администратора ходит из другой сети, и его успех о доступе сервера не говорит ничего.

Прокси прописан в системе, почему обновления его не видят?

Системные переменные читают curl, wget и менеджер пакетов. Система обновлений соединяется сокет-функциями и берёт адрес прокси из настроек главного модуля, поэтому её настраивают отдельно.

Можно ли просто скачать дистрибутив и перезаписать /bitrix/?

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

Как настроить прокси для загрузки дистрибутива на пустой сервер?

В начале файла bitrixsetup.php лежит блок настроек прокси: $proxyAddr, $proxyPort, $proxyUserName и $proxyPassword. Без них загрузчик соединяется напрямую и заканчивается таймаутом.

Как жить, если прокси не дадут никогда?

Каждое обновление превращается в заявку на пакет под свой набор модулей и ручную установку. Между такими заявками сайт живёт без связи с внешними серверами, и обновления безопасности приходят с задержкой.

Смежное

Первоисточник