إعادة تشغيل VM؛ الآن صفحة `/admin/upgrade` لا تُحمّل، طلبات JS تفشل، وبعض صور الأفاتار تُرجع 404.

معلومات الخلفية: الموقع هو lot.almost-dead.net، الإصدار 2.8.0.beta4، مستضاف على Google Cloud/Compute؛ لقد اتبعت الدليل الرسمي القائم على Docker لإعداده. (أنا خبير في تقنيات واجهة المتصفح الأمامية وأفهم المبادئ العامة للاستضافة السحابية، لكنني معتاد على AWS وليس Google.)

السبب الأولي: قمت بإيقاف مثيل VM ثم أعدت تشغيله (في محاولة لتعديل متغيرات البيئة المكشوفة لـ Discourse).

عند عودة VM واستعادة الموقع، لاحظت أن أصول JavaScript كانت تنقطع في المهلة، وكذلك بعض صور المستخدمين الرمزية. في لوحة الإدارة، لا يتم تحميل منطقة صحة المجتمع؛ يستمر المؤشر في الدوران، وفي أدوات مطوري Chrome في تبويب الشبكة، تظهر جميع طلبات /message-bus/.../poll فاشلة. تفشل صفحة الترقية (/admin/upgrade) فورًا تقريبًا ويظهر Chrome رمز الخطأ ERR_FAILED. عند تصفح المواضيع، أرى فشل طلبات POST برمز ERR_CONNECTION_REFUSED وفشل طلبات GET التي يبدأها JavaScript برمز ERR_FAILED. (هذا من متصفح لديه ملفات تعريف ارتباط مسجلة الدخول لحساب المسؤول الخاص بي.)

تحميل الموقع من مثيل متصفح جديد يظهر خطأ Chrome ERR_CONNECTION_REFUSED.

ما جربته:

  • إعادة بناء من جانب الخادم — يبدو أن أمر sudo ./launcher rebuild app ناجح، لكن لا يوجد أي تغيير في سلوك الموقع
    • جربت أيضًا حذف التعليقات عن الإضافات وإعادة البناء، ولا يزال لا يوجد تغيير
  • وضع الأمان — يؤدي طلب /safe-mode فورًا إلى صفحة خطأ ERR_FAILED في Chrome

أي اقتراحات؟

هل جربت

apt-get update
apt-get upgrade

ثم إعادة البناء؟

لقد جربت للتو، ويبدو أن الأمر كما كان من قبل.

لا، موقعك ليس عادًا للعمل، بل هو معطل تمامًا. أنت تنظر جزئيًا إلى ذاكرة التخزين المؤقت. بالنسبة لشخص لم يزُر موقعك من قبل، لا يستجيب على الإطلاق. من المرجح أن المشكلة على مستوى الشبكة/جدار الحماية، أو أن nginx لا يبدأ أو ينهار.

حسناً، هذا منطقي.

بمجرد تنفيذ الأمر sudo ./launcher enter app، يبدو أن nginx يعمل…

root@adn-prod-app:/var/www/discourse# ps aux | grep nginx
root       548  0.0  0.0   2156    64 ?        Ss   07:04   0:00 runsv nginx
root       558  0.0  0.1  55236  2524 ?        S    07:04   0:00 nginx: master process /usr/sbin/nginx
www-data   567  0.0  0.2  55996  5068 ?        S    07:04   0:00 nginx: worker process
www-data   568  0.0  0.0  55996  1628 ?        S    07:04   0:00 nginx: worker process
www-data   569  0.0  0.0  55792  1680 ?        S    07:04   0:00 nginx: cache manager process
root     23179  0.0  0.0   6140   884 pts/1    S+   21:23   0:00 grep nginx

أنا لست على دراية كافية بـ Google Cloud لأعرف ما يجب البحث عنه في إعدادات الشبكة/جدار الحماية لديهم… لاحظت أن مثيل VM يحمل وسوم “http-server” و “https-server”، ويبدو أن نظام جدار الحماية يستخدم هذه الوسوم لتطبيق قواعد “default-allow-http” و “default-allow-https” المدمجة على المثيلات التي تحمل هذه الوسوم. يبدو هذا صحيحاً من وجهة نظري، ويُظهر أمر nslookup أن النطاق الفرعي الذي أستخدمه يحل إلى عنوان IP الخارجي المذكور في واجهة مستخدم Google، ومع ذلك لا يزال العالم الخارجي غير قادر على الوصول إلى المثيل.

