مرحباً، أحاول تثبيت Discourse على جهاز افتراضي جديد يعمل بنظام Ubuntu 20.04 (جربت أيضًا CentOS Stream 9 و Ubuntu 22.04 و openSUSE MicroOS). لدي بعض الخبرة مع Discourse منذ الأيام الأولى للمشروع، وأقوم الآن بتقييمه لعملية ترحيل. في هذه الحالة، سيكون إلى mydomain.tld (النطاق الإنتاجي هو مجرد منتدى ويحتوي على “منتدى” في اسمه وهو معروف بذلك، لذلك بالتأكيد لا أريد discourse.mydomain.tld). فشلت جميع محاولاتي الأخيرة لتثبيت Discourse بدون نطاق فرعي. أعرف أنه كان من الممكن القيام بذلك لأنني قمت بتشغيل منتدى Discourse بهذه الطريقة منذ حوالي 6 سنوات بدون نطاق فرعي. الآن يبدو أن التثبيت يكتمل بنجاح، لكن الموقع لا يتم تحميله. في Ubuntu، يتم التبديل تلقائيًا إلى https:// حتى عندما أضع http:// صراحةً، ولا يتم تحميله على الإطلاق. وفي CentOS و MicroOS، يتم تحميل صفحة الترحيب Nginx لـ http://، ولا يتم تحميل أي شيء مع https://.
جميع محاولاتي على أنظمة التشغيل المذكورة أعلاه في نفس الجهاز الافتراضي تعمل بشكل جيد عند تثبيت Discourse على نطاق فرعي في discourse.mydomain.tld، بما في ذلك الإعداد التلقائي لـ Let’s Encrypt. على حد علمي، سجلات DNS الخاصة بي صحيحة لدى مسجل النطاق ولدي دقة rDNS مناسبة. يظهر اسم مضيف الخادم في /etc/hosts على أنه 127.0.1.1 mydomain.tld mydomain وينجح البرنامج النصي discourse-install في فحص دقة اسم النطاق.
إليك مخرجات discourse-doctor، ولدي أيضًا سجل discourse-install الكامل إذا أراد أي شخص ذلك:
DISCOURSE DOCTOR Sun Oct 9 13:32:47 UTC 2022
OS: Linux mydomain 5.4.0-125-generic #141-Ubuntu SMP Wed Aug 10 13:42:03 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
Found containers/app.yml
==================== YML SETTINGS ====================
DISCOURSE_HOSTNAME=mydomain.tld
SMTP_ADDRESS=mail.mydomain.tld
DEVELOPER_EMAILS=REDACTED
SMTP_PASSWORD=REDACTED
SMTP_PORT=587
SMTP_USER_NAME=admin@mydomain.tld
LETSENCRYPT_ACCOUNT_EMAIL=REDACTED
==================== DOCKER INFO ====================
DOCKER VERSION: Docker version 20.10.12, build 20.10.12-0ubuntu2~20.04.1
DOCKER PROCESSES (docker ps -a)
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
d6f7f53a81db local_discourse/app \"/sbin/boot\" 10 minutes ago Up 4 minutes 0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp app
Discourse container app is running
==================== PLUGINS ====================
- git clone https://github.com/discourse/docker_manager.git
No non-official plugins detected.
See https://github.com/discourse/discourse/blob/main/lib/plugin/metadata.rb for the official list.
========================================
Discourse version at mydomain.tld: NOT FOUND
Discourse version at localhost: NOT FOUND
==================== MEMORY INFORMATION ====================
OS: Linux
RAM (MB): 2029
total used free shared buff/cache available
Mem: 1935 823 547 30 564 934
Swap: 2047 0 2047
==================== DISK SPACE CHECK ====================
---------- OS Disk Space ----------
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 38G 8.0G 28G 23% /
==================== DISK INFORMATION ====================
Disk /dev/sda: 38.15 GiB, 40961572864 bytes, 80003072 sectors
Disk model: QEMU HARDDISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 6643DB1B-E542-4DE1-A04C-C8EB4DAAD77E
Device Start End Sectors Size Type
/dev/sda1 528384 80003038 79474655 37.9G Linux filesystem
/dev/sda14 2048 4095 2048 1M BIOS boot
/dev/sda15 4096 528383 524288 256M EFI System
Partition table entries are not in disk order.
==================== END DISK INFORMATION ====================
==================== MAIL TEST ====================
For a robust test, get an address from http://www.mail-tester.com/
Mail test skipped.
==================== DONE! ====================
مرحباً، شكراً على الرد. حسناً، هذه فكرة جيدة، يبدو أنها لا تقبل الاتصال:
$ curl -v mydomain.tld
* Trying 1.2.3.4:80...
* connect to 1.2.3.4 port 80 failed: Connection refused
* Failed to connect to mydomain.tld port 80: Connection refused
* Closing connection 0
curl: (7) Failed to connect to mydomain.tld port 80: Connection refused
$ curl -v https://mydomain.tld
* Trying 1.2.3.4:443...
* connect to 1.2.3.4 port 443 failed: Connection refused
* Failed to connect to mydomain.tld port 443: Connection refused
* Closing connection 0
curl: (7) Failed to connect to mydomain.tld port 443: Connection refused
هل من الممكن أن يكون ذلك بسبب قيود في منطق إعداد Discourse حيث يتوقع أن يكون .tld شيئاً شائعاً مثل .com أو .org؟ لدي فقط نطاق $5 من نوع .tech أنشأته للاختبار.
من غير المرجح.\n\nأين يتم استضافة الخادم؟ ما الذي يقع بينه وبين العميل؟\n\nإن تزويدنا بالاسم المؤهل بالكامل (FQDN) يساعدنا في إجراء بعض استكشاف الأخطاء وإصلاحها. كما هو الحال، تطلب منا المساعدة في تشخيص هذا الأمر أثناء تغطية أعيننا، لذلك قد يستغرق الأمر بعض الوقت لتحديد المشكلة.
لقد استخدمت discourse-setup. نعم، المنافذ مفتوحة. التثبيت على نطاق فرعي يعمل بشكل جيد، وقمت أيضًا بإعداد تثبيت Docker لخادم بريد بواجهة ويب على نفس الجهاز الظاهري هذا (ولكنني قمت بإعادة تنسيقه لاحقًا).
لا أتذكر أنها عملت مع النطاق الوحيد الذي كان لدي في Hover، ولكن هذا كان منذ فترة.\n\nيمكنك محاولة تبديل سجلات اسم الخادم (NS) إلى CloudFlare واختبار ما إذا كانت مشكلة DNS من هناك مجانًا.
ما يمكنك فعله هو محاولة استخدام سجل Glue. سيجعل هذا خادمك هو مدير DNS ويوجه اسم النطاق إلى خادم أسماء يمكنك إعداده باستخدام سجلات Glue. أساسًا، يصبح خادمك هو خادم الأسماء
لا، أعني أنك لست بحاجة إلى نقل نطاقك بين المسجلين، ولكنك ستحتاج إلى تحديث سجلات NS في Hover لجعل نطاقك يشير إلى مزود DNS مختلف لاختبار هذه النظرية. حاليًا، تم تعيينها على ns1.hover.com و ns2.hover.com
إنها عملية سريعة وغير مؤلمة إلى حد ما. إذا قمت بالتسجيل في CloudFlare ثم حاولت إضافة النطاق هناك، فسوف يمنحونك خادمين جديدين للأسماء يجب إدخالهما في Hover. يوجد دليل للجانب الخاص بـ Hover هنا:
لقد مر وقت طويل منذ أن استخدمت القمة مع أي شيء آخر غير CloudFlare. سأختبر هذا بنفسي قريبًا لمعرفة ما إذا كان بإمكاني اكتشاف أي مشاكل أخرى. تنطبق معظم المشكلات المتعلقة بالقمة على cnames، ولكن يمكنني الآن رؤية أنك تستخدم سجل a.
في الوقت الحالي، قمت بتعطيل SSL في app.yml وأعدت البناء، وأصبح Discourse يعمل الآن على المنفذ 80 بدون نطاق فرعي.
أنا الآن أستخدم أيضًا Hetzner DNS كسلطة. لست متأكدًا مما إذا كان هذا هو ما أحدث الفرق أم أنها كانت مشكلة شهادة Let’s Encrypt الفاشلة. سأبلغ مرة أخرى بعد إعادة بناء أخرى بمجرد أن أتمكن من إنشاء شهادات Let’s Encrypt مرة أخرى وإعادة تمكين SSL.
إذا كنت قد حاولت إعادة البناء أكثر من مرتين، فمن المحتمل أن تكون قد وصلت إلى حد الطلبات من letsencrypt. يمكنك التحايل على هذا عن طريق إضافة اسم مضيف آخر إلى شهادتك.
شكراً للجميع على ردودهم السريعة. يبدو أن الأمر كان مجرد مسألة حد Let’s Encrypt للمعدل. لقد أنشأت نطاقًا جديدًا على Hover وهذه المرة نجح تثبيت Discourse بشكل جيد بدون نطاق فرعي.
مرحباً مرة أخرى @pfaffman أو أي شخص آخر، سؤال غبي: هل يتم تحديث شهادة Let’s Encrypt في كل مرة أقوم فيها بتشغيل ./launcher rebuild app؟ بمعنى آخر، هل سأواجه أي قيود إضافية إذا قمت ببعض التجربة والخطأ وأعدت بناء (ولكن لم أبدأ من الصفر تمامًا) مثيل Discourse الخاص بي عدة مرات متتالية؟ شكراً جزيلاً.