نام (NAME)

systemd-sysext, systemd-sysext.service, systemd-sysext-initrd.service, systemd-sysext-sysroot.service, systemd-confext, systemd-confext.service, systemd-confext-initrd.service, systemd-confext-sysroot.service - فعال‌سازی ایمیج‌های افزونه سیستم

خلاصه دستور (SYNOPSIS)

systemd-sysext [OPTIONS...] COMMAND

systemd-sysext.service

systemd-confext [OPTIONS...] COMMAND

systemd-confext.service

توضیحات (DESCRIPTION)

systemd-sysext ایمیج‌های افزونه سیستم را فعال/غیرفعال می‌کند. ایمیج‌های افزونه سیستم ممکن است – به‌طور پویا در زمان اجرا — سلسله‌مراتب پوشه‌های /usr/ و /opt/ را با فایل‌های اضافی گسترش دهند. این امر به‌ویژه در ایمیج‌های سیستم تغییرناپذیر که در آن‌ها سلسله‌مراتب /usr/ و/یا /opt/ مستقر روی یک فایل‌سیستم فقط‌خواندنی باید به‌طور موقت در زمان اجرا بدون ایجاد هرگونه تغییرات دائمی گسترش یابد، مفید است.

ایمیج‌های افزونه سیستم باید حاوی فایل‌ها و پوشه‌هایی مشابه با ساختار درخت سیستم‌عامل معمولی باشند. هنگامی که یک یا چند ایمیج افزونه سیستم فعال می‌شوند، سلسله‌مراتب /usr/ و /opt/ آن‌ها از طریق "overlayfs" با همان سلسله‌مراتب سیستم‌عامل میزبان ترکیب شده و سلسله‌مراتب /usr/ و /opt/ میزبان با آن رونویسی و سوار می‌شوند ("ادغام"). هنگامی که غیرفعال می‌شوند، نقطه اتصال پیاده می‌شود — و مجدداً نسخه اصلی و دست‌نخورده سلسله‌مراتب میزبان نمایان می‌گردد ("لغو ادغام"). بنابراین، ادغام باعث می‌شود منابع افزونه ناگهان زیر سلسله‌مراتب‌های /usr/ و /opt/ ظاهر شوند، گویی که در خود ایمیج پایه سیستم‌عامل گنجانده شده بودند. لغو ادغام باعث می‌شود آن‌ها دوباره ناپدید شوند و تنها فایل‌هایی که به همراه خود ایمیج پایه سیستم‌عامل ارائه شده بودند بر جای بمانند.

فایل‌ها و پوشه‌های موجود در ایمیج‌های افزونه خارج از سلسله‌مراتب‌های /usr/ و /opt/ ادغام نمی‌شوند، و در نتیجه گنجاندن آن‌ها در یک ایمیج افزونه سیستم هیچ اثری ندارد. به‌ویژه، فایل‌های موجود در /etc/ و /var/ که در یک ایمیج افزونه سیستم گنجانده شده‌اند، پس از فعال‌سازی در سلسله‌مراتب‌های مربوطه ظاهر نخواهند شد.

ایمیج‌های افزونه سیستم به‌طور پیش‌فرض کاملاً فقط‌خواندنی هستند. در فایل‌سیستم‌های میزبان تغییرپذیر، سلسله‌مراتب‌های /usr/ و /opt/ هنگام ادغام افزونه‌ها فقط‌خواندنی می‌شوند، مگر اینکه قابلیت تغییرپذیری فعال شده باشد. تغییرپذیری ممکن است از طریق گزینه --mutable= و گزینه Mutable= در فایل پیکربندی فعال شود؛ برای اطلاعات بیشتر بخش "تغییرپذیری" در ادامه را ببینید.

گزینه‌های مختلف دستور را می‌توان به‌صورت سراسری از طریق فایل‌های پیکربندی تنظیم کرد. برای جزئیات بیشتر sysext.conf(5) را ببینید.

افزونه‌های سیستم قرار است صرفاً افزایشی باشند، یعنی فرض بر این است که فقط فایل‌هایی را شامل شوند که در ایمیج پایه زیرین سیستم‌عامل وجود ندارند. با این حال، سازوکار زیرین (overlayfs) امکان هم‌پوشانی یا حذف فایل‌ها را نیز فراهم می‌کند، اما توصیه می‌شود از این قابلیت استفاده نشود.

