الخلاصة

  • يستخدم الملف التاريخي rpkic_run.sh الاسم rpkic_rpkiv5_cache في الإجرائين، لكنه يغيّر موضع إتاحته داخل الحاوية من /var/cache/rpki-client إلى /root/cache.
  • تميّز وثائق Docker بين مصدر التخزين ووجهته داخل الحاوية. لا يثبت ثبات الاسم أن التطبيق يعيد استخدام الذاكرة المخبأة، ولم يجر التحقق من مساره الفعلي هنا.
  • تبقى سلسلة الصورة والوسائط المشتركة وربط دليل مراسي الثقة متطابقة. وتحافظ سكربتات التشغيل الثلاثة الأخرى التي فحصت على وجهاتها الخاصة.
  • يتعلق الفحص بنسخة ثابتة من المستودع مؤرخة في 1 أبريل 2024، شوهد في 14 سبتمبر 2026. لم تنفذ أوامر حاويات أو برامج تحقق، ولم يثبت انتقال جديد أو فقدان بيانات أو عطل إنتاجي.

ما الذي يفترض أن يعبر مع التطبيق؟

تبدأ التجربة التي يصفها مستودع LACNIC قبل الانتقال نفسه. يطلب ملف README تشغيل برنامج الطرف المعتمد على الخدمة القائمة، وانتظار اكتمال الدورة الأولى وامتلاء ذاكرته المخبأة، ثم إيقاف الحاوية وتشغيل الإجراء الموجّه إلى الخدمة البديلة مع الاحتفاظ بتلك الذاكرة. ليست الحالة السابقة تفصيلا ثانويا في هذه الخطة. إنها أحد الشروط التي تعطي المقارنة معناها.

الطرف المعتمد هنا هو البرنامج الذي يعالج مواد RPKI ويخرج معلومات توجيه متحققا منها. برنامج يمتلك مواد اكتسبها سابقا لا يبدأ من الوضع نفسه الذي يبدأ منه برنامج يكتشف كل شيء من الصفر. قد تكون التجربتان مفيدتين، ولا تعني هذه الملاحظة أن إحداهما معيبة. لكنها تعني أن تجربة البداية الجديدة لا يجوز أن تحل بصمت محل تجربة انتقال تحمل حالة سابقة.

يختار سكربت rpki-client وحدة تخزين مسماة واحدة في الإجرائين. في current تظهر rpkic_rpkiv5_cache داخل الحاوية عند /var/cache/rpki-client. وفي rpkiv5 تظهر الوحدة نفسها عند /root/cache. الجزء الذي يختار المخزن ثابت، بينما الجزء الذي يحدد عنوانه داخل الحاوية مختلف. هذه ملاحظة في التعليمات المنشورة، وليست مشاهدة لما فعله البرنامج عند تشغيله في بيئة فعلية.

الفرق يفتح سؤالا ضيقا: هل موضع الظهور الجديد هو موضع الذاكرة المخبأة الذي تستخدمه الصورة المختارة بالفعل؟ لا تجيب قراءة السكربت وحدها عن ذلك. قد توجد إعدادات داخلية أو أسماء بديلة للمجلدات تجعل المسارين متكافئين، وقد يختار التطبيق موضعا آخر. لم تفحص هذه العلاقات هنا. لذلك لا يمكن الجزم بإعادة الاستخدام، ولا الجزم بأن التطبيق بدأ من دون حالته السابقة.

البقاء لا يساوي الاستخدام

تفصل وثائق Docker الرسمية بين المصدر والوجهة في تركيب وحدة التخزين. الاسم يحدد المخزن الذي ستستخدمه الحاوية، والمسار يحدد أين سيظهر محتواه داخلها. ويمكن للوحدة المسماة أن تستمر بعد إزالة الحاوية التي استخدمتها وأن تتصل بحاوية أخرى. هذه خاصية مهمة لحمل البيانات بين تشغيلين، لكنها لا تحدد تلقائيا الدليل الذي يبحث فيه التطبيق عن ملفاته.

من ثم، فإن الاحتفاظ بالاسم دليل إيجابي ينبغي عدم إسقاطه. لا يختار السكربت مخزنا مختلفا صراحة للإجراء الثاني. وتغيير الوجهة ليس في ذاته أمرا بحذف محتويات الوحدة. قد تبقى البيانات محفوظة في المصدر نفسه بينما يتغير مكان عرضها للتطبيق. القفز من اختلاف المسار إلى ضياع البيانات سيكون أوسع من الدليل، تماما مثل القفز من ثبات المصدر إلى ضمان استخدام البيانات.

هناك ثلاث علاقات منفصلة: بقاء المخزن، وظهوره داخل الحاوية، وقراءة البرنامج له باعتباره حالته السابقة. الأولى تساعد على الثانية، والثانية قد تتيح الثالثة، لكن أيا منها لا يثبت وحده بقية السلسلة. السؤال المطروح يقع بين الظهور والاستخدام. توضيح هذا الموضع يمنع تحويل خاصية تخزين إلى شهادة تشغيل، ويمنع أيضا اختراع حادثة لإعطاء الفرق في التعليمات وزنا أكبر مما يحتمل.

