توزيعات Linux غير القابلة للتغيير للخوادم

ما هو توزيعة Linux غير قابلة للتغيير

توفّر توزيعة Linux غير القابلة للتغيير نظام التشغيل في صورة واحدة، لذلك تستبدل النظام بدلاً من ترقيعه موضعياً. لا توجد عملية apt upgrade لإعادة كتابة الملفات ضمن /usr على خادم قيد التشغيل. تنشئ صورة جديدة أو تسحبها، ثم يضعها الجهاز بجانب الصورة التي يعمل بها، وفي عملية إعادة التشغيل التالية يبدّل الصورة النشطة. تبقى الصورة السابقة على القرص، لذلك يكفي إعادة التشغيل للتراجع عن تحديث معيب.

تُبالغ كلمة «غير قابلة للتغيير» في وصفها. لا شيء يمنع root فعلياً من الكتابة إلى القرص. ما تفعله هذه الأنظمة هو تحميل أدلة النظام بوضع القراءة فقط، وإسناد ملكيتها إلى الصورة. توجد البيانات الدائمة في /var. ويوجد الإعداد الخاص بالجهاز في /etc. كل ما يوجد ضمن /usr تابع للصورة، ولذلك يحتفظ خادمان يشغّلان وسم الصورة نفسه بملفات نظام متطابقة.

تستخدم Red Hat تسميتين واضحتين للنموذجين: وضع الحزم ووضع الصور. وضع الحزم هو نظام قيد التشغيل مع مدير حزم يعدّله. أما وضع الصور فهو خطوة بناء تُنفّذ في مكان آخر وتنتج عنصراً برمجياً، وخادم تقتصر مهمته على إقلاع العنصر الذي تحدده له. تنشأ جميع التفاصيل التالية من هذا الاختلاف الواحد.

لماذا يهم النظام للقراءة فقط بدرجة أكبر على الخادم

يمتلك الخادم الذي يعمل منذ عامين تاريخاً لم يوثّقه أحد. make install ناتج عن مساء متعجل. ومستودع تابع لجهة خارجية أُضيف من أجل حزمة واحدة. وملف إعدادات عُدّل أثناء عطل ولم يُعَد إلى حالته السابقة في نظام إدارة الإعدادات. يُسمّى هذا انحراف الإعدادات، وهو سبب أن إعادة إنشاء «الخادم نفسه» من ملاحظاتك تنتج غالباً جهازاً يتصرف بطريقة مختلفة. تحتوي الملاحظات على الغرض المقصود. أما القرص فيحتوي على الواقع.

يزيل وضع Image المكان الذي يتراكم فيه الانحراف. /usr للقراءة فقط أثناء التشغيل، لذلك تفشل عملية التثبيت اليدوية مباشرة، أو تُسجَّل كطبقة يمكنك عرضها باستخدام أمر واحد. يجعل ذلك الفرق بين جهازين واضحاً بدلاً من أن يبقى مدفوناً في سجلهما. هذه هي المشكلة نفسها التي تعالجها قائمة التحقق الدورية لصيانة خادم Linux بالانضباط، لكن تُعالَج هنا من خلال نظام الملفات بدلاً من ذلك.

التراجع هو إعادة تشغيل، وهذه هي الفكرة كاملة

الفشل الذي صُمّم هذا النموذج لمعالجته هو الفشل الذي وثّقناه من قبل: خادم VPS لا يقلع بعد تحديث النواة. في وضع الحزم، تتعافى من وحدة تحكم الإنقاذ لدى المزوّد. توصل القرص، وتستخدم chroot، ثم تزيل حزمة نواة يدوياً. ينجح ذلك لأن محمّل الإقلاع يحتفظ بالنوى القديمة، لكن النواة وحدها مُدارة بالإصدارات بهذه الطريقة. أما تحديث glibc وتغييرات systemd التي طُبّقت في المعاملة نفسها، فقد طُبّقت بالفعل، ولا يوجد أمر واحد يعيدهما معاً إلى الحالة السابقة.

