'\" t
.TH "SYSTEMD\-NSPAWN" "1" "" "systemd 261.3" "systemd-nspawn"
.\" -----------------------------------------------------------------
.\" * Define some portability stuff
.\" -----------------------------------------------------------------
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.\" http://bugs.debian.org/507673
.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.ie \n(.g .ds Aq \(aq
.el       .ds Aq '
.\" -----------------------------------------------------------------
.\" * set default formatting
.\" -----------------------------------------------------------------
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.ad l
.\" -----------------------------------------------------------------
.\" * MAIN CONTENT STARTS HERE *
.\" -----------------------------------------------------------------
.SH "نام (NAME)"
systemd-nspawn \- اجرای فرمان یا سیستم‌عامل در یک کانتینر سبک فضای‌نام (Namespace)
.SH "خلاصه دستور (SYNOPSIS)"
.HP \w'\fBsystemd\-nspawn\fR\ 'u
\fBsystemd\-nspawn\fR [OPTIONS...] [\fICOMMAND\fR\ [ARGS...]]
.HP \w'\fBsystemd\-nspawn\fR\ 'u
\fBsystemd\-nspawn\fR \-\-boot [OPTIONS...] [ARGS...]
.SH "توضیحات (DESCRIPTION)"
.PP
\fBsystemd\-nspawn\fR
می‌تواند برای اجرای یک فرمان یا سیستم‌عامل در یک کانتینر سبک فضای‌نام (namespace) استفاده شود\&. از جهات بسیاری مشابه
\fBchroot\fR(1)
است، اما بسیار قدرتمندتر زیرا ساختار سلسله‌مراتبی سیستم‌فایل و همچنین درخت فرآیندها، زیرسیستم‌های مختلف IPC، و نام‌های میزبان و دامنه را مجازی‌سازی می‌کند\&.
.PP
\fBsystemd\-nspawn\fR
می‌تواند بر روی هر درخت دایرکتوری شامل یک درخت سیستم‌عامل، با استفاده از گزینه خط فرمان
\fB\-\-directory=\fR
فراخوانی شود\&. با استفاده از گزینه
\fB\-\-machine=\fR
یک درخت سیستم‌عامل به‌طور خودکار در چند مکان جستجو می‌شود، به‌ویژه در
/var/lib/machines/،
که دایرکتوری پیشنهادی برای قرار دادن تصاویر کانتینر سیستم‌عامل نصب‌شده روی سیستم است\&.
.PP
برخلاف
\fBchroot\fR(1)،
\fBsystemd\-nspawn\fR
می‌تواند برای بوت کردن سیستم‌های عامل کامل مبتنی بر لینوکس در یک کانتینر استفاده شود\&.
.PP
\fBsystemd\-nspawn\fR
دسترسی به واسط‌های مختلف هسته در کانتینر مانند
/sys/،
/proc/sys/
یا
/sys/fs/selinux/
را به حالت فقط‌خواندنی محدود می‌کند\&. واسط‌های شبکه میزبان و ساعت سیستم را نمی‌توان از درون کانتینر تغییر داد\&. گره‌های دستگاه را نمی‌توان ایجاد کرد\&. سیستم میزبان را نمی‌توان راه‌اندازی مجدد کرد و ماژول‌های هسته را نمی‌توان از درون کانتینر بارگذاری نمود\&.
\fIاگر از فضاهای‌نام کاربر (user namespaces) استفاده نشود، این جعبه‌شنی (sandbox) را می‌توان به راحتی از درون کانتینر دور زد\fR\&. این بدان معناست که کدهای غیرقابل‌اعتماد باید همیشه در یک فضای‌نام کاربر اجرا شوند؛ به توضیحات گزینه
\fB\-\-private\-users=\fR
در زیر مراجعه کنید\&.
.PP
از ابزاری مانند
\fBdnf\fR(8)،
\fBdebootstrap\fR(8)
یا
\fBpacman\fR(8)
برای راه‌اندازی درخت دایرکتوری سیستم‌عاملی مناسب به عنوان سلسله‌مراتب سیستم‌فایل برای کانتینرهای
\fBsystemd\-nspawn\fR
استفاده کنید\&. برای جزئیات در مورد فراخوانی مناسب این دستورات، بخش «مثال‌ها» در زیر را ببینید\&.
.PP
به عنوان یک بررسی ایمنی،
\fBsystemd\-nspawn\fR
پیش از بوت کردن یک کانتینر، وجود
/usr/lib/os\-release
یا
/etc/os\-release
در درخت کانتینر را بررسی خواهد کرد (به
\fBos-release\fR(5)
مراجعه کنید)\&. در صورتی که سیستم‌عامل کانتینر به قدری قدیمی باشد که این فایل را به صورت پیش‌فرض شامل نشود، ممکن است لازم باشد این فایل به صورت دستی به درخت کانتینر اضافه شود\&.
.PP
\fBsystemd\-nspawn\fR
می‌تواند مستقیماً از خط فرمان تعاملی فراخوانی شود یا به عنوان سرویس سیستمی در پس‌زمینه اجرا گردد\&. در این حالت، هر نمونه کانتینر به عنوان نمونه سرویس اختصاصی خود اجرا می‌شود؛ یک فایل واحد الگوی پیش‌فرض،
systemd\-nspawn@\&.service،
برای سهولت این امر ارائه شده است که نام کانتینر را به عنوان شناسه نمونه در نظر می‌گیرد\&. توجه داشته باشید هنگامی که
\fBsystemd\-nspawn\fR
توسط فایل واحد الگو فراخوانی می‌شود نسبت به فراخوانی تعاملی در خط فرمان، گزینه‌های پیش‌فرض متفاوتی اعمال می‌گردد\&. مهم‌تر از همه اینکه فایل واحد الگو از گزینه
\fB\-\-boot\fR
استفاده می‌کند که در حالت فراخوانی تعاملی
\fBsystemd\-nspawn\fR
از خط فرمان، پیش‌فرض نیست\&. تفاوت‌های بیشتر با پیش‌فرض‌ها در کنار گزینه‌های مختلف پشتیبانی‌شده در زیر مستند شده‌اند\&.
.PP
ابزار
\fBmachinectl\fR(1)
می‌تواند برای اجرای تعدادی از عملیات روی کانتینرها استفاده شود\&. به‌ویژه، دستوراتی با کاربرد آسان برای اجرای کانتینرها به عنوان سرویس‌های سیستمی با استفاده از فایل واحد الگوی
systemd\-nspawn@\&.service
فراهم می‌کند\&.
.PP
در کنار هر کانتینر ممکن است یک فایل تنظیمات با پسوند
\&.nspawn
وجود داشته باشد که شامل تنظیمات اضافی برای اعمال در هنگام اجرای کانتینر است\&. برای جزئیات به
\fBsystemd.nspawn\fR(5)
مراجعه کنید\&. فایل‌های تنظیمات، گزینه‌های پیش‌فرض استفاده‌شده توسط فایل واحد الگوی
systemd\-nspawn@\&.service
را بازنویسی می‌کنند، که معمولاً تغییر مستقیم این فایل الگو را غیرضروری می‌سازد\&.
.PP
توجه داشته باشید که
\fBsystemd\-nspawn\fR
سیستم‌های فایل خصوصی کانتینر را در
/dev/،
/run/
و موارد مشابه مانت خواهد کرد\&. این‌ها در خارج از کانتینر قابل مشاهده نخواهند بود، و محتویات آن‌ها با خروج کانتینر از بین می‌رود\&.
.PP
توجه داشته باشید که اجرای دو کانتینر
\fBsystemd\-nspawn\fR
از یک درخت دایرکتوری یکسان باعث نمی‌شود فرآیندهای درون آن‌ها یکدیگر را ببینند\&. جداسازی فضای‌نام PID این دو کانتینر کامل است و کانتینرها به جز سیستم‌فایل زیرین، اشیاء زمان اجرای بسیار کمی را به اشتراک می‌گذارند\&. در عوض از دستورات
\fBlogin\fR
یا
\fBshell\fR
در
\fBmachinectl\fR(1)
برای درخواست یک نشست ورود اضافی در یک کانتینر در حال اجرا استفاده کنید\&.
.PP
\fBsystemd\-nspawn\fR
مشخصات
\m[blue]\fBContainer Interface\fR\m[]\&\s-2\u[1]\d\s+2
را پیاده‌سازی می‌کند\&.
.PP
کانتینرهای فراخوانی‌شده با
\fBsystemd\-nspawn\fR
در زمان اجرا در سرویس
\fBsystemd-machined\fR(8)
ثبت می‌شوند که کانتینرهای در حال اجرا را پیگیری کرده و واسط‌های برنامه‌نویسی را برای تعامل با آن‌ها فراهم می‌سازد\&.
.SH "عملیات بدون امتیاز ویژه (UNPRIVILEGED OPERATION)"
.PP
\fBsystemd\-nspawn\fR
می‌تواند با یا بدون امتیازات ویژه فراخوانی شود\&. عملکرد کامل در حال حاضر تنها زمانی در دسترس است که با امتیازات ویژه فراخوانی شود\&. هنگام فراخوانی بدون امتیاز، محدودیت‌های مختلفی اعمال می‌شود، از جمله اما نه محدود به موارد زیر:
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
تنها کانتینرهای مبتنی بر تصویر دیسک پشتیبانی می‌شوند (یعنی
\fB\-\-image=\fR)\&. موارد مبتنی بر دایرکتوری (یعنی
\fB\-\-directory=\fR)
تنها در صورتی پشتیبانی می‌شوند که متعلق به محدوده UID «خارجی» (foreign) باشند\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
تنها حالت‌های شبکه‌سازی
\fB\-\-private\-network\fR
و
\fB\-\-network\-veth\fR
پشتیبانی می‌شوند\&.
.RE
.PP
هنگام اجرا در حالت بدون امتیاز، برخی از عملکردهای مورد نیاز از طریق
\fBsystemd-mountfsd.service\fR(8)
و
\fBsystemd-nsresourced.service\fR(8)
ارائه می‌شوند\&.
.SH "گزینه‌ها (OPTIONS)"
.PP
اگر گزینه
\fB\-\-boot\fR
مشخص شود، آرگومان‌ها به عنوان آرگومان‌های برنامه آغازین (init) استفاده می‌شوند\&. در غیر این صورت،
\fICOMMAND\fR
برنامه‌ای را برای اجرا در کانتینر مشخص می‌کند و آرگومان‌های باقی‌مانده به عنوان آرگومان‌های این برنامه استفاده می‌شوند\&. اگر
\fB\-\-boot\fR
استفاده نشود و هیچ آرگومانی مشخص نگردد، یک پوسته (shell) در کانتینر اجرا می‌شود\&.
.PP
گزینه‌های زیر پشتیبانی می‌شوند:
.PP
\fB\-q\fR, \fB\-\-quiet\fR
.RS 4
هرگونه خروجی وضعیت توسط خود ابزار را خاموش می‌کند\&. هنگام استفاده از این سوئیچ، تنها خروجی nspawn خروجی کنسول خود سیستم‌عامل کانتینر خواهد بود\&.
.sp
افزوده‌شده در نسخه 209\&.
.RE
.PP
\fB\-\-settings=\fR\fB\fIMODE\fR\fR
.RS 4
کنترل می‌کند که آیا
\fBsystemd\-nspawn\fR
تنظیمات اضافی مختص هر کانتینر را از فایل‌های
\&.nspawn
جستجو و استفاده کند یا خیر\&. یک مقدار بولی یا مقادیر ویژه
\fBoverride\fR
یا
\fBtrusted\fR
را می‌پذیرد\&.
.sp
در صورت فعال بودن (پیش‌فرض)، یک فایل تنظیمات همنام با ماشین (همان‌طور که با تنظیم
\fB\-\-machine=\fR
مشخص شده، یا از نام دایرکتوری یا فایل تصویر مشتق شده است) با پسوند
\&.nspawn
در
/etc/systemd/nspawn/
و
/run/systemd/nspawn/
جستجو می‌شود\&. اگر در آنجا یافت شود، تنظیمات آن خوانده شده و استفاده می‌شود\&. اگر در آنجا یافت نشود، متعاقباً در همان دایرکتوری فایل تصویر یا در والد بی‌واسطه دایرکتوری ریشه کانتینر جستجو می‌گردد\&. در این حالت، اگر فایل یافت شود، تنظیمات آن نیز خوانده شده و استفاده می‌شود، اما تنظیمات بالقوه ناامن نادیده گرفته خواهند شد\&. توجه داشته باشید که در هر دوی این حالت‌ها، در صورت تعیین هر دو، تنظیمات موجود در خط فرمان بر تنظیمات متناظر از فایل‌های
\&.nspawn
بارگذاری‌شده اولویت دارند\&. تمام تنظیماتی که امتیازات کانتینر را افزایش می‌دهند یا دسترسی به منابع اضافی مانند فایل‌ها یا دایرکتوری‌های میزبان را اعطا می‌کنند، تنظیمات ناامن تلقی می‌شوند\&. برای جزئیات در مورد قالب و محتوای فایل‌های
\&.nspawn،
به
\fBsystemd.nspawn\fR(5)
مراجعه کنید\&.
.sp
اگر این گزینه روی
\fBoverride\fR
تنظیم شود، فایل به همان روش جستجو، خوانده و استفاده می‌شود، با این حال، ترتیب اولویت معکوس می‌گردد: در صورت تعیین هر دو، تنظیمات خوانده‌شده از فایل
\&.nspawn
بر گزینه‌های متناظر خط فرمان اولویت خواهند داشت\&.
.sp
اگر این گزینه روی
\fBtrusted\fR
تنظیم شود، فایل به همان روش جستجو، خوانده و استفاده می‌شود، اما صرف‌نظر از اینکه در
/etc/systemd/nspawn/،
/run/systemd/nspawn/
یا در کنار فایل تصویر یا دایرکتوری ریشه کانتینر یافت شود، تمام تنظیمات اعمال خواهند شد؛ با این وجود آرگومان‌های خط فرمان همچنان بر تنظیمات متناظر اولویت دارند\&.
.sp
در صورت غیرفعال بودن، هیچ فایل
\&.nspawn
خوانده نمی‌شود و هیچ تنظیمی به جز موارد موجود در خط فرمان اعمال نمی‌گردد\&.
.sp
افزوده‌شده در نسخه 226\&.
.RE
.PP
\fB\-\-cleanup\fR
.RS 4
مانت‌های باقی‌مانده و نقاط مانت زیرین استفاده‌شده توسط کانتینر را پاکسازی کرده و بدون فراخوانی هیچ کانتینری خارج می‌شود\&. این ممکن است زمانی مفید باشد که فراخوانی قبلی
\fBsystemd\-nspawn\fR
به طور غیرمنتظره‌ای پایان یافته باشد\&. این امر نیازمند حداقل یکی از گزینه‌های
\fB\-M/\-\-machine=\fR،
\fB\-D/\-\-directory=\fR
یا
\fB\-i/\-\-image=\fR
برای تعیین مانت‌های نیازمند پاکسازی است\&.
.sp
افزوده‌شده در نسخه 257\&.
.RE
.SS "گزینه‌های تصویر (Image Options)"
.PP
\fB\-D\fR, \fB\-\-directory=\fR
.RS 4
دایرکتوری مورد استفاده به عنوان ریشه سیستم‌فایل برای کانتینر\&.
.sp
اگر نه
\fB\-\-directory=\fR
و نه
\fB\-\-image=\fR
مشخص نشوند، دایرکتوری با جستجو برای دایرکتوری همنام با نام ماشین مشخص‌شده با
\fB\-\-machine=\fR
تعیین می‌شود\&. برای مسیر دقیق جستجو، بخش «فایل‌ها و دایرکتوری‌ها» در
\fBmachinectl\fR(1)
را ببینید\&.
.sp
به جای مسیر دایرکتوری می‌توان یک دایرکتوری نسخه‌بندی‌شده
"\&.v/"
را مشخص کرد، برای جزئیات
\fBsystemd.v\fR(7)
را ببینید\&.
.sp
اگر هیچ‌کدام از گزینه‌های
\fB\-\-directory=\fR،
\fB\-\-image=\fR
یا
\fB\-\-machine=\fR
مشخص نشوند، دایرکتوری جاری استفاده خواهد شد\&. نمی‌تواند همراه با
\fB\-\-image=\fR
مشخص شود\&.
.RE
.PP
\fB\-\-template=\fR
.RS 4
دایرکتوری یا زیرحجم
"btrfs"
برای استفاده به عنوان الگو برای دایرکتوری ریشه کانتینر\&. اگر این گزینه مشخص شود و دایرکتوری ریشه کانتینر (همان‌طور که توسط
\fB\-\-directory=\fR
پیکربندی شده است) هنوز وجود نداشته باشد، به عنوان یک اسنپ‌شات
"btrfs"
(در صورت پشتیبانی) یا دایرکتوری معمولی (در غیر این صورت) ایجاد شده و از این درخت الگو پر می‌شود\&. در حالت ایده‌آل، مسیر الگوی مشخص‌شده به ریشه یک زیرحجم
"btrfs"
اشاره دارد که در این صورت یک اسنپ‌شات کپی‌هنگام‌نوشتن (copy\-on\-write) ساده گرفته می‌شود و پر کردن دایرکتوری ریشه به صورت آنی خواهد بود\&. اگر مسیر الگوی مشخص‌شده به ریشه یک زیرحجم
"btrfs"
اشاره نداشته باشد (یا حتی اصلاً به سیستم‌فایل
"btrfs"
مربوط نباشد)، درخت کپی می‌شود (هرچند احتمالاً در یک طرح کپی‌هنگام‌نوشتن \(aqreflink\(aq \(em در صورتی که سیستم‌فایل از آن پشتیبانی کند)، که می‌تواند زمان‌برتر باشد\&. توجه داشته باشید که اسنپ‌شات گرفته‌شده از دایرکتوری یا زیرحجم مشخص‌شده، شامل تمام زیردایرکتوری‌ها و زیرحجم‌های زیر آن است، اما هرگونه زیرمانت را شامل نمی‌شود\&. نمی‌تواند همراه با
\fB\-\-image=\fR
یا
\fB\-\-ephemeral\fR
مشخص شود\&.
.sp
توجه داشته باشید که این سوئیچ، نام میزبان، شناسه ماشین و تمام تنظیمات دیگری را که می‌توانند نمونه را شناسایی کنند دست‌نخورده باقی می‌گذارد\&.
.sp
افزوده‌شده در نسخه 219\&.
.RE
.PP
\fB\-x\fR, \fB\-\-ephemeral\fR
.RS 4
در صورت تعیین شدن، کانتینر با یک اسنپ‌شات موقت از سیستم‌فایل خود اجرا می‌شود که بلافاصله با پایان یافتن کانتینر حذف می‌گردد\&. نمی‌تواند همراه با
\fB\-\-template=\fR
مشخص شود\&.
.sp
توجه داشته باشید که این سوئیچ، نام میزبان، شناسه ماشین و تمام تنظیمات دیگری را که می‌توانند نمونه را شناسایی کنند دست‌نخورده باقی می‌گذارد\&. لطفاً توجه داشته باشید که \(em مانند
\fB\-\-template=\fR
\(em گرفتن اسنپ‌شات موقت در سیستم‌های فایلی که به طور بومی از اسنپ‌شات‌های زیرحجم یا \(aqreflink\(aqها پشتیبانی می‌کنند (مانند
"btrfs"
یا
"xfs"
جدید) نسبت به سیستم‌های فایل سنتی‌تر که پشتیبانی نمی‌کنند (مانند
"ext4")
کارآمدتر است\&. توجه داشته باشید که اسنپ‌شات گرفته‌شده از دایرکتوری یا زیرحجم مشخص‌شده، شامل تمام زیردایرکتوری‌ها و زیرحجم‌های زیر آن است، اما هرگونه زیرمانت را شامل نمی‌شود\&.
.sp
با این گزینه هیچ تغییری در تصویر کانتینر حفظ نمی‌شود\&. از
\fB\-\-volatile=\fR
(توضیح داده شده در زیر) برای سایر سازوکارها به منظور محدود کردن ماندگاری تصاویر کانتینر در زمان اجرا استفاده کنید\&.
.sp
افزوده‌شده در نسخه 219\&.
.RE
.PP
\fB\-i\fR, \fB\-\-image=\fR
.RS 4
تصویر دیسک برای مانت کردن دایرکتوری ریشه کانتینر از آن\&. مسیری به یک فایل معمولی یا یک گره دستگاه بلوکی را می‌پذیرد\&. فایل یا دستگاه بلوکی باید حاوی یکی از موارد زیر باشد:
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
یک جدول پارتیشن MBR با یک پارتیشن منفرد از نوع 0x83 که به عنوان قابل‌بوت علامت‌گذاری شده است\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
یک جدول پارتیشن گاید (GPT) با یک پارتیشن منفرد از نوع 0fc63daf\-8483\-4772\-8e79\-3d69d8477de4\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
یک جدول پارتیشن گاید (GPT) با یک پارتیشن ریشه مشخص‌شده که به عنوان دایرکتوری ریشه کانتینر مانت می‌شود\&. به صورت اختیاری، تصاویر GPT ممکن است حاوی یک پارتیشن داده‌های خانگی (home) و/یا سرور باشند که در مکان‌های مناسب در کانتینر مانت می‌شوند\&. همه این پارتیشن‌ها باید توسط انواع پارتیشن تعریف‌شده در
\m[blue]\fBUAPI\&.2 Discoverable Partitions Specification\fR\m[]\&\s-2\u[2]\d\s+2
شناسایی شوند\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
بدون جدول پارتیشن، و یک سیستم فایل منفرد که کل تصویر را در بر می‌گیرد\&.
.RE
.sp
در تصاویر GPT، اگر یک پارتیشن سیستم EFI (ESP) کشف شود، در صورتی که دایرکتوری با این نام وجود داشته و خالی باشد، به‌طور خودکار در
/efi
(یا
/boot
به عنوان جایگزین) مانت می‌شود\&.
.sp
پارتیشن‌های رمزنگاری‌شده با LUKS به‌طور خودکار رمزگشایی می‌شوند\&. همچنین، در تصاویر GPT در صورتی که هش ریشه برای آن‌ها با استفاده از گزینه
\fB\-\-root\-hash=\fR
مشخص شده باشد، پارتیشن‌های هش یکپارچگی داده dm\-verity راه‌اندازی می‌شوند\&.
.sp
تصاویر تک سیستم‌فایل (یعنی سیستم‌های فایل بدون جدول پارتیشن پیرامونی) را می‌توان با استفاده از dm\-verity باز کرد، در صورتی که داده‌های یکپارچگی با استفاده از گزینه‌های
\fB\-\-root\-hash=\fR
و
\fB\-\-verity\-data=\fR
(و به صورت اختیاری
\fB\-\-root\-hash\-sig=\fR)
ارسال شوند\&.
.sp
هرگونه پارتیشن دیگر مانند پارتیشن‌های خارجی یا پارتیشن‌های swap مانت نمی‌شوند\&. نمی‌تواند همراه با
\fB\-\-directory=\fR
یا
\fB\-\-template=\fR
مشخص شود\&.
.sp
به جای مسیر تصویر می‌توان یک دایرکتوری نسخه‌بندی‌شده
"\&.v/"
را مشخص کرد، برای جزئیات
\fBsystemd.v\fR(7)
را ببینید\&.
.sp
افزوده‌شده در نسخه 211\&.
.RE
.PP
\fB\-\-image\-policy=\fR\fB\fIpolicy\fR\fR
.RS 4
یک رشته خط‌مشی تصویر را به عنوان آرگومان، مطابق با
\fBsystemd.image-policy\fR(7)
می‌پذیرد\&. این خط‌مشی هنگام کار بر روی تصویر دیسک مشخص‌شده از طریق
\fB\-\-image=\fR
(به بالا مراجعه کنید) اعمال می‌شود\&. در صورت عدم تعیین، پیش‌فرض روی
"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"
است، یعنی تمام سیستم‌های فایل شناخته‌شده در تصویر استفاده می‌شوند، اما پارتیشن swap استفاده نمی‌شود\&.
.sp
افزوده‌شده در نسخه 254\&.
.RE
.PP
\fB\-\-mstack=\fR
.RS 4
پشته مانت برای مانت کردن دایرکتوری ریشه کانتینر از آن\&. مسیری به یک دایرکتوری پیاده‌سازی‌کننده
\fBsystemd.mstack\fR(7)
را می‌پذیرد\&. این گزینه می‌تواند برای اجرای یک کانتینر از یک
"overlayfs"
سرهم‌شده از تعدادی لایه استفاده شود که احتمالاً قابل نوشتن بوده و با مانت‌های bind اضافی تقویت شده است\&.
.sp
افزوده‌شده در نسخه 260\&.
.RE
.PP
\fB\-\-oci\-bundle=\fR
.RS 4
مسیری به یک بسته زمان اجرای OCI برای فراخوانی، همان‌طور که در
\m[blue]\fBOCI Runtime Specification\fR\m[]\&\s-2\u[3]\d\s+2
مشخص شده است، می‌پذیرد\&. در این حالت، هیچ فایل
\&.nspawn
بارگذاری نمی‌شود و دایرکتوری ریشه و تنظیمات مختلف از داده‌های JSON زمان اجرای OCI خوانده می‌شوند (اما داده‌های ارائه‌شده در خط فرمان اولویت دارند)\&.
.sp
افزوده‌شده در نسخه 242\&.
.RE
.PP
\fB\-\-read\-only\fR
.RS 4
سیستم‌فایل ریشه کانتینر (و هر سیستم‌فایل دیگر موجود در تصویر کانتینر) را به صورت فقط‌خواندنی مانت می‌کند\&. این گزینه هیچ تاثیری بر مانت‌های اضافی انجام‌شده با
\fB\-\-bind=\fR،
\fB\-\-tmpfs=\fR
و گزینه‌های مشابه ندارد\&. اگر خود فایل تصویر کانتینر یا دایرکتوری آن به صورت فقط‌خواندنی علامت‌گذاری شده باشد، این حالت به صورت ضمنی اعمال می‌شود\&. همچنین در صورت استفاده از
\fB\-\-volatile=\fR
نیز به صورت ضمنی اعمال می‌گردد\&. در این حالت، تصویر کانتینر روی دیسک کاملاً فقط‌خواندنی است، در حالی که تغییرات مجاز بوده اما تنها به صورت غیرماندگار در حافظه نگهداری می‌شوند\&. برای جزئیات بیشتر به زیر مراجعه کنید\&.
.RE
.PP
\fB\-\-volatile\fR, \fB\-\-volatile=\fR\fB\fIMODE\fR\fR
.RS 4
کانتینر را در حالت فرار (volatile) بوت می‌کند\&. هنگامی که هیچ پارامتر حالتی ارسال نشود یا هنگامی که حالت به عنوان
\fByes\fR
مشخص شود، حالت فرار کامل فعال می‌گردد\&. این بدان معناست که دایرکتوری ریشه به عنوان یک نمونه
"tmpfs"
عمدتاً خالی مانت می‌شود، و
/usr/
از درخت سیستم‌عامل به صورت فقط‌خواندنی درون آن مانت می‌گردد (بنابراین سیستم با یک تصویر سیستم‌عامل فقط‌خواندنی، اما وضعیت و پیکربندی دست‌نخورده راه‌اندازی می‌شود؛ هرگونه تغییر با خاموش شدن از بین می‌رود)\&. هنگامی که پارامتر حالت به عنوان
\fBstate\fR
مشخص شود، درخت سیستم‌عامل به صورت فقط‌خواندنی مانت می‌شود، اما
/var/
به عنوان یک نمونه
"tmpfs"
قابل‌نوشتن درون آن مانت می‌گردد (بنابراین سیستم با منابع و پیکربندی سیستم‌عامل فقط‌خواندنی، اما وضعیت دست‌نخورده راه‌اندازی می‌شود، و هرگونه تغییر در دومی با خاموش شدن از بین می‌رود)\&. هنگامی که پارامتر حالت به عنوان
\fBoverlay\fR
مشخص شود، سیستم‌فایل ریشه فقط‌خواندنی از طریق
"overlayfs"
با یک نمونه tmpfs قابل نوشتن ترکیب می‌شود، به طوری که همانند حالت عادی به نظر می‌رسد، اما هرگونه تغییر تنها بر روی سیستم‌فایل موقت اعمال شده و با پایان یافتن کانتینر از بین می‌رود\&. هنگامی که پارامتر حالت به عنوان
\fBno\fR
(پیش‌فرض) مشخص شود، کل درخت سیستم‌عامل به صورت قابل نوشتن در دسترس قرار می‌گیرد (مگر اینکه
\fB\-\-read\-only\fR
مشخص شده باشد، به بالا مراجعه کنید)\&.
.sp
توجه داشته باشید که اگر یکی از حالت‌های فرار انتخاب شود، اثر آن محدود به سیستم‌فایل ریشه (یا
/var/
در مورد
\fBstate\fR)
است و هر مانت دیگری که در سلسله‌مراتب قرار گیرد تحت تأثیر قرار نمی‌گیرد \(em صرف‌نظر از اینکه به طور خودکار ایجاد شده باشد (مانند پارتیشن سیستم EFI که ممکن است در
/efi/
یا
/boot/
مانت شود) یا به صراحت (مثلاً از طریق یک گزینه خط فرمان اضافی مانند
\fB\-\-bind=\fR،
به زیر مراجعه کنید)\&. این بدان معناست که حتی اگر
\fB\-\-volatile=overlay\fR
استفاده شود، در صورت وجود چنین پارتیشنی در تصویر کانتینر مورد استفاده، تغییرات در
/efi/
یا
/boot/
ممنوع است، و حتی اگر
\fB\-\-volatile=state\fR
استفاده شود، در صورتی که
\fB\-\-bind=/etc/foobar\fR
برای مانت کردن آن از خارج از دایرکتوری فقط‌خواندنی
/etc/
کانتینر استفاده شود، فایل فرضی
/etc/foobar
احتمالاً قابل نوشتن خواهد بود\&.
.sp
گزینه
\fB\-\-ephemeral\fR
ارتباط نزدیکی با این تنظیم دارد و رفتاری مشابه را با ایجاد یک کپی موقت و زودگذر از کل تصویر سیستم‌عامل و اجرای آن فراهم می‌سازد\&. برای جزئیات بیشتر به بالا مراجعه کنید\&.
.sp
گزینه‌های
\fB\-\-tmpfs=\fR
و
\fB\-\-overlay=\fR
عملکرد مشابهی را ارائه می‌دهند، اما تنها برای زیردایرکتوری‌های خاصی از تصویر سیستم‌عامل\&. برای جزئیات به زیر مراجعه کنید\&.
.sp
این گزینه عملکرد مشابهی را برای کانتینرها ارائه می‌دهد که سوئیچ خط فرمان هسته
"systemd\&.volatile="
برای سیستم‌های میزبان فراهم می‌کند\&. برای جزئیات به
\fBkernel-command-line\fR(7)
مراجعه کنید\&.
.sp
توجه داشته باشید که تنظیم این گزینه روی
\fByes\fR
یا
\fBstate\fR
تنها با سیستم‌های عاملی در کانتینر به درستی کار خواهد کرد که بتوانند تنها با مانت بودن
/usr/
بوت شوند، و قادر باشند به طور خودکار
/var/
(و در مورد
"\-\-volatile=yes"،
/etc/)
را پر کنند\&. به طور خاص، این بدان معناست که سیستم‌های عاملی که از تفکیک تاریخی
/bin/
و
/lib/
(و دایرکتوری‌های مرتبط) از
/usr/
پیروی می‌کنند (یعنی جایی که موارد قبلی پیوند نمادین به مورد اخیر نیستند) توسط
"\-\-volatile=yes"
به عنوان بار مفید کانتینر پشتیبانی نمی‌شوند\&. گزینه
\fBoverlay\fR
به هیچ آماده‌سازی خاصی در سیستم‌عامل نیاز ندارد، اما توجه داشته باشید که رفتار
"overlayfs"
از چندین جهت با سیستم‌های فایل معمولی تفاوت دارد، و از این رو سازگاری آن محدود است\&.
.sp
افزوده‌شده در نسخه 216\&.
.RE
.PP
\fB\-\-root\-hash=\fR
.RS 4
یک هش ریشه یکپارچگی داده (dm\-verity) را به صورت هگزادسیمال می‌پذیرد\&. این گزینه در صورتی که تصویر مورد استفاده حاوی داده‌های یکپارچگی مناسب باشد (به بالا مراجعه کنید)، بررسی‌های یکپارچگی داده را با استفاده از dm\-verity فعال می‌کند\&. هش مشخص‌شده باید با هش ریشه داده‌های یکپارچگی مطابقت داشته باشد، و معمولاً حداقل ۲۵۶ بیت (و بنابراین ۶۴ کاراکتر هگزادسیمال قالب‌بندی‌شده) طول دارد (مثلاً در مورد SHA256)\&. اگر این گزینه مشخص نشده باشد، اما فایل تصویر دارای ویژگی فایل گسترش‌یافته
"user\&.verity\&.roothash"
باشد (به
\fBxattr\fR(7)
مراجعه کنید)، هش ریشه از آن خوانده می‌شود، همچنین به عنوان کاراکترهای هگزادسیمال قالب‌بندی‌شده\&. اگر ویژگی فایل گسترش‌یافته یافت نشود (یا توسط سیستم‌فایل زیرین پشتیبانی نشود)، اما فایلی با پسوند
\&.roothash
در کنار فایل تصویر یافت شود که در غیر این صورت نام یکسانی دارد (مگر اینکه تصویر پسوند
\&.raw
داشته باشد، که در این صورت فایل هش ریشه نباید آن را در نام خود داشته باشد)، هش ریشه از آن خوانده شده و به طور خودکار استفاده می‌شود، همچنین به عنوان کاراکترهای هگزادسیمال قالب‌بندی‌شده\&.
.sp
توجه داشته باشید که این گزینه هش ریشه را برای سیستم‌فایل ریشه پیکربندی می‌کند\&. تصاویر دیسک ممکن است حاوی سیستم‌های فایل جداگانه‌ای برای سلسله‌مراتب
/usr/
باشند که ممکن است آن‌ها نیز توسط Verity محافظت شوند\&. هش ریشه برای این حفاظت ممکن است از طریق ویژگی فایل گسترش‌یافته
"user\&.verity\&.usrhash"
یا از طریق یک فایل
\&.usrhash
در مجاورت تصویر دیسک، با پیروی از همان قالب و منطق توصیف‌شده در اینجا برای هش ریشه سیستم‌فایل ریشه، پیکربندی شود\&. توجه داشته باشید که در حال حاضر هیچ سوئیچی برای پیکربندی هش ریشه برای
/usr/
از خط فرمان وجود ندارد\&.
.sp
همچنین گزینه
\fIRootHash=\fR
در
\fBsystemd.exec\fR(5)
را ببینید\&.
.sp
افزوده‌شده در نسخه 233\&.
.RE
.PP
\fB\-\-root\-hash\-sig=\fR
.RS 4
امضای PKCS7 گزینه
\fB\-\-root\-hash=\fR
را می‌پذیرد\&. معانی آن همانند گزینه
\fIRootHashSignature=\fR
است، به
\fBsystemd.exec\fR(5)
مراجعه کنید\&.
.sp
افزوده‌شده در نسخه 246\&.
.RE
.PP
\fB\-\-verity\-data=\fR
.RS 4
مسیری به یک فایل یکپارچگی داده (dm\-verity) را می‌پذیرد\&. این گزینه در صورتی که یک هش ریشه ارسال شده باشد و خود تصویر مورد استفاده حاوی داده‌های یکپارچگی نباشد، بررسی‌های یکپارچگی داده را با استفاده از dm\-verity فعال می‌سازد\&. داده‌های یکپارچگی باید با هش ریشه مطابقت داشته باشند\&. اگر این گزینه مشخص نشده باشد، اما فایلی با پسوند
\&.verity
در کنار فایل تصویر یافت شود که در غیر این صورت نام یکسانی دارد (مگر اینکه تصویر پسوند
\&.raw
داشته باشد، که در این صورت فایل داده verity نباید آن را در نام خود داشته باشد)، داده‌های verity از آن خوانده شده و به طور خودکار استفاده می‌شوند\&.
.sp
افزوده‌شده در نسخه 246\&.
.RE
.PP
\fB\-\-pivot\-root=\fR
.RS 4
دایرکتوری مشخص‌شده را به
/
درون کانتینر تغییر محور (pivot) می‌دهد، و ریشه قدیمی کانتینر را آن‌مانت می‌کند، یا آن را به دایرکتوری مشخص‌شده دیگری تغییر محور می‌دهد\&. یکی از موارد زیر را می‌پذیرد: یک آرگومان مسیر \(em که در این صورت مسیر مشخص‌شده به
/
تغییر محور داده می‌شود و ریشه قدیمی آن‌مانت خواهد شد؛ یا یک جفت مسیر ریشه جدید و مقصد تغییر محور برای ریشه قدیمی که با دونقطه جدا شده‌اند\&. مسیر ریشه جدید به
/
تغییر محور داده می‌شود، و
/
قدیمی به دایرکتوری دیگر تغییر محور خواهد یافت\&. هر دو مسیر باید مطلق باشند، و در فضای‌نام سیستم‌فایل کانتینر حل می‌شوند\&.
.sp
این گزینه برای کانتینرهایی است که دارای چندین دایرکتوری قابل بوت در خود هستند؛ برای مثال چندین استقرار
\fBostree\fR(1)\&.
این رفتار بوت‌لودر و initrd را شبیه‌سازی می‌کند که معمولاً انتخاب می‌کنند کدام دایرکتوری به عنوان ریشه مانت شود و PID 1 کانتینر در آن شروع به کار کند\&.
.sp
افزوده‌شده در نسخه 233\&.
.RE
.SS "گزینه‌های اجرا (Execution Options)"
.PP
\fB\-a\fR, \fB\-\-as\-pid2\fR
.RS 4
پوسته یا برنامه مشخص‌شده را به عنوان شناسه فرآیند (PID) ۲ به جای PID 1 (init) فراخوانی می‌کند\&. به طور پیش‌فرض، اگر نه این گزینه و نه
\fB\-\-boot\fR
استفاده نشوند، برنامه انتخاب‌شده به عنوان فرآیندی با PID 1 اجرا می‌شود، حالتی که تنها برای برنامه‌هایی مناسب است که از معانی خاصی که فرآیند با PID 1 در یونیکس دارد آگاه هستند\&. برای مثال، باید تمام فرآیندهایی را که مجدداً به عنوان والد آن تعیین شده‌اند پاکسازی کند (reap)، و باید مدیریت سیگنال سازگار با
\fBsysvinit\fR
را پیاده‌سازی نماید (به طور خاص: در SIGINT راه‌اندازی مجدد شود، در SIGTERM مجدداً اجرا شود، در SIGHUP پیکربندی را دوباره بارگذاری کند و غیره)\&. با
\fB\-\-as\-pid2\fR
یک فرآیند آغازین ساختگی (stub init) به عنوان PID 1 اجرا می‌شود و برنامه انتخاب‌شده به عنوان PID 2 اجرا می‌گردد (و بنابراین نیازی به پیاده‌سازی هیچ معانی خاصی ندارد)\&. فرآیند آغازین ساختگی در صورت لزوم فرآیندها را پاکسازی کرده و به سیگنال‌ها واکنش مناسب نشان می‌دهد\&. توصیه می‌شود از این حالت برای فراخوانی دستورات دلخواه در کانتینرها استفاده شود، مگر اینکه برای اجرای صحیح به عنوان PID 1 اصلاح شده باشند\&. یا به عبارت دیگر: این سوئیچ باید تقریباً برای همه دستورات استفاده شود، به جز زمانی که دستور به یک پیاده‌سازی init یا پوسته اشاره دارد، زیرا این‌ها عموماً قادر به اجرای صحیح به عنوان PID 1 هستند\&. این گزینه ممکن است با
\fB\-\-boot\fR
ترکیب نشود\&.
.sp
افزوده‌شده در نسخه 229\&.
.RE
.PP
\fB\-b\fR, \fB\-\-boot\fR
.RS 4
به طور خودکار یک برنامه آغازین (init) را جستجو کرده و آن را به عنوان PID 1 به جای یک پوسته یا یک برنامه ارائه‌شده توسط کاربر فراخوانی می‌کند\&. اگر این گزینه استفاده شود، آرگومان‌های مشخص‌شده در خط فرمان به عنوان آرگومان‌های برنامه init استفاده می‌شوند\&. این گزینه ممکن است با
\fB\-\-as\-pid2\fR
ترکیب نشود\&.
.sp
جدول زیر حالت‌های مختلف فراخوانی و ارتباط با
\fB\-\-as\-pid2\fR
(به بالا مراجعه کنید) را توضیح می‌دهد:
.sp
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
.B Table\ \&1.\ \&Invocation Mode
.TS
allbox tab(:);
lB lB.
T{
سوئیچ
T}:T{
توضیحات
T}
.T&
l l
l l
l l.
T{
نه \fB\-\-as\-pid2\fR و نه \fB\-\-boot\fR مشخص نشده است
T}:T{
پارامترهای ارائه‌شده به عنوان خط فرمان تفسیر می‌شوند که به عنوان PID 1 در کانتینر اجرا می‌گردد\&.
T}
T{
\fB\-\-as\-pid2\fR مشخص شده است
T}:T{
پارامترهای ارائه‌شده به عنوان خط فرمان تفسیر می‌شوند که به عنوان PID 2 در کانتینر اجرا می‌گردد\&. یک فرآیند آغازین ساختگی به عنوان PID 1 اجرا می‌شود\&.
T}
T{
\fB\-\-boot\fR مشخص شده است
T}:T{
یک برنامه آغازین به طور خودکار جستجو شده و به عنوان PID 1 در کانتینر اجرا می‌شود\&. پارامترهای ارائه‌شده به عنوان پارامترهای فراخوانی برای این فرآیند استفاده می‌شوند\&.
T}
.TE
.sp 1
توجه داشته باشید که اگر از فایل واحد الگوی
systemd\-nspawn@\&.service
استفاده شود،
\fB\-\-boot\fR
حالت عملکرد پیش‌فرض است\&.
.sp
هنگامی که
\fB\-\-boot\fR
استفاده می‌شود، پارامترهای ارائه‌شده به همان روشی که هسته خط فرمان خود را قبل از تحویل به PID 1 پردازش می‌کند، پردازش می‌شوند: هر انتساب
"KEY=VALUE"
که
"KEY"
آن حاوی
"\&."
نباشد، به عنوان یک متغیر محیطی برای PID 1 صادر می‌شود (با جایگزینی
"\-"
در کلید با
"_"
همانند حالتی که از طریق
\fB\-\-setenv=\fR
مشخص شده باشد)، در حالی که تمام پارامترهای دیگر (از جمله انتساب‌های
"systemd\&.*=")
به عنوان آرگومان به برنامه آغازین منتقل می‌شوند\&.
.RE
.PP
\fB\-\-chdir=\fR
.RS 4
قبل از فراخوانی فرآیند در کانتینر، به دایرکتوری کاری مشخص‌شده تغییر مکان می‌دهد\&. یک مسیر مطلق را در فضای‌نام سیستم‌فایل کانتینر انتظار دارد\&.
.sp
افزوده‌شده در نسخه 229\&.
.RE
.PP
\fB\-E \fR\fB\fINAME\fR\fR\fB[=\fR\fB\fIVALUE\fR\fR\fB]\fR, \fB\-\-setenv=\fR\fB\fINAME\fR\fR\fB[=\fR\fB\fIVALUE\fR\fR\fB]\fR
.RS 4
یک متغیر محیطی را برای ارسال به فرآیند آغازین در کانتینر مشخص می‌کند\&. این گزینه می‌تواند برای بازنویسی متغیرهای پیش‌فرض یا تنظیم متغیرهای اضافی استفاده شود\&. می‌توان بیش از یک بار برای تنظیم چندین متغیر از آن استفاده کرد\&. هنگامی که
"="
و
\fIVALUE\fR
حذف شوند، مقدار متغیر با همان نام در محیط برنامه استفاده خواهد شد\&.
.sp
افزوده‌شده در نسخه 209\&.
.RE
.PP
\fB\-u\fR, \fB\-\-uid=\fR
.RS 4
پس از انتقال به درون کانتینر، به کاربر مشخص‌شده که در پایگاه‌داده کاربران کانتینر تعریف شده است تغییر می‌یابد\&. مانند سایر ویژگی‌های systemd\-nspawn، این یک ویژگی امنیتی نیست و تنها محافظتی در برابر عملیات مخرب تصادفی فراهم می‌کند\&. این گزینه پیش‌تر
\fB\-\-user=\fR
نامیده می‌شد\&. نام قدیمی همچنان پذیرفته می‌شود اما منسوخ شده است\&. گزینه کوتاه
\fB\-u\fR
با هر دو نسخه قدیمی و جدید
\fBsystemd\-nspawn\fR
سازگار است\&.
.sp
توجه داشته باشید که اگر اعتبارنامه‌ها در ترکیب با یک
\fB\-\-uid=\fR
غیر ریشه استفاده شوند (مثلاً:
\fB\-\-set\-credential=\fR
یا
\fB\-\-load\-credential=\fR)،
آن‌گاه
\fB\-\-no\-new\-privileges=yes\fR
باید استفاده شود، و
\fB\-\-boot\fR
یا
\fB\-\-as\-pid2\fR
نباید استفاده شوند، زیرا در غیر این صورت اعتبارنامه‌ها به دلیل عدم وجود امتیازات پس از تغییر به کاربر مشخص‌شده، توسط کانتینر غیرقابل‌خواندن خواهند بود\&.
.RE
.PP
\fB\-\-kill\-signal=\fR
.RS 4
سیگنال فرآیندی را مشخص می‌کند که هنگام دریافت
\fBSIGTERM\fR
توسط خود nspawn به PID 1 کانتینر ارسال شود، تا خاموش شدن منظم کانتینر را راه‌اندازی کند\&. اگر
\fB\-\-boot\fR
استفاده شود، مقدار پیش‌فرض
\fBSIGRTMIN+3\fR
است (در سیستم‌های init سازگار با systemd، سیگنال
\fBSIGRTMIN+3\fR
خاموشی منظم را آغاز می‌کند)\&. اگر
\fB\-\-boot\fR
استفاده نشود و این گزینه مشخص نگردد، فرآیندهای کانتینر به طور ناگهانی از طریق
\fBSIGKILL\fR
خاتمه می‌یابند\&. برای فهرستی از سیگنال‌های معتبر،
\fBsignal\fR(7)
را ببینید\&.
.sp
افزوده‌شده در نسخه 220\&.
.RE
.PP
\fB\-\-notify\-ready=\fR
.RS 4
پشتیبانی از اعلان‌ها از فرآیند آغازین کانتینر را پیکربندی می‌کند\&.
\fB\-\-notify\-ready=\fR
یک مقدار بولی را می‌پذیرد\&. اگر false باشد،
\fBsystemd\-nspawn\fR
هنگام ایجاد فرآیند آغازین، مدیر سرویس فراخواننده را با پیام
"READY=1"
مطلع می‌سازد\&. اگر true باشد، قبل از ارسال پیام خود به مدیر سرویس، منتظر پیام
"READY=1"
از فرآیند آغازین در کانتینر می‌ماند\&. برای جزئیات بیشتر در مورد اعلان‌ها،
\fBsd_notify\fR(3)
را ببینید\&.
.sp
پیش‌فرض false است\&. (توجه داشته باشید که این بر خلاف گزینه همنام در
\fBsystemd-vmspawn\fR(1)
است که پیش‌فرض آن true می‌باشد\&.)
.sp
اگر خود
\fBsystemd\-nspawn\fR
با مقدار
\fI$NOTIFY_SOCKET\fR
تنظیم‌شده در محیط خود فراخوانی شود (یعنی خود آن توسط یک مدیر سرویس که از پروتکل
\fBsd_notify\fR(3)
استفاده می‌کند نظارت شود)، پیام‌های
"FDSTORE=1"
و
"FDSTOREREMOVE=1"
دریافت‌شده از بار مفید کانتینر (همراه با هر توصیف‌کننده فایل همراه و برچسب
"FDNAME=")
یک سطح بالاتر به مدیر سرویس دربرگیرنده ارسال می‌شوند\&. این امر اجازه می‌دهد تا مخزن توصیف‌کننده فایل سرویس‌های در حال اجرا در کانتینر در هنگام راه‌اندازی‌های مجدد کانتینر (و به طور متعدی، در طول راه‌اندازی‌های مجدد، اجرای مجدد، راه‌اندازی‌های مجدد نرم و kexecهای مبتنی بر LUO در هر مدیر سرویس بیرونی) حفظ شود، به شرطی که
\fIFileDescriptorStoreMax=\fR/\fIFileDescriptorStorePreserve=yes\fR
روی واحد اجراکننده
\fBsystemd\-nspawn\fR
پیکربندی شده باشند\&. برای جزئیات، مستندات
\m[blue]\fBFile Descriptor Store\fR\m[]\&\s-2\u[4]\d\s+2
را ببینید\&.
.sp
افزوده‌شده در نسخه 231\&.
.RE
.PP
\fB\-\-suppress\-sync=\fR
.RS 4
یک آرگومان بولی را انتظار دارد\&. اگر true باشد، هر شکلی از همگام‌سازی سیستم‌فایل روی دیسک را برای بار مفید کانتینر خاموش می‌کند\&. این بدان معناست که تمام فراخوانی‌های سیستمی مانند
\fBsync\fR(2)،
\fBfsync()\fR،
\fBsyncfs()\fR
و غیره هیچ عملیاتی را انجام نمی‌دهند، و پرچم‌های
\fBO_SYNC\fR/\fBO_DSYNC\fR
برای
\fBopen\fR(2)
و فراخوانی‌های مرتبط در دسترس نخواهند بود\&. این می‌تواند خطرناک باشد، زیرا تضمین‌های یکپارچگی داده فرضی برای بار مفید کانتینر عملاً اجرا نمی‌شوند (یعنی داده‌هایی که فرض می‌شود روی دیسک نوشته شده‌اند در صورت خاموش شدن غیرعادی سیستم ممکن است از بین بروند)\&. با این حال، تا زمانی که این تضمین‌ها لازم یا مطلوب نباشند، این کار می‌تواند کارایی زمان اجرای کانتینر را به طور چشمگیری بهبود بخشد \(en برای مثال به این دلیل که هر داده نوشته‌شده توسط کانتینر ماهیتی موقت و زاید دارد، یا صرفاً یک مصنوع میانی است که توسط مرحله بعدی در یک خط لوله پردازش و نهایی می‌شود\&. پیش‌فرض false است\&.
.sp
افزوده‌شده در نسخه 250\&.
.RE
.SS "گزینه‌های هویت سیستم (System Identity Options)"
.PP
\fB\-M\fR, \fB\-\-machine=\fR
.RS 4
نام ماشین را برای این کانتینر تعیین می‌کند\&. این نام ممکن است برای شناسایی این کانتینر در طول زمان اجرای آن (مثلاً در ابزارهایی مانند
\fBmachinectl\fR(1)
و موارد مشابه) استفاده شود، و برای مقداردهی اولیه نام میزبان (hostname) کانتینر استفاده می‌شود (البته کانتینر می‌تواند آن را بازنویسی کند)\&. در صورت عدم تعیین، آخرین جزء از مسیر دایرکتوری ریشه کانتینر استفاده می‌شود که احتمالاً در صورت انتخاب حالت
\fB\-\-ephemeral\fR
با یک شناسه تصادفی پسوندگذاری می‌شود\&. اگر دایرکتوری ریشه انتخاب‌شده دایرکتوری ریشه میزبان باشد، نام میزبان میزبان به جای آن به عنوان پیش‌فرض استفاده می‌شود\&.
.sp
افزوده‌شده در نسخه 202\&.
.RE
.PP
\fB\-\-hostname=\fR
.RS 4
نام میزبان را برای تنظیم درون کانتینر، در صورتی که با نام ماشین متفاوت باشد، کنترل می‌کند\&. یک نام میزبان معتبر را به عنوان آرگومان انتظار دارد\&. اگر این گزینه استفاده شود، نام میزبان هسته کانتینر روی این مقدار تنظیم می‌شود، در غیر این صورت روی نام ماشین مطابق با گزینه
\fB\-\-machine=\fR
توضیح‌داده‌شده در بالا مقداردهی اولیه خواهد شد\&. نام ماشین برای جنبه‌های مختلف شناسایی کانتینر از خارج استفاده می‌شود، و نام میزبان هسته قابل پیکربندی با این گزینه برای کانتینر جهت شناسایی خود از داخل مفید است\&. معمولاً ایده خوبی است که هر دو شکل شناسایی را همگام نگه دارید تا از سردرگمی جلوگیری شود\&. بنابراین توصیه می‌شود از استفاده از این گزینه خودداری کنید و منحصراً از
\fB\-\-machine=\fR
استفاده نمایید\&. توجه داشته باشید که صرف‌نظر از اینکه نام میزبان کانتینر از نام تنظیم‌شده با
\fB\-\-hostname=\fR
یا نام تنظیم‌شده با
\fB\-\-machine=\fR
مقداردهی اولیه شده باشد، کانتینر بعداً می‌تواند نام میزبان هسته خود را آزادانه و به تنهایی بازنویسی کند\&.
.sp
افزوده‌شده در نسخه 239\&.
.RE
.PP
\fB\-\-uuid=\fR
.RS 4
شناسه یکتای جهانی (UUID) مشخص‌شده را برای کانتینر تنظیم می‌کند\&. اگر این فایل هنوز تنظیم نشده باشد، سیستم init فایل
/etc/machine\-id
را بر این اساس مقداردهی اولیه خواهد کرد\&. توجه داشته باشید که این گزینه تنها در صورتی اثر دارد که
/etc/machine\-id
در کانتینر خالی باشد\&.
.RE
.SS "گزینه‌های مشخصه (Property Options)"
.PP
\fB\-S\fR, \fB\-\-slice=\fR
.RS 4
کانتینر را به جای حالت پیش‌فرض
machine\&.slice،
بخشی از برش (slice) مشخص‌شده قرار می‌دهد\&. این تنها در صورتی اعمال می‌شود که ماشین در واحد دامنه (scope unit) اختصاصی خود اجرا شود، یعنی اگر
\fB\-\-keep\-unit\fR
استفاده نشود\&.
.sp
افزوده‌شده در نسخه 206\&.
.RE
.PP
\fB\-\-property=\fR
.RS 4
یک مشخصه واحد را روی واحد دامنه‌ای که قرار است برای ماشین ثبت شود تنظیم می‌کند\&. این تنها در صورتی اعمال می‌شود که ماشین در واحد دامنه اختصاصی خود اجرا شود، یعنی اگر
\fB\-\-keep\-unit\fR
استفاده نشود\&. انتساب‌های مشخصه واحد را با همان قالبی که
\fBsystemctl set\-property\fR
می‌پذیرد دریافت می‌کند\&. این برای تنظیم محدودیت‌های حافظه و موارد مشابه برای کانتینر مفید است\&.
.sp
افزوده‌شده در نسخه 220\&.
.RE
.PP
\fB\-\-register=\fR
.RS 4
کنترل می‌کند که آیا کانتینر در
\fBsystemd-machined\fR(8)
ثبت شود یا خیر\&. یک آرگومان بولی یا
"auto"
را می‌پذیرد و پیش‌فرض آن
"auto"
است\&. این گزینه باید زمانی فعال شود که کانتینر یک سیستم‌عامل کامل را اجرا می‌کند (به طور خاص: یک مدیر سیستم و سرویس به عنوان PID 1)، و برای اطمینان از اینکه کانتینر از طریق
\fBmachinectl\fR(1)
قابل دسترسی بوده و توسط ابزارهایی مانند
\fBps\fR(1)
نمایش داده می‌شود مفید است\&. اگر کانتینر یک مدیر سرویس را اجرا نمی‌کند، توصیه می‌شود این گزینه را روی
"no"
تنظیم کنید\&. هنگامی که روی
"auto"
تنظیم شود، ثبت کانتینر تلاش می‌شود اما شکست‌ها نادیده گرفته می‌شوند\&.
.sp
افزوده‌شده در نسخه 209\&.
.RE
.PP
\fB\-\-keep\-unit\fR
.RS 4
به جای ایجاد یک واحد دامنه موقت برای اجرای کانتینر در آن، صرفاً از واحد سرویس یا دامنه‌ای استفاده می‌کند که
\fBsystemd\-nspawn\fR
در آن فراخوانی شده است\&. اگر
\fB\-\-register=yes\fR
تنظیم شده باشد، این واحد در
\fBsystemd-machined\fR(8)
ثبت می‌شود\&. این سوئیچ باید زمانی استفاده شود که
\fBsystemd\-nspawn\fR
از درون یک واحد سرویس فراخوانی شود و تنها هدف واحد سرویس اجرای یک کانتینر منفرد
\fBsystemd\-nspawn\fR
باشد\&. این گزینه در صورت اجرا از یک نشست کاربری در دسترس نیست\&.
.sp
توجه داشته باشید که ارسال
\fB\-\-keep\-unit\fR
اثر
\fB\-\-slice=\fR
و
\fB\-\-property=\fR
را غیرفعال می‌کند\&. از
\fB\-\-keep\-unit\fR
و
\fB\-\-register=no\fR
به صورت ترکیبی استفاده کنید تا هر نوع تخصیص واحد یا ثبت در
\fBsystemd\-machined\fR
غیرفعال شود\&.
.sp
افزوده‌شده در نسخه 209\&.
.RE
.SS "گزینه‌های فضای‌نام کاربر (User Namespacing Options)"
.PP
\fB\-\-private\-users=\fR
.RS 4
فضای‌نام کاربر را کنترل می‌کند\&. در صورت فعال بودن، کانتینر با مجموعه خصوصی خود از شناسه‌های کاربر و گروه یونیکس (UIDها و GIDها) اجرا خواهد شد\&. این شامل نگاشت UIDها/GIDهای خصوصی استفاده‌شده در کانتینر (شروع از کاربر ریشه کانتینر 0 به بالا) به محدوده‌ای از UIDها/GIDها در میزبان است که برای اهداف دیگر استفاده نمی‌شوند (معمولاً در محدوده فراتر از UID/GID شماره 65536 میزبان)\&. این پارامتر ممکن است به صورت زیر مشخص شود:
.sp
.RS 4
.ie n \{\
\h'-04' 1.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  1." 4.2
.\}
اگر یک یا دو عدد جداشده با دونقطه مشخص شوند، فضای‌نام کاربر روشن می‌شود\&. پارامتر اول اولین UID/GID میزبان را برای انتساب به کانتینر مشخص می‌کند، و پارامتر دوم تعداد UIDها/GIDهای میزبان را برای انتساب به کانتینر مشخص می‌نماید\&. اگر پارامتر دوم حذف شود، ۶۵۵۳۶ UID/GID اختصاص داده می‌شود\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04' 2.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  2." 4.2
.\}
اگر پارامتر
"yes"
باشد، فضای‌نام کاربر روشن می‌شود\&. محدوده UID/GID مورد استفاده به طور خودکار از مالکیت فایل دایرکتوری ریشه درخت دایرکتوری کانتینر تعیین می‌گردد\&. برای استفاده از این گزینه، مطمئن شوید که درخت دایرکتوری را از قبل آماده کرده‌اید، و اطمینان حاصل کنید که تمام فایل‌ها و دایرکتوری‌های موجود در آن متعلق به UIDها/GIDها در محدوده‌ای هستند که مایل به استفاده از آن هستید\&. همچنین مطمئن شوید که ACLهای فایل استفاده‌شده منحصراً به UIDها/GIDها در محدوده مناسب ارجاع می‌دهند\&. در این حالت، تعداد UIDها/GIDهای اختصاص‌یافته به کانتینر ۶۵۵۳۶ است، و UID/GID مالک دایرکتوری ریشه باید مضربی از ۶۵۵۳۶ باشد\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04' 3.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  3." 4.2
.\}
مقدار ویژه
"pick"
فضای‌نام کاربر را روشن می‌کند\&. در این حالت محدوده UID/GID به طور خودکار انتخاب می‌شود\&. به عنوان مرحله اول، UID/GID مالک فایل دایرکتوری ریشه درخت دایرکتوری کانتینر خوانده می‌شود، و بررسی می‌گردد که هیچ کانتینر دیگری در حال حاضر از آن استفاده نمی‌کند\&. اگر این بررسی موفقیت‌آمیز باشد، محدوده UID/GID تعیین‌شده از این طریق استفاده می‌شود، مشابه رفتاری که در صورت تعیین
"yes"
رخ می‌دهد\&. اگر بررسی موفقیت‌آمیز نباشد (و در نتیجه محدوده UID/GID نشان‌داده‌شده در مالک فایل دایرکتوری ریشه قبلاً در جای دیگری استفاده شده باشد)، یک محدوده UID/GID جدید \(en در حال حاضر استفاده‌نشده \(en شامل ۶۵۵۳۶ UID/GID به صورت تصادفی بین UIDها/GIDهای ۵۲۴۲۸۸ و ۱۸۷۸۹۸۲۶۵۶ میزبان انتخاب می‌شود، که همیشه از مضربی از ۶۵۵۳۶ شروع شده و در صورت امکان، به طور مداوم از نام ماشین هش می‌شود\&. این تنظیم مستلزم
\fB\-\-private\-users\-ownership=auto\fR
است (به زیر مراجعه کنید)، که احتمالاً این اثر را دارد که فایل‌ها و دایرکتوری‌ها در درخت دایرکتوری کانتینر متعلق به کاربران مناسب محدوده انتخاب‌شده خواهند بود\&. استفاده از این گزینه رفتار فضای‌نام کاربر را کاملاً خودکار می‌سازد\&. توجه داشته باشید که اولین فراخوانی یک تصویر کانتینر که قبلاً استفاده نشده است ممکن است منجر به انتخاب یک محدوده UID/GID جدید برای آن شود، و در نتیجه عملیات تنظیم مالکیت فایل (احتمالاً پرهزینه) انجام گیرد\&. با این حال، فراخوانی‌های بعدی کانتینر کم‌هزینه خواهند بود (مگر اینکه البته محدوده UID/GID انتخاب‌شده تا آن زمان به کاربرد دیگری اختصاص یافته باشد)\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04' 4.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  4." 4.2
.\}
اگر پارامتر
"no"
باشد، فضای‌نام کاربر خاموش می‌شود\&. این حالت پیش‌فرض هنگام فراخوانی مستقیم
\fBsystemd\-nspawn\fR
است\&. (توجه داشته باشید که واحد
systemd\-nspawn@\&.service
کاربران خصوصی را فعال می‌کند\&.) این گزینه امن نیست و نباید برای اجرای کدهای غیرقابل‌اعتماد استفاده شود\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04' 5.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  5." 4.2
.\}
اگر پارامتر
"identity"
باشد، فضای‌نام کاربر با یک نگاشت همانی (identity mapping) برای اولین ۶۵۵۳۶ UID/GID به کار گرفته می‌شود\&. این عمدتاً معادل
\fB\-\-private\-users=0:65536\fR
است\&. در حالی که این گزینه جداسازی UID/GID را فراهم نمی‌کند (زیرا تمام UIDها/GIDهای میزبان و کانتینر به صورت یکسان انتخاب می‌شوند)، جداسازی قابلیت‌های فرآیند (process capabilities) را فراهم می‌سازد، و ممکن است در صورتی که فضای‌نام کاربر مناسب با نگاشت‌های UID متمایز امکان‌پذیر نباشد، مفید واقع شود\&. این گزینه امن نیست و نباید برای اجرای کدهای غیرقابل‌اعتماد استفاده شود\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04' 6.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  6." 4.2
.\}
اگر پارامتر
"managed"
باشد، فضای‌نام کاربر در حالت
\fImanaged\fR
(مدیریت‌شده) به کار گرفته می‌شود، یعنی تخصیص محدوده UID به
\fBsystemd-nsresourced.service\fR(8)
محول می‌گردد\&. این حالت در صورت فراخوانی بدون امتیاز به طور پیش‌فرض انتخاب می‌شود، اما در صورت داشتن امتیاز نیز می‌تواند به صراحت درخواست شود\&. در این حالت یک محدوده 64K UID به طور خودکار انتخاب می‌شود\&.
.RE
.sp
توصیه می‌شود حداقل ۶۵۵۳۶ UID/GID به هر کانتینر اختصاص داده شود تا محدوده UID/GID قابل استفاده در کانتینر ۱۶ بیت را پوشش دهد\&. برای بهترین امنیت، محدوده‌های UID/GID همپوشان را به چندین کانتینر اختصاص ندهید\&. بنابراین ایده خوبی است که از ۱۶ بیت بالایی UIDها/GIDهای ۳۲ بیتی میزبان به عنوان شناسه کانتینر استفاده شود، در حالی که ۱۶ بیت پایینی UID/GID مورد استفاده کانتینر را کدگذاری می‌کنند\&. این در واقع رفتاری است که توسط گزینه
\fB\-\-private\-users=pick\fR
اجرا می‌شود\&.
.sp
هنگامی که فضاهای‌نام کاربر استفاده می‌شوند، محدوده GID اختصاص‌یافته به هر کانتینر همیشه یکسان با محدوده UID انتخاب می‌شود\&.
.sp
در بیشتر موارد،
\fB\-\-private\-users=managed\fR
(یا در حالت دارای امتیاز،
\fB\-\-private\-users=pick\fR
نیز) گزینه توصیه‌شده است زیرا ایجاد فضای‌نام کاربر برای امنیت توصیه می‌شود، و این گزینه امنیت کانتینر را به شدت افزایش داده در حالی که در اکثر موارد کاملاً خودکار عمل می‌کند\&.
.sp
توجه داشته باشید که محدوده UID/GID انتخاب‌شده در
/etc/passwd
یا
/etc/group
نوشته نمی‌شود\&. در واقع، تخصیص این محدوده به طور ماندگار ذخیره نمی‌شود، مگر احتمالاً در مالکیت فایل‌های مربوط به فایل‌ها و دایرکتوری‌های کانتینر، به
\fB\-\-private\-users\-ownership=\fR
مراجعه کنید\&.
.sp
توجه داشته باشید هنگامی که فضای‌نام کاربر بدون نگاشت UID استفاده می‌شود (به زیر مراجعه کنید)، مالکیت فایل روی دیسک این موضوع را منعکس می‌کند، و تمام فایل‌ها و دایرکتوری‌های کانتینر متعلق به شناسه‌های کاربری و گروهی موثر کانتینر خواهند بود\&. این بدان معناست که کپی کردن فایل‌ها از و به تصویر کانتینر نیازمند تصحیح مقادیر عددی UID/GID بر اساس جابجایی UID/GID اعمال‌شده است\&.
.sp
توجه داشته باشید که برای عملکرد کاملاً بدون امتیاز در حالت
"managed"،
هر تصویر دایرکتوری باید متعلق به محدوده UID خارجی باشد\&.
.sp
افزوده‌شده در نسخه 220\&.
.RE
.PP
\fB\-\-private\-users\-ownership=\fR
.RS 4
نحوه تنظیم UIDها و GIDهای تصویر کانتینر را برای تطابق با محدوده UID/GID انتخاب‌شده با
\fB\-\-private\-users=\fR
(به بالا مراجعه کنید) کنترل می‌کند\&. یکی از موارد
"off"
(برای دست‌نخورده باقی گذاشتن تصویر)،
"chown"
(برای اعمال بازگشتی
\fBchown()\fR
روی درخت دایرکتوری کانتینر در صورت نیاز)،
"map"
(به منظور استفاده از مانت‌های شفاف نگاشت شناسه از UID 0 به محدوده UID هدف)،
"foreign"
(مشابه مورد قبل، اما از پایه محدوده UID خارجی) یا
"auto"
برای استفاده خودکار از
"map"
یا
"foreign"
در صورت وجود و کاربرد، و
"chown"
در صورت عدم دسترسی را می‌پذیرد\&.
.sp
اگر
"chown"
انتخاب شود، تمام فایل‌ها و دایرکتوری‌های موجود در درخت دایرکتوری کانتینر تنظیم خواهند شد تا متعلق به UIDها/GIDهای مناسب انتخاب‌شده برای کانتینر باشند (به بالا مراجعه کنید)\&. این عملیات بالقوه پرهزینه است، زیرا شامل پیمایش در کل درخت دایرکتوری کانتینر می‌شود\&. علاوه بر مالکیت واقعی فایل، ACLهای فایل نیز تنظیم می‌شوند\&.
.sp
به طور معمول
"foreign"
یا
"map"
بهترین انتخاب است، زیرا UIDها/GIDها را به صورت شفاف در حافظه بر حسب نیاز بدون تغییر تصویر و بدون نیاز به یک عملیات تنظیم بازگشتی پرهزینه نگاشت می‌کند\&. با این حال، در حال حاضر برای همه سیستم‌های فایل در دسترس نیست\&.
.sp
گزینه
\fB\-\-private\-users\-ownership=auto\fR
در صورت استفاده از
\fB\-\-private\-users=pick\fR
به صورت ضمنی اعمال می‌شود\&. این گزینه در صورتی که از فضای‌نام کاربر استفاده نشود، هیچ اثری ندارد\&.
.sp
سوئیچ
\fB\-\-shift\fR
در
\fBsystemd-dissect\fR(1)
ممکن است برای جابجایی مالکیت UID/GID از یا به پایه UID/GID صفر، خارجی یا کانتینر خاص در خارج از هرگونه فراخوانی
\fBsystemd\-nspawn\fR
استفاده شود\&.
.sp
افزوده‌شده در نسخه 230\&.
.RE
.PP
\fB\-\-private\-users\-delegate=\fR
.RS 4
یک عدد صحیح غیرمنفی را می‌پذیرد\&. درخواست می‌کند که تعداد مشخص‌شده‌ای از محدوده‌های اضافی 64K UID/GID به فضای‌نام کاربر کانتینر تفویض شوند\&. این محدوده‌های تفویض‌شده به صورت ۱:۱ نگاشت می‌شوند (یعنی مقادیر UID/GID یکسانی در داخل و خارج فضای‌نام کاربر استفاده می‌شوند) و می‌توانند توسط کانتینرهای تودرتو برای تخصیص محدوده‌های UID/GID موقت خود از طریق
\fBsystemd-nsresourced.service\fR(8)
استفاده شوند\&.
.sp
این گزینه به
\fB\-\-private\-users=managed\fR
نیاز دارد، زیرا این تفویض توسط
\fBsystemd-nsresourced.service\fR(8)
به عنوان بخشی از تخصیص فضای‌نام کاربر انجام می‌شود\&. حداکثر تعداد محدوده‌های تفویض‌شده ۱۶ است\&. پیش‌فرض 0 است، یعنی بدون تفویض\&.
.sp
هنگامی که این گزینه با یک مقدار غیرصفر استفاده می‌شود، سوکت Varlink سرویس
\fBsystemd-nsresourced.service\fR(8)
(/run/systemd/io\&.systemd\&.NamespaceResource)
به طور خودکار به همراه پیوندهای نمادین کشف لازم در
/run/systemd/userdb/
و
/run/varlink/registry/
به درون کانتینر bind\-mount می‌شود\&. این به فرآیندهای درون کانتینر اجازه می‌دهد تا با
\fBsystemd\-nsresourced\fR
روی میزبان تماس بگیرند تا فضاهای‌نام کاربر تودرتو را از محدوده‌های تفویض‌شده تخصیص دهند\&.
.sp
افزوده‌شده در نسخه 260\&.
.RE
.PP
\fB\-U\fR
.RS 4
اگر هسته از ویژگی فضاهای‌نام کاربر پشتیبانی کند، معادل
\fB\-\-private\-users=pick \-\-private\-users\-ownership=auto\fR
است، در غیر این صورت معادل
\fB\-\-private\-users=no\fR
می‌باشد\&.
.sp
توجه داشته باشید که اگر از فایل واحد الگوی
systemd\-nspawn@\&.service
استفاده شود،
\fB\-U\fR
حالت پیش‌فرض است\&.
.sp
نکته: با تکرار عملیات با اولین UID معادل 0، می‌توان اثر
\fB\-\-private\-users\-ownership=chown\fR
(یا
\fB\-U\fR)
بر سیستم فایل را خنثی کرد:
.sp
.if n \{\
.RS 4
.\}
.nf
systemd\-nspawn \&... \-\-private\-users=0 \-\-private\-users\-ownership=chown
.fi
.if n \{\
.RE
.\}
.sp
افزوده‌شده در نسخه 230\&.
.RE
.SS "گزینه‌های شبکه (Networking Options)"
.PP
\fB\-\-private\-network\fR
.RS 4
شبکه‌سازی کانتینر را از میزبان قطع می‌کند\&. این باعث می‌شود تمام واسط‌های شبکه در کانتینر غیرقابل دسترسی شوند، به استثنای دستگاه loopback و مواردی که با
\fB\-\-network\-interface=\fR
مشخص شده و با
\fB\-\-network\-veth\fR
پیکربندی شده‌اند\&. اگر این گزینه مشخص شود، قابلیت
\fBCAP_NET_ADMIN\fR
به مجموعه قابلیت‌هایی که کانتینر حفظ می‌کند اضافه خواهد شد\&. دومی را می‌توان با استفاده از
\fB\-\-drop\-capability=\fR
غیرفعال کرد\&. اگر این گزینه مشخص نشود (یا توسط یکی از گزینه‌های فهرست‌شده در زیر به صورت ضمنی اعمال نشود)، کانتینر دسترسی کامل به شبکه میزبان خواهد داشت\&.
.RE
.PP
\fB\-\-network\-interface=\fR
.RS 4
واسط شبکه مشخص‌شده را به کانتینر اختصاص می‌دهد\&. یا یک نام واسط واحد را می‌پذیرد که به نام روی میزبان ارجاع می‌دهد، یا یک جفت واسط جداشده با دونقطه، که در این صورت مورد اول به نام روی میزبان و مورد دوم به نام در کانتینر ارجاع دارد\&. هنگامی که کانتینر خاتمه می‌یابد، واسط به فضای‌نام فراخواننده بازگردانده شده و به نام اصلی خود تغییر نام می‌یابد\&. توجه داشته باشید که
\fB\-\-network\-interface=\fR
مستلزم
\fB\-\-private\-network\fR
است\&. این گزینه ممکن است بیش از یک بار برای افزودن چندین واسط شبکه به کانتینر استفاده شود\&.
.sp
توجه داشته باشید که هر واسط شبکه مشخص‌شده از این طریق باید در زمان شروع کانتینر از قبل وجود داشته باشد\&. اگر قرار است کانتینر به طور خودکار هنگام بوت از طریق یک نمونه فایل واحد
systemd\-nspawn@\&.service
راه‌اندازی شود، بنابراین ممکن است افزودن یک فایل قطره‌ای (drop-in) واحد به نمونه سرویس (مثلاً
/etc/systemd/system/systemd\-nspawn@foobar\&.service\&.d/50\-network\&.conf)
با محتوایی مانند زیر منطقی باشد:
.sp
.if n \{\
.RS 4
.\}
.nf
[Unit]
Wants=sys\-subsystem\-net\-devices\-ens1\&.device
After=sys\-subsystem\-net\-devices\-ens1\&.device
.fi
.if n \{\
.RE
.\}
.sp
این امر اطمینان حاصل می‌کند که فعال‌سازی سرویس کانتینر تا زمان ظاهر شدن واسط شبکه
"ens1"
به تعویق بیفتد\&. این امر ضروری است زیرا کاوش سخت‌افزار کاملاً ناهمگام است و واسط‌های شبکه ممکن است بعداً در طول فرآیند بوت کشف شوند، پس از اینکه کانتینر معمولاً بدون این وابستگی‌های صریح راه‌اندازی می‌شد\&.
.sp
افزوده‌شده در نسخه 209\&.
.RE
.PP
\fB\-\-network\-macvlan=\fR
.RS 4
یک واسط
"macvlan"
از واسط شبکه اترنت مشخص‌شده ایجاد کرده و آن را به کانتینر اضافه می‌کند\&. یا یک نام واسط واحد را می‌پذیرد که به نام روی میزبان ارجاع می‌دهد، یا یک جفت واسط جداشده با دونقطه، که در این صورت مورد اول به نام روی میزبان و مورد دوم به نام در کانتینر ارجاع دارد\&. واسط
"macvlan"
یک واسط مجازی است که یک آدرس MAC دوم را به یک پیوند اترنت فیزیکی موجود اضافه می‌کند\&. اگر نام واسط کانتینر تعریف نشده باشد، واسط در کانتینر با نام واسط روی میزبان همراه با پیشوند
"mv\-"
نام‌گذاری می‌شود\&. توجه داشته باشید که
\fB\-\-network\-macvlan=\fR
مستلزم
\fB\-\-private\-network\fR
است\&. این گزینه ممکن است بیش از یک بار برای افزودن چندین واسط شبکه به کانتینر استفاده شود\&.
.sp
همانند
\fB\-\-network\-interface=\fR،
واسط شبکه اترنت زیرین باید در زمان شروع کانتینر از قبل وجود داشته باشد، و بنابراین فایل‌های قطره‌ای مشابه فایل واحد همان‌طور که در بالا توضیح داده شد ممکن است مفید باشند\&.
.sp
افزوده‌شده در نسخه 211\&.
.RE
.PP
\fB\-\-network\-ipvlan=\fR
.RS 4
یک واسط
"ipvlan"
از واسط شبکه اترنت مشخص‌شده ایجاد کرده و آن را به کانتینر اضافه می‌کند\&. یا یک نام واسط واحد را می‌پذیرد که به نام روی میزبان ارجاع می‌دهد، یا یک جفت واسط جداشده با دونقطه، که در این صورت مورد اول به نام روی میزبان و مورد دوم به نام در کانتینر ارجاع دارد\&. واسط
"ipvlan"
یک واسط مجازی، مشابه واسط
"macvlan"
است که از همان آدرس MAC واسط زیرین استفاده می‌کند\&. اگر نام واسط کانتینر تعریف نشده باشد، واسط در کانتینر با نام واسط روی میزبان همراه با پیشوند
"iv\-"
نام‌گذاری می‌شود\&. توجه داشته باشید که
\fB\-\-network\-ipvlan=\fR
مستلزم
\fB\-\-private\-network\fR
است\&. این گزینه ممکن است بیش از یک بار برای افزودن چندین واسط شبکه به کانتینر استفاده شود\&.
.sp
همانند
\fB\-\-network\-interface=\fR،
واسط شبکه اترنت زیرین باید در زمان شروع کانتینر از قبل وجود داشته باشد، و بنابراین فایل‌های قطره‌ای مشابه فایل واحد همان‌طور که در بالا توضیح داده شد ممکن است مفید باشند\&.
.sp
افزوده‌شده در نسخه 219\&.
.RE
.PP
\fB\-n\fR, \fB\-\-network\-veth\fR
.RS 4
یک پیوند اترنت مجازی ("veth") بین میزبان و کانتینر ایجاد می‌کند\&. سمت میزبان پیوند اترنت به عنوان یک واسط شبکه همنام با نام کانتینر (همان‌طور که با
\fB\-\-machine=\fR
مشخص شده است)، با پیشوند
"ve\-"
در دسترس خواهد بود\&. سمت کانتینر پیوند اترنت
"host0"
نام‌گذاری خواهد شد\&. گزینه
\fB\-\-network\-veth\fR
مستلزم
\fB\-\-private\-network\fR
است\&.
.sp
توجه داشته باشید که
\fBsystemd-networkd.service\fR(8)
به طور پیش‌فرض شامل یک فایل شبکه
/usr/lib/systemd/network/80\-container\-ve\&.network
مطابق با واسط‌های سمت میزبان ایجادشده از این طریق است، که شامل تنظیماتی برای فعال‌سازی تخصیص خودکار آدرس روی پیوند مجازی ایجادشده از طریق DHCP، و همچنین مسیریابی خودکار IP به واسط‌های شبکه خارجی میزبان می‌باشد\&. همچنین شامل
/usr/lib/systemd/network/80\-container\-host0\&.network
مطابق با واسط سمت کانتینر ایجادشده از این طریق است که شامل تنظیماتی برای فعال‌سازی انتساب آدرس سمت کلاینت از طریق DHCP می‌باشد\&. در صورتی که
systemd\-networkd
هم روی میزبان و هم درون کانتینر در حال اجرا باشد، ارتباط IP خودکار از کانتینر به میزبان با اتصال بیشتر به شبکه خارجی در دسترس خواهد بود\&.
.sp
توجه داشته باشید که
\fB\-\-network\-veth\fR
در صورت استفاده از فایل واحد الگوی
systemd\-nspawn@\&.service
حالت پیش‌فرض است\&.
.sp
توجه داشته باشید که در لینوکس نام واسط‌های شبکه حداکثر می‌تواند ۱۵ کاراکتر طول داشته باشد، در حالی که نام کانتینرها می‌تواند تا ۶۴ کاراکتر طول داشته باشد\&. از آنجا که این گزینه نام واسط سمت میزبان را از نام کانتینر مشتق می‌کند، ممکن است نام کوتاه شود\&. بنابراین، باید دقت شود تا اطمینان حاصل شود که نام‌های واسط در این حالت منحصر‌به‌فرد باقی می‌مانند، یا حتی بهتر است نام کانتینرها عموماً بیشتر از ۱۲ کاراکتر انتخاب نشوند تا از کوتاه‌سازی جلوگیری گردد\&. اگر نام کوتاه شود،
\fBsystemd\-nspawn\fR
به طور خودکار یک مقدار هش ۴ رقمی را به نام الحاق می‌کند تا احتمال تداخل کاهش یابد\&. با این حال، الگوریتم هش بدون برخورد نیست\&. (برای جزئیات در مورد الگوریتم‌های نام‌گذاری قدیمی‌تر برای این واسط،
\fBsystemd.net-naming-scheme\fR(7)
را ببینید)\&. از طرف دیگر، گزینه
\fB\-\-network\-veth\-extra=\fR
می‌تواند استفاده شود که اجازه پیکربندی آزاد نام واسط سمت میزبان را مستقل از نام کانتینر می‌دهد \(em اما ممکن است در صورتی که پل‌بندی به روشی مشابه
\fB\-\-network\-bridge=\fR
مورد نظر باشد، به کمی پیکربندی اضافی نیاز داشته باشد\&.
.sp
افزوده‌شده در نسخه 209\&.
.RE
.PP
\fB\-\-network\-veth\-extra=\fR
.RS 4
یک پیوند اترنت مجازی اضافی بین میزبان و کانتینر اضافه می‌کند\&. یک جفت نام واسط میزبان و نام واسط کانتینر جداشده با دونقطه را می‌پذیرد\&. دومی ممکن است حذف شود که در این صورت به دو سمت کانتینر و میزبان نام یکسانی اختصاص داده می‌شود\&. این سوئیچ مستقل از
\fB\-\-network\-veth\fR
است، و \(em بر خلاف آن \(em ممکن است چندین بار استفاده شود و امکان پیکربندی نام‌های واسط شبکه را فراهم می‌سازد\&. توجه داشته باشید که
\fB\-\-network\-bridge=\fR
هیچ تاثیری بر واسط‌های ایجادشده با
\fB\-\-network\-veth\-extra=\fR
ندارد\&.
.sp
افزوده‌شده در نسخه 228\&.
.RE
.PP
\fB\-\-network\-bridge=\fR
.RS 4
سمت میزبان پیوند اترنت ایجادشده با
\fB\-\-network\-veth\fR
را به واسط پل اترنت (Ethernet bridge) مشخص‌شده اضافه می‌کند\&. یک نام واسط شبکه معتبر از یک دستگاه پل را به عنوان آرگومان انتظار دارد\&. توجه داشته باشید که
\fB\-\-network\-bridge=\fR
مستلزم
\fB\-\-network\-veth\fR
است\&. اگر این گزینه استفاده شود، سمت میزبان پیوند اترنت از پیشوند
"vb\-"
به جای
"ve\-"
استفاده خواهد کرد\&. صرف‌نظر از پیشوند نام‌گذاری استفاده‌شده، همان محدودیت‌های طول نام واسط شبکه اعمال‌شده توسط لینوکس به همراه پیچیدگی‌هایی که ایجاد می‌کند اعمال می‌شود (برای جزئیات به بالا مراجعه کنید)\&.
.sp
همانند
\fB\-\-network\-interface=\fR،
واسط شبکه پل زیرین باید در زمان شروع کانتینر از قبل وجود داشته باشد، و بنابراین فایل‌های قطره‌ای مشابه فایل واحد همان‌طور که در بالا توضیح داده شد ممکن است مفید باشند\&.
.sp
افزوده‌شده در نسخه 209\&.
.RE
.PP
\fB\-\-network\-zone=\fR
.RS 4
یک پیوند اترنت مجازی ("veth") به کانتینر ایجاد کرده و آن را به یک واسط پل اترنت مدیریت‌شده به صورت خودکار اضافه می‌کند\&. واسط پل پس از آرگومان ارائه‌شده با پیشوند
"vz\-"
نام‌گذاری می‌شود\&. واسط پل هنگامی که اولین کانتینر پیکربندی‌شده برای نام آن راه‌اندازی می‌شود به طور خودکار ایجاد می‌گردد، و هنگامی که آخرین کانتینر پیکربندی‌شده برای نام آن خارج می‌شود به طور خودکار حذف خواهد شد\&. از این رو، هر واسط پل پیکربندی‌شده از این طریق تنها تا زمانی وجود دارد که حداقل یک کانتینر در حال اجرا که به آن ارجاع می‌دهد وجود داشته باشد\&. این گزینه به جز این ایجاد/حذف خودکار دستگاه پل، بسیار شبیه به
\fB\-\-network\-bridge=\fR
است\&.
.sp
این تنظیم قرار دادن چندین کانتینر مرتبط را در یک دامنه انتشار مشترک مبتنی بر اترنت مجازی، که در اینجا «ناحیه» (zone) نامیده می‌شود، آسان می‌کند\&. هر کانتینر تنها می‌تواند بخشی از یک ناحیه باشد، اما هر ناحیه می‌تواند شامل هر تعداد کانتینر باشد\&. هر ناحیه با نام خود ارجاع داده می‌شود\&. نام‌ها را می‌توان آزادانه انتخاب کرد (تا زمانی که با پیشوند
"vz\-"
نام‌های معتبر واسط شبکه را تشکیل دهند)، و کافی است همان نام را به سوئیچ
\fB\-\-network\-zone=\fR
کانتینرهای مختلف در حال اجرای همزمان ارسال کنید تا به یک ناحیه بپیوندند\&.
.sp
توجه داشته باشید که
\fBsystemd-networkd.service\fR(8)
به طور پیش‌فرض شامل یک فایل شبکه
/usr/lib/systemd/network/80\-container\-vz\&.network
مطابق با واسط‌های پل ایجادشده از این طریق است، که شامل تنظیماتی برای فعال‌سازی تخصیص خودکار آدرس در شبکه مجازی ایجادشده از طریق DHCP، و همچنین مسیریابی خودکار IP به واسط‌های شبکه خارجی میزبان می‌باشد\&. بنابراین استفاده از
\fB\-\-network\-zone=\fR
در اکثر موارد کاملاً خودکار و برای اتصال چندین کانتینر محلی در یک دامنه انتشار مشترک به میزبان، با اتصال بیشتر به شبکه خارجی کافی است\&.
.sp
افزوده‌شده در نسخه 230\&.
.RE
.PP
\fB\-\-network\-namespace\-path=\fR
.RS 4
مسیری به فایلی که نشان‌دهنده یک فضای‌نام شبکه هسته است و کانتینر باید در آن اجرا شود را می‌پذیرد\&. مسیر مشخص‌شده باید به یک فایل فضای‌نام شبکه (احتمالاً bind-mounted)، همان‌طور که توسط هسته در زیر
/proc/$PID/ns/net
ارائه شده است، ارجاع دهد\&. این کار باعث می‌شود کانتینر وارد فضای‌نام شبکه ارائه‌شده شود\&. یکی از موارد استفاده معمول، دادن یک فضای‌نام شبکه در زیر
/run/netns
است که توسط
\fBip-netns\fR(8)
ایجاد شده است، برای مثال
\fB\-\-network\-namespace\-path=/run/netns/foo\fR\&.
توجه داشته باشید که این گزینه نمی‌تواند همراه با سایر گزینه‌های مربوط به شبکه مانند
\fB\-\-private\-network\fR
یا
\fB\-\-network\-interface=\fR
استفاده شود\&.
.sp
افزوده‌شده در نسخه 236\&.
.RE
.PP
\fB\-p\fR, \fB\-\-port=\fR
.RS 4
اگر شبکه‌سازی خصوصی فعال باشد، یک پورت IP روی میزبان را روی یک پورت IP در کانتینر نگاشت می‌کند\&. یک مشخص‌کننده پروتکل (یا
"tcp"
یا
"udp")،
جداشده با دونقطه از یک شماره پورت میزبان در محدوده 1 تا 65535، جداشده با دونقطه از یک شماره پورت کانتینر در محدوده 1 تا 65535 را می‌پذیرد\&. مشخص‌کننده پروتکل و دونقطه جداکننده آن ممکن است حذف شوند که در این صورت
"tcp"
فرض می‌شود\&. شماره پورت کانتینر و دونقطه آن ممکن است حذف شوند که در این صورت همان پورت به عنوان پورت میزبان فرض می‌شود\&. این گزینه تنها در صورتی پشتیبانی می‌شود که از شبکه‌سازی خصوصی استفاده شود، مانند
\fB\-\-network\-veth\fR،
\fB\-\-network\-zone=\fR
یا
\fB\-\-network\-bridge=\fR\&.
.sp
افزوده‌شده در نسخه 219\&.
.RE
.SS "گزینه‌های امنیت (Security Options)"
.PP
\fB\-\-capability=\fR
.RS 4
یک یا چند قابلیت اضافی را برای اعطا به کانتینر فهرست می‌کند\&. فهرستی از نام‌های قابلیت‌های جداشده با کاما را می‌پذیرد، برای اطلاعات بیشتر
\fBcapabilities\fR(7)
را ببینید\&. توجه داشته باشید که قابلیت‌های زیر در هر صورت اعطا خواهند شد:
\fBCAP_AUDIT_CONTROL\fR,
\fBCAP_AUDIT_WRITE\fR,
\fBCAP_CHOWN\fR,
\fBCAP_DAC_OVERRIDE\fR,
\fBCAP_DAC_READ_SEARCH\fR,
\fBCAP_FOWNER\fR,
\fBCAP_FSETID\fR,
\fBCAP_IPC_OWNER\fR,
\fBCAP_KILL\fR,
\fBCAP_LEASE\fR,
\fBCAP_LINUX_IMMUTABLE\fR,
\fBCAP_MKNOD\fR,
\fBCAP_NET_BIND_SERVICE\fR,
\fBCAP_NET_BROADCAST\fR,
\fBCAP_NET_RAW\fR,
\fBCAP_SETFCAP\fR,
\fBCAP_SETGID\fR,
\fBCAP_SETPCAP\fR,
\fBCAP_SETUID\fR,
\fBCAP_SYS_ADMIN\fR,
\fBCAP_SYS_BOOT\fR,
\fBCAP_SYS_CHROOT\fR,
\fBCAP_SYS_NICE\fR,
\fBCAP_SYS_PTRACE\fR,
\fBCAP_SYS_RESOURCE\fR,
\fBCAP_SYS_TTY_CONFIG\fR\&.
همچنین در صورت تعیین
\fB\-\-private\-network\fR،
\fBCAP_NET_ADMIN\fR
حفظ می‌شود\&. اگر مقدار ویژه
"all"
ارسال شود، تمام قابلیت‌ها حفظ می‌شوند\&.
.sp
اگر مقدار ویژه
"help"
ارسال شود، برنامه نام‌های قابلیت‌های شناخته‌شده را چاپ کرده و خارج می‌شود\&.
.sp
این گزینه مجموعه محدودکننده قابلیت‌ها (bounding set) را تنظیم می‌کند که قابلیت‌های فراگیر (ambient capabilities) داده‌شده با
\fB\-\-ambient\-capability=\fR
را نیز محدود می‌نماید\&.
.sp
افزوده‌شده در نسخه 186\&.
.RE
.PP
\fB\-\-drop\-capability=\fR
.RS 4
یک یا چند قابلیت اضافی را برای حذف از کانتینر مشخص می‌کند\&. این امکان اجرای کانتینر با قابلیت‌های کمتر از حالت پیش‌فرض (به بالا مراجعه کنید) را فراهم می‌سازد\&.
.sp
اگر مقدار ویژه
"help"
ارسال شود، برنامه نام‌های قابلیت‌های شناخته‌شده را چاپ کرده و خارج می‌شود\&.
.sp
این گزینه مجموعه محدودکننده قابلیت‌ها را تنظیم می‌کند که قابلیت‌های فراگیر داده‌شده با
\fB\-\-ambient\-capability=\fR
را نیز محدود می‌نماید\&.
.sp
افزوده‌شده در نسخه 209\&.
.RE
.PP
\fB\-\-ambient\-capability=\fR
.RS 4
یک یا چند قابلیت اضافی را برای ارسال در مجموعه موروثی و فراگیر به برنامه آغازشده در کانتینر مشخص می‌کند\&. مقدار
"all"
برای این تنظیم پشتیبانی نمی‌شود\&.
.sp
تمام قابلیت‌های مشخص‌شده در اینجا باید در مجموعه مجاز با گزینه‌های
\fB\-\-capability=\fR
و
\fB\-\-drop\-capability=\fR
باشند\&. در غیر این صورت، یک پیام خطا نمایش داده خواهد شد\&.
.sp
این گزینه نمی‌تواند با حالت بوت کانتینر (همان‌طور که از طریق
\fB\-\-boot\fR
درخواست می‌شود) ترکیب شود\&.
.sp
اگر مقدار ویژه
"help"
ارسال شود، برنامه نام‌های قابلیت‌های شناخته‌شده را چاپ کرده و خارج می‌شود\&.
.sp
افزوده‌شده در نسخه 248\&.
.RE
.PP
\fB\-\-no\-new\-privileges=\fR
.RS 4
یک آرگومان بولی را می‌پذیرد\&. مقدار پرچم
\fBPR_SET_NO_NEW_PRIVS\fR
را برای بار مفید کانتینر مشخص می‌کند\&. پیش‌فرض خاموش است\&. هنگامی که روشن شود، کد بار مفید کانتینر نمی‌تواند امتیازات جدیدی کسب کند، یعنی بیت فایل "setuid" و همچنین قابلیت‌های سیستم فایل دیگر اثری نخواهند داشت\&. برای جزئیات در مورد این پرچم،
\fBprctl\fR(2)
را ببینید\&.
.sp
افزوده‌شده در نسخه 239\&.
.RE
.PP
\fB\-\-system\-call\-filter=\fR
.RS 4
فیلتر فراخوانی‌های سیستمی اعمال‌شده روی کانتینرها را تغییر می‌دهد\&. فهرستی از نام‌های فراخوانی سیستمی یا نام‌های گروه‌های جداشده با فاصله را می‌پذیرد (مورد اخیر با پیشوند
"@"
مشخص می‌شود، همان‌طور که توسط دستور
\fBsyscall\-filter\fR
از
\fBsystemd-analyze\fR(1)
فهرست شده است)\&. فراخوانی‌های سیستمی ارائه‌شده مجاز خواهند بود\&. فهرست ممکن است به صورت اختیاری با پیشوند
"~"
مشخص شود، که در این صورت تمام فراخوانی‌های سیستمی فهرست‌شده ممنوع خواهند بود\&. اگر این گزینه خط فرمان چندین بار استفاده شود، فهرست‌های پیکربندی‌شده با یکدیگر ترکیب می‌شوند\&. اگر هم یک فهرست مثبت و هم یک فهرست منفی (یعنی یک فهرست فراخوانی سیستمی بدون پیشوند
"~"
و یکی با پیشوند
"~")
پیکربندی شوند، فهرست منفی بر فهرست مثبت اولویت دارد\&. توجه داشته باشید که
\fBsystemd\-nspawn\fR
همیشه یک فهرست مجاز فراخوانی سیستمی را پیاده‌سازی می‌کند (بر خلاف فهرست رد!)، و بنابراین این گزینه خط فرمان بسته به پیشوند
"~"
مدخل‌هایی را به فهرست مجاز پیش‌فرض اضافه یا از آن حذف می‌کند\&. توجه داشته باشید که فیلتر فراخوانی‌های سیستمی اعمال‌شده در صورتی که قابلیت‌های اضافی با استفاده از
\fB\-\-capabilities=\fR
ارسال شوند نیز به صورت ضمنی تغییر می‌کند\&.
.sp
افزوده‌شده در نسخه 235\&.
.RE
.PP
\fB\-\-restrict\-address\-families=\fR
.RS 4
خانواده‌های آدرس سوکت قابل دسترسی برای کانتینر را محدود می‌کند\&. فهرستی از نام‌های خانواده آدرس جداشده با فاصله مانند
\fBAF_INET\fR،
\fBAF_INET6\fR
یا
\fBAF_UNIX\fR
را می‌پذیرد\&. هنگامی که با پیشوند
"~"
همراه باشند، خانواده‌های آدرس فهرست‌شده ممنوع خواهند شد، در غیر این صورت مجاز خواهند بود (در فهرست مجاز قرار می‌گیرند)\&. از مقدار ویژه
"none"
برای ممنوع کردن همه خانواده‌های آدرس استفاده کنید\&. این گزینه ممکن است بیش از یک بار مشخص شود که در این صورت فهرست‌های پیکربندی‌شده با یکدیگر ترکیب می‌شوند\&. اگر هم یک فهرست مثبت و هم یک فهرست منفی پیکربندی شوند، فهرست منفی بر فهرست مثبت اولویت خواهد داشت\&.
.sp
توجه داشته باشید که در حال حاضر این گزینه به صورت پیش‌فرض بدون محدودیت است، یعنی همه خانواده‌های آدرس در دسترس هستند\&. در نسخه آینده systemd، حالت پیش‌فرض تغییر خواهد کرد تا خانواده‌های آدرس به
\fBAF_INET\fR،
\fBAF_INET6\fR
و
\fBAF_UNIX\fR
محدود شوند\&. از
\fB\-\-restrict\-address\-families=\fR
(با یک آرگومان خالی) استفاده کنید یا
\fIRestrictAddressFamilies=\fR
را در یک فایل
\&.nspawn
تنظیم کنید تا صراحتاً از فیلتر کردن انصراف دهید\&.
.sp
افزوده‌شده در نسخه 261\&.
.RE
.PP
\fB\-Z\fR, \fB\-\-selinux\-context=\fR
.RS 4
زمینه امنیتی SELinux مورد استفاده برای برچسب‌گذاری فرآیندها در کانتینر را تنظیم می‌کند\&.
.sp
افزوده‌شده در نسخه 209\&.
.RE
.PP
\fB\-L\fR, \fB\-\-selinux\-apifs\-context=\fR
.RS 4
زمینه امنیتی SELinux مورد استفاده برای برچسب‌گذاری فایل‌ها در سیستم‌های فایل API مجازی در کانتینر را تنظیم می‌کند\&.
.sp
افزوده‌شده در نسخه 209\&.
.RE
.SS "گزینه‌های منابع (Resource Options)"
.PP
\fB\-\-rlimit=\fR
.RS 4
محدودیت منبع POSIX مشخص‌شده را برای بار مفید کانتینر تنظیم می‌کند\&. انتسابی به صورت
"\fILIMIT\fR=\fISOFT\fR:\fIHARD\fR"
یا
"\fILIMIT\fR=\fIVALUE\fR"
را انتظار دارد، جایی که
\fILIMIT\fR
باید به یک نوع محدودیت منبع مانند
\fBRLIMIT_NOFILE\fR
یا
\fBRLIMIT_NICE\fR
اشاره داشته باشد\&. فیلدهای
\fISOFT\fR
و
\fIHARD\fR
باید به مقادیر عددی محدودیت نرم و سخت منبع ارجاع دهند\&. اگر فرم دوم استفاده شود،
\fIVALUE\fR
ممکن است مقداری را مشخص کند که هم به عنوان محدودیت نرم و هم سخت استفاده می‌شود\&. به جای یک مقدار عددی، می‌توان از رشته ویژه
"infinity"
برای خاموش کردن محدودیت منبع برای نوع خاصی از منبع استفاده کرد\&. این گزینه خط فرمان ممکن است چندین بار برای کنترل محدودیت‌ها روی چندین نوع محدودیت استفاده شود\&. اگر چندین بار برای یک نوع محدودیت یکسان استفاده شود، آخرین استفاده برنده است\&. برای جزئیات در مورد محدودیت‌های منابع به
\fBsetrlimit\fR(2)
مراجعه کنید\&. به طور پیش‌فرض، محدودیت‌های منابع برای فرآیند آغازین کانتینر (PID 1) روی همان مقادیری تنظیم می‌شوند که هسته لینوکس در ابتدا به سیستم init میزبان تحویل داده است\&. توجه داشته باشید که برخی از محدودیت‌های منابع روی منابع شمارش‌شده به ازای هر کاربر اعمال می‌شوند، به‌ویژه
\fBRLIMIT_NPROC\fR\&.
این بدان معناست که مگر اینکه فضای‌نام کاربر به کار گرفته شده باشد (یعنی
\fB\-\-private\-users=\fR
استفاده شود، به بالا مراجعه کنید)، هرگونه محدودیت تعیین‌شده برای مصرف منابع همان کاربر در همه کانتینرهای محلی و همچنین میزبان اعمال خواهد شد\&. این بدان معناست که باید دقت ویژه‌ای در مورد این محدودیت‌ها به کار گرفته شود زیرا ممکن است توسط کدهای احتمالاً کمتر قابل‌اعتماد فعال شوند\&. مثال:
"\-\-rlimit=RLIMIT_NOFILE=8192:16384"\&.
.sp
افزوده‌شده در نسخه 239\&.
.RE
.PP
\fB\-\-oom\-score\-adjust=\fR
.RS 4
مقدار تنظیم امتیاز OOM ("خارج از حافظه") را برای بار مفید کانتینر تغییر می‌دهد\&. این گزینه
/proc/self/oom_score_adj
را کنترل می‌کند که بر اولویتی که با آن این کانتینر هنگام کمبود حافظه خاتمه می‌یابد تأثیر می‌گذارد\&. برای جزئیات به
\fBproc\fR(5)
مراجعه کنید\&. یک عدد صحیح در محدوده \-1000\&...1000 را می‌پذیرد\&.
.sp
افزوده‌شده در نسخه 239\&.
.RE
.PP
\fB\-\-cpu\-affinity=\fR
.RS 4
وابستگی پردازنده (CPU affinity) بار مفید کانتینر را کنترل می‌کند\&. فهرستی از شماره‌های پردازنده یا محدوده‌های عددی جداشده با کاما (که مقدار شروع و پایان مورد اخیر با خط تیره جدا شده است) را می‌پذیرد\&. برای جزئیات
\fBsched_setaffinity\fR(2)
را ببینید\&.
.sp
افزوده‌شده در نسخه 239\&.
.RE
.PP
\fB\-\-personality=\fR
.RS 4
معماری ("personality") گزارش‌شده توسط
\fBuname\fR(2)
در کانتینر را کنترل می‌کند\&. در حال حاضر تنها
"x86"
و
"x86\-64"
پشتیبانی می‌شوند\&. این گزینه هنگام اجرای یک کانتینر ۳۲ بیتی روی یک میزبان ۶۴ بیتی مفید است\&. اگر از این تنظیم استفاده نشود، معماری گزارش‌شده در کانتینر همان معماری گزارش‌شده روی میزبان است\&.
.sp
افزوده‌شده در نسخه 209\&.
.RE

.SS "گزینه‌های یکپارچه‌سازی (Integration Options)"
.PP
\fB\-\-resolv\-conf=\fR
.RS 4
نحوه مدیریت
/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"
را می‌پذیرد\&.
.sp
اگر روی
"off"
تنظیم شود، فایل
/etc/resolv\&.conf
در کانتینر همان‌طور که در تصویر گنجانده شده است باقی می‌ماند، و نه تغییر می‌یابد و نه چیزی روی آن bind-mount می‌شود\&.
.sp
اگر روی
"copy\-host"
تنظیم شود، فایل
/etc/resolv\&.conf
از میزبان به درون کانتینر کپی می‌شود، مگر اینکه فایل از قبل وجود داشته و یک فایل معمولی نباشد (مثلاً یک پیوند نمادین)\&. به طور مشابه، اگر
"replace\-host"
استفاده شود، فایل کپی شده و جایگزین هر اینود موجود از جمله پیوندهای نمادین می‌شود\&. به طور مشابه، اگر
"bind\-host"
استفاده شود، فایل از میزبان به درون کانتینر bind-mount می‌شود\&.
.sp
اگر روی
"copy\-static"،
"replace\-static"
یا
"bind\-static"
تنظیم شود، فایل ایستا
resolv\&.conf
ارائه‌شده با
\fBsystemd-resolved.service\fR(8)
(به طور خاص:
/usr/lib/systemd/resolv\&.conf)
به درون کانتینر کپی یا bind-mount می‌شود\&.
.sp
اگر روی
"copy\-uplink"،
"replace\-uplink"
یا
"bind\-uplink"
تنظیم شود، فایل آپ‌لینک
resolv\&.conf
مدیریت‌شده توسط
systemd\-resolved\&.service
(به طور خاص:
/run/systemd/resolve/resolv\&.conf)
به درون کانتینر کپی یا bind-mount می‌شود\&.
.sp
اگر روی
"copy\-stub"،
"replace\-stub"
یا
"bind\-stub"
تنظیم شود، فایل خرد (stub)
resolv\&.conf
مدیریت‌شده توسط
systemd\-resolved\&.service
(به طور خاص:
/run/systemd/resolve/stub\-resolv\&.conf)
به درون کانتینر کپی یا bind-mount می‌شود\&.
.sp
اگر روی
"delete"
تنظیم شود، فایل
/etc/resolv\&.conf
در کانتینر در صورت وجود حذف می‌گردد\&.
.sp
در نهایت، اگر روی
"auto"
تنظیم شود، در صورت روشن بودن شبکه‌سازی خصوصی (به
\fB\-\-private\-network\fR
مراجعه کنید) فایل به همان صورت باقی می‌ماند\&. در غیر این صورت، اگر
systemd\-resolved\&.service
در حال اجرا باشد از فایل خرد
resolv\&.conf
آن استفاده می‌شود، و اگر در حال اجرا نباشد از فایل
/etc/resolv\&.conf
میزبان استفاده می‌گردد\&. در حالت‌های اخیر، اگر تصویر قابل نوشتن باشد، فایل کپی می‌شود، و در غیر این صورت bind-mount خواهد شد\&.
.sp
توصیه می‌شود در صورتی که کانتینر باید قادر به اعمال تغییرات در پیکربندی DNS به صورت مستقل و با انحراف از تنظیمات میزبان باشد، از
"copy\-\&..."
یا
"replace\-\&..."
استفاده کنید\&. در غیر این صورت،
"bind"
ارجحیت دارد، زیرا بدین معناست که تغییرات مستقیم در
/etc/resolv\&.conf
در کانتینر مجاز نیست، زیرا یک bind-mount فقط‌خواندنی است (اما توجه داشته باشید که اگر کانتینر امتیازات کافی داشته باشد، ممکن است به سادگی اقدام به آن‌مانت کردن bind-mount کند)\&. توجه داشته باشید که چه فایل bind-mount شده باشد و چه کپی شده باشد، پس از مقداردهی اولیه زودهنگام یک‌باره، عموماً انتشار بیشتری از پیکربندی انجام نمی‌شود (این به این دلیل است که فایل معمولاً از طریق کپی کردن و تغییر نام به‌روزرسانی می‌شود)\&. پیش‌فرض
"auto"
است\&.
.sp
افزوده‌شده در نسخه 239\&.
.RE
.PP
\fB\-\-timezone=\fR
.RS 4
نحوه مدیریت
/etc/localtime
درون کانتینر (یعنی همگام‌سازی منطقه زمانی محلی از میزبان به کانتینر) را پیکربندی می‌کند\&. یکی از موارد
"off"،
"copy"،
"bind"،
"symlink"،
"delete"
یا
"auto"
را می‌پذیرد\&. اگر روی
"off"
تنظیم شود، فایل
/etc/localtime
در کانتینر همان‌طور که در تصویر گنجانده شده است باقی می‌ماند، و نه تغییر می‌یابد و نه چیزی روی آن bind-mount می‌شود\&. اگر روی
"copy"
تنظیم شود، فایل
/etc/localtime
میزبان به درون کانتینر کپی می‌شود\&. به طور مشابه، اگر
"bind"
استفاده شود، فایل از میزبان به درون کانتینر bind-mount می‌شود\&. اگر روی
"symlink"
تنظیم شود، یک پیوند نمادین ایجاد می‌شود که از
/etc/localtime
در کانتینر به فایل منطقه زمانی در کانتینر که با تنظیم منطقه زمانی روی میزبان مطابقت دارد اشاره می‌کند\&. اگر روی
"delete"
تنظیم شود، فایل موجود در کانتینر در صورت وجود حذف می‌گردد\&. اگر روی
"auto"
تنظیم شود و فایل
/etc/localtime
میزبان یک پیوند نمادین باشد، حالت
"symlink"
استفاده می‌شود، و در غیر این صورت حالت
"copy"،
مگر اینکه تصویر فقط‌خواندنی باشد که در این صورت به جای آن از
"bind"
استفاده می‌شود\&. پیش‌فرض
"auto"
است\&.
.sp
افزوده‌شده در نسخه 239\&.
.RE
.PP
\fB\-\-link\-journal=\fR
.RS 4
کنترل می‌کند که آیا ژورنال کانتینر برای سیستم میزبان قابل مشاهده باشد یا خیر\&. در صورت فعال بودن، امکان مشاهده فایل‌های ژورنال کانتینر را از میزبان (اما نه برعکس) فراهم می‌سازد\&. یکی از موارد
"no"،
"host"،
"try\-host"،
"guest"،
"try\-guest"،
"auto"
را می‌پذیرد\&. اگر
"no"
باشد، ژورنال پیوند داده نمی‌شود\&. اگر
"host"
باشد، فایل‌های ژورنال در سیستم‌فایل میزبان (در زیر
/var/log/journal/\fImachine\-id\fR)
ذخیره می‌شوند و زیردایرکتوری در همان مکان به درون کانتینر bind-mount می‌شود\&. اگر
"guest"
باشد، فایل‌های ژورنال در سیستم‌فایل مهمان (در زیر
/var/log/journal/\fImachine\-id\fR)
ذخیره می‌شوند و زیردایرکتوری در همان مکان به درون میزبان پیوند نمادین می‌شود\&.
"try\-host"
و
"try\-guest"
همین کار را انجام می‌دهند اما در صورتی که ثبت ژورنال ماندگار در میزبان فعال نباشد، یا کانتینر در حالت
\fB\-\-ephemeral\fR
باشد، با شکست مواجه نمی‌شوند\&. اگر
"auto"
(پیش‌فرض) باشد و زیردایرکتوری مناسب در
/var/log/journal
وجود داشته باشد، به درون کانتینر bind-mount می‌شود\&. اگر زیردایرکتوری وجود نداشته باشد، هیچ پیوند دادنی انجام نمی‌شود\&. در عمل، یک بار بوت کردن کانتینر با
"guest"
یا
"host"
در صورتی که در ادامه از مقدار پیش‌فرض
"auto"
استفاده شود، ژورنال را به صورت ماندگار پیوند خواهد داد\&.
.sp
توجه داشته باشید که اگر از فایل واحد الگوی
systemd\-nspawn@\&.service
استفاده شود،
\fB\-\-link\-journal=try\-guest\fR
حالت پیش‌فرض است\&.
.sp
افزوده‌شده در نسخه 187\&.
.RE
.PP
\fB\-j\fR
.RS 4
معادل
\fB\-\-link\-journal=try\-guest\fR
است\&.
.sp
افزوده‌شده در نسخه 187\&.
.RE
.PP
\fB\-\-forward\-journal=\fR
.RS 4
با راه‌اندازی
\fBsystemd-journal-remote\fR(8)
که به یک سوکت یونیکس که به درون کانتینر bind-mount شده گوش می‌دهد، ژورنال کانتینر را به میزبان هدایت می‌کند\&. سرویس
\fBsystemd-journald\fR(8)
کانتینر از طریق اعتبارنامه
\fIjournal\&.forward_to_socket\fR
به سوکت متصل شده و مدخل‌های ژورنال را به صورت بلادرنگ به میزبان ارسال می‌کند\&. مسیری به یک فایل یا دایرکتوری ژورنال را می‌پذیرد که مدخل‌های دریافت‌شده در آن ذخیره خواهند شد\&. اگر مسیر به
"\&.journal"
ختم شود، مدخل‌ها در یک فایل منفرد نوشته می‌شوند؛ در غیر این صورت مدخل‌ها به ازای هر میزبان در دایرکتوری مشخص‌شده تفکیک می‌شوند\&.
.sp
افزوده‌شده در نسخه 261\&.
.RE
.PP
\fB\-\-forward\-journal\-max\-use=\fR\fB\fIBYTES\fR\fR, \fB\-\-forward\-journal\-keep\-free=\fR\fB\fIBYTES\fR\fR, \fB\-\-forward\-journal\-max\-file\-size=\fR\fB\fIBYTES\fR\fR, \fB\-\-forward\-journal\-max\-files=\fR\fB\fIN\fR\fR
.RS 4
این گزینه‌ها تنظیمات متناظر
\fBsystemd-journal-remote\fR(8)
را هنگام هدایت مدخل‌های ژورنال از کانتینر پیکربندی می‌کنند\&. برای توضیحات این تنظیمات به
\fBjournal-remote.conf\fR(5)
مراجعه کنید\&.
.sp
افزوده‌شده در نسخه 261\&.
.RE
.SS "گزینه‌های مانت (Mount Options)"
.PP
\fB\-\-bind=\fR, \fB\-\-bind\-ro=\fR
.RS 4
یک فایل یا دایرکتوری را از میزبان به درون کانتینر bind-mount می‌کند\&. یکی از موارد زیر را می‌پذیرد: یک آرگومان مسیر \(em که در این صورت مسیر مشخص‌شده از میزبان به همان مسیر در کانتینر مانت می‌شود، یا یک جفت مسیر جداشده با دونقطه \(em که در این صورت اولین مسیر مشخص‌شده منبع در میزبان و مسیر دوم مقصد در کانتینر است، یا یک سه‌تایی جداشده با دونقطه از مسیر منبع، مسیر مقصد و گزینه‌های مانت\&. مسیر منبع ممکن است به صورت اختیاری با نویسه
"+"
پیشوندگذاری شود\&. در این صورت، مسیر منبع نسبت به دایرکتوری ریشه تصویر در نظر گرفته می‌شود\&. این امکان راه‌اندازی bind-mountها در داخل تصویر کانتینر را فراهم می‌سازد\&. مسیر منبع ممکن است به عنوان یک رشته خالی مشخص شود که در این صورت یک دایرکتوری موقت در زیر دایرکتوری
/var/tmp/
میزبان استفاده می‌شود\&. با خاموش شدن کانتینر، این دایرکتوری به طور خودکار حذف می‌گردد\&. اگر مسیر منبع مطلق نباشد، نسبت به دایرکتوری کاری جاری حل می‌شود\&. گزینه
\fB\-\-bind\-ro=\fR
مانت‌های bind فقط‌خواندنی ایجاد می‌کند\&. گریزهای بک‌اسلش تفسیر می‌شوند، بنابراین
"\e:"
می‌تواند برای تعبیه دو‌نقطه در هر یک از مسیرها استفاده شود\&. این گزینه ممکن است چندین بار برای ایجاد چندین نقطه bind-mount مستقل مشخص گردد\&.
.sp
گزینه‌های مانت با کاما جدا می‌شوند\&.
\fBrbind\fR
و
\fBnorbind\fR
ایجاد یک bind-mount بازگشتی یا معمولی را کنترل می‌کنند\&. پیش‌فرض
\fBrbind\fR
است\&.
\fBnoidmap\fR،
\fBidmap\fR،
\fBrootidmap\fR
و
\fBowneridmap\fR
نگاشت شناسه (ID mapping) را کنترل می‌کنند\&.
.sp
استفاده از
\fBidmap\fR،
\fBrootidmap\fR
یا
\fBowneridmap\fR
نیازمند پشتیبانی سیستم‌فایل مبدا از مانت‌های دارای نگاشت شناسه کاربر/گروه است\&. پیش‌فرض
\fBnoidmap\fR
است\&. با فرض
\fBx\fR
به عنوان آفست محدوده UID کانتینر،
\fBy\fR
به عنوان طول محدوده UID کانتینر، و
\fBp\fR
به عنوان UID مالک اینود منبع bind-mount روی میزبان:
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
اگر
\fBnoidmap\fR
استفاده شود، هر کاربر
\fBz\fR
در محدوده
\fB0 \&... y\fR
که از داخل کانتینر دیده می‌شود به
\fBx + z\fR
در محدوده
\fBx \&... x + y\fR
روی میزبان نگاشت می‌گردد\&. سایر کاربران میزبان به
\fBnobody\fR
در داخل کانتینر نگاشت می‌شوند\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
اگر
\fBidmap\fR
استفاده شود، هر کاربر
\fBz\fR
در محدوده UID
\fB0 \&... y\fR
که از داخل کانتینر دیده می‌شود به همان
\fBz\fR
در همان محدوده
\fB0 \&... y\fR
روی میزبان نگاشت می‌گردد\&. سایر کاربران میزبان به
\fBnobody\fR
در داخل کانتینر نگاشت می‌شوند\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
اگر
\fBrootidmap\fR
استفاده شود، کاربر
\fB0\fR
دیده شده از داخل کانتینر به
\fBp\fR
روی میزبان نگاشت می‌گردد\&. سایر کاربران میزبان به
\fBnobody\fR
در داخل کانتینر نگاشت می‌شوند\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
اگر
\fBowneridmap\fR
استفاده شود، مالک دایرکتوری مقصد در داخل کانتینر به
\fBp\fR
روی میزبان نگاشت می‌گردد\&. سایر کاربران میزبان به
\fBnobody\fR
در داخل کانتینر نگاشت می‌شوند\&.
.RE
.sp
از هر گزینه نگاشت شناسه‌ای که استفاده شود، همان نگاشت برای شناسه‌های کاربران و گروه‌ها به کار خواهد رفت\&. اگر
\fBrootidmap\fR
یا
\fBowneridmap\fR
استفاده شوند، گروه مالک دایرکتوری bind-mount شده هیچ اثری نخواهد داشت\&.
.sp
توجه داشته باشید هنگامی که این گزینه در ترکیب با
\fB\-\-private\-users\fR
استفاده می‌شود، نقاط مانت حاصل متعلق به کاربر
\fBnobody\fR
خواهند بود\&. دلیل آن این است که مانت و فایل‌ها و دایرکتوری‌های آن همچنان متعلق به کاربران و گروه‌های مربوطه در میزبان هستند که در کانتینر وجود ندارند، و بنابراین تحت UID عام 65534 (nobody) نمایش داده می‌شوند\&. اگر چنین bind-mountهایی ایجاد شوند، توصیه می‌شود آن‌ها را با استفاده از
\fB\-\-bind\-ro=\fR
به صورت فقط‌خواندنی درآورید\&. متناوباً می‌توانید از گزینه مانت "idmap" برای نگاشت شناسه‌های سیستم‌فایل استفاده کنید\&.
.sp
افزوده‌شده در نسخه 198\&.
.RE
.PP
\fB\-\-bind\-user=\fR
.RS 4
دایرکتوری خانگی (home) کاربر مشخص‌شده در میزبان را به درون کانتینر bind می‌کند\&. نام یک کاربر موجود در میزبان را به عنوان آرگومان می‌پذیرد\&. ممکن است چندین بار برای bind کردن چندین کاربر به درون کانتینر استفاده شود\&. این کار دو عمل را انجام می‌دهد:
.sp
.RS 4
.ie n \{\
\h'-04' 1.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  1." 4.2
.\}
دایرکتوری خانگی کاربر با استفاده از یک مانت با شناسه‌های نگاشت‌شده (idmapped mount) از میزبان در
/run/host/home/
bind-mount می‌شود تا UID/GID کاربر میزبان به UID/GID اختصاص‌یافته آن در کانتینر نگاشت گردد\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04' 2.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  2." 4.2
.\}
یک رکورد کاربر و گروه به فرمت JSON در
/run/userdb/
تولید می‌شود که کاربر نگاشت‌شده را توصیف می‌کند\&. این رکورد شامل یک نمایش کمینه‌شده از رکورد کاربر در میزبان است که با UID/GID و مسیر دایرکتوری خانگی اختصاص‌یافته به کاربر در کانتینر تنظیم شده است\&. ماژول NSS گلیبک
\fBnss-systemd\fR(8)
این رکوردها را از آنجا برداشته و در پایگاه‌های داده کاربر/گروه کانتینر در دسترس قرار می‌دهد\&.
.RE
.sp
ترکیب این دو عملیات فوق اطمینان می‌دهد که امکان ورود به کانتینر با استفاده از همان اطلاعات حساب کاربری موجود در میزبان وجود دارد\&. کاربر تنها به صورت موقت در حین اجرای کانتینر نگاشت می‌شود، و خود نگاشت منجر به تغییرات ماندگار در کانتینر نمی‌شود (به جز شاید پیام‌های لاگ تولیدشده در زمان ورود و موارد مشابه)\&. به ویژه توجه داشته باشید که انتساب UID/GID در کانتینر به صورت ماندگار انجام نمی‌شود\&. اگر کاربر به صورت موقت نگاشت شده باشد، بهتر است به کاربر اجازه ایجاد تغییرات ماندگار در کانتینر داده نشود\&. اگر کاربر فایل‌ها یا دایرکتوری‌هایی متعلق به خود باقی بگذارد، و آن UIDها/GIDها در طول فراخوانی‌های بعدی کانتینر (احتمالاً با یک نگاشت متفاوت
\fB\-\-bind\-user=\fR)
مجدداً استفاده شوند، آن فایل‌ها و دایرکتوری‌ها برای کاربر «جدید» قابل دسترسی خواهند بود\&.
.sp
نگاشت رکورد کاربر/گروه تنها در صورتی کار می‌کند که کانتینر حاوی systemd 249 یا جدیدتر باشد، و
\fBnss\-systemd\fR
به درستی در
nsswitch\&.conf
پیکربندی شده باشد\&. برای جزئیات به
\fBnss-systemd\fR(8)
مراجعه کنید\&.
.sp
توجه داشته باشید که رکورد کاربر منتقل‌شده از میزبان به کانتینر حاوی هش رمز عبور یونیکس کاربر خواهد بود، تا ورود بدون درز به کانتینر امکان‌پذیر باشد\&. اگر کانتینر نسبت به میزبان کمتر مورد اعتماد باشد، بنابراین استفاده از یک تابع هش قوی رمز عبور یونیکس (مانند yescrypt یا مشابه آن، با پیشوند هش
"$y$")
بسیار حائز اهمیت است\&.
.sp
هنگام bind کردن یک کاربر از میزبان به کانتینر، بررسی‌هایی انجام می‌شود تا اطمینان حاصل گردد که نام کاربری هنوز در کانتینر شناخته‌شده نیست\&. علاوه بر این، بررسی می‌شود که UID/GID تخصیص‌یافته برای آن در حال حاضر در پایگاه‌های داده کاربر/گروه کانتینر تعریف نشده باشد\&. هر دو بررسی مستقیماً به
/etc/passwd
و
/etc/group
کانتینر دسترسی دارند، و بنابراین ممکن است حساب‌های موجود در سایر پایگاه‌های داده را تشخیص ندهند\&.
.sp
افزوده‌شده در نسخه 249\&.
.RE
.PP
\fB\-\-bind\-user\-shell=\fR
.RS 4
هنگامی که با
\fB\-\-bind\-user=\fR
استفاده شود، پوسته مشخص‌شده را در رکوردهای کاربری کاربران bind شده به درون کانتینر می‌گنجاند\&. یا یک مقدار بولی یا یک مسیر مطلق را می‌پذیرد\&.
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
اگر false باشد (پیش‌فرض)، هیچ پوسته‌ای در رکوردهای کاربری برای کاربران bind شده به درون کانتینر ارسال نمی‌شود\&. این امر باعث می‌شود کاربران bind شده از پوسته پیش‌فرض کانتینر استفاده کنند\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
اگر true باشد، پوسته‌های مشخص‌شده توسط رکوردهای کاربر در میزبان در رکوردهای کاربری تمام کاربران bind شده به کانتینر گنجانده می‌شوند\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
در صورت ارسال یک مسیر مطلق، آن مسیر را به عنوان پوسته برای رکوردهای کاربری تمام کاربران bind شده به کانتینر تنظیم می‌کند\&.
.RE
.sp
نکته: این گزینه وجود پوسته‌های مشخص‌شده در کانتینر را بررسی نخواهد کرد\&.
.sp
این عملیات تنها در ترکیب با
\fB\-\-bind\-user=\fR
پشتیبانی می‌شود\&.
.sp
افزوده‌شده در نسخه 258\&.
.RE
.PP
\fB\-\-bind\-user\-group=\fR\fB\fINAME\fR\fR
.RS 4
هنگامی که با
\fB\-\-bind\-user=\fR
استفاده شود، گروه مشخص‌شده را به عنوان یک گروه کمکی در رکوردهای کاربری کاربران bind شده به کانتینر می‌گنجاند\&. یک نام گروه را می‌پذیرد\&.
.sp
نکته: این گزینه وجود گروه‌های مشخص‌شده در کانتینر را بررسی نخواهد کرد\&.
.sp
این عملیات تنها در ترکیب با
\fB\-\-bind\-user=\fR
پشتیبانی می‌شود\&.
.sp
افزوده‌شده در نسخه 259\&.
.RE
.PP
\fB\-\-inaccessible=\fR
.RS 4
مسیر مشخص‌شده را در کانتینر غیرقابل دسترسی می‌کند\&. این کار با اور‌مانت کردن مسیر مشخص‌شده (که باید در کانتینر وجود داشته باشد) با یک گره فایل خالی از همان نوع که محدودکننده‌ترین حالت دسترسی پشتیبانی‌شده را دارد انجام می‌شود\&. این یک روش مؤثر برای ماسک کردن فایل‌ها، دایرکتوری‌ها و سایر اشیاء سیستم‌فایل از بار مفید کانتینر است\&. در صورتی که نیاز به ماسک کردن چند مسیر باشد، این گزینه ممکن است بیش از یک بار استفاده شود\&.
.sp
افزوده‌شده در نسخه 242\&.
.RE
.PP
\fB\-\-tmpfs=\fR
.RS 4
یک سیستم‌فایل tmpfs را به درون کانتینر مانت می‌کند\&. یک آرگومان مسیر مطلق منفرد را می‌پذیرد که محل مانت کردن نمونه tmpfs را مشخص می‌نماید (که در این حالت حالت دسترسی دایرکتوری 0755 و متعلق به root/root انتخاب می‌شود)، یا به صورت اختیاری یک جفت مسیر و رشته گزینه مانت جداشده با دونقطه که برای مانت استفاده می‌شود (که در این حالت پیش‌فرض هسته برای حالت دسترسی و مالک انتخاب خواهد شد، مگر اینکه طور دیگری مشخص شده باشد)\&. گریزهای بک‌اسلش در مسیر تفسیر می‌شوند، بنابراین
"\e:"
می‌تواند برای تعبیه دو‌نقطه در مسیر استفاده شود\&.
.sp
توجه داشته باشید که این گزینه نمی‌تواند برای جایگزینی سیستم‌فایل ریشه کانتینر با یک سیستم‌فایل موقت استفاده شود\&. با این حال، گزینه
\fB\-\-volatile=\fR
که در زیر توضیح داده شده است عملکرد مشابهی را با تمرکز بر پیاده‌سازی تصاویر سیستم‌عامل بدون وضعیت (stateless) ارائه می‌دهد\&.
.sp
افزوده‌شده در نسخه 214\&.
.RE
.PP
\fB\-\-overlay=\fR, \fB\-\-overlay\-ro=\fR
.RS 4
چندین درخت دایرکتوری را در یک سیستم‌فایل هم‌پوشان (overlay) ترکیب کرده و آن را به درون کانتینر مانت می‌کند\&. فهرستی از مسیرهای جداشده با دونقطه به درخت‌های دایرکتوری جهت ترکیب و نقطه مانت مقصد را می‌پذیرد\&.
.sp
گریزهای بک‌اسلش در مسیرها تفسیر می‌شوند، بنابراین
"\e:"
می‌تواند برای تعبیه دو‌نقطه در مسیرها استفاده شود\&.
.sp
اگر سه یا چند مسیر مشخص شوند، آخرین مسیر مشخص‌شده نقطه مانت مقصد در کانتینر است، و تمام مسیرهای مشخص‌شده قبل از آن به درخت‌های دایرکتوری در میزبان ارجاع دارند و به ترتیب مشخص‌شده در یک سیستم‌فایل overlay ترکیب می‌شوند\&. بنابراین، چپ‌ترین مسیر پایین‌ترین درخت دایرکتوری، و مسیر ماقبل آخر بالاترین درخت دایرکتوری در ترتیب چیدمان پشته است\&. اگر به جای
\fB\-\-overlay=\fR
از
\fB\-\-overlay\-ro=\fR
استفاده شود، یک سیستم‌فایل overlay فقط‌خواندنی ایجاد می‌شود\&. اگر یک سیستم‌فایل overlay قابل نوشتن ایجاد شود، تمام تغییرات اعمال‌شده در آن در بالاترین درخت دایرکتوری در ترتیب چیدمان پشته، یعنی مسیر ماقبل آخر مشخص‌شده، نوشته می‌شوند\&.
.sp
اگر تنها دو مسیر مشخص شوند، دومین مسیر مشخص‌شده هم به عنوان بالاترین درخت دایرکتوری در ترتیب پشته همان‌طور که از میزبان دیده می‌شود، و هم به عنوان نقطه مانت برای سیستم‌فایل overlay در کانتینر استفاده خواهد شد\&. حداقل باید دو مسیر مشخص شود\&.
.sp
مسیرهای منبع ممکن است به صورت اختیاری با نویسه
"+"
پیشوندگذاری شوند\&. در این صورت آن‌ها نسبت به دایرکتوری ریشه تصویر در نظر گرفته می‌شوند\&. بالاترین مسیر منبع نیز ممکن است به عنوان یک رشته خالی مشخص شود، که در این صورت یک دایرکتوری موقت در زیر
/var/tmp/
میزبان استفاده می‌شود\&. دایرکتوری با خاموش شدن کانتینر به طور خودکار حذف می‌گردد\&. این رفتار برای قابل‌نوشتن کردن دایرکتوری‌های فقط‌خواندنی کانتینر در حین اجرای کانتینر مفید است\&. برای مثال، از
"\-\-overlay=+/var::/var"
استفاده کنید تا به طور خودکار یک دایرکتوری موقت قابل نوشتن را روی یک دایرکتوری فقط‌خواندنی
/var/
هم‌پوشانی نماید\&. اگر یک مسیر منبع مطلق نباشد، نسبت به دایرکتوری کاری جاری حل می‌شود\&.
.sp
برای جزئیات در مورد سیستم‌های فایل overlay،
\m[blue]\fBOverlay Filesystem\fR\m[]\&\s-2\u[5]\d\s+2
را ببینید\&. توجه داشته باشید که معانی سیستم‌های فایل overlay به طور قابل توجهی با سیستم‌های فایل معمولی متفاوت است، به ویژه در رابطه با اطلاعات گزارش‌شده دستگاه و اینود\&. اطلاعات دستگاه و اینود ممکن است برای یک فایل در حین نوشتن روی آن تغییر کند، و فرآیندها ممکن است گاهی نسخه‌های قدیمی فایل‌ها را مشاهده کنند\&. توجه داشته باشید که این سوئیچ به طور خودکار گزینه مانت
"workdir="
را برای سیستم‌فایل overlay از بالاترین درخت دایرکتوری مشتق می‌کند و آن را هم‌سطح (هم‌نیا) با آن قرار می‌دهد\&. بنابراین ضروری است که بالاترین درخت دایرکتوری خود یک نقطه مانت نباشد (زیرا دایرکتوری کاری باید روی همان سیستم‌فایلی باشد که بالاترین درخت دایرکتوری قرار دارد)\&. همچنین توجه داشته باشید که گزینه مانت
"lowerdir="
مسیرهای پشته را با ترتیبی معکوس نسبت به این سوئیچ دریافت می‌کند\&.
.sp
توجه داشته باشید که این گزینه نمی‌تواند برای جایگزینی سیستم‌فایل ریشه کانتینر با یک سیستم‌فایل overlay استفاده شود\&. با این حال، گزینه
\fB\-\-volatile=\fR
توضیح داده شده در بالا قابلیت مشابهی را با تمرکز بر پیاده‌سازی تصاویر سیستم‌عامل بدون وضعیت فراهم می‌کند\&.
.sp
افزوده‌شده در نسخه 220\&.
.RE
.SS "گزینه‌های ورودی/خروجی (Input/Output Options)"
.PP
\fB\-\-console=\fR\fB\fIMODE\fR\fR
.RS 4
نحوه راه‌اندازی ورودی، خروجی و خروجی خطای استاندارد را برای بار مفید کانتینر و همچنین دستگاه
/dev/console
برای کانتینر پیکربندی می‌کند\&. یکی از مقادیر
\fBinteractive\fR،
\fBread\-only\fR،
\fBpassive\fR،
\fBpipe\fR
یا
\fBautopipe\fR
را می‌پذیرد\&. اگر
\fBinteractive\fR
باشد، یک pseudo\-TTY تخصیص یافته و به عنوان
/dev/console
در کانتینر در دسترس قرار می‌گیرد\&. سپس به صورت دوطرفه به ورودی و خروجی استاندارد ارسال‌شده به
\fBsystemd\-nspawn\fR
متصل می‌شود\&.
\fBread\-only\fR
مشابه است اما تنها خروجی کانتینر منتشر می‌شود و هیچ ورودی از فراخواننده خوانده نخواهد شد\&. اگر
\fBpassive\fR
باشد، یک pseudo TTY تخصیص می‌یابد، اما به جایی متصل نمی‌شود\&. در حالت
\fBpipe\fR
هیچ pseudo TTY تخصیص نمی‌یابد، اما توصیف‌کننده‌های فایل ورودی، خروجی و خروجی خطای استاندارد ارسال‌شده به
\fBsystemd\-nspawn\fR
\(em همان‌طور که هستند \(em به بار مفید کانتینر منتقل می‌شوند، بند بعدی را ببینید\&. در نهایت، حالت
\fBautopipe\fR
هنگامی که
\fBsystemd\-nspawn\fR
روی یک ترمینال فراخوانی شود مانند
\fBinteractive\fR
عمل می‌کند، و در غیر این صورت مانند
\fBpipe\fR\&.
اگر
\fBsystemd\-nspawn\fR
از یک ترمینال فراخوانی شود، پیش‌فرض
\fBinteractive\fR
است، و در غیر این صورت
\fBread\-only\fR\&.
.sp
در حالت
\fBpipe\fR،
دستگاه
/dev/console
در کانتینر وجود نخواهد داشت\&. این بدان معناست که بار مفید کانتینر عموماً نمی‌تواند یک سیستم init کامل باشد زیرا سیستم‌های init تمایل دارند به در دسترس بودن
/dev/console
وابسته باشند\&. از سوی دیگر، در این حالت فراخوانی‌های کانتینر می‌توانند در خط لوله‌های پوسته (shell pipelines) استفاده شوند\&. دلیل آن این است که pseudo TTYهای واسط اجازه انتشار دوطرفه مستقل وضعیت پایان فایل (EOF) را نمی‌دهند، که برای عملکرد صحیح خط لوله‌های پوسته ضروری است\&.
\fIتوجه داشته باشید که حالت \fR\fI\fBpipe\fR\fR\fI باید با احتیاط استفاده شود\fR،
زیرا ارسال توصیف‌کننده‌های فایل دلخواه به بارهای مفید کانتینر با قابلیت اطمینان کمتر ممکن است واسط‌های ناخواسته‌ای را برای دسترسی بار مفید کانتینر باز کند\&. به عنوان مثال، اگر یک توصیف‌کننده فایل ارسال‌شده به نوعی از TTY ارجاع دهد، APIهایی مانند
\fBTIOCSTI\fR
ممکن است برای ترکیب ورودی که ممکن است برای گریز از کانتینر استفاده شود، به کار روند\&. از این رو حالت
\fBpipe\fR
تنها باید در صورتی استفاده شود که بار مفید به اندازه کافی قابل اعتماد باشد یا زمانی که توصیف‌کننده‌های فایل ورودی/خروجی/خروجی خطای استاندارد به عنوان موارد ایمن، به عنوان مثال پایپ‌ها، شناخته شده باشند\&.
.sp
افزوده‌شده در نسخه 242\&.
.RE
.PP
\fB\-\-pipe\fR, \fB\-P\fR
.RS 4
معادل
\fB\-\-console=pipe\fR
است\&.
.sp
افزوده‌شده در نسخه 242\&.
.RE
.PP
\fB\-\-background=\fR\fB\fICOLOR\fR\fR
.RS 4
رنگ پس‌زمینه ترمینال را تا زمانی که کانتینر اجرا می‌شود به رنگ ANSI مشخص‌شده تغییر می‌دهد\&. رنگ مشخص‌شده باید یک رنگ پس‌زمینه ANSI X3\&.64 SGR باشد، یعنی رشته‌هایی مانند
"40"،
"41"،
\&...،
"47"،
"48;2;\&..."،
"48;5;\&..."\&.
برای جزئیات،
\m[blue]\fBANSI Escape Code (Wikipedia)\fR\m[]\&\s-2\u[6]\d\s+2
را ببینید\&. یک رشته خالی برای غیرفعال کردن هرگونه رنگ‌آمیزی اختصاص دهید\&.
.sp
افزوده‌شده در نسخه 256\&.
.RE
.SS "اعتبارنامه‌ها (Credentials)"
.PP
\fB\-\-load\-credential=\fR\fB\fIID\fR\fR\fB:\fR\fB\fIPATH\fR\fR, \fB\-\-set\-credential=\fR\fB\fIID\fR\fR\fB:\fR\fB\fIVALUE\fR\fR
.RS 4
یک اعتبارنامه را به کانتینر ارسال می‌کند\&. این دو گزینه متناظر با تنظیمات
\fILoadCredential=\fR
و
\fISetCredential=\fR
در فایل‌های واحد هستند\&. برای جزئیات در مورد این مفاهیم و همچنین نحو آرگومان‌های این گزینه، به
\fBsystemd.exec\fR(5)
مراجعه کنید\&.
.sp
نکته: هنگامی که
\fBsystemd\-nspawn\fR
به عنوان سرویس سیستمی systemd اجرا می‌شود، می‌تواند اعتبارنامه‌هایی را که از طریق
\fILoadCredential=\fR/\fISetCredential=\fR
دریافت کرده است به بار مفید کانتینر منتقل کند\&. یک مدیر سرویس systemd که به عنوان PID 1 در کانتینر اجرا می‌شود می‌تواند آن‌ها را بیشتر به سرویس‌هایی که خود راه‌اندازی می‌کند منتقل نماید\&. بنابراین می‌توان به راحتی اعتبارنامه‌ها را از یک مدیر سرویس والد به یک سرویس مدیر کانتینر و از آنجا به بار مفید آن منتقل کرد\&. این کار حتی می‌تواند به صورت بازگشتی انجام شود\&.
.sp
به منظور تعبیه داده‌های دودویی در داده‌های اعتبارنامه برای
\fB\-\-set\-credential=\fR،
از گریزهای سبک C استفاده کنید (یعنی
"\en"
برای تعبیه یک خط جدید، یا
"\ex00"
برای تعبیه یک بایت
\fBNUL\fR)\&.
توجه داشته باشید که پوسته فراخواننده ممکن است قبلاً یک بار گریززدایی را اعمال کرده باشد، بنابراین ممکن است به گریز مضاعف نیاز باشد!
.sp
سرویس‌های
\fBsystemd-sysusers.service\fR(8)
و
\fBsystemd-firstboot\fR(1)
اعتبارنامه‌های پیکربندی‌شده از این طریق را به منظور پیکربندی رمز عبور و پوسته کاربر ریشه کانتینر و همچنین محلی‌سازی (locale)، نگاشت کلید و منطقه زمانی سیستم در طول فرآیند اولین بوت کانتینر می‌خوانند\&. این امر به ویژه در ترکیب با
\fB\-\-volatile=yes\fR
مفید است که در آن هر بوت منفرد به عنوان اولین بوت به نظر می‌رسد، زیرا پیکربندی اعمال‌شده در
/etc/
در چرخه‌های راه‌اندازی مجدد کانتینر از بین می‌رود\&. برای جزئیات به صفحات راهنمای مربوطه مراجعه کنید\&. مثال:
.sp
.if n \{\
.RS 4
.\}
.nf
# systemd\-nspawn \-i image\&.raw \e
          \-\-volatile=yes \e
          \-\-set\-credential=firstboot\&.locale:de_DE\&.UTF\-8 \e
          \-\-set\-credential=passwd\&.hashed\-password\&.root:\*(Aq$y$j9T$yAuRJu1o5HioZAGDYPU5d\&.$F64ni6J2y2nNQve90M/p0ZP0ECP/qqzipNyaY9fjGpC\*(Aq \e
          \-b
.fi
.if n \{\
.RE
.\}
.sp
خط فرمان فوق فایل تصویر مشخص‌شده
image\&.raw
را در حالت فرار فراخوانی می‌کند، یعنی با
/etc/
و
/var/
خالی\&. بار مفید کانتینر این مورد را به عنوان اولین بوت تشخیص می‌دهد و
systemd\-firstboot\&.service
را فراخوانی می‌کند که سپس دو اعتبارنامه ارائه‌شده را برای پیکربندی محلی‌سازی اولیه سیستم و رمز عبور ریشه می‌خواند\&.
.sp
افزوده‌شده در نسخه 247\&.
.RE
.SS "سایر گزینه‌ها (Other)"
.PP
\fB\-\-system\fR, \fB\-\-user\fR
.RS 4
اجرا در دامنه سیستم یا کاربر را مشخص می‌کند\&. این گزینه کنترل می‌کند که با کدام مدیر سرویس و نمونه machined تعامل داشته باشد، و همچنین پیش‌فرض‌های عملیاتی مانند حالت فضای‌نام کاربر و شبکه‌سازی خصوصی را تعیین می‌نماید\&. اگر هیچ‌کدام مشخص نشوند، هنگام اجرا به عنوان root گزینه
\fB\-\-system\fR
و در غیر این صورت
\fB\-\-user\fR
به صورت ضمنی اعمال می‌شود\&.
.sp
نکته: برای سازگاری به عقب،
\fB\-\-user\fR
که به دنبال آن یک آرگومان موقعیتی بیاید به عنوان فرم منسوخ‌شده
\fB\-\-user=\fR\fB\fINAME\fR\fR
(اکنون
\fB\-\-uid=\fR)
تفسیر می‌شود\&. برای استفاده از
\fB\-\-user\fR
جهت انتخاب دامنه هنگامی که آرگومان‌های موقعیتی در ادامه می‌آیند، آن‌ها را با
"\-\-"
جدا کنید\&.
.sp
افزوده‌شده در نسخه 261\&.
.RE
.PP
\fB\-\-no\-pager\fR
.RS 4
خروجی را به یک صفحه‌بند لوله‌کشی نمی‌کند\&.
.RE
.PP
\fB\-h\fR, \fB\-\-help\fR
.RS 4
یک متن راهنمای کوتاه را چاپ کرده و خارج می‌شود\&.
.RE
.PP
\fB\-\-version\fR
.RS 4
یک رشته کوتاه نسخه برنامه را چاپ کرده و خارج می‌شود\&.
.RE
.PP
\fB\-\-no\-ask\-password\fR
.RS 4
برای عملیات دارای امتیاز ویژه از کاربر درخواست احراز هویت نمی‌کند\&.
.RE

.SH "کلیدهای میانبر (HOTKEYS)"
.PP
هنگامی که در حالت تعاملی فراخوانی شود (یعنی حالت پیش‌فرض
\fB\-\-console=interactive\fR)،
چند میانبر صفحه‌کلید ویژه که زمان اجرای کانتینر را کنترل می‌کنند، درک می‌شوند\&. این میانبرها باید در عرض ۱ ثانیه تایپ شوند تا اثرگذار باشند، در غیر این صورت به عنوان فشردن کلید معمولی به کانتینر ارسال خواهند شد\&.
.PP
Ctrl\-] Ctrl\-] Ctrl\-]
.RS 4
کانتینر را بلافاصله خاتمه داده و تمام فرآیندها را متوقف می‌کند\&.
.RE
.PP
Ctrl\-] Ctrl\-] r
.RS 4
یک درخواست راه‌اندازی مجدد (reboot) به کانتینر ارسال می‌کند\&.
.sp
افزوده‌شده در نسخه 258\&.
.RE
.PP
Ctrl\-] Ctrl\-] p
.RS 4
یک درخواست خاموش شدن (shutdown) به کانتینر ارسال می‌کند\&.
.sp
افزوده‌شده در نسخه 258\&.
.RE
.SH "محیط (ENVIRONMENT)"
.PP
\fI$SYSTEMD_LOG_LEVEL\fR
.RS 4
حداکثر سطح لاگ پیام‌های منتشرشده (پیام‌های با سطح لاگ بالاتر، یعنی کم‌اهمیت‌تر، متوقف خواهند شد)\&. فهرستی از مقادیر جداشده با کاما را می‌پذیرد\&. یک مقدار می‌تواند یکی از موارد زیر (به ترتیب کاهش اهمیت) باشد:
\fBemerg\fR،
\fBalert\fR،
\fBcrit\fR،
\fBerr\fR،
\fBwarning\fR،
\fBnotice\fR،
\fBinfo\fR،
\fBdebug\fR،
یا یک عدد صحیح در محدوده 0\&...7\&. برای اطلاعات بیشتر
\fBsyslog\fR(3)
را ببینید\&. هر مقدار می‌تواند به صورت اختیاری با یکی از پیشوندهای
\fBconsole\fR،
\fBsyslog\fR،
\fBkmsg\fR
یا
\fBjournal\fR
همراه با یک دونقطه مشخص شود تا حداکثر سطح لاگ را برای آن مقصد خاص لاگ تنظیم کند (به عنوان مثال
\fBSYSTEMD_LOG_LEVEL=debug,console:info\fR
مشخص می‌کند که لاگ در سطح debug ثبت شود مگر در هنگام ارسال لاگ به کنسول که باید در سطح info باشد)\&. توجه داشته باشید که حداکثر سطح لاگ سراسری بر هر حداکثر سطح لاگ اختصاصی مقصد اولویت دارد\&.
.RE
.PP
\fI$SYSTEMD_LOG_COLOR\fR
.RS 4
یک مقدار بولی\&. اگر true باشد، پیام‌های نوشته‌شده در tty بر اساس اولویت رنگ‌آمیزی می‌شوند\&.
.sp
این تنظیم تنها زمانی مفید است که پیام‌ها مستقیماً در ترمینال نوشته شوند، زیرا
\fBjournalctl\fR(1)
و سایر ابزارهایی که لاگ‌ها را نمایش می‌دهند، پیام‌ها را خود بر اساس سطح لاگ رنگ‌آمیزی می‌کنند\&.
.RE
.PP
\fI$SYSTEMD_LOG_TIME\fR
.RS 4
یک مقدار بولی\&. اگر true باشد، پیام‌های لاگ کنسول با یک برچسب زمانی پیشوندگذاری می‌شوند\&.
.sp
این تنظیم تنها زمانی مفید است که پیام‌ها مستقیماً در ترمینال یا یک فایل نوشته شوند، زیرا
\fBjournalctl\fR(1)
و سایر ابزارهایی که لاگ‌ها را نمایش می‌دهند، خود برچسب‌های زمانی را بر اساس فراداده‌های مدخل پیوست می‌کنند\&.
.RE
.PP
\fI$SYSTEMD_LOG_LOCATION\fR
.RS 4
یک مقدار بولی\&. اگر true باشد، پیام‌ها با نام فایل و شماره خط در کد منبع که پیام از آن سرچشمه می‌گیرد، پیشوندگذاری می‌شوند\&.
.sp
توجه داشته باشید که محل لاگ در هر صورت اغلب به عنوان فراداده به مدخل‌های ژورنال پیوست می‌شود\&. با این حال، گنجاندن مستقیم آن در متن پیام می‌تواند در هنگام اشکال‌زدایی برنامه‌ها سودمند باشد\&.
.RE
.PP
\fI$SYSTEMD_LOG_TID\fR
.RS 4
یک مقدار بولی\&. اگر true باشد، پیام‌ها با شناسه عددی رشته (TID) جاری پیشوندگذاری می‌شوند\&.
.sp
توجه داشته باشید که این اطلاعات در هر صورت به عنوان فراداده به مدخل‌های ژورنال پیوست می‌شود\&. با این حال، گنجاندن مستقیم آن در متن پیام می‌تواند در هنگام اشکال‌زدایی برنامه‌ها سودمند باشد\&.
.RE
.PP
\fI$SYSTEMD_LOG_TARGET\fR
.RS 4
مقصد پیام‌های لاگ\&. یکی از موارد
\fBconsole\fR
(ثبت در tty متصل‌شده)،
\fBconsole\-prefixed\fR
(ثبت در tty متصل‌شده اما با پیشوندهایی که سطح لاگ و "facility" را کدگذاری می‌کنند،
\fBsyslog\fR(3)
را ببینید)،
\fBkmsg\fR
(ثبت در بافر حلقوی لاگ هسته)،
\fBjournal\fR
(ثبت در ژورنال)،
\fBjournal\-or\-kmsg\fR
(ثبت در ژورنال در صورت موجود بودن، و در غیر این صورت در kmsg)،
\fBauto\fR
(تعیین خودکار مقصد لاگ مناسب، حالت پیش‌فرض)،
\fBnull\fR
(غیرفعال کردن خروجی لاگ)\&.
.RE
.PP
\fI$SYSTEMD_LOG_RATELIMIT_KMSG\fR
.RS 4
کنترل می‌کند که آیا نرخ ارسال پیام به kmsg محدود شود یا خیر\&. یک مقدار بولی را می‌پذیرد\&. مقدار پیش‌فرض
"true"
است\&. در صورت غیرفعال بودن، systemd نرخ پیام‌های نوشته‌شده در kmsg را محدود نخواهد کرد\&.
.RE
.PP
\fI$SYSTEMD_PAGER\fR, \fI$PAGER\fR
.RS 4
صفحه‌بندی که هنگام مشخص نشدن
\fB\-\-no\-pager\fR
استفاده می‌شود\&. در صورت تنظیم بودن
\fI$SYSTEMD_PAGER\fR
از آن استفاده می‌شود؛ در غیر این صورت
\fI$PAGER\fR
استفاده می‌گردد\&. اگر نه
\fI$SYSTEMD_PAGER\fR
و نه
\fI$PAGER\fR
تنظیم نشده باشند، مجموعه‌ای از پیاده‌سازی‌های شناخته‌شده صفحه‌بند به نوبت آزمایش می‌شوند، از جمله
\fBless\fR(1)
و
\fBmore\fR(1)،
تا زمانی که یکی یافت شود\&. اگر هیچ پیاده‌سازی صفحه‌بندی کشف نشود، هیچ صفحه‌بندی فراخوانی نخواهد شد\&. تنظیم این متغیرهای محیطی روی یک رشته خالی یا مقدار
"cat"
معادل ارسال
\fB\-\-no\-pager\fR
است\&.
.sp
نکته: اگر
\fI$SYSTEMD_PAGERSECURE\fR
تنظیم نشده باشد،
\fI$SYSTEMD_PAGER\fR
و
\fI$PAGER\fR
تنها می‌توانند برای غیرفعال کردن صفحه‌بند (با
"cat"
یا
"")
استفاده شوند، و در غیر این صورت نادیده گرفته می‌شوند\&.
.RE
.PP
\fI$SYSTEMD_LESS\fR
.RS 4
بازنویسی گزینه‌های ارسال‌شده به
\fBless\fR
(به طور پیش‌فرض
"FRSXMK")\&.
.sp
کاربران ممکن است به ویژه تمایل داشته باشند دو گزینه را تغییر دهند:
.PP
\fBK\fR
.RS 4
این گزینه به صفحه‌بند دستور می‌دهد که با فشردن
Ctrl+C
بلافاصله خارج شود\&. برای اجازه دادن به
\fBless\fR
جهت مدیریت
Ctrl+C
توسط خود برای بازگشت به خط فرمان صفحه‌بند، این گزینه را حذف کنید\&.
.sp
اگر مقدار
\fI$SYSTEMD_LESS\fR
شامل
"K"
نباشد و صفحه‌بند فراخوانی‌شده
\fBless\fR
باشد،
Ctrl+C
توسط برنامه اجرایی نادیده گرفته می‌شود و باید توسط صفحه‌بند مدیریت گردد\&.
.RE
.PP
\fBX\fR
.RS 4
این گزینه به صفحه‌بند دستور می‌دهد رشته‌های مقداردهی اولیه و لغو مقداردهی اولیه termcap را به ترمینال ارسال نکند\&. این گزینه به طور پیش‌فرض تنظیم شده است تا خروجی دستور حتی پس از خروج از صفحه‌بند در ترمینال قابل مشاهده باقی بماند\&. با این وجود، این کار مانع از عملکرد برخی از قابلیت‌های صفحه‌بند می‌شود، به ویژه خروجی صفحه‌بندی‌شده را نمی‌توان با ماوس پیمایش کرد\&.
.RE
.sp
توجه داشته باشید که تنظیم متغیر محیطی معمولی
\fI$LESS\fR
هیچ تاثیری بر فراخوانی‌های
\fBless\fR
توسط ابزارهای systemd ندارد\&.
.sp
برای بحث بیشتر
\fBless\fR(1)
را ببینید\&.
.RE
.PP
\fI$SYSTEMD_LESSCHARSET\fR
.RS 4
بازنویسی مجموعه نویسه ارسال‌شده به
\fBless\fR
(به طور پیش‌فرض
"utf\-8"،
اگر ترمینال فراخواننده سازگار با UTF\-8 تشخیص داده شود)\&.
.sp
توجه داشته باشید که تنظیم متغیر محیطی معمولی
\fI$LESSCHARSET\fR
هیچ تاثیری بر فراخوانی‌های
\fBless\fR
توسط ابزارهای systemd ندارد\&.
.RE
.PP
\fI$SYSTEMD_PAGERSECURE\fR
.RS 4
دستورات رایج صفحه‌بند مانند
\fBless\fR(1)،
علاوه بر «صفحه‌بندی»، یعنی پیمایش در خروجی، از باز کردن یا نوشتن در فایل‌های دیگر و اجرای دستورات دلخواه پوسته پشتیبانی می‌کنند\&. هنگامی که دستورات با امتیازات بالا، مثلاً تحت
\fBsudo\fR(8)
یا
\fBpkexec\fR(1)
فراخوانی می‌شوند، صفحه‌بند به یک مرز امنیتی تبدیل می‌شود\&. باید دقت شود که تنها برنامه‌های با قابلیت‌های کاملاً محدود به عنوان صفحه‌بند استفاده شوند و ویژگی‌های تعاملی ناخواسته مانند باز کردن یا ایجاد فایل‌های جدید یا راه‌اندازی زیرفرآیندها مجاز نباشند\&. «حالت امن» برای صفحه‌بند ممکن است همان‌طور که در زیر توضیح داده شده فعال شود،
\fIاگر صفحه‌بند از آن پشتیبانی کند\fR
(بیشتر صفحه‌بندها به گونه‌ای نوشته نشده‌اند که این موضوع را در نظر بگیرند)\&. توصیه می‌شود در هنگام اجازه دادن به کاربران غیرقابل‌اعتماد برای اجرای دستورات با دسترسی‌های بالا، یا «حالت امن» را صراحتاً فعال کنید یا صفحه‌بند را با استفاده از
\fB\-\-no\-pager\fR
یا
\fIPAGER=cat\fR
به طور کامل غیرفعال نمایید\&.
.sp
این گزینه یک آرگومان بولی می‌پذیرد\&. در صورت تنظیم روی true، «حالت امن» صفحه‌بند فعال می‌شود\&. در «حالت امن»،
\fBLESSSECURE=1\fR
هنگام فراخوانی صفحه‌بند تنظیم خواهد شد که به صفحه‌بند دستور می‌دهد دستوراتی را که فایل‌های جدید باز می‌کنند یا ایجاد می‌نمایند یا زیرفرآیندهای جدیدی را آغاز می‌کنند غیرفعال کند\&. در حال حاضر تنها
\fBless\fR(1)
شناخته شده است که این متغیر را درک کرده و «حالت امن» را پیاده‌سازی می‌کند\&.
.sp
در صورت تنظیم روی false، هیچ محدودیتی بر روی صفحه‌بند اعمال نمی‌شود\&. تنظیم
\fISYSTEMD_PAGERSECURE=0\fR
یا حذف نکردن آن از محیط به ارث رسیده ممکن است به کاربر اجازه دهد دستورات دلخواه را فراخوانی کند\&.
.sp
هنگامی که
\fI$SYSTEMD_PAGERSECURE\fR
تنظیم نشده باشد، ابزارهای systemd تلاش می‌کنند به طور خودکار تشخیص دهند که آیا «حالت امن» باید فعال شود و آیا صفحه‌بند از آن پشتیبانی می‌کند یا خیر\&. «حالت امن» فعال می‌شود اگر UID موثر با مالک نشست ورود یکسان نباشد،
\fBgeteuid\fR(2)
و
\fBsd_pid_get_owner_uid\fR(3)
را ببینید، یا هنگام اجرا تحت
\fBsudo\fR(8)
یا ابزارهای مشابه (که در آن‌ها
\fI$SUDO_UID\fR
تنظیم شده است
\&\s-2\u[7]\d\s+2)\&.
در این موارد،
\fISYSTEMD_PAGERSECURE=1\fR
تنظیم خواهد شد و صفحه‌بندهایی که شناخته نشده‌اند «حالت امن» را پیاده‌سازی کنند اصلاً استفاده نخواهند شد\&. توجه داشته باشید که این تشخیص خودکار تنها رایج‌ترین سازوکارها را برای ارتقای امتیاز پوشش می‌دهد و به عنوان یک تسهیل در نظر گرفته شده است\&. توصیه می‌شود که صراحتاً
\fI$SYSTEMD_PAGERSECURE\fR
را تنظیم کرده یا صفحه‌بند را غیرفعال کنید\&.
.sp
توجه داشته باشید که اگر قرار است متغیرهای
\fI$SYSTEMD_PAGER\fR
یا
\fI$PAGER\fR
به جز برای غیرفعال کردن صفحه‌بند رعایت شوند،
\fI$SYSTEMD_PAGERSECURE\fR
نیز باید تنظیم شده باشد\&.
.RE
.PP
\fI$SYSTEMD_COLORS\fR
.RS 4
یک آرگومان بولی یا یک مقدار خاص را می‌پذیرد\&. به طور پیش‌فرض (تنظیم‌نشده)،
\fBsystemd\fR
و ابزارهای وابسته در صورت امکان از رنگ‌ها در خروجی خود استفاده خواهند کرد\&. اگر
\fI$COLORTERM\fR
روی
"truecolor"
یا
"24bit"
تنظیم شده باشد، رنگ‌های ۲۴ بیتی فعال می‌شوند، در غیر این صورت ۲۵۶ رنگ فعال خواهد شد، مگر اینکه
\fI$NO_COLOR\fR
یا
\fI$TERM\fR
نشان دهد که رنگ‌ها غیرفعال هستند\&.
.PP
\fBtrue\fR
.RS 4
همانند حالت تنظیم‌نشده است، با این تفاوت که
\fI$NO_COLOR\fR
نادیده گرفته می‌شود\&.
.RE
.PP
\fBfalse\fR
.RS 4
خروجی تک‌رنگ خواهد بود\&.
.RE
.PP
"16", "256", "24bit"
.RS 4
به ترتیب همیشه از ۱۶ رنگ پایه ANSI، ۲۵۶ رنگ یا رنگ ۲۴ بیتی استفاده می‌کند\&.
.RE
.PP
"auto\-16", "auto\-256", "auto\-24bit"
.RS 4
از تعداد رنگ‌های داده‌شده با توجه به
\fI$TERM\fR
و آنچه کنسول به آن متصل است استفاده می‌کند\&.
.RE
.RE
.PP
\fI$SYSTEMD_URLIFY\fR
.RS 4
مقدار باید یک بولی باشد\&. کنترل می‌کند که آیا پیوندهای قابل کلیک در خروجی برای شبیه‌سازهای ترمینالی که از این قابلیت پشتیبانی می‌کنند تولید شود یا خیر\&. این گزینه را می‌توان برای بازنویسی تصمیمی که
\fBsystemd\fR
بر اساس
\fI$TERM\fR
و سایر شرایط می‌گیرد مشخص کرد\&.
.RE
.SH "مثال‌ها (EXAMPLES)"
.PP
\fBمثال\ \&۱.\ \&دانلود یک تصویر TAR اوبونتو و باز کردن یک پوسته در آن\fR
.sp
.if n \{\
.RS 4
.\}
.nf
# 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
.fi
.if n \{\
.RE
.\}
.PP
این دستور تصویر
\&.tar
مشخص‌شده را دانلود و اعتبارسنجی می‌کند، و سپس از
\fBsystemd-nspawn\fR(1)
برای باز کردن یک پوسته در آن استفاده می‌نماید\&.
.PP
\fBمثال\ \&۲.\ \&ساخت و بوت کردن یک توزیع فدورا مینیمال در یک کانتینر\fR
.sp
.if n \{\
.RS 4
.\}
.nf
# dnf \-y \-\-releasever=44 \-\-installroot=/var/lib/machines/f44 \e
      \-\-use\-host\-config \-\-setopt=install_weak_deps=0 \e
      \-\-repo=fedora \-\-repo=updates install \e
      passwd dnf fedora\-release nano util\-linux systemd systemd\-networkd
# systemd\-nspawn \-bD /var/lib/machines/f44
.fi
.if n \{\
.RE
.\}
.PP
(هنگام استفاده از
\fBdnf\fR
<= 4،
\fI\-\-use\-host\-config\fR
را حذف کنید\&.) این دستور یک توزیع فدورا مینیمال را در دایرکتوری
/var/lib/machines/f44
نصب می‌کند و سپس آن سیستم‌عامل را در یک کانتینر فضای‌نام بوت می‌نماید\&. از آنجا که نصب در زیر دایرکتوری استاندارد
/var/lib/machines/
قرار دارد، شروع ماشین با استفاده از
\fBsystemd\-nspawn \-M f44\fR
نیز امکان‌پذیر است\&.
.PP
\fBمثال\ \&۳.\ \&راه‌اندازی یک پوسته در کانتینری از یک توزیع دبیان ناپایدار مینیمال\fR
.sp
.if n \{\
.RS 4
.\}
.nf
# debootstrap unstable ~/debian\-tree/
# systemd\-nspawn \-D ~/debian\-tree/
.fi
.if n \{\
.RE
.\}
.PP
این دستور یک توزیع دبیان ناپایدار (unstable) مینیمال را در دایرکتوری
~/debian\-tree/
نصب کرده و سپس یک پوسته از این تصویر در یک کانتینر فضای‌نام اجرا می‌کند\&.
.PP
\fBdebootstrap\fR
به صورت پیش‌فرض از
\m[blue]\fBDebian\fR\m[]\&\s-2\u[8]\d\s+2
و
\m[blue]\fBUbuntu\fR\m[]\&\s-2\u[9]\d\s+2
پشتیبانی می‌کند، بنابراین می‌توان از همان دستور برای نصب هر یک از آن‌ها استفاده کرد\&. برای سایر توزیع‌های خانواده دبیان، باید یک آینه (mirror) مشخص شود،
\fBdebootstrap\fR(8)
را ببینید\&.
.PP
\fBمثال\ \&۴.\ \&بوت کردن یک توزیع آرچ لینوکس مینیمال در یک کانتینر\fR
.sp
.if n \{\
.RS 4
.\}
.nf
# pacstrap \-c ~/arch\-tree/ base
# systemd\-nspawn \-bD ~/arch\-tree/
.fi
.if n \{\
.RE
.\}
.PP
این دستور یک توزیع آرچ لینوکس مینیمال را در دایرکتوری
~/arch\-tree/
نصب کرده و سپس یک سیستم‌عامل را در یک کانتینر فضای‌نام در آن بوت می‌کند\&.
.PP
\fBمثال\ \&۵.\ \&نصب توزیع غلتان OpenSUSE Tumbleweed\fR
.sp
.if n \{\
.RS 4
.\}
.nf
# zypper \-\-root=/var/lib/machines/tumbleweed ar \-c \e
      https://download\&.opensuse\&.org/tumbleweed/repo/oss tumbleweed
# zypper \-\-root=/var/lib/machines/tumbleweed refresh
# zypper \-\-root=/var/lib/machines/tumbleweed install \-\-no\-recommends \e
      systemd shadow zypper openSUSE\-release vim
# systemd\-nspawn \-M tumbleweed passwd root
# systemd\-nspawn \-M tumbleweed \-b
.fi
.if n \{\
.RE
.\}
.PP
\fBمثال\ \&۶.\ \&بوت در یک اسنپ‌شات موقت از سیستم میزبان\fR
.sp
.if n \{\
.RS 4
.\}
.nf
# systemd\-nspawn \-D / \-xb
.fi
.if n \{\
.RE
.\}
.PP
این دستور کپی‌ای از سیستم میزبان را در یک اسنپ‌شات اجرا می‌کند که بلافاصله با خروج کانتینر حذف می‌شود\&. بنابراین، تمام تغییرات سیستم‌فایل ایجادشده در طول زمان اجرا با خاموش شدن از بین خواهند رفت\&.
.PP
\fBمثال\ \&۷.\ \&اجرای یک کانتینر با زمینه‌های امنیتی جعبه‌شنی SELinux\fR
.sp
.if n \{\
.RS 4
.\}
.nf
# 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 \e
      \-Z system_u:system_r:svirt_lxc_net_t:s0:c0,c1 \-D /srv/container /bin/sh
.fi
.if n \{\
.RE
.\}
.PP
\fBمثال\ \&۸.\ \&اجرای یک کانتینر با یک استقرار OSTree\fR
.sp
.if n \{\
.RS 4
.\}
.nf
# systemd\-nspawn \-b \-i ~/image\&.raw \e
      \-\-pivot\-root=/ostree/deploy/$OS/deploy/$CHECKSUM:/sysroot \e
      \-\-bind=+/sysroot/ostree/deploy/$OS/var:/var
.fi
.if n \{\
.RE
.\}
.SH "وضعیت خروج (EXIT STATUS)"
.PP
کد خروج برنامه اجراشده در کانتینر بازگردانده می‌شود\&.
.SH "همچنین ببینید (SEE ALSO)"
.PP
\fBsystemd\fR(1), \fBsystemd.nspawn\fR(5), \fBchroot\fR(1), \fBdnf\fR(8), \fBdebootstrap\fR(8), \fBpacman\fR(8), \fBzypper\fR(8), \fBsystemd.slice\fR(5), \fBmachinectl\fR(1), \fBimportctl\fR(1), \fBsystemd-mountfsd.service\fR(8), \fBsystemd-nsresourced.service\fR(8), \fBsystemd.mstack\fR(7), \fBbtrfs\fR(8)
.SH "نکات (NOTES)"
.IP " 1." 4
Container Interface
.RS 4
\%https://systemd.io/CONTAINER_INTERFACE
.RE
.IP " 2." 4
UAPI.2 Discoverable Partitions Specification
.RS 4
\%https://uapi-group.org/specifications/specs/discoverable_partitions_specification
.RE
.IP " 3." 4
OCI Runtime Specification
.RS 4
\%https://github.com/opencontainers/runtime-spec/blob/master/spec.md
.RE
.IP " 4." 4
File Descriptor Store
.RS 4
\%https://systemd.io/FILE_DESCRIPTOR_STORE
.RE
.IP " 5." 4
Overlay Filesystem
.RS 4
\%https://docs.kernel.org/filesystems/overlayfs.html
.RE
.IP " 6." 4
ANSI Escape Code (Wikipedia)
.RS 4
\%https://en.wikipedia.org/wiki/ANSI_escape_code#SGR_(Select_Graphic_Rendition)_parameters
.RE
.IP " 7." 4
توصیه می‌شود که ابزارهای دیگر در صورت لزوم
\fI$SUDO_UID\fR
را تنظیم و بررسی کنند، و با آن به عنوان یک رابط رایج رفتار نمایند.
.IP " 8." 4
Debian
.RS 4
\%https://www.debian.org
.RE
.IP " 9." 4
Ubuntu
.RS 4
\%https://www.ubuntu.com
.RE
.IP "10." 4
Arch Linux
.RS 4
\%https://www.archlinux.org
.RE
.IP "11." 4
OpenSUSE Tumbleweed
.RS 4
\%https://software.opensuse.org/distributions/tumbleweed
.RE