أفاد مستخدم لـ ZimaOS في أيرلندا بأن عمليات سحب صور Docker كانت تصل أحيانًا إلى نطاقات وكلاء إقليمية مثل ghcr.1panel.live أو daocloud.io، حتى بعد محاولات مسح الإعدادات. وفشلت عمليات السحب المتأثرة بسبب أخطاء في شهادات TLS أو بسبب قيود الوصول الإقليمية، بدلًا من إتمامها عبر السجل الرسمي المتوقع.
وصفت الردود في البداية هذه الوكلاء بأنها مرايا مفروضة، لكن ردًا لاحقًا من فريق ZimaOS أضاف تصحيحًا مهمًا: يحاول ZimaOS أولًا استخدام Docker Hub، ولا يستخدم وكيلًا إلا بعد فشل عملية السحب تلك. لذلك يوثّق النقاش مشكلة في مسار الرجوع الاحتياطي وطلبًا لإضافة خيار «السجلات الرسمية فقط»، وليس دليلًا على إرسال كل عملية سحب صور إلى وكيل إقليمي منذ البداية.
ما واجهه المستخدم في أيرلندا
أفاد lucslav عن فشل متكرر في تثبيت صور Docker أثناء استخدام ZimaOS في أيرلندا. وظهر السلوك نفسه عبر الواجهة الرسومية ومن خلال عمليات السحب في الطرفية، كما أن المحاولات اليدوية لمسح إعدادات المرآة لم تجعل التغيير دائمًا على ما يبدو.
كان الخطأ الأكثر تحديدًا الذي نُسخ في النقاش هو:
tls: failed to verify certificate: x509: certificate signed by unknown authorityوقد تضمّن الطلب الفاشل نطاقات وكلاء أو مرايا بدلًا من الاكتفاء بسجل الصور الرسمي المتوقع. ولأن الاتصال المباشر بالسجلات الرسمية كان أكثر موثوقية من موقع المستخدم، طلب lucslav توفير طريقة دائمة لتعطيل هذه المسارات الإقليمية.
الخطآن الإضافيان اللذان أُبلغ عنهما لاحقًا
في متابعة لاحقة، تذكّر lucslav ظهور نوعين آخرين من الرسائل. أفادت إحداهما بأن الخدمة متاحة في البرّ الرئيسي للصين فقط. وأفادت الأخرى بأن الشهادة منتهية الصلاحية أو لم تصبح سارية بعد.
عزّزت هذه الرسائل اعتقاد المستخدم بأن نقطة النهاية الاحتياطية غير مناسبة لكل المناطق. فاستجابة تقييد المنطقة تمنع استخدام الخدمة خارج نطاقها المقصود، بينما تمنع الشهادة المنتهية أو غير السارية بعد الوثوق باتصال TLS.
ظل التغيير المطلوب في المنتج بسيطًا طوال النقاش: إضافة إعداد يتيح للمستخدمين تعطيل المرايا الإقليمية وفرض الاتصالات المباشرة بالسجلات الرسمية، مثل سجل حاويات GitHub وDocker Hub.
كيف فسّر gelbuilding الفشل
وافق gelbuilding على أن السلوك المُبلغ عنه لا يبدو كفقدان عادي للاتصال بالإنترنت. وكان تفسيره أن طلب Docker وصل إلى مرآة سجل تعذّر التحقق من شهادتها، ما تسبب في إيقاف Docker لعملية السحب.
بعد أن أضاف lucslav رسالتي «متاح في البرّ الرئيسي للصين فقط» و«الشهادة منتهية أو غير سارية»، اعتبر gelbuilding أن نقطة النهاية نفسها هي فرع الفشل. ومن هذا المنظور، لم تعد المرايا تحسّن الموثوقية للمستخدمين الأوروبيين، بل أصبحت تتسبب في فشل حاد لعملية التثبيت.
تمثل حل الواجهة المقترح في خيار شبيه بـ استخدام السجلات الرسمية فقط. ولم يُقدَّم في النقاش أي خيار مماثل أو إجراء إعداد مؤكد، لذا ينبغي فهم الرد على أنه اقتراح للمنتج، لا خطوة متاحة حاليًا.
الإبلاغ عن فشل مشابه من الولايات المتحدة
انضم connorb لاحقًا إلى النقاش من الولايات المتحدة بعد تلقيه خطأ مشابهًا أثناء محاولة تثبيت صورة Docker. وأظهر ذلك أن المشكلة الموضحة في النقاش لم تكن محصورة في موقع المستخدم الأصلي في أيرلندا.
سأل connorb عما إذا كان هناك حل بديل. ورد lucslav بأنه لم يعثر على حل، واقترح البحث عن صورة بديلة متى أمكن. ولم يثبت النقاش ما إذا كانت الصورة البديلة ستستخدم سجلًا آخر أو مالك مستودع مختلفًا أو حزمة تطبيق مختلفة.
فريق ZimaOS يوضح ترتيب السحب
أضاف raller1028 أهم توضيح متعلق بالسلوك قرب نهاية النقاش: عندما يسحب ZimaOS صورة، فإنه يحاول أولًا الحصول عليها عبر Docker Hub. ولا تتم محاولة استخدام الوكيل إلا عند فشل عملية السحب الأصلية.
يغيّر ذلك طريقة تفسير التقارير السابقة. فقد واجه أفراد المجتمع حالات فشل مرتبطة بالوكيل، لكن رد الفريق يشير إلى أن الوكيل كان مسارًا احتياطيًا، لا الوجهة الأولى لكل عملية سحب.
ويترك هذا التوضيح سؤالًا بلا إجابة: لماذا فشل طلب Docker Hub الأصلي قبل انتقال النظام إلى الوكيل؟ لا يتضمن النقاش سجلات أو اختبارات متابعة تحدد ما إذا كان الفشل الأول ناتجًا عن الاتصال أو المصادقة أو حدود المعدل أو عدم توفر الصورة أو DNS أو سبب آخر.
ما الذي لم يحسمه النقاش
لم يقدّم أي مشارك طريقة دائمة مؤكدة لتعطيل الرجوع إلى الوكيل. وأفاد lucslav بأن المحاولات اليدوية لمسح الإعدادات لم تستمر، لكن المنشور لم يتضمن الملف أو الإعداد أو الخدمة المعنية بالتحديد.
كما لم يؤكد النقاش أن الشهادة نفسها كانت منتهية في كل حالة. فقد نوقشت ثلاث رسائل مختلفة: جهة إصدار شهادة غير معروفة، وشهادة منتهية أو غير سارية بعد، وقيد يقتصر فيه توفر الخدمة على البرّ الرئيسي للصين. وقد تكون هذه الرسائل مرتبطة بنقاط نهاية مختلفة للوكيل أو بمراحل مختلفة من عملية الرجوع الاحتياطي.
وأخيرًا، لم يُنشر في هذا النقاش أي إصدار نهائي من ZimaOS أو إعداد أو حل بديل. وكانت النتيجة العملية طلبًا للمنتج: توفير سياسة دائمة للاتصال المباشر فقط في المناطق التي لا تحتاج إلى المرايا الإقليمية أو يتعذر فيها الوصول إليها.
معلومات جديرة بالحفاظ عليها عند الإبلاغ عن المشكلة نفسها
كان المنشور الأصلي مفيدًا لأنه تضمّن منطقة المستخدم، وأسماء مضيفي الوكلاء، وحقيقة تأثر كل من الواجهة والطرفية، ورسالة x509 الكاملة. وأضافت الردود اللاحقة حالتين إضافيتين من رسائل الخطأ الظاهرة، إلى جانب بلاغ مشابه من دولة أخرى.
لذلك ينبغي أن يحافظ بلاغ المتابعة المفيد على النوع نفسه من الأدلة: إصدار ZimaOS، والبلد أو المنطقة، ومرجع الصورة الأصلي، وما إذا بدأت عملية السحب من الواجهة أو الطرفية، وفشل السجل الرسمي الأول، واسم المضيف الاحتياطي، ورسالة الشهادة أو تقييد المنطقة كاملة.
ستمكّن هذه المعلومات فريق ZimaOS من التمييز بين فشل السحب من السجل الرسمي وفشل الرجوع إلى الوكيل. ويمكن للمستخدمين الاستعانة بـ دليل تطبيقات Docker في ZimaOS لسير عمل التثبيت المعتاد.
الأسئلة الشائعة من نقاش المجتمع
هل كانت المرايا الإقليمية هي مسار السحب الأول؟
وفقًا لرد فريق ZimaOS، لا. يحاول ZimaOS أولًا سحب الصورة عبر Docker Hub، ولا يحاول استخدام الوكيل إلا بعد فشل عملية السحب تلك.
ما الأخطاء التي أُبلغ عنها فعلًا؟
يتضمن النقاش خطأً يفيد بوجود جهة إصدار شهادة غير معروفة، ورسالة متذكَّرة عن شهادة منتهية أو غير سارية بعد، ورسالة تفيد بأن الخدمة متاحة في البرّ الرئيسي للصين فقط.
هل قدّم النقاش مفتاحًا لتعطيل الوكلاء؟
لا. كان مفتاح «استخدام السجلات الرسمية فقط» طلب ميزة من أفراد المجتمع، وليس إعدادًا موجودًا عُرض في النقاش.
هل كان هناك حل بديل مؤكد؟
لم يُؤكَّد أي حل بديل دائم. اقترح أحد المشاركين العثور على صورة بديلة، بينما أوضح الفريق أن ترتيب السحب هو السجل الرسمي أولًا ثم الوكيل.
هل كانت المشكلة مقتصرة على أوروبا؟
لا. جاء البلاغ الأصلي من أيرلندا، لكن مستخدمًا آخر أبلغ لاحقًا عن خطأ مشابه في تثبيت صورة Docker من الولايات المتحدة.