في وضع الصور، تكون الوحدة هي النظام بأكمله. على مضيف bootc:

sudo bootc status
sudo bootc rollback
sudo systemctl reboot

يعيد bootc rollback ترتيب محمّل الإقلاع إلى إدخال الإقلاع السابق، وهو صورة النظام التي كنت تشغّلها قبل ساعة، بالنواة ومساحة المستخدم معاً. لا يُنزَّل شيء ولا يُعاد بناء شيء، لأن الصورة القديمة لم تغادر القرص.

تنفّذ Fedora CoreOS العملية نفسها، ولكن بأسماء مختلفة:

sudo systemctl stop zincati.service
sudo rpm-ostree rollback -r

أوقف Zincati أولاً. Zincati هو الوكيل الذي يُبقي جهاز Fedora CoreOS على أحدث إصدار. لذلك، إذا تركته قيد التشغيل، فسيجهّز التحديث الذي تراجعت عنه للتو. تعيد -r التشغيل بعد تجهيز التراجع. للاحتفاظ بعملية نشر تثق بها ومنع جامع البيانات المهملة من حذفها:

sudo ostree admin pin 0
rpm-ostree status

يسرد rpm-ostree status عمليات النشر بالترتيب الذي سيعرضها به محمّل الإقلاع، ويضع نقطة بجانب العملية قيد التشغيل، ويعرض Pinned: yes بجانب العملية التي ثبّتَّها.

ينفّذ Talos ذلك باستدعاء API واحد من محطة عملك:

talosctl rollback --nodes 10.20.30.40

يحتفظ Flatcar بقسمي /usr ويتنقل بينهما. يحتوي كل موضع على أولوية وعداد لمحاولات الإقلاع في جدول الأقسام، لذلك ينفد عدد محاولات الموضع الذي لا يقلع بنجاح، ويختار محمّل الإقلاع الموضع الآخر. تحقّق من الموضع الذي تستخدمه وما إذا كان قد وُسِم بأنه سليم:

sudo cgpt show "$(rootdev -s /usr)" | grep successful=1

يطبع الموضع السليم قيد التشغيل سطراً يحتوي على priority=1 tries=0 successful=1. يعني عدم وجود سطر مطابق أن الموضع الحالي لم يُؤكَّد قط، وهي الحالة التي يكون فيها الجهاز بين تحديث وأول إقلاع نظيف بعده.

ما الذي يحل محل «تثبيت حزمة»: bootc وContainerfile

bootc هي الأداة التي عمّمت هذا النمط. وتصف نفسها بأنها أداة لإجراء تحديثات معاملاتية للنظام في مكانه، باستخدام صور حاويات OCI ‏(open container initiative)، وهي مشروع ضمن CNCF Sandbox. يصبح خادمك عبارة عن Containerfile. اعتباراً من أغسطس 2026، تكون صورة Fedora الأساسية هي quay.io/fedora/fedora-bootc:44، وتكون صورة CentOS Stream الأساسية هي quay.io/centos-bootc/centos-bootc:stream10.

FROM quay.io/fedora/fedora-bootc:44
RUN dnf -y install nginx && dnf clean all
RUN systemctl enable nginx

أنشئ الصورة وادفعها كما تفعل مع أي صورة أخرى:

sudo podman build -t registry.example.com/edge/web:2026-08-19 .
sudo podman push registry.example.com/edge/web:2026-08-19

ثم على الخادم:

sudo bootc upgrade --check
sudo bootc upgrade --apply

يستعلم bootc upgrade عن مصدر الصورة ويضع الصورة الجديدة في قائمة الانتظار للإقلاع التالي. يعرض --check ما إذا كان هناك تحديث متاحاً ولا يغيّر شيئاً. يعيد --apply التشغيل للإقلاع باستخدامها. يوجّه bootc switch registry.example.com/edge/web:next الجهاز إلى صورة مختلفة مع الحفاظ على /etc و/var، وبذلك يمكنك نقل الخادم بين مسارات الصور دون إعادة تثبيته.

