لماذا تبدأ الحاوية بإنشاء ملفات مملوكة للمستخدم الجذر فقط بعد تحديث الصورة؟

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

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

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

أثبت أن الملكية لا تتغير إلا بعد بدء الحاوية المحدّثة

أوقف المكدس وسجّل UID وGID الرقميين، والوضع، وقوائم ACL، والطوابع الزمنية لملف موجود واحد ولدليلِه الأب. شغّل الحاوية المحدّثة مرة واحدة مع إظهار السجلات، ثم افحص المسار نفسه وملفًا جديدًا واحدًا.

تغيّر استدعاءات نظام Linux ‏chown ملكية الملفات الرقمية، لذلك فإن الدليل الحاسم هو UID وGID قبل بدء التشغيل وبعده، وليس اسم المستخدم الذي يعرضه المضيف.

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

قارن مستخدم الصورة قبل التحديث وبعده

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

توثّق Docker أن تعليمة USER تضبط هوية وقت التشغيل لتعليمات الصورة اللاحقة ولنقطة دخول الحاوية وأمرها، ما لم يستبدلها تجاوزٌ آخر في وقت التشغيل.

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

تحقق مما إذا كانت نقطة الدخول الجديدة تنفّذ chown عوديًا

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

تعرّف GNU Coreutils ‏chown العودي بأنه إعادة كتابة للملكية عبر شجرة الأدلة المحددة، ما قد يجعل حجم موجودًا وصحيحًا يبدو وكأن ملكيته تغيّرت فور بدء الصورة الجديدة.

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

-15% OFF

دقّق في تجاوزات المستخدم في Compose والمتغيرات المحذوفة PUID أو PGID

قارن نموذج Compose المنشور قبل التحديث وبعده، بما في ذلك user: ومتغيرات البيئة والمجموعات الإضافية والملفات المتجاوزة وال إعدادات المخزنة لدى مدير المكدس.

يستخدم Kubernetes ‏هويات رقمية صريحة لوقت التشغيل والأحجام، موضحًا الحد الفاصل نفسه في الحاويات: تجاوز وقت التشغيل وسياسة ملكية الحجم إعدادان منفصلان يجب أن يظلا متوافقين.

إذا كانت الصورة القديمة تترجم متغيرَي PUID وPGID، بينما أزال الإصدار الجديد هذه المتغيرات أو أعاد تسميتها، فقد تظل المتغيرات موجودة من دون أن تتحكم في العملية. تحقّق مباشرة من UID قيد التشغيل.

ضع في الحسبان تعيينات معرّفات الجذر دون صلاحيات ومساحات أسماء المستخدمين

سجّل ما إذا كان Docker يعمل بصلاحيات الجذر، أو دون صلاحيات الجذر، أو مع إعادة تعيين مساحة أسماء المستخدمين. قارن UID الظاهر داخل الحاوية بمالك inode نفسه كما يظهر على المضيف.

توضح Red Hat أن الحاويات التي تعمل دون صلاحيات الجذر تستخدم نطاقات UID وGID فرعية، لذلك لا يظهر جذر الحاوية بالضرورة كـ UID 0 على المضيف، وقد يكشف التحديث عن تعيين مختلف أو وضع تشغيل مختلف.

لا تغيّر ملكية حجم يعمل دون صلاحيات الجذر عوديًا إلى جذر المضيف قبل فهم التعيين. فقد يجعل ذلك البيانات غير قابلة للوصول بالنسبة إلى هوية الحاوية المقصودة.

تحقق مما إذا كان تحميل مُعيّن للمعرّفات أو تحميل شبكي يغيّر المالك الظاهر

حدّد ما إذا كانت بيانات التطبيق موجودة على نظام ملفات محلي أو تحميل مُعيّن للمعرّفات أو NFS أو SMB أو FUSE أو مشاركة NAS. سجّل خيارات التحميل وقارن الملكية من الخادم والمضيف والحاوية.

يفصل نموذج التحميل المُعيّن للمعرّفات في نواة Linux بين ملكية نظام الملفات وملكية التحميل، لذلك قد يظهر الملف نفسه بمعرّفات مختلفة دون إعادة كتابة فعلية عودية للملكية.

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

استعد هوية تشغيل ثابتة وتحقق منها في التحديث التالي

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

تتناول مقالة ZimaSpace حول ملكية الحاوية بعد نسخ بيانات التطبيق أسباب النسخ والترحيل؛ أما هذه المقالة فتعزل التغيير الذي أدخلته الصورة البديلة.

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

الأسئلة الشائعة

هل يثبت الملف المملوك للجذر أن الحاوية بأكملها تعمل كجذر؟

لا. فقد تعمل نقطة الدخول لفترة وجيزة بصلاحيات الجذر لتهيئة حجم، ثم تتخلى عن الصلاحيات قبل بدء التطبيق.

هل ينبغي أن أغيّر ملكية الحجم بأكمله عوديًا؟

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

هل يمكن لتحديث الصورة تغيير UID الخاص بالتطبيق؟

نعم. يمكن للمشرفين تغيير مستخدم الصورة، أو إعادة بناء قاعدة حساباتها، أو إعادة تسمية إعدادات PUID أو PGID، أو إضافة عملية ترحيل لملكية الملفات عند بدء التشغيل.

الدعم والنصائح

المزيد للقراءة

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.