ایمیج‌های افزونه سیستم را می‌توان در قالب‌های زیر ارائه کرد:

1.پوشه‌های معمولی یا زیرحجم‌های btrfs حاوی درخت سیستم‌عامل

2.ایمیج‌های دیسک دارای برچسب دیسک GPT، پیرو مشخصات پارتیشن‌های قابل‌شناسایی UAPI.2[1]

3.ایمیج‌های دیسک فاقد جدول پارتیشن، با یک فایل‌سیستم عریان لینوکس (مانند erofs، squashfs یا ext4)

این قالب‌های ایمیج همان مواردی هستند که systemd-nspawn(1) از طریق سوئیچ‌های --directory=/--image= خود پشتیبانی می‌کند و همچنین همان‌هایی هستند که مدیر سرویس از طریق RootDirectory=/RootImage= پشتیبانی می‌نماید. مشابه آن‌ها، این ایمیج‌ها می‌توانند به‌صورت اختیاری حاوی اطلاعات اعتبارسنجی Verity باشند.

افزونه‌های سیستم در پوشه‌های /etc/extensions/، /run/extensions/ و /var/lib/extensions/ جستجو می‌شوند. دو پوشه اول فهرست‌شده برای نگهداری ایمیج‌های باینری حجیم مناسب نیستند، اما همچنان برای نگهداری پیوندهای نمادین به آن‌ها مفید هستند. مکان اصلی برای نصب افزونه‌های سیستم /var/lib/extensions/ است. هر پوشه یافت‌شده در این پوشه‌های جستجو به عنوان ایمیج‌های افزونه مبتنی بر پوشه در نظر گرفته می‌شود؛ هر فایلی با پسوند .raw به عنوان ایمیج‌های افزونه مبتنی بر ایمیج دیسک در نظر گرفته می‌شود. هنگام فراخوانی در initrd، پوشه اضافی /.extra/sysext/ نیز در میان پوشه‌هایی که برای یافتن ایمیج‌های افزونه جستجو می‌شوند گنجانده می‌شود. با این حال توجه داشته باشید که به‌طور پیش‌فرض یک سیاست ایمیج سخت‌گیرانه‌تر بر ایمیج‌های یافت‌شده در آنجا اعمال می‌شود، به توضیحات زیر مراجعه کنید. این پوشه توسط systemd-stub(7) با ایمیج‌های افزونه یافت‌شده در پارتیشن سیستم EFI سیستم پر می‌شود.

در زمان بوت، ایمیج‌های افزونه سیستم و پیکربندی در صورتی که سرویس‌های systemd-sysext.service و systemd-confext.service فعال باشند، به‌طور خودکار فعال می‌شوند. توجه داشته باشید که این سرویس‌ها تنها پس از سوار شدن فایل‌سیستم‌های زیرین که ممکن است افزونه‌های سیستم و پیکربندی در آن‌ها قرار داشته باشند اجرا می‌شوند. برای امکان‌پذیر ساختن ارائه منابعی که توسط زیرسیستم‌های در حال اجرا در نخستین مراحل بوت پردازش می‌شوند (برای نمونه، سرویس‌های سیستم یا تعاریف systemd-sysusers(8))، سرویس‌های initrd به نام‌های systemd-sysext-sysroot.service و systemd-confext-sysroot.service ارائه شده‌اند. در حال حاضر، هنگامی که پارتیشن /var/ مجزا باشد، نمی‌توان از این سرویس‌ها برای ادغام افزونه‌های سیستم از /sysroot/var/lib/extensions/ و افزونه‌های پیکربندی از /sysroot/var/lib/confexts/ استفاده کرد. این افزونه‌ها بعداً توسط سرویس‌های systemd-sysext.service و systemd-confext.service در طول فرآیند بوت اصلی سیستم‌عامل ادغام می‌شوند.