لإجراء التحديثات دون تدخل، فعّل المؤقت الذي يوفّره المشروع:

sudo systemctl enable --now bootc-fetch-apply-updates.timer

هذا هو الحل في نمط الصور لموضوع التحديثات غير التفاعلية على Ubuntu ولموضوع dnf-automatic على Rocky وAlma. يكمن الفرق في ما يتم تطبيقه. يطبّق المؤقت في نمط الحزم الإصدارات التي يحتويها المستودع في تلك الليلة، لذلك تختلف المجموعة الناتجة قليلاً من جهاز إلى آخر. أما المؤقت في نمط الصور فيطبّق artifact واحداً سبق أن أقلعت به في مكان آخر.

تنتج عن Containerfile قاعدتا بناء. يجب وضع البيانات القابلة للكتابة تحت /var، لذلك يحتاج البرنامج الذي يصر على الكتابة داخل دليل التثبيت الخاص به إلى symlink أو إلى إضافة سطر systemd BindPaths= وقت البناء. كما يتم دمج /etc بطريقة ثلاثية عند التحديث، وهذا يعني أن الملف الذي لم تعدّله يكتسب الإصدار الجديد من الصورة، بينما يُحتفظ بالملف الذي عدّلته محلياً.

عندما تحتاج إلى أداة على جهاز يعمل لجلسة تصحيح أخطاء واحدة:

sudo bootc usr-overlay
sudo dnf -y install strace

يضيف ذلك overlay مؤقتاً قابلاً للكتابة على /usr، ويتم التخلص منه عند إعادة التشغيل التالية. استخدمه لفحص مشكلة، لا لإصلاحها. لا يمكنك تغيير kernel بهذه الطريقة، ويختفي كل ما تثبّته عند إعادة التشغيل، وهذا مقصود.

Fedora CoreOS: تهيئة مرة واحدة، وتحديثات مستمرة

لا يحتوي Fedora CoreOS على مُثبّت تفاعلي. تكتب ملف Butane بصيغة YAML، وتحوله إلى Ignition بصيغة JSON، ثم تسلّمه إلى الجهاز عند الإقلاع الأول:

podman run --interactive --rm quay.io/coreos/butane:release \
       --pretty --strict < your_config.bu > transpiled_config.ign

يعمل Ignition في initramfs عند الإقلاع الأول فقط. وهذه هي النقطة التي تربك المستخدمين القادمين من cloud-init. إذا لم يتضمن الإعداد مفتاح SSH، فسيقلع الجهاز دون وسيلة للوصول إليه، وسيكون الحل هو إعادة تهيئته من البداية. اختبر الإعداد على جهاز مؤقت قبل توجيهه إلى خادم مهم.

التثبيت على قرص من بيئة حية:

sudo coreos-installer install /dev/sda \
    --ignition-url https://example.com/example.ign

تكون التحديثات تلقائية افتراضياً. أنت تتحكم في وقتها، لا في حدوثها. ضع ملف TOML في /etc/zincati/config.d/55-updates-strategy.toml لاختيار الاستراتيجية الدورية:

[updates]
strategy = "periodic"

ضمن هذه الاستراتيجية، تضيف نافذة صيانة واحدة لكل إدخال في مصفوفة الجداول، بحيث تبدأ كل نافذة بالاسم updates.periodic.window مكتوباً بين قوسين مربعين مزدوجين بوصفه عنواناً، ثم تتبعه ثلاثة مفاتيح:

• days، قائمة بأسماء الأيام، مثل "Sat" و"Sun".
• start_time، وقت بدء النافذة، مكتوباً بصيغة "22:30".
• length_minutes، مدة بقاء النافذة مفتوحة، مثل 60.

هذه الأوقات بتوقيت UTC. لإيقاف التحديثات تماماً، شغّل sudo systemctl disable --now zincati.service، وتقبّل أنك أصبحت مسؤولاً عن جدولة التصحيحات.

