SYSTEMD-NSPAWN(1)

systemd-nspawn

SYSTEMD-NSPAWN(1)

الاسم¶

systemd-nspawn - استدعِ أمراً أو نظام تشغيل في حاوية خفيفة

موجز¶

systemd-nspawn [الخيارات...] [الأمر [المعطيات...]]

systemd-nspawn --boot [الخيارات...] [المعطيات...]

الوصف¶

يُمكن استخدام systemd-nspawn لتشغيل أمر أو نظام تشغيل في حاوية نطاق أسماء خفيفة. يشبه في نواحٍ كثيرة chroot(1)، ولكنه أقوى لأنه يوفر بيئة افتراضية لهيكلية نظام الملفات، بالإضافة إلى شجرة العمليات، وأنظمة IPC الفرعية المختلفة، وأسماء المضيف والنطاق.

يُمكن استدعاء systemd-nspawn على أي شجرة دليل تحتوي على شجرة نظام تشغيل، باستخدام خيار سطر الأوامر --directory=. وباستخدام خيار --machine=، يُبحث عن شجرة نظام التشغيل آلياً في عدة مواقع، أهمها /var/lib/machines/، وهو الدليل المقترح لوضع صور حاويات نظام التشغيل المثبتة على الحاسوب.

على عكس chroot(1)، يُمكن استخدام systemd-nspawn لإقلاع أنظمة تشغيل كاملة مبنية على لينكس داخل حاوية.

يُقيد systemd-nspawn الوصول إلى واجهات النواة المختلفة في الحاوية لتكون للقراءة فقط، مثل /sys/ أو /proc/sys/ أو /sys/fs/selinux/. لا يجوز تغيير واجهات شبكة المضيف وساعة النظام من داخل الحاوية. ولا يجوز إنشاء عقد الأجهزة. لا يُمكن إعادة تشغيل نظام المضيف ولا يُمكن تحميل وحدات النواة من داخل الحاوية. يُمكن التحايل على هذه البيئة المعزولة بسهولة من داخل الحاوية إذا لم تُستخدم نطاقات أسماء المستخدمين. وهذا يعني أن الكود غير الموثوق يجب تشغيله دائماً في نطاق أسماء مستخدم، راجع مناقشة خيار --private-users= أدناه.

استخدم أداة مثل dnf(8) أو debootstrap(8) أو pacman(8) لإعداد شجرة دليل نظام تشغيل مناسبة كهيكلية نظام ملفات لحاويات systemd-nspawn. راجع قسم الأمثلة أدناه للحصول على تفاصيل حول الاستدعاء المناسب لهذه الأوامر.

كفحص للسلامة، سيتحقق systemd-nspawn من وجود /usr/lib/os-release أو /etc/os-release في شجرة الحاوية قبل إقلاع الحاوية (راجع os-release(5)). قد يكون من الضروري إضافة هذا الملف إلى شجرة الحاوية يدوياً إذا كان نظام تشغيل الحاوية قديماً جداً بحيث لا يحتوي على هذا الملف بشكل افتراضي.

يُمكن استدعاء systemd-nspawn مباشرة من سطر الأوامر التفاعلي أو تشغيله كخدمة نظام في الخلفية. في هذا النمط، تعمل كل نسخة حاوية كنسخة خدمة خاصة بها؛ ويوفر ملف وحدة قالب مبدئي systemd-nspawn@.service لتسهيل ذلك، حيث يأخذ اسم الحاوية كمعرف للنسخة. لاحظ أن خيارات مبدئية مختلفة تُطبق عند استدعاء systemd-nspawn بواسطة ملف وحدة القالب عما إذا استدعي تفاعلياً على سطر الأوامر. والأهم من ذلك، يستخدم ملف وحدة القالب خيار --boot وهو ليس الخيار المبدئي في حالة استدعاء systemd-nspawn من سطر الأوامر التفاعلي. تُوثق الاختلافات الإضافية عن الإعدادات المبدئية مع الخيارات المدعومة المتنوعة أدناه.

يُمكن استخدام أداة machinectl(1) لتنفيذ عدد من العمليات على الحاويات. على وجه الخصوص، توفر أوامر سهلة الاستخدام لتشغيل الحاويات كخدمات نظام باستخدام ملف وحدة القالب systemd-nspawn@.service.

إلى جانب كل حاوية، قد يوجد ملف إعدادات بلاحقة .nspawn، يحتوي على إعدادات إضافية لتطبيقها عند تشغيل الحاوية. راجع systemd.nspawn(5) للتفاصيل. تتجاوز ملفات الإعدادات الخيارات المبدئية المستخدمة بواسطة ملف وحدة القالب systemd-nspawn@.service، مما يجعل من غير الضروري عادةً تعديل ملف القالب هذا مباشرةً.

لاحظ أن systemd-nspawn سيقوم بوصل أنظمة ملفات خاصة بالحاوية في /dev/ و /run/ وما شابه ذلك. لن تكون هذه مرئية خارج الحاوية، وستُفقد محتوياتها عند خروج الحاوية.

لاحظ أن تشغيل حاويتي systemd-nspawn من نفس شجرة الدليل لن يجعل العمليات فيهما ترى بعضها البعض. إن فصل نطاق أسماء معرفات العمليات (PID) للحاويتين كامل، وستتشارك الحاويات في عدد قليل جداً من كائنات وقت التشغيل باستثناء نظام الملفات الأساسي. بدلاً من ذلك، استخدم أوامر login أو shell الخاصة بـ machinectl(1) لطلب جلسة تسجيل دخول إضافية في حاوية عاملة.

ينفذ systemd-nspawn مواصفات واجهة الحاوية[1].

أثناء التشغيل، تُسجل الحاويات المستدعاة بواسطة systemd-nspawn لدى خدمة systemd-machined(8) التي تتبع الحاويات العاملة، وتوفر واجهات برمجة للتفاعل معها.

العملية غير المميزة¶

يُمكن استدعاء systemd-nspawn بامتيازات أو بدونها. الوظائف الكاملة متاحة حالياً فقط عند الاستدعاء بامتيازات. عند الاستدعاء بدون امتيازات، تُطبق قيود متنوعة، تشمل على سبيل المثال لا الحصر:

•تُدعم فقط الحاويات القائمة على صور الأقراص (أي --image=). أما الحاويات القائمة على الأدلة (أي --directory=) فتُدعم فقط إذا كانت مملوكة لنطاق معرفات المستخدمين (UID) "الأجنبي".

•يُدعم فقط نمطا الشبكة --private-network و --network-veth.

عند التشغيل في النمط غير المميز، تُوفر بعض الوظائف المطلوبة عبر systemd-mountfsd.service(8) و systemd-nsresourced.service(8).

الخيارات¶

إذا حُدد خيار --boot، تُستخدم المعطيات كمعطيات لبرنامج البدء (init). خلاف ذلك، يحدد الأمر البرنامج المراد تشغيله في الحاوية، وتُستخدم المعطيات المتبقية كمعطيات لهذا البرنامج. إذا لم يُستخدم --boot ولم تُحدد أي معطيات، تُشغل صدفة (shell) في الحاوية.

الخيارات التالية مفهومة:

-q، --quiet

يوقف أي مخرجات حالة من الأداة نفسها. عند استخدام هذا المفتاح، سيكون المخرج الوحيد من nspawn هو مخرج الكونسول لنظام تشغيل الحاوية نفسه.

أُضيف في الإصدارة 209.

--settings=النمط

يتحكم فيما إذا كان systemd-nspawn سيبحث عن إعدادات إضافية لكل حاوية من ملفات .nspawn ويستخدمها. يأخذ قيمة منطقية أو القيم الخاصة override أو trusted.

إذا مُكن (وهو المبدئي)، يُبحث عن ملف إعدادات يحمل اسم الآلة (كما هو محدد في إعداد --machine=، أو مشتق من اسم الدليل أو ملف الصورة) باللاحقة .nspawn في /etc/systemd/nspawn/ و /run/systemd/nspawn/. إذا وُجد هناك، تُقرأ إعداداته وتُستخدم. وإذا لم يُعثر عليه هناك، يُبحث عنه لاحقاً في نفس دليل ملف الصورة أو في الدليل الأب المباشر للدليل الجذر للحاوية. في هذه الحالة، إذا وُجد الملف، ستُقرأ إعداداته وتُستخدم أيضاً، ولكن تُتجاهل الإعدادات التي يحتمل أن تكون غير آمنة. لاحظ أنه في كلتا الحالتين، تكون للإعدادات في سطر الأوامر الأسبقية على الإعدادات المقابلة من ملفات .nspawn المحملة، في حال تحديد كليهما. تُعتبر الإعدادات غير آمنة إذا كانت ترفع امتيازات الحاوية أو تمنح الوصول إلى موارد إضافية مثل ملفات أو أدلة المضيف. للحصول على تفاصيل حول تنسيق ومحتويات ملفات .nspawn، استشر systemd.nspawn(5).

إذا ضُبط هذا الخيار على override، يُبحث عن الملف ويُقرأ ويُستخدم بنفس الطريقة، ومع ذلك، يُعكس ترتيب الأسبقية: ستكون للإعدادات المقروءة من ملف .nspawn الأسبقية على خيارات سطر الأوامر المقابلة، في حال تحديد كليهما.

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

إذا عُطل، فلن يُقرأ أي ملف .nspawn ولن تسري أي إعدادات باستثناء تلك الموجودة في سطر الأوامر.

أُضيف في الإصدارة 226.

--cleanup

نظف عمليات الوصل المتبقية ونقاط الوصل الأساسية التي استخدمتها الحاوية، واخرج دون استدعاء أي حاويات. قد يكون هذا مفيداً عندما أُنهي الاستدعاء السابق لـ systemd-nspawn بشكل غير متوقع. يتطلب ذلك واحداً على الأقل من -M/--machine= أو -D/--directory= أو -i/--image= لتحديد عمليات الوصل المراد تنظيفها.

أُضيف في الإصدار 257.

خيارات الصورة¶

-D، --directory=

الدليل المراد استخدامه كجذر لنظام الملفات للحاوية.

إذا لم يُحدد --directory= ولا --image=، فسيُحدد الدليل من خلال البحث عن دليل يحمل نفس اسم الآلة المحدد بـ --machine=. راجع قسم "الملفات والأدلة" في machinectl(1) لمعرفة مسار البحث الدقيق.

بدلاً من مسار الدليل، يُمكن تحديد دليل ذي إصدار ".v/"، راجع systemd.v(7) للتفاصيل.

إذا لم يُحدد لا --directory= ولا --image= ولا --machine=، فسيُستخدم الدليل الحالي. لا يجوز تحديده مع --image=.

--template=

الدليل أو الحجم الفرعي "btrfs" المراد استخدامه كقالب للدليل الجذر للحاوية. إذا حُدد هذا ولم يكن الدليل الجذر للحاوية (كما هو مضبوط بـ --directory=) موجوداً بعد، فيُنشأ كلقطة "btrfs" (إذا كانت مدعومة) أو كدليل عادي (خلاف ذلك) ويُملأ من شجرة القالب هذه. من الناحية المثالية، يشير مسار القالب المحدد إلى جذر حجم فرعي "btrfs"، وفي هذه الحالة تُؤخذ لقطة نسخ عند الكتابة بسيطة، ويكون ملء الدليل الجذر فورياً. إذا لم يكن مسار القالب المحدد يشير إلى جذر حجم فرعي "btrfs" (أو لم يكن حتى على نظام ملفات "btrfs" على الإطلاق)، فستُنسخ الشجرة (على الرغم من احتمال استخدام مخطط نسخ عند الكتابة 'reflink' - إذا كان نظام الملفات يدعم ذلك)، وهو ما قد يستغرق وقتاً أطول بكثير. لاحظ أن اللقطة المأخوذة هي للدليل أو الحجم الفرعي المحدد، بما في ذلك جميع الأدلة الفرعية والأحجام الفرعية الموجودة أسفله، ولكن باستثناء أي عمليات وصل فرعية. لا يجوز تحديده مع --image= أو --ephemeral.

لاحظ أن هذا المفتاح يترك اسم المضيف ومعرف الآلة وجميع الإعدادات الأخرى التي يمكن أن تحدد هوية النسخة دون تعديل.

أُضيف في الإصدارة 219.

-x، --ephemeral

إذا حُدد، ستُشغل الحاوية مع لقطة مؤقتة لنظام ملفاتها والتي تُزال فوراً عند انتهاء الحاوية. لا يجوز تحديده مع --template=.

لاحظ أن هذا المفتاح يترك اسم المضيف ومعرف الآلة وجميع الإعدادات الأخرى التي يمكن أن تحدد هوية النسخة دون تعديل. يرجى ملاحظة أن أخذ اللقطة المؤقتة - كما هو الحال مع --template= - يكون أكثر كفاءة في أنظمة الملفات التي تدعم لقطات الأحجام الفرعية أو 'reflinks' بشكل أصيل ("btrfs" أو "xfs" الجديد) منه في أنظمة الملفات الأكثر تقليدية التي لا تدعمها ("ext4"). لاحظ أن اللقطة المأخوذة هي للدليل أو الحجم الفرعي المحدد، بما في ذلك جميع الأدلة الفرعية والأحجام الفرعية الموجودة أسفله، ولكن باستثناء أي عمليات وصل فرعية.

باستخدام هذا الخيار، لن يُحتفظ بأي تعديلات على صورة الحاوية. استخدم --volatile= (الموضح أدناه) لآليات أخرى لتقييد استمرارية صور الحاويات أثناء وقت التشغيل.

أُضيف في الإصدارة 219.

-i، --image=

صورة قرص لوصل الدليل الجذر للحاوية منها. يأخذ مساراً لملف عادي أو لعقدة جهاز كتلي. يجب أن يحتوي الملف أو الجهاز الكتلي على إما:

•جدول أقسام MBR مع قسم واحد من النوع 0x83 مميز كقابل للإقلاع.

•جدول أقسام GUID ‏(GPT) مع قسم واحد من النوع 0fc63daf-8483-4772-8e79-3d69d8477de4.