همچنین، صفحه سرویس‌های قابل‌حمل[2] را برای یک سازوکار ساده جهت ارائه سرویس‌های سیستم در ایمیج‌های دیسک، به شیوه‌ای مشابه با افزونه‌های سیستم‌عامل ببینید. به تفاوت‌های ایزوله‌سازی میان این دو سازوکار توجه کنید: در حالی که افزونه‌های سیستم مستقیماً ایمیج سیستم‌عامل زیرین را با فایل‌های اضافی گسترش می‌دهند که گویی در خود ایمیج سیستم‌عامل ارائه شده‌اند و بنابراین هیچ‌گونه ایزوله‌سازی امنیتی را در بر ندارند، سرویس‌های قابل‌حمل به یک شیوه یا شیوه دیگر ایزوله‌سازی در سطح سرویس را اعمال می‌کنند.

تضمین می‌شود که سرویس‌های systemd-sysext.service و systemd-confext.service پیش از رسیدن به basic.target راه‌اندازی خود را به پایان برسانند؛ یعنی زمانی که سرویس‌های معمولی مقداردهی اولیه می‌شوند (آن‌هایی که از DefaultDependencies=no استفاده نمی‌کنند)، فایل‌ها و پوشه‌های ارائه‌شده توسط افزونه‌های سیستم و پیکربندی در /usr/، /opt/، و /etc/ در دسترس بوده و قابل دسترسی هستند.

افزونه‌های سیستم و پیکربندی را می‌توان برای گسترش initrd نیز به کار برد، و سرویس‌های initrd شامل systemd-sysext-initrd.service و systemd-confext-initrd.service بدین منظور ارائه شده‌اند. توجه داشته باشید که برخی محدودیت‌ها اعمال می‌شوند: منابعی که در نخستین مراحل بوت initrd استفاده می‌شوند (مانند سرویس‌های سیستم) قابل به‌روزرسانی نیستند.

توجه داشته باشید که مفهومی به عنوان فعال/غیرفعال‌سازی ایمیج‌های افزونه سیستم نصب‌شده وجود ندارد: تمام ایمیج‌های افزونه نصب‌شده به‌طور خودکار در زمان بوت فعال می‌شوند. با این حال، می‌توانید یک پوشه خالی با نامی مشابه افزونه (بدون .raw) در /etc/extensions/ قرار دهید تا افزونه‌ای با همان نام را در یک پوشه سیستمی با اولویت پایین‌تر "ماسک" (پنهان/غیرفعال) کنید. همچنین می‌توان با استفاده از گزینه‌های خط فرمان کرنل شامل rd.systemd.sysext=، rd.systemd.confext=، systemd.sysext= و systemd.confext= ادغام خودکار را به‌طور کلی غیرفعال کرد. توجه داشته باشید که systemd-sysext-sysroot.service و systemd-confext-sysroot.service توسط گزینه‌های systemd.sysext= و systemd.confext= کنترل می‌شوند، زیرا این سرویس‌ها افزونه‌های سیستم و پیکربندی را برای سیستم اصلی ادغام می‌کنند، نه برای initrd.

یک سازوکار ساده برای سازگاری نسخه اعمال می‌شود: یک ایمیج افزونه سیستم باید حاوی یک فایل /usr/lib/extension-release.d/extension-release.NAME باشد که باید با نام ایمیج آن مطابقت داشته باشد و با فایل os-release میزبان مقایسه می‌شود: فیلدهای ID= موجود در آن‌ها باید مطابقت داشته باشند مگر اینکه برای افزونه مقدار "_any" تنظیم شده باشد. اگر ID= افزونه برابر با "_any" نباشد، فیلد SYSEXT_LEVEL= (در صورت تعریف) باید مطابقت داشته باشد. اگر مورد اخیر تعریف نشده باشد، در عوض فیلد VERSION_ID= باید مطابقت داشته باشد. اگر افزونه فیلد ARCHITECTURE= را تعریف کند و مقدار آن "_any" نباشد، باید با معماری کرنل که توسط uname(2) گزارش می‌شود مطابقت داشته باشد، اما شناسه‌های معماری استفاده‌شده همان مواردی هستند که برای ConditionArchitecture= در systemd.unit(5) شرح داده شده‌اند. اگر افزونه پس از اعمال نیازمند بازخوانی مدیر سرویس باشد، EXTENSION_RELOAD_MANAGER= می‌تواند روی 1 تنظیم شود. توجه داشته باشید که به دلایلی که پیش‌تر ذکر شد، سرویس‌های قابل‌حمل[2] همچنان روش پیشنهادی برای ارائه سرویس‌های سیستم باقی می‌مانند. افزونه‌های سیستم نباید فایل /usr/lib/os-release را همراه داشته باشند (زیرا با درخت /usr/ میزبان ادغام خواهد شد و داده‌های نسخه سیستم‌عامل میزبان را رونویسی می‌کند که مطلوب نیست). فایل extension-release از همان قالب و معناشناسی پیروی می‌کند و حاوی همان محتوایی است که فایل os-release سیستم‌عامل دارد، اما منابع موجود در ایمیج افزونه را توصیف می‌کند.