تتوفر طبقات الحزم كخيار عند الضرورة:

sudo rpm-ostree install --allow-inactive vim
sudo systemctl reboot

ينشئ ذلك deployment جديداً مع إضافة الحزمة، ولا يسري التغيير إلا بعد إعادة التشغيل. لكن التكلفة تظهر لاحقاً. يُعاد تطبيق مجموعة الحزم ذات الطبقات فوق كل صورة أساسية جديدة، ولذلك فإن اختفاء حزمة من المستودع في يوم التحديث يؤدي إلى فشل ذلك التحديث. توجّهك وثائق Fedora نفسها إلى استخدام الحاويات لأي شيء جوهري، وإلى استخدام صورة bootc عندما تحتاج فعلاً إلى تغيير نظام التشغيل.

Flatcar Container Linux: لا يوجد مدير حزم على الإطلاق

Flatcar هو امتداد CoreOS Container Linux، وهو الخيار الأكثر تقييداً بين الخيارات العامة. لا يوجد مدير حزم يمكن الاعتماد عليه عند الحاجة. كل ما تشغّله هو حاوية. تتم عملية الإعداد باستخدام Ignition، كما في Fedora CoreOS. التحديثات هي قسمان من نوع A/B هما /usr المذكوران أعلاه، ويتولى update_engine تنفيذها، بينما يحدد locksmithd موعد إعادة التشغيل.

update_engine_client -status
update_engine_client -check_for_update

يعني UPDATE_STATUS_UPDATED_NEED_REBOOT أن الفتحة غير النشطة تحتوي بالفعل على الصورة الجديدة، ولم يتبقَّ سوى إعادة التشغيل. استراتيجية إعادة التشغيل الافتراضية هي reboot مع تأخير مدته خمس دقائق، لذلك سيُعاد تشغيل VPS واحد في بيئة الإنتاج وفق جدوله تلقائياً، ما لم تحدد خلاف ذلك. اضبط نافذة في /etc/flatcar/update.conf:

REBOOT_STRATEGY=reboot
LOCKSMITHD_REBOOT_WINDOW_START="Thu 04:00"
LOCKSMITHD_REBOOT_WINDOW_LENGTH=1h

يترك REBOOT_STRATEGY=off إعادة التشغيل لك. يؤدي SERVER=disabled في الملف نفسه إلى إيقاف التحقق من التحديثات بالكامل. في المجموعة، يحد REBOOT_STRATEGY=etcd-lock مع locksmithctl set-max 4 من عدد العقد التي يمكن إعادة تشغيلها في الوقت نفسه، لذلك لا يؤدي أي تحديث إلى إيقاف المجموعة بأكملها معاً.

Talos Linux: بلا shell ولا SSH ولا console

يُعدّ Talos الأضيق نطاقاً بين الأنظمة الأربعة، وهو الأوضح في تحديد الغرض منه. فهو يشغّل عقد Kubernetes. لا يوجد daemon لـSSH، ولا shell، ولا تسجيل دخول عبر console. تُنفَّذ كل عملية من خلال استدعاء gRPC API باستخدام talosctl من محطة العمل لديك، وبالاعتماد على machine config تحتفظ به في git.

talosctl upgrade --nodes 10.20.30.40 \
  --image ghcr.io/siderolabs/installer:v1.10.6

استبدل الوسم بالإصدار الذي تريد الترقية إليه. تستخدم الترقية مخطط A-B يحتفظ بنواة النظام وصورة نظام التشغيل السابقة. لذلك، إذا فشل الإصدار الجديد في الإقلاع، يتراجع Talos تلقائياً دون تدخل. يختلف تصحيح الأخطاء لأنّه لا يوجد shell. استخدم talosctl logs وtalosctl dmesg بدلاً من journalctl على الجهاز.

إذا لم تكن أعباء العمل لديك تعمل على Kubernetes، فإن Talos ليس الخيار المناسب. أما إذا كانت تعمل عليه، فإن Talos يلغي فئة كاملة من الحوادث، لأن عبارة «سجّل شخص الدخول إلى عقدة وغيّر شيئاً» لا يمكن أن تحدث.