تشرح Docker أيضا أن التركيب فوق دليل غير فارغ في الحاوية قد يحجب المحتوى الموجود أصلا في الصورة. وقد تنسخ المحتويات السابقة إلى وحدة فارغة عند البداية وفق سلوك النسخ الافتراضي. هذه قواعد للمنصة تجعل وجهة التركيب معلومة ذات معنى. لكنها لا تكشف محتوى الصورة المعنية، ولا تثبت ما قرأه هذا الإصدار من rpki-client، ولا تحل محل فحص نقطة دخوله وإعداداته.

التعليمات تحدد المقصود، لا النتيجة

يصف README توجيه الإجراء البديل بواسطة تغيير ربط اسم المضيف نحو خدمة RRDP الجديدة، وهي واجهة جلب المستودعات المسماة في السكربتات. ثم يقترح مقارنة المخرجات يدويا، ويذكر عدد حمولات أصل المسار المتحقق منها، أو VRP، مثالا. المقصود مفهوم: تغيير الخدمة التي يستقي منها البرنامج مع إبقاء حالة سابقة لديه. لكن المقصود ليس سجلا يثبت أن الشرط تحقق في تشغيل بعينه.

إذا لم يثبت استخدام الحالة السابقة في الإجراء الثاني، فقد تختلط في تفسير مخرجاته آثار تغيير الخدمة وآثار تغيير البداية. هذه إمكانية تفسير، وليست نتيجة مرصودة. وقد تكون المخرجات مناسبة لاختبار اكتشاف جديد، ولكنها لا تصبح تلقائيا اختبارا بذاكرة مخبأة ممتلئة لمجرد أن README وصف ذلك التسلسل. اسم التجربة ينبغي أن يتبع الشرط الذي جرى إثباته، لا أن يعوّض عن إثباته.

المقارنة بالعدد مفيدة كبداية، ولكن نطاقها محدود. يمكن أن يكون لمجموعتين العدد نفسه مع اختلاف العناصر التي تحتويانها. لم يرصد هذا الفحص اختلافا من هذا النوع بين مخرجات فعلية. الملاحظة منطقية فقط: تساوي العدد لا يثبت تطابق المجموعة، ولا يشرح مصدر الحالة التي أنتجتها. لذلك لا يكفي رقم متساو لإضافة ادعاء أوسع عن استمرار كل شروط المقارنة.

لا تقدم حزمة المصادر المفحوصة سجلا مكتملا لتشغيلين مترابطين يحدد أين قرأ التطبيق ذاكرته المخبأة وما الحالة التي كانت متاحة قبل الإجراء البديل. هذا لا يعني أن القائمين على المشروع لم ينفذوا اختبارات داخلية قط. إنه يميز حدود الأدلة العامة التي فحصت. قراءة الأسماء والمسارات والوسائط لا يجوز أن تكتب بوصفها مراجعة لحاوية حية أو إعادة بناء لتاريخ التشغيل.

ما يحافظ عليه السكربت فعلا

تستخدم عمليتا rpki-client سلسلة الصورة rpki/rpki-client:8.2 نفسها. ويربط كل منهما دليل مراسي الثقة المحلي إلى /etc/tals، ويستخدم الوسائط المشتركة -s 480 -c -v -v -v، ويحافظ على خيارات التشغيل في الخلفية وDNS المخصص. وتظهر إصدارات أخرى للصورة في تعليقات، لا كاختيارات نشطة. لا يصح بناء قصة تبديل إصدارات منفذة من سطور لا تعمل.

هذه الثوابت تضيّق النقد. الملف لا يبدل كل العوامل بلا تمييز؛ إنه يحتفظ باختيار الصورة ومدخلات الثقة والوسائط المشتركة ومصدر التخزين. الدليل المتاح يسمح بالتركيز على الوجهة المختلفة والعلاقة التي لم تثبت مع التطبيق. فإذا ظهر تفسير خاص بالصورة يثبت تكافؤ المسارين، فسوف تضعف مسألة استمرار الوصول. ينبغي أن تظل هذه النتيجة المحتملة جزءا من التحليل، لا أن تستبعد لأنها تقلل حدته.

سلسلة الصورة ليست صورة جرى فحص بصمتها ومحتوياتها. لم تسحب صورة، ولم تراجع نقطة دخول أو صلاحيات أو روابط رمزية، ولم يثبت المسار الفعلي للذاكرة المخبأة. كما لا تستنتج دلالات الوسائط الخاصة بالإصدار من دون دليل إضافي. ما يثبت هنا هو تطابق النصوص في الإجرائين. هذا أضيق من تطابق السلوك، لكنه يظل مقابلا إيجابيا لا بد من الاحتفاظ به.

