فشل الترقية إلى أحدث إصدار 21/8/25

تثبيت
1

تطلب آخر ترقية إعادة بناء التطبيق في المشغل، لكنها فشلت.

يبدو أنها فشلت في محاولة ترحيل قاعدة بيانات 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

2

السبب

  • تحاول عملية الترحيل ترقية الامتداد “vector”.
  • يجب أن يكون مستخدم PostgreSQL الذي يقوم بتشغيل عملية الترحيل (على سبيل المثال، discourse) هو مالك الامتداد، ولكنه مملوك لمستخدم مختلف (غالباً postgres).

الحل

  • اتصل بقاعدة البيانات الخاصة بك بصفتك المالك
  • قم بتشغيل التحديث بصفتك المالك

تحقق من المناقشة حول نفس الموضوع Still an issue: ERROR: must be owner of extension vector - #2 by Falco

إعجاب واحد (1)
3

لقد أصلح ذلك.

ومع ذلك، لا تزال المشكلة المتعلقة بـ nginx و secondsites التي أبلغت عنها منذ أكثر من عام قائمة،
في ملفات تكوين nginx داخل الحاوية، يتحقق مما إذا كان عنوان URL ليس للموقع الأول ويغيره إلى ذلك. لقد علقت هذا الكود - مرة أخرى.

إعجاب واحد (1)
4

لقد كانت هناك تغييرات كبيرة في كيفية التعامل مع إعدادات nginx.

هل لديك إعداد متعدد المواقع بدون وكيل عكسي؟

5

حسنًا، لقد مر ما يقرب من عامين منذ أن نظرت في nginx كثيرًا، ولكن هذه المشكلة كانت موجودة عندما انتقلت لأول مرة إلى Discourse قبل عامين، لذا فهي ليست جديدة.

إليك مقتطف من ملف 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;

    # 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

}

6

يبدو أنه في كل مرة يقوم فيها بإعداد حاوية جديدة (مثل أثناء إعادة التشغيل) فإنه يعيد كتابة الملف
/etc/nginx/conf.d/outlets/server/20-https.conf، وهذه الأسطر تسبب إعادة توجيه إلى نظام discourse الافتراضي:

if ($https_host != huskerlist.tssi.com) {
rewrite (.$) https://huskerlist.tssi.com
}

هل هناك طريقة لتجنب ذلك؟ ما الغرض الذي يخدمه هذا الكود؟

7

هذا صحيح. هل تقوم بتحرير هذا الملف داخل الحاوية؟ بناء حاوية جديدة يبني حاوية جديدة. لا يقوم بإعادة كتابة هذا الملف، بل جميع الملفات.

يمكنك إضافة عناصر إلى ملف app.yml الخاص بك لتغيير الملف بعد إعادة كتابته.

ما هي التغييرات التي تجريها على هذا الملف؟ ولماذا؟

أوه. انتظر.

لم تجب على هذا السؤال، لكنني أعتقد أن الإجابة هي نعم.

إنه يجبر الموقع حيث أنك في الغالب لا تريد أن يكون موقعك متاحًا بأكثر من اسم مضيف واحد.

لذلك ستحتاج إلى إضافة بعض التعليمات البرمجية إلى ملف app.yml الخاص بك للتراجع عن ذلك.

منذ وقت طويل، كان لدي حل لهذا في Setup Multisite Configuration with Let's Encrypt and no Reverse Proxy

لذلك ستحتاج إلى إضافة 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;
        }

لذلك يمكنك إما حذفه أو إيجاد طريقة لجعله يتحقق أيضًا من أسماء المضيفين الأخرى الخاصة بك.

8

إذًا، ما تقوله أساسًا هو أن طريقة ‘secondsite’ لاستضافة منتدين مستقلين على خادم واحد معطلة وليست ضمن قائمة الأشياء التي سيتم إصلاحها.

لذا يمكنك إما حذفه أو إيجاد طريقة لجعله يتحقق أيضًا من أسماء المضيفين الأخرى الخاصة بك.

حذفه في الحاوية هو ما كنت أفعله، ولكن في كل مرة تبدأ فيها الحاوية أو يتم إنشاء صورة حاوية جديدة، يتم إعادة هذا الكود، لذا يجب تغييره في المصدر في مكان ما بحيث عند بناء حاوية جديدة، يتم بناؤها بشكل صحيح مع التحقق من مجالات متعددة في app.yml. (هذا ربما يكون أفضل من مجرد حذف تلك الأسطر الثلاثة من الكود.)

إذا لم يتم تحديث الكود الذي يبني قالب شهادة SSL للويب للتحقق من app.yml للحصول على secondsite (و thirdsite و…)، فيبدو أن هذا يحتاج إلى الحدوث في app.yml، مما يجعله إصلاحًا مخصصًا لي بدلاً من إصلاح لجميع المستخدمين الذين يشغلون منتديات متعددة على خادم واحد باستخدام طريقة secondsite المعطلة على ما يبدو.

في الوقت الحالي، أنا في منتصف مشروع ترحيل نظام كبير لأحد العملاء، وهذه المواقع هي الأكثر نشاطًا خلال موسم كرة القدم على أي حال، لذا أحتاج إلى إعداد خادم الاختبار الخاص بي لاختبار كتابة تصحيحات app.yml بدلاً من محاولة إصلاح النظام المباشر أثناء التنقل.

9

بالتفكير في الأمر بإيجاز، فإن إصلاح قالب SSL يمثل تحديًا إلى حد ما.

المنطق الحالي يقول: إذا لم يكن الموقع A، فاجعله A.

إن إدخال موقع ثانٍ يعقد الأمور، لأنه إذا لم يكن A ولم يكن B، فليس من الواضح أيضًا أن تغييره إلى A أو B هو الشيء الصحيح الذي يجب فعله. (قد يكون هذا هو سبب عدم معالجة Discourse لهذا الأمر.)

ربما يكون حذف تلك الأسطر من التعليمات البرمجية هو الشيء الصحيح الذي يجب فعله عندما تكون هناك مواقع متعددة في النهاية، لأن خادم nginx الخارجي يجب أن يرسل فقط حزم HTTPS التي تتطابق مع A أو B. يجب أن يحدث فرض HTTP إلى HTTPS بالفعل في خادم nginx الخارجي.

10

لم تكن أبدًا ضمن قائمة الأشياء التي سيتم دعمها. الطريقة الموصى بها كانت دائمًا استخدام وكيل عكسي. لقد ابتكرت طريقة للقيام بذلك بدون وكيل عكسي. وقد تعطلت حيلتي قبل بضع سنوات.

كان القيام بتعدد المواقع بدون وكيل عكسي دائمًا خدعة. إذا كنت محترفًا، فيجب عليك إزالة قوالب ssl و let’s encrypt واستخدام وكيل عكسي يتعامل مع ssl. يستخدم Cdck haproxy. لقد كنت أستخدم traefik. Caddy سهل الإدارة للغاية. توقفت عن استخدامه لأنه إذا قام شخص ما بإزالة cname لموقعه، فسيؤدي ذلك إلى فشل جميع تجديدات الشهادات (قد لا يكون هذا هو الحال بعد الآن، لقد مرت سنوات).

11

بما أنني أستخدم nginx مع proxy_pass لتمرير حركة المرور إلى الحاوية، فهل أنا على صواب في أن هذا يعني أنني أستخدم طريقة الوكيل العكسي (reverse proxy) لتعدد المواقع (multisite)؟

12

نعم. لقد نسيت ذلك!

اجعله يقوم بـ https وإزالة قوالب ssl و let’s encrypt من ملف yml الخاص بك.

13

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.