مرحبًا بك في nginx! بعد التثبيت الجديد

الدعم تثبيت
1

مرحبًا،

أنا جديد في Discourse وتعثرت أثناء التثبيت. قمت بإنشاء آلة افتراضية بنظام Ubuntu Server 18.04، ثم اتبعت إرشادات التثبيت تقريبًا.

عندما أقول “تقريبًا”، أعني أنني لم أستخدم خادمًا سحابيًا، بل استخدمت Ubuntu Server. لم أقم بتثبيت Docker يدويًا، بل تركت أداة discourse-setup تقوم بتثبيته لي. أيضًا، لم أقوم بإعداد خادم بريد بعد، رغم أنني قدمت إجابات معقولة خلال عملية الإعداد. لست متأكدًا مما إذا كان هذا هو العائق الرئيسي هنا. تم إعداد DNS بالكامل، ولدى الخمان عنوان IP ثابت.

بعد عملية التمهيد، عندما أتصفح إلى الاسم الكامل للمجال (FQDN) للخادم، أرى صفحة “مرحبًا بك في nginx!” بدلاً من صفحة “تهانينا، لقد قمت بتثبيت Discourse!”.

هذا التثبيت مخصص لبيئة مختبرية ولن يكون متاحًا للعامة.

مارك.

2

هل تم تثبيت nginx على الخادم؟ لا ينبغي أن يكون كذلك. لكن discourse-setup كان ينبغي أن يكتشف ذلك. هل أنت متأكد من صحة إعدادات DNS لديك؟

3

لم يتم تثبيت Nginx على الخادم. فيما يتعلق بـ DNS، لدي سجل A وسجل PTR للخادم. ما هي المتطلبات الأخرى؟

مارك.

4

الطريقة الوحيدة لرؤية تلك الصفحة هي إذا قمت بتوجيه DNS إلى الخادم الخاطئ، أو إذا كان NGINX خارج الحاوية ويشغل المنفذ 80 مما يمنع الحاوية من الاستجابة.

5

إذا قمت بتوجيه متصفح الويب مباشرةً إلى عنوان IP الخاص بالخادم، فستظهر صفحة ترحيب Nginx أيضًا.

عند الاتصال عبر SSH بخادم Ubuntu:
marc@community:~$ locate nginx
/var/discourse/image/base/install-nginx
marc@community:~$

بالإضافة إلى ذلك، وأثناء التواجد على خادم Ubuntu:
sudo find / -iname "*nginx*"
…العديد من الملفات تحت /var/lib/docker/overlay2…
/var/discourse/image/base/install-nginx
/var/discourse/shared/standalone/letsencrypt/deploy/nginx.sh
/var/discourse/shared/standalone/log/var-log/nginx

6

أظهر لنا نتيجة:

lsof -i:80
7

الأمر lsof -i:80 لا يُنتج أي مخرجات.

8

إذن لا يوجد شيء يستمع إلى المنفذ 80؟

إذا كان Docker يستمع إلى :80، وهو ما تحققه أي تثبيت ناجح (ويتطلبه لكي يرى nginx داخل الحاوية أي شيء)، فستظهر لك:

COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
docker-pr 890 root    4u  IPv6 961922      0t0  TCP *:http (LISTEN)

إذا لم يكن nginx مثبتًا خارج الحاوية، ولا يستمع Docker إلى هذا المنفذ، فإن الطريقة الوحيدة لرؤية صفحة الترحيب الخاصة بـ nginx هي وجود خطأ في إعدادات الشبكة.

9

يبدو أنك محق. مخرجات تشغيل nmap على جهاز الكمبيوتر المحمول الخاص بي باتجاه عنوان IP للخادم:

Starting Nmap 7.01 ( https://nmap.org ) at 2020-04-10 23:34 AEST
Nmap scan report for community.aureus-group-sb.com (192.168.12.35)
Host is up (0.0010s latency).
Not shown: 999 closed ports
PORT STATE SERVICE
22/tcp open ssh
MAC Address: 0C:8B:FD:CD:AF:EB (Intel Corporate)

Nmap done: 1 IP address (1 host up) scanned in 1.74 seconds

10

تذكّر: قد تكون مشكلة الشبكة، لكنها لا تقتصر على:

  • سياسة على الآلة الافتراضية تمنع الوصول (ufw أو ما شابه)
  • سياسة على الخادم الافتراضي تمنع الوصول (وضع الشبكة غير مُعدّ بشكل صحيح)
  • سياسة على الشبكة غير مُعدّة بشكل صحيح (قوائم التحكم بالوصول بين الشبكات الفرعية)
  • إعدادات DNS غير صحيحة

لا تُعدّ المشكلة متعلقة بـ Discourse إلا إذا لم تكن أي من الحالات المذكورة أعلاه صحيحة. أنت تتبع التثبيت القياسي، لكن اعترافك بأنك تقوم بالتثبيت في بيئة ليست قياسية بأي حال.

إذا كان بإمكان مؤسستك دفع 5 دولارات شهريًا، فقد يكون من الأرخص من حيث وقتك وضع هذا النظام في السحابة وتقييد جدار حماية خادم VPS السحابي لخدمة الصفحات فقط لبيئتك.

11

في الوقت الحالي، أركز بشكل أساسي على جانب التعلم من إعداد هذا النظام. بمجرد أن أسيطر على ذلك، سننظر بالتأكيد في خيارات الاستضافة.

بشأن جوانب الشبكة التي ذكرتها:

  • ufw غير نشط و iptables قيد التشغيل: لم أقم بإجراء أي تغييرات على تثبيت Ubuntu server الافتراضي.
    ** عند النظر في تكوين iptables، فإن سلسلة الإدخال (input chain) لديها سياسة لقبول جميع الحزم، وكذلك سلسلة الإخراج (output chain). أما سلسلة التوجيه (forward chain) فلها بعض الإشارات المتعلقة بـ Docker (انظر أدناه).
  • بطاقة الشبكة الافتراضية (vNIC) الوحيدة للآلة الافتراضية (VM) مُهيأة في وضع الجسر (Bridged mode) – مما يربطها مباشرة بالشبكة الفعلية.
  • جهاز الكمبيوتر المحمول الذي أعمل منه والآلة الافتراضية (VM) يقعان على نفس الشبكة الفرعية.
  • لست متأكدًا من المتطلبات الدقيقة لـ DNS. حاولت العثور على تلك المواصفات، لكنني لم أستطع العثور على وثيقة حاسمة. ومع ذلك، فيما يتعلق بـ DNS، يمكنني عمل ping للخادم باستخدام الاسم، واسم النطاق الكامل (FQDN)، وعنوان IP. لست متأكدًا مما إذا كان هناك أي شيء آخر يحتاج إلى التوفر فيما يتعلق بـ DNS.
12

ما هي سياسة الشبكة القائمة بين الآلة الافتراضية والعالم الخارجي؟

إذا نجح أمر git pull، وتمكنت من تشغيل discourse-setup، فهل كان هناك أي عائق يمنع الاتصال بـ GitHub لتحميل محتوى الحاوية؟

إذا لم يكن عنوان الخادم قابلاً للوصول، فستفشل شهادة Let’s Encrypt، لذا هل قمت بتعديل ملف YML لتعطيل HTTPS؟

13

يمكن للآلة الافتراضية الاتصال بالإنترنت ولا توجد قيود على وصولها إلى GitHub. أثناء تشغيل discourse-setup، تركت خيار بريد حساب Let’s Encrypt؟ (اضغط Enter لتخطي) [me@example.com]: فارغًا.

لم قمت بتعديل أي ملفات YML.

14

ترك هذا الحقل فارغًا يعني أنك لن تتلقى تنبيهات بشأن مشاكل الشهادات، ولا يمنع الحاوية من محاولة تمكين Let’s Encrypt.

حسنًا، لقد سلطنا الضوء على بعض المشاكل الأكبر، لكنها لا تتعلق بالموضوع الأصلي. لديك nginx في شبكتك في مكان ما يعرض صفحة، ولكن بناءً على اختباراتك على الجهاز الافتراضي، فإنك لا تمتلك nginx مثبتًا ولا يستمع docker.

بمجرد أن تكتشف كيفية حدوث ذلك، ستكون الخطوة التالية هي تكوين ملف YML بشكل صحيح. في الوقت الحالي، تحتاج إلى العثور على مصدر تلك الصفحة.

15

كنت أفكر في نفس الأمر. دعني أقوم ببعض البحث لمعرفة مصدر تلك الصفحة.

16

إليك ما تعلمته. إذا قمت بإيقاف تشغيل الخادم، فلا يمكنني عمل ping له (عنوان IP، الاسم، وFQDN). وعند التصفح إلى عنوان IP، أظهرت صفحة

17

لقد تفحصت الحاوية عبر الأمر docker exec -it <cont.id> /bin/bash وتحققت من مخرجات ps aux. وقد ظهر السطر التالي:

root 2030 0.2 0.0 2160 1328 ? Ss 14:10 0:01 runsv nginx

إذًا يبدو أن nginx يعمل داخل الحاوية، غير أن مخرجات nsenter -t 1446 -n netstat -plnt تُظهر ما يلي:

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 127.0.0.1:3000          0.0.0.0:*               LISTEN      3606/unicorn master 
tcp        0      0 0.0.0.0:5432            0.0.0.0:*               LISTEN      3590/postmaster     
tcp        0      0 0.0.0.0:6379            0.0.0.0:*               LISTEN      3591/redis-server * 
tcp6       0      0 :::5432                 :::*                    LISTEN      3590/postmaster     
tcp6       0      0 :::6379                 :::*                    LISTEN      3591/redis-server *

هل يدل ذلك على أن الحاوية لا تستمع إلى المنفذ 80 والمنفذ 443؟