| SYSTEMD-NSPAWN(1) | systemd-nspawn | SYSTEMD-NSPAWN(1) |
نام (NAME)
systemd-nspawn - اجرای فرمان یا سیستمعامل در یک کانتینر سبک فضاینام (Namespace)
خلاصه دستور (SYNOPSIS)
systemd-nspawn [OPTIONS...] [COMMAND [ARGS...]]
systemd-nspawn --boot [OPTIONS...] [ARGS...]
توضیحات (DESCRIPTION)
systemd-nspawn میتواند برای اجرای یک فرمان یا سیستمعامل در یک کانتینر سبک فضاینام (namespace) استفاده شود. از جهات بسیاری مشابه chroot(1) است، اما بسیار قدرتمندتر زیرا ساختار سلسلهمراتبی سیستمفایل و همچنین درخت فرآیندها، زیرسیستمهای مختلف IPC، و نامهای میزبان و دامنه را مجازیسازی میکند.
systemd-nspawn میتواند بر روی هر درخت دایرکتوری شامل یک درخت سیستمعامل، با استفاده از گزینه خط فرمان --directory= فراخوانی شود. با استفاده از گزینه --machine= یک درخت سیستمعامل بهطور خودکار در چند مکان جستجو میشود، بهویژه در /var/lib/machines/، که دایرکتوری پیشنهادی برای قرار دادن تصاویر کانتینر سیستمعامل نصبشده روی سیستم است.
برخلاف chroot(1)، systemd-nspawn میتواند برای بوت کردن سیستمهای عامل کامل مبتنی بر لینوکس در یک کانتینر استفاده شود.
systemd-nspawn دسترسی به واسطهای مختلف هسته در کانتینر مانند /sys/، /proc/sys/ یا /sys/fs/selinux/ را به حالت فقطخواندنی محدود میکند. واسطهای شبکه میزبان و ساعت سیستم را نمیتوان از درون کانتینر تغییر داد. گرههای دستگاه را نمیتوان ایجاد کرد. سیستم میزبان را نمیتوان راهاندازی مجدد کرد و ماژولهای هسته را نمیتوان از درون کانتینر بارگذاری نمود. اگر از فضاهاینام کاربر (user namespaces) استفاده نشود، این جعبهشنی (sandbox) را میتوان به راحتی از درون کانتینر دور زد. این بدان معناست که کدهای غیرقابلاعتماد باید همیشه در یک فضاینام کاربر اجرا شوند؛ به توضیحات گزینه --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 مشخصات Container Interface[1] را پیادهسازی میکند.
کانتینرهای فراخوانیشده با systemd-nspawn در زمان اجرا در سرویس systemd-machined(8) ثبت میشوند که کانتینرهای در حال اجرا را پیگیری کرده و واسطهای برنامهنویسی را برای تعامل با آنها فراهم میسازد.
عملیات بدون امتیاز ویژه (UNPRIVILEGED OPERATION)
systemd-nspawn میتواند با یا بدون امتیازات ویژه فراخوانی شود. عملکرد کامل در حال حاضر تنها زمانی در دسترس است که با امتیازات ویژه فراخوانی شود. هنگام فراخوانی بدون امتیاز، محدودیتهای مختلفی اعمال میشود، از جمله اما نه محدود به موارد زیر:
هنگام اجرا در حالت بدون امتیاز، برخی از عملکردهای مورد نیاز از طریق systemd-mountfsd.service(8) و systemd-nsresourced.service(8) ارائه میشوند.
گزینهها (OPTIONS)
اگر گزینه --boot مشخص شود، آرگومانها به عنوان آرگومانهای برنامه آغازین (init) استفاده میشوند. در غیر این صورت، COMMAND برنامهای را برای اجرا در کانتینر مشخص میکند و آرگومانهای باقیمانده به عنوان آرگومانهای این برنامه استفاده میشوند. اگر --boot استفاده نشود و هیچ آرگومانی مشخص نگردد، یک پوسته (shell) در کانتینر اجرا میشود.
گزینههای زیر پشتیبانی میشوند:
-q, --quiet
افزودهشده در نسخه 209.
--settings=MODE
در صورت فعال بودن (پیشفرض)، یک فایل تنظیمات همنام با ماشین (همانطور که با تنظیم --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
افزودهشده در نسخه 257.
گزینههای تصویر (Image Options)
-D, --directory=
اگر نه --directory= و نه --image= مشخص نشوند، دایرکتوری با جستجو برای دایرکتوری همنام با نام ماشین مشخصشده با --machine= تعیین میشود. برای مسیر دقیق جستجو، بخش «فایلها و دایرکتوریها» در machinectl(1) را ببینید.
به جای مسیر دایرکتوری میتوان یک دایرکتوری نسخهبندیشده ".v/" را مشخص کرد، برای جزئیات systemd.v(7) را ببینید.
اگر هیچکدام از گزینههای --directory=، --image= یا --machine= مشخص نشوند، دایرکتوری جاری استفاده خواهد شد. نمیتواند همراه با --image= مشخص شود.
--template=
توجه داشته باشید که این سوئیچ، نام میزبان، شناسه ماشین و تمام تنظیمات دیگری را که میتوانند نمونه را شناسایی کنند دستنخورده باقی میگذارد.
افزودهشده در نسخه 219.
-x, --ephemeral
توجه داشته باشید که این سوئیچ، نام میزبان، شناسه ماشین و تمام تنظیمات دیگری را که میتوانند نمونه را شناسایی کنند دستنخورده باقی میگذارد. لطفاً توجه داشته باشید که — مانند --template= — گرفتن اسنپشات موقت در سیستمهای فایلی که به طور بومی از اسنپشاتهای زیرحجم یا 'reflink'ها پشتیبانی میکنند (مانند "btrfs" یا "xfs" جدید) نسبت به سیستمهای فایل سنتیتر که پشتیبانی نمیکنند (مانند "ext4") کارآمدتر است. توجه داشته باشید که اسنپشات گرفتهشده از دایرکتوری یا زیرحجم مشخصشده، شامل تمام زیردایرکتوریها و زیرحجمهای زیر آن است، اما هرگونه زیرمانت را شامل نمیشود.
با این گزینه هیچ تغییری در تصویر کانتینر حفظ نمیشود. از --volatile= (توضیح داده شده در زیر) برای سایر سازوکارها به منظور محدود کردن ماندگاری تصاویر کانتینر در زمان اجرا استفاده کنید.
افزودهشده در نسخه 219.
-i, --image=
در تصاویر GPT، اگر یک پارتیشن سیستم EFI (ESP) کشف شود، در صورتی که دایرکتوری با این نام وجود داشته و خالی باشد، بهطور خودکار در /efi (یا /boot به عنوان جایگزین) مانت میشود.
پارتیشنهای رمزنگاریشده با LUKS بهطور خودکار رمزگشایی میشوند. همچنین، در تصاویر GPT در صورتی که هش ریشه برای آنها با استفاده از گزینه --root-hash= مشخص شده باشد، پارتیشنهای هش یکپارچگی داده dm-verity راهاندازی میشوند.
تصاویر تک سیستمفایل (یعنی سیستمهای فایل بدون جدول پارتیشن پیرامونی) را میتوان با استفاده از dm-verity باز کرد، در صورتی که دادههای یکپارچگی با استفاده از گزینههای --root-hash= و --verity-data= (و به صورت اختیاری --root-hash-sig=) ارسال شوند.
هرگونه پارتیشن دیگر مانند پارتیشنهای خارجی یا پارتیشنهای swap مانت نمیشوند. نمیتواند همراه با --directory= یا --template= مشخص شود.
به جای مسیر تصویر میتوان یک دایرکتوری نسخهبندیشده ".v/" را مشخص کرد، برای جزئیات systemd.v(7) را ببینید.
افزودهشده در نسخه 211.
--image-policy=policy
افزودهشده در نسخه 254.
--mstack=
افزودهشده در نسخه 260.
--oci-bundle=
افزودهشده در نسخه 242.
--read-only
--volatile, --volatile=MODE
توجه داشته باشید که اگر یکی از حالتهای فرار انتخاب شود، اثر آن محدود به سیستمفایل ریشه (یا /var/ در مورد state) است و هر مانت دیگری که در سلسلهمراتب قرار گیرد تحت تأثیر قرار نمیگیرد — صرفنظر از اینکه به طور خودکار ایجاد شده باشد (مانند پارتیشن سیستم EFI که ممکن است در /efi/ یا /boot/ مانت شود) یا به صراحت (مثلاً از طریق یک گزینه خط فرمان اضافی مانند --bind=، به زیر مراجعه کنید). این بدان معناست که حتی اگر --volatile=overlay استفاده شود، در صورت وجود چنین پارتیشنی در تصویر کانتینر مورد استفاده، تغییرات در /efi/ یا /boot/ ممنوع است، و حتی اگر --volatile=state استفاده شود، در صورتی که --bind=/etc/foobar برای مانت کردن آن از خارج از دایرکتوری فقطخواندنی /etc/ کانتینر استفاده شود، فایل فرضی /etc/foobar احتمالاً قابل نوشتن خواهد بود.
گزینه --ephemeral ارتباط نزدیکی با این تنظیم دارد و رفتاری مشابه را با ایجاد یک کپی موقت و زودگذر از کل تصویر سیستمعامل و اجرای آن فراهم میسازد. برای جزئیات بیشتر به بالا مراجعه کنید.
گزینههای --tmpfs= و --overlay= عملکرد مشابهی را ارائه میدهند، اما تنها برای زیردایرکتوریهای خاصی از تصویر سیستمعامل. برای جزئیات به زیر مراجعه کنید.
این گزینه عملکرد مشابهی را برای کانتینرها ارائه میدهد که سوئیچ خط فرمان هسته "systemd.volatile=" برای سیستمهای میزبان فراهم میکند. برای جزئیات به kernel-command-line(7) مراجعه کنید.
توجه داشته باشید که تنظیم این گزینه روی yes یا state تنها با سیستمهای عاملی در کانتینر به درستی کار خواهد کرد که بتوانند تنها با مانت بودن /usr/ بوت شوند، و قادر باشند به طور خودکار /var/ (و در مورد "--volatile=yes"، /etc/) را پر کنند. به طور خاص، این بدان معناست که سیستمهای عاملی که از تفکیک تاریخی /bin/ و /lib/ (و دایرکتوریهای مرتبط) از /usr/ پیروی میکنند (یعنی جایی که موارد قبلی پیوند نمادین به مورد اخیر نیستند) توسط "--volatile=yes" به عنوان بار مفید کانتینر پشتیبانی نمیشوند. گزینه overlay به هیچ آمادهسازی خاصی در سیستمعامل نیاز ندارد، اما توجه داشته باشید که رفتار "overlayfs" از چندین جهت با سیستمهای فایل معمولی تفاوت دارد، و از این رو سازگاری آن محدود است.
افزودهشده در نسخه 216.
--root-hash=
توجه داشته باشید که این گزینه هش ریشه را برای سیستمفایل ریشه پیکربندی میکند. تصاویر دیسک ممکن است حاوی سیستمهای فایل جداگانهای برای سلسلهمراتب /usr/ باشند که ممکن است آنها نیز توسط Verity محافظت شوند. هش ریشه برای این حفاظت ممکن است از طریق ویژگی فایل گسترشیافته "user.verity.usrhash" یا از طریق یک فایل .usrhash در مجاورت تصویر دیسک، با پیروی از همان قالب و منطق توصیفشده در اینجا برای هش ریشه سیستمفایل ریشه، پیکربندی شود. توجه داشته باشید که در حال حاضر هیچ سوئیچی برای پیکربندی هش ریشه برای /usr/ از خط فرمان وجود ندارد.
همچنین گزینه RootHash= در systemd.exec(5) را ببینید.
افزودهشده در نسخه 233.
--root-hash-sig=
افزودهشده در نسخه 246.
--verity-data=
افزودهشده در نسخه 246.
--pivot-root=
این گزینه برای کانتینرهایی است که دارای چندین دایرکتوری قابل بوت در خود هستند؛ برای مثال چندین استقرار ostree(1). این رفتار بوتلودر و initrd را شبیهسازی میکند که معمولاً انتخاب میکنند کدام دایرکتوری به عنوان ریشه مانت شود و PID 1 کانتینر در آن شروع به کار کند.
افزودهشده در نسخه 233.
گزینههای اجرا (Execution Options)
-a, --as-pid2
افزودهشده در نسخه 229.
-b, --boot
جدول زیر حالتهای مختلف فراخوانی و ارتباط با --as-pid2 (به بالا مراجعه کنید) را توضیح میدهد:
Table 1. Invocation Mode
| سوئیچ | توضیحات |
| نه --as-pid2 و نه --boot مشخص نشده است | پارامترهای ارائهشده به عنوان خط فرمان تفسیر میشوند که به عنوان PID 1 در کانتینر اجرا میگردد. |
| --as-pid2 مشخص شده است | پارامترهای ارائهشده به عنوان خط فرمان تفسیر میشوند که به عنوان PID 2 در کانتینر اجرا میگردد. یک فرآیند آغازین ساختگی به عنوان PID 1 اجرا میشود. |
| --boot مشخص شده است | یک برنامه آغازین به طور خودکار جستجو شده و به عنوان PID 1 در کانتینر اجرا میشود. پارامترهای ارائهشده به عنوان پارامترهای فراخوانی برای این فرآیند استفاده میشوند. |
توجه
داشته
باشید که
اگر از فایل
واحد الگوی
systemd-nspawn@.service
استفاده
شود، --boot
حالت
عملکرد
پیشفرض
است.
هنگامی که --boot استفاده میشود، پارامترهای ارائهشده به همان روشی که هسته خط فرمان خود را قبل از تحویل به PID 1 پردازش میکند، پردازش میشوند: هر انتساب "KEY=VALUE" که "KEY" آن حاوی "." نباشد، به عنوان یک متغیر محیطی برای PID 1 صادر میشود (با جایگزینی "-" در کلید با "_" همانند حالتی که از طریق --setenv= مشخص شده باشد)، در حالی که تمام پارامترهای دیگر (از جمله انتسابهای "systemd.*=") به عنوان آرگومان به برنامه آغازین منتقل میشوند.
--chdir=
افزودهشده در نسخه 229.
-E NAME[=VALUE], --setenv=NAME[=VALUE]
افزودهشده در نسخه 209.
-u, --uid=
توجه داشته باشید که اگر اعتبارنامهها در ترکیب با یک --uid= غیر ریشه استفاده شوند (مثلاً: --set-credential= یا --load-credential=)، آنگاه --no-new-privileges=yes باید استفاده شود، و --boot یا --as-pid2 نباید استفاده شوند، زیرا در غیر این صورت اعتبارنامهها به دلیل عدم وجود امتیازات پس از تغییر به کاربر مشخصشده، توسط کانتینر غیرقابلخواندن خواهند بود.
--kill-signal=
افزودهشده در نسخه 220.
--notify-ready=
پیشفرض false است. (توجه داشته باشید که این بر خلاف گزینه همنام در systemd-vmspawn(1) است که پیشفرض آن true میباشد.)
اگر خود systemd-nspawn با مقدار $NOTIFY_SOCKET تنظیمشده در محیط خود فراخوانی شود (یعنی خود آن توسط یک مدیر سرویس که از پروتکل sd_notify(3) استفاده میکند نظارت شود)، پیامهای "FDSTORE=1" و "FDSTOREREMOVE=1" دریافتشده از بار مفید کانتینر (همراه با هر توصیفکننده فایل همراه و برچسب "FDNAME=") یک سطح بالاتر به مدیر سرویس دربرگیرنده ارسال میشوند. این امر اجازه میدهد تا مخزن توصیفکننده فایل سرویسهای در حال اجرا در کانتینر در هنگام راهاندازیهای مجدد کانتینر (و به طور متعدی، در طول راهاندازیهای مجدد، اجرای مجدد، راهاندازیهای مجدد نرم و kexecهای مبتنی بر LUO در هر مدیر سرویس بیرونی) حفظ شود، به شرطی که FileDescriptorStoreMax=/FileDescriptorStorePreserve=yes روی واحد اجراکننده systemd-nspawn پیکربندی شده باشند. برای جزئیات، مستندات File Descriptor Store[4] را ببینید.
افزودهشده در نسخه 231.
--suppress-sync=
افزودهشده در نسخه 250.
گزینههای هویت سیستم (System Identity Options)
-M, --machine=
افزودهشده در نسخه 202.
--hostname=
افزودهشده در نسخه 239.
--uuid=
گزینههای مشخصه (Property Options)
-S, --slice=
افزودهشده در نسخه 206.
--property=
افزودهشده در نسخه 220.
--register=
افزودهشده در نسخه 209.
--keep-unit
توجه داشته باشید که ارسال --keep-unit اثر --slice= و --property= را غیرفعال میکند. از --keep-unit و --register=no به صورت ترکیبی استفاده کنید تا هر نوع تخصیص واحد یا ثبت در systemd-machined غیرفعال شود.
افزودهشده در نسخه 209.
گزینههای فضاینام کاربر (User Namespacing Options)
--private-users=
توصیه میشود حداقل ۶۵۵۳۶ UID/GID به هر کانتینر اختصاص داده شود تا محدوده UID/GID قابل استفاده در کانتینر ۱۶ بیت را پوشش دهد. برای بهترین امنیت، محدودههای UID/GID همپوشان را به چندین کانتینر اختصاص ندهید. بنابراین ایده خوبی است که از ۱۶ بیت بالایی UIDها/GIDهای ۳۲ بیتی میزبان به عنوان شناسه کانتینر استفاده شود، در حالی که ۱۶ بیت پایینی 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 اعمالشده است.
توجه داشته باشید که برای عملکرد کاملاً بدون امتیاز در حالت "managed"، هر تصویر دایرکتوری باید متعلق به محدوده UID خارجی باشد.
افزودهشده در نسخه 220.
--private-users-ownership=
اگر "chown" انتخاب شود، تمام فایلها و دایرکتوریهای موجود در درخت دایرکتوری کانتینر تنظیم خواهند شد تا متعلق به UIDها/GIDهای مناسب انتخابشده برای کانتینر باشند (به بالا مراجعه کنید). این عملیات بالقوه پرهزینه است، زیرا شامل پیمایش در کل درخت دایرکتوری کانتینر میشود. علاوه بر مالکیت واقعی فایل، ACLهای فایل نیز تنظیم میشوند.
به طور معمول "foreign" یا "map" بهترین انتخاب است، زیرا UIDها/GIDها را به صورت شفاف در حافظه بر حسب نیاز بدون تغییر تصویر و بدون نیاز به یک عملیات تنظیم بازگشتی پرهزینه نگاشت میکند. با این حال، در حال حاضر برای همه سیستمهای فایل در دسترس نیست.
گزینه --private-users-ownership=auto در صورت استفاده از --private-users=pick به صورت ضمنی اعمال میشود. این گزینه در صورتی که از فضاینام کاربر استفاده نشود، هیچ اثری ندارد.
سوئیچ --shift در systemd-dissect(1) ممکن است برای جابجایی مالکیت UID/GID از یا به پایه UID/GID صفر، خارجی یا کانتینر خاص در خارج از هرگونه فراخوانی systemd-nspawn استفاده شود.
افزودهشده در نسخه 230.
--private-users-delegate=
این گزینه به --private-users=managed نیاز دارد، زیرا این تفویض توسط systemd-nsresourced.service(8) به عنوان بخشی از تخصیص فضاینام کاربر انجام میشود. حداکثر تعداد محدودههای تفویضشده ۱۶ است. پیشفرض 0 است، یعنی بدون تفویض.
هنگامی که این گزینه با یک مقدار غیرصفر استفاده میشود، سوکت Varlink سرویس systemd-nsresourced.service(8) (/run/systemd/io.systemd.NamespaceResource) به طور خودکار به همراه پیوندهای نمادین کشف لازم در /run/systemd/userdb/ و /run/varlink/registry/ به درون کانتینر bind-mount میشود. این به فرآیندهای درون کانتینر اجازه میدهد تا با systemd-nsresourced روی میزبان تماس بگیرند تا فضاهاینام کاربر تودرتو را از محدودههای تفویضشده تخصیص دهند.
افزودهشده در نسخه 260.
-U
توجه داشته باشید که اگر از فایل واحد الگوی systemd-nspawn@.service استفاده شود، -U حالت پیشفرض است.
نکته: با تکرار عملیات با اولین UID معادل 0، میتوان اثر --private-users-ownership=chown (یا -U) بر سیستم فایل را خنثی کرد:
systemd-nspawn ... --private-users=0 --private-users-ownership=chown
افزودهشده در نسخه 230.
گزینههای شبکه (Networking Options)
--private-network
--network-interface=
توجه داشته باشید که هر واسط شبکه مشخصشده از این طریق باید در زمان شروع کانتینر از قبل وجود داشته باشد. اگر قرار است کانتینر به طور خودکار هنگام بوت از طریق یک نمونه فایل واحد 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=
همانند --network-interface=، واسط شبکه اترنت زیرین باید در زمان شروع کانتینر از قبل وجود داشته باشد، و بنابراین فایلهای قطرهای مشابه فایل واحد همانطور که در بالا توضیح داده شد ممکن است مفید باشند.
افزودهشده در نسخه 211.
--network-ipvlan=
همانند --network-interface=، واسط شبکه اترنت زیرین باید در زمان شروع کانتینر از قبل وجود داشته باشد، و بنابراین فایلهای قطرهای مشابه فایل واحد همانطور که در بالا توضیح داده شد ممکن است مفید باشند.
افزودهشده در نسخه 219.
-n, --network-veth
توجه داشته باشید که 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 حالت پیشفرض است.
توجه داشته باشید که در لینوکس نام واسطهای شبکه حداکثر میتواند ۱۵ کاراکتر طول داشته باشد، در حالی که نام کانتینرها میتواند تا ۶۴ کاراکتر طول داشته باشد. از آنجا که این گزینه نام واسط سمت میزبان را از نام کانتینر مشتق میکند، ممکن است نام کوتاه شود. بنابراین، باید دقت شود تا اطمینان حاصل شود که نامهای واسط در این حالت منحصربهفرد باقی میمانند، یا حتی بهتر است نام کانتینرها عموماً بیشتر از ۱۲ کاراکتر انتخاب نشوند تا از کوتاهسازی جلوگیری گردد. اگر نام کوتاه شود، systemd-nspawn به طور خودکار یک مقدار هش ۴ رقمی را به نام الحاق میکند تا احتمال تداخل کاهش یابد. با این حال، الگوریتم هش بدون برخورد نیست. (برای جزئیات در مورد الگوریتمهای نامگذاری قدیمیتر برای این واسط، systemd.net-naming-scheme(7) را ببینید). از طرف دیگر، گزینه --network-veth-extra= میتواند استفاده شود که اجازه پیکربندی آزاد نام واسط سمت میزبان را مستقل از نام کانتینر میدهد — اما ممکن است در صورتی که پلبندی به روشی مشابه --network-bridge= مورد نظر باشد، به کمی پیکربندی اضافی نیاز داشته باشد.
افزودهشده در نسخه 209.
--network-veth-extra=
افزودهشده در نسخه 228.
--network-bridge=
همانند --network-interface=، واسط شبکه پل زیرین باید در زمان شروع کانتینر از قبل وجود داشته باشد، و بنابراین فایلهای قطرهای مشابه فایل واحد همانطور که در بالا توضیح داده شد ممکن است مفید باشند.
افزودهشده در نسخه 209.
--network-zone=
این تنظیم قرار دادن چندین کانتینر مرتبط را در یک دامنه انتشار مشترک مبتنی بر اترنت مجازی، که در اینجا «ناحیه» (zone) نامیده میشود، آسان میکند. هر کانتینر تنها میتواند بخشی از یک ناحیه باشد، اما هر ناحیه میتواند شامل هر تعداد کانتینر باشد. هر ناحیه با نام خود ارجاع داده میشود. نامها را میتوان آزادانه انتخاب کرد (تا زمانی که با پیشوند "vz-" نامهای معتبر واسط شبکه را تشکیل دهند)، و کافی است همان نام را به سوئیچ --network-zone= کانتینرهای مختلف در حال اجرای همزمان ارسال کنید تا به یک ناحیه بپیوندند.
توجه داشته باشید که systemd-networkd.service(8) به طور پیشفرض شامل یک فایل شبکه /usr/lib/systemd/network/80-container-vz.network مطابق با واسطهای پل ایجادشده از این طریق است، که شامل تنظیماتی برای فعالسازی تخصیص خودکار آدرس در شبکه مجازی ایجادشده از طریق DHCP، و همچنین مسیریابی خودکار IP به واسطهای شبکه خارجی میزبان میباشد. بنابراین استفاده از --network-zone= در اکثر موارد کاملاً خودکار و برای اتصال چندین کانتینر محلی در یک دامنه انتشار مشترک به میزبان، با اتصال بیشتر به شبکه خارجی کافی است.
افزودهشده در نسخه 230.
--network-namespace-path=
افزودهشده در نسخه 236.
-p, --port=
افزودهشده در نسخه 219.
گزینههای امنیت (Security Options)
--capability=
اگر مقدار ویژه "help" ارسال شود، برنامه نامهای قابلیتهای شناختهشده را چاپ کرده و خارج میشود.
این گزینه مجموعه محدودکننده قابلیتها (bounding set) را تنظیم میکند که قابلیتهای فراگیر (ambient capabilities) دادهشده با --ambient-capability= را نیز محدود مینماید.
افزودهشده در نسخه 186.
--drop-capability=
اگر مقدار ویژه "help" ارسال شود، برنامه نامهای قابلیتهای شناختهشده را چاپ کرده و خارج میشود.
این گزینه مجموعه محدودکننده قابلیتها را تنظیم میکند که قابلیتهای فراگیر دادهشده با --ambient-capability= را نیز محدود مینماید.
افزودهشده در نسخه 209.
--ambient-capability=
تمام قابلیتهای مشخصشده در اینجا باید در مجموعه مجاز با گزینههای --capability= و --drop-capability= باشند. در غیر این صورت، یک پیام خطا نمایش داده خواهد شد.
این گزینه نمیتواند با حالت بوت کانتینر (همانطور که از طریق --boot درخواست میشود) ترکیب شود.
اگر مقدار ویژه "help" ارسال شود، برنامه نامهای قابلیتهای شناختهشده را چاپ کرده و خارج میشود.
افزودهشده در نسخه 248.
--no-new-privileges=
افزودهشده در نسخه 239.
--system-call-filter=
افزودهشده در نسخه 235.
--restrict-address-families=
توجه داشته باشید که در حال حاضر این گزینه به صورت پیشفرض بدون محدودیت است، یعنی همه خانوادههای آدرس در دسترس هستند. در نسخه آینده systemd، حالت پیشفرض تغییر خواهد کرد تا خانوادههای آدرس به AF_INET، AF_INET6 و AF_UNIX محدود شوند. از --restrict-address-families= (با یک آرگومان خالی) استفاده کنید یا RestrictAddressFamilies= را در یک فایل .nspawn تنظیم کنید تا صراحتاً از فیلتر کردن انصراف دهید.
افزودهشده در نسخه 261.
-Z, --selinux-context=
افزودهشده در نسخه 209.
-L, --selinux-apifs-context=
افزودهشده در نسخه 209.
گزینههای منابع (Resource Options)
--rlimit=
افزودهشده در نسخه 239.
--oom-score-adjust=
افزودهشده در نسخه 239.
--cpu-affinity=
افزودهشده در نسخه 239.
--personality=
افزودهشده در نسخه 209.
گزینههای یکپارچهسازی (Integration Options)
--resolv-conf=
اگر روی "off" تنظیم شود، فایل /etc/resolv.conf در کانتینر همانطور که در تصویر گنجانده شده است باقی میماند، و نه تغییر مییابد و نه چیزی روی آن bind-mount میشود.
اگر روی "copy-host" تنظیم شود، فایل /etc/resolv.conf از میزبان به درون کانتینر کپی میشود، مگر اینکه فایل از قبل وجود داشته و یک فایل معمولی نباشد (مثلاً یک پیوند نمادین). به طور مشابه، اگر "replace-host" استفاده شود، فایل کپی شده و جایگزین هر اینود موجود از جمله پیوندهای نمادین میشود. به طور مشابه، اگر "bind-host" استفاده شود، فایل از میزبان به درون کانتینر bind-mount میشود.
اگر روی "copy-static"، "replace-static" یا "bind-static" تنظیم شود، فایل ایستا resolv.conf ارائهشده با systemd-resolved.service(8) (به طور خاص: /usr/lib/systemd/resolv.conf) به درون کانتینر کپی یا bind-mount میشود.
اگر روی "copy-uplink"، "replace-uplink" یا "bind-uplink" تنظیم شود، فایل آپلینک resolv.conf مدیریتشده توسط systemd-resolved.service (به طور خاص: /run/systemd/resolve/resolv.conf) به درون کانتینر کپی یا bind-mount میشود.
اگر روی "copy-stub"، "replace-stub" یا "bind-stub" تنظیم شود، فایل خرد (stub) resolv.conf مدیریتشده توسط systemd-resolved.service (به طور خاص: /run/systemd/resolve/stub-resolv.conf) به درون کانتینر کپی یا bind-mount میشود.
اگر روی "delete" تنظیم شود، فایل /etc/resolv.conf در کانتینر در صورت وجود حذف میگردد.
در نهایت، اگر روی "auto" تنظیم شود، در صورت روشن بودن شبکهسازی خصوصی (به --private-network مراجعه کنید) فایل به همان صورت باقی میماند. در غیر این صورت، اگر systemd-resolved.service در حال اجرا باشد از فایل خرد resolv.conf آن استفاده میشود، و اگر در حال اجرا نباشد از فایل /etc/resolv.conf میزبان استفاده میگردد. در حالتهای اخیر، اگر تصویر قابل نوشتن باشد، فایل کپی میشود، و در غیر این صورت bind-mount خواهد شد.
توصیه میشود در صورتی که کانتینر باید قادر به اعمال تغییرات در پیکربندی DNS به صورت مستقل و با انحراف از تنظیمات میزبان باشد، از "copy-..." یا "replace-..." استفاده کنید. در غیر این صورت، "bind" ارجحیت دارد، زیرا بدین معناست که تغییرات مستقیم در /etc/resolv.conf در کانتینر مجاز نیست، زیرا یک bind-mount فقطخواندنی است (اما توجه داشته باشید که اگر کانتینر امتیازات کافی داشته باشد، ممکن است به سادگی اقدام به آنمانت کردن bind-mount کند). توجه داشته باشید که چه فایل bind-mount شده باشد و چه کپی شده باشد، پس از مقداردهی اولیه زودهنگام یکباره، عموماً انتشار بیشتری از پیکربندی انجام نمیشود (این به این دلیل است که فایل معمولاً از طریق کپی کردن و تغییر نام بهروزرسانی میشود). پیشفرض "auto" است.
افزودهشده در نسخه 239.
--timezone=
افزودهشده در نسخه 239.
--link-journal=
توجه داشته باشید که اگر از فایل واحد الگوی systemd-nspawn@.service استفاده شود، --link-journal=try-guest حالت پیشفرض است.
افزودهشده در نسخه 187.
-j
افزودهشده در نسخه 187.
--forward-journal=
افزودهشده در نسخه 261.
--forward-journal-max-use=BYTES, --forward-journal-keep-free=BYTES, --forward-journal-max-file-size=BYTES, --forward-journal-max-files=N
افزودهشده در نسخه 261.
گزینههای مانت (Mount Options)
--bind=, --bind-ro=
گزینههای مانت با کاما جدا میشوند. rbind و norbind ایجاد یک bind-mount بازگشتی یا معمولی را کنترل میکنند. پیشفرض rbind است. noidmap، idmap، rootidmap و owneridmap نگاشت شناسه (ID mapping) را کنترل میکنند.
استفاده از idmap، rootidmap یا owneridmap نیازمند پشتیبانی سیستمفایل مبدا از مانتهای دارای نگاشت شناسه کاربر/گروه است. پیشفرض noidmap است. با فرض x به عنوان آفست محدوده UID کانتینر، y به عنوان طول محدوده UID کانتینر، و p به عنوان UID مالک اینود منبع bind-mount روی میزبان:
از هر گزینه نگاشت شناسهای که استفاده شود، همان نگاشت برای شناسههای کاربران و گروهها به کار خواهد رفت. اگر rootidmap یا owneridmap استفاده شوند، گروه مالک دایرکتوری bind-mount شده هیچ اثری نخواهد داشت.
توجه داشته باشید هنگامی که این گزینه در ترکیب با --private-users استفاده میشود، نقاط مانت حاصل متعلق به کاربر nobody خواهند بود. دلیل آن این است که مانت و فایلها و دایرکتوریهای آن همچنان متعلق به کاربران و گروههای مربوطه در میزبان هستند که در کانتینر وجود ندارند، و بنابراین تحت UID عام 65534 (nobody) نمایش داده میشوند. اگر چنین bind-mountهایی ایجاد شوند، توصیه میشود آنها را با استفاده از --bind-ro= به صورت فقطخواندنی درآورید. متناوباً میتوانید از گزینه مانت "idmap" برای نگاشت شناسههای سیستمفایل استفاده کنید.
افزودهشده در نسخه 198.
--bind-user=
ترکیب این دو عملیات فوق اطمینان میدهد که امکان ورود به کانتینر با استفاده از همان اطلاعات حساب کاربری موجود در میزبان وجود دارد. کاربر تنها به صورت موقت در حین اجرای کانتینر نگاشت میشود، و خود نگاشت منجر به تغییرات ماندگار در کانتینر نمیشود (به جز شاید پیامهای لاگ تولیدشده در زمان ورود و موارد مشابه). به ویژه توجه داشته باشید که انتساب UID/GID در کانتینر به صورت ماندگار انجام نمیشود. اگر کاربر به صورت موقت نگاشت شده باشد، بهتر است به کاربر اجازه ایجاد تغییرات ماندگار در کانتینر داده نشود. اگر کاربر فایلها یا دایرکتوریهایی متعلق به خود باقی بگذارد، و آن UIDها/GIDها در طول فراخوانیهای بعدی کانتینر (احتمالاً با یک نگاشت متفاوت --bind-user=) مجدداً استفاده شوند، آن فایلها و دایرکتوریها برای کاربر «جدید» قابل دسترسی خواهند بود.
نگاشت رکورد کاربر/گروه تنها در صورتی کار میکند که کانتینر حاوی systemd 249 یا جدیدتر باشد، و nss-systemd به درستی در nsswitch.conf پیکربندی شده باشد. برای جزئیات به nss-systemd(8) مراجعه کنید.
توجه داشته باشید که رکورد کاربر منتقلشده از میزبان به کانتینر حاوی هش رمز عبور یونیکس کاربر خواهد بود، تا ورود بدون درز به کانتینر امکانپذیر باشد. اگر کانتینر نسبت به میزبان کمتر مورد اعتماد باشد، بنابراین استفاده از یک تابع هش قوی رمز عبور یونیکس (مانند yescrypt یا مشابه آن، با پیشوند هش "$y$") بسیار حائز اهمیت است.
هنگام bind کردن یک کاربر از میزبان به کانتینر، بررسیهایی انجام میشود تا اطمینان حاصل گردد که نام کاربری هنوز در کانتینر شناختهشده نیست. علاوه بر این، بررسی میشود که UID/GID تخصیصیافته برای آن در حال حاضر در پایگاههای داده کاربر/گروه کانتینر تعریف نشده باشد. هر دو بررسی مستقیماً به /etc/passwd و /etc/group کانتینر دسترسی دارند، و بنابراین ممکن است حسابهای موجود در سایر پایگاههای داده را تشخیص ندهند.
افزودهشده در نسخه 249.
--bind-user-shell=
نکته: این گزینه وجود پوستههای مشخصشده در کانتینر را بررسی نخواهد کرد.
این عملیات تنها در ترکیب با --bind-user= پشتیبانی میشود.
افزودهشده در نسخه 258.
--bind-user-group=NAME
نکته: این گزینه وجود گروههای مشخصشده در کانتینر را بررسی نخواهد کرد.
این عملیات تنها در ترکیب با --bind-user= پشتیبانی میشود.
افزودهشده در نسخه 259.
--inaccessible=
افزودهشده در نسخه 242.
--tmpfs=
توجه داشته باشید که این گزینه نمیتواند برای جایگزینی سیستمفایل ریشه کانتینر با یک سیستمفایل موقت استفاده شود. با این حال، گزینه --volatile= که در زیر توضیح داده شده است عملکرد مشابهی را با تمرکز بر پیادهسازی تصاویر سیستمعامل بدون وضعیت (stateless) ارائه میدهد.
افزودهشده در نسخه 214.
--overlay=, --overlay-ro=
گریزهای بکاسلش در مسیرها تفسیر میشوند، بنابراین "\:" میتواند برای تعبیه دونقطه در مسیرها استفاده شود.
اگر سه یا چند مسیر مشخص شوند، آخرین مسیر مشخصشده نقطه مانت مقصد در کانتینر است، و تمام مسیرهای مشخصشده قبل از آن به درختهای دایرکتوری در میزبان ارجاع دارند و به ترتیب مشخصشده در یک سیستمفایل overlay ترکیب میشوند. بنابراین، چپترین مسیر پایینترین درخت دایرکتوری، و مسیر ماقبل آخر بالاترین درخت دایرکتوری در ترتیب چیدمان پشته است. اگر به جای --overlay= از --overlay-ro= استفاده شود، یک سیستمفایل overlay فقطخواندنی ایجاد میشود. اگر یک سیستمفایل overlay قابل نوشتن ایجاد شود، تمام تغییرات اعمالشده در آن در بالاترین درخت دایرکتوری در ترتیب چیدمان پشته، یعنی مسیر ماقبل آخر مشخصشده، نوشته میشوند.
اگر تنها دو مسیر مشخص شوند، دومین مسیر مشخصشده هم به عنوان بالاترین درخت دایرکتوری در ترتیب پشته همانطور که از میزبان دیده میشود، و هم به عنوان نقطه مانت برای سیستمفایل overlay در کانتینر استفاده خواهد شد. حداقل باید دو مسیر مشخص شود.
مسیرهای منبع ممکن است به صورت اختیاری با نویسه "+" پیشوندگذاری شوند. در این صورت آنها نسبت به دایرکتوری ریشه تصویر در نظر گرفته میشوند. بالاترین مسیر منبع نیز ممکن است به عنوان یک رشته خالی مشخص شود، که در این صورت یک دایرکتوری موقت در زیر /var/tmp/ میزبان استفاده میشود. دایرکتوری با خاموش شدن کانتینر به طور خودکار حذف میگردد. این رفتار برای قابلنوشتن کردن دایرکتوریهای فقطخواندنی کانتینر در حین اجرای کانتینر مفید است. برای مثال، از "--overlay=+/var::/var" استفاده کنید تا به طور خودکار یک دایرکتوری موقت قابل نوشتن را روی یک دایرکتوری فقطخواندنی /var/ همپوشانی نماید. اگر یک مسیر منبع مطلق نباشد، نسبت به دایرکتوری کاری جاری حل میشود.
برای جزئیات در مورد سیستمهای فایل overlay، Overlay Filesystem[5] را ببینید. توجه داشته باشید که معانی سیستمهای فایل overlay به طور قابل توجهی با سیستمهای فایل معمولی متفاوت است، به ویژه در رابطه با اطلاعات گزارششده دستگاه و اینود. اطلاعات دستگاه و اینود ممکن است برای یک فایل در حین نوشتن روی آن تغییر کند، و فرآیندها ممکن است گاهی نسخههای قدیمی فایلها را مشاهده کنند. توجه داشته باشید که این سوئیچ به طور خودکار گزینه مانت "workdir=" را برای سیستمفایل overlay از بالاترین درخت دایرکتوری مشتق میکند و آن را همسطح (همنیا) با آن قرار میدهد. بنابراین ضروری است که بالاترین درخت دایرکتوری خود یک نقطه مانت نباشد (زیرا دایرکتوری کاری باید روی همان سیستمفایلی باشد که بالاترین درخت دایرکتوری قرار دارد). همچنین توجه داشته باشید که گزینه مانت "lowerdir=" مسیرهای پشته را با ترتیبی معکوس نسبت به این سوئیچ دریافت میکند.
توجه داشته باشید که این گزینه نمیتواند برای جایگزینی سیستمفایل ریشه کانتینر با یک سیستمفایل overlay استفاده شود. با این حال، گزینه --volatile= توضیح داده شده در بالا قابلیت مشابهی را با تمرکز بر پیادهسازی تصاویر سیستمعامل بدون وضعیت فراهم میکند.
افزودهشده در نسخه 220.
گزینههای ورودی/خروجی (Input/Output Options)
--console=MODE
در حالت pipe، دستگاه /dev/console در کانتینر وجود نخواهد داشت. این بدان معناست که بار مفید کانتینر عموماً نمیتواند یک سیستم init کامل باشد زیرا سیستمهای init تمایل دارند به در دسترس بودن /dev/console وابسته باشند. از سوی دیگر، در این حالت فراخوانیهای کانتینر میتوانند در خط لولههای پوسته (shell pipelines) استفاده شوند. دلیل آن این است که pseudo TTYهای واسط اجازه انتشار دوطرفه مستقل وضعیت پایان فایل (EOF) را نمیدهند، که برای عملکرد صحیح خط لولههای پوسته ضروری است. توجه داشته باشید که حالت pipe باید با احتیاط استفاده شود، زیرا ارسال توصیفکنندههای فایل دلخواه به بارهای مفید کانتینر با قابلیت اطمینان کمتر ممکن است واسطهای ناخواستهای را برای دسترسی بار مفید کانتینر باز کند. به عنوان مثال، اگر یک توصیفکننده فایل ارسالشده به نوعی از TTY ارجاع دهد، APIهایی مانند TIOCSTI ممکن است برای ترکیب ورودی که ممکن است برای گریز از کانتینر استفاده شود، به کار روند. از این رو حالت pipe تنها باید در صورتی استفاده شود که بار مفید به اندازه کافی قابل اعتماد باشد یا زمانی که توصیفکنندههای فایل ورودی/خروجی/خروجی خطای استاندارد به عنوان موارد ایمن، به عنوان مثال پایپها، شناخته شده باشند.
افزودهشده در نسخه 242.
--pipe, -P
افزودهشده در نسخه 242.
--background=COLOR
افزودهشده در نسخه 256.
اعتبارنامهها (Credentials)
--load-credential=ID:PATH, --set-credential=ID:VALUE
نکته: هنگامی که systemd-nspawn به عنوان سرویس سیستمی systemd اجرا میشود، میتواند اعتبارنامههایی را که از طریق LoadCredential=/SetCredential= دریافت کرده است به بار مفید کانتینر منتقل کند. یک مدیر سرویس systemd که به عنوان PID 1 در کانتینر اجرا میشود میتواند آنها را بیشتر به سرویسهایی که خود راهاندازی میکند منتقل نماید. بنابراین میتوان به راحتی اعتبارنامهها را از یک مدیر سرویس والد به یک سرویس مدیر کانتینر و از آنجا به بار مفید آن منتقل کرد. این کار حتی میتواند به صورت بازگشتی انجام شود.
به منظور تعبیه دادههای دودویی در دادههای اعتبارنامه برای --set-credential=، از گریزهای سبک C استفاده کنید (یعنی "\n" برای تعبیه یک خط جدید، یا "\x00" برای تعبیه یک بایت NUL). توجه داشته باشید که پوسته فراخواننده ممکن است قبلاً یک بار گریززدایی را اعمال کرده باشد، بنابراین ممکن است به گریز مضاعف نیاز باشد!
سرویسهای systemd-sysusers.service(8) و systemd-firstboot(1) اعتبارنامههای پیکربندیشده از این طریق را به منظور پیکربندی رمز عبور و پوسته کاربر ریشه کانتینر و همچنین محلیسازی (locale)، نگاشت کلید و منطقه زمانی سیستم در طول فرآیند اولین بوت کانتینر میخوانند. این امر به ویژه در ترکیب با --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.
سایر گزینهها (Other)
--system, --user
نکته: برای سازگاری به عقب، --user که به دنبال آن یک آرگومان موقعیتی بیاید به عنوان فرم منسوخشده --user=NAME (اکنون --uid=) تفسیر میشود. برای استفاده از --user جهت انتخاب دامنه هنگامی که آرگومانهای موقعیتی در ادامه میآیند، آنها را با "--" جدا کنید.
افزودهشده در نسخه 261.
--no-pager
-h, --help
--version
--no-ask-password
کلیدهای میانبر (HOTKEYS)
هنگامی که در حالت تعاملی فراخوانی شود (یعنی حالت پیشفرض --console=interactive)، چند میانبر صفحهکلید ویژه که زمان اجرای کانتینر را کنترل میکنند، درک میشوند. این میانبرها باید در عرض ۱ ثانیه تایپ شوند تا اثرگذار باشند، در غیر این صورت به عنوان فشردن کلید معمولی به کانتینر ارسال خواهند شد.
Ctrl-] Ctrl-] Ctrl-]
Ctrl-] Ctrl-] r
افزودهشده در نسخه 258.
Ctrl-] Ctrl-] p
افزودهشده در نسخه 258.
محیط (ENVIRONMENT)
$SYSTEMD_LOG_LEVEL
$SYSTEMD_LOG_COLOR
این تنظیم تنها زمانی مفید است که پیامها مستقیماً در ترمینال نوشته شوند، زیرا journalctl(1) و سایر ابزارهایی که لاگها را نمایش میدهند، پیامها را خود بر اساس سطح لاگ رنگآمیزی میکنند.
$SYSTEMD_LOG_TIME
این تنظیم تنها زمانی مفید است که پیامها مستقیماً در ترمینال یا یک فایل نوشته شوند، زیرا journalctl(1) و سایر ابزارهایی که لاگها را نمایش میدهند، خود برچسبهای زمانی را بر اساس فرادادههای مدخل پیوست میکنند.
$SYSTEMD_LOG_LOCATION
توجه داشته باشید که محل لاگ در هر صورت اغلب به عنوان فراداده به مدخلهای ژورنال پیوست میشود. با این حال، گنجاندن مستقیم آن در متن پیام میتواند در هنگام اشکالزدایی برنامهها سودمند باشد.
$SYSTEMD_LOG_TID
توجه داشته باشید که این اطلاعات در هر صورت به عنوان فراداده به مدخلهای ژورنال پیوست میشود. با این حال، گنجاندن مستقیم آن در متن پیام میتواند در هنگام اشکالزدایی برنامهها سودمند باشد.
$SYSTEMD_LOG_TARGET
$SYSTEMD_LOG_RATELIMIT_KMSG
$SYSTEMD_PAGER, $PAGER
نکته: اگر $SYSTEMD_PAGERSECURE تنظیم نشده باشد، $SYSTEMD_PAGER و $PAGER تنها میتوانند برای غیرفعال کردن صفحهبند (با "cat" یا "") استفاده شوند، و در غیر این صورت نادیده گرفته میشوند.
$SYSTEMD_LESS
کاربران ممکن است به ویژه تمایل داشته باشند دو گزینه را تغییر دهند:
K
اگر مقدار $SYSTEMD_LESS شامل "K" نباشد و صفحهبند فراخوانیشده less باشد، Ctrl+C توسط برنامه اجرایی نادیده گرفته میشود و باید توسط صفحهبند مدیریت گردد.
X
توجه داشته باشید که تنظیم متغیر محیطی معمولی $LESS هیچ تاثیری بر فراخوانیهای less توسط ابزارهای systemd ندارد.
برای بحث بیشتر less(1) را ببینید.
$SYSTEMD_LESSCHARSET
توجه داشته باشید که تنظیم متغیر محیطی معمولی $LESSCHARSET هیچ تاثیری بر فراخوانیهای less توسط ابزارهای systemd ندارد.
$SYSTEMD_PAGERSECURE
این گزینه یک آرگومان بولی میپذیرد. در صورت تنظیم روی true، «حالت امن» صفحهبند فعال میشود. در «حالت امن»، LESSSECURE=1 هنگام فراخوانی صفحهبند تنظیم خواهد شد که به صفحهبند دستور میدهد دستوراتی را که فایلهای جدید باز میکنند یا ایجاد مینمایند یا زیرفرآیندهای جدیدی را آغاز میکنند غیرفعال کند. در حال حاضر تنها less(1) شناخته شده است که این متغیر را درک کرده و «حالت امن» را پیادهسازی میکند.
در صورت تنظیم روی false، هیچ محدودیتی بر روی صفحهبند اعمال نمیشود. تنظیم SYSTEMD_PAGERSECURE=0 یا حذف نکردن آن از محیط به ارث رسیده ممکن است به کاربر اجازه دهد دستورات دلخواه را فراخوانی کند.
هنگامی که $SYSTEMD_PAGERSECURE تنظیم نشده باشد، ابزارهای systemd تلاش میکنند به طور خودکار تشخیص دهند که آیا «حالت امن» باید فعال شود و آیا صفحهبند از آن پشتیبانی میکند یا خیر. «حالت امن» فعال میشود اگر UID موثر با مالک نشست ورود یکسان نباشد، geteuid(2) و sd_pid_get_owner_uid(3) را ببینید، یا هنگام اجرا تحت sudo(8) یا ابزارهای مشابه (که در آنها $SUDO_UID تنظیم شده است [7]). در این موارد، SYSTEMD_PAGERSECURE=1 تنظیم خواهد شد و صفحهبندهایی که شناخته نشدهاند «حالت امن» را پیادهسازی کنند اصلاً استفاده نخواهند شد. توجه داشته باشید که این تشخیص خودکار تنها رایجترین سازوکارها را برای ارتقای امتیاز پوشش میدهد و به عنوان یک تسهیل در نظر گرفته شده است. توصیه میشود که صراحتاً $SYSTEMD_PAGERSECURE را تنظیم کرده یا صفحهبند را غیرفعال کنید.
توجه داشته باشید که اگر قرار است متغیرهای $SYSTEMD_PAGER یا $PAGER به جز برای غیرفعال کردن صفحهبند رعایت شوند، $SYSTEMD_PAGERSECURE نیز باید تنظیم شده باشد.
$SYSTEMD_COLORS
true
false
"16", "256", "24bit"
"auto-16", "auto-256", "auto-24bit"
$SYSTEMD_URLIFY
مثالها (EXAMPLES)
مثال ۱. دانلود یک تصویر 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) برای باز کردن یک پوسته در آن استفاده مینماید.
مثال ۲. ساخت و بوت کردن یک توزیع فدورا مینیمال در یک کانتینر
# dnf -y --releasever=44 --installroot=/var/lib/machines/f44 \
--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/f44
(هنگام استفاده از dnf <= 4، --use-host-config را حذف کنید.) این دستور یک توزیع فدورا مینیمال را در دایرکتوری /var/lib/machines/f44 نصب میکند و سپس آن سیستمعامل را در یک کانتینر فضاینام بوت مینماید. از آنجا که نصب در زیر دایرکتوری استاندارد /var/lib/machines/ قرار دارد، شروع ماشین با استفاده از systemd-nspawn -M f44 نیز امکانپذیر است.
مثال ۳. راهاندازی یک پوسته در کانتینری از یک توزیع دبیان ناپایدار مینیمال
# debootstrap unstable ~/debian-tree/ # systemd-nspawn -D ~/debian-tree/
این دستور یک توزیع دبیان ناپایدار (unstable) مینیمال را در دایرکتوری ~/debian-tree/ نصب کرده و سپس یک پوسته از این تصویر در یک کانتینر فضاینام اجرا میکند.
debootstrap به صورت پیشفرض از Debian[8] و Ubuntu[9] پشتیبانی میکند، بنابراین میتوان از همان دستور برای نصب هر یک از آنها استفاده کرد. برای سایر توزیعهای خانواده دبیان، باید یک آینه (mirror) مشخص شود، debootstrap(8) را ببینید.
مثال ۴. بوت کردن یک توزیع آرچ لینوکس مینیمال در یک کانتینر
# pacstrap -c ~/arch-tree/ base # systemd-nspawn -bD ~/arch-tree/
این دستور یک توزیع آرچ لینوکس مینیمال را در دایرکتوری ~/arch-tree/ نصب کرده و سپس یک سیستمعامل را در یک کانتینر فضاینام در آن بوت میکند.
مثال ۵. نصب توزیع غلتان 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
مثال ۶. بوت در یک اسنپشات موقت از سیستم میزبان
# systemd-nspawn -D / -xb
این دستور کپیای از سیستم میزبان را در یک اسنپشات اجرا میکند که بلافاصله با خروج کانتینر حذف میشود. بنابراین، تمام تغییرات سیستمفایل ایجادشده در طول زمان اجرا با خاموش شدن از بین خواهند رفت.
مثال ۷. اجرای یک کانتینر با زمینههای امنیتی جعبهشنی 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
مثال ۸. اجرای یک کانتینر با یک استقرار OSTree
# systemd-nspawn -b -i ~/image.raw \
--pivot-root=/ostree/deploy/$OS/deploy/$CHECKSUM:/sysroot \
--bind=+/sysroot/ostree/deploy/$OS/var:/var
وضعیت خروج (EXIT STATUS)
کد خروج برنامه اجراشده در کانتینر بازگردانده میشود.
همچنین ببینید (SEE ALSO)
systemd(1), systemd.nspawn(5), chroot(1), dnf(8), debootstrap(8), pacman(8), zypper(8), systemd.slice(5), machinectl(1), importctl(1), systemd-mountfsd.service(8), systemd-nsresourced.service(8), systemd.mstack(7), btrfs(8)
نکات (NOTES)
- 1.
- Container Interface
- 2.
- UAPI.2 Discoverable Partitions Specification
- 3.
- OCI Runtime Specification
- 4.
- File Descriptor Store
- 5.
- Overlay Filesystem
- 6.
- ANSI Escape Code (Wikipedia)
- 7.
- توصیه میشود که ابزارهای دیگر در صورت لزوم $SUDO_UID را تنظیم و بررسی کنند، و با آن به عنوان یک رابط رایج رفتار نمایند.
- 8.
- Debian
- 9.
- Ubuntu
- 10.
- Arch Linux
- 11.
- OpenSUSE Tumbleweed
| systemd 261.3 |