نام (NAME)

ostree-state-overlay@.service - راه‌اندازی لایه‌های روکش وضعیت (state overlays)

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

ostree-state-overlay@.service

مدیریت /OPT (DEALING WITH /OPT)

نکته: به‌طور کلی، اولویت در مدیریت نرم‌افزارهای /opt استفاده از پیوندهای نمادین برای تنها بخش‌هایی است که نیاز به تغییرپذیری دارند به مکانی در /var که می‌تواند مثلاً توسط یک فایل tmpfiles.d ایجاد شود. برای اطلاعات بیشتر، ببینید: https://bootc-dev.github.io/bootc/building/guidance.html#handling-read-only-vs-writable-locations.

توضیحات (DESCRIPTION)

در برخی موارد، مفید است که بتوان یک دایرکتوری را به عنوان بخشی از کامیت OSTree داشت و در عین حال این دایرکتوری در سمت کلاینت قابل نوشتن باشد. یک نمونه، نرم‌افزاری است که در /opt ارائه می‌شود. /opt سلسله‌مراتب فایل جایگزین و دارای فضای نام اختصاصی ارائه‌دهنده نرم‌افزار است که ممکن است شامل کد و وضعیت باشد. با لایه‌های روکش وضعیت (state overlays)، می‌توان بخش کد را در OSTree تثبیت کرد، در حالی که همچنان به دایرکتوری اجازه داده می‌شود قابل نوشتن باشد تا وضعیت در آنجا نگهداری شود.

از آنجا که این دایرکتوری قابل نوشتن است، هیچ چیز مانع از آن نمی‌شود که کد دارای مجوز کافی، محتوای حاصل از کامیت OSTree را تغییر دهد یا حذف کند. این در تضاد آشکار با محتوای /usr است و بیشتر با توزیع‌های مبتنی بر مدیر بسته مطابقت دارد.

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

برای فعال‌سازی این قابلیت، کافی است الگوی واحد را نمونه‌سازی کنید و از مسیر هدف (با نشانه‌گذاری مسیر اسکیپ‌شده در systemd) به عنوان نام نمونه استفاده نمایید. برای نمونه، جهت فعال‌سازی آن روی /opt:

$ systemctl enable --now ostree-state-overlay@opt.service