مفهوم systemd-confext از همان اصول عملکرد systemd-sysext(8) پیروی می‌کند اما به جای کار روی /usr و /opt، ابزار confext فقط /etc را گسترش می‌دهد. فایل‌ها و پوشه‌های موجود در ایمیج‌های confext خارج از سلسله‌مراتب /etc/ ادغام نمی‌شوند، و بنابراین هنگام گنجانده شدن در ایمیج هیچ تاثیری ندارند. قالب‌های این ایمیج‌ها مشابه ایمیج‌های sysext است. سلسله‌مراتب ادغام‌شده با پرچم "nosuid" و (در صورتی که از طریق --noexec=false غیرفعال نشده باشد) با پرچم "noexec" سوار خواهد شد.

دقیقاً مانند sysextها، confextها نیز به‌طور پیش‌فرض کاملاً فقط‌خواندنی هستند. ادغام confextها روی فایل‌سیستم‌های میزبان تغییرپذیر باعث می‌شود /etc/ به حالت فقط‌خواندنی درآید. همانند sysextها، تغییرپذیری را می‌توان از طریق گزینه --mutable= فعال کرد. برای اطلاعات بیشتر به بخش "تغییرپذیری" در زیر مراجعه کنید.

افزونه‌های پیکربندی در پوشه‌های /run/confexts/، /var/lib/confexts/، /usr/lib/confexts/ و /usr/local/lib/confexts/ جستجو می‌شوند. پوشه نخست فهرست‌شده برای نگهداری ایمیج‌های باینری حجیم مناسب نیست، اما همچنان برای نگهداری پیوندهای نمادین به آن‌ها مفید است. مکان اصلی برای نصب افزونه‌های پیکربندی /var/lib/confexts/ است. هر پوشه یافت‌شده در این پوشه‌های جستجو به عنوان ایمیج‌های confext مبتنی بر پوشه در نظر گرفته می‌شود؛ هر فایلی با پسوند .raw به عنوان ایمیج‌های confext مبتنی بر ایمیج دیسک در نظر گرفته می‌شود.

مجدداً، دقیقاً مانند ایمیج‌های sysext، ایمیج‌های confext نیز حاوی یک فایل /etc/extension-release.d/extension-release.NAME خواهند بود که باید با نام ایمیج مطابقت داشته باشد (با راه فرار معمول ویژگی تعمیم‌یافته user.extension-release.strict در xattr(7))، و باز هم محتوای آن یک یا چند مورد از ID=، VERSION_ID= و CONFEXT_LEVEL است. سپس ایمیج‌های confext در برابر لایه پایه سیستم‌عامل بررسی و تطبیق داده می‌شوند.

کاربردها (USES)

مهم‌ترین مورد کاربرد برای ایمیج‌های سیستم، محیط‌های تغییرناپذیر هستند که در آن‌ها ابزارهای اشکال‌زدایی و توسعه باید به‌صورت اختیاری در دسترس قرار گیرند، اما در خود ایمیج پایه تغییرناپذیر سیستم‌عامل گنجانده نشوند (برای نمونه strace(1) و gdb(1) باید یک افزونه با قابلیت نصب اختیاری باشند تا اشکال‌زدایی/توسعه آسان‌تر شود). ایمیج‌های افزونه سیستم نباید به عنوان یک چارچوب عمومی بسته‌بندی نرم‌افزار اشتباه گرفته شوند، زیرا هیچ ساختار وابستگی در دسترس نیست: افزونه‌های سیستم باید تمام فایل‌های مورد نیاز خود را به همراه داشته باشند، به جز مواردی که قبلاً در ایمیج سیستم میزبان زیرین ارائه شده‌اند. معمولاً ایمیج‌های افزونه سیستم هم‌زمان با ایمیج پایه سیستم‌عامل — در همان سیستم ساخت — ایجاد می‌شوند.