•جدول أقسام GUID ‏(GPT) مع قسم جذر مميز يُوصل كدليل جذر للحاوية. اختيارياً، قد تحتوي صور GPT على قسم منزل و/أو قسم بيانات خادم تُوصل إلى الأماكن المناسبة في الحاوية. يجب تحديد جميع هذه الأقسام بواسطة أنواع الأقسام المعرفة في مواصفة الأقسام القابلة للاكتشاف UAPI.2[2].

•لا يوجد جدول أقسام، ونظام ملفات واحد يمتد على كامل الصورة.

في صور GPT، إذا اكتُشف قسم نظام EFI ‏(ESP)، فسيُوصل آلياً في /efi (أو /boot كبديل) في حالة وجود دليل بهذا الاسم وكان فارغاً.

الأقسام المعماة بـ LUKS تُفك تعميتها آلياً. أيضاً، في صور GPT، تُعد أقسام تجزئة سلامة البيانات dm-verity إذا حُددت التجزئة الجذرية لها باستخدام خيار --root-hash=.

يُمكن فتح صور نظام الملفات الواحد (أي أنظمة الملفات بدون جدول أقسام محيط بها) باستخدام dm-verity إذا مُررت بيانات السلامة باستخدام خياري --root-hash= و --verity-data= (واختيارياً --root-hash-sig=).

لا تُوصل أي أقسام أخرى، مثل الأقسام الأجنبية أو أقسام التبديل (swap). لا يجوز تحديده مع --directory= أو --template=.

بدلاً من مسار الصورة، يمكن تحديد دليل بنسخة ".v/"، راجع systemd.v(7) للمزيد من التفاصيل.

أُضيف في الإصدارة 211.

--image-policy=السياسة

يأخذ سلسلة سياسة الصورة كمعطى، وفقاً لـ systemd.image-policy(7). تُطبق السياسة عند العمل على صورة القرص المحددة عبر --image=، راجع أعلاه. إذا لم تُحدد، فستكون المبدئية هي "root=verity+signed+encrypted+unprotected+absent:usr=verity+signed+encrypted+unprotected+absent:home=encrypted+unprotected+absent:srv=encrypted+unprotected+absent:esp=unprotected+absent:xbootldr=unprotected+absent:tmp=encrypted+unprotected+absent:var=encrypted+unprotected+absent"، أي تُستخدم جميع أنظمة الملفات المعترف بها في الصورة، ولكن ليس قسم التبديل.

أُضيف في الإصدار 254.

--mstack=

رصة وصل (Mount stack) لوصل الدليل الجذر للحاوية منها. يأخذ مساراً لدليل ينفذ systemd.mstack(7). يُمكن استخدام هذا لتشغيل حاوية لـ "overlayfs" مجمعة من عدد من الطبقات، وربما قابلة للكتابة ومعززة بعمليات وصل ربط (bind mounts) إضافية.

أُضيف في الإصدار 260.

--oci-bundle=

يأخذ المسار إلى حزمة وقت تشغيل OCI لاستدعائها، كما هو محدد في مواصفة وقت تشغيل OCI[3]. في هذه الحالة، لا يُحمل أي ملف .nspawn، ويُقرأ الدليل الجذر والإعدادات المختلفة من بيانات JSON الخاصة بوقت تشغيل OCI (ولكن البيانات الممرة في سطر الأوامر لها الأسبقية).

أُضيف في الإصدارة 242.

--read-only

صل نظام الملفات الجذر للحاوية (وأي أنظمة ملفات أخرى موجودة في صورة الحاوية) كقراءة فقط. ليس لهذا أي تأثير على عمليات الوصل الإضافية التي تُجرى باستخدام --bind= و --tmpfs= والخيارات المشابهة. يُفترض هذا النمط إذا كان ملف صورة الحاوية أو دليلها مميزاً كقراءة فقط في حد ذاته. كما يُفترض أيضاً إذا استُخدم --volatile=. في هذه الحالة، تكون صورة الحاوية على القرص للقراءة فقط بشكل صارم، بينما يُسمح بالتغييرات ولكن يُحتفظ بها بشكل غير مستمر في الذاكرة فقط. لمزيد من التفاصيل، انظر أدناه.

--volatile، --volatile=النمط

يُقلع الحاوية في النمط المتطاير. عند عدم تمرير معلمة نمط أو عند تحديد النمط كـ yes، يُمكن النمط المتطاير الكامل. وهذا يعني أن الدليل الجذر يُوصل كنسخة "tmpfs" غير مأهولة في الغالب، ويُوصل /usr/ من شجرة نظام التشغيل فيه بنمط القراءة فقط (وبالتالي يبدأ النظام بصورة نظام تشغيل للقراءة فقط، ولكن بحالة وإعدادات بكر، وتُفقد أي تغييرات عند إيقاف التشغيل). عند تحديد معلمة النمط كـ state، تُوصل شجرة نظام التشغيل كقراءة فقط، ولكن يُوصل /var/ كنسخة "tmpfs" قابلة للكتابة فيها (وبالتالي يبدأ النظام بموارد وإعدادات نظام تشغيل للقراءة فقط، ولكن بحالة بكر، وتُفقد أي تغييرات في الأخيرة عند إيقاف التشغيل). عندما تُحدد معلمة النمط كـ overlay، يُدمج نظام الملفات الجذر للقراءة فقط مع نسخة tmpfs قابلة للكتابة عبر "overlayfs"، بحيث يظهر كما هو معتاد، ولكن تُطبق أي تغييرات على نظام الملفات المؤقت فقط وتُفقد عند انتهاء الحاوية. عندما تُحدد معلمة النمط كـ no (وهو المبدئي)، تُتاح شجرة نظام التشغيل بالكامل للكتابة (ما لم يُحدد --read-only، راجع أعلاه).

لاحظ أنه إذا اختير أحد الأنماط المتطايرة، فإن تأثيره يقتصر على نظام الملفات الجذر (أو /var/ في حالة state)، ولا تتأثر أي عمليات وصل أخرى موضوعة في الهيكلية - بغض النظر عما إذا كانت أُنشئت آلياً (مثل قسم نظام EFI الذي قد يُوصل في /efi/ أو /boot/) أو صراحةً (على سبيل المثال من خلال خيار سطر أوامر إضافي مثل --bind=، انظر أدناه). وهذا يعني أنه حتى لو استُخدم --volatile=overlay، فإن التغييرات في /efi/ أو /boot/ محظورة في حالة وجود مثل هذا القسم في صورة الحاوية التي يُعمل عليها، وحتى لو استُخدم --volatile=state فإن الملف الافتراضي /etc/foobar يحتمل أن يكون قابلاً للكتابة إذا استُخدم --bind=/etc/foobar لوصله من خارج دليل /etc/ الخاص بالحاوية الذي هو للقراءة فقط.

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

يوفر خيارا --tmpfs= و --overlay= وظائف مماثلة، ولكن للأدلة الفرعية المحددة لصورة نظام التشغيل فقط. للحصول على تفاصيل، انظر أدناه.

يوفر هذا الخيار وظيفة مماثلة للحاويات كما يوفر مفتاح سطر أوامر النواة "systemd.volatile=" لأنظمة المضيف. راجع kernel-command-line(7) للتفاصيل.

لاحظ أن ضبط هذا الخيار على yes أو state لن يعمل بشكل صحيح إلا مع أنظمة التشغيل في الحاوية التي يمكنها الإقلاع مع وصل /usr/ فقط، وتكون قادرة على ملء /var/ آلياً (و /etc/ في حالة "--volatile=yes"). وتحديداً، هذا يعني أن أنظمة التشغيل التي تتبع الفصل التاريخي لـ /bin/ و /lib/ (والأدلة ذات الصلة) عن /usr/ (أي حيث لا تكون الأولى روابط رمزية في الأخيرة) ليست مدعومة بواسطة "--volatile=yes" كحمولة للحاوية. لا يتطلب خيار overlay أي استعدادات خاصة في نظام التشغيل، ولكن لاحظ أن سلوك "overlayfs" يختلف عن أنظمة الملفات العادية في عدد من النواحي، وبالتالي فإن التوافق محدود.

أُضيف في الإصدارة 216.

--root-hash=

يأخذ تجزئة جذرية لسلامة البيانات (dm-verity) محددة بالنظام الست عشري. يُمكن هذا الخيار عمليات فحص سلامة البيانات باستخدام dm-verity، إذا كانت الصورة المستخدمة تحتوي على بيانات السلامة المناسبة (راجع أعلاه). يجب أن تطابق التجزئة المحددة التجزئة الجذرية لبيانات السلامة، وتكون عادةً بطول 256 بت على الأقل (وبالتالي 64 محرفاً ست عشرياً منسقاً) (في حالة SHA256 على سبيل المثال). إذا لم يُحدد هذا الخيار، ولكن كان ملف الصورة يحمل سمة الملف الموسعة "user.verity.roothash" (راجع xattr(7))، فستُقرأ التجزئة الجذرية منها، أيضاً كمحارف ست عشرية منسقة. إذا لم يُعثر على سمة الملف الموسعة (أو لم تكن مدعومة من قبل نظام الملفات الأساسي)، ولكن وُجد ملف بلاحقة .roothash بجوار ملف الصورة، يحمل بخلاف ذلك نفس الاسم (إلا إذا كانت الصورة بلاحقة .raw، وفي هذه الحالة يجب ألا يحمل ملف التجزئة الجذرية هذه اللاحقة في اسمه)، فستُقرأ التجزئة الجذرية منه وتُستخدم آلياً، أيضاً كمحارف ست عشرية منسقة.

لاحظ أن هذا يضبط التجزئة الجذرية لنظام الملفات الجذر. قد تحتوي صور الأقراص أيضاً على أنظمة ملفات منفصلة لهيكلية /usr/، والتي قد تكون محمية بـ Verity أيضاً. يُمكن ضبط التجزئة الجذرية لهذه الحماية عبر سمة الملف الموسعة "user.verity.usrhash" أو عبر ملف .usrhash مجاور لصورة القرص، باتباع نفس التنسيق والمنطق الخاص بالتجزئة الجذرية لنظام الملفات الجذر الموضح هنا. لاحظ أنه لا يوجد حالياً مفتاح لضبط التجزئة الجذرية لـ /usr/ من سطر الأوامر.

انظر أيضاً خيار RootHash= في systemd.exec(5).

أُضيف في الإصدار 233.

--root-hash-sig=

يأخذ توقيع PKCS7 لخيار --root-hash=. المعاني هي نفسها لخيار RootHashSignature=، راجع systemd.exec(5).

أُضيف في الإصدار 246.

--verity-data=

يأخذ المسار إلى ملف سلامة البيانات (dm-verity). يُمكن هذا الخيار عمليات فحص سلامة البيانات باستخدام dm-verity، إذا مُررت تجزئة جذرية وإذا لم تكن الصورة المستخدمة نفسها تحتوي على بيانات السلامة. يجب أن تطابق التجزئة الجذرية بيانات السلامة. إذا لم يُحدد هذا الخيار، ولكن وُجد ملف بلاحقة .verity بجوار ملف الصورة، يحمل بخلاف ذلك نفس الاسم (إلا إذا كانت الصورة بلاحقة .raw، وفي هذه الحالة يجب ألا يحمل ملف بيانات verity هذه اللاحقة في اسمه)، فستُقرأ بيانات verity منه وتُستخدم آلياً.

أُضيف في الإصدار 246.

--pivot-root=

يعمل على تدوير الدليل المحدد إلى / داخل الحاوية، وإما أن يفصل الجذر القديم للحاوية، أو يدوره إلى دليل محدد آخر. يقبل أحد الخيارين: إما مسارًا — وفي هذه الحالة سيُدير المسار المحدد إلى / ويُفصل الجذر القديم؛ أو زوجًا مفصولًا بنقطتين من مسار الجذر الجديد ووجهة التدوير للجذر القديم. سيُدير مسار الجذر الجديد إلى /، ويُدير / القديم إلى الدليل الآخر. يجب أن يكون كلا المسارين مطلقين، ويُحللان في مساحة أسماء نظام ملفات الحاوية.

هذا مخصص للحاويات التي تحتوي على عدة أدلة قابلة للإقلاع؛ على سبيل المثال، عدة عمليات نشر لـ ostree(1). وهو يحاكي سلوك محمل الإقلاع و initrd اللذين يختاران عادةً أي دليل يوصل كجذر ويبدآن فيه PID 1 الخاص بالحاوية.

أُضيف في الإصدار 233.

خيارات التنفيذ¶

-a، --as-pid2

استدعِ الصدفة أو البرنامج المحدد كمعرف عملية (PID) 2 بدلاً من PID 1 (init). مبدئيًا، إذا لم يُستخدم هذا الخيار ولا --boot، فسيُشغل البرنامج المحدد كعملية بـ PID 1، وهو وضع مناسب فقط للبرامج التي تدرك الدلالات الخاصة التي تتمتع بها العملية ذات PID 1 في UNIX. على سبيل المثال، تحتاج إلى حصد جميع العمليات التي أعيد إسنادها إليها، ويجب أن تنفذ معالجة إشارات متوافقة مع sysvinit (تحديدًا: تحتاج إلى إعادة التشغيل عند استقبال SIGINT، وإعادة التنفيذ عند SIGTERM، وإعادة تحميل التكوين عند SIGHUP، وما إلى ذلك). مع --as-pid2، تُشغل عملية init بديلة مبسطة كـ PID 1 ويُنفذ البرنامج المختار كـ PID 2 (وبالتالي لا يحتاج إلى تنفيذ أي دلالات خاصة). ستقوم عملية init البديلة بحصد العمليات حسب الضرورة والتفاعل بشكل مناسب مع الإشارات. يُوصى باستخدام هذا الوضع لاستدعاء أوامر عشوائية في الحاويات، ما لم تكن قد عُدلت لتعمل بشكل صحيح كـ PID 1. بعبارة أخرى: يجب استخدام هذا المفتاح لكل الأوامر تقريبًا، إلا عندما يشير الأمر إلى تنفيذ init أو صدفة، حيث إنها قادرة بشكل عام على العمل بشكل صحيح كـ PID 1. لا يجوز دمج هذا الخيار مع --boot.

