لا يوجد اتصال آمن بـ Discourse المستضاف ذاتيًا بعد آخر تحديث

تثبيت
1

مرحباً. لقد قمت بتحديث Discourse Image و Discourse قبل بضع ساعات باستخدام ./launcher rebuild app. في العملية، واجهت بعض الأخطاء التي تم إصلاحها عن طريق إزالة خطوط تثبيت الإضافات المهملة من app.yml. لم يتم إجراء أي تغييرات تكوين أخرى. الآن لدي حاوية Docker قيد التشغيل تستمع إلى منافذ TCP 80 و 443، ولكن nginx داخل الحاوية يرفض قبول اتصالات SSL/TLS. يظهر ملف error.log داخل الحاوية عدم وجود أخطاء في الشهادات، ولا يظهر ملف access.log أي طلبات، ويظهر telnet إلى منفذ 443 رفض الاتصال، ويعمل الوصول عبر HTTP على منفذ TCP 80، ولكن لدينا مشاكل في مصادقة SSO (من المحتمل أن تكون مشكلة في ملفات تعريف الارتباط الآمنة فقط). لا يساعد إعادة تشغيل المشغل أو discourse-doctor. كما أن إعادة تشغيل nginx داخل الحاوية لا تساعد. أين يجب أن أنظر الآن وماذا أفعل؟

إعجابَين (2)
2

سيحدث ذلك إذا كان ufw ممكّنًا ولم يتم إعداده للسماح بالاتصالات على منفذ https 443

تعديل: ستحتاج إلى فتح هذا المنفذ لكي يعمل mail-receiver بشكل صحيح

3

لم أفعل شيئًا بتكوين ufw أو iptables أو ما شابه. تم فتح المنفذ بالضبط قبل التحديث. هل يمكن أن يتغير التكوين مع عملية تحديث Discourse؟

4

بالتأكيد يمكن ذلك، يجب أن يوضع حاوية Discourse Docker أمام ufw. ومع ذلك، فإن عدم فتح المنفذ 443 يسبب مشاكل في الاتصال بين الحاويات المختلفة أو مشاكل مع telnet

ماذا يعرض .\launcher logs app؟ (يمكنك استخدام برنامج MS Word لتعديل اسم النطاق الخاص بك، وما إلى ذلك)
هل تصل إلى الخادم الخاص بك عبر PuTTy أو عميل SSH آخر؟ هل تفتح المنفذ 22؟

5

أواجه هذه المشكلة أيضًا في نسخة مستضافة ذاتيًا بعد إعادة بناء حديثة. لم يتم إجراء أي تغييرات في التكوين باستثناء إعادة البناء نفسها. يمكنني الوصول إلى الخادم عبر SSH وهذا هو ناتج ./launcher logs app.


run-parts: executing /etc/runit/1.d/00-ensure-links
run-parts: executing /etc/runit/1.d/00-fix-var-logs
run-parts: executing /etc/runit/1.d/01-cleanup-web-pids
run-parts: executing /etc/runit/1.d/anacron
run-parts: executing /etc/runit/1.d/cleanup-pids
Cleaning stale PID files
run-parts: executing /etc/runit/1.d/copy-env
run-parts: executing /etc/runit/1.d/install-ssl
Started runsvdir, PID is 45
ok: run: redis: (pid 55) 0s
supervisor pid: 53 unicorn pid: 76

حاوية Docker قيد التشغيل كما يتضح من ناتج docker ps. (معرف الحاوية محذوف)

local_discourse/app “/sbin/boot” 16 minutes ago Up 16 minutes 0.0.0.0:80->80/tcp, [::]:80->80/tcp, 0.0.0.0:443->443/tcp, [::]:443->443/tcp, 0.0.0.0:5432->5432/tcp, [::]:5432->5432/tcp app

ملاحظة هامة لتسليط الضوء عليها، نحن لا نستخدم openSSL لشهاداتنا، نظرًا لطلب مُصدر معين. ومع ذلك، لم تتغير هذه الشهادة وكانت تعمل بشكل جيد قبل إعادة البناء.

يبدو أن هناك عدم تطابق بين عنوان IP الذي يتوقعه nginx (عنوان IP المحلي) والعنوان الذي تم تعيينه للحاوية. يبدو أن الحاوية قد تعمل في وضع الجسر؟ إليك إعدادات الشبكة من الحاوية.

"Labels": {
    "org.opencontainers.image.created": "2025-07-25T21:40:36+00:00"
},
"NetworkSettings": {
    "Bridge": "",
    "SandboxID": "[REDACTED]",
    "SandboxKey": "[REDACTED]",
    "Ports": {
        "443/tcp": [
            {
                "HostIp": "0.0.0.0",
                "HostPort": "443"
            },
            {
                "HostIp": "::",
                "HostPort": "443"
            }
        ],
        "5432/tcp": [
            {
                "HostIp": "0.0.0.0",
                "HostPort": "5432"
            },
            {
                "HostIp": "::",
                "HostPort": "5432"
            }
        ],
        "80/tcp": [
            {
                "HostIp": "0.0.0.0",
                "HostPort": "80"
            },
            {
                "HostIp": "::",
                "HostPort": "80"
            }
        ]
    },
    "HairpinMode": false,
    "LinkLocalIPv6Address": "",
    "LinkLocalIPv6PrefixLen": 0,
    "SecondaryIPAddresses": null,
    "SecondaryIPv6Addresses": null,
    "EndpointID": "[REDACTED]",
    "Gateway": "172.17.0.1",
    "GlobalIPv6Address": "",
    "GlobalIPv6PrefixLen": 0,
    "IPAddress": "172.17.0.2",
    "IPPrefixLen": 16,
    "IPv6Gateway": "",
    "MacAddress": "[REDACTED]",
    "Networks": {
        "bridge": {
            "IPAMConfig": null,
            "Links": null,
            "Aliases": null,
            "MacAddress": "[REDACTED]",
            "DriverOpts": null,
            "GwPriority": 0,
            "NetworkID": "[REDACTED]",
            "EndpointID": "[REDACTED]",
            "Gateway": "172.17.0.1",
            "IPAddress": "172.17.0.2",
            "IPPrefixLen": 16,
            "IPv6Gateway": "",
            "GlobalIPv6Address": "",
            "GlobalIPv6PrefixLen": 0,
            "DNSNames": null
        }
    }
}
6

يبدو أن هناك طلب سحب جديد (PR) قد أدخل متطلب متغير جديد إلى ملف app.yml. لم يتم توثيق هذا بعد، ولكنك تحتاج إلى إضافة ENABLE_SSL: true إلى ملف app.yml الخاص بك.

7

يبدو هذا وكأنه خطأ. لقد تم تفعيل SSL افتراضيًا لعدة سنوات. هل يمكنك ربط الالتزام؟

أراه في الكود في قالب SSL. قد أكون أفتقد شيئًا ما نظرًا لأنني على هاتفي ويواجه GitHub مشاكل، ولكنه يبدو أنه سيكسر كل موقع مستضاف ذاتيًا.

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

هذه هي هنا، بالتأكيد خطأ غير مقصود عند دمج إعداد ssl-on-boot:

لقد قمت بتحديث ENABLE_SSL ليكون 1 افتراضيًا هنا:

شكراً على اكتشاف @tanya_byrne

3 إعجابات
9

حفظ جيد يا جيف! شكراً!

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

شكرا على الإصلاح @featheredtoast

إعجابَين (2)
11

شكراً لكم يا رفاق. لقد قمنا بحل المشكلة أيضاً.

إعجابَين (2)
12

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