یکی دیگر از موارد کاربرد برای مفهوم افزونه سیستم، جایگزینی موقت منابع ارائه‌شده توسط سیستم‌عامل با منابع جدیدتر است، برای نمونه نصب نسخه توسعه کامپایل‌شده محلی از یک مؤلفه سطح پایین روی ایمیج سیستم‌عامل تغییرناپذیر بدون نیاز به ساخت مجدد کامل سیستم‌عامل یا تغییر ایمیج اسماً تغییرناپذیر. (برای مثال "نصب" یک بسته ساخته‌شده محلی با DESTDIR=/var/lib/extensions/mytest make install && systemd-sysext refresh، که آن را در /usr/ در دسترس قرار می‌دهد گویی در خود ایمیج سیستم‌عامل نصب شده است.) این حالت فارغ از اینکه /usr/ میزبان زیرین به عنوان یک ایمیج دیسک تغییرناپذیر مدیریت می‌شود یا یک درخت سنتی تحت کنترل مدیر بسته (یعنی قابل نوشتن) است، کار می‌کند.

با systemd-confext می‌توان پیکربندی مجدد سرویس‌های سیستم‌عامل را در زمان اجرا انجام داد. گاهی اوقات نیاز است که مقادیر برخی پارامترهای پیکربندی تعویض شوند یا فقط یک سرویس خاص بدون استقرار کد جدید یا استقرار کامل سیستم‌عامل مجدداً راه‌اندازی شود. به عبارت دیگر، ما می‌خواهیم بتوانیم گزینه‌های با بیشترین بسامد پیکربندی را به پرچم‌های قابل‌به‌روزرسانی در زمان اجرا که می‌توانند بدون راه‌اندازی مجدد سیستم تغییر یابند، متصل کنیم. این کار به کاهش زمان‌های سرویس‌دهی هنگام نیاز به تغییر پیکربندی سیستم‌عامل کمک خواهد کرد. همچنین این ابزار یک ابزار قابل‌اعتماد برای مدیریت پیکربندی فراهم می‌کند زیرا هنگام حذف ایمیج systemd-confext تمام فایل‌های پیکربندی قدیمی ناپدید می‌شوند.

تغییرپذیری (MUTABILITY)

به‌طور پیش‌فرض، ادغام افزونه‌های سیستم روی فایل‌سیستم‌های میزبان تغییرپذیر باعث می‌شود سلسله‌مراتب‌های /usr/ و /opt/ فقط‌خواندنی شوند. ادغام افزونه‌های پیکربندی نیز همین اثر را بر /etc/ خواهد داشت. حالت تغییرپذیر امکان نوشتن در این مکان‌ها را هنگام ادغام افزونه‌ها فراهم می‌کند.

حالت‌های زیر پشتیبانی می‌شوند:

1.disabled: اجبار حالت تغییرناپذیر حتی اگر پوشه‌های هدایت نوشتن زیر /var/lib/extensions.mutable/ وجود داشته باشند. این مقدار پیش‌فرض است.

2.auto: حالت خودکار. تغییرپذیری به‌طور پیش‌فرض غیرفعال است و تنها در صورتی فعال می‌شود که یک پوشه هدایت نوشتن مربوطه زیر /var/lib/extensions.mutable/ وجود داشته باشد.

3.enabled: اجبار حالت تغییرپذیر و ایجاد خودکار پوشه‌های هدایت نوشتن زیر /var/lib/extensions.mutable/ در صورت نیاز.

4.import: اجبار حالت تغییرناپذیر مانند disabled در بالا، اما ادغام محتوای پوشه‌های زیر /var/lib/extensions.mutable/ در فایل‌سیستم میزبان.

