השדרוג האחרון דרש בנייה מחדש של האפליקציה ב-launcher, אך הוא נכשל.
נראה שהוא נכשל בניסיון להעביר את מסד הנתונים של secondsite:
2025-08-21 06:44:42.493 UTC [867] discourse@discourse_nu ERROR: must be owner of extension vector
2025-08-21 06:44:42.493 UTC [867] discourse@discourse_nu STATEMENT: ALTER EXTENSION vector UPDATE TO ‘0.7.0’;
1 העברות נכשלו!
העברת secondsite נכשלה
Checkout the discussion on the same Still an issue: ERROR: must be owner of extension vector - #2 by Falco
זה פתר את הבעיה.
עם זאת, הבעיה עם nginx ו-secondsites שדיווחתי עליה לפני יותר משנה עדיין קיימת,
בקובצי התצורה של nginx בתוך הקונטיינר, הוא בודק אם ה-URL אינו עבור האתר הראשון ומשנה אותו לאתר זה. ביטלתי את הקוד הזה – שוב.
There have been big changes in how the nginx config is handled.
Do you have a multisite setup with no reverse proxy?
Well, it’s been nearly 2 years since I’ve looked at nginx much, but this problem existed when I first moved over to Discourse 2 years ago, so it is not new.
Here’s an excerpt from the nginx.conf file:
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;
# Load configuration files for the default server block.
#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; # managed by Certbot
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/lists.tssi.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/lists.tssi.com/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by 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;
# Load configuration files for the default server block.
#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; # managed by Certbot
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/lists.tssi.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/lists.tssi.com/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
Apparently every time it set up a new container (such as during a reboot) it rewrites the
/etc/nginx/conf.d/outlets/server/20-https.conf file, and these lines cause a redirect to the default discourse system:
if ($https_host != huskerlist.tssi.com) {
rewrite (.$) https://huskerlist.tssi.com
}
Is there a way to avoid this? What purpose does this code serve?
That’s right. Are you editing that file inside of the container? Building a new container builds a new container. It’s not rewriting that file, but all files.
You can add stuff to your app.yml to change the file after it’s rewritten.
What changes are you making to that file? Why?
Oh. Wait.
You didn’t answer this question, but I think the answer is yes.
It forces the site since you mostly never want your site to be available by more than one hostname.
So you’ll need to add some code to your app.yml to un-do that.
A long time ago, I had a solution for this in Setup Multisite Configuration with Let's Encrypt and no Reverse Proxy
So you’ll need to add a sed in an exec or maybe use some replace stanza(s) to remove or modify that bit. You probably still need to follow the stuff in that topic (that I think may still work) to get multiple You can now use the DISCOURSE_HOSTNAME_ALIASES: www.domain.com,otherdomain.org,www.otherdomain.org to get certs for the additional hostnames.
I suppose the most clever solution might be to contrive to add the other hostname aliases into that if ($http_host != code somehow. I don’t have any sites set up that way right now, so I’m not likely to want to spend time figuring it out for fun.
But yeah, the web ssl template has this:
if (\$http_host != ${DISCOURSE_HOSTNAME}) {
rewrite (.*) https://${DISCOURSE_HOSTNAME}\$1 permanent;
}
so you could either delete it or find a way to make it also check for your other hostnames.
אז, בעצם מה שאתה אומר זה שהשיטה ‘secondsite’ לאירוח של שני פורומים עצמאיים על שרת אחד שבורה ולא נמצאת ברשימת הדברים לתיקון.
אז אתה יכול למחוק את זה או למצוא דרך לגרום לזה לבדוק גם את שמות המתחם האחרים שלך.
מחיקתו בתוך הקונטיינר זה מה שעשיתי, אבל בכל פעם שקונטיינר מתחיל או שנוצר אימג’ חדש של קונטיינר, הוא מחזיר את הקוד הזה, אז צריך לשנות אותו במקור איפשהו כך שכאשר הוא בונה קונטיינר חדש, הוא בונה אותו נכון ובודק ריבוי דומיינים ב-app.yml. (זה כנראה עדיף על מחיקה של 3 שורות הקוד האלה.)
אם הקוד שבונה את תבנית ה-web ssl לא יתעדכן כדי לבדוק את app.yml עבור secondsite (וגם thirdsite ו… ), נשמע שזה צריך לקרות ב-app.yml, מה שהופך את זה לתיקון מותאם אישית עבורי ולא תיקון לכל המשתמשים שמריצים פורומים מרובים על שרת יחיד תוך שימוש בשיטת secondsite השבורה לכאורה.
כרגע אני בעיצומו של פרויקט הגירת מערכת גדולה עבור לקוח, והאתרים האלה פעילים במיוחד בעונת הכדורגל בכל מקרה, אז אני צריך להקים את שרת הבדיקות שלי כדי לבדוק כתיבת תיקונים ל-app.yml במקום לנסות לתקן את המערכת החיה תוך כדי תנועה.
בהתחשב בכך בקצרה, תיקון תבנית ה-SSL הוא מאתגר במידה מסוימת.
הלוגיקה הנוכחית אומרת: אם האתר אינו A, הפוך אותו ל-A.
הכנסת אתר שני מסבכת את העניינים, כי אם הוא אינו A והוא אינו B, גם לא ברור ששינויו ל-A או ל-B הוא הדבר הנכון לעשות. (זו אולי הסיבה לכך שזה לא טופל על ידי Discourse.)
אולי מחיקת שורות הקוד האלה היא הדבר הנכון לעשות כאשר ישנם מספר אתרים, מכיוון ששרת ה-nginx החיצוני אמור לשלוח רק חבילות https התואמות ל-A או ל-B. הכפייה מ-HTTP ל-HTTPS אמורה כבר להתרחש בשרת ה-nginx החיצוני.
It was never on the list of things to support. The recommended was was always to use a reverse proxy. I contrived a way to do it without a reverse proxy. And my hack broke a couple years ago.
Doing multisite without a reverse proxy was always a parlor trick. If you’re a pro, you should remove the ssl and let’s encrypt templates and use a reverse proxy that handles ssl. Cdck uses haproxy. I’ve been using traefik. Caddy is pretty easy to manage. I quit using it because if someone removed the cname for their site it would cause all cert renewals to fail (that may no longer be the case, it’s been years).
האם אני צודק בכך שאני משתמש בשיטת ה-reverse proxy עבור multisite, מכיוון שאני משתמש ב-nginx עם proxy_pass להעברת תעבורה לקונטיינר?
כן. שכחתי מזה!
תגרום לזה לעשות את ה-https ולהסיר את תבניות ה-ssl וה-let’s encrypt מקובץ ה-yml שלך.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.