توزيعات Linux غير القابلة للتغيير للخوادم: هل تستحق؟

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

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

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

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

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

يحمل خادم يعمل منذ عامين تاريخاً لم يدوّنه أحد. 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 هي الأداة التي عمّمت هذا النمط. وتصف نفسها بأنّها أداة لتحديث نظام التشغيل بشكل transactional وin-place باستخدام صور حاويات OCI (open container initiative)، وهي مشروع ضمن CNCF Sandbox. يصبح خادمك عبارة عن Containerfile. اعتباراً من August 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. والفرق هو ما يتم تطبيقه. يطبّق مؤقت نمط الحزم أي إصدارات يحتويها المستودع في تلك الليلة، ولذلك تختلف المجموعة الناتجة قليلاً على كل جهاز. أمّا مؤقت نمط الصور فيطبّق أثراً واحداً سبق أن أقلعت باستخدامه في مكان آخر.

تنتج عن Containerfile قاعدتا بناء. يجب وضع البيانات القابلة للكتابة تحت /var، ولذلك يحتاج البرنامج الذي يصرّ على الكتابة داخل دليل التثبيت الخاص به إلى رابط رمزي أو إلى إضافة سطر BindPaths= في systemd أثناء البناء. كما يُدمج /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

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

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

Flatcar هو استمرار لـ CoreOS Container Linux، وهو الخيار الأكثر تقييداً بين الخيارات العامة. لا يوجد مدير حزم يمكن الاعتماد عليه عند الحاجة. كل ما تشغّله هو حاوية. تتم عملية التهيئة باستخدام Ignition، كما في Fedora CoreOS. التحديثات هي قسمَا /usr بنظام A/B المذكوران أعلاه، وتنفّذهما 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 ولا وحدة تحكم

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

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

استبدل الوسم بالإصدار الذي تريد الترقية إليه. تستخدم الترقية مخطط A-B يحتفظ بإصدار kernel وصورة نظام التشغيل السابقة، لذلك إذا فشل الإصدار الجديد في الإقلاع، ينفّذ Talos عملية rollback تلقائياً من دون تدخل. يختلف تصحيح الأخطاء لعدم وجود 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، ثم تحديث الخوادم. يكون ذلك منخفض التكلفة عند وجود خط الأنابيب. لكنه يتطلب عملاً فعلياً لإنشائه عند عدم وجوده، كما يحتاج إلى registry يمكن للخوادم الوصول إليه، ما يعني تشغيل خدمة أخرى أو دفع فاتورة أخرى.

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

وكلاء المورّد ومزوّد الخدمة. تُطرح عادةً وكلاء المراقبة والنسخ الاحتياطي على هيئة .deb أو .rpm مع install script يكتب في /usr ويفعّل وحدة. يفشل ذلك 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. لا يلغي نمط image العمل. بل ينقل العمل من الخادم إلى عملية build، ويضيف إليك registry ومسار pipeline لتنفيذ هذا النقل. إذا كان لديك مكان مناسب لتنفيذ هذا العمل، فستحصل على خوادم متطابقة، وتصبح عملية rollback مجرد إعادة تشغيل. أما إذا لم يكن لديك ذلك، فقد أضفت مكوّنات متحركة إلى خادم كان يعمل جيداً، وجعلت معالجة المشكلات عند الساعة 2 صباحاً أصعب.

لا يزال الحل العملي في المنطقة الوسطى صالحاً: توزيعة عادية مع تحديثات أمنية تلقائية، إضافة إلى عملية rebuild سبق أن اختبرتها فعلياً. اختيار هذه القاعدة قرار مستقل، وقد غُطي في اختيار نظام التشغيل الذي ستشغّله على VPS الخاص بك. نمط image ليس إلا أحدث جولة في نقاش قديم جداً حول كيفية وصول البرامج إلى الجهاز، وتاريخ توزيعات 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 إذا أردت مضيف حاويات minimal مع آلية تحديث A/B ومن دون مدير حزم يمكن لأي شخص استخدامه. اختر Talos فقط عندما يكون الجهاز عقدة Kubernetes، لأنه لا يحتوي على shell ولا يشغّل أي شيء آخر.