5.ephemeral: اجبار حالت تغییرپذیر مانند enabled در بالا، اما به جای استفاده از پوشه هدایت نوشتن زیر /var/lib/extensions.mutable/، ابزار systemd-sysext از پوشه‌های موقت خالی استفاده خواهد کرد. این بدان معناست که تغییرات ایجادشده در سلسله‌مراتب‌های ادغام‌شده هنگام لغو ادغام آن‌ها از بین خواهند رفت.

6.ephemeral-import: اجبار حالت تغییرپذیر مانند ephemeral در بالا، اما به جای نادیده گرفتن محتوای پوشه‌های هدایت نوشتن زیر /var/lib/extensions.mutable/، آن‌ها مانند آنچه import انجام می‌دهد در فایل‌سیستم میزبان ادغام می‌شوند.

برای تعیین حالت‌ها با استفاده از گزینه خط فرمان --mutable= به بخش "گزینه‌ها" در ادامه مراجعه کنید.

به استثنای حالت ephemeral، حالت تغییرپذیر عملیات نوشتن را به زیرپوشه‌های موجود در /var/lib/extensions.mutable/ هدایت می‌کند.

عملیات نوشتن در /usr/ به /var/lib/extensions.mutable/usr/ هدایت می‌شود،

عملیات نوشتن در /opt/ به /var/lib/extensions.mutable/opt/ هدایت می‌شود، و

عملیات نوشتن در /etc/ در /var/lib/extensions.mutable/etc/ قرار می‌گیرد.

اگر usr/، opt/ یا etc/ در /var/lib/extensions.mutable/ پیوندهای نمادین باشند، در این صورت عملیات نوشتن به مقصدهای این پیوندها هدایت می‌شود. در نتیجه، برای حفظ تغییرپذیری یک فایل‌سیستم میزبان، پیوندهای نمادین زیر را ایجاد کنید:

/var/lib/extensions.mutable/etc/ → /etc/

/var/lib/extensions.mutable/usr/ → /usr/

/var/lib/extensions.mutable/opt/ → /opt/

تا عملیات نوشتن به سلسله‌مراتب پوشه پایه اصلی بازگردانده شود.

همچنین، یک فایل‌سیستم موقت را می‌توان در /var/lib/extensions.mutable/ سوار کرد، یا پیوندهای نمادین در /var/lib/extensions.mutable/ می‌توانند به زیرپوشه‌هایی در یک فایل‌سیستم موقت (برای نمونه زیر /tmp/) اشاره کنند تا فقط تغییرات موقت مجاز باشد. توجه داشته باشید که این با حالت ephemeral یکسان نیست، زیرا فایل‌سیستم موقت پس از لغو ادغام همچنان وجود خواهد داشت.

افزوده‌شده در نسخه 256.

فرمان‌ها (COMMANDS)

فرمان‌های زیر توسط هر دو مفهوم sysext و confext درک می‌شوند:

status

هنگامی که بدون هیچ فعل دستوری فراخوانی شود، یا هنگامی که status مشخص گردد، وضعیت ادغام فعلی به‌طور جداگانه (هم برای /usr/ و /opt/ در sysext و هم برای /etc/ در confext) نشان داده می‌شود.

افزوده‌شده در نسخه 248.

merge

تمام ایمیج‌های افزونه سیستم که در حال حاضر نصب شده‌اند را در /usr/ و /opt/ ادغام می‌کند؛ این کار با سوار کردن این سلسله‌مراتب‌ها با یک فایل‌سیستم "overlayfs" که سلسله‌مراتب‌های زیرین را با موارد موجود در ایمیج‌های افزونه ترکیب می‌کند، انجام می‌شود. اگر سلسله‌مراتب‌ها از قبل ادغام شده باشند، این دستور با شکست مواجه می‌شود. برای confext، ادغام به جای آن در پوشه /etc/ انجام می‌پذیرد.

افزوده‌شده در نسخه 248.

unmerge

با پیاده‌سازی فایل‌سیستم‌های "overlayfs" که پیش‌تر توسط merge ایجاد شده بودند، تمام ایمیج‌های افزونه سیستم که در حال حاضر نصب شده‌اند را از /usr/ و /opt/ برای sysext و از /etc/ برای confext لغو ادغام می‌کند.

افزوده‌شده در نسخه 248.

refresh

