Сбой обновления до последней версии 21.08.25

[MikeNolan]

Последнее обновление требовало пересборки приложения в лаунчере, но это не удалось.

Сначала возникла ошибка из-за того, что adplugin был установлен отдельно, поэтому я удалил его.

Похоже, затем сбой произошел при попытке миграции базы данных secondsite:

2025-08-21 06:44:42.493 UTC [867] discourse@discourse_nu ERROR: должен быть владельцем расширения vector
2025-08-21 06:44:42.493 UTC [867] discourse@discourse_nu STATEMENT: ALTER EXTENSION vector UPDATE TO ‘0.7.0’;

---

1 миграция не удалась!

Не удалось выполнить миграцию secondsite

[jahan_gagan]

Причина

• Миграция пытается обновить расширение «vector».
• Пользователь PostgreSQL, запускающий миграцию (например, discourse), должен быть владельцем расширения, но оно принадлежит другому пользователю (часто postgres).

Решение

• Подключитесь к базе данных от имени владельца.
• Выполните обновление от имени владельца.

Ознакомьтесь с обсуждением по этой теме: Still an issue: ERROR: must be owner of extension vector - #2 by Falco

[MikeNolan]

Это исправило проблему.

Однако проблема с nginx и вторичными сайтами, о которой я сообщал более года назад, всё ещё актуальна.

В конфигурационных файлах nginx внутри контейнера проверяется, не является ли URL адресом первого сайта, и при необходимости он заменяется на него. Я снова закомментировал этот код.

[pfaffman (Jay Pfaffman)]

@MikeNolan

в файлах конфигурации nginx внутри контейнера проверяется, не является ли URL адресом первого сайта, и при необходимости он меняется на него. Я снова закомментировал этот код.

В способе обработки конфигурации nginx произошли значительные изменения.

У вас настроен мультисайт без обратного прокси?

[MikeNolan]

Что ж, прошло почти 2 года с тех пор, как я в последний раз смотрел на nginx, но эта проблема существовала ещё тогда, когда я впервые перешёл на Discourse 2 года назад, так что она не нова.

Вот фрагмент из файла nginx.conf:

server {
    server_name  huskerlist.tssi.com;
    root         /var/www/html;

    allow 162.210.7.125;
    allow 162.210.7.112;
    allow 162.210.7.116;
    allow 76.84.125.160;
    allow 172.17.0.2;
    allow 72.250.242.47;
    allow all;

    if ( $lockdown ) {
       set $custom_server_name "lists.tssi.com";
       return 300 "site is down for maintenance";
    }


    client_max_body_size 100M;

    # Загрузить файлы конфигурации для блока сервера по умолчанию.
    #include /etc/nginx/default.d/*.conf;

    location / {
            proxy_pass https://127.0.0.1:8443/;
            #proxy_pass http://unix:/var/discourse/shared/standalone/nginx.http.sock;
            proxy_set_header Host $http_host;
            proxy_http_version 1.1;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
            proxy_set_header X-Real-IP $remote_addr;
    }

    error_page 404 /404.html;
        location = /usr/share/nginx/html/40x.html {
    }

    error_page 500 502 503 504 /50x.html;
        location = /usr/share/nginx/html/50x.html {
    }

listen [::]:443 ssl; # управляется Certbot
listen 443 ssl; # управляется Certbot
ssl_certificate /etc/letsencrypt/live/lists.tssi.com/fullchain.pem; # управляется Certbot
ssl_certificate_key /etc/letsencrypt/live/lists.tssi.com/privkey.pem; # управляется Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # управляется Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # управляется Certbot

}

server {
    server_name  nu-sports.tssi.com;
    root         /var/www/html;

    allow 162.210.7.125;
    allow 162.210.7.112;
    allow 162.210.7.116;
    allow 76.84.125.160;
    allow 172.17.0.2;
    allow 72.250.242.47;
    allow all;

    if ( $lockdown ) {
       set $custom_server_name "lists.tssi.com";
       rewrite ^ https://lists.tssi.com/n-maint.html;
    }
    client_max_body_size 100M;

    # Загрузить файлы конфигурации для блока сервера по умолчанию.
    #include /etc/nginx/default.d/*.conf;

    location / {
            proxy_pass https://127.0.0.1:8443/;
            #proxy_pass http://unix:/var/discourse/shared/standalone/nginx2.http.sock:;
            proxy_set_header Host $http_host;
            proxy_http_version 1.1;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
            proxy_set_header X-Real-IP $remote_addr;
    }

    error_page 404 /404.html;
        location = /usr/share/nginx/html/40x.html {
    }

    error_page 500 502 503 504 /50x.html;
        location = /usr/share/nginx/html/50x.html {
    }

listen [::]:443 ssl; # управляется Certbot
listen 443 ssl; # управляется Certbot
ssl_certificate /etc/letsencrypt/live/lists.tssi.com/fullchain.pem; # управляется Certbot
ssl_certificate_key /etc/letsencrypt/live/lists.tssi.com/privkey.pem; # управляется Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # управляется Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # управляется Certbot

}

[MikeNolan]

Похоже, что при каждом запуске нового контейнера (например, после перезагрузки) файл /etc/nginx/conf.d/outlets/server/20-https.conf перезаписывается, и эти строки вызывают перенаправление на систему Discourse по умолчанию:

if ($https_host != huskerlist.tssi.com) {

rewrite (.$) https://huskerlist.tssi.com

}

Есть ли способ избежать этого? Какую цель выполняет этот код?

[pfaffman (Jay Pfaffman)]

@MikeNolan

Похоже, что каждый раз при создании нового контейнера (например, после перезагрузки) переписывается

файл /etc/nginx/conf.d/outlets/server/20-https.conf

Верно. Вы редактируете этот файл внутри контейнера? Создание нового контейнера означает создание нового контейнера. Переписывается не только этот файл, а все файлы.

@MikeNolan

Есть ли способ избежать этого?

Вы можете добавить что-то в ваш app.yml, чтобы изменить файл после его переписывания.

@MikeNolan

Какую цель преследует этот код?

Какие именно изменения вы вносите в этот файл? Зачем?

Ох. Постойте.

@pfaffman

У вас есть настройка мультисайта без обратного прокси?

Вы не ответили на этот вопрос, но, думаю, ответ — да.

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

Поэтому вам нужно добавить в ваш app.yml код, который отменит это.

Давным-давно у меня было решение для этого по адресу Setup Multisite Configuration with Let's Encrypt and no Reverse Proxy

@pfaffman

Но прямо сейчас (2023.02.11) эти инструкции не работают!! (Смотрите Настройка Let’s Encrypt с несколькими доменами / перенаправлениями, чтобы узнать, как обновить настройку letsencrypt и добавить часть fullpath. Я обновлю это, чтобы отразить эти изменения, очень скоро.)

Так что вам нужно будет добавить sed в exec или, возможно, использовать одну или несколько директив replace, чтобы удалить или изменить этот фрагмент. Вам, вероятно, всё ещё нужно следовать инструкциям из той темы (которые, как я думаю, всё ещё работают), чтобы получить несколько Теперь вы можете использовать DISCOURSE_HOSTNAME_ALIASES: www.domain.com,otherdomain.org,www.otherdomain.org для получения сертификатов для дополнительных имён хостов.

Думаю, самым изящным решением может быть придумать способ добавить другие псевдонимы имён хостов в этот код if ($http_host != каким-то образом. У меня сейчас нет сайтов, настроенных таким образом, поэтому я вряд ли захочу тратить время на то, чтобы разобраться в этом ради забавы.

Но да, в шаблоне web ssl есть следующее:

        if (\$http_host != ${DISCOURSE_HOSTNAME}) {
          rewrite (.*) https://${DISCOURSE_HOSTNAME}\$1 permanent;
        }

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

[MikeNolan]

Итак, по сути, вы говорите, что метод «secondsite» для размещения двух независимых форумов на одном сервере не работает и не включён в список задач по исправлению.

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

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

Если код, который формирует шаблон веб-SSL, не будет обновлён для проверки наличия secondsite (а также thirdsite и т. д.) в файле app.yml, то, похоже, это нужно реализовать непосредственно в app.yml. В таком случае это будет индивидуальное исправление для меня, а не решение проблемы для всех пользователей, запускающих несколько форумов на одном сервере с помощью, по-видимому, неработающего метода secondsite.

Сейчас я занимаюсь масштабным проектом по миграции системы для клиента, и эти сайты наиболее активны в период футбольного сезона. Поэтому мне необходимо настроить тестовый сервер для проверки исправлений в файле app.yml, а не пытаться исправлять работающую систему на лету.

[MikeNolan]

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

Текущая логика гласит: если сайт не является A, сделайте его A.

Введение второго сайта усложняет ситуацию, потому что если он не является ни A, ни B, то также неясно, будет ли правильным изменением его превращение в A или B. (Возможно, именно поэтому Discourse ещё не решил эту проблему.)

Возможно, удаление этих строк кода — правильное решение в случае наличия нескольких сайтов, поскольку внешний сервер nginx должен передавать только HTTPS-пакеты, соответствующие либо A, либо B. Принудительное перенаправление HTTP на HTTPS уже должно выполняться на внешнем сервере nginx.

[pfaffman (Jay Pfaffman)]

@MikeNolan

Итак, по сути вы говорите, что метод «secondsite» для размещения двух независимых форумов на одном сервере не работает и не входит в список задач по исправлению.

Этот метод никогда не входил в список поддерживаемых. Рекомендованным способом всегда было использование обратного прокси. Я придумал способ сделать это без обратного прокси, но мой «костыль» перестал работать пару лет назад.

Развёртывание нескольких сайтов без обратного прокси всегда было лишь фокусом для любительской демонстрации. Если вы профессионал, вам следует удалить шаблоны SSL и Let’s Encrypt и использовать обратный прокси, который обрабатывает SSL. Cdck использует HAProxy. Я использовал Traefik. Caddy довольно прост в управлении. Я перестал его использовать, потому что если кто-то удалял CNAME для своего сайта, это приводило к сбоям при обновлении всех сертификатов (возможно, это уже не так, прошло много лет).

[MikeNolan]

Так как я использую nginx с proxy_pass для перенаправления трафика в контейнер для двух разных FQDN, правильно ли я понимаю, что это означает использование метода обратного прокси для мультисайта?

[pfaffman (Jay Pfaffman)]

Да, я забыл про этот момент!

Пусть nginx обрабатывает HTTPS, удалите шаблоны SSL и Let’s Encrypt из вашего YAML-файла и пересоберите проект.