by exposing some port of the container and telling the outer NGINX to forward traffic for discourse to that port (as suggested here and here).
Since the how-to here on meta uses the socket method, I suppose that is the preferred method. But what exactly are the benefits compared to the port-method?
I can’t seem to get the the socket version to work even though I followed the instructions here. I just get ERR_CONNECTION_REFUSED when trying to access the discourse subdomain. Other webpages served by the same NGINX are working fine.
UNIX sockets (as opposed to TCP sockets) are faster and more efficient, and less prone to accidental disclosure to places you don’t want connections coming from. A misconfiguration can potentially cause a listening TCP socket to be exposed to the Internet, whereas there’s absolutely no way you can make a mistake such that a UNIX socket is exposed directly to the Internet.
OK, so I’ll continue trying the UNIX socket. What would be some steps for trouble shooting why a UNIX socket is not working? (I already have the default_server listening on port 81 for the time being, just to have it out of the way)
I already tried both with and without the extra colon. But good to know that it should definitely be without the colon. Regarding rebuild: this is the config for the outer NGINX, so I don’t see why a rebuilt would be necessary. Or did I miss something? Or do you mean restart the NGINX?
I am on http for the moment, just to avoid any additional sources of error. This is my discourse.conf:
ls -al /var/discourse/shared/standalone/nginx.http.sock gives me srw-rw-rw- 1 root root 0 Mar 29 02:53 /var/discourse/shared/standalone/nginx.http.sock
sudo updatedb && locate nginx.http.sockgives me (after quite a bit of delay) /var/discourse/shared/standalone/nginx.http.sock
Yes, the error is on a client machine. Okay, then I suspect the problem is with my /etc/nginx/sites-available/default. For the time being I set it to listen to port 81:
In my mind, this should imply that /etc/nginx/sites-available/default will not interfere with the settings in discourse.conf and indeed: if I change the defauklt server to port 80, I get the BGINX welcome page instead of ERR_CONNECTION_REFUSED.
So maybe my discourse.conf is simply not being included in the nginx.conf? That would also explain why NGINX din’t complain about the extra }… And indeed, I had my discourse.conf in the wrong path (sites-available instead of sites-enabled).
But when I fixed that, I saw the NGINX welcome page even when calling test.mydomain.net. So, for lack of other ideas, I tried starting the conainer but uit said it was already started. So I stopped and re-started it and now I’m getting 502 bad gateway.
So I did a cleanup based on this suggestion (plus a stop and restart of the container) and tada it is finally working.
So, to draw some lessons from this that might be useful for others: what puzzles me is how exactly the container interacts with the outer NGINX. As I indicated earlier, I was assuming that they are two separate entities that are merely linked in that they are sending packets back and forth between them. In other words: changes in the NGINX-configuration will not affect the container at all, as long as those packets are still sent back and forth. But now it looks like the container “fixed itself” after I fixed the outer NGINX?!?
Or maybe this is just a combination of several independent issues? In other words: if I had done a container cleanup earlier, and then fixed the outer NGINX, the result would have been the same?
@tophee@Lutz من فضلكما أعطيني بعض النصائح، شكرًا
لدي 3 مواقع متعددة قيد التشغيل، وكل منها يعطل HTTPS ويشغل nginx فوق المضيف. ملف nginx.conf يشبه هذا. الرابط يعطي خطأ 522.
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
lua_shared_dict ssl_certs_cache 1m;
init_by_lua_block {
-- تعريف دالة لتحديد نطاقات SNI التي سيتم التعامل معها تلقائيًا
-- وتسجيل شهادات جديدة لها. الافتراضي عدم السماح بأي نطاق، لذا يجب تكوين ذلك.
function allow_domain(domain)
if domain:find("antivte.com$") then
return true
end
return false
end
-- تهيئة مثيل خادم الشهادات الخلفي.
cert_server = (require "resty.ssl-cert-server").new({
backend = '127.0.0.1:8999',
allow_domain = allow_domain
})
}
# خادم HTTPS
server {
listen 443 ssl;
# يعمل أيضًا مع منفذ HTTPS غير الافتراضي.
listen 8443 ssl;
server_name bbs.antivte.com; # <-- غيّر هذا
# معالج ديناميكي لإصدار أو إرجاع الشهادات لنطاقات SNI.
ssl_certificate_by_lua_block {
cert_server:ssl_certificate()
}
# شهادة احتياطية مطلوبة من nginx، والشهادة الموقعة ذاتيًا مقبولة.
# openssl req -new -newkey rsa:2048 -days 3650 -nodes -x509 \
# -subj '/CN=sni-support-required-for-valid-ssl' \
# -keyout /etc/nginx/certs/fallback-self-signed.key \
# -out /etc/nginx/certs/fallback-self-signed.crt
ssl_certificate /etc/nginx/certs/fallback-self-signed.crt;
ssl_certificate_key /etc/nginx/certs/fallback-self-signed.key;
location / {
proxy_pass http://unix:/var/discourse/shared/bbs/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;
}
}
# خادم HTTP
server {
listen 80;
server_name bbs.antivte.com; # <-- غيّر هذا
return 301 https://$host$request_uri;
# نقطة النهاية المستخدمة لإجراء التحقق من النطاق مع Let's Encrypt.
location /.well-known/acme-challenge/ {
content_by_lua_block {
cert_server:challenge_server()
}
}
}
# خادم HTTPS
server {
listen 443 ssl;
# يعمل أيضًا مع منفذ HTTPS غير الافتراضي.
listen 8443 ssl;
server_name ytb.antivte.com; # <-- غيّر هذا
# معالج ديناميكي لإصدار أو إرجاع الشهادات لنطاقات SNI.
ssl_certificate_by_lua_block {
cert_server:ssl_certificate()
}
# شهادة احتياطية مطلوبة من nginx، والشهادة الموقعة ذاتيًا مقبولة.
# openssl req -new -newkey rsa:2048 -days 3650 -nodes -x509 \
# -subj '/CN=sni-support-required-for-valid-ssl' \
# -keyout /etc/nginx/certs/fallback-self-signed.key \
# -out /etc/nginx/certs/fallback-self-signed.crt
ssl_certificate /etc/nginx/certs/fallback-self-signed.crt;
ssl_certificate_key /etc/nginx/certs/fallback-self-signed.key;
location / {
proxy_pass http://unix:/var/discourse/shared/ytb/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;
}
}
# خادم HTTP
server {
listen 80;
server_name ytb.antivte.com; # <-- غيّر هذا
return 301 https://$host$request_uri;
# نقطة النهاية المستخدمة لإجراء التحقق من النطاق مع Let's Encrypt.
location /.well-known/acme-challenge/ {
content_by_lua_block {
cert_server:challenge_server()
}
}
}
# خادم HTTPS
server {
listen 443 ssl;
# يعمل أيضًا مع منفذ HTTPS غير الافتراضي.
listen 8443 ssl;
server_name cp.antivte.com; # <-- غيّر هذا
# معالج ديناميكي لإصدار أو إرجاع الشهادات لنطاقات SNI.
ssl_certificate_by_lua_block {
cert_server:ssl_certificate()
}
# شهادة احتياطية مطلوبة من nginx، والشهادة الموقعة ذاتيًا مقبولة.
# openssl req -new -newkey rsa:2048 -days 3650 -nodes -x509 \
# -subj '/CN=sni-support-required-for-valid-ssl' \
# -keyout /etc/nginx/certs/fallback-self-signed.key \
# -out /etc/nginx/certs/fallback-self-signed.crt
ssl_certificate /etc/nginx/certs/fallback-self-signed.crt;
ssl_certificate_key /etc/nginx/certs/fallback-self-signed.key;
location / {
proxy_pass http://unix:/var/discourse/shared/cp/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;
}
}
# خادم HTTP
server {
listen 80;
server_name cp.antivte.com; # <-- غيّر هذا
return 301 https://$host$request_uri;
# نقطة النهاية المستخدمة لإجراء التحقق من النطاق مع Let's Encrypt.
location /.well-known/acme-challenge/ {
content_by_lua_block {
cert_server:challenge_server()
}
}
}
}
عذراً، لا يمكنني مساعدتك في هذا الأمر. أول وآخر مرة (تقريباً) نظرت فيها إلى تفاصيل NGINX كانت قبل ثلاث سنوات، عندما قمت بإعداد منتداي… وليس لدي أي خبرة في المواقع المتعددة على الإطلاق.