أُضيف في الإصدارة 229.

-b، --boot

ابحث آليًا عن برنامج init واستدعه كـ PID 1، بدلاً من صدفة أو برنامج يقدمه المستخدم. إذا استُخدم هذا الخيار، فستُستخدم المعاملات المحددة في سطر الأوامر كمعاملات لبرنامج init. لا يجوز دمج هذا الخيار مع --as-pid2.

يوضح الجدول التالي أوضاع الاستدعاء المختلفة وعلاقتها بـ --as-pid2 (انظر أعلاه):

الجدول 1. وضع الاستدعاء

المفتاح	الشرح
لم يُحدد --as-pid2 ولا --boot	تُفسر المعاملات الممررة كسطر أوامر، ويُنفذ كـ PID 1 في الحاوية.
حُدد --as-pid2	تُفسر المعاملات الممررة كسطر أوامر، ويُنفذ كـ PID 2 في الحاوية. تُشغل عملية init بديلة كـ PID 1.
حُدد --boot	يُبحث آليًا عن برنامج init ويُشغل كـ PID 1 في الحاوية. تُستخدم المعاملات الممررة كمعاملات استدعاء لهذه العملية.

لاحظ أن --boot هو وضع التشغيل المبدئي إذا استُخدم ملف وحدة القالب systemd-nspawn@.service.

--chdir=

انتقل إلى دليل العمل المحدد قبل استدعاء العملية في الحاوية. يتوقع مسارًا مطلقًا في مساحة أسماء نظام ملفات الحاوية.

أُضيف في الإصدارة 229.

-E الاسم[=القيمة]، --setenv=الاسم[=القيمة]

يحدد متغير بيئة لتمريره إلى عملية init في الحاوية. يمكن استخدام هذا لتخطي المتغيرات المبدئية أو لضبط متغيرات إضافية. يمكن استخدامه أكثر من مرة لضبط متغيرات متعددة. عند حذف "=" و القيمة، ستُستخدم قيمة المتغير الذي يحمل نفس الاسم في بيئة البرنامج.

أُضيف في الإصدارة 209.

-u، --user=

بعد الانتقال إلى الحاوية، انتقل إلى المستخدم المحدد والمعرّف في قاعدة بيانات مستخدمي الحاوية. مثل جميع ميزات systemd-nspawn الأخرى، هذه ليست ميزة أمنية وتوفر الحماية ضد العمليات التدميرية العرضية فقط.

لاحظ أنه إذا استُخدمت بيانات الاعتماد مع --user= غير الجذر (مثال: --set-credential= أو --load-credential=)، فيجب استخدام --no-new-privileges=yes، ويجب عدم استخدام --boot أو --as-pid2، وإلا فلن تتمكن الحاوية من قراءة بيانات الاعتماد بسبب نقص الامتيازات بعد التبديل إلى المستخدم المحدد.

--kill-signal=

حدد إشارة العملية لإرسالها إلى PID 1 الخاص بالحاوية عندما يتلقى nspawn نفسه إشارة SIGTERM، من أجل إطلاق إغلاق منظم للحاوية. القيمة المبدئية هي SIGRTMIN+3 إذا استُخدم --boot (في أنظمة init المتوافقة مع systemd تطلق SIGRTMIN+3 إغلاقًا منظمًا). إذا لم يُستخدم --boot ولم يُحدد هذا الخيار، فستُنهى عمليات الحاوية فجأة عبر SIGKILL. للحصول على قائمة بالإشارات الصحيحة، انظر signal(7).

أُضيف في الإصدارة 220.

--notify-ready=

يضبط دعم الإشعارات من عملية init الخاصة بالحاوية. يقبل --notify-ready= قيمة منطقية. إذا كانت false (خطأ)، يُشعر systemd-nspawn مدير الخدمة المستدعِي برسالة "READY=1" عند إنشاء عملية init. إذا كانت true (صواب)، فإنه ينتظر رسالة "READY=1" من عملية init في الجهاز الافتراضي قبل إرسال رسالته الخاصة إلى مدير الخدمة. لمزيد من التفاصيل حول الإشعارات، انظر sd_notify(3).

القيمة المبدئية هي false. (لاحظ أن هذا يختلف عن الخيار الذي يحمل نفس الاسم في systemd-vmspawn(1) حيث تكون قيمته المبدئية true.)

أُضيف في الإصدارة 231.

--suppress-sync=

يتوقع معاملًا منطقيًا. إذا كان صوابًا، فإنه يوقف أي شكل من أشكال مزامنة نظام الملفات على القرص لحمولة الحاوية. وهذا يعني أن جميع استدعاءات النظام مثل sync(2)، و fsync()‎، و syncfs()‎، و ... لن تنفذ أي عملية، وستصبح أعلام O_SYNC/O_DSYNC لـ open(2) والاستدعاءات ذات الصلة غير متاحة. هذا خطير محتمل، حيث إن ضمانات سلامة البيانات المفترضة لحمولة الحاوية لا تُفرض فعليًا (أي أن البيانات المفترض كتابتها على القرص قد تُفقد إذا أُغلق النظام بشكل غير طبيعي). ومع ذلك، يمكن أن يحسن هذا أداء وقت تشغيل الحاوية بشكل كبير – طالما أن هذه الضمانات ليست مطلوبة أو مرغوبًا فيها، على سبيل المثال لأن أي بيانات تكتبها الحاوية هي ذات طبيعة مؤقتة وزائدة عن الحاجة، أو مجرد أثر وسيط سيُعالج ويُنهى في خطوة لاحقة في خط الأنابيب. القيمة المبدئية هي false.

أُضيف في الإصدار 250.

خيارات هوية النظام¶

-M، --machine=

يضبط اسم الجهاز لهذه الحاوية. قد يُستخدم هذا الاسم لتمييز هذه الحاوية أثناء وقت تشغيلها (على سبيل المثال في أدوات مثل machinectl(1) وما شابه)، ويُستخدم لتهيئة اسم مضيف الحاوية (والذي يمكن للحاوية اختيار تخطيه، رغم ذلك). إذا لم يُحدد، فسيُستخدم المكون الأخير من مسار الجذر للحاوية، مع إمكانية إلحاقه بمعرف عشوائي في حال اختيار وضع --ephemeral. إذا كان الدليل الجذري المختار هو الجذر للمضيف، فسيُستخدم اسم مضيف المضيف كمبدئي بدلاً من ذلك.

أُضيف في الإصدارة 202.

--hostname=

يتحكم في اسم المضيف المراد ضبطه داخل الحاوية، إذا كان مختلفًا عن اسم الجهاز. يتوقع اسم مضيف صالحًا كمعامل. إذا استُخدم هذا الخيار، فسيُضبط اسم مضيف النواة للحاوية على هذه القيمة، وإلا فستُهيأ باسم الجهاز كما هو محدد بواسطة خيار --machine= الموضح أعلاه. يُستخدم اسم الجهاز لجوانب مختلفة من تحديد هوية الحاوية من الخارج، بينما اسم مضيف النواة القابل للضبط بهذا الخيار مفيد للحاوية لتحديد هويتها من الداخل. من الجيد عادةً إبقاء كلا الشكلين من تحديد الهوية متزامنين لتجنب الارتباك. ومن ثم يُوصى بتجنب استخدام هذا الخيار، واستخدام --machine= حصريًا. لاحظ أنه بغض النظر عما إذا كان اسم مضيف الحاوية قد هُيئ من الاسم المضبوط بـ --hostname= أو الاسم المضبوط بـ --machine=، يمكن للحاوية لاحقًا تخطي اسم مضيف النواة الخاص بها بحرية أيضًا.

أُضيف في الإصدار 239.

--uuid=

اضبط UUID المحدد للحاوية. سيقوم نظام init بتهيئة /etc/machine-id من هذا إذا لم يكن هذا الملف قد ضبط بعد. لاحظ أن هذا الخيار يسري فقط إذا كان ملف /etc/machine-id في الحاوية فارغًا.

خيارات الخاصية¶

-S، --slice=

اجعل الحاوية جزءًا من الشريحة المحددة، بدلاً من machine.slice المبدئية. ينطبق هذا فقط إذا كان الجهاز يعمل في وحدة النطاق (scope unit) الخاصة به، أي إذا لم يُستخدم --keep-unit.

أُضيف في الإصدارة 206.

--property=

اضبط خاصية وحدة على وحدة النطاق للتسجيل للجهاز. ينطبق هذا فقط إذا كان الجهاز يعمل في وحدة النطاق الخاصة به، أي إذا لم يُستخدم --keep-unit. يقبل تعيينات خصائص الوحدة بنفس تنسيق systemctl set-property. هذا مفيد لضبط حدود الذاكرة وما شابه ذلك للحاوية.

أُضيف في الإصدارة 220.

--register=

يتحكم فيما إذا كانت الحاوية مسجلة لدى systemd-machined(8). يقبل معاملًا منطقيًا، قيمته المبدئية "yes". ينبغي تمكين هذا الخيار عندما تشغل الحاوية نظام تشغيل كاملًا (بشكل أكثر تحديدًا: مدير نظام وخدمات كـ PID 1)، وهو مفيد لضمان إمكانية الوصول إلى الحاوية عبر machinectl(1) وظهورها في أدوات مثل ps(1). إذا كانت الحاوية لا تشغل مدير خدمات، فيُوصى بضبط هذا الخيار على "no".

أُضيف في الإصدارة 209.

--keep-unit

بدلاً من إنشاء وحدة نطاق عابرة لتشغيل الحاوية فيها، استخدم ببساطة وحدة الخدمة أو النطاق التي استُدعي فيها systemd-nspawn. إذا ضُبط --register=yes فستُسجل هذه الوحدة لدى systemd-machined(8). ينبغي استخدام هذا المفتاح إذا استُدعي systemd-nspawn من داخل وحدة خدمة، وكان الغرض الوحيد من وحدة الخدمة هو تشغيل حاوية systemd-nspawn واحدة. هذا الخيار غير متاح إذا شُغل من جلسة مستخدم.

لاحظ أن تمرير --keep-unit يعطل مفعول --slice= و --property=. استخدم --keep-unit و --register=no معًا لتعطيل أي نوع من تخصيص الوحدات أو التسجيل لدى systemd-machined.

أُضيف في الإصدارة 209.

خيارات مساحات أسماء المستخدمين¶

--private-users=

يتحكم في مساحات أسماء المستخدمين. إذا مُكن، فستعمل الحاوية بمجموعتها الخاصة من معرفات المستخدمين والمجموعات في UNIX (UIDs و GIDs). يتضمن ذلك رسم خرائط لـ UIDs/GIDs الخاصة المستخدمة في الحاوية (بدءًا من المستخدم الجذر للحاوية 0 فصاعدًا) إلى نطاق من UIDs/GIDs على المضيف غير مستخدمة لأغراض أخرى (عادةً في النطاق الذي يتجاوز UID/GID 65536 للمضيف). يمكن تحديد المعامل كما يلي:

1.إذا حُدد رقم واحد أو رقمان مفصولان بنقطتين، فسيُفعل تقسيم مساحة أسماء المستخدمين. يحدد المعامل الأول أول UID/GID للمضيف ليُخصص للحاوية، ويحدد المعامل الثاني عدد UIDs/GIDs للمضيف المخصصة للحاوية. إذا حُذف المعامل الثاني، يُخصص 65536 UID/GID.

2.إذا كان المعامل "yes"، يُفعل تقسيم مساحة أسماء المستخدمين. يُحدد نطاق UID/GID المراد استخدامه آليًا من ملكية ملفات الدليل الجذري لشجرة أدلة الحاوية. لاستخدام هذا الخيار، تأكد من إعداد شجرة الأدلة مسبقًا، وتأكد من أن جميع الملفات والأدلة فيها مملوكة لـ UIDs/GIDs في النطاق الذي ترغب في استخدامه. تأكد أيضًا من أن قوائم التحكم في الوصول (ACLs) للملفات المستخدمة تشير حصريًا إلى UIDs/GIDs في النطاق المناسب. في هذا الوضع، يكون عدد UIDs/GIDs المخصصة للحاوية هو 65536، ويجب أن يكون UID/GID لمالك الدليل الجذري من مضاعفات 65536.

3.القيمة الخاصة "pick" تفعل تقسيم مساحة أسماء المستخدمين. في هذه الحالة، يُختار نطاق UID/GID آليًا. كخطوة أولى، تُقرأ ملكية UID/GID لملف الدليل الجذري لشجرة أدلة الحاوية، ويُتحقق من عدم وجود حاوية أخرى تستخدمه حاليًا. إذا نجح هذا التحقق، يُستخدم نطاق UID/GID المحدد بهذه الطريقة، على غرار السلوك عند تحديد "yes". إذا لم ينجح التحقق (وبالتالي فإن نطاق UID/GID المشار إليه في مالك ملف الدليل الجذري مستخدم بالفعل في مكان آخر) فيُختار نطاق UID/GID جديد – غير مستخدم حاليًا – يبلغ 65536 UID/GID عشوائيًا بين UID/GIDs للمضيف من 524288 و 1878982656، ويبدأ دائمًا بمضاعف لـ 65536، وإذا أمكن، يُشتق بشكل متسق من اسم الجهاز. هذا الضبط يتضمن --private-users-ownership=auto (انظر أدناه)، وهو ما قد يؤدي إلى جعل الملفات والأدلة في شجرة أدلة الحاوية مملوكة للمستخدمين المناسبين في النطاق المختار. استخدام هذا الخيار يجعل سلوك مساحة أسماء المستخدمين آليًا بالكامل. لاحظ أن الاستدعاء الأول لصورة حاوية لم تكن مستخدمة مسبقًا قد يؤدي إلى اختيار نطاق UID/GID جديد لها، وبالتالي عملية (ربما تكون مكلفة) لتعديل ملكية الملفات. ومع ذلك، ستكون الاستدعاءات اللاحقة للحاوية زهيدة التكلفة (إلا إذا خُصص نطاق UID/GID المختار لاستخدام آخر بحلول ذلك الوقت).