يضيف الإجراء البديل ربط اسم RRDP بالعنوان 96.126.99.186. لم يتصل هذا الفحص بالعنوان. إنه مدخل تاريخي في التجربة المنشورة، لا خدمة حية تحققت منها المراجعة. تغيير الخدمة متوقع في انتقال كهذا؛ تغيير موضع إظهار التخزين مدخل آخر. إذا غيّر الأخير الحالة الفعلية، فستحتاج نسبة النتيجة إلى الخدمة وحدها إلى دليل إضافي. السكربت لا يثبت تحقق هذا الاحتمال أو انتفاءه.

ثلاث مقارنات تمنع تعميما مؤسسيا

يحافظ سكربت FORT على /root/cache في الإجرائين، مع إضافة روابط أسماء RRDP والمستودع في الإجراء البديل. ويحافظ سكربت Routinator الأحدث على /home/routinator/.rpki-cache. وتحافظ النسخة المخصصة لما قبل 0.12 على الوجهة نفسها في زوج إجراءاتها، وتختار سلسلة الصورة v0.10.1. هذه مقارنات تعليمات، لا اختبارات تثبت استخدام البرامج لذاكرتها المخبأة على نحو صحيح.

مع ذلك، فهي تظهر أن تغيير الوجهة ليس ضرورة عامة في أسلوب الانتقال الذي ينشره المستودع. الاختلاف المرصود يخص زوج rpki-client. ولا يثبت أن برامج التحقق لدى LACNIC تفقد حالتها، أو أن أسطول حاويات الإنتاج لدى السجل يستخدم تلك التعليمات، أو أن مشغلا خارجيا واجه مشكلة. الصفة المؤسسية للناشر لا توسع النطاق التشغيلي لكل سطر إلى ما وراء ما جرى فحصه.

في الملفات المجاورة اختلافات ثانوية تستحق التسجيل دون تحويلها إلى محور جديد. الإجراء الحالي في سكربت Routinator الأحدث يستخدم وسائط خادم مشتركة تتضمن --refresh=120، بينما يكتب الإجراء البديل وسائط منفصلة لا تذكر الخيار صراحة. لم يثبت السلوك الافتراضي الفعلي للإصدار. لذلك لا تنسب إليه مهلة تحديث غير عادية أو عطل؛ إنه شرط آخر قد يحتاجه سجل المقارنة.

يتضمن ملف dnsmasq روابط عناوين RRDP والمستودع البديلة وروابط قديمة معلقة. ويتحدث README عن تعديل خيار DNS إذا لم تستخدم تلك الخدمة. لا يثبت هذا أي خدمة DNS كانت تعمل بالفعل أو أي إجابة تلقاها البرنامج في البداية. استنتاج أن المرجع كان موجها مسبقا إلى البديل سيخلق قصة ثانية بلا مشاهدة. يبقى الاختلاف الأساسي هو مصدر تخزين ثابت ووجهة داخلية مختلفة.

التاريخ حد في الاستنتاج

الملفات مثبتة عند fdbecab2890e0da2f9a393ac4be2659d14f54ca2، بتاريخ 1 أبريل 2024، وفحصت في 14 سبتمبر 2026. بقاء الأداة متاحة اليوم لا يجعلها خطة انتقال جديدة ولا يكشف بيئة الإنتاج الحالية. ويذكر README أن سلطة تصديق فرعية لم تكن قد نسخت بعد في السياق التاريخي. لا يجوز نقل التحفظ إلى الحاضر بوصفه اتهاما بأن النسخ لا يزال ناقصا.

تثبيت المصدر يسمح بتحديد أي تعليمات يناقشها القارئ، لكنه لا يثبت أي وحدة تحمل الاسم نفسه كانت موجودة على مضيف أثناء تشغيل قديم، أو أي محتوى كانت الصورة المشار إليها تحمل، أو أي مواد سبق للتطبيق اكتسابها. لا يقول التحليل إن هذه الأشياء تغيرت. يقول فقط إن هوية المصدر ليست كل هوية التشغيل، وإن الاستنتاج عن تشغيل يحتاج إلى روابط مشاهدة لا يوفرها اسم ملف ثابت وحده.

توحيد المسارين نصيا قد يحسن اتساق التعليمات، ولكنه لا يثبت الموقع الصحيح قبل معرفة ما يستخدمه التطبيق. كما أن تصحيح التعليمات لاحقا لا يشهد بأثر رجعي على تشغيل قديم. الحل المناسب يبدأ بتفسير العلاقة بين المصدر والوجهة والمسار الفعلي، ثم تقرير ما إذا كانت التعليمات تحتاج إلى تعديل. ترتيب كهذا يجعل الإصلاح صغيرا بقدر المسألة، ويمنع تحويله إلى شهادة سلامة لم تمنحها الأدلة.

المصادر

الوثائق السبع هي README التاريخي، وسكربت rpki-client، وسكربت FORT، وسكربت Routinator الأحدث، ونسخته الأقدم، وإعداد DNS، ووثائق Docker. تأتي من موقعين للنشر، لا من سبع تحقيقات مستقلة. لم تنفذ أوامر إزالة حاويات أو تنظيف وحدات أو تشغيل برامج تحقق.