هل من الممكن أن تكون ذاكرة الوصول العشوائي (RAM) على وشك النفاد، مما يؤدي إلى قاتل الذاكرة الخارجة عن النطاق (OOM killer) بإيقاف بعض العمليات العشوائية مثل sshd، وبالتالي قطع اتصالك وتسبب مشاكل؟
يجب أن يكون هناك شيء في مخرجات dmesg أو /var/log/messages أو مخرجات journalctl إذا كان قاتل الذاكرة الخارجة عن النطاق يعمل.
أشك في أن نفاد الذاكرة العشوائية (RAM) هو مشكلتي، بل المشكلة تكمن في إصراري على استخدام وحدة تحكم PuTTY بدلاً من وحدة تحكم DO.
لذلك، سأنتقل إلى الاقتراح السابق من @pfaffman، خاصة بعد اكتشافي أن وحدة تحكم PuTTY تنقطع حتى عندما أستخدمها في شيء مختلف تمامًا عن إدارة Discourse.
قد يكون السبب هو الذاكرة العشوائية (RAM). هل لديك مساحة تبديل (Swap)؟
هل جربت تعديل إعداد البقاء نشطًا، مثل هذا؟
@pfaffman لم أحدد أي شيء — أستخدم جميع الإعدادات الافتراضية للقطرات، مع الاعتماد على فريق DigitalOcean لضمان سلوك معقول.
أولاً، سأحاول تعيين keep-alive كما اقترح @omarfilip أعلى، ثم سأتفحص حالة مساحة التبديل، تليها اقتراح @pfaffman باستخدام وحدة تحكم DigitalOcean الأصلية (إذا سمحت إعدادات keep-alive لي بالاستمرار في استخدام وحدة تحكم PuTTY، فسأستخدمها لأنها أكثر سهولة في الاستخدام من نظيرتها في DigitalOcean).
بما أنني محاط بعدد كبير من الأشخاص الودودين الذين يساعدونني، أود إعادة التأكيد على أسبابي لمحاولة دمج Ghost وDiscourse: فأنا أرى أنهما الأداة المثالية لأي شخص يرغب في كتابة وثائق تقنية وتقديم أفضل دعم لمناقشة هذه الوثائق. خطتي هي معالجة موضوع إدارة الهوية والحسابات (IAM) باستخدام عدة مزودي خدمات PaaS لإدارة الهوية المثيرين للاهتمام؛ فهذا الموضوع غير موثق بشكل كافٍ (على الأقل في رأيي، استنادًا إلى سنوات من استخدام هذه الخدمات بنفسي).
ومن أجل “اختبار تجريبي” لأداتي المدمجة بين Ghost وDiscourse، قررت وصف جميع تفاصيل عملية إنشاء هذه الأداة واختبارها. لذا، يجب على جميع الأشخاص الذين يساعدونني أن يعرفوا أن هذا الجهد يهدف إلى مساعدة مجتمع Discourse وGhost وDigital Ocean.
إذا قمت باستخدام التثبيت بلمسة واحدة من Digital Ocean ولم تستخدم التثبيت القياسي الرسمي لـ Discourse، فمن المرجح أنك لم تقم بتكوين مساحة التبديل (swap)، وبالتالي عند إعادة البناء قد تنفد ذاكرة الوصول العشوائي (RAM) ما لم يكن لديك أكثر من 2 جيجابايت.
يمكنك تجربة الأمر التالي:
cd /var/discourse
./discourse-setup
وسيقوم بإنشاء مساحة تبديل (swap) لك إذا لزم الأمر.
إذا كنت ترغب في الحصول على مساعدة بخصوص تثبيت Digital Ocean بلمسة واحدة وتريد “الاعتماد على فريق Digital Ocean لضمان سلوك معقول”، فيجب أن تعتمد عليهم في دعمك.
ولكن بما أنني أكتب بالفعل، فإن طريقة أسهل للتأكد من أن المشكلة ليست في PuTTY (وهو ما قد يوفر وقتًا طويلاً في تعديل معاملات PuTTY دون جدوى) هي تجربة وحدة التحكم (console). وإذا لم تكن قد نفذت أمر discourse-setup، فأنا متأكد تقريبًا من أن المشكلة هي في مساحة التبديل (swap space).
@pfaffman لقد اتبعت عملية التثبيت الرسمية لمنصة Discourse حرفيًا، بما في ذلك استخدام PuTTY المذكور في وثيقة التثبيت الرسمية تلك.
من الممكن أنك استنتجت رأيك حول كيفية استخدامي لتثبيت Digital Ocean بنقرة واحدة، وتعتقد أنه يجب أن أعتمد على Digital Ocean:
إذا كنت ترغب في الحصول على مساعدة بخصوص تثبيت Digital Ocean بنقرة واحدة وتريد “الاعتماد على فريق Digital Ocean لضمان سلوك معقول”، فعليك حينها الاعتماد عليهم لدعمك.
إشارتي إلى التثبيت بنقرة واحدة تأتي من البريد الإلكتروني الأخير الصادر عن Discourse:
هورا، إصدار جديد من Discourse متاح الآن!
إصدارك الحالي: 2.7.0.beta1
الإصدار الجديد: 2.7.0.beta2
- قم بالترقية بسهولة عبر ترقية المتصفح بنقرة واحدة
لذا، فإن الوضع الحالي هو:
مع علمي بأنك تكسب رزقك من مساعدة الناس في Discourse. وعلى الرغم من أنني لا أبدو كعميل محتمل، فقد خصصت وقتًا لسحبني من ورطة../launcher rebuild app بنجاح.شكرًا جزيلاً للجميع الذين قدموا أجزاء من الحل.
أوه! خطأ مني! آسف جداً!
إذن لديك swap، وتخميني كان خاطئاً. هذا مؤسف، لأن الأمر كان سيصبح إصلاحاً سهلاً. 
هذا مطمئن بعد أن اتهمتك ظلمًا!
ومن السيء جداً معرفة أن برنامج Putty سيء إلى هذا الحد. لا أفهم كيف يظل العميل الموصى به لـ SSH على نظام ويندوز.
أعتقد أن هناك الآن عميلاً جزءاً من ذلك النظام الفرعي الخاص بـ Linux، لكن إصدار ويندوز الذي كنت أستخدمه بانتظام كان ويندوز 98.
سعيد لأنك قدّمت الأمر!
جميع أنظمة التشغيل الحديثة تأتي مع عملاء SSH مدمجة بشكل افتراضي، لذا لا داعي لاستخدام عملاء من جهات خارجية. حتى في Windows Terminal، يمكنني ببساطة كتابة SSH. يجب أن يعمل ذلك بشرط تحديث نظام Windows الخاص بك.
يا إلهي. حقًا؟ آخر مرة (ظننتُ) أنني راجعتُها، كانت تتطلب بعض التثبيت الذي بدا صعبًا.
وهل يمكنها استخدام مفتاح SSH عادي وليس ذلك الهراء بصيغة PEM؟
هذه القصة الطويلة لها نهاية سعيدة كبيرة ويمكن تصنيفها على أنها ضجة في فنجان شاي. لقد تعلمت الكثير عن Discourse، ونتيجة لذلك أخطط للبقاء هنا إلى أجل غير مسمى. وفيما يلي وصف مفصل للنهاية السعيدة:
كانت مشكلتي في الترقية من Beta1 إلى Beta2 تتجلى في انتهاء مهلة وحدة تحكم PuTTY. ففسّرت ذلك على أنه انهيار هائل في مهمة ترقية Discourse، وقضيت وقتًا طويلاً في تعلم “الداخلية” الخاصة بـ Discourse — وهو نفق أرنب سعيد جدًا بأنني سلكته دون داعٍ.
حل مشكلتي بسيط للغاية (بمجرد أن تعرف أين “تضغط”) — بسيط مثل 1، 2، 3 أدناه:
فتح @Falco “عيوننا الجماعية” من خلال الإشارة إلى استخدام OpenSSH المدمج في Windows 10 ببساطة (شكرًا لـ Scott Hanselman).
بما أنني وعدت بالفعل @codinghorror بكتابة أفضل وثيقة على الإطلاق تقدّم Discourse للعالم كشكر له (ولفريقه) على مساعدتي في فهم Discourse، فقد سمح لي @pfaffman بجعل اقتراح @Falco هذا هو الجزء الأول من وثيقتي.
أوصي باستخدام tmux، بهذه الطريقة يمكنك إعادة الاتصال بالجلسة التي تعمل على إعادة البناء حتى لو انتهى وقت اتصال العميل.
@md-misko شكرًا على التلميح:
الميزة الرائعة في tmux هي أنه يتيح لك فتح نوافذ متعددة في نفس الوقت، كل منها يشغل قشرة (shell) خاصة به، ولكن باستخدام اتصال SSH واحد مشترك. وعلاوة على ذلك، يمكنك أيضًا فتح عدة “نوافذ” في نفس الوقت، تشبه إلى حد ما علامات التبويب ولكن تحتوي على نوافذ فرعية أكثر.
مرحباً @sunjam، يبدو أن المشكلة يمكن حلها بالإصدار الجديد من gem omniauth-vkontakte 1.7.0.
لقد أنشأت طلب دمج (pull request) لمُصنِّف الإضافة. كحل مؤقت، يمكنك تغيير رابط GitHub في ملف app.yml إلى:
- git clone https://github.com/rapekas/discourse-vk-auth
ثم إعادة البناء.