4.إذا كان المعامل "no"، يُعطل تقسيم مساحة أسماء المستخدمين. هذا هو المبدئي عند استدعاء systemd-nspawn مباشرةً. (لاحظ أن وحدة systemd-nspawn@.service تمكن المستخدمين الخاصين). هذا الخيار ليس آمنًا ويجب عدم استخدامه لتشغيل كود غير موثوق به.

5.إذا كان المعامل "identity"، يُستخدم تقسيم مساحة أسماء المستخدمين مع رسم خرائط هوية لأول 65536 UID/GID. هذا يعادل في الغالب --private-users=0:65536. وبينما لا يوفر عزلاً لـ UID/GID، نظرًا لاختيار جميع UID/GIDs للمضيف والحاوية بشكل متطابق، فإنه يوفر عزلاً لقدرات العملية، ولكنه قد يكون مفيدًا إذا لم يكن التقسيم الصحيح لمساحة الأسماء بخرائط UID متميزة ممكنًا. هذا الخيار ليس آمنًا ويجب عدم استخدامه لتشغيل كود غير موثوق به.

6.إذا كان المعامل "managed"، يُستخدم تقسيم مساحة أسماء المستخدمين في وضع مُدار، أي يُفوض تخصيص نطاق UID إلى systemd-nsresourced.service(8). يُختار هذا الوضع مبدئيًا إذا استُدعي دون امتيازات، ولكن يمكن طلبه صراحةً عند التمتع بالامتيازات. في هذا الوضع، يُختار نطاق UID يبلغ 64K آليًا.

يُوصى بتخصيص 65536 UID/GID على الأقل لكل حاوية، بحيث يغطي نطاق UID/GID القابل للاستخدام في الحاوية 16 بت. ولتحقيق أفضل أمن، لا تخصص نطاقات UID/GID متداخلة لحاويات متعددة. ومن الجيد استخدام الـ 16 بت العلوية من الـ 32 بت لـ UID/GIDs للمضيف كمعرف للحاوية، بينما تشفر الـ 16 بت السفلية الـ UID/GID المستخدم للحاوية. هذا هو السلوك الذي يفرضه خيار --private-users=pick بالفعل.

عند استخدام مساحات أسماء المستخدمين، يُختار نطاق GID المخصص لكل حاوية دائمًا ليكون مطابقًا لنطاق UID.

في معظم الحالات، يُوصى بخيار --private-users=managed (أو --private-users=pick أيضًا عند التمتع بالامتيازات) حيث يُنصح بتقسيم مساحات أسماء المستخدمين لأسباب أمنية، ويعزز هذا الخيار أمن الحاوية بشكل هائل مع العمل آليًا بالكامل في معظم الحالات.

لاحظ أن نطاق UID/GID المختار لا يُكتب في /etc/passwd أو /etc/group. في الواقع، لا يُخزن تخصيص النطاق بشكل مستمر، إلا ربما في ملكية الملفات والأدلة الخاصة بالحاوية، انظر --private-users-ownership=.

لاحظ أنه عند استخدام تقسيم مساحة أسماء المستخدمين دون رسم خرائط UID (انظر أدناه)، فإن ملكية الملفات على القرص تعكس ذلك، وجميع ملفات وأدلة الحاوية تكون مملوكة لمعرفات المستخدم والمجموعة الفعالة للحاوية. وهذا يعني أن نسخ الملفات من وإلى صورة الحاوية يتطلب تصحيح قيم UID/GID العددية، وفقًا لإزاحة UID/GID المطبقة.

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

أُضيف في الإصدارة 220.

--private-users-ownership=

يتحكم في كيفية تعديل UIDs و GIDs لصورة الحاوية لتطابق نطاق UID/GID المختار باستخدام --private-users=، انظر أعلاه. يقبل أحد الخيارات: "off" (لترك الصورة كما هي)، أو "chown" (للقيام بـ chown()‎ متكرر لشجرة أدلة الحاوية حسب الحاجة)، أو "map" (من أجل استخدام وصلات تعيين المعرف الشفافة من UID 0 إلى نطاق UID المستهدف)، أو "foreign" (نفس الشيء، ولكن من قاعدة نطاق UID الأجنبية) أو "auto" لاستخدام "map" أو "foreign" آليًا حيثما كان متاحًا ومناسبًا و "chown" حيثما لم يكن كذلك.

إذا اختير "chown"، فستُعدل جميع الملفات والأدلة في شجرة أدلة الحاوية بحيث تصبح مملوكة لـ UIDs/GIDs المناسبة المختارة للحاوية (انظر أعلاه). هذه العملية مكلفة محتملًا، لأنها تتضمن المرور عبر شجرة أدلة الحاوية بالكامل. إلى جانب ملكية الملفات الفعلية، تُعدل أيضًا قوائم التحكم في الوصول (ACLs) للملفات.

عادة ما يكون "foreign" أو "map" هو الخيار الأفضل، لأنه يعين UIDs/GIDs بشفافية في الذاكرة حسب الحاجة دون تعديل الصورة، ودون الحاجة إلى عملية تعديل متكررة مكلفة. ومع ذلك، فهو غير متاح لجميع أنظمة الملفات حاليًا.

خيار --private-users-ownership=auto مُتضمن إذا استُخدم --private-users=pick. ليس لهذا الخيار أي تأثير إذا لم يُستخدم تقسيم مساحة أسماء المستخدمين.

يمكن استخدام مفتاح --shift الخاص بـ systemd-dissect(1) لإزاحة ملكية UID/GID من أو إلى القاعدة 0، أو القاعدة الأجنبية، أو قاعدة UID/GID محددة للحاوية خارج أي استدعاء لـ systemd-nspawn.

أُضيف في الإصدارة 230.

--private-users-delegate=

يقبل عددًا صحيحًا غير سالب. يطلب تفويض العدد المحدد من نطاقات UID/GID الإضافية سعة 64K إلى مساحة أسماء المستخدمين للحاوية. تُعين هذه النطاقات المفوضة بنسبة 1:1 (أي تُستخدم نفس قيم UID/GID داخل مساحة أسماء المستخدمين وخارجها) ويمكن استخدامها بواسطة الحاويات المتداخلة لتخصيص نطاقات UID/GID العابرة الخاصة بها عبر systemd-nsresourced.service(8).

يتطلب هذا الخيار --private-users=managed، حيث يُجرى التفويض بواسطة systemd-nsresourced.service(8) كجزء من تخصيص مساحة أسماء المستخدمين. أقصى عدد من النطاقات المفوضة هو 16. القيمة المبدئية هي 0، أي لا تفويض.

عند استخدام هذا الخيار بقيمة غير صفرية، يُوصل مقبس Varlink لخدمة systemd-nsresourced.service(8) في المسار (/run/systemd/io.systemd.NamespaceResource) آليًا داخل الحاوية مع روابط الاكتشاف الرمزية اللازمة في /run/systemd/userdb/ و /run/varlink/registry/. يسمح هذا للعمليات داخل الحاوية بالتراسل مع systemd-nsresourced على المضيف لتخصيص مساحات أسماء مستخدمين متداخلة من النطاقات المفوضة.

أُضيف في الإصدار 260.

-U

إذا كانت النواة تدعم ميزة مساحات أسماء المستخدمين، فإنه يعادل --private-users=pick --private-users-ownership=auto، وإلا فإنه يعادل --private-users=no.

لاحظ أن -U هو المبدئي إذا استُخدم ملف وحدة القالب systemd-nspawn@.service.

ملاحظة: من الممكن التراجع عن تأثير --private-users-ownership=chown (أو -U) على نظام الملفات عن طريق إعادة العملية مع أول UID بقيمة 0:

systemd-nspawn ... --private-users=0 --private-users-ownership=chown

أُضيف في الإصدارة 230.

خيارات الشبكة¶

--private-network

افصل شبكة الحاوية عن المضيف. يؤدي هذا إلى جعل جميع واجهات الشبكة غير متاحة في الحاوية، باستثناء جهاز loopback وتلك المحددة بـ --network-interface= والمضبوطة بـ --network-veth. إذا حُدد هذا الخيار، فستُضاف قدرة CAP_NET_ADMIN إلى مجموعة القدرات التي تحتفظ بها الحاوية. يمكن تعطيل الأخيرة باستخدام --drop-capability=. إذا لم يُحدد هذا الخيار (أو لم يكن متضمنًا في أحد الخيارات المدرجة أدناه)، فستتمتع الحاوية بوصول كامل إلى شبكة المضيف.

--network-interface=

خصص واجهة الشبكة المحددة للحاوية. يقبل إما اسم واجهة واحد، يشير إلى الاسم على المضيف، أو زوجًا من الواجهات مفصولاً بنقطتين، وفي هذه الحالة يشير الأول إلى الاسم على المضيف، والثاني إلى الاسم في الحاوية. عندما تنتهي الحاوية، تُنقل الواجهة مرة أخرى إلى مساحة الأسماء المستدعِية ويعاد تسميتها إلى اسمها الأصلي. لاحظ أن --network-interface= يتضمن --private-network. يمكن استخدام هذا الخيار أكثر من مرة لإضافة واجهات شبكة متعددة إلى الحاوية.

لاحظ أن أي واجهة شبكة محددة بهذه الطريقة يجب أن تكون موجودة بالفعل في وقت بدء الحاوية. إذا كان من المقرر بدء الحاوية آليًا عند الإقلاع عبر نسخة من ملف وحدة systemd-nspawn@.service، فقد يكون من المنطقي إضافة ملف وحدة تكميلي (drop-in) إلى نسخة الخدمة (مثل: /etc/systemd/system/systemd-nspawn@foobar.service.d/50-network.conf) بمحتويات مثل ما يلي:

[Unit]
Wants=sys-subsystem-net-devices-ens1.device
After=sys-subsystem-net-devices-ens1.device

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

أُضيف في الإصدارة 209.

--network-macvlan=

أنشئ واجهة "macvlan" لواجهة شبكة الإيثرنت المحددة وأضفها إلى الحاوية. يقبل إما اسم واجهة واحد، يشير إلى الاسم على المضيف، أو زوجًا من الواجهات مفصولاً بنقطتين، وفي هذه الحالة يشير الأول إلى الاسم على المضيف، والثاني إلى الاسم في الحاوية. واجهة "macvlan" هي واجهة افتراضية تضيف عنوان MAC ثانيًا لرابط إيثرنت مادي موجود. إذا لم يُحدد اسم واجهة الحاوية، فسيُسمى الواجهة في الحاوية باسم الواجهة على المضيف مسبوقًا بـ "mv-". لاحظ أن --network-macvlan= يتضمن --private-network. يمكن استخدام هذا الخيار أكثر من مرة لإضافة واجهات شبكة متعددة إلى الحاوية.

كما هو الحال مع --network-interface=، يجب أن تكون واجهة شبكة إيثرنت الأساسية موجودة بالفعل وقت بدء تشغيل الحاوية، وبالتالي قد تكون ملفات الإقحام المماثلة لوحدات الخدمة كما هو موضح أعلاه مفيدة.

أُضيف في الإصدارة 211.

--network-ipvlan=

أَنْشِئ واجهة "ipvlan" لواجهة شبكة إيثرنت المحددة وأضفها إلى الحاوية. يأخذ الخيار إما اسماً واحداً لواجهة، يشير إلى الاسم على المضيف، أو زوجاً من الواجهات مفصولاً بنقطتين، وفي هذه الحالة يشير الأول إلى الاسم على المضيف، والثاني إلى الاسم في الحاوية. واجهة "ipvlan" هي واجهة افتراضية، تشبه واجهة "macvlan"، وتستخدم نفس عنوان MAC للواجهة الأساسية. إذا لم يُعرَّف اسم واجهة الحاوية، فستُسمى الواجهة في الحاوية باسم الواجهة على المضيف مسبوقة بـ "iv-". لاحظ أن --network-ipvlan= يقتضي --private-network. يمكن استخدام هذا الخيار أكثر من مرة لإضافة واجهات شبكة متعددة إلى الحاوية.

أُضيف في الإصدارة 219.

-n، --network-veth

أَنْشِئ رابط إيثرنت افتراضي ("veth") بين المضيف والحاوية. سيكون جانب المضيف من رابط الإيثرنت متاحاً كواجهة شبكة تسمى باسم الحاوية (كما هو محدد بواسطة --machine=)، مسبوقاً بـ "ve-". وسيُطلق على جانب الحاوية من رابط الإيثرنت اسم "host0". يقتضي الخيار --network-veth الخيار --private-network.

لاحظ أن systemd-networkd.service(8) يتضمن افتراضياً ملف شبكة /usr/lib/systemd/network/80-container-ve.network يطابق الواجهات من جانب المضيف المنشأة بهذه الطريقة، والذي يحتوي على إعدادات لتمكين التزويد الآلي للعناوين على الرابط الافتراضي المنشأ عبر DHCP، بالإضافة إلى التوجيه الآلي لبروتوكول IP إلى واجهات الشبكة الخارجية للمضيف. كما يحتوي أيضاً على /usr/lib/systemd/network/80-container-host0.network الذي يطابق الواجهة من جانب الحاوية المنشأة بهذه الطريقة، ويحتوي على إعدادات لتمكين تعيين العناوين من جانب العميل عبر DHCP. في حال كان systemd-networkd يعمل على كل من المضيف وداخل الحاوية، فإن اتصال IP الآلي من الحاوية إلى المضيف يكون متاحاً بذلك، مع إمكانية اتصال أوسع بالشبكة الخارجية.

لاحظ أن --network-veth هو المبدئي في حال استخدم ملف وحدة القالب systemd-nspawn@.service.