ما الذي يتخلى عنه مستأجر VPS فعلياً

عمليات التثبيت المخصصة على نظام قيد التشغيل. هذه هي النقطة الأهم. لا يتوفر sudo apt install htop عند الساعة 2am أثناء حادثة. في bootc تحصل على overlay مؤقت يختفي عند إعادة التشغيل. في Fedora CoreOS تحصل على deployment بطبقات يتطلب إعادة التشغيل. أما في Flatcar وTalos فلا تحصل على شيء.

خط أنابيب بناء لم يكن لديك من قبل. تعني إضافة حزمة تعديل Containerfile، وبناء image، ودفعها إلى registry، ثم تنفيذ rolling للخوادم. تكون هذه العملية قليلة التكلفة عند توفر خط الأنابيب. لكنها تتطلب عملاً فعلياً لإنشائها عندما لا تكون موجودة، كما تحتاج إلى registry يمكن للخوادم الوصول إليه. وهذا يعني تشغيل خدمة أخرى أو دفع فاتورة أخرى.

وحدات kernel. يأتي kernel من image، ولذلك لا تستمر وحدة جرى تجميعها مقابل kernel قيد التشغيل بعد التحديث التالي. يجب بناء الوحدات خارج الشجرة وحزم DKMS (dynamic kernel module support) داخل image، مقابل kernel الخاص بذلك image. وكل ما يحتاج إلى وحدة لا تحملها image الأساسية يتحول إلى مشكلة بناء بدلاً من كونه مشكلة تثبيت.

وكلاء المورّد ومزوّد الخدمة. تُطرح عادةً وكلاء المراقبة والنسخ الاحتياطي على هيئة .deb أو .rpm، مع script للتثبيت يكتب داخل /usr ويفعّل unit. يفشل ذلك script على نظام للقراءة فقط. ينشر بعض المورّدين container أو يوثقون طريقة تثبيت تعتمد على image mode. لكن كثيرين لا يفعلون ذلك. تحقق من هذه النقطة قبل الالتزام، لأن أسطولاً لا يمكنك مراقبته أسوأ من أسطول ينحرف عن الحالة المطلوبة.

الـimage نفسها. لا تعرض تقريباً أي لوحة تحكم لـVPS Fedora CoreOS أو Flatcar أو Talos إلى جانب Ubuntu وDebian. أنت توفّر القرص، وهذا هو موضوع القسم التالي.

الحصول على إحدى هذه الصور على VPS تستأجره

تحقق أولاً من أمرين لدى مزود الخدمة: أن لديك وصولاً إلى وحدة تحكم خارج النطاق، أي VNC أو وحدة تحكم تسلسلية، وأنه يمكنك إقلاع نظام إنقاذ. من دون وحدة تحكم، يصبح الخادم الذي لا يعود إلى العمل تذكرة دعم بدلاً من إصلاح يستغرق خمس دقائق.

إذا كان مزود الخدمة يقبل الصور المخصصة، فارفع صورة البائع بصيغة raw أو qcow2 وينتهي العمل. وإلا فاكتب الصورة على القرص بنفسك من نظام الإنقاذ. يوفّر Flatcar نصاً برمجياً مستقلاً لهذا الغرض تحديداً، ويعمل من أي نظام Linux:

curl -fsSLO https://raw.githubusercontent.com/flatcar/init/flatcar-master/bin/flatcar-install
chmod +x flatcar-install
sudo ./flatcar-install -d /dev/sda -i ignition.json

شغّل ذلك من نظام الإنقاذ، وليس من الخادم الذي تستبدله، لأن النص يعيد تقسيم جهاز الهدف أثناء عمله. يحتاج الجهاز إلى مساحة قابلة للاستخدام لا تقل عن 8 GB، ويجب أن توفر بيئة الإنقاذ bash، أو bzip2 أو lbzip2، وlsblk، وwget، وudevadm، وgpg وgawk. يجب أن يحتوي ignition.json على مفتاح SSH، وإلا فلن يملك النظام المثبّت وسيلة للسماح لك بالدخول.

