Форум

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

Причиной вопроса стала курьезная, но неприятная ситуация.
25.08.19 провел обновление Веб-окружения с версии 7.3.4. до версии 7.4.1. После обновления соединение по порту 80 было корректным, но сайт прекратил работу по порту 443, соединение HTTPS. Сообщение в браузере, типа, нет возможности загрузить сертификат.
После анализа выяснилось, что в файле /etc/nginx/bx/conf/ssl.conf отсутствовала команда на прямое включение протокола, а именно:
ssl on;
До обновления эта директива в файле была. Подумал, что разработчики Битрикса допустили ошибку(?) - пардон.
Добавляю в файл ssl.conf директиву
ssl on;
Проверил тестом nginx –t. Тест сообщает, что директива ssl устарела, но синтаксис нормальный. Делаю перезагрузку и сайт работает корректно.
Решил разобраться с «устареванием» директивы. На официальном сайте nginx сказано, что теперь ssl не директива, а параметр. Параметр должен включаться в другую директиву listen.
Тут я вспоминаю, что директива listen используется для настроек конфигурации обработки входящих запросов. Для этой цели используется файл etc/nginx/bx/site_avaliable/ssl.s1.conf. Открываю этот файл и вижу директиву в старой нотации:
listen 443 http2
А должно быть в новой нотации вместе с ssl.
listen 443 http2 ssl
Возникает ощущение, что обновление прошло не корректно. Чтобы исключить лишние версии покупаю почасовой хостинг, в качестве персонального эталона. Загружаю туда Веб-окружение. Оказывается, на эталоне файл etc/nginx/bx/site_avaliable/ssl.s1.conf имеет правильную запись в новой нотации
listen 443 http2 ssl
Отсюда, сразу становится ясно:
(1) файл etc/nginx/bx/site_avaliable/ssl.s1.conf не обновился,
(2) файл /etc/nginx/bx/conf/ssl.conf обновился, так как в нем исчезла директива (ssl on;), которая теперь и не нужна

Обращаю внимание, что моем сервере файл файл etc/nginx/bx/site_avaliable/ssl.s1.conf имеет права rw-rw-r--, а этот же файл на эталонном сервере имеет другие права rw-r- - r--. Делаю предположение, что различие в правах остановило скрипт по обновлению.
Хотелось бы знать условия остановки обновления, чтобы всегда отслеживать их соблюдение.
Заранее спасибо.

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

Конечно, спасибо, за рекомендацию по поиску ошибок, но я задаю вопрос на совершенно иную тему: "как устроен сценарий обновления Виртуальной Машины/Веб-окружения, или как устроен скрипт миграции пакета обновлений".
Я предполагал, что сценарий простой. Есть список файлов на обновление. Эти файлы собраны в пакет обновлений (сборка) и хранятся в каком-то репозитории Битрикса. Именно эти файлы и обновляются на машине клиента. Если клиент вносил какие-то изменения в обновляемый файл, то скрипт обновления автоматически затрет изменения. Но это проблемы клиента.
Похоже, сценарий иной. Кроме списка файлов (сборки в репозитории), есть условия на состояние файла на обновляемой машине. Например, файл обновляется, если его владельцем обозначен bitrix. Если владелец root, то файл не обновляется, хотя он и есть в списке на обновление. Возможно, сценарий совсем другой: есть один пакет загрузки на чистую платформу и немного отличающийся пакет для обновлений. Об этом, об обновлении файла etc/nginx/bx/site_avaliable/ssl.s1.conf пишет предыдущий участник
Мне НЕ хочется гадать, мне хочется знать точный сценарий обновления. Исходя из этого, подстроить свою работу.

Семён Забусов, Вот полностью согласен. У меня вообще для Битрикс24 стоит тестовый портал, где обкатываются все обновления+свои приложения. Сервер так же обновляется, потом пишется план обновления для боевого, а потом уже боевой обновляется.
И на тестовом просто nginx ругался на устаревшую директиву, а так всё работало нормально. Я вообще потратил около недели суммарно, чтобы понять, как правильно править конфиги, чтобы ничего не улетало при обновлении.