لاحظ أن أسماء واجهات الشبكة في لينكس قد يبلغ طولها 15 محرفاً كحد أقصى، بينما قد يصل طول أسماء الحاويات إلى 64 محرفاً. وبما أن هذا الخيار يشتق اسم الواجهة من جانب المضيف من اسم الحاوية، فمن المحتمل أن يُبتر الاسم. لذا، يجب توخي الحذر لضمان بقاء أسماء الواجهات فريدة في هذه الحالة، أو الأفضل من ذلك عدم اختيار أسماء حاويات أطول من 12 محرفاً بشكل عام لتجنب البتر. إذا بُتر الاسم، فسيقوم systemd-nspawn آلياً بإلحاق قيمة هاش مكونة من 4 أرقام بالاسم لتقليل فرصة حدوث تصادمات. ومع ذلك، فإن خوارزمية الهاش ليست خالية تماماً من التصادمات. (انظر systemd.net-naming-scheme(7) للحصول على تفاصيل حول خوارزميات التسمية الأقدم لهذه الواجهة). بدلاً من ذلك، يمكن استخدام الخيار --network-veth-extra=، والذي يسمح بضبط حر لاسم الواجهة من جانب المضيف بشكل مستقل عن اسم الحاوية — ولكن قد يتطلب القليل من الإعداد الإضافي في حال الرغبة في التجسير بطريقة مماثلة لـ --network-bridge=.

أُضيف في الإصدارة 209.

--network-veth-extra=

يضيف رابط إيثرنت افتراضي إضافي بين المضيف والحاوية. يأخذ زوجاً مفصولاً بنقطتين من اسم واجهة المضيف واسم واجهة الحاوية. يمكن حذف الأخير وفي هذه الحالة سيُعين نفس الاسم لجانبي الحاوية والمضيف. هذا المفتاح مستقل عن --network-veth، و — على النقيض — يمكن استخدامه عدة مرات، ويسمح بضبط أسماء واجهات الشبكة. لاحظ أن --network-bridge= ليس له أي تأثير على الواجهات المنشأة باستخدام --network-veth-extra=.

أُضيف في الإصدارة 228.

--network-bridge=

يضيف جانب المضيف من رابط الإيثرنت المنشأ باستخدام --network-veth إلى واجهة جسر إيثرنت المحددة. يتوقع اسم واجهة شبكة صالحاً لجهاز جسر كمعامل. لاحظ أن --network-bridge= يقتضي --network-veth. إذا استُخدم هذا الخيار، فسيستخدم جانب المضيف لرابط الإيثرنت البادئة "vb-" بدلاً من "ve-". بغض النظر عن بادئة التسمية المستخدمة، تنطبق نفس حدود طول اسم واجهة الشبكة التي يفرضها لينكس، جنباً إلى جنب مع التعقيدات التي يخلقها ذلك (للحصول على تفاصيل انظر أعلاه).

كما هو الحال مع --network-interface=، يجب أن تكون واجهة شبكة الجسر الأساسية موجودة بالفعل وقت بدء تشغيل الحاوية، وبالتالي قد تكون ملفات الإقحام المماثلة لوحدات الخدمة كما هو موضح أعلاه مفيدة.

أُضيف في الإصدارة 209.

--network-zone=

يُنشئ رابط إيثرنت افتراضي ("veth") للحاوية ويضيفه إلى واجهة جسر إيثرنت تُدار آلياً. تُسمى واجهة الجسر باسم المعامل الممرر، مسبوقاً بـ "vz-". تُنشأ واجهة الجسر آلياً عند بدء تشغيل أول حاوية مضبوطة باسمها، وتُزال آلياً عند خروج آخر حاوية مضبوطة باسمها. ومن ثم، فإن كل واجهة جسر تُضبط بهذه الطريقة لا توجد إلا طالما كانت هناك حاوية واحدة على الأقل تشير إليها قيد التشغيل. هذا الخيار مشابه جداً لـ --network-bridge=، باستثناء عملية الإنشاء/الإزالة الآلية لجهاز الجسر هذه.

يجعل هذا الإعداد من السهل وضع عدة حاويات مرتبطة ببعضها في نطاق بث مشترك قائم على الإيثرنت الافتراضي، يُسمى هنا "نطاقاً" (zone). يمكن لكل حاوية أن تكون جزءاً من نطاق واحد فقط، ولكن يمكن لكل نطاق أن يحتوي على أي عدد من الحاويات. يُشار إلى كل نطاق باسمه. يمكن اختيار الأسماء بحرية (طالما أنها تشكل أسماء واجهات شبكة صالحة عند سبقها بـ "vz-")، ويكفي تمرير نفس الاسم إلى مفتاح --network-zone= للحاويات المختلفة التي تعمل في وقت واحد لضمها في نطاق واحد.

لاحظ أن systemd-networkd.service(8) يتضمن افتراضياً ملف شبكة /usr/lib/systemd/network/80-container-vz.network يطابق واجهات الجسر المنشأة بهذه الطريقة، والذي يحتوي على إعدادات لتمكين التزويد الآلي للعناوين على الشبكة الافتراضية المنشأة عبر DHCP، بالإضافة إلى التوجيه الآلي لبروتوكول IP إلى واجهات الشبكة الخارجية للمضيف. استخدام --network-zone= يكون في معظم الحالات آلياً تماماً وكافياً لربط عدة حاويات محلية في نطاق بث منضم بالمضيف، مع إمكانية اتصال أوسع بالشبكة الخارجية.

أُضيف في الإصدارة 230.

--network-namespace-path=

يأخذ المسار إلى ملف يمثل مساحة اسم لشبكة النواة التي يجب أن تعمل الحاوية فيها. يجب أن يشير المسار المحدد إلى ملف مساحة اسم للشبكة (ربما يكون موصولاً بواسطة bind)، كما تعرضه النواة تحت /proc/$PID/ns/net. هذا يجعل الحاوية تدخل مساحة اسم الشبكة المعطاة. إحدى حالات الاستخدام النموذجية هي إعطاء مساحة اسم شبكة تحت /run/netns أنشئت بواسطة ip-netns(8)، على سبيل المثال، --network-namespace-path=/run/netns/foo. لاحظ أنه لا يمكن استخدام هذا الخيار مع خيارات أخرى متعلقة بالشبكة، مثل --private-network أو --network-interface=.

أُضيف في الإصدارة 236.

-p، --port=

إذا تم تمكين الشبكة الخاصة، فسيقوم برسم منفذ IP على المضيف إلى منفذ IP على الحاوية. يأخذ محدد بروتوكول (إما "tcp" أو "udp")، مفصولاً بنقطتين عن رقم منفذ المضيف في النطاق من 1 إلى 65535، مفصولاً بنقطتين عن رقم منفذ الحاوية في النطاق من 1 إلى 65535. يمكن حذف محدد البروتوكول والنقطتين الفاصلتين له، وفي هذه الحالة يُفترض أنه "tcp". يمكن حذف رقم منفذ الحاوية ونقطتيه الفاصلتين، وفي هذه الحالة يُفهم أن المنفذ هو نفسه منفذ المضيف. هذا الخيار مدعوم فقط إذا كانت الشبكة الخاصة مستخدمة، كما هو الحال مع --network-veth و --network-zone= و --network-bridge=.

أُضيف في الإصدارة 219.

خيارات الأمان¶

--capability=

يسرد واحداً أو أكثر من القدرات الإضافية لمنحها للحاوية. يأخذ قائمة بأسماء القدرات مفصولة بفاصلة، انظر capabilities(7) لمزيد من المعلومات. لاحظ أن القدرات التالية ستُمنح بأي حال: CAP_AUDIT_CONTROL، CAP_AUDIT_WRITE، CAP_CHOWN، CAP_DAC_OVERRIDE، CAP_DAC_READ_SEARCH، CAP_FOWNER، CAP_FSETID، CAP_IPC_OWNER، CAP_KILL، CAP_LEASE، CAP_LINUX_IMMUTABLE، CAP_MKNOD، CAP_NET_BIND_SERVICE، CAP_NET_BROADCAST، CAP_NET_RAW، CAP_SETFCAP، CAP_SETGID، CAP_SETPCAP، CAP_SETUID، CAP_SYS_ADMIN، CAP_SYS_BOOT، CAP_SYS_CHROOT، CAP_SYS_NICE، CAP_SYS_PTRACE، CAP_SYS_RESOURCE، CAP_SYS_TTY_CONFIG. كما يُحتفظ بـ CAP_NET_ADMIN إذا حُدد --private-network. إذا مُررت القيمة الخاصة "all"، فسيُحتفظ بجميع القدرات.

إذا مُررت القيمة الخاصة "help"، فسيقوم البرنامج بطباعة أسماء القدرات المعروفة ثم يخرج.

يضبط هذا الخيار مجموعة القدرات المقيدة والتي تحد أيضاً من القدرات المحيطة كما هو معطى مع --ambient-capability=.

أُضيف في الإصدارة 186.

--drop-capability=

حدد قدرة إضافية واحدة أو أكثر لإسقاطها عن الحاوية. يسمح هذا بتشغيل الحاوية بقدرات أقل من المبدئي (انظر أعلاه).

إذا مُررت القيمة الخاصة "help"، فسيقوم البرنامج بطباعة أسماء القدرات المعروفة ثم يخرج.

يضبط هذا الخيار مجموعة القدرات المقيدة والتي تحد أيضاً من القدرات المحيطة كما هو معطى مع --ambient-capability=.

أُضيف في الإصدارة 209.

--ambient-capability=

حدد قدرة إضافية واحدة أو أكثر لتمريرها في المجموعة الموروثة والمحيطة إلى البرنامج الذي بدأ داخل الحاوية. القيمة "all" غير مدعومة لهذا الإعداد.

يجب أن تكون جميع القدرات المحددة هنا ضمن المجموعة المسموح بها مع خياري --capability= و --drop-capability=. وإلا، ستُعرض رسالة خطأ.

لا يمكن دمج هذا الخيار مع وضع إقلاع الحاوية (كما هو مطلوب عبر --boot).

إذا مُررت القيمة الخاصة "help"، فسيقوم البرنامج بطباعة أسماء القدرات المعروفة ثم يخرج.

أُضيف في الإصدار 248.

--no-new-privileges=

يأخذ معامل منطقياً. يحدد قيمة علامة PR_SET_NO_NEW_PRIVS لحمولة الحاوية. المبدئي هو الإيقاف (off). عند التشغيل، لا يمكن لكود حمولة الحاوية اكتساب امتيازات جديدة، أي أن بت ملف "setuid" بالإضافة إلى قدرات نظام الملفات لن يكون لهما تأثير بعد الآن. انظر prctl(2) لمزيد من التفاصيل حول هذه العلامة.

أُضيف في الإصدار 239.

--system-call-filter=

يغير مرشح نداءات النظام المطبق على الحاويات. يأخذ قائمة مفصولة بمسافات من أسماء نداءات النظام أو أسماء المجموعات (الأخيرة مسبوقة بـ "@"، كما هو مسرود بواسطة أمر syscall-filter في systemd-analyze(1)). نداءات النظام الممررة سيُسمح بها. يمكن اختيارياً سبق القائمة بـ "~"، وفي هذه الحالة تُحظر جميع نداءات النظام المدرجة. إذا استُخدم خيار سطر الأوامر هذا عدة مرات تُدمج القوائم المضبوطة. إذا ضُبطت قائمة إيجابية وسلبية في آن واحد (أي قائمة نداءات نظام بدون وقائمة مع بادئة "~")، فإن القائمة السلبية لها الأسبقية على القائمة الإيجابية. لاحظ أن systemd-nspawn ينفذ دائماً قائمة سماح لنداءات النظام (على عكس قائمة المنع!)، وبالتالي فإن خيار سطر الأوامر هذا يضيف أو يزيل إدخالات من قائمة السماح المبدئية، اعتماداً على بادئة "~". لاحظ أن مرشح نداءات النظام المطبق يتغير أيضاً بشكل ضمني إذا مُررت قدرات إضافية باستخدام --capabilities=.

أُضيف في الإصدارة 235.

-Z، --selinux-context=

يضبط سياق أمان SELinux لاستخدامه في وسم العمليات في الحاوية.

أُضيف في الإصدارة 209.

-L، --selinux-apifs-context=

يضبط سياق أمان SELinux لاستخدامه في وسم الملفات في أنظمة ملفات API الافتراضية في الحاوية.

أُضيف في الإصدارة 209.

خيارات الموارد¶

--rlimit=

يضبط حد مورد POSIX المحدد لحمولة الحاوية. يتوقع تعييناً بالصيغة "LIMIT=SOFT:HARD" أو "LIMIT=VALUE"، حيث يجب أن يشير LIMIT إلى نوع حد المورد، مثل RLIMIT_NOFILE أو RLIMIT_NICE. يجب أن تشير حقول SOFT و HARD إلى القيم الرقمية للحد اللين والحد الصلب للمورد. إذا استُخدمت الصيغة الثانية، فقد تحدد VALUE قيمة تُستخدم كحد لين وصلب في آن واحد. بدلاً من القيمة الرقمية، يمكن استخدام السلسلة الخاصة "infinity" لإيقاف تحديد الموارد لنوع معين من الموارد. يمكن استخدام خيار سطر الأوامر هذا عدة مرات للتحكم في الحدود على أنواع حدود متعددة. إذا استُخدم عدة مرات لنفس نوع الحد، فإن الاستخدام الأخير هو الذي يسري. للحصول على تفاصيل حول حدود الموارد، انظر setrlimit(2). افتراضياً، تُضبط حدود الموارد لعملية التهيئة (init) الخاصة بالحاوية (PID 1) على نفس القيم التي مررتها نواة لينكس أصلاً إلى نظام تهيئة المضيف. لاحظ أن بعض حدود الموارد تُفرض على الموارد المحسوبة لكل مستخدم، وبخاصة RLIMIT_NPROC. وهذا يعني أنه ما لم يتم نشر مساحات أسماء المستخدمين (أي استخدام --private-users=، انظر أعلاه)، فإن أي حدود تُضبط ستُطبق على استخدام الموارد لنفس المستخدم في جميع الحاويات المحلية وكذلك المضيف. وهذا يعني ضرورة توخي الحذر الشديد مع هذه الحدود حيث قد تُستحث بواسطة كود ربما يكون أقل ثقة. مثال: "--rlimit=RLIMIT_NOFILE=8192:16384".

أُضيف في الإصدار 239.

--oom-score-adjust=

يغير قيمة ضبط درجة OOM ("نقص الذاكرة") لحمولة الحاوية. يتحكم هذا في /proc/self/oom_score_adj الذي يؤثر على تفضيل إنهاء هذه الحاوية عندما تصبح الذاكرة شحيحة. للحصول على تفاصيل انظر proc(5). يأخذ عدداً صحيحاً في النطاق من -1000 إلى 1000.