في /var/discourse/shared/standalone/log/rails/production.log أرى أخطاء تتعلق بالاتصال بـ Redis؛ هل هناك طريقة لإصلاح ذلك؟

Job exception: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
Job exception: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
Job exception: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
Job exception: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
Job exception: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
Job exception: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL) subscribe failed, reconnecting in 1 second. Call stack /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis/client.rb:384:in `rescue in establish_connection'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis/client.rb:365:in `establish_connection'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis/client.rb:117:in `block in connect'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis/client.rb:330:in `with_reconnect'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis/client.rb:116:in `connect'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis/client.rb:403:in `ensure_connected'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis/client.rb:255:in `block in process'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis/client.rb:342:in `logging'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis/client.rb:254:in `process'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis/client.rb:148:in `call'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/rack-mini-profiler-2.3.3/lib/mini_profiler/profiling_methods.rb:85 :in `block in profile_method'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis.rb:959:in `block in get'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis.rb:70:in `block in synchronize'
/usr/local/lib/ruby/2.7.0/monitor.rb:202:in `synchronize'
/usr/local/lib/ruby/2.7.0/monitor.rb:202:in `mon_synchronize'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis.rb:70:in `synchronize'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis.rb:958:in `get'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/message_bus-3.3.6/lib/message_bus/backends/redis.rb:361:in `process_global_backlog'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/message_bus-3.3.6/lib/message_bus/backends/redis.rb:269:in `block in global_subscribe'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/message_bus-3.3.6/lib/message_bus/backends/redis.rb:282:in `global_subscribe'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/message_bus-3.3.6/lib/message_bus.rb:781:in `global_subscribe_thread'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/message_bus-3.3.6/lib/message_bus.rb:729:in `block in new_subscriber_thread'
Job exception: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
Creating scope :open. Overwriting existing method Poll.open.

مرحباً،
قد يكون هذا بعيد الاحتمال، لكن آخر مرة رأيت فيها خطأ في Redis كانت مرتبطة بطريقة ما (أو لنقل في نفس السياق) بشهادات SSL (هل هي مفقودة؟).
ربما تكون الأمر ./launcher logs app مفيداً؟

آه، هناك بعض تحذيرات nginx هنا، يتبعها هذه الرسالة التي تبدو وكأنها تفتقد إلى مُعرِّف: Reload error for :