ترکیبی از unmerge و merge: در صورتی که از قبل سوار شده باشد، نمونه موجود "overlayfs" به‌طور موقت پیاده شده و سپس با یک نسخه جدید جایگزین می‌شود. این فرمان پس از نصب/حذف ایمیج‌های افزونه سیستم برای به‌روزرسانی مناسب فایل‌سیستم "overlayfs" مفید است. اگر هنگام اجرای این فرمان هیچ افزونه سیستمی نصب نشده باشد، معادل unmerge بدون ایجاد هیچ نمونه جدیدی از "overlayfs" اجرا می‌شود. توجه داشته باشید که در حال حاضر یک لحظه کوتاه وجود دارد که در آن نه فایل‌سیستم "overlayfs" قدیمی و نه جدید سوار نیستند. این بدان معناست که تمام منابع ارائه‌شده توسط یک افزونه سیستم برای مدت کوتاهی ناپدید خواهند شد — حتی اگر در طول عملیات نوسازی به‌طور مداوم وجود داشته باشد.

افزوده‌شده در نسخه 248.

list

فهرست کوتاهی از ایمیج‌های افزونه نصب‌شده را نمایش می‌دهد.

افزوده‌شده در نسخه 248.

-h, --help

یک متن راهنمای کوتاه را چاپ کرده و خارج می‌شود.

--version

یک رشته کوتاه نسخه را چاپ کرده و خارج می‌شود.

گزینه‌ها (OPTIONS)

--root=

نسبت به پوشه ریشه مشخص‌شده عمل می‌کند، یعنی اتصال "overlayfs" را نه بر روی سلسله‌مراتب‌های سطح بالای /usr/ و /opt/ میزبان برای sysext یا /etc/ برای confext، بلکه در زیر یک پوشه ریشه مشخص‌شده برقرار می‌سازد.

افزوده‌شده در نسخه 248.

--force

هنگام ادغام افزونه‌های سیستم در /usr/ و /opt/ برای sysext و /etc/ برای confext، ناسازگاری‌های نسخه را نادیده می‌گیرد، یعنی ادغام را بدون در نظر گرفتن اینکه اطلاعات نسخه موجود در ایمیج‌ها با میزبان مطابقت دارد یا خیر، اجبار می‌کند.

افزوده‌شده در نسخه 248.

--always-refresh=yes|no

هنگام نوسازی افزونه‌های سیستم روی /usr/ و /opt/ برای sysext و /etc/ برای confext، در صورتی که افزونه‌های ادغام‌شده فعلی با آنچه قرار است ادغام شود مطابقت داشته باشد، آن را نادیده می‌گیرد. به‌طور پیش‌فرض وقتی تغییری یافت نشود از نوسازی صرف‌نظر می‌شود. توجه داشته باشید که تغییرات ایجادشده در پوشه یک افزونه در حالی که ادغام شده است بدون این پرچم نادیده گرفته می‌شوند (مگر اینکه افزونه دیگری تغییر کرده باشد). همچنین توجه داشته باشید که تغییر محتوا در حین ادغام بودن در overlayfs رفتاری تعریف‌نشده است.

افزوده‌شده در نسخه 260.

--image-policy=policy

یک رشته سیاست ایمیج را مطابق با systemd.image-policy(7) به عنوان آرگومان دریافت می‌کند. این سیاست هنگام کار با ایمیج‌های دیسک افزونه سیستم اعمال می‌شود. اگر مشخص نشود، برای افزونه‌های سیستم مقدار پیش‌فرض "root=verity+signed+encrypted+unprotected+absent:usr=verity+signed+encrypted+unprotected+absent" است، یعنی فقط فایل‌سیستم‌های root و /usr/ موجود در ایمیج استفاده می‌شوند. برای افزونه‌های پیکربندی مقدار پیش‌فرض "root=verity+signed+encrypted+unprotected+absent" است. هنگام اجرا در initrd و کار بر روی یک ایمیج افزونه سیستم ذخیره‌شده در پوشه /.extra/sysext/، به‌طور پیش‌فرض سیاست کمی سخت‌گیرانه‌تری استفاده می‌شود: "root=signed+absent:usr=signed+absent"، برای جزئیات بیشتر به بخش‌های بالا مراجعه کنید.