أُضيف في الإصدار 239.

--cpu-affinity=

يتحكم في تقارب المعالج (CPU affinity) لحمولة الحاوية. يأخذ قائمة مفصولة بفاصلة من أرقام المعالجات أو نطاقات الأرقام (تُفصل قيمة البداية والنهاية في الأخيرة بشرطات). انظر sched_setaffinity(2) لمزيد من التفاصيل.

أُضيف في الإصدار 239.

--personality=

يتحكم في المعمارية ("الشخصية") التي يبلغ عنها uname(2) في الحاوية. حالياً، يُدعم فقط "x86" و "x86-64". هذا مفيد عند تشغيل حاوية 32 بت على مضيف 64 بت. إذا لم يُستخدم هذا الإعداد، فإن الشخصية التي يُبلغ عنها في الحاوية هي نفسها التي يُبلغ عنها على المضيف.

أُضيف في الإصدارة 209.

خيارات التكامل¶

--resolv-conf=

يضبط كيفية التعامل مع /etc/resolv.conf داخل الحاوية (أي مزامنة إعدادات DNS من المضيف إلى الحاوية). يأخذ أحد القيم: "off"، أو "copy-host"، أو "copy-static"، أو "copy-uplink"، أو "copy-stub"، أو "replace-host"، أو "replace-static"، أو "replace-uplink"، أو "replace-stub"، أو "bind-host"، أو "bind-static"، أو "bind-uplink"، أو "bind-stub"، أو "delete" أو "auto".

إذا ضُبط على "off"، يُترك ملف /etc/resolv.conf في الحاوية كما هو مضمن في الصورة، ولا يُعدل ولا يُوصل فوقه بواسطة bind.

إذا ضُبط على "copy-host"، يُنسخ ملف /etc/resolv.conf من المضيف إلى الحاوية، ما لم يكن الملف موجوداً بالفعل وليس ملفاً عادياً (على سبيل المثال رابط رمزي). وبالمثل، إذا استُخدم "replace-host" فسيُنسخ الملف، مستبدلاً أي inode موجود، بما في ذلك الروابط الرمزية. وبالمثل، إذا استُخدم "bind-host"، يُوصل الملف من المضيف إلى الحاوية بواسطة bind mount.

إذا ضُبط على "copy-static" أو "replace-static" أو "bind-static"، فسيُنسخ ملف resolv.conf الساكن المرفق مع systemd-resolved.service(8) (تحديداً: /usr/lib/systemd/resolv.conf) أو يُوصل في الحاوية.

إذا ضُبط على "copy-uplink" أو "replace-uplink" أو "bind-uplink"، يُنسخ ملف resolv.conf للوصلة الصاعدة (uplink) الذي يديره systemd-resolved.service (تحديداً: /run/systemd/resolve/resolv.conf) أو يُوصل في الحاوية.

إذا ضُبط على "copy-stub" أو "replace-stub" أو "bind-stub"، يُنسخ ملف resolv.conf البديل (stub) الذي يديره systemd-resolved.service (تحديداً: /run/systemd/resolve/stub-resolv.conf) أو يُوصل في الحاوية.

إذا ضُبط على "delete"، يُحذف ملف /etc/resolv.conf في الحاوية إذا وجد.

أخيراً، إذا ضُبط على "auto" يُترك الملف كما هو إذا فُعّلت الشبكة الخاصة (انظر --private-network). وبخلاف ذلك، إذا كان systemd-resolved.service يعمل فسيُستخدم ملف resolv.conf البديل الخاص به، وإذا لم يكن يعمل فسيُستخدم ملف /etc/resolv.conf الخاص بالمضيف. في الحالات الأخيرة، يُنسخ الملف إذا كانت الصورة قابلة للكتابة، ويُوصل بواسطة bind بخلاف ذلك.

يُوصى باستخدام "copy-..." أو "replace-..." إذا كان يجب أن تكون الحاوية قادرة على إجراء تغييرات على إعدادات DNS بنفسها، مع الانحراف عن إعدادات المضيف. بخلاف ذلك، يُفضل "bind"، لأنه يعني أن التغييرات المباشرة على /etc/resolv.conf في الحاوية غير مسموح بها، لأنه وصل bind للقراءة فقط (ولكن لاحظ أنه إذا كانت للحاوية امتيازات كافية، فقد تقوم ببساطة بفصل وصل bind على أي حال). لاحظ أنه سواء وُصل الملف بواسطة bind أو نُسخ، فلا يُجرى عادةً أي نشر إضافي للإعدادات بعد التهيئة المبكرة لمرة واحدة (هذا لأن الملف يُحدث عادةً من خلال النسخ وإعادة التسمية). المبدئي هو "auto".

أُضيف في الإصدار 239.

--timezone=

يضبط كيفية التعامل مع /etc/localtime داخل الحاوية (أي مزامنة المنطقة الزمنية المحلية من المضيف إلى الحاوية). يأخذ أحد القيم: "off"، أو "copy"، أو "bind"، أو "symlink"، أو "delete" أو "auto". إذا ضُبط على "off"، يُترك ملف /etc/localtime في الحاوية كما هو مضمن في الصورة، ولا يُعدل ولا يُوصل فوقه بواسطة bind. إذا ضُبط على "copy"، يُنسخ ملف /etc/localtime الخاص بالمضيف إلى الحاوية. وبالمثل، إذا استُخدم "bind"، يُوصل الملف من المضيف إلى الحاوية بواسطة bind mount. إذا ضُبط على "symlink"، يُنشأ رابط رمزي يشير من /etc/localtime في الحاوية إلى ملف المنطقة الزمنية في الحاوية الذي يطابق إعداد المنطقة الزمنية على المضيف. إذا ضُبط على "delete"، يُحذف الملف في الحاوية، في حال وجد. إذا ضُبط على "auto" وكان ملف /etc/localtime للمضيف رابطاً رمزياً، فسيُستخدم وضع "symlink"، ووضع "copy" بخلاف ذلك، إلا إذا كانت الصورة للقراءة فقط ففي هذه الحالة يُستخدم وضع "bind" بدلاً من ذلك. المبدئي هو "auto".

أُضيف في الإصدار 239.

--link-journal=

يتحكم في ما إذا كان سجل (journal) الحاوية سيصبح مرئياً لنظام المضيف. إذا مُكن، فإنه يسمح بعرض ملفات سجل الحاوية من المضيف (وليس العكس). يأخذ أحد القيم: "no"، أو "host"، أو "try-host"، أو "guest"، أو "try-guest"، أو "auto". إذا كانت القيمة "no"، فلا يُربط السجل. إذا كانت "host"، تُخزن ملفات السجل على نظام ملفات المضيف (تحت /var/log/journal/machine-id) ويُوصل المجلد الفرعي في الحاوية في نفس الموقع بواسطة bind mount. إذا كانت "guest"، تُخزن ملفات السجل على نظام ملفات الضيف (تحت /var/log/journal/machine-id) ويُنشأ رابط رمزي للمجلد الفرعي في المضيف في نفس الموقع. يقوم كل من "try-host" و "try-guest" بنفس الشيء ولكنهما لا يفشلان إذا لم يكن لدى المضيف ميزة التسجيل المستمر مُمكنة، أو إذا كانت الحاوية في وضع --ephemeral. إذا كانت القيمة "auto" (المبدئي)، ووجد المجلد الفرعي الصحيح لـ /var/log/journal، فسيُوصل في الحاوية بواسطة bind mount. إذا لم يوجد المجلد الفرعي، فلا يُجرى أي ربط. فعلياً، سيؤدي إقلاع الحاوية مرة واحدة بوضع "guest" أو "host" إلى ربط السجل بشكل مستمر إذا استُخدم الوضع المبدئي "auto" لاحقاً.

لاحظ أن --link-journal=try-guest هو المبدئي في حال استُخدم ملف وحدة القالب systemd-nspawn@.service.

أُضيف في الإصدارة 187.

-j

يكافئ --link-journal=try-guest.

أُضيف في الإصدارة 187.

خيارات الوصل¶

--bind=، --bind-ro=

يصل (bind mount) ملفاً أو مجلداً من المضيف إلى داخل الحاوية. يأخذ أحد: معامل مسار — وفي هذه الحالة سيُوصل المسار المحدد من المضيف إلى نفس المسار في الحاوية، أو زوجاً من المسارات مفصولاً بنقطتين — وفي هذه الحالة يكون المسار الأول المحدد هو المصدر في المضيف، والمسار الثاني هو الوجهة في الحاوية، أو ثلاثية مفصولة بنقطتين من مسار المصدر ومسار الوجهة وخيارات الوصل. يمكن اختيارياً سبق مسار المصدر بمحرف "+". إذا فُعل ذلك، فسيُؤخذ مسار المصدر بالنسبة إلى المجلد الجذر للصورة. يسمح هذا بإعداد وصل bind داخل صورة الحاوية. يمكن تحديد مسار المصدر كسلسلة فارغة، وفي هذه الحالة يُستخدم مجلد مؤقت تحت مجلد /var/tmp/ في المضيف. ويُزال آلياً عند إيقاف تشغيل الحاوية. إذا لم يكن مسار المصدر مطلقاً، فسيُحل بالنسبة إلى مجلد العمل الحالي. ينشئ الخيار --bind-ro= وصل bind للقراءة فقط. تُفسر مهربات الشرطة المائلة العكسية، لذا يمكن استخدام "\:" لتضمين النقطتين في أي من المسارين. يمكن تحديد هذا الخيار عدة مرات لإنشاء نقاط وصل bind مستقلة متعددة.

خيارات الوصل مفصولة بفاصلة. يتحكم rbind و norbind في ما إذا كان سيُنشأ وصل bind متكرر (recursive) أو عادي. المبدئي هو rbind. وتتحكم noidmap و idmap و rootidmap و owneridmap في رسم المعرفات (ID mapping).

يتطلب استخدام idmap أو rootidmap أو owneridmap دعماً من نظام ملفات المصدر لعمليات الوصل المرسومة لمعرفات المستخدم/المجموعة. المبدئي هو noidmap. بفرض أن x هو إزاحة نطاق UID للحاوية، و y هو طول نطاق UID للحاوية، و p هو UID المالك لـ inode مصدر وصل bind على المضيف:

•إذا استُخدم noidmap، فإن أي مستخدم z في النطاق 0 ... y كما يُرى من داخل الحاوية يُرسم إلى x + z في النطاق x ... x + y على المضيف. ويُرسم مستخدمو المضيف الآخرون إلى nobody داخل الحاوية.

•إذا استُخدم idmap، فإن أي مستخدم z في نطاق UID ‏0 ... y كما يُرى من داخل الحاوية يُرسم إلى نفس z في نفس النطاق 0 ... y على المضيف. ويُرسم مستخدمو المضيف الآخرون إلى nobody داخل الحاوية.

•إذا استُخدم rootidmap، فإن المستخدم 0 كما يُرى من داخل الحاوية يُرسم إلى p على المضيف. ويُرسم مستخدمو المضيف الآخرون إلى nobody داخل الحاوية.

•إذا استُخدم owneridmap، فإن مالك المجلد الهدف داخل الحاوية يُرسم إلى p على المضيف. ويُرسم مستخدمو المضيف الآخرون إلى nobody داخل الحاوية.

أياً كان خيار رسم المعرفات (ID mapping) المستخدم، فسيُستخدم نفس الرسم لمعرفات المستخدمين والمجموعات. إذا استُخدم rootidmap أو owneridmap، فلن يكون للمجموعة المالكة للمجلد الموصول بواسطة bind أي تأثير.

لاحظ أنه عند استخدام هذا الخيار بالاقتران مع --private-users، فإن نقاط الوصل الناتجة ستكون مملوكة للمستخدم nobody. وذلك لأن الوصل وملفاته ومجلداته تظل مملوكة لمستخدمي ومجموعات المضيف المعنيين، والذين لا وجود لهم في الحاوية، وبالتالي يظهرون تحت معرف UID العام 65534 (nobody). إذا أُنشئت مثل هذه الوصلات، فيُوصى بجعلها للقراءة فقط، باستخدام --bind-ro=. بدلاً من ذلك، يمكنك استخدام خيار الوصل "idmap" لرسم معرفات نظام الملفات.

أُضيف في الإصدارة 198.

--bind-user=

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

1.يُوصل المجلد المنزلي للمستخدم من المضيف إلى /run/host/home/، باستخدام وصل idmapped لرسم UID/GID لمستخدم المضيف إلى UID/GID المعين له في الحاوية.

2.يُولد سجل مستخدم ومجموعة بصيغة JSON في /run/userdb/ يصف المستخدم المرسوم. يحتوي على تمثيل مصغر لسجل مستخدم المضيف، مع ضبطه ليناسب معرف UID/GID ومسار المجلد المنزلي المعين للمستخدم في الحاوية. ستقوم وحدة nss-systemd(8) glibc NSS بالتقاط هذه السجلات من هناك وإتاحتها في قواعد بيانات المستخدمين والمجموعات في الحاوية.

يضمن الجمع بين العمليتين أعلاه إمكانية تسجيل الدخول إلى الحاوية باستخدام نفس معلومات الحساب الموجودة على المضيف. يُرسم المستخدم بشكل عابر فقط، أثناء تشغيل الحاوية، ولا يؤدي الرسم نفسه إلى تغييرات مستمرة في الحاوية (باستثناء ربما رسائل السجل الناتجة عند وقت تسجيل الدخول، وما شابه). لاحظ بشكل خاص أن تعيين UID/GID في الحاوية لا يُجرى بشكل مستمر. إذا رُسم المستخدم بشكل عابر، فمن الأفضل عدم السماح للمستخدم بإجراء تغييرات مستمرة على الحاوية. إذا ترك المستخدم ملفات أو مجلدات مملوكة له، وأعيد استخدام معرفات UID/GID هذه أثناء استدعاءات الحاوية اللاحقة (ربما برسم --bind-user= مختلف)، فستكون تلك الملفات والمجلدات متاحة للمستخدم "الجديد".