يتبع Fedora CoreOS البنية نفسها، ويعمل مثبّته داخل حاوية:

sudo podman run --pull=always --privileged --rm \
    -v /dev:/dev -v /run/udev:/run/udev -v .:/data -w /data \
    quay.io/coreos/coreos-installer:release \
    install /dev/vdb -i config.ign

تحقق من اسم الجهاز باستخدام lsblk قبل تشغيله. تؤدي الكتابة إلى الجهاز الخطأ إلى إتلاف كل ما كان موجوداً عليه، ولا تظهر مطالبة تأكيد.

يوفّر bootc المسار الوحيد الذي يتجاوز وضع الإنقاذ، لأنه يحوّل نظام Linux قيد التشغيل في مكانه:

sudo podman run --rm --privileged -v /dev:/dev -v /var/lib/containers:/var/lib/containers -v /:/target \
             --pid=host --security-opt label=type:unconfined_t \
             quay.io/fedora/fedora-bootc:44 \
             bootc install to-existing-root

اقرأ وثائق الصورة الأساسية التي تستخدمها قبل تشغيل ذلك، وجرّبه على خادم يمكنك التخلّي عنه. بعد إعادة التشغيل، يعمل الخادم بالصورة، وتختفي مجموعة الحزم التي كانت لديك.

من ينبغي أن يشغّل خادماً غير قابل للتغيير، ومن لا ينبغي له ذلك

استخدم هذا النهج إذا كانت خوادمك تعامل كموارد قابلة للاستبدال. أي إذا كنت تدير أجهزة كثيرة انطلاقاً من وصفة واحدة. وينطبق ذلك على عُقد CI (التكامل المستمر) التي تعمل لمدة ساعة، أو عُقد k3s أو Kubernetes التي تستبدلها بدلاً من إصلاحها. وينطبق أيضاً على أي بيئة تكون فيها الإجابة عن خادم متعطل معروفة مسبقاً: «احذفه وأنشئ خادماً آخر». يفيد هذا النهج أيضاً عندما تحتاج إلى إثبات ما يعمل على جهاز أمام مدقق، لأن الإجابة تكون image digest بدلاً من قائمة الحزم.

لا تستخدم هذا النهج إذا كان لديك VPS واحد تديره يدوياً، ويشغّل ثلاث خدمات، وتثبّت البرامج عند الحاجة، ولا تملك build pipeline. لا يلغي image mode العمل. بل ينقل العمل من الخادم إلى عملية البناء، ويضيف إلى هذه العملية registry وpipeline. إذا كان لديك مكان لتنفيذ هذا العمل، فستحصل على خوادم متطابقة، وعلى rollback لا يتطلب سوى إعادة التشغيل. أما إذا لم يكن لديك ذلك، فقد أضفت مكونات إلى خادم كان يعمل جيداً، وجعلت التعامل معه عند الساعة 2 صباحاً أصعب.

لا يزال الحل العملي المتوسط يعمل: توزيع عادي مع تحديثات أمنية تلقائية، إلى جانب عملية إعادة بناء جرّبتها فعلياً. اختيار هذا الأساس قرار مستقل، وتتناوله كيفية اختيار نظام التشغيل الذي ستشغّله على VPS الخاص بك. لا يمثل image mode سوى الجولة الأحدث من نقاش قديم جداً حول كيفية وصول البرامج إلى الجهاز، كما أن تاريخ توزيعات Linux يتمحور إلى حد كبير حول تكرار هذا النقاش.

FAQ

هل توزيعة Linux غير القابلة للتغيير غير قابلة للتغيير فعلاً؟