$ sudo ./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/letsencrypt
[Tue 14 Sep 2021 10:44:41 PM UTC] Domains not changed.
[Tue 14 Sep 2021 10:44:41 PM UTC] Skip, Next renewal time is: Tue Oct  5 00:05:09 UTC 2021
[Tue 14 Sep 2021 10:44:41 PM UTC] Add '--force' to force to renew.
[Tue 14 Sep 2021 10:44:42 PM UTC] Installing key to:/shared/ssl/lot.almost-dead.net.key
[Tue 14 Sep 2021 10:44:42 PM UTC] Installing full chain to:/shared/ssl/lot.almost-dead.net.cer
[Tue 14 Sep 2021 10:44:42 PM UTC] Run reload cmd: sv reload nginx
warning: nginx: unable to open supervise/ok: file does not exist
[Tue 14 Sep 2021 10:44:42 PM UTC] Reload error for :
[Tue 14 Sep 2021 10:44:42 PM UTC] Domains not changed.
[Tue 14 Sep 2021 10:44:42 PM UTC] Skip, Next renewal time is: Mon Oct  4 00:06:04 UTC 2021
[Tue 14 Sep 2021 10:44:42 PM UTC] Add '--force' to force to renew.
[Tue 14 Sep 2021 10:44:43 PM UTC] Installing key to:/shared/ssl/lot.almost-dead.net_ecc.key
[Tue 14 Sep 2021 10:44:43 PM UTC] Installing full chain to:/shared/ssl/lot.almost-dead.net_ecc.cer
[Tue 14 Sep 2021 10:44:43 PM UTC] Run reload cmd: sv reload nginx
warning: nginx: unable to open supervise/ok: file does not exist
[Tue 14 Sep 2021 10:44:43 PM UTC] Reload error for :
Started runsvdir, PID is 546
ok: run: redis: (pid 554) 0s
ok: run: postgres: (pid 560) 0s
chgrp: invalid group: 'syslog'
supervisor pid: 558 unicorn pid: 579
Shutting Down
run-parts: executing /etc/runit/3.d/01-nginx
ok: down: nginx: 1s, normally up
run-parts: executing /etc/runit/3.d/02-unicorn
(558) exiting
ok: down: unicorn: 0s, normally up
run-parts: executing /etc/runit/3.d/10-redis
ok: down: redis: 0s, normally up
run-parts: executing /etc/runit/3.d/99-postgres
ok: down: postgres: 0s, normally up
ok: down: nginx: 3s, normally up
ok: down: postgres: 1s, normally up
ok: down: redis: 2s, normally up
ok: down: cron: 0s, normally up
ok: down: unicorn: 2s, normally up
ok: down: rsyslog: 0s, normally up
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/letsencrypt
[Tue 14 Sep 2021 10:54:00 PM UTC] Domains not changed.
[Tue 14 Sep 2021 10:54:00 PM UTC] Skip, Next renewal time is: Tue Oct  5 00:05:09 UTC 2021
[Tue 14 Sep 2021 10:54:00 PM UTC] Add '--force' to force to renew.
[Tue 14 Sep 2021 10:54:00 PM UTC] Installing key to:/shared/ssl/lot.almost-dead.net.key
[Tue 14 Sep 2021 10:54:01 PM UTC] Installing full chain to:/shared/ssl/lot.almost-dead.net.cer
[Tue 14 Sep 2021 10:54:01 PM UTC] Run reload cmd: sv reload nginx
fail: nginx: runsv not running
[Tue 14 Sep 2021 10:54:01 PM UTC] Reload error for :
[Tue 14 Sep 2021 10:54:01 PM UTC] Domains not changed.
[Tue 14 Sep 2021 10:54:01 PM UTC] Skip, Next renewal time is: Mon Oct  4 00:06:04 UTC 2021
[Tue 14 Sep 2021 10:54:01 PM UTC] Add '--force' to force to renew.
[Tue 14 Sep 2021 10:54:01 PM UTC] Installing key to:/shared/ssl/lot.almost-dead.net_ecc.key
[Tue 14 Sep 2021 10:54:01 PM UTC] Installing full chain to:/shared/ssl/lot.almost-dead.net_ecc.cer
[Tue 14 Sep 2021 10:54:01 PM UTC] Run reload cmd: sv reload nginx
fail: nginx: runsv not running
[Tue 14 Sep 2021 10:54:01 PM UTC] Reload error for :
Started runsvdir, PID is 539
ok: run: redis: (pid 549) 0s
ok: run: postgres: (pid 555) 0s
chgrp: invalid group: 'syslog'
supervisor pid: 551 unicorn pid: 579
$

لست متأكدًا من السبب، لكن هل يمكن أن تكون مفقودة؟

أراهم داخل التطبيق…

root@adn-prod-app:/var/www/discourse# ls -l /shared/ssl/
total 24
-rw-r--r-- 1 root root 5950 Sep 14 22:54 lot.almost-dead.net.cer
-rw-r--r-- 1 root root 5329 Sep 14 22:54 lot.almost-dead.net_ecc.cer
-rw------- 1 root root  302 Sep 14 22:54 lot.almost-dead.net_ecc.key
-rw------- 1 root root 3243 Sep 14 22:54 lot.almost-dead.net.key

:facepalm: يبدو أن مشكلتي كانت في أن الآلة الافتراضية عادت للعمل بعنوان IP مختلف، وقد كنت بحاجة إلى تعديل سجل A الخاص بي ليشير إلى العنوان الجديد.

الموقع عاد للعمل، شكرًا لاستماعكم!