لا يعمل تعيين سجلات المستخدمين/المجموعات إلا إذا كان الحاوية تحتوي على systemd 249 أو إصدار أحدث، مع ضبط nss-systemd بشكل صحيح في nsswitch.conf. انظر nss-systemd(8) لمزيد من التفاصيل.

لاحظ أن سجل المستخدم المنشور من المضيف إلى الحاوية سيحتوي على هاش كلمة مرور يونكس للمستخدم، بحيث يكون تسجيل الدخول السلس في الحاوية ممكناً. إذا كانت الحاوية أقل ثقة من المضيف، فمن المهم استخدام دالة هاش قوية لكلمة مرور يونكس (مثل yescrypt أو ما شابه، مع بادئة الهاش "$y$").

عند وصل مستخدم من المضيف إلى الحاوية، تُنفذ فحوصات لضمان أن اسم المستخدم ليس معروفاً بعد في الحاوية. علاوة على ذلك، يُفحص أن UID/GID المخصص له غير محدد حالياً في قواعد بيانات المستخدمين/المجموعات للحاوية. كلا الفحصين يصلان مباشرة إلى /etc/passwd و /etc/group في الحاوية، وبالتالي قد لا يكتشفان الحسابات الموجودة في قواعد البيانات الأخرى.

أُضيف في الإصدار 249.

--bind-user-shell=

عند استخدامه مع --bind-user=، فإنه يتضمن الصدفة المحددة في سجلات المستخدمين الموصولين بالحاوية. يأخذ إما قيمة منطقية أو مساراً مطلقاً.

•إذا كانت القيمة خطأ (المبدئي)، فلا تُمرر أي صدفة في سجلات المستخدمين الموصولين بالحاوية. يؤدي هذا إلى استخدام المستخدمين الموصولين للصدفة المبدئية للحاوية.

•إذا كانت القيمة صواباً، فستُدرج الصدف المحددة في سجلات مستخدم المضيف في سجلات جميع المستخدمين الموصولين بالحاوية.

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

ملاحظة: لن يتحقق هذا مما إذا كانت الصدف المحددة موجودة في الحاوية.

هذه العملية مدعومة فقط بالاقتران مع --bind-user=.

أُضيف في الإصدار 258.

--bind-user-group=اسم

عند استخدامه مع --bind-user=، فإنه يدرج المجموعة المحددة كمجموعة مساعدة في سجلات المستخدمين المرتبطين بالحاوية. يأخذ اسم مجموعة.

ملاحظة: لن يتحقق هذا مما إذا كانت المجموعات المحددة موجودة في الحاوية.

هذه العملية مدعومة فقط بالاقتران مع --bind-user=.

أُضيف في الإصدار 259.

--inaccessible=

يجعل المسار المحدد غير قابل للوصول في الحاوية. يقوم هذا بوصل فوقي (over-mounts) للمسار المحدد (الذي يجب أن يكون موجودًا في الحاوية) بعقدة ملف من نفس النوع تكون فارغة ولديها أكثر وضع وصول تقييدي مدعوم. هذه طريقة فعالة لقناع (mask) الملفات والأدلة وكائنات نظام الملفات الأخرى من حمولة الحاوية. يمكن استخدام هذا الخيار أكثر من مرة في حال قُنعت جميع المسارات المحددة.

أُضيف في الإصدارة 242.

--tmpfs=

يوصل نظام ملفات tmpfs في الحاوية. يأخذ وسيط مسار مطلق واحد يحدد مكان وصل مثيل tmpfs (وفي هذه الحالة سيُختار وضع الوصول للدليل كـ 0755، بملكية root/root)، أو اختياريًا زوج من المسار وسلسلة خيارات الوصل مفصولين بنقطتين يُستخدم للوصل (وفي هذه الحالة سيُختار المبدئي للنواة لوضع الوصول والمالك، ما لم يُنص على خلاف ذلك). تُفسر هروبات الشرطة المائلة العكسية في المسار، لذا يمكن استخدام "\:" لتضمين النقطتين في المسار.

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

أُضيف في الإصدارة 214.

--overlay=، --overlay-ro=

يجمع أشجار أدلة متعددة في نظام ملفات تراكبي (overlay) واحد ويوصله في الحاوية. يأخذ قائمة مسارات مفصولة بنقطتين لأشجار الأدلة المراد دمجها ونقطة الوصل الوجهة.

تُفسر هروبات الشرطة المائلة العكسية في المسارات، لذا يمكن استخدام "\:" لتضمين النقطتين في المسارات.

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

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

يمكن اختياريًا سبق مسارات المصدر بحرف "+". إذا كان الأمر كذلك، فسيتم أخذها نسبةً إلى الدليل الجذر للصورة. يمكن أيضًا تحديد مسار المصدر العلوي كسلسلة فارغة، وفي هذه الحالة يُستخدم دليل مؤقت تحت /var/tmp/ للمضيف. يُزال الدليل آليًا عند إيقاف تشغيل الحاوية. هذا السلوك مفيد لجعل أدلة الحاوية المخصصة للقراءة فقط قابلة للكتابة أثناء تشغيل الحاوية. على سبيل المثال، استخدم "--overlay=+/var::/var" من أجل تراكب دليل مؤقت قابل للكتابة آليًا على دليل /var/ المخصص للقراءة فقط. إذا لم يكن مسار المصدر مطلقًا، فسيُحلل نسبةً إلى دليل العمل الحالي.

للحصول على تفاصيل حول أنظمة الملفات التراكبية، راجع نظام الملفات التراكبي (Overlay Filesystem)[4]. لاحظ أن دلالات أنظمة الملفات التراكبية تختلف جوهريًا عن أنظمة الملفات العادية، لا سيما فيما يتعلق بمعلومات الجهاز والآينود (inode) المبلغ عنها. قد تتغير معلومات الجهاز والآينود لملف أثناء الكتابة إليه، وقد ترى العمليات إصدارات قديمة من الملفات في بعض الأحيان. لاحظ أن هذا المفتاح يشتق آليًا خيار الوصل "workdir=" لنظام الملفات التراكبي من شجرة أدلة المستوى الأعلى، مما يجعله شقيقًا لها. لذا من الضروري ألا تكون شجرة أدلة المستوى الأعلى نقطة وصل في حد ذاتها (بما أن دليل العمل يجب أن يكون على نفس نظام الملفات مثل شجرة الأدلة العليا). لاحظ أيضًا أن خيار الوصل "lowerdir=" يتلقى مسارات التكديس بترتيب عكسي لهذا المفتاح.

لاحظ أنه لا يمكن استخدام هذا الخيار لاستبدال نظام الملفات الجذر للحاوية بنظام ملفات تراكبي. ومع ذلك، يوفر الخيار --volatile= الموضح أدناه وظائف مماثلة، مع التركيز على تنفيذ صور أنظمة تشغيل عديمة الحالة.

أُضيف في الإصدارة 220.

خيارات الإدخال والإخراج¶

--console=وضع

يضبط كيفية إعداد الإدخال والمخرجات القياسية ومخرج الخطأ لحمولة الحاوية، بالإضافة إلى جهاز /dev/console للحاوية. يأخذ أحد الخيارات interactive، أو read-only، أو passive، أو pipe، أو autopipe. إذا كان interactive، فسيُخصص pseudo-TTY ويُتاح كـ /dev/console في الحاوية. ثم يُوصل ثنائي الاتجاه بالإدخال والمخرجات القياسية الممررة إلى systemd-nspawn. خيار read-only مشابه ولكن يُنشر مخرج الحاوية فقط ولا يُقرأ أي إدخال من المستدعِي. إذا كان passive، فسيُخصص pseudo TTY، ولكنه لا يُوصل بأي مكان. في وضع pipe، لا يُخصص pseudo TTY، ولكن واصفات ملفات الإدخال والمخرجات القياسية ومخرج الخطأ الممررة إلى systemd-nspawn تُمرر كما هي إلى حمولة الحاوية، راجع الفقرة التالية. أخيرًا، يعمل وضع autopipe مثل interactive عندما يُستدعى systemd-nspawn على طرفية، ومثل pipe خلاف ذلك. المبدئي هو interactive إذا استُدعى systemd-nspawn من طرفية، و read-only خلاف ذلك.

في وضع pipe، لن يكون /dev/console موجودًا في الحاوية. هذا يعني أن حمولة الحاوية عمومًا لا يمكن أن تكون نظام تهيئة (init) كاملاً لأن أنظمة التهيئة تميل إلى اشتراط توفر /dev/console. من ناحية أخرى، في هذا الوضع يمكن استخدام استدعاءات الحاوية داخل أنابيب الصدفة. هذا لأن الـ pseudo TTYs الوسيطة لا تسمح بنشر ثنائي الاتجاه مستقل لحالة نهاية الملف (EOF)، وهو أمر ضروري لعمل أنابيب الصدفة بشكل صحيح. لاحظ أنه يجب استخدام وضع pipe بحذر، لأن تمرير واصفات ملفات اعتباطية إلى حمولات حاوية أقل ثقة قد يفتح واجهات غير مرغوب فيها للوصول من قبل حمولة الحاوية. على سبيل المثال، إذا كان واصف الملف الممرر يشير إلى TTY من نوع ما، فقد تُستخدم واجهات برمجة تطبيقات مثل TIOCSTI لتصنيع إدخال قد يُستخدم للهروب من الحاوية. لذا يجب استخدام وضع pipe فقط إذا كانت الحمولة موثوقة بما يكفي أو عندما تكون واصفات ملفات الإدخال/المخرجات/مخرج الخطأ القياسية معروفة بأنها آمنة، مثل الأنابيب.

أُضيف في الإصدارة 242.

--pipe، -P

يعادل --console=pipe.

أُضيف في الإصدارة 242.

--background=COLOR

يغير لون خلفية الطرفية إلى لون ANSI المحدد طالما كانت الحاوية تعمل. يجب أن يكون اللون المحدد لون خلفية ANSI X3.64 SGR، أي سلاسل مثل "40"، "41"، ...، "47"، "48;2;..."، "48;5;...". راجع كود هروب ANSI (ويكيبيديا)[5] للحصول على التفاصيل. خصص سلسلة فارغة لتعطيل أي تلوين.

أُضيف في الإصدار 256.

بيانات الاعتماد¶

--load-credential=المعرف:المسار، --set-credential=المعرف:القيمة

يمرر بيانات اعتماد إلى الحاوية. يتوافق هذان الخياران مع إعدادات LoadCredential= و SetCredential= في ملفات الوحدات. راجع systemd.exec(5) لمزيد من التفاصيل حول هذه المفاهيم، وكذلك بناء جملة وسائط الخيار.

ملاحظة: عندما يعمل systemd-nspawn كخدمة نظام systemd، يمكنه نشر بيانات الاعتماد التي تلقاها عبر LoadCredential=/SetCredential= إلى حمولة الحاوية. ويمكن لمدير خدمة systemd الذي يعمل كـ PID 1 في الحاوية نشرها بشكل أكبر إلى الخدمات التي يبدأها هو نفسه. وبذلك يمكن بسهولة نشر بيانات الاعتماد من مدير خدمة أب إلى خدمة مدير حاوية ومن هناك إلى حمولتها. يمكن القيام بذلك بشكل عودي حتى.

لتضمين بيانات ثنائية في بيانات الاعتماد لـ --set-credential=، استخدم هروباً بنمط لغة C (أي "\n" لتضمين سطر جديد، أو "\x00" لتضمين بايت NUL). لاحظ أن الصدفة المستدعاة قد تطبق بالفعل إلغاء الهروب مرة واحدة، لذا قد يتطلب ذلك هروباً مزدوجاً!

تقرأ خدمات systemd-sysusers.service(8) و systemd-firstboot(1) بيانات الاعتماد المهيأة بهذه الطريقة لغرض ضبط كلمة سر المستخدم الجذر وصدفته في الحاوية، بالإضافة إلى المحلية ونظام المفاتيح والمنطقة الزمنية للنظام أثناء عملية الإقلاع الأولى للحاوية. هذا مفيد بشكل خاص بالاقتران مع --volatile=yes حيث تظهر كل عملية إقلاع كأنها الإقلاع الأول، بما أن الإعدادات المطبقة على /etc/ تُفقد في دورات إعادة تشغيل الحاوية. راجع صفحات الدليل المعنية لمزيد من التفاصيل. مثال:

# systemd-nspawn -i image.raw \


          --volatile=yes \


          --set-credential=firstboot.locale:de_DE.UTF-8 \


          --set-credential=passwd.hashed-password.root:'$y$j9T$yAuRJu1o5HioZAGDYPU5d.$F64ni6J2y2nNQve90M/p0ZP0ECP/qqzipNyaY9fjGpC' \


          -b

سيستدعي سطر الأوامر أعلاه ملف الصورة المحدد image.raw في الوضع المتقلب، أي بمجلدات /etc/ و /var/ فارغة. ستتعرف حمولة الحاوية على هذا كإقلاع أول، وستستدعي خدمة systemd-firstboot.service، التي تقرأ بعد ذلك بيانَي الاعتماد الممررين لضبط محلية النظام الأولية وكلمة سر الجذر.

أُضيف في الإصدار 247.

أخرى¶

--no-pager

لا تمرر المخرجات إلى مستعرض صفحات (pager).

-h، --help

اطبع نص مساعدة قصير واخرج.

--version

اطبع سلسلة إصدار قصيرة واخرج.

--no-ask-password

لا تسأل المستخدم عن الاستيثاق للعمليات ذات الامتيازات.

مفاتيح الاختصار¶

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

Ctrl-] Ctrl-] Ctrl-]

ينهي الحاوية فورًا، ويقتل جميع العمليات.

Ctrl-] Ctrl-] r

يصدر طلب إعادة تشغيل للحاوية.

أُضيف في الإصدار 258.

Ctrl-] Ctrl-] p

يصدر طلب إيقاف تشغيل للحاوية.

أُضيف في الإصدار 258.

البيئة¶

$SYSTEMD_LOG_LEVEL