لا، والاسم يسبب التباساً. لا يزال بإمكان root الكتابة إلى القرص. ما يحدث فعلياً هو تحميل /usr للقراءة فقط أثناء التشغيل واستبداله بالكامل بالصورة التالية، بينما يبقى /etc و/var قابلين للكتابة وتستمر محتوياتهما عبر التحديثات. تُرفض التغييرات التي تجريها ضمن /usr في حينها أو تُحذف عند التحديث التالي، لذلك يكون الأثر العملي هو أن أدلة النظام لا تتغير إلا عند تغيّر الصورة.

هل يمكنني تشغيل Fedora CoreOS أو Flatcar على VPS لا يوفّرهما؟

عادةً نعم، إذا كان المزوّد يتيح لك نظام إنقاذ والوصول إلى وحدة التحكم. شغّل نظام الإنقاذ، واكتب صورة القرص الخاصة بالتوزيعة إلى جهاز الكتل، ثم أعد التشغيل. ينفّذ سكربت flatcar-install الخاص بـFlatcar ذلك من أي نظام Linux، بينما توفّر Fedora CoreOS coreos-installer في صورة حاوية يمكنك تشغيلها بالطريقة نفسها. يحتاج كلاهما إلى ملف Ignition يتضمن مفتاح SSH الخاص بك، لأنه لا توجد مطالبة بكلمة مرور عند الإقلاع الأول يمكن الاعتماد عليها. لا تحاول تنفيذ ذلك من دون الوصول إلى وحدة التحكم؛ فالجهاز الذي يفشل في العودة إلى التشغيل لن يتيح لك أي وسيلة لفحصه.

كيف أثبّت حزمة على خادم غير قابل للتغيير؟

أضفها إلى الصورة ثم أعد النشر. في bootc، تكون العملية عبارة عن سطر RUN dnf -y install ... في Containerfile، ثم إعادة البناء، ثم الدفع، وبعد ذلك تنفيذ sudo bootc upgrade --apply على الجهاز. في Fedora CoreOS، يمكنك إضافتها بطبقات باستخدام sudo rpm-ostree install ثم إعادة التشغيل، لكن ستُطبَّق هذه الحزمة مجدداً مع كل تحديث مستقبلي. في Flatcar وTalos لا يوجد مدير حزم، لذلك تكون الإجابة هي استخدام حاوية. ولأداة تصحيح أخطاء مؤقتة على مضيف bootc، يوفّر لك sudo bootc usr-overlay بيئة /usr قابلة للكتابة تختفي عند إعادة التشغيل التالية.

هل يحل image mode مشكلة VPS لا يقلع بعد تحديث kernel؟

يحوّل عملية الاسترداد من مهمة تتطلب وحدة تحكم لنظام الإنقاذ إلى مجرد إعادة تشغيل. تبقى الصورة السابقة، بما فيها kernel وuserspace، على القرص، لذلك يعيدك sudo bootc rollback أو sudo rpm-ostree rollback -r إليها. يذهب Talos وFlatcar إلى أبعد من ذلك، إذ يتراجعان تلقائياً عند فشل الإقلاع من الفتحة الجديدة، لأن إدخال الإقلاع لا يصبح الافتراضي إلا بعد إقلاع ناجح واحد. لا يمنع أي من ذلك التحديث السيئ، لكنه يجعل التراجع عنه سهلاً.

أي توزيعة غير قابلة للتغيير ينبغي أن أختار لخادم؟

اختر bootc إذا كنت تريد خادم Linux متعدد الأغراض تبنيه مثل صورة حاوية ويمكنك تثبيته على جهاز تملكه مسبقاً. اختر Fedora CoreOS إذا كنت تريد هذا النموذج مع تنفيذ عملية البناء نيابةً عنك وتحديثات تلقائية جاهزة. اختر Flatcar إذا كنت تريد مضيف حاويات بسيطاً يستخدم نظام تحديث A/B ولا يتضمن مدير حزم يمكن لأي شخص اللجوء إليه. اختر Talos فقط عندما يكون الجهاز عقدة Kubernetes، لأنه لا يوفّر shell ولا يشغّل أي شيء آخر.