אין חיבור מאובטח ל-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 (ככל הנראה זו בעיה עם קובצי Cookie מאובטחים בלבד). הפעלה מחדש של ה-launcher ו-discourse-doctor אינם עוזרים. הפעלה מחדש של nginx בתוך הקונטיינר גם אינה עוזרת. לאן להסתכל עכשיו ומה לעשות?

2 לייקים
2

it will do if ufw is enabled and not set-up to allow connections on https port 443

Edit: you’ll need this port to be open for mail-receiver to work properly

3

לא עשיתי כלום עם תצורת ufw, iptables וכו’. היציאה נפתחה בדיוק לפני העדכון. האם התצורה יכולה להשתנות עם תהליך העדכון של Discourse?

4

it absolutely could, Discourse docker container should step in front of ufw. However, not have prt 443 open causes issues in cross-talk between different containers or issue with telnet

what deos .\launcher logs app return? (you can use MS word to redact your domain name, etc.)

do you access your server through PuTTy or another SSH client? opening port 22 ?

5

I am also seeing this issue on a self-hosted instance after a recent rebuild. No changes in configuration except the rebuild itself. I can access the server through SSH and this is the output of ./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 container is running as evidenced by my output from docker ps. (container id redacted)

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

An important note to highlight, we don’t use openSSL for our certs, due to requiring a specific issuer. However, this cert has not changed and was working fine before the rebuild.

There seems to be a mismatch between the IP nginx expects (local IP) and the one found assigned to the container. Looks like the container may be running in bridge mode? Here are the network settings from the container.

"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
        }
    }
}
CONNECTION REFUSED on self-hosted instance after rebuild
6

נראה שיש PR חדש שהכניס דרישת משתנה חדשה לקובץ app.yml. זה עדיין לא נראה מתועד, אך עליך להוסיף ENABLE_SSL: true לקובץ app.yml שלך.

7

That sounds like a bug. Ssl has been on by default for some years. Can you link to the commit?

I see it in the code in the ssl template. I may be missing something since I’m in my phone and github is having issues, but it looks like it’ll break every self hosted site.

לייק 1
8

It’s this one here, definitely an unintended bug with merging the ssl-on-boot configuration:

I’ve updated the ENABLE_SSL to be 1 by default here:

Thanks for the catch @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.