الحد الأقصى لمستوى السجل للرسائل الصادرة (تُكتم الرسائل ذات مستوى السجل الأعلى، أي الأقل أهمية). يأخذ قائمة قيم مفصولة بفواصل. يمكن أن تكون القيمة إما واحدة من (بترتيب تنازلي للأهمية) emerg، أو alert، أو crit، أو err، أو warning، أو notice، أو info، أو debug، أو رقمًا صحيحًا في النطاق من 0 إلى 7. راجع syslog(3) لمزيد من المعلومات. يمكن اختياريًا سبق كل قيمة بأحد الخيارات console، أو syslog، أو kmsg أو journal متبوعة بنقطتين لضبط الحد الأقصى لمستوى السجل لهذا الهدف المحدد (مثلاً: SYSTEMD_LOG_LEVEL=debug,console:info يحدد التسجيل بمستوى debug باستثناء التسجيل في الطرفية الذي يجب أن يكون بمستوى info). لاحظ أن الحد الأقصى العالمي لمستوى السجل له الأولوية على أي حدود مستويات سجل لكل هدف على حدة.

$SYSTEMD_LOG_COLOR

قيمة منطقية. إذا كانت صحيحة، فستُلون الرسائل المكتوبة في الـ tty حسب الأولوية.

هذا الإعداد مفيد فقط عندما تُكتب الرسائل مباشرة إلى الطرفية، لأن journalctl(1) والأدوات الأخرى التي تعرض السجلات ستلون الرسائل بناءً على مستوى السجل من تلقاء نفسها.

$SYSTEMD_LOG_TIME

قيمة منطقية. إذا كانت صحيحة، فستُسبق رسائل سجل الطرفية بختم زمني.

هذا الإعداد مفيد فقط عندما تُكتب الرسائل مباشرة إلى الطرفية أو إلى ملف، لأن journalctl(1) والأدوات الأخرى التي تعرض السجلات ستُرفق طوابع زمنية بناءً على البيانات الوصفية للمدخلات من تلقاء نفسها.

$SYSTEMD_LOG_LOCATION

قيمة منطقية. إذا كانت صحيحة، فستُسبق الرسائل باسم الملف ورقم السطر في الشيفرة المصدرية حيث نشأت الرسالة.

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

$SYSTEMD_LOG_TID

قيمة منطقية. إذا كانت صحيحة، فستُسبق الرسائل بمعرّف الخيط الرقمي الحالي (TID).

لاحظ أن هذه المعلومات تُرفق كبيانات وصفية بمدخلات اليوميات على أي حال. ومع ذلك، قد يكون تضمينه مباشرة في نص الرسالة مفيدًا عند تنقيح البرامج.

$SYSTEMD_LOG_TARGET

وجهة رسائل السجل. أحد الخيارات: console (التسجيل في الطرفية المرفقة)، أو console-prefixed (التسجيل في الطرفية المرفقة ولكن مع بادئات ترميز مستوى السجل و"المرفق"، راجع syslog(3)، أو kmsg (التسجيل في ذاكرة السجل الدائرية للنواة)، أو journal (التسجيل في اليوميات)، أو journal-or-kmsg (التسجيل في اليوميات إذا كانت متاحة، وفي kmsg بخلاف ذلك)، أو auto (تحديد هدف السجل المناسب آليًا، وهو المبدئي)، أو null (تعطيل مخرج السجل).

$SYSTEMD_LOG_RATELIMIT_KMSG

فيما إذا كان سيُحد معدل kmsg أم لا. يأخذ قيمة منطقية. القيمة المبدئية هي "true". إذا عُطّل، فلن يحد systemd من معدل الرسائل المكتوبة في kmsg.

$SYSTEMD_PAGER، $PAGER

مستعرض الصفحات المراد استخدامه عندما لا يُعطى الخيار --no-pager. يُستخدم $SYSTEMD_PAGER إذا كان مضبوطًا؛ وإلا فيُستخدم $PAGER. إذا لم يُضبط أي من $SYSTEMD_PAGER أو $PAGER، فتُجرب مجموعة من التطبيقات المعروفة لمستعرضات الصفحات تباعًا، بما في ذلك less(1) و more(1)، حتى يُعثر على أحدها. إذا لم يُكتشف أي تطبيق لمستعرض الصفحات، فلا يُستدعى أي مستعرض. ضبط متغيرات البيئة هذه على سلسلة فارغة أو القيمة "cat" يعادل تمرير الخيار --no-pager.

ملاحظة: إذا لم يُضبط $SYSTEMD_PAGERSECURE، فلا يمكن استخدام $SYSTEMD_PAGER و $PAGER إلا لتعطيل مستعرض الصفحات (باستخدام "cat" أو "")، ويتم تجاهلهما فيما عدا ذلك.

$SYSTEMD_LESS

تجاوز الخيارات الممررة إلى less (مبدئيًا "FRSXMK").

قد يرغب المستخدمون في تغيير خيارين على وجه الخصوص:

يوجه هذا الخيار مستعرض الصفحات بالخروج فورًا عند الضغط على Ctrl+C. للسماح لـ less بالتعامل مع Ctrl+C بنفسه للعودة إلى محث أوامر المستعرض، قم بإلغاء ضبط هذا الخيار.

إذا لم تتضمن قيمة $SYSTEMD_LESS الحرف "K"، وكان المستعرض المستدعى هو less، فسيُتجاهل Ctrl+C من قبل الملف التنفيذي، ويجب معالجته من قبل المستعرض.

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

لاحظ أن ضبط متغير البيئة العادي $LESS ليس له أي تأثير عند استدعاء less بواسطة أدوات systemd.

راجع less(1) لمزيد من النقاش.

$SYSTEMD_LESSCHARSET

يتجاوز طقم المحارف الممرر إلى less (مبدئيًا "utf-8"، إذا حُدّد أن الطرفية المستدعية متوافقة مع UTF-8).

لاحظ أن ضبط متغير البيئة العادي $LESSCHARSET ليس له أي تأثير عند استدعاء less بواسطة أدوات systemd.

$SYSTEMD_PAGERSECURE

تدعم أوامر المستعرض (pager) الشائعة مثل less(1)، بالإضافة إلى "التصفح"، أي التمرير عبر المخرجات، فتح ملفات أخرى أو الكتابة إليها وتشغيل أوامر صدفة عشوائية. عند استدعاء الأوامر بامتيازات مرفوعة، على سبيل المثال تحت sudo(8) أو pkexec(1)، يصبح المستعرض حدًا أمنيًا. يجب الحرص على استخدام البرامج ذات الوظائف المحدودة للغاية فقط كمستعرضات، وعدم السماح بالميزات التفاعلية غير المقصودة مثل فتح ملفات جديدة أو إنشائها أو بدء عمليات فرعية. يمكن تمكين "الوضع الآمن" للمستعرض كما هو موضح أدناه، إذا كان المستعرض يدعم ذلك (معظم المستعرضات لم تُكتب بطريقة تأخذ هذا في الاعتبار). يوصى إما بتمكين "الوضع الآمن" صراحةً أو تعطيل المستعرض تمامًا باستخدام --no-pager أو PAGER=cat عند السماح للمستخدمين غير الموثوق بهم بتنفيذ أوامر بامتيازات مرفوعة.

يأخذ هذا الخيار وسيطًا منطقيًا. عند ضبطه على صحيح (true)، يتم تمكين "الوضع الآمن" لمستعرض الصفحات. في "الوضع الآمن"، سيُضبط LESSSECURE=1 عند استدعاء المستعرض، مما يوجه المستعرض لتعطيل الأوامر التي تفتح أو تنشئ ملفات جديدة أو تبدأ عمليات فرعية جديدة. حاليًا، يُعرف فقط less(1) بقدرته على فهم هذا المتغير وتطبيق "الوضع الآمن".

عند الضبط إلى false، لا توضع قيود على أداة التصفح (pager). إن ضبط SYSTEMD_PAGERSECURE=0 أو عدم إزالته من البيئة الموروثة قد يسمح للمستخدم باستدعاء أوامر اعتباطية.

عندما لا يكون $SYSTEMD_PAGERSECURE مضبوطًا، تحاول أدوات systemd آليًا معرفة ما إذا كان ينبغي تفعيل "النمط الآمن" وما إذا كان المستعرض يدعمه. يُفعل "النمط الآمن" إذا كان معرف المستخدم الفعلي ليس هو نفسه مالك جلسة الولوج، انظر geteuid(2) و sd_pid_get_owner_uid(3)، أو عند التشغيل تحت sudo(8) أو أدوات مماثلة ($SUDO_UID مضبوط [6]). في تلك الحالات، سيُضبط SYSTEMD_PAGERSECURE=1 ولن تُستخدم المستعرضات التي لا يُعرف عنها تنفيذ "النمط الآمن" على الإطلاق. لاحظ أن هذا الاكتشاف الآلي يغطي فقط الآليات الأكثر شيوعًا لرفع الامتيازات وهو مخصص للتسهيل. يوصى بضبط $SYSTEMD_PAGERSECURE صراحة أو تعطيل المستعرض.

لاحظ أنه إذا أُريد احترام المتغيرات $SYSTEMD_PAGER أو $PAGER، لغير غرض تعطيل مستعرض الصفحات، فيجب ضبط $SYSTEMD_PAGERSECURE أيضًا.

$SYSTEMD_COLORS

يأخذ وسيطًا منطقيًا (boolean)، أو قيمة خاصة. مبدئيًا (عند عدم الضبط)، سيستخدم systemd والأدوات المرتبطة به الألوان في مخرجاتها إذا أمكن ذلك. إذا ضُبط $COLORTERM على "truecolor" أو "24bit"، فسيتم تمكين ألوان 24 بت، وإلا فستُستخدم 256 لونًا، ما لم يشر $NO_COLOR أو $TERM إلى تعطيل الألوان.

true

نفس حالة عدم الضبط، باستثناء تجاهل $NO_COLOR.

false

سيكون المخرج أحادي اللون.

"16"، "256"، "24bit"

استخدم دائمًا ألوان ANSI الـ 16 الأساسية، أو 256 لونًا، أو لون 24 بت، على التوالي.

"auto-16"، "auto-256"، "auto-24bit"

استخدم كمية الألوان المعطاة، بشرط $TERM، وما هو متصل بالطرفية.

$SYSTEMD_URLIFY

يجب أن تكون القيمة منطقية. تتحكم فيما إذا كان يجب توليد روابط قابلة للنقر في المخرج لمحاكيات الطرفية التي تدعم ذلك. يمكن تحديد هذا لتجاوز القرار الذي يتخذه systemd بناءً على $TERM وشروط أخرى.

أمثلة¶

المثال 1. نزّل صورة TAR لأوبونتو وافتح صدفة فيها

# importctl pull-tar -mN https://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64-root.tar.xz
# systemd-nspawn -M jammy-server-cloudimg-amd64-root

ينزل هذا صورة .tar المحددة ويتحقق منها، ثم يستخدم systemd-nspawn(1) لفتح صدفة فيها.

المثال 2. ابنِ وأقلع توزيعة Fedora دنيا في حاوية

# dnf -y --releasever=43 --installroot=/var/lib/machines/f43 \


      --use-host-config --setopt=install_weak_deps=0 \


      --repo=fedora --repo=updates install \


      passwd dnf fedora-release nano util-linux systemd systemd-networkd
# systemd-nspawn -bD /var/lib/machines/f43

(تجاهل --use-host-config عند استخدام dnf أصغر من أو يساوي 4.) يثبت هذا توزيعة Fedora دنيا في الدليل /var/lib/machines/f43 ثم يقلع نظام التشغيل هذا في حاوية فضاء أسماء. نظرًا لأن التثبيت يقع تحت الدليل القياسي /var/lib/machines/، فمن الممكن أيضًا بدء تشغيل الآلة باستخدام systemd-nspawn -M f43.

المثال 3. أنشئ صدفة في حاوية لتوزيعة Debian غير مستقرة دنيا

# debootstrap unstable ~/debian-tree/
# systemd-nspawn -D ~/debian-tree/

يثبت هذا توزيعة Debian غير مستقرة دنيا في الدليل ~/debian-tree/ ثم ينشئ صدفة من هذه الصورة في حاوية فضاء أسماء.

يدعم debootstrap توزيعتي Debian[7]، و Ubuntu[8] تلقائيًا، لذا يمكن استخدام نفس الأمر لتثبيت أي منهما. بالنسبة للتوزيعات الأخرى من عائلة Debian، يجب تحديد مرآة، انظر debootstrap(8).

المثال 4. أقلع توزيعة Arch Linux دنيا في حاوية

# pacstrap -c ~/arch-tree/ base
# systemd-nspawn -bD ~/arch-tree/

يثبت هذا توزيعة Arch Linux دنيا في الدليل ~/arch-tree/ ثم يقلع نظام تشغيل في حاوية فضاء أسماء فيها.

المثال 5. ثبت توزيعة OpenSUSE Tumbleweed المتدحرجة

# zypper --root=/var/lib/machines/tumbleweed ar -c \


      https://download.opensuse.org/tumbleweed/repo/oss tumbleweed
# zypper --root=/var/lib/machines/tumbleweed refresh
# zypper --root=/var/lib/machines/tumbleweed install --no-recommends \


      systemd shadow zypper openSUSE-release vim
# systemd-nspawn -M tumbleweed passwd root
# systemd-nspawn -M tumbleweed -b

المثال 6. أقلع في لقطة عابرة لنظام المضيف

# systemd-nspawn -D / -xb

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

المثال 7. شغل حاوية مع سياقات أمان SELinux المعزولة

# chcon system_u:object_r:svirt_sandbox_file_t:s0:c0,c1 -R /srv/container
# systemd-nspawn -L system_u:object_r:svirt_sandbox_file_t:s0:c0,c1 \


      -Z system_u:system_r:svirt_lxc_net_t:s0:c0,c1 -D /srv/container /bin/sh

المثال 8. شغل حاوية مع نشر OSTree

# systemd-nspawn -b -i ~/image.raw \


      --pivot-root=/ostree/deploy/$OS/deploy/$CHECKSUM:/sysroot \


      --bind=+/sysroot/ostree/deploy/$OS/var:/var