افزوده‌شده در نسخه 254.

حالت تغییرپذیر را تنظیم می‌کند. مقدار ویژه "help" مقادیر شناخته‌شده را فهرست می‌کند.

no

اجبار حالت تغییرناپذیر حتی با وجود پوشه‌های هدایت نوشتن. این مقدار پیش‌فرض است.

افزوده‌شده در نسخه 256.

auto

فعال‌سازی حالت تغییرپذیر به‌طور جداگانه برای /usr/، /opt/، و /etc/ در صورتی که زیرپوشه‌های هدایت نوشتن یا پیوندهای نمادین در /var/lib/extensions.mutable/ حاضر باشند؛ در غیر این صورت غیرفعال می‌شود. برای اطلاعات بیشتر درباره هدایت نوشتن به بخش "تغییرپذیری" در بالا مراجعه کنید.

افزوده‌شده در نسخه 256.

yes

اجبار حالت تغییرپذیر. در صورت عدم وجود، پوشه‌های هدایت نوشتن در /var/lib/extensions.mutable/ ایجاد خواهند شد.

افزوده‌شده در نسخه 256.

import

حالت تغییرناپذیر، اما همراه با ادغام محتوای پوشه‌های هدایت نوشتن در /var/lib/extensions.mutable/ در فایل‌سیستم میزبان.

افزوده‌شده در نسخه 256.

ephemeral

اجبار حالت تغییرپذیر، اما با نادیده گرفتن محتوای پوشه‌های هدایت نوشتن در /var/lib/extensions.mutable/، و دور ریخته شدن تغییرات فایل‌سیستم میزبان پس از لغو ادغام.

افزوده‌شده در نسخه 256.

ephemeral-import

اجبار حالت تغییرپذیر، همراه با ادغام محتوای پوشه‌های هدایت نوشتن در /var/lib/extensions.mutable/ در فایل‌سیستم میزبان، اما با دور ریخته شدن تغییرات ایجادشده در فایل‌سیستم میزبان پس از لغو ادغام.

افزوده‌شده در نسخه 256.

help

فهرست مقادیر شناخته‌شده را نمایش داده و بلافاصله خارج می‌شود.

افزوده‌شده در نسخه 259.

افزوده‌شده در نسخه 256.

--noexec=BOOL

هنگام ادغام افزونه‌های پیکربندی در /etc/ به‌طور پیش‌فرض از پرچم اتصال "MS_NOEXEC" استفاده می‌شود. این گزینه می‌تواند برای غیرفعال کردن آن استفاده شود.

افزوده‌شده در نسخه 254.

--no-reload

هنگامی که همراه با merge، unmerge یا refresh استفاده شود، دیمن را پس از اعمال تغییرات مجدداً بارگذاری نمی‌کند، حتی اگر افزونه‌ای که اعمال شده از طریق تنظیم EXTENSION_RELOAD_MANAGER= روی 1 نیازمند بازخوانی باشد.

افزوده‌شده در نسخه 255.

--no-pager

خروجی را به یک صفحه‌بندی‌کننده هدایت نمی‌کند.

--no-legend

راهنما، یعنی سرستون‌های جدول و پانویس حاوی نکات را چاپ نمی‌کند.

--json=MODE

خروجی را در قالب JSON نشان می‌دهد. یکی از مقادیر زیر را می‌پذیرد: "short" (برای کوتاه‌ترین خروجی ممکن بدون هیچ‌گونه فاصله خالی یا شکست خط اضافی)، "pretty" (برای یک نسخه خواناتر و مرتب از همان با تورفتگی و شکست خط) یا "off" (برای خاموش کردن خروجی JSON، که پیش‌فرض است).

وضعیت خروج (EXIT STATUS)

در صورت موفقیت، 0 برگردانده می‌شود.

همچنین ببینید (SEE ALSO)

systemd(1), sysext.conf(5), systemd-nspawn(1), systemd-stub(7), importctl(1)

یادداشت‌ها (NOTES)

1.: مشخصات پارتیشن‌های قابل‌شناسایی UAPI.2

https://uapi-group.org/specifications/specs/discoverable_partitions_specification

2.: سرویس‌های قابل‌حمل

https://systemd.io/PORTABLE_SERVICES