عند zypper refreshتلقي تقارير خطأ HTTP 500 على نظام SLES، حدد أولاً عنوان URL الخاص بالمستودع الذي أعاد هذا الخطأ. يشير خطأ HTTP 500 إلى أن الخادم الذي يعالج الطلب واجه حالة غير متوقعة؛ وقد يكون هذا الخادم هو مضيف المستودع، أو خادم إدارة الأصول عن بُعد (RMT) الخاص بالمؤسسة، أو خادم وكيل HTTP. اعزل المستودع المعطل وقم بإصلاحه أو الإبلاغ عن نقطة النهاية هذه قبل مسح البيانات الوصفية المحلية. لا يمكن لإعادة بناء ذاكرة التخزين المؤقت القسرية إصلاح خادم لا يزال يُعيد خطأ 500.
تُوثّق أدلة إدارة وترقية SLES 15 SP7 الحالية من SUSE أوامر عرض المستودعات وتحديثها، بما في ذلك zypper refresh -fdbإعادة بناء بيانات تعريف المستودع المحلي. ولا تُشير هذه الأدلة إلى وجود مشكلة حالية من نوع HTTP 500 على مستوى SLES. ويعتمد الحل العملي على ما إذا كان عنوان URL تابعًا لمركز عملاء SUSE، أو نسخة احتياطية داخلية، أو مستودع تابع لجهة خارجية.
ابدأ بتسجيل اسم المستودع المستعار وعنوان URL الخاص به. على نظام SLES، قم بتشغيل الأمر التالي:
zypper repos -uيعرض هذا -uالخيار مصدر كل مستودع مُكوّن. لاحظ الإدخالات المُفعّلة والمُعدّة للتحديث، ثم قارن أسماء مضيفي عناوين URL التي فشلت. إذا فشل أحد مستودعات الطرف الثالث بينما يتم تحديث مصادر تحديث SUSE بنجاح، فابحث عن مالك ذلك المستودع. إذا أشارت عدة مستودعات إلى نفس المضيف الداخلي وفشلت جميعها، فإن المرآة المشتركة أو خدمة إدارة النسخ الاحتياطي عن بُعد أو الخادم الوكيل العكسي أو اتصالها بالخادم المصدر تُعدّ مؤشرات أقوى.
بعد ذلك، قم بتحديث المستودع المتأثر فقط باستخدام الاسم المستعار:
sudo zypper refresh -f 'Vendor-App'استبدل Vendor-Appالاسم المستعار الموضح في الأمر zypper repos -u. هذا يمنع ظهور شاشة مليئة بالأخطاء المتكررة من مستودعات غير ذات صلة، ويمنحك نتيجة مركزة لمشاركتها مع المسؤول. إذا كان الاسم المستعار يحتوي على مسافات، فاحتفظ بعلامات الاقتباس المفردة. احتفظ بعنوان URL والطابع الزمني للخطأ كما هما، ولكن احذف أي اسم مستخدم أو كلمة مرور أو رمز مميز أو أي معلومات سرية أخرى مضمنة قبل إرسال السجلات أو لقطات الشاشة.
اقرأ رسالة خطأ Zypper كاملةً وحدد عنوان URL الخاص بالبيانات الوصفية الذي تشير إليه، والذي غالبًا ما يكون ملفًا ضمن دليل المستودع repodata. إذا كان بالإمكان الاستعلام عن نقطة النهاية بدون بيانات اعتماد، فقارن استجابة HTTP الخاصة بها من مضيف SLES.
curl -sS -D - -o /dev/null --max-time 20 "$METADATA_URL"قم بتعيين METADATA_URLعنوان URL الخاص بالبيانات الوصفية المعيبة بدقة دون إدخال بيانات الاعتماد في عنوان URL أو سطر الأوامر. يقوم الأمر بطباعة رؤوس الاستجابة وتجاهل نص الاستجابة. HTTP/1.1 500تؤكد نتيجة كهذه أن خادمًا في مسار الطلب يُرجع خطأً؛ لكنها لا تُثبت ما إذا كان المصدر أو وسيطًا هو من تسبب به. قد يستخدم Curl أيضًا إعدادات مصادقة أو وكيل مختلفة عن Zypper، لذا تعامل مع هذا على أنه مقارنة، وليس إعادة إنتاج نهائية. إذا كان الوصول إلى المستودع يتطلب مصادقة، فاستخدم طريقة الاختبار المعتمدة في مؤسستك بدلًا من كشف بيانات الاعتماد.
يختلف رد الخطأ 500 عن مشكلة في ذاكرة التخزين المؤقت للبيانات الوصفية المحلية. كما أنه يختلف عن أعطال نظام أسماء النطاقات (DNS)، وأخطاء شهادات TLS، ومهلات الاتصال، واستجابات المصادقة مثل 401 أو 403. تتطلب هذه الرسائل فحوصات مختلفة. لا تقم بتعطيل التحقق من TLS، أو تغيير المستودع إلى HTTP عادي، أو حذف ذاكرة التخزين المؤقت بشكل متكرر لإخفاء رد الخطأ 500. بالنسبة لدلالات HTTP، يُعرّف RFC 9110 رد الخطأ 500 بأنه حالة غير متوقعة للخادم منعت إتمام الطلب.
يمكنك فحص حالة المستودع وتغييرها باستخدام Zypper أو YaST. على سبيل المثال، zypper modifyrepoيمكن للأمر الموثق تعطيل مستودع باستخدام اسم مستعار، لكن هذا خيار تشغيلي مؤقت، وليس إصلاحًا لمصدر مطلوب معطل. تجنب تعديل عناوين URL للمستودعات المُنشأة بشكل عشوائي، خاصةً بعد ترحيل حزمة الخدمة، لأن مستودعات المنتجات والتحديثات تستخدم مسارات خاصة بكل إصدار.
لا ينبغي إعادة محاولة الوصول إلى جميع المستودعات المفعّلة إلا بعد أن يُعيد الخادم أو الوكيل استجابة صحيحة:
sudo zypper refresh -f
إذا استجابت نقطة النهاية الآن ولكن لا يزال Zypper يُبلغ عن بيانات مستودع محلية قديمة أو غير متناسقة، فإن قسم استكشاف الأخطاء وإصلاحها في SLES 15 SP7 من SUSE يوصي بتحديث كامل للبيانات الوصفية وإعادة بناء قاعدة البيانات باستخدام:
sudo zypper refresh -fdbيؤدي هذا إلى تنزيل البيانات الوصفية الأولية وإعادة بناء قاعدة بيانات Zypper المحلية القابلة للحل. وهو مفيد لحل مشاكل البيانات الوصفية المحلية، ولكنه ليس حلاً لمشكلة الاستجابة المستمرة برمز الخطأ 500. لا تخلط بين تحديث بيانات المستودع الوصفية وتثبيت التحديثات: شغّل أمر التصحيح أو التحديث المعتاد فقط بعد اكتمال التحديث بنجاح.
قم بتشغيل zypper refresh -f 'ALIAS'الأمر للمصدر الذي كان به عطل سابقًا، ثم sudo zypper refresh -fلجميع المستودعات المُفعّلة. يتم تأكيد الإصلاح عند تنزيل بيانات تعريف المستودع المتأثر بنجاح دون ظهور خطأ HTTP 500، وعند انتهاء Zypper بنجاح دون وجود أي مصدر مُفعّل به معطل. إذا استمر عطل أحد المصادر، احتفظ بعنوان URL الكامل، ورمز الحالة، وعناوين الاستجابة، والوقت، وقم بتسليمها إلى مالك نقطة النهاية تلك.
تتبع خطأ تحديث Zypper إلى SUSE أو RMT أو نقطة نهاية تابعة لجهة خارجية، ثم قم بتطبيق الإصلاح الصحيح من جانب الخادم أو ذاكرة التخزين المؤقت دون تعطيل التحديثات الأساسية.
قم بحل أخطاء مساحة التخزين الرقيقة في SUSE LVM عن طريق التحقق من استخدام البيانات والبيانات الوصفية، وتوسيع المجموعة بأمان، ومنع الانقطاعات المتكررة.
حدد ما إذا كان نظام الملفات Btrfs مخصصًا للقراءة فقط عن قصد، أو يعاني من نقص في المساحة، أو يحمي البيانات بعد حدوث أخطاء، ثم اختر مسار استعادة يناسب السبب.
قم بإعداد القنوات المتطابقة، وإنشاء مفتاح التنشيط، وتشغيل عميل SLES 15 بدون اتصال مباشر بالإنترنت مع الحفاظ على الاتصال اللازم لتسجيل دخول المدير.
قم بإصلاح خطأ تشغيل XIO الخاص بـ YaST عبر SSH، وتحقق من إعادة توجيه X11 و xauth، وقم بالتبديل إلى واجهة ncurses عندما تكون النافذة البعيدة غير ضرورية.
ابحث عن لقطة Btrfs قبل التحديث، واختبرها للقراءة فقط، واجعل الاسترداد دائمًا باستخدام Snapper مع فهم البيانات التي تبقى خارج عملية التراجع الجذرية.
إرسال سجلات نظام SLES إلى جامع rsyslog عن بعد عبر TLS مصادق عليه، مع عمليات التحقق من الشهادات، وتخزين الانقطاعات مؤقتًا، واختبارات التسليم.
استخدم سجلات ذاكرة الوصول العشوائي (RAM) والمبادلة والنواة وZypper لتحديد ضغط الذاكرة الحقيقي وحماية حالة الحزمة واختيار محاولة إعادة ترقية SLES أكثر أمانًا.
قم بتمكين تحديثات الأمان التلقائية لنظام Debian عبر SSH، واحتفظ بمصادر الحزم الافتراضية، وتحقق من عمليات التشغيل المجدولة من خلال سجلات systemd و APT.
قارن خيارات تسليم البريد، وقم بتكوين smartd على Ubuntu، وتحقق من وصول تحذيرات حالة القرص إلى صندوق الوارد الخاص بك.
