homectl - کنترل
سرویس
دایرکتوریهای
خانگی
کاربر (systemd-homed)
homectl [OPTIONS...] {COMMAND} [NAME...]
از homectl
میتوان
برای
ایجاد،
حذف، تغییر
یا بازرسی
دایرکتوری
خانگی
کاربر
استفاده
کرد. این
ابزار
اساساً
دستوری
برای تعامل
با systemd-homed.service(8) است
که
دایرکتوریهای
خانگی
کاربران را
مدیریت
میکند.
دایرکتوریهای
خانگی
مدیریتشده
توسط systemd-homed.service
خودکفا (self-contained)
هستند و
بنابراین
رکورد کامل
فرادادههای
کاربر را در
خود فضای
ذخیرهسازی
دادههای
دایرکتوری
خانگی
نگهداری
میکنند،
که این امر
مهاجرت و
انتقال
آنها را
میان
ماشینهای
مختلف آسان
میسازد.
بهطور
خاص، یک
دایرکتوری
خانگی یک
رکورد
کاربری
متناظر را
توصیف
میکند، و
هر رکورد
کاربری
مدیریتشده
توسط systemd-homed.service
نیز به
معنای وجود
و
کپسولهسازی
یک
دایرکتوری
خانگی است.
بدین ترتیب
حساب
کاربری و
دایرکتوری
خانگی به
مفهومی
یکسان
تبدیل
میشوند.
مکانیسمهای
ذخیرهسازی
پشتیبان
زیر
پشتیبانی
میشوند:
•یک فایل
لوپبک (loopback)
رمزشده LUKS2
اختصاصی
برای کاربر
که در /home/*.home
ذخیره
میشود.
هنگام
ورود،
سیستمفایل
موجود در
این
فایلها پس
از ضمیمه
شدن حجم
رمزشده LUKS2
سوار (mount)
میشود.
گذرواژه
کاربر با
عبارتعبور
رمزنگاری
حجم LUKS2 یکسان
است. بدین
ترتیب
دسترسی به
دادهها
بدون احراز
هویت قبلی
کاربر، حتی
برای مدیر
سیستم نیز
امکانپذیر
نیست. این
مکانیسم
ذخیرهسازی
قویترین
امنیت داده
را فراهم
میکند و
بنابراین
توصیه
میشود.
•مشابه
مورد قبل،
اما
سیستمفایل
رمزشده LUKS2
روی یک
دستگاه
بلوکی
عادی،
مانند یک
حافظه فلش USB
قرار دارد.
در این
حالت،
دایرکتوریهای
خانگی و
تمامی
دادههای
درون آنها
به سادگی با
وصل کردن
فلش USB به
سیستمهای
مختلف در
زمانهای
گوناگون،
میان
ماشینها
قابلانتقال
خواهند
بود.
•یک
دایرکتوری
رمزشده با
استفاده از
"fscrypt" روی
سیستمفایلهایی
که از آن
پشتیبانی
میکنند (در
حال حاضر
اساساً "ext4")،
واقع در /home/*.homedir.
این
مکانیسم
نیز
رمزنگاری
فراهم
میکند،
اما به
میزان
قابلتوجهی
ضعیفتر از
LUKS2 است، زیرا
بیشتر
فرادادههای
سیستمفایل
محافظتنشده
باقی
میمانند.
علاوه بر
این، در حال
حاضر پس از
ایجاد
دایرکتوری
خانگی از
تغییر
گذرواژه
کاربر
پشتیبانی
نمیکند.
•یک
زیرحجم (subvolume)
متعلق به "btrfs"
برای هر
کاربر،
واقع در /home/*.homedir.
این روش
هیچگونه
رمزنگاری
ارائه
نمیدهد،
اما
پشتیبانی
خوبی از
سهمیهبندی
دیسک (quota)
دارد.
•یک
دایرکتوری
معمولی
برای هر
کاربر،
واقع در /home/*.homedir.
این روش
رمزنگاری
ارائه
نمیدهد،
اما یک
راهکار
جایگزین (fallback)
مناسب و
دردسترس
روی همه
ماشینها
است، حتی
جاهایی که
پشتیبانی
از LUKS2، "fscrypt" یا
"btrfs" موجود
نیست.
•یک
اشتراک
فایل
ویندوز (CIFS)
اختصاصی
برای هر
کاربر.
توجه
داشته
باشید که
systemd-homed.service و homectl
حسابهای
کاربری
«سنتی»
یونیکس که
با useradd(8) یا
ابزارهای
مشابه
ساخته
شدهاند را
مدیریت
نمیکنند.
بهویژه،
این قابلیت
برای
مدیریت
کاربران
سیستمی
(یعنی
کاربرانی
با شناسه
کاربری UID
کمتر از
۱۰۰۰) مناسب
نبوده و
منحصراً
برای
کاربران
عادی
(«انسانی»)
است.
توجه
داشته
باشید
کاربران و
دایرکتوریهای
خانگی که از
طریق systemd-homed.service
مدیریت
میشوند،
در /etc/passwd و
فایلهای
مشابه ظاهر
نمیشوند؛
آنها در
زمان اجرا
توسط NSS
مربوط به glibc
ترکیب و
ساخته
میشوند. از
این رو
قابلشناسایی
بوده و
میتوان
آنها را از
طریق ابزار
getent(1) فهرست
کرد.
این ابزار
مستقیماً
با systemd-homed.service
ارتباط
برقرار
میکند و
میتواند
دستورات
خاصی را روی
دایرکتوریهای
خانگی که
مدیریت
میکند
اجرا نماید.
از آنجا که
هر
دایرکتوری
خانگی که به
این شیوه
مدیریت
میشود یک
رکورد
کاربر و
گروه JSON نیز
تعریف
میکند،
این
دایرکتوریهای
خانگی را
میتوان از
طریق userdbctl(1)
نیز بررسی و
فهرست کرد.
دایرکتوریهای
خانگی
مدیریتشده
توسط systemd-homed.service
معمولاً در
یکی از دو
حالت یا در
یک وضعیت
گذار میان
آنها قرار
دارند: در
حالت "active"
(فعال) آنها
قفلگشایی
و سوار (mount) شده
و در نتیجه
برای سیستم
و
برنامههای
آن
قابلدسترسی
هستند؛ در
حالت "inactive"
(غیرفعال)
سوار نشده و
در دسترس
نیستند.
فعالسازی
بهطور
خودکار
هنگام ورود
کاربر رخ
میدهد و
معمولاً
تنها پس از
ارائه
گذرواژه (یا
توکن احراز
هویت دیگر)
تکمیل
میشود.
غیرفعالسازی
پس از خروج
کامل کاربر
انجام
میپذیرد.
یک
دایرکتوری
خانگی تا
زمانی که
کاربر
دستکم یک
بار وارد
سیستم شده
باشد (یعنی
حداقل یک
نشست ورود
داشته باشد)
فعال باقی
میماند.
هنگامی که
کاربر برای
بار دوم
بهصورت
همزمان
وارد شود،
دایرکتوری
خانگی فعال
باقی
میماند.
این
دایرکتوری
تنها پس از
پایان
آخرین نشست
کاربر
غیرفعال
میشود.
گزینههای
عمومی زیر
پشتیبانی
میشوند
(گزینههای
بیشتری که
ویژگیهای
مختلف
رکوردهای
کاربری
مدیریتشده
توسط systemd-homed.service را
کنترل
میکنند،
در بخشهای
پایینتر
مستند
شدهاند):
--identity=FILE
رکورد JSON
کاربر را از
فایل
مشخصشده
میخواند.
اگر
بهصورت "-"
داده شود،
رکورد
کاربر را از
ورودی
استاندارد
میخواند.
شیء JSON
ارائهشده
باید از
ساختار
مستندشده
در
JSON User Records[1]
پیروی کند.
این گزینه
میتواند
همراه با
دستورات
create
و
update (در
ادامه
مشاهده
کنید)
استفاده
شود، جایی
که امکان
پیکربندی
مستقیم
رکورد
کاربر را در
قالب JSON
بههمان
شکل اصلی
فراهم
میکند،
بهجای
تنظیم
تکتک
ویژگیهای
رکورد
کاربر (به
زیر مراجعه
کنید).
افزودهشده
در نسخه 245.
--json=FORMAT, -j
در صورت
استفاده از
دستور
inspect (در
ادامه
ببینید)،
نمایش
خروجی
رکورد
کاربر در
قالب JSON را
کنترل
میکند. یکی
از مقادیر
"pretty" (خوانا)،
"short" (کوتاه) یا
"off" (خاموش) را
میپذیرد.
اگر "pretty"
باشد،
فاصلهها و
خطوط جدید
مناسب برای
خوانایی
بهتر
دادههای JSON
در خروجی
درج
میشوند.
اگر "short"
باشد، تمام
فاصلههای
اضافی حذف
میشوند.
اگر "off"
(پیشفرض)
باشد،
اطلاعات
کاربر در
قالب JSON نمایش
داده
نمیشود
بلکه با
قالببندی
خوانا برای
انسان
ارائه
میگردد.
گزینه
-j
هنگام
اجرای
تعاملی
مقدار "pretty" و
در غیر این
صورت "short" را
انتخاب
میکند.
افزودهشده
در نسخه 245.
--export-format=FORMAT, -E,
-EE
هنگام
استفاده
همراه با
دستور
inspect در
حالت JSON (در
بالا
ببینید)،
میتوان از
آن برای حذف
برخی
جنبههای
رکورد JSON
کاربر در
خروجی
استفاده
کرد. بهطور
مشخص، اگر
قالب "stripped"
استفاده
شود،
فیلدهای binding و
runtime از رکورد
حذف
میشوند.
اگر قالب "minimal"
به کار رود،
امضای
رمزنگاریشده
نیز حذف
میشود. اگر
قالب "full"
استفاده
شود، رکورد
کامل JSON نمایش
داده
میشود (این
حالت
پیشفرض
است). این
گزینه برای
رونوشتبرداری
از یک رکورد
کاربری
موجود به
سیستمی
دیگر جهت
ایجاد
کاربری
مشابه با
همان
تنظیمات
مفید است.
بهطور خاص:
homectl inspect -EE | ssh root@othersystem homectl create -i-
میتواند
به عنوان یک
خط فرمان
ساده برای
همانندسازی
(replication) یک کاربر
روی
میزبانی
دیگر
استفاده
شود.
-E معادل
-j --export-format=stripped،
-EE
معادل
-j --export-format=minimal
است. توجه
داشته
باشید که
هنگام
همانندسازی
حسابهای
کاربری،
رکوردهای
کاربری
بهدستآمده
در حالت "stripped"
امضاهای
رمزنگاریشده
اصلی را حفظ
میکنند و
بنابراین
تنها زمانی
قابلتغییر
هستند که
کلید خصوصی
لازم برای
بهروزرسانی
آنها در
ماشین مقصد
موجود باشد.
هنگام
همانندسازی
کاربران در
حالت "minimal"،
امضا در حین
فرآیند حذف
میشود و در
نتیجه
رکورد به
طور ضمنی با
کلید ماشین
مقصد امضا
خواهد شد و
میتواند
بدون نیاز
به انتقال
کلید
خصوصی، در
آنجا
بهروزرسانی
شود.
افزودهشده
در نسخه 245.
--offline
برای
بهروزرسانی
نسخه رکورد
کاربری و
دایرکتوری blob
تعبیهشده
در داخل
ناحیه
خانگی
تلاشی
نمیکند.
این امر
امکان
انجام
عملیات روی
نواحی
خانگی که
غایب
(غیرفعال/ناموجود)
هستند یا
بدون نیاز
به احراز
هویت به
عنوان
کاربری که
در حال
تغییر است
را فراهم
میسازد.
افزودهشده
در نسخه 256.
--key-name=
هنگام
استفاده
همراه با
دستور
add-signing-key،
نامی را که
کلید عمومی
در حال
افزودهشدن
تحت آن
ذخیره
میشود،
مشخص یا
بازنویسی
میکند. نام
مشخصشده
میتواند
آزادانه
انتخاب
شود، اما
باید دارای
پسوند ".public"
باشد. اگر
این گزینه
استفاده
نشود، نام
از نام فایل
مشخصشده
مشتق
میگردد.
اگر کلید از
ورودی
استاندارد
خوانده
شود، این
گزینه برای
ارائه نامی
مناسب برای
کلید در حال
اضافه شدن
الزامی است.
افزودهشده
در نسخه 258.
--seize=
یک
آرگومان
بولی
میپذیرد.
هنگام
استفاده
همراه با
create
یا
register، حذف
امضاهای
رمزنگاریشده
از
رکوردهای
کاربری JSON
ارائهشده
را کنترل
میکند، که
این امر اثر
امضای
آنها با
کلید امضای
محلی (local.public) به
جای امضای
قبلی را
دارد. اگر
این سوییچ
روی true تنظیم
شود،
رکوردهای
کاربری
اضافه شده
به صورت
محلی
مدیریت
میشوند (و
بنابراین
میتوان
آنها را
بهصورت
محلی تغییر
داد)، در
حالی که اگر
روی false تنظیم
شود،
رکوردهای
کاربری
همچنان
توسط مبدا
اصلی خود
مدیریت و
کنترل
میشوند (و
بنابراین
به صورت
محلی
قابلتغییر
نیستند). این
سوییچ برای
create بهطور
پیشفرض true و
برای
register
بهطور
پیشفرض false
است.
افزودهشده
در نسخه 258.
--prompt-new-user
اگر
همراه با
firstboot
استفاده
شود و تا این
لحظه هیچ
حساب
کاربری
عادی روی
سیستم وجود
نداشته
باشد، این
ابزار
اطلاعات
کاربر را به
صورت
تعاملی
درخواست
کرده و
حسابی
ایجاد
میکند.
افزودهشده
در نسخه 256.
--prompt-shell=
یک
آرگومان
بولی
میپذیرد.
در صورت
استفاده از
firstboot --prompt-new-user،
درخواست
تعاملی
برای
انتخاب
پوسته ورود
(login shell) را کنترل
میکند.
مقدار
پیشفرض آن true
است.
افزودهشده
در نسخه 259.
--prompt-groups=
یک
آرگومان
بولی
میپذیرد.
در صورت
استفاده از
firstboot --prompt-new-user،
درخواست
تعاملی
برای
گروههای
کمکی جهت
افزودن
کاربر جدید
به آنها را
کنترل
میکند.
مقدار
پیشفرض آن true
است.
افزودهشده
در نسخه 259.
--chrome=
یک
آرگومان
بولی
میپذیرد.
بهطور
پیشفرض،
صفحه ایجاد
تعاملی
کاربر از
طریق
firstboot --prompt-new-user
نوارهای
تزئینی ("chrome")
با رنگ
معکوس را در
بالا و
پایین صفحه
ترمینال
نمایش
میدهد، که
با تنظیم
این گزینه
روی false
میتوان
آنها را
غیرفعال
کرد.
افزودهشده
در نسخه 259.
--mute-console=
یک
آرگومان
بولی
میپذیرد.
اگر روی true
تنظیم شود،
خروجی
گزارش
وقایع (log)
هسته و
خروجی
وضعیت مدیر
سرویس به
کنسول
سیستم در
زمان اجرای
firstboot --prompt-new-user
بهطور
موقت
غیرفعال
میشود تا
در خروجی آن
وقفهای
ایجاد
نگردد.
مقدار
پیشفرض آن
false است.
افزودهشده
در نسخه 259.
--match=this|other|any|auto, -A, -N,
-T
گزینه
--match=
یکی از
مقادیر "this"،
"other"، "any" یا "auto"
را
میپذیرد.
برخی از
تنظیمات
رکورد
کاربر
میتوانند
طوری تعریف
شوند که فقط
با
ماشینهای
خاص، یا همه
ماشینها
به جز یکی،
یا همه
ماشینها
مطابقت
داشته
باشند. با
این سوییچ
میتوان
کنترل کرد
که تنظیمات
بعد از آن در
خط فرمان
روی کدام
ماشینها
اعمال شود.
اگر "this" مشخص
شود، تنظیم
فقط روی
سیستم محلی
اعمال
میشود
(تطابق
مثبت)؛ اگر
"other" باشد،
روی همه
سیستمها
به جز سیستم
محلی اعمال
خواهد شد
(تطابق
منفی)؛ اگر
"any" باشد،
روی همه
سیستمها
اعمال
میشود (مگر
اینکه یک
تنظیم
تطابق مثبت
یا منفی
برای هر
ماشین مشخص
شده باشد).
اگر "auto"
باشد، به
منطق
پیشفرض
بازمیگردد:
اینکه آیا
یک تنظیم
بهطور
پیشفرض
برای سیستم
محلی اعمال
شود یا همه
سیستمها،
به گزینه
مورد نظر
بستگی دارد.
توجه
داشته
باشید که
تنها برخی
از تنظیمات
رکورد
کاربر را
میتوان به
این صورت
شرطی کرد.
این گزینه
روی سایر
تنظیمات
تأثیری
ندارد و
نادیده
گرفته
میشود. این
گزینه ممکن
است چندین
بار در یک خط
فرمان برای
اعمال
تنظیمات
مشروط با
تطابقهای
مختلف به
همان رکورد
کاربر ظاهر
شود. برای
جزئیات در
مورد اینکه
کدام
تنظیمات
ممکن است با
چنین تطابق
برای هر
ماشین
استفاده
شوند و کدام
یک
نمیتوانند،
به JSON User Records[1]
مراجعه
کنید.
-A
میانبری
برای --match=any، -T
کوتاهشده
--match=this و -N
کوتاهشده
--match=other است.
در اینجا
نمونهای
از یک
فراخوانی
آورده شده
است که فیلد
storage را روی
سیستم محلی
به "luks" اما در
سایر
سیستمها
به "cifs" تنظیم
میکند:
# homectl update lennart -T --storage=luks -N --storage=cifs
افزودهشده
در نسخه 258.
-H, --host=
عملیات
را از راه
دور اجرا
میکند. یک
نام
میزبان، یا
نام کاربری
و نام
میزبان
جداشده با
"@" را برای
اتصال مشخص
کنید. نام
میزبان
میتواند
به صورت
اختیاری
دارای
پسوند
درگاه گوش
دادن ssh
جداشده با
":" و سپس نام
یک کانتینر
جداشده با
"/" باشد، که
مستقیماً
به کانتینر
مشخصشده
روی میزبان
مورد نظر
متصل
میشود. این
کار از SSH برای
گفتگو با
نمونه مدیر
ماشین راه
دور
استفاده
میکند.
نامهای
کانتینر را
میتوان با
machinectl -H HOST
فهرست کرد.
آدرسهای IPv6
را داخل
کروشه قرار
دهید.
-M, --machine=
عملیات
را روی یک
کانتینر
محلی اجرا
میکند. نام
کانتینری
را برای
اتصال مشخص
کنید، که
میتواند
به صورت
اختیاری
دارای
پیشوند نام
کاربری
برای اتصال
و نویسه
جداکننده "@"
باشد. اگر
رشته ویژه
".host" به جای
نام
کانتینر
استفاده
شود،
اتصالی به
سیستم محلی
برقرار
میشود (که
برای اتصال
به گذرگاه
کاربری یک
کاربر خاص
مفید است: "--user
--machine=lennart@.host"). اگر
نحو "@"
استفاده
نشود،
اتصال با
کاربر root
برقرار
میشود. اگر
نحو "@"
استفاده
شود، سمت چپ
یا سمت راست
ممکن است
حذف شوند
(اما نه هر
دو)، که در
این صورت
نام کاربری
محلی و ".host" در
نظر گرفته
میشوند.
--no-pager
خروجی را
به یک
صفحهبند (pager)
هدایت
نمیکند.
--no-legend
راهنمای
علائم (legend)،
یعنی
سرایند
ستونها و
پانوشت
حاوی نکات
را چاپ
نمیکند.
--no-ask-password
برای
عملیات
دارای
دسترسی
ویژه از
کاربر
درخواست
احراز هویت
نمیکند.
-h, --help
متن
راهنمای
کوتاهی را
چاپ کرده و
خارج
میشود.
--version
رشته
نسخه
کوتاهی را
چاپ کرده و
خارج
میشود.
گزینههای
زیر
ویژگیهای
مختلف
رکوردهای
کاربر/دایرکتوریهای
خانگی را که
systemd-homed.service مدیریت
میکند،
کنترل
مینمایند.
این
سوییچها
ممکن است
همراه با
دستورات create
و update برای
پیکربندی
جنبههای
مختلف
دایرکتوری
خانگی و
حساب
کاربری
استفاده
شوند:
--real-name=NAME, -c NAME
نام
واقعی
کاربر. این
فیلد
متناظر با
فیلد GECOS در
رکوردهای
کلاسیک NSS
یونیکس است.
افزودهشده
در نسخه 245.
--realm=REALM
قلمرو (realm)
برای کاربر.
قلمرو
کاربر را به
سازمان یا
سیستم
نصبشده
خاصی مرتبط
میسازد و
امکان
تمایز
کاربران
همنام
تعریفشده
در بسترهای
مختلف را
فراهم
میکند.
قلمرو
میتواند
هر رشتهای
باشد که به
عنوان یک
نام دامنه DNS
معتبر نیز
واجد شرایط
باشد، و
توصیه
میشود که
از نام
دامنه
سازمان یا
زیرساخت
برای این
منظور
استفاده
شود، اما
این موضوع
الزامی یا
اجباری
نیست. در هر
سیستم فقط
یک کاربر
منفرد با
همان نام
میتواند
وجود داشته
باشد، و اگر
کاربری با
همان نام و
قلمرو دیده
شود، فرض
میشود که
به همان
کاربر
اشاره
دارد، در
حالی که
کاربری با
همان نام
اما قلمرو
متفاوت یک
کاربر مجزا
تلقی
میشود.
توجه داشته
باشید که
این بدان
معناست که
وجود دو
کاربر با
نام یکسان
اما
قلمروهای
مجزا روی یک
سیستم مجاز
نیست.
اختصاص یک
قلمرو به
کاربر
اختیاری
است.
افزودهشده
در نسخه 245.
--alias=NAME[,NAME...]
نامهای
اضافی برای
کاربر. یک یا
چند نام
کاربری
معتبر
یونیکس را
که با کاما
از هم جدا
شدهاند،
میپذیرد.
میتواند
چندین بار
برای تعریف
چندین نام
مستعار
استفاده
شود. نام
کاربری
مستعار را
میتوان در
هر جایی که
نام کاربری
اصلی
قابلمشخصکردن
باشد مشخص
کرد و به
همان رکورد
کاربری
ارجاع داده
میشود.
افزودهشده
در نسخه 258.
--email-address=EMAIL
یک آدرس
پست
الکترونیکی
را برای
پیوند دادن
به کاربر
میپذیرد.
هنگام
ورود،
متغیر
محیطی
$EMAIL از
این مقدار
مقداردهی
اولیه
میشود.
افزودهشده
در نسخه 245.
--location=TEXT
مشخصات
مکان را
برای این
کاربر
دریافت
میکند. این
یک متن آزاد
است که ممکن
است برای
برنامههای
موقعیتیابی
جغرافیایی
قابلاستفاده
باشد یا
نباشد. مثال:
--location="Berlin, Germany" یا
--location="Basement, Room 3a"
افزودهشده
در نسخه 245.
--birth-date=[DATE]
تاریخ
تولد کاربر
را در قالب
تقویم
استاندارد ISO
8601 ("YYYY-MM-DD")
میپذیرد.
اولین سال
قابلنمایش
1900 است. اگر یک
رشته خالی
منتقل شود،
تاریخ تولد
بازنشانی
شده و لغو
میگردد.
افزودهشده
در نسخه 261.
--icon-name=ICON
نام
آیکونی را
برای
ارتباط با
کاربر طبق
طرح
تعریفشده
توسط
Icon Naming Specification[2]
میپذیرد.
افزودهشده
در نسخه 245.
--home-dir=PATH,
-dPATH
مسیری را
برای
استفاده به
عنوان
دایرکتوری
خانگی
کاربر
میپذیرد.
توجه داشته
باشید که
این
دایرکتوری
همان
پوشهای
است که
دایرکتوری
خانگی
کاربر در
زمان ورود
به آن سوار (mount)
میشود. این
مسیر جایی
نیست که
دادههای
کاربر
واقعاً در
آن ذخیره
میشوند،
برای آن
موضوع به
--image-path=
مراجعه
کنید. در
صورت عدم
تعیین،
مقدار
پیشفرض آن
/home/$USER است.
افزودهشده
در نسخه 245.
--uid=UID
یک شناسه
کاربری
عددی
یونیکس (UID)
ترجیحی را
برای
انتساب به
این کاربر
میپذیرد.
اگر قرار
باشد
کاربری با UID
مشخصشده
ایجاد شود و
این شناسه
قبلاً توسط
کاربر
دیگری در
سیستم محلی
گرفته شده
باشد،
ایجاد
دایرکتوری
خانگی رد
میشود. با
این حال
توجه داشته
باشید اگر
پس از ایجاد
دایرکتوری
خانگی، از
آن در سیستم
دیگری
استفاده
شود و UID
پیکربندیشده
توسط کاربر
دیگری در
آنجا گرفته
شده باشد،
آنگاه
systemd-homed
ممکن است UID
متفاوتی را
در آن سیستم
به کاربر
اختصاص دهد.
شناسه
کاربری
مشخصشده
باید خارج
از محدوده
کاربران
سیستمی
باشد. توصیه
میشود از
محدوده UID بین
60001...60513 برای این
منظور
استفاده
شود. در صورت
عدم تعیین، UID
به صورت
خودکار
انتخاب
میشود. اگر
هنگام ورود
مشخص شود که
مالکیت
دایرکتوری
خانگی
متعلق به UID
متفاوتی
است،
مالکیت
دایرکتوری
خانگی و همه
موارد زیر
آن پیش از
تکمیل ورود
به طور
خودکار
تغییر
خواهد کرد.
توجه
داشته
باشید که
تغییر این
گزینه برای
دایرکتوریهای
خانگی
موجود
معمولاً
روی
دایرکتوریهای
خانگی که
قبلاً به
صورت محلی
ثبت
شدهاند
(دارای binding
محلی هستند)
اثری
ندارد،
زیرا UID
استفادهشده
برای یک
حساب در
سیستم محلی
زمانی
تعیین
میشود که
دایرکتوری
خانگی برای
اولین بار
روی آن فعال
گردد، و سپس
تا زمان حذف
دایرکتوری
خانگی
معتبر باقی
میماند.
توجه
داشته
باشید که
کاربران
مدیریتشده
توسط systemd-homed
همواره
دارای یک
گروه
متناظر با
همان نام و
همچنین یک GID
منطبق بر UID
کاربر
هستند.
بنابراین،
پیکربندی GID
بهصورت
جداگانه
مجاز نیست.
افزودهشده
در نسخه 245.
--member-of=GROUP, -G GROUP
فهرستی
از
گروههای
کمکی
یونیکس
جداشده با
کاما را که
این کاربر
باید به
آنها تعلق
داشته
باشد،
میپذیرد.
مثال:
--member-of=wheel
برای اعطای
امتیازات
مدیریتی به
کاربر. توجه
داشته
باشید که
systemd-homed
هیچ گروهی
را به جز
گروهی که از
نظر نام و UID/GID
عددی با
کاربر
همخوانی
دارد،
مدیریت
نمیکند.
بنابراین
هر گروهی که
در اینجا
فهرست شده
باشد باید
به طور
مستقل، به
عنوان مثال
با
groupadd(8) ثبت
شده باشد. هر
گروه
ناموجودی
نادیده
گرفته
میشود. این
گزینه ممکن
است بیش از
یک بار
استفاده
شود، که در
این صورت
تمام
فهرستهای
گروهی
مشخصشده
با یکدیگر
ترکیب
میشوند.
اگر کاربر
در حال حاضر
عضو گروهی
باشد که در
این فهرست
نیامده
است، کاربر
از آن گروه
حذف خواهد
شد.
افزودهشده
در نسخه 245.
--capability-bounding-set=CAPABILITIES,
--capability-ambient-set=CAPABILITIES
این
گزینهها
فهرستی از
قابلیتهای
فرآیند (process capabilities)
جداشده با
فاصله
(مانند
CAP_WAKE_ALARM،
CAP_BLOCK_SUSPEND و غیره)
را
میپذیرند
که باید در
مجموعههای
توانمندی
مرزی (bounding) و
فراگیر (ambient)
برای تمام
نشستهای
کاربر
تنظیم شوند.
برای
جزئیات
بیشتر
درباره
مفهوم
قابلیتها
به
capabilities(7)
مراجعه
کنید. این
گزینهها
ممکن است
بیش از یک
بار
استفاده
شوند، که در
این صورت
فهرستهای
مشخصشده
ترکیب
میشوند.
اگر
پارامتر با
نویسه "~"
شروع شود،
اثر آن
معکوس
میگردد:
یعنی
قابلیت
مشخصشده
از مجموعه
مربوطه حذف
(سلب) میشود.
افزودهشده
در نسخه 254.
--access-mode=MODE
یک حالت
دسترسی به
فایل
یونیکس را
در مبنای
هشت (اکتال)
میپذیرد.
حالت
دسترسی خود
دایرکتوری
خانگی را
پیکربندی
میکند.
توجه داشته
باشید که
این گزینه
فقط زمانی
استفاده
میشود که
دایرکتوری
برای اولین
بار ایجاد
شود، و
کاربر
میتواند
پس از آن هر
زمان که
بخواهد آن
را تغییر
دهد. مثال:
--access-mode=0700
افزودهشده
در نسخه 245.
--umask=MASK
ماسک
حالت
دسترسی (در
قالب اکتال)
را جهت
اعمال به
فایلها و
دایرکتوریهای
تازهساختهشده
کاربر
دریافت
میکند ("umask").
در صورت
تنظیم، umask
اولیه
تنظیمشده
برای تمام
نشستهای
ورود کاربر
را کنترل
کرده و
احتمالاً
مقادیر
پیشفرض
سیستم را
بازنویسی
مینماید.
افزودهشده
در نسخه 245.
--skel=PATH
یک مسیر
سیستمفایل
به یک
دایرکتوری
را دریافت
میکند.
دایرکتوری
اسکلت (skeleton) را
برای
مقداردهی
اولیه
دایرکتوری
خانگی مشخص
میکند.
تمام
فایلها و
دایرکتوریهای
موجود در
مسیر
مشخصشده
در هر
دایرکتوری
خانگی
تازهساختهشده
رونوشتبرداری
میشوند. در
صورت عدم
تعیین،
مقدار
پیشفرض آن
/etc/skel/ است.
افزودهشده
در نسخه 245.
--shell=SHELL
یک مسیر
سیستمفایل
را
میپذیرد.
باینری
پوسته را
برای اجرا
در هنگام
ورود به
ترمینال
مشخص
میکند. در
صورت عدم
تعیین،
مقدار
پیشفرض آن
/bin/bash است.
افزودهشده
در نسخه 245.
--setenv=VARIABLE[=VALUE]
یک
مقداردهی
متغیر
محیطی را
برای تنظیم
در تمامی
فرآیندهای
کاربر
میپذیرد.
میتواند
چندین بار
برای تنظیم
چندین
متغیر
محیطی
استفاده
شود. هنگامی
که "=" و
VALUE حذف
شوند،
مقدار
متغیری با
همین نام در
محیط
برنامه
استفاده
خواهد شد.
توجه
داشته
باشید که
تعدادی از
تنظیمات
دیگر نیز
منجر به
تنظیم
متغیرهای
محیطی برای
کاربر
میشوند،
از جمله --email=،
--timezone= و --language=.
افزودهشده
در نسخه 245.
--timezone=TIMEZONE
نام مکان
منطقه
زمانی را که
منطقه
زمانی
کاربر
مشخصشده
را تعیین
میکند،
دریافت
مینماید.
هنگامی که
کاربر وارد
سیستم
میشود،
متغیر
محیطی
$TZ از
این تنظیم
مقداردهی
اولیه
میگردد.
مثال:
--timezone=Europe/Amsterdam
منجر به
متغیر
محیطی "
TZ=:Europe/Amsterdam"
میشود. (":"
بهصورت
عمدی به
عنوان بخشی
از مشخصات
منطقه
زمانی
استفاده
شده است، به
tzset(3) مراجعه
کنید.)
افزودهشده
در نسخه 245.
--language=LANG
فهرستی
از
زبانهای
مورد نظر
کاربر را که
با کاما یا
دونقطه از
هم جدا
شدهاند و
بر اساس
اولویت
نزولی مرتب
شدهاند،
دریافت
میکند.
متغیرهای
محیطی
$LANG و
$LANGUAGE هنگام
ورود از این
مقدار
مقداردهی
اولیه
میشوند و
از این رو
مقادیر
مناسب برای
این
متغیرهای
محیطی در
اینجا
پذیرفته
میشوند،
به عنوان
مثال
--language=de_DE.UTF-8.
این گزینه
ممکن است
بیش از یک
بار
استفاده
شود که در
این صورت
فهرستهای
زبان با
یکدیگر
الحاق
میشوند.
افزودهشده
در نسخه 245.
--default-area=AREA
رشتهای
را دریافت
میکند که
یک «ناحیه»
(area)
دایرکتوری
خانگی را
برای
استفاده به
عنوان
پیشفرض
مشخص
میسازد.
نواحی،
دایرکتوریهای
خانگی
ثانویه در
داخل
دایرکتوری
خانگی اصلی
یک کاربر
هستند.
هنگام ورود
به سیستم،
کاربر
میتواند
ناحیهای
را که مایل
است به آن
وارد شود
مشخص کند،
که این امر
اطمینان
حاصل
میکند
متغیر
محیطی
$HOME روی
~/Areas/ با پسوند
نام ناحیه
تنظیم شود.
برای
جزئیات
بیشتر در
مورد مفهوم
ناحیه به
pam_systemd_home(8) مراجعه
کنید. توجه
داشته
باشید که
این گزینه
فقط
پیشفرض را
تعیین
میکند که
میتواند
در زمان
ورود
بازنویسی
شود.
هنگامی که
این گزینه
با یک رشته
خالی به
عنوان
مقدار مشخص
شود، هر
ناحیه
پیشفرضی
که قبلاً
اعلان شده
باشد از
رکورد
کاربر حذف
خواهد شد.
افزودهشده
در نسخه 258.
--ssh-authorized-keys=KEYS
یا یک خط
کلید مجاز SSH
را برای
انتساب به
رکورد
کاربر
میپذیرد
یا کاراکتر
"@" به همراه
مسیری به یک
فایل را
برای
خواندن یک
یا چند خط از
این دست
دریافت
میکند.
کلیدهای SSH که
از این طریق
پیکربندی
میشوند در
اختیار SSH
قرار
میگیرند
تا اجازه
دسترسی به
این
دایرکتوری
خانگی و
رکورد
کاربر را
صادر کند.
این گزینه
میتواند
بیش از یک
بار برای
پیکربندی
چندین کلید SSH
استفاده
شود.
اضافهشده
در نسخه 245.
--pkcs11-token-uri=URI
یک نشانی
RFC 7512 PKCS#11 URI دریافت
میکند که
به یک توکن
امنیتی
(مانند YubiKey یا
کارت
هوشمند PIV)
اشاره دارد
که قادر به
باز کردن
قفل حساب
کاربری
خواهد بود.
نشانی توکن
امنیتی
باید به یک
توکن
امنیتی با
دقیقاً یک
جفت گواهی X.509
و کلید
خصوصی
اشاره کند.
سپس یک کلید
مخفی
تصادفی
تولید شده،
با کلید
عمومی
گواهی X.509
رمزگذاری
میشود و به
عنوان بخشی
از رکورد
کاربر
ذخیره
میگردد. در
زمان ورود،
این کلید با
ماژول PKCS#11
رمزگشایی
شده و سپس
برای باز
کردن قفل
حساب و
منابع
مرتبط
استفاده
میشود.
برای
مشاهده
نمونهای
از نحوه
راهاندازی
احراز هویت
با یک توکن
امنیتی، به
بخشهای
زیر مراجعه
کنید.
به جای یک PKCS#11
URI معتبر،
رشتههای
ویژه "list" و "auto"
میتوانند
مشخص شوند.
اگر "list"
ارسال شود،
جدول
کوتاهی از
توکنهای
سختافزاری
PKCS#11 مناسب و
متصل فعلی
به همراه
نشانیهای URI
آنها نمایش
داده
میشود. اگر
"auto" ارسال
شود، یک
توکن
سختافزاری
PKCS#11 مناسب به
صورت
خودکار
انتخاب
میشود (اگر
دقیقاً یک
توکن مناسب
کشف نشود،
این عملیات
با شکست
مواجه
خواهد شد).
مورد دوم یک
میانبر
مفید برای
رایجترین
حالت است که
در آن تنها
یک توکن
سختافزاری
PKCS#11 متصل است.
توجه
داشته
باشید که
بسیاری از
توکنهای
امنیتی
سختافزاری
هم PKCS#11/PIV و هم FIDO2
با افزونه
"hmac-secret" را
پیادهسازی
میکنند (به
عنوان مثال:
سری YubiKey 5)،
همانطور
که با گزینه
--fido2-device= در زیر
پشتیبانی
میشود. هر
دو سازوکار
به یک
اندازه
قدرتمند
هستند،
هرچند FIDO2
فناوری
مدرنتری
است.
توکنهای PKCS#11/PIV
این مزیت را
دارند که
قبل از
احراز هویت
قابل
شناسایی
هستند و
بنابراین
میتوانند
برای
استنتاج
هویت کاربر
جهت ورود
استفاده
شوند، چیزی
که FIDO2 اجازه
آن را
نمیدهد.
دستگاههای
PKCS#11/PIV عموماً
قبل از
استفاده
نیازمند
مقداردهی
اولیه
هستند (یعنی
ذخیره یک
جفت کلید
عمومی/خصوصی
روی آنها،
مثال زیر را
ببینید)؛
توکنهای
امنیتی FIDO2
معمولاً به
آن نیازی
ندارند و
بدون
پیکربندی
اضافی کار
میکنند.
اضافهشده
در نسخه 245.
--fido2-credential-algorithm=STRING
الگوریتم
COSE مورد
استفاده در
تولید
اطلاعات
کاربری را
مشخص
میکند.
مقدار
پیشفرض "es256"
است. مقادیر
پشتیبانیشده
عبارتند از
"es256"، "rs256" و "eddsa".
"es256" بیانگر
ECDSA روی NIST P-256 با SHA-256
است. "rs256"
بیانگر RSA
۲–۰۴۸ بیتی
با پدینگ PKCS#1.5 و
SHA-256 است. "eddsa"
بیانگر EDDSA
روی Curve25519 با SHA-512
است.
توجه
داشته
باشید که
احرازکننده
شما ممکن
است از برخی
الگوریتمها
پشتیبانی
نکند.
اضافهشده
در نسخه 251.
--fido2-device=PATH
مسیری به
یک دستگاه
"hidraw" لینوکس
(مانند /dev/hidraw1)
دریافت
میکند که
به یک توکن
امنیتی FIDO2 با
پیادهسازی
افزونه "hmac-secret"
اشاره دارد
و قادر به
باز کردن
قفل حساب
کاربر
خواهد بود.
یک مقدار
سالت
تصادفی روی
میزبان
تولید شده و
به دستگاه FIDO2
ارسال
میشود؛
دستگاه با
استفاده از
یک کلید
مخفی
داخلی، هش HMAC
سالت را
محاسبه
میکند.
نتیجه سپس
به عنوان
کلید برای
باز کردن
قفل حساب
کاربری
استفاده
میشود.
سالت
تصادفی در
رکورد
کاربر
گنجانده
میشود تا
هر زمان که
احراز هویت
لازم بود،
دوباره به
توکن FIDO2
ارسال گردد.
به جای یک
مسیر معتبر
به دستگاه
"hidraw" مربوط به
FIDO2، میتوان
رشتههای
ویژه "list" و "auto"
را مشخص کرد.
اگر "list"
ارسال شود،
جدول
کوتاهی از
دستگاههای
FIDO2 مناسب
کشفشده
نمایش داده
میشود. اگر
"auto" ارسال
شود، در
صورتی که
دقیقاً یک
توکن کشف
شده باشد،
توکن FIDO2
مناسب به
صورت
خودکار
انتخاب
میشود.
مورد دوم یک
میانبر
مفید برای
رایجترین
حالت است که
در آن تنها
یک توکن
سختافزاری
FIDO2 متصل است.
توجه
داشته
باشید
دستگاههای
FIDO2 مناسب
برای این
گزینه باید
افزونه "hmac-secret"
را
پیادهسازی
کرده باشند.
اکثر
دستگاههای
فعلی (مانند
سری YubiKey 5) این
کار را
انجام
میدهند.
اگر این
افزونه
پیادهسازی
نشده باشد،
دستگاه
نمیتواند
برای باز
کردن قفل
دایرکتوریهای
خانگی
استفاده
شود.
دستگاه FIDO2
را میتوان
متعاقباً
با تنظیم
مسیر
دستگاه روی
یک رشته
خالی حذف
کرد (به
عنوان مثال
homectl update $USER --fido2-device="").
توجه
داشته
باشید که
بسیاری از
توکنهای
امنیتی
سختافزاری
هم FIDO2 و هم PKCS#11/PIV
را
پیادهسازی
میکنند (و
بنابراین
میتوانند
با هر یک از
گزینههای
--fido2-device= یا --pkcs11-token-uri=
استفاده
شوند)، برای
بحث بیشتر
به توضیحات
بالا
مراجعه
کنید.
اضافهشده
در نسخه 246.
--fido2-with-client-pin=BOOL
هنگام
ثبت توکن
امنیتی FIDO2،
تعیین
میکند که
آیا هنگام
باز کردن
قفل حساب،
کاربر ملزم
به وارد
کردن یک پین
(PIN) باشد یا
خیر (ویژگی
"clientPin" در FIDO2).
مقدار
پیشفرض "yes"
است. (توجه:
اگر توکن
امنیتی
اصلاً از
ویژگی "clientPin"
پشتیبانی
نکند، یا
اجازه فعال
یا غیرفعال
کردن آن را
ندهد، این
تنظیم
بیاثر
خواهد بود.)
اضافهشده
در نسخه 249.
--fido2-with-user-presence=BOOL
هنگام
ثبت توکن
امنیتی FIDO2،
تعیین
میکند که
آیا کاربر
هنگام باز
کردن قفل
حساب ملزم
به تایید
حضور (لمس
توکن،
ویژگی "up" در
FIDO2) باشد یا
خیر. مقدار
پیشفرض "yes"
است. (توجه:
اگر توکن
امنیتی
اصلاً از
ویژگی "up"
پشتیبانی
نکند، یا
اجازه فعال
یا غیرفعال
کردن آن را
ندهد، این
تنظیم
بیاثر
خواهد بود.)
اضافهشده
در نسخه 249.
--fido2-with-user-verification=BOOL
هنگام
ثبت توکن
امنیتی FIDO2،
تعیین
میکند که
آیا هنگام
باز کردن
قفل حساب به
تایید هویت
کاربر
(ویژگی "uv" در
FIDO2) نیاز است
یا خیر.
مقدار
پیشفرض "no"
است. (توجه:
اگر توکن
امنیتی
اصلاً از
ویژگی "uv"
پشتیبانی
نکند، یا
اجازه فعال
یا غیرفعال
کردن آن را
ندهد، این
تنظیم
بیاثر
خواهد بود.)
اضافهشده
در نسخه 249.
--recovery-key=BOOL
یک
آرگومان
بولی
میپذیرد.
در صورت
فعال بودن،
یک کلید
بازیابی
برای حساب
پیکربندی
میشود.
کلید
بازیابی یک
کلید
دسترسی
تولیدشده
توسط
رایانه است
که در صورت
فراموشی
گذرواژه یا
گم شدن توکن
احراز
هویت،
میتواند
برای
بازیابی
دسترسی به
حساب
استفاده
شود. این
کلید تولید
شده و روی
صفحه نمایش
داده
میشود، و
باید چاپ
شده یا به
مکان امنی
انتقال
یابد. برای
باز کردن
قفل حساب
میتوان به
جای
گذرواژه
معمولی از
یک کلید
بازیابی
استفاده
کرد.
اضافهشده
در نسخه 247.
--blob=PATH, -b PATH,
--blob=FILENAME=PATH, -b
FILENAME=PATH
یا مسیر
یک
دایرکتوری
را
میپذیرد،
یا یک نام
فایل که به
دنبال آن
مسیر فایل
آمده است.
اگر فقط
مسیر یک
دایرکتوری
مشخص شود،
کل
دایرکتوری blob
کاربر با
مسیر
مشخصشده
جایگزین
میشود.
توجه داشته
باشید که
این
جایگزینی
قبل از
اعمال
دستکاریهای
تکتک
فایلها
انجام
میشود، به
این معنی که
این
تغییرات
تکفایلی
روی
دایرکتوری
مشخصشده
اعمال
خواهند شد.
اگر یک نام
فایل و مسیر
فایل مشخص
شود، فایل blob
مشخصشده
با مسیر
مشخصشده
بازنویسی
خواهد شد.
اگر کاملاً
خالی
گذاشته
شود، کل
دایرکتوری blob
تخلیه
میشود (که
تمام
فلگهای
قبلی مربوط
به blob تا این
نقطه را نیز
بازنشانی
میکند). اگر
یک نام فایل
مشخص شود
اما مسیر
مربوطه
خالی باشد،
آن فایل از
دایرکتوری blob
حذف خواهد
شد. تمام
تغییرات
روی
رونوشتهای
موقت از
فایلها در
دایرکتوریها
انجام
میشود، به
این معنی که
فایلهای
اصلی
مشخصشده
در خط فرمان
دستکاری
نمیشوند.
برای کسب
اطلاعات
بیشتر
درباره
دایرکتوریهای
blob به
User Record Blob Directories[3]
مراجعه
کنید.
اضافهشده
در نسخه 256.
--avatar=PATH,
--login-background=PATH
یک مسیر
فایل
دریافت
میکنند. در
صورت
تنظیم،
فایل
مشخصشده
برای
بازنویسی
فایل
مربوطه در
دایرکتوری blob
کاربر
استفاده
میشود. در
صورت خالی
بودن، فایل
مربوطه از
دایرکتوری blob
حذف
میگردد. در
اصل، این
گزینهها
میانبرهایی
برای
--blob=FILENAME=PATH
برای نام
فایلهای
شناختهشده
تعریفشده
در
User Record Blob Directories[3]
هستند.
اضافهشده
در نسخه 256.
--locked=BOOLEAN
یک
آرگومان
بولی
میپذیرد.
مشخص
میکند که
آیا این
حساب
کاربری
باید قفل
شود یا خیر.
در صورت
درست (true)
بودن، ورود
به این حساب
ممنوع است و
در صورت
نادرست (false -
مقدار
پیشفرض)
بودن، ورود
مجاز خواهد
بود (البته
تنها در
صورتی که
احراز مجوز
به شکل دیگر
موفقیتآمیز
باشد).
اضافهشده
در نسخه 245.
--not-before=TIMESTAMP,
--not-after=TIMESTAMP
این
گزینهها
یک رشته
برچسب
زمانی در
قالب
مستندشده
در
systemd.time(7)
دریافت
کرده و
مقاطع
زمانی را
پیکربندی
میکنند که
قبل و بعد از
آنها ورود
به این حساب
مجاز نیست.
اضافهشده
در نسخه 245.
--rate-limit-interval=SECS,
--rate-limit-burst=NUMBER
یک
محدودیت
نرخ برای
تلاشهای
احراز هویت
این کاربر
پیکربندی
میکند. اگر
کاربر بیش
از تعداد
مشخصشده
روی یک
سیستم خاص
در بازه
زمانی
تعیینشده
برای احراز
هویت تلاش
کند، احراز
هویت تا
زمان سپری
شدن آن بازه
زمانی رد
خواهد شد.
مقدار
پیشفرض ۱۰
بار در هر ۱
دقیقه است.
اضافهشده
در نسخه 245.
--password-hint=TEXT
یک
راهنمای
گذرواژه
دریافت
میکند تا
در کنار
رکورد
کاربر
ذخیره شود.
این رشته
فقط برای
کاربران
مجاز و خود
کاربر قابل
دسترسی است
و توسط سایر
کاربران
قابل
پرسوجو
نیست. مثال:
--password-hint="My first pet's name".
اضافهشده
در نسخه 245.
--enforce-password-policy=BOOL, -P
یک
آرگومان
بولی
میپذیرد.
مشخص
میکند که
آیا سیاست
گذرواژه
سیستم در
رابطه با
کیفیت و
استحکام
گذرواژههای
انتخابی
برای این
کاربر
اعمال شود
یا خیر.
مقدار
پیشفرض
فعال (on) است.
-P
کوتاهشده
گزینه
--enforce-password-policy=no
است.
اضافهشده
در نسخه 245.
--password-change-now=BOOL
یک
آرگومان
بولی
میپذیرد.
در صورت true
بودن، در
ورود بعدی
از کاربر
خواسته
میشود
گذرواژه
خود را
تغییر دهد.
اضافهشده
در نسخه 245.
--password-change-min=TIME,
--password-change-max=TIME,
--password-change-warn=TIME,
--password-change-inactive=TIME
هر یک از
این
گزینهها
یک مشخصه
بازه زمانی
به عنوان
آرگومان (در
ساختار
نحوی
مستندشده
در
systemd.time(7))
میپذیرند
و جنبههای
مختلفی از
سیاست
انقضای
گذرواژه
کاربر را
پیکربندی
میکنند. به
طور مشخص،
--password-change-min=
پیکربندی
میکند که
پس از تغییر
گذرواژه
کاربر، چه
مدت زمان
باید سپری
شود تا
بتوان
دوباره
گذرواژه را
تغییر داد.
اگر کاربر
قبل از سپری
شدن این
زمان تلاش
کند
گذرواژه را
تغییر دهد،
درخواست رد
میشود.
--password-change-max= تعیین
میکند چه
مدت پس از
تغییر،
گذرواژه
منقضی شده و
باید
مجدداً
تغییر یابد.
پس از سپری
شدن این
زمان، ورود
تنها پس از
تغییر
گذرواژه
ممکن خواهد
بود.
--password-change-warn=
مشخص
میکند چه
مدت زودتر
از زمان
پیکربندیشده
با
--password-change-max= در
هنگام ورود
به کاربر
هشدار داده
شود که
گذرواژهاش
به زودی
منقضی
میشود. در
نهایت،
--password-change-inactive= مدت
زمانی را که
پس از
انقضای
گذرواژه
باید سپری
شود تا دیگر
به کاربر
اجازه ورود
یا تغییر
گذرواژه
داده نشود،
پیکربندی
میکند.
توجه داشته
باشید که
این
گزینهها
تنها برای
احراز هویت
با گذرواژه
اعمال
میشوند و
برای سایر
اشکال
احراز هویت
(مانند
احراز هویت
با توکن
امنیتی
مبتنی بر PKCS#11)
کاربرد
ندارند.
اضافهشده
در نسخه 245.
--disk-size=BYTES
یک
اندازه به
بایت را به
عنوان
آرگومان
دریافت
میکند
(احتمالاً
با
پسوندهای
متداول K, M, G, ... بر
مبنای
۱۰۲۴)، یا یک
مقدار
درصدی، یا
رشتههای
ویژه "min" یا
"max"، و فضای
دیسک
اختصاصیافته
به کاربر را
پیکربندی
میکند. اگر
یک مقدار
درصدی مشخص
شود (یعنی
آرگومان
همراه با
پسوند "%"
باشد)، نسبت
به فضای
دیسک موجود
در
فایلسیستم
پشتیبان در
نظر گرفته
میشود. اگر
به عنوان "min"
مشخص شود،
حداقل فضای
دیسک مجاز
تحت
محدودیتهای
فایلسیستم
پشتیبان و
سایر
محدودیتها
را اختصاص
میدهد، و
اگر به
عنوان "max"
مشخص شود،
حداکثر
فضای دیسک
موجود را
اختصاص
میدهد. اگر
بکاند LUKS2
استفاده
شود، این
گزینه
اندازه
فایل loopback و
فایلسیستم
درون آن را
پیکربندی
میکند.
برای سایر
بکاندهای
ذخیرهسازی،
سهمیه دیسک
را با
استفاده از
منطق
سهمیهبندی
بومی
فایلسیستم
(در صورت
موجود بودن)
پیکربندی
میکند. اگر
مشخص نشود،
برای
بکاند LUKS2 به
طور
پیشفرض
روی ۸۵٪
فضای دیسک
موجود و
برای
سایرین
بدون سهمیه
تنظیم
میشود.
اضافهشده
در نسخه 245.
--nice=NICE
اولویت
زمانبندی
عددی ("سطح nice")
را برای
اعمال روی
فرایندهای
کاربر در
هنگام ورود
دریافت
میکند. یک
مقدار عددی
در بازه ۲۰-
(بالاترین
اولویت) تا
۱۹
(پایینترین
اولویت)
میپذیرد.
اضافهشده
در نسخه 245.
--rlimit=LIMIT=VALUE[:VALUE]
پیکربندی
محدودیتهای
منابع برای
فرایندهای
این کاربر
را
امکانپذیر
میسازد؛
برای
جزئیات به
getrlimit(2) مراجعه
کنید. یک نام
محدودیت
منبع (مانند
"LIMIT_NOFILE") به
همراه یک
علامت
مساوی و سپس
یک مقدار
عددی
محدودیت را
دریافت
میکند. به
صورت
اختیاری،
میتوان یک
مقدار عددی
دوم را با
علامت
دونقطه جدا
کرده و مشخص
نمود. اگر دو
مقدار مشخص
شود، به
ترتیب به
محدودیتهای
نرم و سخت
اشاره دارد.
اگر فقط یک
مقدار مشخص
شود، هر دو
محدودیت به
صورت یکجا
تنظیم
میشوند.
اضافهشده
در نسخه 245.
--tasks-max=TASKS
یک عدد
صحیح بدون
علامت غیر
صفر به
عنوان
آرگومان
دریافت
میکند.
حداکثر
تعداد
تسکها
(یعنی
رشتهها،
که در آن هر
فرایند
حداقل یک
رشته است) را
که کاربر
میتواند
در هر لحظه
داشته باشد
پیکربندی
میکند. این
محدودیت
برای تمام
تسکهای
منشعبشده
از
نشستهای
کاربر
اعمال
میشود،
حتی اگر
هویت کاربر
را از طریق
su(1) یا ابزاری
مشابه
تغییر دهند.
از
--rlimit=LIMIT_NPROC= برای
قرار دادن
محدودیت بر
روی
تسکهایی
که واقعاً
تحت UID کاربر
اجرا
میشوند
استفاده
کنید، تا
بدین ترتیب
فرایندهای
فرزندی که
هویت کاربر
را تغییر
دادهاند
مستثنی
شوند. این
گزینه
تنظیم
TasksMax= را
در واحد
اسلایس systemd
برای هر
کاربر یعنی
user-$UID.slice کنترل
میکند.
برای
جزئیات
بیشتر به
systemd.resource-control(5)
مراجعه
کنید.
اضافهشده
در نسخه 245.
--memory-high=BYTES,
--memory-max=BYTES
محدودیتی
را بر حسب
بایت برای
حافظهای
که یک کاربر
میتواند
در هر لحظه
روی سیستم
اشغال کند
تنظیم
میکند
(پسوندهای
معمول K, M, G, ... بر
مبنای ۱۰۲۴
پشتیبانی
میشوند).
این شامل
تمام حافظه
مصرفی توسط
خود کاربر و
تمامی
فرایندهای
منشعبشده
توسط او که
اعتبارنامه
کاربری را
تغییر
دادهاند
میشود. این
گزینهها
تنظیمات
MemoryHigh=
و
MemoryMax= را در
واحد
اسلایس systemd
برای هر
کاربر یعنی
user-$UID.slice کنترل
میکنند.
برای
جزئیات
بیشتر به
systemd.resource-control(5)
مراجعه
کنید.
اضافهشده
در نسخه 245.
--cpu-weight=WEIGHT,
--io-weight=WEIGHT
وزنهای
زمانبندی
پردازنده (CPU)
و
ورودی/خروجی
(IO) فرایندهای
کاربر، از
جمله
فرایندهای
منشعبشده
توسط کاربر
که
اعتبارنامه
کاربری را
تغییر
دادهاند،
تنظیم
میکند. یک
مقدار عددی
در بازه
۱...۱۰۰۰۰
میپذیرد.
این گزینه
تنظیمات
CPUWeight=
و
IOWeight= را در
واحد
اسلایس systemd
برای هر
کاربر یعنی
user-$UID.slice کنترل
میکند.
برای
جزئیات
بیشتر به
systemd.resource-control(5)
مراجعه
کنید.
اضافهشده
در نسخه 245.
--tmp-limit=BYTES,
--tmp-limit=PERCENT,
--dev-shm-limit=BYTES,
--dev-shm-limit=PERCENT
سهمیه
اختصاصی هر
کاربر روی /tmp/
و /dev/shm/ را که
هنگام ورود
کاربر
اعمال
میشود،
کنترل
میکند. یا
یک مقدار
مطلق به
بایت (همراه
با
پسوندهای
رایج K, M, G, T بر
مبنای ۱۰۲۴)
یا یک درصد
میپذیرد.
در حالت
دوم،
محدودیت
نسبت به
اندازه
فایلسیستم
مربوطه
اعمال
میشود. این
محدودیت
تنها در
صورتی
اعمال
میشود که
فایلسیستم
مربوطه "tmpfs"
باشد و در
غیر این
صورت
تاثیری
ندارد. توجه
داشته
باشید که
اگر از این
گزینهها
استفاده
نشود، ممکن
است همچنان
یک سهمیه
پیشفرض
اعمال شود
(معمولاً
۸۰٪).
اضافهشده
در نسخه 258.
--storage=STORAGE
سازوکار
ذخیرهسازی
مورد
استفاده
برای این
دایرکتوری
خانگی را
انتخاب
میکند. یکی
از مقادیر
"luks"، "fscrypt"،
"directory"، "subvolume" یا
"cifs" را
میپذیرد.
برای
جزئیات
مربوط به
این
سازوکارها،
به توضیحات
بالا
مراجعه
کنید. اگر یک
دایرکتوری
خانگی جدید
ایجاد شود و
نوع
ذخیرهسازی
به طور خاص
تعیین نشده
باشد،
homed.conf(5)
مشخص
میکند که
از کدام
ذخیرهسازی
پیشفرض
استفاده
شود.
اضافهشده
در نسخه 245.
--image-path=PATH
یک مسیر
در
فایلسیستم
دریافت
میکند. محل
قرارگیری
دایرکتوری
خانگی
کاربر را
پیکربندی
میکند.
هنگامی که
از
ذخیرهسازی
LUKS2 استفاده
میشود به
مسیر فایل loopback
اشاره
دارد، در
غیر این
صورت به
مسیر
دایرکتوری
خانگی (که
ممکن است در
/home/ یا هر
فایلسیستم
قابل
دسترسی
دیگری باشد)
اشاره
میکند. در
صورت مشخص
نشدن،
هنگام
استفاده از
ذخیرهسازی
LUKS به طور
پیشفرض
روی /home/$USER.home و
برای سایر
سازوکارهای
ذخیرهسازی
روی /home/$USER.homedir
تنظیم
میشود.
برای
سازوکار
ذخیرهسازی
"cifs" تعریف
نشده است.
برای
استفاده از
ذخیرهسازی
LUKS2 روی یک
دستگاه
بلوکی
معمولی
(مانند
فلشمموری
USB)، مسیر
دستگاه
بلوکی را در
اینجا وارد
کنید. تعیین
مسیر یک
دایرکتوری
در اینجا
هنگام
استفاده از
ذخیرهسازی
LUKS2 مجاز نیست.
به طور
مشابه، در
صورت
استفاده از
هر یک از
بکاندهای
ذخیرهسازی
دیگر،
تعیین مسیر
یک فایل
معمولی یا
نود دستگاه
مجاز نیست.
اضافهشده
در نسخه 245.
--drop-caches=BOOL
حافظههای
پنهان
فایلسیستم
سیستمعامل
را در هنگام
خروج به
صورت
خودکار
تخلیه
میکند. این
ویژگی در
ترکیب با
بکاند
ذخیرهسازی
fscrypt مفید است
تا اطمینان
حاصل شود
سیستمعامل
نسخههای
رمزگشاییشده
فایلها و
پوشهها را
پس از خروج
کاربر در
حافظه نگه
نمیدارد (و
آنها را در
دسترس باقی
نمیگذارد).
این گزینه
در سایر
بکاندها
نیز
پشتیبانی
میشود،
اما مزیت
خاصی در
آنها به
همراه
ندارد.
مقدار
پیشفرض
غیرفعال
است، مگر
اینکه
بکاند
ذخیرهسازی
انتخابشده
fscrypt باشد که در
آن صورت به
طور
پیشفرض
فعال است.
توجه داشته
باشید که
تخلیه
کشهای
سیستمعامل
برای مدت
کوتاهی پس
از خروج
تأثیر منفی
بر عملکرد
سیستمعامل
خواهد
گذاشت.
اضافهشده
در نسخه 250.
--fs-type=TYPE
هنگامی
که
ذخیرهسازی
LUKS2 استفاده
میشود،
نوع
فایلسیستم
مورد
استفاده در
داخل
کانتینر LUKS2
دایرکتوری
خانگی را
پیکربندی
میکند. یکی
از مقادیر
"btrfs"، "ext4" یا "xfs".
در صورت عدم
تعیین،
homed.conf(5)
نوع
فایلسیستم
پیشفرض
مورد
استفاده را
تعیین
میکند.
توجه داشته
باشید که "xfs"
توصیه
نمیشود،
زیرا
پشتیبانی
آن از تغییر
اندازه
فایلسیستم
بسیار
محدود است.
اضافهشده
در نسخه 245.
--luks-discard=BOOL
هنگامی
که
ذخیرهسازی
LUKS2 استفاده
میشود،
فعال بودن
قابلیت "discard"
فایلسیستم
را
پیکربندی
میکند. در
صورت فعال
بودن،
فایلسیستم
مستقر روی
حجم LUKS2
اطلاعات
بلوکهای
خالی را به LUKS2
و فایل loopback
زیرین
گزارش
میدهد؛
این کار
تضمین
میکند
فضای خالی
دایرکتوری
خانگی به
فایلسیستم
پشتیبان
زیر حجم LUKS2
بازگردانده
شود، که
منجر به
ایجاد یک
فایل loopback
تُنُک ("sparse")
میگردد.
این گزینه
اکثراً به
طور
پیشفرض
غیرفعال
است، زیرا
اجازه over-committing به
دایرکتوریهای
خانگی را
میدهد که
اگر
فایلسیستم
زیرین
هنگام
تخصیص یک
بلوک توسط
فایلسیستم
بالایی پر
شود،
خطاهای I/O رخ
خواهد داد.
چنین
خطاهای I/O
معمولاً نه
توسط
فایلسیستمها
و نه توسط
برنامهها
به خوبی
مدیریت
نمیشوند.
هنگامی که
ذخیرهسازی
LUKS2 روی
دستگاههای
بلوکی
معمولی (به
جای فایل loopback)
استفاده
میشود،
منطق discard به
طور
پیشفرض
فعال است.
اضافهشده
در نسخه 245.
--luks-offline-discard=BOOL
مشابه
--luks-discard=،
عملیات
آزادسازی (trimming)
فایلسیستم
را کنترل
میکند. با
این حال، در
حالی که
--luks-discard=
آنچه را که
هنگام فعال
بودن
دایرکتوری
خانگی رخ
میدهد
کنترل
میکند،
--luks-offline-discard=
اتفاقات
زمان
غیرفعال
شدن آن را
کنترل
میکند،
یعنی آیا
هنگام
غیرفعال
کردن
دایرکتوری
خانگی،
فضای
ذخیرهسازی
کوتاه/آزاد
شود یا خیر.
این گزینه
به طور
پیشفرض
فعال است تا
اطمینان
حاصل شود در
زمان عدم
ورود
کاربر،
فضای دیسک
به حداقل
میرسد.
اضافهشده
در نسخه 246.
--luks-extra-mount-options=OPTIONS
رشتهای
شامل
گزینههای
مانت اضافی
را برای
استفاده
هنگام مانت
کردن حجم LUKS
دریافت
میکند. در
صورت مشخص
شدن، این
رشته به
گزینههای
مانت
پیشفرض و
داخلی
اضافه
خواهد شد.
مقدار
پیشفرض
"
compress=zstd:1,noacl,user_subvol_rm_allowed"
است.
اضافهشده
در نسخه 250.
--luks-cipher=CIPHER,
--luks-cipher-mode=MODE,
--luks-volume-key-size=BYTES,
--luks-pbkdf-type=TYPE,
--luks-pbkdf-hash-algorithm=ALGORITHM,
--luks-pbkdf-force-iterations=ITERATIONS,
--luks-pbkdf-time-cost=SECONDS,
--luks-pbkdf-memory-cost=BYTES,
--luks-pbkdf-parallel-threads=THREADS,
--luks-sector-size=BYTES
پارامترهای
رمزنگاری
مختلف را
برای
سازوکار
ذخیرهسازی
LUKS2 پیکربندی
میکند.
برای
جزئیات
مربوط به
ویژگیهای
خاص، به
cryptsetup(8)
مراجعه
کنید.
توجه
داشته
باشید که homectl
مانند /proc/crypto
برای
اندازه
کلید از
بایت
استفاده
میکند،
اما cryptsetup(8) از
بیت
استفاده
مینماید.
اضافهشده
در نسخه 245.
--auto-resize-mode=
پیکربندی
میکند که
آیا
فایلسیستم
پشتیبان در
هنگام ورود
و خروج به
طور خودکار
رشد و/یا
کوچک شود یا
خیر. یکی از
رشتههای
"off"، "grow" یا
"shrink-and-grow" را
میپذیرد.
در حال حاضر
فقط برای
بکاند LUKS2
اعمال
میشود، و
آن هم در
صورتی که
فایلسیستم
btrfs در داخل آن
استفاده
شده باشد
(زیرا تنها
در این صورت
افزایش/کاهش
اندازه
برخط
فایلسیستم
پشتیبانی
میشود). اگر
LUKS2/btrfs استفاده
شود، به طور
پیشفرض
روی "shrink-and-grow"
است، در غیر
این صورت off
است. در صورت
تنظیم روی
"off"، هیچ
کوچک یا
بزرگسازی
خودکاری در
طول ورود یا
خروج انجام
نمیشود. در
صورت تنظیم
روی "grow"، اگر
ناحیه
خانگی در
حال حاضر
کوچکتر
باشد، به
اندازهای
که از طریق
--disk-size=
پیکربندی
شده است رشد
میکند. اگر
هماکنون
با اندازه
پیکربندیشده
مطابقت
داشته باشد
یا بزرگتر
باشد، هیچ
عملیاتی
اجرا
نمیشود. در
صورت تنظیم
روی "shrink-and-grow"،
ناحیه
خانگی در
طول خروج
نیز به
حداقل
اندازهای
که فضای
دیسک
استفادهشده
و
محدودیتهای
فایلسیستم
اجازه
میدهند
تغییر
اندازه
میدهد.
بنابراین
این حالت
تضمین
میکند که
وقتی ناحیه
خانگی فعال
است، به
اندازه
پیکربندیشده
باشد، اما
در زمان
غیرفعال
بودن فشرده
شده و تنها
حداقل فضای
ممکن را
اشغال کند.
توجه داشته
باشید که
اگر سیستم
به طور
غیرعادی
خاموش شود
یا کاربر به
درستی خارج
نشود،
عملیات
کوچکسازی
انجام
نخواهد شد و
کاربر باید
پیش از
اجرای مجدد
آن، دوباره
وارد و خارج
شود.
اضافهشده
در نسخه 250.
--rebalance-weight=
پارامتر
وزن را برای
منطق
بازتعادلسازی
فضای خالی
دیسک
پیکربندی
میکند.
تنها برای
بکاند LUKS2
اعمال
میشود
(زیرا برای
بکاند LUKS2
فضای دیسک
به جای
اینکه
مانند سایر
بکاندها
بلافاصله
از یک مخزن
مشترک
تخصیص
یابد، از یک
فایلسیستم
loopback اختصاصی
برای هر
کاربر
تخصیص داده
میشود). در
فواصل
زمانی
منظم، فضای
خالی دیسک
در نواحی
خانگی فعال
و فضای
ذخیرهسازی
پشتیبان
آنها با در
نظر گرفتن
مقدار وزن
پیکربندیشده
در اینجا،
در میان
آنها
بازتوزیع
میشود. یک
عدد صحیح در
بازه
۱...۱۰۰۰۰ یا
رشته ویژه
"off" را
انتظار
دارد. در
صورت عدم
تعیین، به
طور
پیشفرض
۱۰۰ است. وزن
برای
مقیاسبندی
فضای خالی
در دسترس
نواحی
خانگی
استفاده
میشود: یک
ناحیه
خانگی با
وزن ۲۰۰ دو
برابر یک
ناحیه با
وزن ۱۰۰
فضای خالی
دریافت
خواهد کرد؛
یک ناحیه
خانگی با
وزن ۵۰ نیمی
از آن را
دریافت
میکند. به
فایلسیستم
پشتیبان
فضایی
معادل با
وزن ۲۰
اختصاص
مییابد. در
صورت تنظیم
روی "off"، هیچ
توزیع
خودکار
فضای خالی
برای این
ناحیه
خانگی
انجام
نمیشود.
توجه داشته
باشید که
تغییر
اندازه
صریح ناحیه
خانگی (با
homectl
resize که در زیر
آمده است)
بازتعادل
خودکار را
به طور ضمنی
خاموش
میکند.
برای
فعالسازی
مجدد
بازتعادل
خودکار از
--rebalance-weight= با یک
پارامتر
خالی
استفاده
کنید.
اضافهشده
در نسخه 250.
--nosuid=BOOL,
--nodev=BOOL, --noexec=BOOL
گزینههای
مانت "nosuid"، "nodev"
و "noexec" را برای
دایرکتوریهای
خانگی
پیکربندی
میکند. به
طور
پیشفرض،
"nodev" و "nosuid" فعال
هستند، در
حالی که "noexec"
غیرفعال
است. برای
جزئیات
بیشتر
درباره این
گزینههای
مانت به
mount(8)
مراجعه
کنید.
اضافهشده
در نسخه 245.
--cifs-domain=DOMAIN,
--cifs-user-name=USER,
--cifs-service=SERVICE,
--cifs-extra-mount-options=OPTIONS
دامنه و
کاربر
اشتراکگذاری
فایل
ویندوز (CIFS) را
برای
انتساب به
دایرکتوری
خانگی/حساب
کاربر، و
همچنین
اشتراک
فایل ("service") را
برای مانت
شدن به
عنوان
دایرکتوری
پیکربندی
میکند.
مورد دوم
زمانی
استفاده
میشود که
ذخیرهسازی
"cifs" انتخاب
شده باشد.
اشتراک
فایل باید
در قالب
"//
host/
share/
directory/..."
مشخص شود.
بخش
دایرکتوری
اختیاری
است — در
صورت مشخص
نشدن،
دایرکتوری
خانگی در
بالاترین
سطح
دایرکتوری
اشتراک
قرار خواهد
گرفت. تنظیم
--cifs-extra-mount-options= امکان
تعیین
گزینههای
مانت اضافی
را هنگام
مانت کردن
اشتراک
فراهم
میکند،
برای
جزئیات به
mount.cifs(8) مراجعه
کنید.
اضافهشده
در نسخه 245.
--stop-delay=SECS
مدت
زمانی را که
مدیر سرویس
اختصاصی هر
کاربر پس از
پایان
یافتن
تمامی
نشستهای
کاربر باید
به اجرا
ادامه دهد،
پیکربندی
میکند.
مقدار
پیشفرض در
logind.conf(5)
پیکربندی
شده است
(البته برای
دایرکتوریهای
خانگی با
ذخیرهسازی
LUKS2 واقع روی
رسانههای
جداشدنی،
این مقدار
به طور
پیشفرض ۰
است). مدت
زمان
طولانیتر
اطمینان
حاصل
میکند که
ورودهای
سریع و مکرر
کارآمدتر
باشند،
زیرا نیازی
به
راهاندازی
مجدد مدیر
سرویس
کاربر در هر
بار ورود
نیست.
اضافهشده
در نسخه 245.
--kill-processes=BOOL
مشخص
میکند که
آیا همه
فرایندهای
کاربر در
هنگام خروج
خاتمه داده
شوند یا خیر.
مقدار
پیشفرض در
logind.conf(5)
پیکربندی
شده است.
اضافهشده
در نسخه 245.
--auto-login=BOOL
یک
آرگومان
بولی
میپذیرد.
پیکربندی
میکند که
آیا رابط
کاربری
گرافیکی
سیستم در
صورت امکان
باید این
کاربر را به
صورت
خودکار
وارد سیستم
کند یا خیر.
مقدار
پیشفرض
غیرفعال
است. اگر
کمتر یا
بیشتر از یک
کاربر به
این روش
علامتگذاری
شوند، ورود
خودکار
غیرفعال
میشود.
اضافهشده
در نسخه 245.
--session-launcher=LAUNCHER
یک
آرگومان
رشتهای
میپذیرد.
فایل مدخل
desktop. را برای
اجراکننده
نشست
ترجیحی
کاربر
پیکربندی
میکند
(یعنی "gnome"، "plasma"
یا نامهای
دیگری که در
/usr/share/xsessions/ یا /usr/share/wayland-sessions
ظاهر
میشوند).
این تنظیم
توسط مدیر
نمایش
خوانده
میشود تا
نشست
پیشفرضی
را که هنگام
ورود کاربر
اجرا
میشود
انتخاب کند.
اضافهشده
در نسخه 256.
--session-type=TYPE
یک
آرگومان
رشتهای
میپذیرد.
نوع نشست
ترجیحی
کاربر را
پیکربندی
میکند
(یعنی "x11"، "wayland"
و سایر
مقادیر
پذیرفتهشده
توسط
$XDG_SESSION_TYPE).
این تنظیم
توسط مدیر
نمایش
خوانده
میشود تا
نوع نشست
پیشفرضی
را که کاربر
به آن وارد
میشود
انتخاب کند.
اضافهشده
در نسخه 256.
دستورات
زیر
پشتیبانی
میشوند:
list
فهرست
کردن تمام
دایرکتوریهای
خانگی (به
همراه
جزئیات
کوتاه) که در
حال حاضر
توسط systemd-homed.service
مدیریت
میشوند.
همچنین در
صورتی که
هیچ دستوری
در خط فرمان
مشخص نشده
باشد، این
دستور اجرا
میشود.
(توجه داشته
باشید که
فهرست
کاربران
نمایشدادهشده
توسط این
دستور شامل
کاربرانی
که توسط
زیرسیستمهای
دیگر
مدیریت
میشوند،
مانند
کاربران
سیستمی یا
هر کاربر
سنتی
فهرستشده
در /etc/passwd
نمیشود.)
افزودهشده
در نگارش 245.
activate USER [USER...]
فعالسازی
یک یا چند
دایرکتوری
خانگی.
دایرکتوریهای
خانگی هر
کاربر
فهرستشده
فعال شده و
در نقطهٔ
اتصال
آنها
(معمولاً در
/home/$USER) در دسترس
قرار
میگیرند.
توجه داشته
باشید که هر
خانهٔ
فعالشده
با این روش
برای همیشه
فعال
میماند،
مگر اینکه
دوباره به
صورت صریح
غیرفعال
شود (با
deactivate،
زیر را
ببینید)، یا
کاربر خارج
شود و
دوباره
وارد شود و
در نتیجه به
دلیل منطق
غیرفعالسازی
خودکار پس
از خروج
غیرفعال
شود.
فعالسازی
یک
دایرکتوری
خانگی شامل
عملیات
گوناگونی
است که به
سازوکار
ذخیرهسازی
انتخابشده
بستگی دارد.
اگر از
سازوکار LUKS2
استفاده
شود، این
کار عموماً
شامل موارد
زیر است:
درخواست
گذرواژه از
کاربر،
برپایی
دستگاه loopback،
اعتبارسنجی
و
فعالسازی
حجم LUKS2،
بررسی
سیستمفایل،
اتصال (mount)
سیستمفایل
و در صورت
لزوم تغییر
مالکیت
تمام
فایلهای
موجود به UID/GID
صحیح.
افزودهشده
در نگارش 245.
deactivate USER [USER...]
غیرفعالسازی
یک یا چند
دایرکتوری
خانگی. این
دستور اثر
activate را خنثی
میکند.
افزودهشده
در نگارش 245.
inspect USER [USER...]
نمایش
جزئیات
گوناگون
دربارهٔ
دایرکتوریهای
خانگی
مشخصشده.
این دستور
اطلاعات
گوناگونی
را دربارهٔ
دایرکتوری
خانگی و
حساب
کاربری آن
نشان
میدهد، از
جمله
دادههای
زمان اجرا
مانند
وضعیت
فعلی، مصرف
دیسک و
موارد
مشابه.
ترکیب با
--json=
برای نمایش
رکورد
کاربری
تفصیلی JSON به
جای آن، که
ممکن است با
--export-format= ترکیب
شود تا
جنبههای
معینی از
خروجی
نادیده
گرفته شوند.
افزودهشده
در نگارش 245.
authenticate USER [USER...]
اعتبارسنجی
اطلاعات
هویتی
ورودی یک
دایرکتوری
خانگی. این
دستور از
فراخواننده
گذرواژه (یا
موارد
مشابه) را
درخواست
میکند و
بررسی
میکند که
آیا قفل
دایرکتوری
خانگی را به
درستی باز
میکند یا
خیر. این
دستور
دایرکتوری
خانگی را در
همان
وضعیتی که
قرار دارد
رها
میکند،
یعنی اگر
قبلاً
غیرفعال
بود در
وضعیت
غیرفعال، و
اگر قبلاً
فعال بود در
وضعیت فعال
باقی
میگذارد.
افزودهشده
در نگارش 245.
create USER, create
--identity=PATH [USER]
ایجاد یک
دایرکتوری
خانگی/حساب
کاربری
جدید با نام
مشخصشده.
از
گزینههای
گوناگون
ویژگیهای
رکورد
کاربری
(همانطور
که در بالا
مستند شده
است) برای
کنترل
جنبههای
مختلف
دایرکتوری
خانگی و
حسابهای
کاربری آن
استفاده
کنید.
نام
کاربری
مشخصشده
باید از نحو
دقیق شرح
داده شده در
User/Group Name Syntax[4] پیروی
کند.
افزودهشده
در نگارش 245.
adopt PATH [PATH...]
پذیرفتن
یک یا چند
دایرکتوری
خانگی
موجود در
سیستم محلی.
یک یا چند
مسیر به
دایرکتوریهای
خانگی *.home
مربوط به LUKS
یا
دایرکتوریهای
خانگی
مستقل یا
زیرحجمهای
*.homedir/ که قبلاً
توسط systemd-homed
ایجاد
شدهاند را
دریافت
کرده و
آنها را به
صورت محلی
برای ورود
در دسترس
قرار
میدهد.
فایلهای
ارجاعدادهشده
جابهجا
نمیشوند.
این یک
جایگزین
برای
انتقال
چنین
دایرکتوریهای
خانگی به /home/
است (جایی که
به صورت
خودکار
شناسایی
میشدند).
افزودهشده
در نگارش 258.
register FILE [FILE...]
ثبت یک
یا چند
کاربر،
بدون ایجاد
دایرکتوریهای
خانگی
آنها. یک یا
چند مسیر به
فایلهای
رکورد
کاربری JSON را
دریافت
میکند. اگر
مسیر به
صورت "-"
مشخص شود،
رکورد
کاربری JSON را
از ورودی
استاندارد
میخواند.
ثبت یک
کاربر، آن
را بدون
ایجاد یک
دایرکتوری
خانگی جدید
روی سیستم
محلی در
دسترس قرار
میدهد. این
ویژگی
بهویژه
برای قابل
دسترس کردن
یک کاربر
روی سیستمی
که در ابتدا
روی آن
ایجاد
نشده،
بسیار مفید
است.
در اینجا
مثالی از
نحوهٔ
دسترسیپذیر
کردن یک
حساب
کاربری
محلی به
همراه
دایرکتوری
خانگی آن
روی یک
سیستم راه
دور با
استفاده از
اشتراکگذاری
فایل SMB/CIFS
آورده شده
است. با فرض
نصب بودن Samba
در
پیکربندی
پیشفرض
خود، به
عنوان
کاربر "root"
فراخوانی
کنید:
به عنوان
کاربر عادی
ادامه دهید
"lennart":
$ homectl update lennart --ssh-authorized-keys=... -N --storage=cifs --cifs-service="//$HOSTNAME/lennart"
$ homectl get-signing-key | ssh targetsystem homectl add-signing-key --key-name="$HOSTNAME".public
$ homectl inspect -E lennart | ssh targetsystem homectl register -
$ ssh lennart@targetsystem
این دستور
ابتدا
اطمینان
حاصل
میکند که
حساب
کاربری "lennart"
برای Samba
شناختهشده
و قابل
دسترس است.
سپس یک
دسترسی
محلی SSH را که
باید برای
دسترسی به
این کاربر
استفاده
شود ثبت
میکند و CIFS
را به عنوان
فضای
ذخیرهسازی
پیشفرض
برای
سیستمهای
غیرمحلی
روی این
حساب
پیکربندی
مینماید.
سپس کلید
امضای حساب
سیستم محلی
را به سیستم
هدف اضافه
میکند. سپس
حساب
کاربری
محلی را در
سیستم هدف
ثبت
مینماید.
در نهایت به
حساب در
سیستم هدف
وارد
میشود.
سیستم هدف
سپس از طریق
SMB/CIFS به عقب
متصل
میشود تا
به
دایرکتوری
خانگی
دسترسی
پیدا کند.
افزودهشده
در نگارش 258.
unregister USER...
لغو ثبت
یک یا چند
حساب
کاربری. این
کار تنها
رکورد
کاربری را
از سیستم
محلی حذف
میکند و
دایرکتوری
خانگی را
پاک
نمیکند.
دایرکتوری
خانگی
میتواند
بعداً از
طریق دستور
register یا
adopt روی
این سیستم
یا یک سیستم
دیگر
دوباره
اضافه شود.
توجه داشته
باشید که
لغو ثبت
کاربری که
دایرکتوری
خانگی آن در
/home/ قرار
دارد، باعث
ناپدید شدن
کاربر از
پایگاهداده
کاربران
محلی
نخواهد شد،
زیرا تمامی
دایرکتوریهای
خانگی
پشتیبانیشدهٔ
قرارگرفته
در آنجا، در
پایگاهداده
کاربران
ظاهر
میشوند. با
این وجود،
رکورد
کاربر
«تثبیتنشده»
میشود،
یعنی
وابستگی
خود را به
سیستم محلی
از دست
میدهد.
هنگام ورود
به سیستم،
این
وابستگی
بهطور
خودکار
بازیابی
میشود و یک
جفت UID/GID محلی
به دست
میآورد.
افزودهشده
در نگارش 258.
remove USER
حذف یک
دایرکتوری
خانگی/حساب
کاربری. این
دستور هم
رکورد
کاربری
دایرکتوری
خانگی و هم
خود
دایرکتوری
خانگی را
حذف
میکند، و
بنابراین
تمامی
فایلها و
دایرکتوریهای
تحت مالکیت
کاربر را
پاک
مینماید.
افزودهشده
در نگارش 245.
update USER, update
--identity=PATH [USER]
بهروزرسانی
یک
دایرکتوری
خانگی/حساب
کاربری. از
گزینههای
گوناگون
ویژگیهای
رکورد
کاربری
(همانطور
که در بالا
مستند شده
است) برای
اعمال
تغییرات در
حساب
استفاده
کنید، یا به
جای آن یک
رکورد
کاربری
کامل و
بهروزشدهٔ
JSON را از طریق
گزینهٔ
--identity=
ارائه دهید.
توجه
داشته
باشید که
اعمال
تغییرات
روی
رکوردهای
کاربری که
توسط یک
کلید خصوصی
رمزنگاری
موجود در
سیستم محلی
امضا
نشدهاند
مجاز نیست،
مگر اینکه
--identity= همراه با
یک رکورد
کاربری
استفاده
شود که از
قبل به
درستی توسط
یک کلید
خصوصی
شناختهشده
امضا شده
باشد.
افزودهشده
در نگارش 245.
passwd USER
تغییر
گذرواژهٔ
دایرکتوری
خانگی/حساب
کاربری
مشخصشده.
افزودهشده
در نگارش 245.
resize USER BYTES
تغییر
فضای دیسک
اختصاصیافته
به
دایرکتوری
خانگی
مشخصشده.
اگر از
سازوکار
ذخیرهسازی
LUKS2 استفاده
شود، این
دستور
بهطور
خودکار
اندازهٔ
فایل loopback و
سیستمفایل
درون آن را
تغییر
میدهد.
توجه داشته
باشید که
اگر "ext4" درون
حجم LUKS2
استفاده
شده باشد،
لازم است
دایرکتوری
خانگی را
قبل از کوچک
کردن آن
غیرفعال
کنید (یعنی
کاربر باید
خارج شده
باشد).
افزایش
اندازه
میتواند
در حالی که
دایرکتوری
خانگی فعال
است انجام
شود. اگر "xfs"
درون حجم LUKS2
استفاده
شود،
دایرکتوری
خانگی به
هیچ وجه
نمیتواند
کوچک شود. در
هر سه
سیستمفایل
"ext4"، "xfs" و "btrfs"
دایرکتوری
خانگی ممکن
است در حالی
که کاربر
وارد سیستم
است
بزرگتر
شود، و در
مورد آخری،
در حالی که
کاربر وارد
سیستم است
میتواند
کوچکتر
نیز بشود.
اگر از
سازوکارهای
ذخیرهسازی
"subvolume"، "directory"،
"fscrypt" استفاده
شود، تغییر
اندازه
باعث تغییر
سهمیهٔ (quota)
سیستمفایل
خواهد شد.
پارامتر
اندازه
میتواند
از
پسوندهای
معمول B، K، M،
G، T (بر مبنای
۱۰۲۴)
استفاده
کند.
رشتههای
ویژهٔ "min" و
"max"
میتوانند
به جای یک
مقدار عددی
اندازه
مشخص شوند،
تا فضای
دیسک
اختصاصیافته
به ناحیهٔ
خانگی را با
در نظر
گرفتن
محدودیتهای
سیستمفایل،
مصرف دیسک
درون
ناحیهٔ
خانگی و
فضای
ذخیرهسازی
پشتیبان،
به حداقل یا
حداکثر
برسانند.
افزودهشده
در نگارش 245.
lock USER
تعلیق
موقت
دسترسی به
دایرکتوری
خانگی
کاربر و حذف
هرگونه
کلید
رمزنگاری
مرتبط از
حافظه.
هرگونه
تلاش برای
دسترسی به
دایرکتوری
خانگی
کاربر
متوقف
خواهد ماند
تا زمانی که
قفل
دایرکتوری
خانگی
مجدداً باز
شود (یعنی
دوباره
اعتبارسنجی
شود). این
قابلیت در
درجهٔ اول
برای
استفاده در
زمان تعلیق
سیستم (system suspend) در
نظر گرفته
شده است تا
اطمینان
حاصل شود که
دادههای
کاربر تا
زمان
اعتبارسنجی
مجدد پس از
ادامهٔ کار
(resume)، قابل
دسترسی
نیستند. این
عملیات فقط
برای
دایرکتوریهای
خانگی
تعریف شده
است که از
سازوکار
ذخیرهسازی
LUKS2 استفاده
میکنند.
افزودهشده
در نگارش 245.
unlock USER
ادامهٔ
دسترسی
مجدد به
دایرکتوری
خانگی
کاربر، که
اثر دستور
lock
در بالا را
خنثی
میکند. این
دستور
نیازمند
اعتبارسنجی
کاربر است،
زیرا
کلیدهای
رمزنگاری
مورد نیاز
برای
دسترسی به
دایرکتوری
خانگی باید
دوباره به
دست آیند.
افزودهشده
در نگارش 245.
lock-all
اجرای
همزمان
دستور
lock روی
تمامی
دایرکتوریهای
خانگی
مناسب. این
عملیات
عموماً
هنگام
تعلیق
سیستم (یعنی
توسط
systemctl suspend و
دستورات
مرتبط) اجرا
میشود تا
اطمینان
حاصل شود که
کلیدهای
رمزنگاری
تمامی
کاربران
فعال برای
دسترسی به
دایرکتوریهای
خانگی
آنها از
حافظه حذف
میشوند.
افزودهشده
در نگارش 245.
deactivate-all
اجرای
همزمان
دستور
deactivate
روی تمامی
دایرکتوریهای
خانگی فعال.
این عملیات
عموماً
هنگام
خاموش شدن
سیستم (یعنی
توسط
systemctl poweroff و
دستورات
مرتبط) اجرا
میشود تا
اطمینان
حاصل شود که
دایرکتوریهای
خانگی
تمامی
کاربران
فعال قبل از
قطع اتصال (unmount)
/home/ و
سیستمفایلهای
مرتبط، به
طور کامل
غیرفعال
میشوند.
افزودهشده
در نگارش 247.
with USER COMMAND...
فعالسازی
دایرکتوری
خانگی
کاربر
مشخصشده،
اجرای
دستور
مشخصشده
(تحت هویت
فراخواننده،
نه کاربر
مشخصشده) و
غیرفعالسازی
مجدد
دایرکتوری
خانگی پس از
آن (مگر
اینکه
کاربر به
شکل دیگری
وارد سیستم
شده باشد).
این دستور
برای اجرای
اسکریپتهای
پشتیبانگیری
ممتاز و
موارد
مشابه مفید
است، اما
برای امکان
بازگشایی
دایرکتوری
خانگی
کاربر،
نیازمند
اعتبارسنجی
با اطلاعات
هویتی
کاربر است.
افزودهشده
در نگارش 245.
rebalance
تعادلبخشی
مجدد فضای
آزاد دیسک
بین نواحی
خانگی فعال
و فضای
ذخیرهسازی
پشتیبان.
--rebalance-weight= در بالا
را ببینید.
این دستور
هیچ
عملیاتی
انجام
نمیدهد
مگر اینکه
حداقل یک
ناحیهٔ
خانگی فعال
LUKS2 وجود
داشته باشد
که
تعادلبخشی
مجدد فضای
دیسک برای
آن فعال شده
باشد. این
عملیات
همگام (synchronous)
است: تنها
زمانی کامل
خواهد شد که
فضای دیسک
مطابق با
وزنهای
تعادلبخشی
مجدد
بازتوزیع
شود. توجه
داشته
باشید که
تعادلبخشی
مجدد
بهطور
خودکار در
پسزمینه
در فواصل
زمانی منظم
نیز انجام
میشود. از
این دستور
برای
اطمینان
همگام از
بازتوزیع
مناسب فضای
دیسک پیش از
آغاز
عملیاتی که
به مقادیر
زیادی فضای
دیسک نیاز
دارد،
استفاده
کنید.
افزودهشده
در نگارش 250.
firstboot
این
دستور قرار
است در طول
بوت اولیهٔ
سیستم
فراخوانی
شود. بررسی
میکند که
آیا تاکنون
هیچ ناحیهٔ
خانگی عادی
وجود دارد
یا خیر، و
اگر وجود
ندارد از
کاربر
بهصورت
تعاملی روی
کنسول نام
کاربری و
گذرواژه را
درخواست
کرده و یکی
میسازد
(تنها در
صورتی که
--prompt-new-user مشخص
شده باشد). به
عنوان
جایگزین،
اگر یک یا
چند
اعتبارنامهٔ
سرویس که
نام آنها
با "home.create." آغاز
میشود به
دستور
ارسال شوند
(حاوی یک
رکورد
کاربری در
قالب JSON)، این
کاربران
بهطور
خودکار در
زمان بوت
ایجاد
میشوند.
این دستور
توسط واحد
سرویس systemd-homed-firstboot.service
فراخوانی
میشود.
افزودهشده
در نگارش 256.
list-signing-keys
نمایش
فهرستی از
کلیدهای
عمومی که
دایرکتوریهای
خانگی
میتوانند
با آنها
امضا شوند
تا برای
ورود محلی
مجاز
شناخته
شوند. یکی از
چنین
کلیدهایی
(local.public) بهطور
خودکار
برای امضای
دایرکتوریهای
خانگی
ایجادشده
در سطح محلی
تولید
خواهد شد،
اما
کلیدهای
عمومی
بیشتری نیز
ممکن است
ثبت شوند تا
دایرکتوریهای
خانگی از
مبداهای
دیگر را نیز
بپذیرند (
add-signing-key در زیر
را ببینید).
افزودهشده
در نگارش 258.
get-signing-key [NAME...]
نوشتن
کلید عمومی
مشخصشده
با نام در
خروجی
استاندارد
(در قالب PEM).
اگر نامی
مشخص نشود،
پیشفرض local.public
است، یعنی
کلیدی که
بهطور
خودکار
برای
دایرکتوریهای
خانگی
ایجادشده
در سطح محلی
تولید
میشود.
افزودهشده
در نگارش 258.
add-signing-key [FILE...]
افزودن
کلید(های)
عمومی از
فایل(های)
کلید PEM
مشخصشده
به فهرست
کلیدهایی
که نواحی
خانگی باید
توسط آنها
امضا شده
باشند تا
برای ورود
محلی مجاز
دانسته
شوند. اگر
مسیر "-"
مشخص شود،
یا اگر
اصلاً هیچ
فایلی مشخص
نشود، کلید
از ورودی
استاندارد
خوانده
خواهد شد.
نام
فایل(های)
کلید باید
دارای
پسوند .public
باشد و نام
فایل(ها) پس
از
افزودهشدن
برای
نامگذاری
کلید(ها) نیز
استفاده
خواهد شد.
اگر یک کلید
از ورودی
استاندارد
افزوده
شود، نام
کلید باید
صراحتاً از
طریق
--key-name=
مشخص شود،
بالا را
ببینید.
این دستور
برای مجاز
دانستن
استفاده از
دایرکتوریهای
خانگی محلی
روی یک
سیستم راه
دور مفید
است. مثال:
homectl get-signing-key | ssh myotherhost homectl add-signing-key --key-name="$HOSTNAME".public
افزودهشده
در نگارش 258.
remove-signing-key NAME...
حذف کلید
عمومی
شناساییشده
با نام
مشخصشده
از فهرست
کلیدهایی
که کنترل
میکنند
ورود
دایرکتوریهای
خانگی از چه
مبداهایی
مجاز است.
افزودهشده
در نگارش 258.
هنگامی که
با دستور firstboot
فراخوانی
میشود، homectl
از منطق
اطلاعات
هویتی
سرویس که
توسط
ImportCredential=/LoadCredential=/SetCredential=
پیادهسازی
شده است
پشتیبانی
میکند
(برای
جزئیات به
systemd.exec(5) مراجعه
کنید). هنگام
ارسال،
اطلاعات
هویتی زیر
استفاده
میشوند:
home.create.*
اگر یک
یا چند
دادهٔ
هویتی که
نام آنها
با "home.create." آغاز
میشود و به
دنبال آن یک
نام کاربری
معتبر
یونیکس
میآید
ارسال
شوند، یک
ناحیهٔ
خانگی جدید
ایجاد
میشود،
یکی برای هر
رکورد
کاربری
مشخصشده.
افزودهشده
در نگارش 256.
systemd.firstboot=
این
متغیر بولی
اثر دستور
homectl
firstboot را
غیرفعال
میکند. این
پارامتر در
درجهٔ اول
توسط
systemd-firstboot(1)
تفسیر
میشود.
افزودهشده
در نگارش 256.
در صورت
موفقیت، 0 و
در غیر این
صورت یک کد
خطای
غیرصفر
بازگردانده
میشود.
هنگامی که
یک دستور با
with فراخوانی
میشود، کد
وضعیت خروج
فرزند
منتقل
میشود. در
عمل، homectl در
صورتی بدون
خطا خارج
میشود که
دستور هم با
موفقیت
فراخوانی
شود و با
موفقیت
پایان
یابد.
$SYSTEMD_LOG_LEVEL
حداکثر
سطح لاگ
پیامهای
صادرشده
(پیامهای
با سطح لاگ
بالاتر،
یعنی
پیامهای
کماهمیتتر،
نادیده
گرفته
خواهند شد).
فهرستی از
مقادیر
جداشده با
کاما را
میپذیرد.
یک مقدار
میتواند
یکی از
موارد زیر
باشد (به
ترتیب کاهش
اهمیت):
emerg،
alert،
crit،
err،
warning،
notice،
info،
debug، یا یک
عدد صحیح در
محدودهٔ 0...7.
برای
اطلاعات
بیشتر
syslog(3) را
ببینید. هر
مقدار
میتواند
بهصورت
اختیاری با
یکی از
پیشوندهای
console،
syslog،
kmsg یا
journal همراه با
یک دونقطه
پیشوندگذاری
شود تا
حداکثر سطح
لاگ را برای
آن مقصد لاگ
خاص تنظیم
کند (به
عنوان مثال
SYSTEMD_LOG_LEVEL=debug,console:info مشخص
میکند که
لاگگیری
در سطح debug
انجام شود
به جز زمانی
که در کنسول
لاگ گرفته
میشود که
باید در سطح
info باشد). توجه
داشته
باشید که
حداکثر سطح
لاگ سراسری
بر هر
حداکثر سطح
لاگ به ازای
هر مقصد
اولویت
دارد.
$SYSTEMD_LOG_COLOR
یک مقدار
بولی. اگر
درست باشد،
پیامهای
نوشتهشده
در tty بر اساس
اولویت
رنگی
خواهند شد.
این تنظیم
فقط زمانی
مفید است که
پیامها
مستقیماً
در ترمینال
نوشته
شوند، زیرا
journalctl(1) و سایر
ابزارهایی
که لاگها
را نمایش
میدهند،
خودشان
پیامها را
بر اساس سطح
لاگ رنگی
میکنند.
$SYSTEMD_LOG_TIME
یک مقدار
بولی. اگر
درست باشد،
پیامهای
لاگ کنسول
با برچسب
زمان
پیشوندگذاری
میشوند.
این تنظیم
فقط زمانی
مفید است که
پیامها
مستقیماً
در ترمینال
یا یک فایل
نوشته
شوند، زیرا
journalctl(1) و سایر
ابزارهایی
که لاگها
را نمایش
میدهند،
خودشان
برچسبهای
زمانی را بر
اساس
متادیتای
مدخل الصاق
مینمایند.
$SYSTEMD_LOG_LOCATION
یک مقدار
بولی. اگر
درست باشد،
پیامها با
نام فایل و
شمارهٔ خط
در کد منبع
که پیام از
آنجا
سرچشمه
میگیرد،
پیشوندگذاری
میشوند.
توجه
داشته
باشید که
مکان لاگ
اغلب به هر
حال به
عنوان
متادیتا به
مدخلهای
ژورنال
پیوست
میشود. با
این وجود
گنجاندن
مستقیم آن
در متن پیام
میتواند
هنگام رفع
اشکال
برنامهها
راحت باشد.
$SYSTEMD_LOG_TID
یک مقدار
بولی. اگر
درست باشد،
پیامها با
شناسهٔ
عددی ریسهٔ
(TID) فعلی
پیشوندگذاری
میشوند.
توجه
داشته
باشید که
این
اطلاعات به
هر حال به
عنوان
متادیتا به
مدخلهای
ژورنال
پیوست
میشود. با
این حال
گنجاندن
مستقیم آن
در متن پیام
میتواند
هنگام
اشکالزدایی
برنامهها
سودمند
باشد.
$SYSTEMD_LOG_TARGET
مقصد
پیامهای
لاگ. یکی از
موارد زیر:
console
(لاگگیری
در tty
متصلشده)،
console-prefixed
(لاگگیری
در tty
متصلشده
اما با
پیشوندهایی
که سطح لاگ و
«facility» را
کدگذاری
میکنند،
syslog(3) را
ببینید)،
kmsg
(لاگگیری
در بافر
مدور لاگ
هسته)،
journal
(لاگگیری
در ژورنال)،
journal-or-kmsg
(لاگگیری
در ژورنال
در صورت در
دسترس
بودن، و در
غیر این
صورت در kmsg)،
auto
(تعیین
خودکار
مقصد لاگ
مناسب،
حالت
پیشفرض)،
null
(غیرفعال
کردن خروجی
لاگ).
$SYSTEMD_LOG_RATELIMIT_KMSG
آیا kmsg با
محدودیت
نرخ (ratelimit) ارسال
شود یا خیر.
یک مقدار
بولی
میگیرد.
پیشفرض "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
بازنویسی
مجموعه
نویسه (charset)
ارسالشده
به
less (بهطور
پیشفرض "utf-8"،
اگر تشخیص
داده شود که
ترمینال
فراخواننده
با UTF-8 سازگار
است).
توجه
داشته
باشید که
تنظیم
متغیر
محیطی
معمولی $LESSCHARSET
هیچ تاثیری
بر
فراخوانیهای
less توسط
ابزارهای systemd
ندارد.
$SYSTEMD_PAGERSECURE
دستورات
پیجر
متداول
مانند
less(1)،
علاوه بر
«صفحهبندی»
یعنی
پیمایش در
خروجی، از
باز کردن یا
نوشتن در
فایلهای
دیگر و
اجرای
دستورات
دلخواه شل
پشتیبانی
میکنند.
هنگامی که
دستورات با
مجوزهای
ارتقایافته
اجرا
میشوند،
برای مثال
تحت
sudo(8) یا
pkexec(1)، پیجر به
یک مرز
امنیتی
تبدیل
میشود.
باید دقت
شود که تنها
برنامههایی
با
قابلیتهای
اکیداً
محدود به
عنوان پیجر
استفاده
شوند، و
ویژگیهای
تعاملی
ناخواسته
مانند باز
کردن یا
ایجاد
فایلهای
جدید یا
راهاندازی
زیرفرآیندها
مجاز
نباشند.
«حالت امن»
برای پیجر
ممکن است
همانطور
که در زیر
شرح داده
شده است
فعال شود،
اگر پیجر از
آن
پشتیبانی
کند (بیشتر
پیجرها به
شکلی نوشته
نشدهاند
که این
موضوع را مد
نظر قرار
دهند). توصیه
میشود
هنگام
اجازه دادن
به کاربران
غیرقابل
اعتماد
برای اجرای
دستورات با
مجوزهای
بالا، یا
صراحتاً
«حالت امن»
را فعال
کنید یا با
استفاده از
--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
تنظیم شده
باشد [5])،
«حالت امن»
فعال
میشود. در
آن موارد،
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
و شرایط
دیگر
میگیرد،
مشخص شود.
مثال 1. ایجاد
یک کاربر "waldo"
در گروه
مدیریتی
"wheel"، و
اختصاص 500 MiB
فضای دیسک
به آن.
homectl create waldo --real-name="Waldo McWaldo" -G wheel --disk-size=500M
مثال 2. ایجاد
یک کاربر "wally"
روی یک فلش
مموری USB، و
اختصاص
حداکثر 500
وظیفهٔ
همزمان به
آن.
homectl create wally --real-name="Wally McWally" --image-path=/dev/disk/by-id/usb-SanDisk_Ultra_Fit_476fff954b2b5c44-0:0 --tasks-max=500
مثال 3. تغییر
مقدار nice
کاربر "odlaw" به
+5 و اطمینان
از اینکه
متغیر
محیطی $SOME
هنگام ورود
به سیستم
برای او روی
رشتهٔ "THING"
تنظیم شده
باشد.
homectl update odlaw --nice=5 --setenv=SOME=THING
مثال 4. برپایی
اعتبارسنجی
با یک توکن
امنیتی YubiKey با
استفاده از
PKCS#11/PIV:
# Clear the Yubikey from any old keys (careful!)
ykman piv reset
# Generate a new private/public key pair on the device, store the public key in 'pubkey.pem'.
ykman piv generate-key -a RSA2048 9d pubkey.pem
# Create a self-signed certificate from this public key, and store it on the device.
ykman piv generate-certificate --subject "Knobelei" 9d pubkey.pem
# We do not need the public key on disk anymore
rm pubkey.pem
# Allow the security token to unlock the account of user 'lafcadio'.
homectl update lafcadio --pkcs11-token-uri=auto
مثال 5. برپایی
اعتبارسنجی
با یک توکن
امنیتی FIDO2:
# Allow a FIDO2 security token to unlock the account of user 'nihilbaxter'.
homectl update nihilbaxter --fido2-device=auto
مثال 6. افزودن
یک کلید
بازیابی به
یک حساب
کاربری
موجود:
# Generate and add a recovery key for user 'emily'.
homectl update emily --recovery-key=yes
- 1.
- رکوردهای
کاربری JSON
- 2.
- مشخصات
نامگذاری
آیکون
- 3.
- دایرکتوریهای
حباب (Blob)
رکورد
کاربر
- 4.
- نحو نام
کاربر/گروه
- 5.
- به
ابزارهای
دیگر توصیه
میشود که
$SUDO_UID را بر
حسب نیاز
تنظیم و
بررسی کنند
و با آن به
عنوان یک
رابط مشترک
رفتار
نمایند.
