مرحبًا، أحصل على الخطأ المذكور في العنوان (انظر أيضًا أدناه) بعد ظهور الرسالة “✓ المنافذ 80 و 443 حرة للاستخدام” أثناء التهيئة. تم إعداد DNS، وتم تكوين SSL، والموقع يعمل من الخارج (جرب ذلك بنفسك)، وتمت إضافة مخرجات curl (مختصرة) أدناه، أي أنه يمكن الوصول إليه من الجهاز نفسه. لقد نفدت من الأفكار حول ما ينقص. شكرًا على أي توضيح.
# ./discourse-setup
→ التحقق من وجود تحديثات لصورة معالج الإعداد...
→ بدء معالج إعداد Discourse...
___ _
| \(_)___ __ ___ _ _ _ _ ___ ___
| |) | (_-\< / _/ _ \ || | '_(_-\< / -_)
|___/|_/__/\__\___/\_,_|_| /__/\___|
معالج الإعداد
→ سيساعدك هذا المعالج في تكوين تثبيت Discourse.
→ اضغط على Ctrl+C في أي وقت للإلغاء.
── فحوصات النظام ──
[1/5] التحقق من متطلبات النظام
✓ جاري التشغيل بصلاحيات الجذر
✓ Docker متاح
✓ الذاكرة: 8 جيجابايت، المعالج: 4 أنوية
── التكوين ──
[2/5] إعداد التكوين
✓ المنافذ 80 و 443 حرة للاستخدام
→ إنشاء تكوين جديد...
→ إنشاء تكوين جديد من القالب...
── إعدادات الموقع ──
[3/5] أدخل تفاصيل موقعك
عنوان البريد الإلكتروني لحسابات المسؤول؟
eduard.pech@logophilia.eu▌
هل لديك اسم نطاق لـ Discourse؟
▸ نعم لا
اسم المضيف لـ Discourse؟
metabolism.logophilia.eu▌
هل تريد تكوين SMTP لإرسال البريد الإلكتروني؟ (يتطلب بيانات اعتماد SMTP)
نعم ▸ لا
── مراجعة التكوين ──
╭────────────────────────────────────────────╮
│ │
│ اسم المضيف metabolism.logophilia.eu │
│ بريد المسؤول eduard.pech@logophilia.eu │
│ SMTP (غير مُكوّن) │
│ Let's Encrypt مفعل │
│ │
╰────────────────────────────────────────────╯
هل يبدو هذا صحيحًا؟
▸ نعم لا
→ تم العثور على 8 جيجابايت من الذاكرة و 4 أنوية معالجة
→ تعيين db_shared_buffers = 2048MB
→ تعيين UNICORN_WORKERS = 8
── التحقق من الشبكة ──
[4/5] التحقق من تكوين النطاق
→ التحقق من اسم نطاقك...
⚠ يبدو أن المنفذ 443 لهذا الجهاز غير قابل للوصول باستخدام اسم المضيف: metabolism.logophilia.eu
⚠ فشل الاتصال بـ http://metabolism.logophilia.eu (المنفذ 80) أيضًا.
يشير هذا إلى أن metabolism.logophilia.eu يحل إلى عنوان IP لا يصل إلى هذه
الآلة التي تقوم فيها بتثبيت Discourse.
أول ما يجب فعله هو التأكد من أن metabolism.logophilia.eu يحل إلى عنوان IP الخاص بهذا الخادم.
عادةً ما يتم ذلك في نفس المكان الذي اشتريت فيه النطاق.
إذا كنت متأكدًا من أن عنوان IP يُحل بشكل صحيح، فقد تكون المشكلة متعلقة بجدار الحماية.
قد يساعد البحث في الويب عن "فتح المنافذ خادع السحابي الخاص بك".
هذه الأداة مصممة فقط لأبسط التثبيتات القياسية. إذا لم تتمكن من حل
المشكلة المذكورة أعلاه، فستحتاج إلى تحرير containers/app.yml بنفسك ثم كتابة:
./launcher rebuild app
✗ فشل التحقق من DNS لـ metabolism.logophilia.eu
[root@logophilia discourse]# dig metabolism.logophilia.eu
; <<< DiG 9.18.33 <<< metabolism.logophilia.eu
;; الخيارات العامة: +cmd
;; تم الحصول على الإجابة:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36726
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; قسم OPT PSEUDOSECTION:
; EDNS: الإصدار: 0, flags:; udp: 512
;; قسم السؤال:
;metabolism.logophilia.eu. IN A
;; قسم الإجابة:
metabolism.logophilia.eu. 300 IN A 75.119.134.68
;; وقت الاستعلام: 8 مللي ثانية
;; الخادم: 213.136.95.10#53(213.136.95.10) (UDP)
;; الوقت: Sat Jun 06 04:52:23 CEST 2026
;; حجم الرسالة المستلمة: 69
[root@logophilia discourse]# curl -v https://metabolism.logophilia.eu
* تم حل Host metabolism.logophilia.eu:443.
* IPv6: (لا يوجد)
* IPv4: 75.119.134.68
* جاري المحاولة 75.119.134.68:443...
* ALPN: curl يعرض h2,http/1.1
* TLSv1.3 (خارجي)، مصافحة TLS، ترحيب العميل (1):
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
* CApath: لا يوجد
* TLSv1.3 (داخلي)، مصافحة TLS، ترحيب الخادم (2):
* TLSv1.3 (داخلي)، TLS تغيير التشفير، تغيير مواصفات التشفير (1):
* TLSv1.3 (داخلي)، مصافحة TLS، امتدادات مشفرة (8):
* TLSv1.3 (داخلي)، مصافحة TLS، شهادة (11):
* TLSv1.3 (داخلي)، مصافحة TLS، التحقق من الشهادة (15):
* TLSv1.3 (داخلي)، مصافحة TLS، انتهى (20):
* TLSv1.3 (خارجي)، TLS تغيير التشفير، تغيير مواصفات التشفير (1):
* TLSv1.3 (خارجي)، مصافحة TLS، انتهى (20):
* اتصال SSL باستخدام TLSv1.3 / TLS_AES_256_GCM_SHA384 / x25519 / RSASSA-PSS
* ALPN: الخادم قبل http/1.1
* شهادة الخادم:
* الموضوع: CN=metabolism.logophilia.eu
* تاريخ البدء: Jun 6 00:26:43 2026 GMT
* تاريخ الانتهاء: Sep 4 00:26:42 2026 GMT
* subjectAltName: تطابق المضيف "metabolism.logophilia.eu" مع الشهادة "metabolism.logophilia.eu"
* المصدّر: C=US; O=Let's Encrypt; CN=YR2
* التحقق من شهادة SSL ناجح.
* مستوى الشهادة 0: نوع المفتاح العام RSA (2048/112 Bits/secBits)، مُوقّع باستخدام sha256WithRSAEncryption
* مستوى الشهادة 1: نوع المفتاح العام RSA (2048/112 Bits/secBits)، مُوقّع باستخدام sha256WithRSAEncryption
* مستوى الشهادة 2: نوع المفتاح العام RSA (4096/152 Bits/secBits)، مُوقّع باستخدام sha256WithRSAEncryption
* مستوى الشهادة 3: نوع المفتاح العام RSA (4096/152 Bits/secBits)، مُوقّع باستخدام sha256WithRSAEncryption
* متصل بـ metabolism.logophilia.eu (75.119.134.68) المنفذ 443
* باستخدام HTTP/1.x
> GET / HTTP/1.1
> Host: metabolism.logophilia.eu
> User-Agent: curl/8.12.1
> Accept: */*
>
* تم إرسال الطلب بالكامل
* TLSv1.3 (داخلي)، مصافحة TLS، تذكرة الجلسة الجديدة (4):
* TLSv1.3 (داخلي)، مصافحة TLS، تذكرة الجلسة الجديدة (4):
< HTTP/1.1 200 OK
< Date: Sat, 06 Jun 2026 02:52:36 GMT
< Server: Apache
< Last-Modified: Sat, 06 Jun 2026 01:25:19 GMT
< ETag: "1325f-6538ba67ff892"
< Accept-Ranges: bytes
< Content-Length: 78431
< Content-Type: text/html; charset=UTF-8
<
<!doctype html>
<html lang="en" data-bs-theme="auto">
<head>
<title>
metabolism.logophilia.eu — صفحة ترحيب النطاق لـ </title>
<meta charset="utf-8">
……
لقد تفحصت موقعك الإلكتروني بنفسي. يبدو أن موفر الاستضافة الخاص بك يحتجز المنفذ 443 لعرض صفحة الترحيب هذه. ستحتاج إلى معرفة كيفية تحرير المنفذ 443/80 بالكامل تمامًا حتى يتمكن Discourse من التحكم فيه.
لقد قمت بذلك بالفعل، فالخادم الافتراضي الخاص (VPS) مُدار عبر Virtualmin، والأمر مجرد خانة اختيار. للأسف، عند إلغاء تحديد خيار “تمكين الموقع الإلكتروني”، لا يمكنني استخدام أمر curl للوصول إلى المنفذ 443 أو 80 من المضيف، ولا يزال إعداد Discourse يشتكي بنفس الخطأ. لذا فكرت في إعادة تمكين الموقع الإلكتروني، على الأقل لأظهر أن مصافحة SSL تعمل.
وكما تلاحظ في منشوري الأصلي، فإن إعداد Discourse يدعي في الواقع (في البداية) أن المنفذ 443 متاح. هذه أول عملية تثبيت لي، وسأفسر ذلك على النحو التالي: كل شيء أخضر. إذن لماذا يغير الإعداد “رأيه”؟
ومع ذلك، لا أحتاج حقًا إلى فهم كل تفصيلة. فقط لأقول: عند تعطيل Apache على النطاق الفرعي، تكون نتيجة إعداد Discourse هي نفسها.
شكرًا لك على تخصيص الوقت. إذا كان هناك أي شيء آخر يمكنني تقديمه للتوضيح، فسأفعل (تقريبًا) أي شيء.
النص تجاوز تقييم 5/5 الآن، ويبدو أنه يقوم برفع وتثبيت العديد من العناصر الإضافية. شهادة SSL غير صحيحة حاليًا، وأظن أنها في انتظار انتهاء مهلة TTL، أو ربما ستعمل بشكل صحيح بمجرد انتهاء الإعداد.
في حين أنني لا أعرف شيئًا تقريبًا عن Discourse أو Docker أو حتى Ruby… إلا أن جانب DNS لا يشكل أي مشكلة أبدًا شكرًا مرة أخرى!
لذلك ظننت أن صورة Docker تأتي مع Postgres مُثبّتًا مسبقًا. هل يمكنك التوضيح ما إذا كنت بحاجة إلى تثبيت Postgres على الخادم الافتراضي (VPS)؟ لأن تعليمات التثبيت لا تذكر ذلك.
… أو ربما أن Docker يأتي مع Postgres، لكن السكربت فشل بطريقة ما؟ لأنه يتوقف في النهاية:
........
I, [2026-06-06T04:23:49.114769 #1] INFO -- : File > /etc/runit/1.d/install-ssl chmod: +x chown:
I, [2026-06-06T04:23:49.114999 #1] INFO -- : Replacing # after ssl with if [ -z "$DISABLE_LETSENCRYPT" ] || [ -n "$ENABLE_LETSENCRYPT" ]; then
/usr/local/bin/configure-ssl
exec /usr/local/bin/configure-letsencrypt
fi
# after ssl in /etc/runit/1.d/install-ssl
I, [2026-06-06T04:23:49.125964 #1] INFO -- : File > /usr/local/bin/configure-ssl chmod: +x chown:
I, [2026-06-06T04:23:49.127031 #1] INFO -- : > curl https://raw.githubusercontent.com/acmesh-official/acme.sh/3.0.6/acme.sh > /opt/acme.sh
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 215k 100 215k 0 0 635k 0 --:--:-- --:--:-- --:--:-- 637k
I, [2026-06-06T04:23:49.514883 #1] INFO -- : > chmod +x /opt/acme.sh
I, [2026-06-06T04:23:49.554670 #1] INFO -- : File > /usr/local/bin/configure-letsencrypt chmod: +x chown:
I, [2026-06-06T04:23:49.596808 #1] INFO -- : File > /usr/local/bin/letsencrypt chmod: +x chown:
I, [2026-06-06T04:23:49.598926 #1] INFO -- : > echo "Beginning of custom commands"
Beginning of custom commands
I, [2026-06-06T04:23:49.605809 #1] INFO -- : > echo "End of custom commands"
End of custom commands
I, [2026-06-06T04:23:49.608842 #1] INFO -- : Terminating async processes
I, [2026-06-06T04:23:49.609015 #1] INFO -- : Sending INT to HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/15/bin/postmaster -D /etc/postgresql/15/main pid: 44
I, [2026-06-06T04:23:49.609157 #1] INFO -- : Sending TERM to exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 111
2026-06-06 04:23:49.609 UTC [44] LOG: received fast shutdown request
111:signal-handler (1780719829) Received SIGTERM scheduling shutdown...
2026-06-06 04:23:49.612 UTC [44] LOG: aborting any active transactions
2026-06-06 04:23:49.619 UTC [44] LOG: background worker "logical replication launcher" (PID 58) exited with exit code 1
2026-06-06 04:23:49.623 UTC [53] LOG: shutting down
2026-06-06 04:23:49.634 UTC [53] LOG: checkpoint starting: shutdown immediate
111:M 06 Jun 2026 04:23:49.683 * User requested shutdown...
111:M 06 Jun 2026 04:23:49.683 * Saving the final RDB snapshot before exiting.
111:M 06 Jun 2026 04:23:49.698 * DB saved on disk
111:M 06 Jun 2026 04:23:49.700 # Redis is now ready to exit, bye bye...
2026-06-06 04:23:49.711 UTC [53] LOG: checkpoint complete: wrote 87 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.041 s, sync=0.022 s, total=0.088 s; sync files=52, longest=0.008 s, average=0.001 s; distance=86 kB, estimate=86 kB
2026-06-06 04:23:49.735 UTC [44] LOG: database system is shut down
هذا متوقع، لأنك لم تقم بتثبيت Discourse ليكون خادم الويب.
إذن، من المرجح جدًا أن لديك المشكلة نفسها، وهي أن البوابات (Ports) للآلة الافتراضية (VM) الخاصة بك غير مكشوفة على الإنترنت.
لا، لا يدعي ذلك. إنه يذكر بوضوح أن Discourse لا يملك صلاحية الوصول إلى المنفذ. كما أن أمر curl الخاص بك يُظهر أن شيئًا آخر يتحكم في المنفذ 443.
أعتقد أن الحاوية (Container) بنيت بنجاح، لكن إما أنها لا تستطيع البدء لأن شيئًا آخر يستحوذ على المنفذ 443، أو أنها لا تقوم بأي شيء لأن المنفذ 443 يُوجَّه إلى مكان آخر.
في الواقع، النص يقول في البداية “متاحة للاستخدام”. مع ذلك، لقد نجحت في تشغيل مثيلتي الآن بمساعدة Gemini (معظمها يتعلق باستخدام Docker، طبعًا lol). أود أن أقدم “دليل التشغيل” الخاص بي لأي مستخدمين آخرين لـ Virtualmin، لأن: “تحرير المنفذ 443” ليس الحل هنا. باقي منشوري سيكون هذا الدليل، وإذا كان من الأفضل نشره في مكان آخر، مثل موضوع جديد، فالرجاء إخباري بالأفضل؛ أعتقد أنني لست الوحيد الذي لديه هذا الإعداد، وقد يكون مفيدًا للآخرين. شكرًا مجددًا!
إذا كنت تستخدم خادمًا افتراضيًا خاصًا (VPS) يُدار بواسطة Webmin/Virtualmin، وتستخدم نطاقًا فرعيًا:
دليل التشغيل الحاسم لـ Virtualmin + Discourse *
(1) تنظيف البقايا (في حال إعادة المحاولة، كما فعلتُ):
يجب حذف سطور templates/web.ssl.template.yml وtemplates/web.letsencrypt.ssl.template.yml تمامًا من ملف app.yml. فمُحلّل التشغيل المخصص سيقوم بتقييمها حتى لو سبقت بعلامة #.
(3) إعداد البريد الإلكتروني والمتغيرات:
غيّر DISCOURSE_SKIP_EMAIL_SETUP من '1' إلى '0'، لأن Discourse لن يتمكن من الاتصال والتحقق من DiscordID؛
أضف DISCOURSE_FORCE_HTTPS: true لكي يولد الخادم الخلفي عناوين URL آمنة.
تذكير ودي: تأكد من تعيين DISCOURSE_SMTP_USER_NAME إلى اسم حساب البريد الإلكتروني الخام (مثل 'logophilia')، وليس عنوان البريد الإلكتروني الكامل (مثل 'logophilia@logophilia.eu')، وأحط بيانات الاعتماد بعلامات اقتباس مفردة (') لتجاوز أخطاء تحليل أحرف YAML المحتملة.
(4) إعداد كتلة expose:
تأكد من أن كتلة expose: في ملف app.yml تحتوي على تعيين HTTP؛ فالتعيين 443=>8443 اختياري/مُكرر، لأن Virtualmin ينهي منطق SSL قبل تمريره:
expose:
- 8080:80
يمكنك الآن البدء بإعادة البناء:
cd /var/discourse
./launcher rebuild app
(5) إعداد النطاق الفرعي ومسار الوكيل (Proxy):
أنشئ نطاقك الفرعي في Virtualmin كالمعتاد، وحمّيه بشهادة SSL من Let’s Encrypt (يتم ذلك تلقائيًا، فقط تأكد من عدم حدوث أخطاء لأي سبب غير ذي صلة).
انتقل إلى مسارات الوكيل (Virtualmin → نطاقك الفرعي → إعدادات الويب → مسارات الوكيل)، أنشئ تعيينًا جديدًا من / إلى http://localhost:8080/، اترك خيار “الخدمة محليًا” غير محدّد، لكن فعل Proxy WebSocket على نعم للسماح بالتحديثات الفورية وتدفقات الإشعارات.
(6) تعليمات رأس CSRF:
في Webmin ➔ خوادم ➔ خادم الويب Apache ➔ [ابحث عن إعدادات نطاقك الفرعي هنا وانقر على إعدادات 443] ➔ تحرير التعليمات، ضع السطور التالية فوق كتلة الوكيل الخاصة بـ Virtualmin الخاصة بـ Let’s Encrypt (عادةً “ProxyPass /.well-known !”) لتسهيل نقل رموز CSRF:
ProxyPreserveHost On
RequestHeader set X-Forwarded-Proto "https"
RequestHeader set X-Forwarded-For %{REMOTE_ADDR}s
ProxyPreserveHost On: يخبر Discourse باسم النطاق الفعلي بدلاً من “localhost”. RequestHeader set X-Forwarded-Proto "https": يخبر Discourse صراحةً أن المستخدم يستخدم اتصالاً آمنًا، مما يتوافق مع إعداد DISCOURSE_FORCE_HTTPS: true. RequestHeader set X-Forwarded-For: ينقل عنوان IP الفعلي للزائر إلى الحاوية لكي تعمل سجلات الأمان.
(7) المصافحة النظيفة للحاوية:
أثناء اكتمال عملية إعادة البناء الطويلة (آسف… لكن هذا صحيح بالفعل؛-)، تأكد من مسح أي مخطط حاوية عالق محتمل باستخدام docker rm -f app حتى يقوم تشغيل ./launcher start app بتشغيل مثيل جديد تمامًا مرتبط بالمنفذ 8080. تحقق من أن أمر docker ps يظهر شيئًا تحت “المنافذ” مشابهًا لـ:
# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
d21772a21e36 local_discourse/app "/sbin/boot" 45 minutes ago Up 45 minutes 0.0.0.0:8080->80/tcp, [::]:8080->80/tcp, 0.0.0.0:8443->443/tcp, [::]:8443->443/tcp app
(كما ترون، تركتُ تعليمات 443=>8443 في ملف app.yml الخاص بي، وتعمل في كلا الحالتين.)
(8) المراقبة والإطلاق:
تابع تدفق التشغيل بـ docker logs -f app حتى تنتهي عمليات ترحيل قاعدة البيانات ويبدأ العمال في معالجة الطلبات. ببساطة، ستظهر مجموعة من سطور “INFO” بسرعة.
(9) الإنهاء:
افتح نطاقك الفرعي في متصفح، انقر على تسجيل، واترك النظام يرسل بريدًا إلكترونيًا للتحقق إلى صندوق بريدك.
شكرًا مرة أخرى!