آرگومانهای
اضافی به
عنوان
آرگومانهای
اضافه خط
فرمان هسته
با استفاده
از SMBIOS ارسال
میشوند.
گزینههای
زیر
پشتیبانی
میشوند:
-q, --quiet
هرگونه
خروجی
وضعیت
تولیدشده
توسط خود
ابزار را
غیرفعال
میکند. در
صورت
استفاده از
این سوئیچ،
تنها خروجی
vmspawn همان
خروجی
کنسول
سیستمعامل
ماشین
مجازی
خواهد بود.
افزودهشده
در نسخه 256.
--system, --user
مشخص
میکند که
آیا با مدیر
کاربری
تعامل شود
یا مدیر
سیستمی، و
اینکه در
نمونه machined
کاربری ثبت
شود یا
نمونه machined
سیستمی. در
صورت مشخص
نشدن،
هنگام اجرا
به عنوان root
از مدیر
سیستمی و
نمونه machined
سیستمی
استفاده
میشود، در
غیر این
صورت از
مدیر
کاربری و
نمونه machined
کاربری
استفاده
خواهد شد.
افزودهشده
در نسخه 260.
-D, --directory=
دایرکتوری
مورد
استفاده به
عنوان ریشه
سیستم فایل
برای ماشین
مجازی.
باید یکی
از
گزینههای
--directory= یا --image=
مشخص شود. در
صورت مشخص
نشدن
هیچکدام،
--directory=. فرض
میشود.
نکته: در
صورت مانت
کردن
دایرکتوریای
که متعلق به
کاربر root
نیست، ممکن
است برای
نگاشت به
فضای نام subuid
کاربر به
--private-users= نیاز
داشته
باشید.
نمونهای
از نحوه
استفاده از
/etc/subuid برای این
منظور در
ادامه آمده
است.
افزودهشده
در نسخه 256.
-x, --ephemeral
در صورت
مشخص شدن،
ماشین
مجازی با یک
رونوشت
موقت (snapshot) از
سیستم فایل
خود اجرا
میشود که
بلافاصله
پس از پایان
کار ماشین
مجازی حذف
خواهد شد. در
حال حاضر
تنها با
--image=
کار میکند.
توجه داشته
باشید که
--ephemeral
با
--extra-drive= کار
نخواهد کرد.
افزودهشده
در نسخه 260.
-i, --image=
تصویر
دیسک سیستم
فایل ریشه
(یا گره
دستگاه)
برای ماشین
مجازی.
افزودهشده
در نسخه 255.
--image-format=FORMAT
قالب
تصویر دیسک
ارسالشده
به
--image= را
مشخص
میکند. یکی
از مقادیر
"raw" یا "qcow2" را
میپذیرد.
مقدار
پیشفرض "raw"
است. توجه
داشته
باشید که "qcow2"
تنها برای
فایلهای
معمولی
پشتیبانی
میشود، نه
دستگاههای
بلوکی.
افزودهشده
در نسخه 260.
--image-disk-type=TYPE
نوع دیسک
مورد
استفاده
برای دیسک
ریشه
ارسالشده
به
--image= را
مشخص
میکند.
درایوهای
اضافی
اضافهشده
از طریق
--extra-drive=
این نوع
دیسک را به
ارث
میبرند
مگر اینکه
با یک
پیشوند نوع
دیسک صریح
لغو شوند.
یکی از
مقادیر
"virtio-blk"، "virtio-scsi"،
"nvme" یا "scsi-cd" را
میپذیرد.
مقدار
پیشفرض
"virtio-blk" است.
هنگامی که
"scsi-cd" مشخص
شود، دیسک
به عنوان یک
درایو CD-ROM
فقطخواندنی
متصل
میشود.
افزودهشده
در نسخه 261.
--discard-disk=BOOL
کنترل
میکند که
آیا qemu
درخواستهای
دورریز (discard) از
ماشین
مجازی را
پردازش کند
یا خیر. این
امر از مصرف
بیش از حد
نیاز فضای
دیسک توسط
ماشینهای
مجازی
طولانیمدت
جلوگیری
میکند. این
گزینه به
طور
پیشفرض
فعال است.
افزودهشده
در نسخه 256.
--grow-image=BYTES, -G
BYTES
در صورتی
که فایل
تصویر
مشخصشده
با
--image=
کوچکتر
باشد،
اندازه آن
را به مقدار
مشخصشده
بر حسب بایت
افزایش
میدهد. اگر
هیچ فایل
تصویری
استفاده
نشود یا
اندازه
فایل تصویر
از قبل
برابر یا
بزرگتر از
مقدار
درخواستی
باشد، هیچ
عملیاتی
انجام
نمیدهد.
اندازه
مشخصشده
پسوندهای
معمول K، M، G
(بر مبنای 1024)
را
میپذیرد.
مقادیر
مشخصشده
به مضارب 4096
به بالا گرد
میشوند.
افزودهشده
در نسخه 258.
--cpus=CPUS
تعداد
پردازندهها
(CPU) برای
راهاندازی
ماشین
مجازی.
مقدار
پیشفرض 1
است.
افزودهشده
در نسخه 255.
--ram=BYTES[:MAXBYTES[:SLOTS]]
میزان
حافظه برای
راهاندازی
ماشین
مجازی.
مقدار
پیشفرض 2G
است. اگر
حداکثر
اندازه بعد
از دونقطه
مشخص شود،
اتصال گرم
حافظه (memory hotplug) با
حد بالای
تعیینشده
فعال
میشود.
تعداد
اسلاتهای
اتصال گرم
را میتوان
به صورت
اختیاری پس
از دونقطه
دوم مشخص
کرد که
مقدار
پیشفرض آن 1
است.
افزودهشده
در نسخه 255.
--kvm=BOOL
کنترل
میکند که
آیا
شتابدهی KVM
فعال شود یا
خیر. اگر
مشخص نشود
یا روی
auto
تنظیم شود،
پشتیبانی
از KVM به طور
خودکار
شناسایی
خواهد شد.
اگر true باشد،
وجود KVM
الزامی است.
اگر false باشد، KVM
غیرفعال
میشود.
افزودهشده
در نسخه 255.
--vsock=BOOL
کنترل
میکند که
آیا یک سوکت
VSOCK برای
مهمان
تخصیص داده
شود یا خیر.
اگر مشخص
نشود یا روی
auto تنظیم
شود،
پشتیبانی
از شبکه VSOCK به
طور خودکار
شناسایی
خواهد شد.
اگر true باشد،
وجود VSOCK
الزامی است.
اگر false باشد،
شبکه VSOCK
غیرفعال
میشود.
افزودهشده
در نسخه 255.
--vsock-cid=CID
شناسه CID
مشخص را
برای
استفاده
مهمان
تنظیم
میکند.
مقادیر
معتبر CID در
محدوده
3 تا
4294967294 (
0xFFFF_FFFE)
هستند.
مقادیر CID
خارج از این
محدوده
رزرو
شدهاند. به
طور
پیشفرض، vmspawn
تلاش
میکند یک CID
برای مهمان
از روی نام
ماشین مشتق
کند، و در
صورتی که
این CID اشغال
شده باشد به
یک CID تصادفی
بازمیگردد.
افزودهشده
در نسخه 255.
--tpm=BOOL
کنترل
میکند که
آیا یک
دستگاه TPM
برای مهمان
از طریق
swtpm(8)
ارائه شود
یا خیر. اگر
مشخص نشود
یا روی
auto
تنظیم شود،
vmspawn وجود
باینری swtpm را
به طور
خودکار
بررسی
میکند. اگر yes
باشد،
پشتیبانی
از swtpm الزامی
است. اگر no
باشد، TPM
غیرفعال
میشود.
افزودهشده
در نسخه 256.
--tpm-state=PATH|auto|off
محل
قرارگیری
وضعیت TPM را در
صورت فعال
بودن
پشتیبانی
از TPM
پیکربندی
میکند (به
--tpm= در بالا
مراجعه
کنید). این
گزینه یک
مسیر مطلق
سیستم فایل
به یک
دایرکتوری
را
میپذیرد
تا وضعیت به
طور پایدار
در آن قرار
گیرد. اگر
دایرکتوری
وجود
نداشته
باشد بر حسب
نیاز ایجاد
میشود. اگر
روی رشته
ویژه "auto"
تنظیم شود،
یک مسیر
پایدار به
طور خودکار
از مسیر
تصویر یا
مسیر
دایرکتوری VM
با افزودن
پسوند ".tpmstate"
مشتق
میشود. اگر
روی رشته
ویژه "off"
تنظیم شود،
وضعیت TPM تنها
به صورت
گذرا
نگهداری
میشود و
هنگام
خاموش شدن VM
پاک
میگردد.
این حالت
برای VMهایی
که کلیدهای
رمزنگاری
دیسک را به TPM
قفل
میکنند
مناسب
نیست، زیرا
این کلیدها
با هر بار
راهاندازی
مجدد از دست
خواهند رفت.
مقدار
پیشفرض "auto"
است.
اگر --ephemeral
مشخص شده
باشد، "auto"
مانند "off"
رفتار
میکند.
افزودهشده
در نسخه 258.
--efi-nvram-template=PATH
یک مسیر
مطلق، یا یک
مسیر نسبی
که با ./ شروع
میشود را
میپذیرد.
مسیر یک
فایل قالب EFI NVRAM
را برای کپی
و استفاده
به عنوان
وضعیت
اولیه NVRAM
متغیرهای EFI
مشخص
میکند. در
صورت مشخص
نشدن، قالب
پیشفرض NVRAM
از تعریف
سفتافزار
کپی و
استفاده
میشود.
افزودهشده
در نسخه 261.
--efi-nvram-state=PATH|auto|off
محل
قرارگیری
وضعیت NVRAM
متغیرهای EFI
را
پیکربندی
میکند. این
گزینه یک
مسیر مطلق
سیستم فایل
به یک فایل
معمولی را
میپذیرد
تا وضعیت به
طور پایدار
در آن قرار
گیرد. اگر
فایل وجود
نداشته
باشد بر حسب
نیاز ایجاد
میشود. اگر
روی رشته
ویژه "auto"
تنظیم شود،
یک مسیر
پایدار به
طور خودکار
از مسیر
تصویر یا
دایرکتوری VM
با افزودن
پسوند ".efinvramstate"
مشتق
میشود. اگر
روی رشته
ویژه "off"
تنظیم شود،
وضعیت NVRAM
متغیرهای EFI
تنها به
صورت گذرا
نگهداری
شده و هنگام
خاموش شدن VM
پاک میشود.
مقدار
پیشفرض "auto"
است.
اگر --ephemeral
مشخص شده
باشد، "auto"
مانند "off"
رفتار
میکند.
افزودهشده
در نسخه 261.
--secure-boot=BOOL
تنظیم
میکند که
آیا جستجو
برای
سفتافزاری
که از
راهاندازی
امن (Secure Boot)
پشتیبانی
میکند
انجام شود
یا خیر. یک
مقدار بولی
یا "auto" را
میپذیرد.
تنظیم این
گزینه روی yes
معادل
--firmware-features=secure-boot است و
تنظیم آن
روی no معادل
--firmware-features=~secure-boot
میباشد.
تنظیم این
گزینه روی
"auto" ویژگی
"secure-boot" را از هر
دو فهرست
ویژگیهای
گنجاندهشده
و
مستثنیشده
حذف میکند.
افزودهشده
در نسخه 255.
--firmware=PATH
انتخاب
میکند که
کدام
سفتافزار
در VM استفاده
شود. یکی از
مقادیر "auto"،
"uefi"، "bios"، "none"،
یک مسیر
مطلق، یا یک
مسیر نسبی
که با ./ شروع
میشود را
میپذیرد.
مقدار
پیشفرض "auto"
است که
سفتافزار UEFI
را انتخاب
میکند مگر
اینکه
--linux= یک
تصویر هسته
غیر PE را مشخص
کند، که در
این صورت "none"
انتخاب
میشود. "uefi"
سفتافزار OVMF
را
بارگذاری
میکند
(برای
انتخاب یک
مورد خاص،
از مسیری به
فایل تعریف
سفتافزار JSON
استفاده
کنید). "bios" از
بارگذاری OVMF
صرفنظر
کرده و به QEMU
اجازه
میدهد از BIOS
داخلی خود
استفاده
کند (مانند SeaBIOS
روی x86). "none"
بارگذاری
سفتافزار
را به طور
کامل
غیرفعال
میکند و
برای بوت
مستقیم
هسته
نیازمند
مشخص شدن
--linux=
است. بوت
کردن یک UKI
نیازمند "uefi"
است. اگر
رشته ویژه
"list" مشخص
شود، تمام
فایلهای
تعریف
سفتافزار
کشفشده
فهرست
میشوند.
اگر رشته
ویژه "describe"
مشخص شود،
سفتافزار UEFI
که (با در نظر
گرفتن
--firmware-features=)
انتخاب
میشد چاپ
شده و
برنامه
خارج
میشود. اگر
یک رشته
خالی مشخص
شود، این
گزینه به
مقدار
پیشفرض
خود
بازنشانی
میشود.
افزودهشده
در نسخه 256.
--firmware-features=FEATURE[,FEATURE...]
فهرستی
از
رشتههای
ویژگیهای
سفتافزار
جداشده با
کاما را
میپذیرد.
این گزینه
را میتوان
چندین بار
مشخص کرد،
که در این
صورت
فهرستهای
ویژگیها
با یکدیگر
ترکیب
میشوند. در
صورت مشخص
شدن، تنها
تعاریف
سفتافزاری
که تمام
ویژگیهای
مورد نیاز
را داشته
باشند در
طول کشف
خودکار
سفتافزار
در نظر
گرفته
خواهند شد.
ویژگیهایی
که با
پیشوند "~"
مشخص شوند
مستثنی
هستند:
سفتافزاری
که چنین
ویژگیای
داشته باشد
نادیده
گرفته
خواهد شد.
اگر یک
ویژگی هم در
فهرست
موارد
گنجاندهشده
و هم در
موارد
مستثنیشده
ظاهر شود،
اولویت با
گنجاندن
است. به طور
پیشفرض،
سفتافزارهایی
که دارای
ویژگی "enrolled-keys"
باشند
مستثنی
میشوند.
اگر یک رشته
خالی ارسال
شود، هر دو
فهرست
ویژگیهای
گنجاندهشده
و
مستثنیشده
بازنشانی
میشوند.
اگر رشته
ویژه "list"
مشخص شود،
تمامی
ویژگیهای
سفتافزار
موجود
فهرست
میشوند.
افزودهشده
در نسخه 261.
--coco=
هشدار:
این ویژگی
آزمایشی
است و
احتمالاً
در
نسخههای
آینده systemd
تغییر
خواهد کرد
(یا به شکل
فعلی خود
حذف خواهد
شد).
پیکربندی
میکند که
آیا مهمان
به عنوان یک
ماشین
مجازی
محرمانه (Confidential VM)
اجرا شود یا
خیر. یکی از
مقادیر "no"
یا "sev-snp" را
میپذیرد.
مقدار
پیشفرض "no"
است.
"sev-snp"
قابلیت AMD SEV-SNP
را فعال
میکند. این
به KVM روی
میزبان x86_64 با
سختافزار
و
سفتافزار
دارای
قابلیت SNP
نیاز دارد.
--firmware= باید به
یک تصویر
خام OVMF
ساختهشده
با SNP به صورت .fd
اشاره کند؛
تفکیک
استاندارد
pflash + NVRAM تحت SNP
پشتیبانی
نمیشود،
بنابراین
سفتافزار
از طریق -bios
دستور QEMU
بارگذاری
میشود و
راهاندازی
امن (Secure Boot) در
دسترس نیست.
اعتبارنامههای
SMBIOS
ارسالشده
از طریق --set-credential=
یا --load-credential= رد
میشوند
زیرا خارج
از
اندازهگیری
راهاندازی
(launch measurement) SNP قرار
دارند. بوت
مستقیم
هسته از
طریق --linux=
الزامی است
تا هسته، initrd و
خط فرمان در
اندازهگیری
راهاندازی
هش شوند
("kernel-hashes=on")؛ بوت
کردن هسته
از روی
تصویر دیسک
از طریق
سفتافزار،
آن را خارج
از
اندازهگیری
باقی
میگذارد.
یک vTPM، در
صورت اتصال
از طریق --tpm=،
باید توسط
مهمان به
عنوان
غیرقابلاعتماد
در نظر
گرفته شود.
افزودهشده
در نسخه 261.
-n, --network-tap
یک
دستگاه TAP
برای
برقراری
ارتباط
شبکهای با
ماشین
مجازی
ایجاد
میکند.
نکته:
استفاده از
شبکه TAP
نیازمند
دسترسی root
است. علاوه
بر این، systemd-networkd(8)
باید روی
میزبان در
حال اجرا و
به درستی
پیکربندی
شده باشد تا
رابط
میزبان را
آمادهسازی
کند. فایل
".network" مربوطه
را میتوان
در /usr/lib/systemd/network/80-vm-vt.network
یافت.
افزودهشده
در نسخه 255.
--network-user-mode
استفاده
از شبکه در
حالت
کاربری.
افزودهشده
در نسخه 255.
--linux=PATH
تصویر
هسته
لینوکس را
برای بوت
مستقیم
هسته تنظیم
میکند. اگر
یک تصویر از
نوع
دایرکتوری
استفاده
شود و
--linux= حذف
شده باشد، vmspawn
با فرض
اینکه XBOOTLDR در /boot
و ESP در /efi قرار
دارند،
ورودیهای
بوتلودر
را مطابق با
مشخصات
بوتلودر UAPI.1[1]
جستجو
خواهد کرد.
اگر هیچ
هستهای در
تصویر نصب
نشده باشد،
بوت تصویر
با شکست
مواجه
میشود.
افزودهشده
در نسخه 256.
--initrd=PATH
initrd مورد
استفاده
برای بوت
مستقیم
هسته را
تنظیم
میکند. اگر
--linux=
ارائهشده
یک ورودی
نوع ۲ از
مشخصات
بوتلودر UAPI.1[1]
باشد، این
آرگومان
لازم نیست.
اگر هیچ initrdای
در تصویر
نصب نشده
باشد، بوت
تصویر با
شکست مواجه
میشود.
--initrd=
میتواند
چندین بار
مشخص شود و vmspawn
آنها را با
یکدیگر
ادغام
خواهد کرد.
افزودهشده
در نسخه 256.
--smbios11=STRING, -s
STRING
رشته
مشخصشده
را به عنوان
رشته
سازنده SMBIOS Type #11
به ماشین
مجازی
ارسال
میکند. این
قابلیت
برای
پارامتربندی
ماشین
مجازی
فراخوانیشده
به روشهای
مختلف مفید
است. برای
جزئیات،
smbios-type-11(7) را
ببینید.
افزودهشده
در نسخه 258.
--notify-ready=
پشتیبانی
از
اعلانها
از فرآیند init
ماشین
مجازی به
systemd-vmspawn را
پیکربندی
میکند. اگر
true باشد،
systemd-vmspawn
تنها زمانی
ماشین را
آماده در
نظر
میگیرد که
پیام "
READY=1" را
از فرآیند init
در ماشین
مجازی
دریافت
کرده باشد.
اگر false باشد،
systemd-vmspawn
بلافاصله
پس از
ایجاد،
ماشین را
آماده تلقی
میکند. در
هر دو حالت،
systemd-vmspawn پس از
آماده شدن
ماشین
مجازی
راهاندازیشده،
اعلان
آمادگی خود
را به مدیر
خود ارسال
میکند.
برای
جزئیات
بیشتر
درباره
اعلانها،
sd_notify(3) را
ببینید.
مقدار
پیشفرض true
است. (توجه
داشته
باشید که
این برعکس
گزینه
همنام در
systemd-nspawn(1) است که
مقدار
پیشفرض آن
false میباشد.)
افزودهشده
در نسخه 258.
-M, --machine=
نام
ماشین را
برای این
ماشین
مجازی
تنظیم
میکند. این
نام
میتواند
برای
شناسایی
این ماشین
مجازی در
طول زمان
اجرای آن
استفاده
شود (برای
مثال در
ابزارهایی
مانند
machinectl(1) و
موارد
مشابه).
افزودهشده
در نسخه 255.
--uuid=
شناسه
یکتای
عمومی (UUID)
مشخصشده
را برای
ماشین
مجازی
تنظیم
میکند.
سیستم init در
صورتی که
فایل /etc/machine-id
هنوز تنظیم
نشده باشد،
آن را از این
مقدار
مقداردهی
اولیه
خواهد کرد.
توجه داشته
باشید که
این گزینه
تنها در
صورتی
اثرگذار
است که /etc/machine-id در
ماشین
مجازی پر
نشده باشد.
افزودهشده
در نسخه 256.
-S, --slice=
ماشین
مجازی را به
جای برش
پیشفرض machine.slice،
به بخشی از
برش (slice)
مشخصشده
تبدیل
میکند. این
گزینه تنها
در صورتی
اعمال
میشود که
ماشین در
واحد اسکوپ
خود اجرا
شود، یعنی
اگر
--keep-unit
استفاده
نشده باشد.
افزودهشده
در نسخه 258.
--property=
یک مشخصه
واحد را روی
واحد اسکوپ
که برای
ماشین ثبت
میشود
تنظیم
میکند. این
گزینه تنها
در صورتی
اعمال
میشود که
ماشین در
واحد اسکوپ
خود اجرا
شود، یعنی
اگر
--keep-unit
استفاده
نشده باشد.
مقداردهی
ویژگیهای
واحد را با
همان قالب
systemctl
set-property
میپذیرد.
این ویژگی
برای تنظیم
محدودیتهای
حافظه و
موارد
مشابه برای
ماشین
مجازی مفید
است.
افزودهشده
در نسخه 258.
--register=
کنترل
میکند که
آیا ماشین
مجازی در
systemd-machined(8) ثبت شود
یا خیر. یک
آرگومان
بولی یا "auto"
را
میپذیرد و
مقدار
پیشفرض آن
"auto" است. این
امر تضمین
میکند که
ماشین
مجازی از
طریق
machinectl(1)
قابل
دسترسی
باشد.
هنگامی که
روی "auto"
تنظیم شود،
ثبتنام
تلاش
میشود اما
از خطاها
صرفنظر
میگردد.
افزودهشده
در نسخه 256.
--private-users=UID_SHIFT[:UID_RANGE]
فضای نام
کاربری را
تحت
--directory=
کنترل
میکند. در
صورت فعال
بودن، به
virtiofsd(1)
دستور داده
میشود که
شناسههای
کاربر و
گروه (UID و GID) را
نگاشت کند.
این کار
شامل نگاشت
UID/GIDهای خصوصی
استفادهشده
در ماشین
مجازی (با
شروع از
کاربر ریشه 0
ماشین
مجازی به
بالا) به
محدودهای
از UID/GIDها در
میزبان است
که برای
مقاصد دیگر
استفاده
نمیشوند
(معمولاً در
محدوده
بالاتر از UID/GID
65536 میزبان).
اگر یک یا
دو عدد
جداشده با
دونقطه
مشخص شوند،
فضای نام
کاربری
فعال
میشود. UID_SHIFT
نخستین UID/GID
میزبان را
برای نگاشت
مشخص
میکند، UID_RANGE
اختیاری
است و تعداد
UID/GIDهای
میزبان را
برای
انتساب به
ماشین
مجازی مشخص
مینماید.
اگر UID_RANGE حذف
شود، ۶۵۵۳۶
مقدار UID/GID
اختصاص
داده
میشود.
هنگام
استفاده از
فضاهای نام
کاربر،
محدوده GID
اختصاصیافته
به هر ماشین
مجازی
همیشه
دقیقاً
برابر با
محدوده UID
انتخاب
میشود.
افزودهشده
در نسخه 256.
--bind=PATH,
--bind-ro=PATH
مانت
کردن یک
دایرکتوری
از میزبان
به داخل
ماشین
مجازی. یکی
از این
موارد را
میپذیرد:
یک آرگومان
مسیر — که
در این صورت
مسیر
مشخصشده
از میزبان
به همان
مسیر در
داخل ماشین
مجازی مانت
میشود، یا
یک جفت مسیر
جداشده با
دونقطه —
که در این
صورت مسیر
نخست منبع
در میزبان و
مسیر دوم
مقصد در
ماشین
مجازی است.
اگر مسیر
منبع مطلق
نباشد،
نسبت به
دایرکتوری
کاری جاری
حل میشود.
گزینه
--bind-ro=
نقاط مانت bind
فقطخواندنی
ایجاد
میکند.
گریزهای
بکاسلش
تفسیر
میشوند،
بنابراین
میتوان از
"\:" برای
گنجاندن
دونقطه در
هر یک از
مسیرها
استفاده
کرد. این
گزینه را
میتوان
چندین بار
برای ایجاد
چندین نقطه
مانت bind مستقل
مشخص نمود.
افزودهشده
در نسخه 256.
--extra-drive=[FORMAT:][DISKTYPE:]PATH
یک تصویر
دیسک یا
دستگاه
بلوکی روی
میزبان را
دریافت
کرده و آن را
به عنوان یک
درایو دیگر
در اختیار
ماشین
مجازی قرار
میدهد. به
صورت
اختیاری،
قالب تصویر
و/یا نوع
دیسک را
میتوان با
پیشوند
کردن
مقادیر
آنها قبل
از مسیر و با
جداسازی
توسط
دونقطه
مشخص کرد.
پیشوندهای
قالب و نوع
دیسک
میتوانند
به هر
ترتیبی
ظاهر شوند.
قالب به طور
پیشفرض "raw"
است و نوع
دیسک به طور
پیشفرض
برابر با
مقدار
--image-disk-type=
(که خود به
طور
پیشفرض
"virtio-blk" است)
میباشد.
توجه داشته
باشید که "qcow2"
تنها برای
فایلهای
معمولی
پشتیبانی
میشود، نه
دستگاههای
بلوکی.
افزودهشده
در نسخه 256.
--bind-volume=PROVIDER:VOLUME[:CONFIG][:K=V,...]
یک حجم
ذخیرهسازی
را از یک
ارائهدهنده
storagectl(1) دریافت
کرده و آن را
به ماشین
مجازی متصل
میکند.
PROVIDER
نام
ارائهدهنده
است
(معمولاً "block"
یا "fs").
VOLUME نام
حجمی است که
به متد
Acquire()
ارائهدهنده
ارسال
میشود.
CONFIG
نوع دستگاه
مهمان را
انتخاب
میکند و
یکی از
مقادیر
"virtio-blk"، "virtio-scsi"،
"nvme" یا "scsi-cd" را
میپذیرد.
در صورت
خالی بودن
یا حذف شدن،
به طور
پیشفرض
"virtio-blk" است.
فهرست
انتهایی K=V
جداشده با
کاما
پارامترهایی
را به
io.systemd.StorageProvider.Acquire()
ارسال
میکند: template=،
create= (یکی از
"any"، "new"، "open")،
read-only= (یا ro=؛ یک
مقدار بولی
یا "auto" را
میپذیرد)،
size= / create-size=
(اندازه
برای
حجمهای
ایجادشده)،
request-as= (یکی از
"blk"، "reg"، "dir"؛
"dir" توسط vmspawn رد
میشود).
هر حجم
متصلشده
با نام
"PROVIDER:VOLUME"
شناسایی
میشود.
حجمهای
متصلشده
در زمان
راهاندازی
از طریق این
گزینه
نمیتوانند
در زمان
اجرا از
طریق machinectl unbind-volume
جدا شوند؛
تنها
حجمهای
اضافهشده
در زمان
اجرا از
طریق machinectl bind-volume
قابل حذف
هستند.
ارائهدهنده
در مسیر
/run/systemd/io.systemd.StorageProvider/ برای
حالت
سیستمی (یا
$XDG_RUNTIME_DIR/systemd/io.systemd.StorageProvider/
برای حالت
کاربری)
جستجو
میشود، که
با محدوده
زمان اجرای
انتخابشده
از طریق --user /
--system مطابقت
دارد.
افزودهشده
در نسخه 261.
--bind-user=
دایرکتوری
خانگی
کاربر
مشخصشده
در میزبان
را به درون
ماشین
مجازی متصل
(bind) میکند.
نام یک
کاربر
موجود در
میزبان را
به عنوان
آرگومان
میپذیرد.
میتواند
چندین بار
برای متصل
کردن چندین
کاربر به
ماشین
مجازی
استفاده
شود. این کار
دو عمل را
انجام
میدهد:
1.دایرکتوری
خانگی
کاربر از
میزبان در
مسیر /run/vmhost/home/ با
استفاده از
virtiofs در دسترس
قرار
میگیرد.
ترجمه
شناسه virtiofsd
برای نگاشت
UID/GID کاربر
میزبان به UID/GID
اختصاصیافته
به آن در
ماشین
مجازی
استفاده
میشود.
2.رکوردهای
کاربری و
گروهی JSON که
کاربر
نگاشتشده
را توصیف
میکنند
تولید شده و
با استفاده
از
اعتبارنامههای
"userdb.transient.*" به
داخل ماشین
مجازی
منتقل
میشوند.
آنها شامل
یک
بازنمایی
کمینهشده
از رکورد
کاربری
میزبان
هستند که با
UID/GID و مسیر
دایرکتوری
خانگی
اختصاصیافته
به کاربر در
ماشین
مجازی
تطبیق داده
شده است.
ماژول
nss-systemd(8)
در glibc NSS این
رکوردها را
از آنجا
دریافت
کرده و در
پایگاههای
داده
کاربر/گروه
ماشین
مجازی در
دسترس قرار
میدهد.
ترکیب دو
عملیات فوق
این امکان
را تضمین
میکند که
ورود به
ماشین
مجازی با
استفاده از
همان
اطلاعات
حساب
کاربری در
میزبان
امکانپذیر
باشد. کاربر
تنها به
صورت گذرا و
تا زمانی که
ماشین
مجازی در
حال اجرا
است نگاشت
میشود، و
خود نگاشت
منجر به
تغییرات
دائمی در
ماشین
مجازی
نمیشود (به
جز
احتمالاً
پیامهای
لاگ
تولیدشده
در هنگام
ورود و
موارد
مشابه). به
ویژه توجه
داشته
باشید که
انتساب UID/GID در
ماشین
مجازی به
صورت دائمی
انجام
نمیشود.
اگر کاربر
به صورت
گذرا نگاشت
شده باشد،
بهتر است
اجازه
اعمال
تغییرات
دائمی در
ماشین
مجازی به وی
داده نشود.
اگر کاربر
فایلها یا
دایرکتوریهایی
متعلق به
خود به جا
بگذارد و آن
UID/GIDها در
فراخوانیهای
بعدی ماشین
مجازی
(احتمالاً
با نگاشت
--bind-user= متفاوت)
بازاستفاده
شوند، آن
فایلها و
دایرکتوریها
برای کاربر
"جدید" در
دسترس
خواهند
بود.
نگاشت
رکورد
کاربر/گروه
تنها در
صورتی کار
میکند که
ماشین
مجازی شامل
systemd نسخه 258 یا
جدیدتر
باشد و nss-systemd
به درستی در
nsswitch.conf
پیکربندی
شده باشد.
برای
جزئیات،
nss-systemd(8) را
ببینید.
توجه
داشته
باشید که
رکورد
کاربری
منتقلشده
از میزبان
به ماشین
مجازی شامل
هش رمز عبور
یونیکس
کاربر
خواهد بود
تا ورود
بدون مشکل
در ماشین
مجازی
امکانپذیر
باشد.
بنابراین
اگر ماشین
مجازی نسبت
به میزبان
کمتر مورد
اعتماد
است،
استفاده از
یک تابع هش
رمز عبور
یونیکس قوی
(مانند yescrypt یا
مشابه آن،
با پیشوند
هش "$y$") اهمیت
دارد.
افزودهشده
در نسخه 259.
--bind-user-shell=
هنگامی
که همراه با
--bind-user= استفاده
شود، پوسته
مشخصشده
را در
رکوردهای
کاربری
کاربران
متصلشده
به ماشین
مجازی
میگنجاند.
یک مقدار
بولی یا یک
مسیر مطلق
را
میپذیرد.
•اگر false
باشد
(پیشفرض)،
هیچ
پوستهای
در
رکوردهای
کاربری
برای
کاربران
متصلشده
به ماشین
مجازی
ارسال
نمیشود.
این امر
باعث
میشود
کاربران
متصلشده
از پوسته
پیشفرض
ماشین
مجازی
استفاده
کنند.
•اگر true
باشد،
پوستههای
مشخصشده
توسط
رکوردهای
کاربری
میزبان در
رکوردهای
کاربری
تمامی
کاربران
متصلشده
به ماشین
مجازی
گنجانده
میشوند.
•اگر یک
مسیر مطلق
ارسال شود،
آن مسیر را
به عنوان
پوسته برای
رکوردهای
کاربری
تمامی
کاربران
متصلشده
به ماشین
مجازی
تنظیم
میکند.
نکته: این
گزینه وجود
پوستههای
مشخصشده
در ماشین
مجازی را
بررسی
نخواهد
کرد.
این
عملیات
تنها در
ترکیب با
--bind-user=
پشتیبانی
میشود.
افزودهشده
در نسخه 259.
--bind-user-group=NAME
هنگامی
که همراه با
--bind-user= استفاده
شود، گروه
مشخصشده
را به عنوان
یک گروه
کمکی در
رکوردهای
کاربری
کاربران
متصلشده
به ماشین
مجازی
میگنجاند.
نام یک گروه
را
میپذیرد.
نکته: این
گزینه وجود
گروههای
مشخصشده
در ماشین
مجازی را
بررسی
نخواهد
کرد.
این
عملیات
تنها در
ترکیب با
--bind-user=
پشتیبانی
میشود.
افزودهشده
در نسخه 259.
--forward-journal=FILE|DIR
هدایت
ژورنال
ماشین
مجازی به
میزبان. در
حال حاضر از
systemd-journal-remote(8) برای
دریافت
مدخلهای
ژورنال
هدایتشده
از VM مهمان
استفاده
میشود. این
گزینه مشخص
میکند که
این ژورنال
در کجای
میزبان
ذخیره شود و
دارای همان
معنایی است
که برای
-o/
--output
در
systemd-journal-remote(8)
توصیف شده
است.
افزودهشده
در نسخه 256.
--forward-journal-max-use=BYTES,
--forward-journal-keep-free=BYTES,
--forward-journal-max-file-size=BYTES,
--forward-journal-max-files=N
--pass-ssh-key=BOOL
به طور
پیشفرض،
یک کلید SSH
برای مجاز
ساختن
systemd-vmspawn
به باز کردن
یک اتصال D-Bus
به گذرگاه systemd
ماشین
مجازی
ایجاد
میشود.
تنظیم این
گزینه روی
"no" تولید
کلید SSH را
غیرفعال
میکند.
کلیدهای
تولیدشده
گذرا
هستند؛ به
این معنا که
تنها برای
فراخوانی
جاری systemd-vmspawn
معتبر
هستند و
معمولاً
ذخیره
دائمی
نمیشوند.
افزودهشده
در نسخه 256.
--ssh-key-type=TYPE
نوع کلید
SSH تولیدی را
پیکربندی
میکند؛
برای
اطلاعات
بیشتر
ssh-keygen(1) را
ببینید.
به طور
پیشفرض
کلیدهای "ed25519"
تولید
میشوند،
با این حال
اگر ماشین
مجازی نسخه
بسیار
قدیمیای
از sshd(8) داشته
باشد،
کلیدهای "rsa"
نیز
میتوانند
مفید
باشند.
افزودهشده
در نسخه 256.
--console=MODE
نحوه
راهاندازی
کنسول
ماشین
مجازی را
پیکربندی
میکند. یکی
از مقادیر
"interactive"، "read-only"،
"native"، "gui" یا
"headless" را
میپذیرد.
مقدار
پیشفرض
"interactive" است. "interactive"
یک رابط
ترمینال
تعاملی به
ماشین
مجازی
ارائه
میدهد. "read-only"
مشابه است،
اما اکیداً
فقطخواندنی
است، یعنی
هیچ ورودی
از کاربر را
نمیپذیرد.
"native" نیز یک
رابط مبتنی
بر TTY ارائه
میدهد،
اما از
پیادهسازی
بومی qemu
استفاده
میکند (که
به معنای در
دسترس بودن
مانیتور qemu
است). "gui" رابط
گرافیکی
کاربر در qemu
را نمایش
میدهد. "headless"
ماشین
مجازی را
بدون
هیچگونه
کنسولی
اجرا
میکند، که
برای
استفاده
خودکار یا
اسکریپتشده
مفید است.
افزودهشده
در نسخه 256.
--console-transport=TRANSPORT
پروتکل
انتقال
مورد
استفاده
برای کنسول
ماشین
مجازی را
پیکربندی
میکند. یکی
از مقادیر
"virtio" یا "serial" را
میپذیرد.
مقدار
پیشفرض "virtio"
است. "virtio" از یک
دستگاه virtio-serial
استفاده
میکند که
به صورت /dev/hvc0 در
ماشین
مجازی ظاهر
میشود. "serial"
از یک درگاه
سریال
معمولی
استفاده
میکند که
به صورت /dev/ttyS0 (یا
/dev/ttyAMA0 در معماری
ARM) در ماشین
مجازی ظاهر
میشود. این
گزینه تنها
در
حالتهای
--console=interactive،
--console=read-only و
--console=native
اثرگذار
است.
افزودهشده
در نسخه 261.
--background=COLOR
رنگ
پسزمینه
ترمینال را
تا زمانی که
ماشین
مجازی در
حال اجرا
است به رنگ ANSI
مشخصشده
تغییر
میدهد. رنگ
مشخصشده
باید یک رنگ
پسزمینه
بر اساس ANSI X3.64 SGR
باشد، یعنی
رشتههایی
مانند "40"،
"41"، ...، "47"،
"48;2;..."، "48;5;...".
برای
جزئیات،
کدهای فرار
ANSI
(ویکیپدیا)[2]
را ببینید.
برای
غیرفعال
کردن
رنگآمیزی
یک رشته
خالی
اختصاص
دهید. این
گزینه تنها
در
حالتهای
--console=interactive و
--console=read-only
اثرگذار
است.
افزودهشده
در نسخه 256.
--load-credential=ID:PATH,
--set-credential=ID:VALUE
ارسال یک
اعتبارنامه
به ماشین
مجازی. این
دو گزینه
متناظر با
تنظیمات
LoadCredential= و
SetCredential= در
فایلهای
واحد هستند.
برای
جزئیات
درباره این
مفاهیم و
همچنین
نحوه نگارش
آرگومانهای
این
گزینهها،
systemd.exec(5) را
ببینید.
به منظور
گنجاندن
دادههای
باینری در
دادههای
اعتبارنامه
برای --set-credential=،
از گریز به
سبک زبان C
استفاده
کنید (یعنی
"\n" برای
گنجاندن خط
جدید، یا "\x00"
برای
گنجاندن یک
بایت NUL).
توجه داشته
باشید که
پوسته
فراخواننده
ممکن است یک
بار
گریززدایی
را اعمال
کند،
بنابراین
ممکن است به
دو بار گریز
دادن نیاز
باشد!
اعتبارنامهها
ترجیحاً از
طریق
رشتههای SMBIOS Type
11 یا
فایلهای fw_cfg
در QEMU به
ماشین
مجازی
منتقل
میشوند.
اگر هیچیک
از این
سازوکارها
در دسترس
نباشد،
اعتبارنامهها
در خط فرمان
هسته با
استفاده از
systemd.set_credential_binary=
ارسال
میشوند که
یک کانال
محرمانه
نیست. در این
حالت از این
روش برای
ارسال
اطلاعات
محرمانه به
ماشین
مجازی
استفاده
نکنید.
افزودهشده
در نسخه 255.
--no-pager
خروجی را
به یک
صفحهبند
لولهکشی
نمیکند.
-h, --help
یک متن
راهنمای
کوتاه را
چاپ کرده و
خارج
میشود.
--version
یک رشته
کوتاه نسخه
برنامه را
چاپ کرده و
خارج
میشود.
--no-ask-password
برای
عملیات
دارای
دسترسی
ویژه از
کاربر
درخواست
احراز هویت
نمیکند.
$SYSTEMD_LOG_LEVEL
حداکثر
سطح لاگ
پیامهای
منتشرشده
(پیامهای
با سطح لاگ
بالاتر،
یعنی
کماهمیتتر،
متوقف
خواهند شد).
فهرستی از
مقادیر
جداشده با
کاما را
میپذیرد.
یک مقدار
میتواند
یکی از
موارد زیر
(به ترتیب
کاهش اهمیت)
باشد:
emerg،
alert،
crit،
err،
warning،
notice،
info،
debug،
یا یک عدد
صحیح در
محدوده 0...7.
برای
اطلاعات
بیشتر
syslog(3) را
ببینید. هر
مقدار
میتواند
به صورت
اختیاری با
یکی از
پیشوندهای
console،
syslog،
kmsg یا
journal همراه با
یک دونقطه
مشخص شود تا
حداکثر سطح
لاگ را برای
آن مقصد خاص
لاگ تنظیم
کند (به
عنوان مثال
SYSTEMD_LOG_LEVEL=debug,console:info مشخص
میکند که
لاگ در سطح debug
ثبت شود مگر
در هنگام
ارسال لاگ
به کنسول که
باید در سطح
info باشد). توجه
داشته
باشید که
حداکثر سطح
لاگ سراسری
بر هر
حداکثر سطح
لاگ
اختصاصی
مقصد
اولویت
دارد.
$SYSTEMD_LOG_COLOR
یک مقدار
بولی. اگر true
باشد،
پیامهای
نوشتهشده
در tty بر اساس
اولویت
رنگآمیزی
میشوند.
این تنظیم
تنها زمانی
مفید است که
پیامها
مستقیماً
در ترمینال
نوشته
شوند، زیرا
journalctl(1) و سایر
ابزارهایی
که لاگها
را نمایش
میدهند،
پیامها را
خود بر اساس
سطح لاگ
رنگآمیزی
میکنند.
$SYSTEMD_LOG_TIME
یک مقدار
بولی. اگر true
باشد،
پیامهای
لاگ کنسول
با یک برچسب
زمانی
پیشوندگذاری
میشوند.
این تنظیم
تنها زمانی
مفید است که
پیامها
مستقیماً
در ترمینال
یا یک فایل
نوشته
شوند، زیرا
journalctl(1) و سایر
ابزارهایی
که لاگها
را نمایش
میدهند،
خود
برچسبهای
زمانی را بر
اساس
فرادادههای
مدخل پیوست
میکنند.
$SYSTEMD_LOG_LOCATION
یک مقدار
بولی. اگر true
باشد،
پیامها با
نام فایل و
شماره خط در
کد منبع که
پیام از آن
سرچشمه
میگیرد،
پیشوندگذاری
میشوند.
توجه
داشته
باشید که
محل لاگ در
هر صورت
اغلب به
عنوان
فراداده به
مدخلهای
ژورنال
پیوست
میشود. با
این حال،
گنجاندن
مستقیم آن
در متن پیام
میتواند
در هنگام
اشکالزدایی
برنامهها
سودمند
باشد.
$SYSTEMD_LOG_TID
یک مقدار
بولی. اگر true
باشد،
پیامها با
شناسه عددی
رشته (TID) جاری
پیشوندگذاری
میشوند.
توجه
داشته
باشید که
این
اطلاعات در
هر صورت به
عنوان
فراداده به
مدخلهای
ژورنال
پیوست
میشود. با
این حال،
گنجاندن
مستقیم آن
در متن پیام
میتواند
در هنگام
اشکالزدایی
برنامهها
سودمند
باشد.
$SYSTEMD_LOG_TARGET
مقصد
پیامهای
لاگ. یکی از
موارد
console
(ثبت در tty
متصلشده)،
console-prefixed (ثبت در tty
متصلشده
اما با
پیشوندهایی
که سطح لاگ و
"facility" را
کدگذاری
میکنند،
syslog(3) را
ببینید)،
kmsg
(ثبت در بافر
حلقوی لاگ
هسته)،
journal
(ثبت در
ژورنال)،
journal-or-kmsg (ثبت در
ژورنال در
صورت موجود
بودن، و در
غیر این
صورت در kmsg)،
auto
(تعیین
خودکار
مقصد لاگ
مناسب،
حالت
پیشفرض)،
null
(غیرفعال
کردن خروجی
لاگ).
$SYSTEMD_LOG_RATELIMIT_KMSG
کنترل
میکند که
آیا نرخ
ارسال پیام
به kmsg محدود
شود یا خیر.
یک مقدار
بولی را
میپذیرد.
مقدار
پیشفرض "true"
است. در صورت
غیرفعال
بودن، systemd نرخ
پیامهای
نوشتهشده
در kmsg را
محدود
نخواهد
کرد.
$SYSTEMD_PAGER, $PAGER
صفحهبندی
که هنگام
مشخص نشدن
--no-pager استفاده
میشود. در
صورت تنظیم
بودن
$SYSTEMD_PAGER از
آن استفاده
میشود؛ در
غیر این
صورت
$PAGER
استفاده
میگردد.
اگر نه
$SYSTEMD_PAGER و
نه
$PAGER تنظیم
نشده
باشند،
مجموعهای
از
پیادهسازیهای
شناختهشده
صفحهبند
به نوبت
آزمایش
میشوند،
از جمله
less(1) و
more(1)، تا
زمانی که
یکی یافت
شود. اگر هیچ
پیادهسازی
صفحهبندی
کشف نشود،
هیچ
صفحهبندی
فراخوانی
نخواهد شد.
تنظیم این
متغیرهای
محیطی روی
یک رشته
خالی یا
مقدار "cat"
معادل
ارسال
--no-pager
است.
نکته: اگر
$SYSTEMD_PAGERSECURE تنظیم
نشده باشد،
$SYSTEMD_PAGER و $PAGER
تنها
میتوانند
برای
غیرفعال
کردن
صفحهبند
(با "cat" یا "")
استفاده
شوند، و در
غیر این
صورت
نادیده
گرفته
میشوند.
$SYSTEMD_LESS
بازنویسی
گزینههای
ارسالشده
به
less (به طور
پیشفرض "FRSXMK").
کاربران
ممکن است به
ویژه تمایل
داشته
باشند دو
گزینه را
تغییر
دهند:
K
این
گزینه به
صفحهبند
دستور
میدهد که
با فشردن Ctrl+C
بلافاصله
خارج شود.
برای اجازه
دادن به
less
جهت مدیریت
Ctrl+C توسط خود
برای
بازگشت به
خط فرمان
صفحهبند،
این گزینه
را حذف کنید.
اگر مقدار
$SYSTEMD_LESS شامل "K"
نباشد و
صفحهبند
فراخوانیشده
less باشد، Ctrl+C
توسط
برنامه
اجرایی
نادیده
گرفته
میشود و
باید توسط
صفحهبند
مدیریت
گردد.
X
این
گزینه به
صفحهبند
دستور
میدهد
رشتههای
مقداردهی
اولیه و لغو
مقداردهی
اولیه termcap را
به ترمینال
ارسال نکند.
این گزینه
به طور
پیشفرض
تنظیم شده
است تا
خروجی
دستور حتی
پس از خروج
از
صفحهبند
در ترمینال
قابل
مشاهده
باقی بماند.
با این
وجود، این
کار مانع از
عملکرد
برخی از
قابلیتهای
صفحهبند
میشود، به
ویژه خروجی
صفحهبندیشده
را
نمیتوان
با ماوس
پیمایش
کرد.
توجه
داشته
باشید که
تنظیم
متغیر
محیطی
معمولی $LESS
هیچ تاثیری
بر
فراخوانیهای
less توسط
ابزارهای systemd
ندارد.
برای بحث
بیشتر less(1) را
ببینید.
$SYSTEMD_LESSCHARSET
بازنویسی
مجموعه
نویسه
ارسالشده
به
less (به طور
پیشفرض
"utf-8"، اگر
ترمینال
فراخواننده
سازگار با UTF-8
تشخیص داده
شود).
توجه
داشته
باشید که
تنظیم
متغیر
محیطی
معمولی $LESSCHARSET
هیچ تاثیری
بر
فراخوانیهای
less توسط
ابزارهای systemd
ندارد.
$SYSTEMD_PAGERSECURE
دستورات
رایج
صفحهبند
مانند
less(1)،
علاوه بر
«صفحهبندی»،
یعنی
پیمایش در
خروجی، از
باز کردن یا
نوشتن در
فایلهای
دیگر و
اجرای
دستورات
دلخواه
پوسته
پشتیبانی
میکنند.
هنگامی که
دستورات با
امتیازات
بالا،
مثلاً تحت
sudo(8) یا
pkexec(1)
فراخوانی
میشوند،
صفحهبند
به یک مرز
امنیتی
تبدیل
میشود.
باید دقت
شود که تنها
برنامههای
با
قابلیتهای
کاملاً
محدود به
عنوان
صفحهبند
استفاده
شوند و
ویژگیهای
تعاملی
ناخواسته
مانند باز
کردن یا
ایجاد
فایلهای
جدید یا
راهاندازی
زیرفرآیندها
مجاز
نباشند.
«حالت امن»
(secure mode) برای
صفحهبند
ممکن است
همانطور
که در زیر
توضیح داده
شده فعال
شود،
اگر
صفحهبند
از آن
پشتیبانی
کند (بیشتر
صفحهبندها
به گونهای
نوشته
نشدهاند
که این
موضوع را در
نظر بگیرند).
توصیه
میشود در
هنگام
اجازه دادن
به کاربران
غیرقابلاعتماد
برای اجرای
دستورات با
دسترسیهای
بالا، یا
«حالت امن»
را صراحتاً
فعال کنید
یا
صفحهبند
را با
استفاده از
--no-pager یا
PAGER=cat به
طور کامل
غیرفعال
نمایید.
این گزینه
یک آرگومان
بولی
میپذیرد.
در صورت
تنظیم روی
true، «حالت
امن»
صفحهبند
فعال
میشود. در
«حالت
امن»، LESSSECURE=1
هنگام
فراخوانی
صفحهبند
تنظیم
خواهد شد که
به
صفحهبند
دستور
میدهد
دستوراتی
را که
فایلهای
جدید باز
میکنند یا
ایجاد
مینمایند
یا
زیرفرآیندهای
جدیدی را
آغاز
میکنند
غیرفعال
کند. در حال
حاضر تنها
less(1) شناخته
شده است که
این متغیر
را درک کرده
و «حالت
امن» را
پیادهسازی
میکند.
در صورت
تنظیم روی
false، هیچ
محدودیتی
بر روی
صفحهبند
اعمال
نمیشود.
تنظیم SYSTEMD_PAGERSECURE=0
یا حذف
نکردن آن از
محیط به ارث
رسیده ممکن
است به
کاربر
اجازه دهد
دستورات
دلخواه را
فراخوانی
کند.
هنگامی که
$SYSTEMD_PAGERSECURE تنظیم
نشده باشد،
ابزارهای systemd
تلاش
میکنند به
طور خودکار
تشخیص دهند
که آیا
«حالت امن»
باید فعال
شود و آیا
صفحهبند
از آن
پشتیبانی
میکند یا
خیر. در
صورتی که UID
موثر با
مالک نشست
ورود یکسان
نباشد ( geteuid(2) و
sd_pid_get_owner_uid(3) را
ببینید)، یا
هنگام اجرا
تحت sudo(8) یا
ابزارهای
مشابه (که در
آنها $SUDO_UID
تنظیم شده
است [3])،
«حالت امن»
فعال
میشود. در
این موارد،
SYSTEMD_PAGERSECURE=1 تنظیم
خواهد شد و
صفحهبندهایی
که شناخته
نشدهاند
«حالت امن»
را
پیادهسازی
کنند اصلاً
استفاده
نخواهند شد.
توجه داشته
باشید که
این تشخیص
خودکار
تنها
رایجترین
سازوکارها
را برای
ارتقای
امتیاز
پوشش
میدهد و به
عنوان یک
تسهیل در
نظر گرفته
شده است.
توصیه
میشود که
صراحتاً
$SYSTEMD_PAGERSECURE را
تنظیم کرده
یا
صفحهبند
را غیرفعال
کنید.
توجه
داشته
باشید که
اگر قرار
است
متغیرهای
$SYSTEMD_PAGER یا $PAGER به
جز برای
غیرفعال
کردن
صفحهبند
رعایت
شوند، $SYSTEMD_PAGERSECURE
نیز باید
تنظیم شده
باشد.
$SYSTEMD_COLORS
یک
آرگومان
بولی یا یک
مقدار خاص
را
میپذیرد.
به طور
پیشفرض
(تنظیمنشده)،
systemd و
ابزارهای
وابسته در
صورت امکان
از رنگها
در خروجی
خود
استفاده
خواهند کرد.
اگر
$COLORTERM روی
"truecolor" یا "24bit"
تنظیم شده
باشد،
رنگهای ۲۴
بیتی فعال
میشوند،
در غیر این
صورت ۲۵۶
رنگ فعال
خواهد شد،
مگر اینکه
$NO_COLOR یا
$TERM
نشان دهد که
رنگها
غیرفعال
هستند.
true
همانند
حالت
تنظیمنشده
است، با این
تفاوت که $NO_COLOR
نادیده
گرفته
میشود.
false
خروجی
تکرنگ
خواهد بود.
"16", "256", "24bit"
به ترتیب
همیشه از ۱۶
رنگ پایه ANSI،
۲۵۶ رنگ یا
رنگ ۲۴ بیتی
استفاده
میکند.
"auto-16", "auto-256",
"auto-24bit"
از تعداد
رنگهای
دادهشده
با توجه به
$TERM و آنچه
کنسول به آن
متصل است
استفاده
میکند.
$SYSTEMD_URLIFY
مقدار
باید یک
بولی باشد.
کنترل
میکند که
آیا
پیوندهای
قابل کلیک
در خروجی
برای
شبیهسازهای
ترمینالی
که از این
قابلیت
پشتیبانی
میکنند
تولید شود
یا خیر. این
گزینه را
میتوان
برای
بازنویسی
تصمیمی که
systemd بر اساس $TERM
و سایر
شرایط
میگیرد
مشخص کرد.
مثال ۱. اجرای
یک تصویر
ماشین
مجازی Arch Linux
تولیدشده
توسط mkosi
$ mkosi -d arch -p systemd -p linux --autologin -o image.raw -f build
$ systemd-vmspawn --image=image.raw
مثال ۲. وارد
کردن و
اجرای یک
تصویر Fedora 44 Cloud با
استفاده از
importctl
$ curl -L \
-O https://download.fedoraproject.org/pub/fedora/linux/releases/44/Cloud/x86_64/images/Fedora-Cloud-Base-Generic-44-1.7.x86_64.qcow2 \
-O https://download.fedoraproject.org/pub/fedora/linux/releases/44/Cloud/x86_64/images/Fedora-Cloud-44-1.7-x86_64-CHECKSUM \
-O https://fedoraproject.org/fedora.gpg
$ gpgv --keyring ./fedora.gpg Fedora-Cloud-44-1.7-x86_64-CHECKSUM
$ sha256sum -c Fedora-Cloud-44-1.7-x86_64-CHECKSUM
# importctl import-raw -m Fedora-Cloud-Base-Generic-44-1.7.x86_64.qcow2 fedora-44-cloud
# systemd-vmspawn -M fedora-44-cloud
مثال ۳. ساخت
و اجرای
تصویر
سیستمی systemd و
هدایت
ژورنال
ماشین
مجازی به یک
فایل محلی
$ mkosi build
$ systemd-vmspawn \
-D mkosi.output/system \
--private-users $(grep $(whoami) /etc/subuid | cut -d: -f2) \
--linux mkosi.output/system.efi \
--forward-journal=vm.journal \
enforcing=0
نکته: این
مثال
همچنین از
یک آرگومان
خط فرمان
هسته برای
اطمینان از
راهاندازی
نشدن SELinux در
حالت
اجباری (enforcing)
استفاده
میکند.
مثال ۴. اتصال
SSH به یک
ماشین
مجازی در
حال اجرا با
استفاده از
systemd-ssh-proxy
$ mkosi build
$ my_vsock_cid=3735928559
$ systemd-vmspawn \
-D mkosi.output/system \
--private-users $(grep $(whoami) /etc/subuid | cut -d: -f2) \
--linux mkosi.output/system.efi \
--vsock-cid $my_vsock_cid \
enforcing=0
$ ssh root@vsock/$my_vsock_cid -i /run/user/$UID/systemd/vmspawn/machine-*-system-ed25519
