Scroll to navigation

SYSTEMD.OFFLINE-UPDATES(7) systemd.offline-updates SYSTEMD.OFFLINE-UPDATES(7)

الاسم

systemd.offline-updates - تطبيق التحديثات غير المتصلة في systemd

تطبيق تحديثات النظام غير المتصلة

تصف صفحة الدليل هذه كيفية تنفيذ تحديثات النظام "غير المتصلة" باستخدام systemd. نقصد بتحديثات نظام التشغيل "غير المتصلة" تثبيت الحزم والتحديثات التي تُشغّل مع إقلاع النظام في وضع تحديث نظام خاص، لتجنب المشكلات المتعلقة بتعارض المكتبات والخدمات الجاري تشغيلها حاليًا مع تلك الموجودة على القرص. هذا المستند مستوحى من السبورة البيضاء لتصميم GNOME[1].

المنطق:

1.يُحضّر مدير الحزم تحديثات النظام بتنزيل جميع الحزم (.rpm أو .deb أو أيًا كان) لتحديثها دون اتصال في دليل خاص /var/lib/system-update (أو دليل آخر من اختيار مدير الحزم/الترقية).

2.عندما يوافق المستخدم على التحديث، يُنشأ الرابط الرمزي /system-update أو /etc/system-update الذي يشير إلى /var/lib/system-update (أو أينما كان الدليل الذي يحتوي على ملفات الترقية) ويُعاد تشغيل النظام. هذا الرابط الرمزي موجود في الدليل الجذر، لأننا نحتاج إلى التحقق منه مبكرًا جدًا عند الإقلاع، في وقت لا يكون فيه /var/ متاحًا بعد.

3.في مرحلة مبكرة جدًا من عملية التشغيل الجديدة، يقوم systemd-system-update-generator(8) بالتحقق من وجود /system-update أو /etc/system-update. إذا كان الأمر كذلك، فإنه (مؤقتًا ولهذا التشغيل فقط) يعيد توجيه (أي الروابط الرمزية) default.target إلى system-update.target، وهو هدف خاص يستدعي النظام الأساسي (أي sysinit.target، بحيث تُوصل جميع أنظمة الملفات دون غيرها) ووحدات تحديث النظام.

4.يستمر النظام الآن في الإقلاع إلى default.target، وبالتالي إلى system-update.target. يسحب هذا الهدف جميع وحدات تحديث النظام. يجب أن تؤدي خدمة واحدة فقط التحديث (انظر النقطة التالية)، ويجب أن تخرج جميع الخدمات الأخرى بشكل نظيف مع رمز إرجاع "نجاح" ودون فعل أي شيء. يجب ترتيب خدمات التحديث بعد sysinit.target بحيث يبدأ التحديث بعد وصل جميع أنظمة الملفات.

5.كخطوة أولى، يجب أن تتحقق خدمة التحديث مما إذا كان الرابط الرمزي /system-update أو /etc/system-update يشير إلى الموقع المستخدم من قبل خدمة التحديث تلك. في حالة عدم وجوده أو الإشارة إلى موقع مختلف، يجب أن تخرج الخدمة دون خطأ. من الممكن تثبيت خدمات تحديث متعددة، وإطلاق خدمات تحديث متعددة بالتوازي، ويجب فقط للخدمة التي تتوافق مع الأداة التي أنشأت الرابط الرمزي قبل إعادة التشغيل أن تنفذ أي إجراءات. من غير الآمن تشغيل تحديثات متعددة بالتوازي.

6.يجب أن تؤدي خدمة التحديث الآن مهمتها. إذا كان ذلك مناسبًا وممكنًا، يجب أن تنشئ لقطة لنظام الملفات، ثم تثبت جميع الحزم. بعد الانتهاء (بغض النظر عما إذا نجح التحديث أو فشل)، يجب إعادة تشغيل الجهاز، على سبيل المثال عن طريق استدعاء systemctl reboot. بالإضافة إلى ذلك، عند الفشل، يجب أن يعود البرنامج النصي إلى لقطة نظام الملفات القديمة (بدون الرابط الرمزي).

7.يجب أن تخرج نصوص التحديث فقط بعد انتهاء التحديث. من المتوقع أن تتسبب الخدمة التي تؤدي التحديث في إعادة تشغيل الجهاز بعد الانتهاء. إذا تم الوصول إلى system-update.target بنجاح، أي أن جميع خدمات التحديث قد شُغّلت، ولا يزال الرابط الرمزي /system-update أو /etc/system-update موجودًا، فسيُزال ويُعاد تشغيل الجهاز كإجراء أمان.

8.بعد إعادة التشغيل، وبما أن الرابط الرمزي /system-update و /etc/system-update قد اختفى، لن يعيد المولد توجيه default.target بعد الآن ويُقلع النظام الآن إلى الهدف المبدئي مرة أخرى.

التوصيات

1.لجعل الأمور أكثر متانة قليلاً، نوصي بربط نص التحديث بـ system-update.target عبر رابط رمزي .wants/ في حزمة التوزيع، بدلاً من الاعتماد على systemctl enable في نصوص postinst لحزمتك. بشكل أكثر تحديدًا، لنص التحديث الخاص بك، أنشئ ملف .service بدون قسم [Install]، ثم أضف رابطًا رمزيًا مثل /usr/lib/systemd/system/system-update.target.wants/foobar.service → ../foobar.service إلى حزمتك.

2.تأكد من إزالة الروابط الرمزية /system-update و /etc/system-update في أقرب وقت ممكن في نص التحديث لتجنب حلقات إعادة التشغيل في حالة فشل التحديث.

3.استخدم FailureAction=reboot في ملف الخدمة الخاص بنص التحديث الخاص بك لضمان تشغيل إعادة التشغيل تلقائيًا في حالة فشل التحديث. يضمن FailureAction= تنشيط الوحدة المحددة في حالة خروج النص الخاص بك بشكل غير سليم (بسبب رمز خطأ غير صفر، أو إشارة/تفريغ الذاكرة). إذا نجح البرنامج النصي الخاص بك، فيجب عليك تشغيل إعادة التشغيل في الكود الخاص بك، على سبيل المثال عن طريق استدعاء logind's Reboot() أو استدعاء systemctl reboot. انظر org.freedesktop.login1(5) للحصول على تفاصيل حول واجهة برمجة تطبيقات D-Bus الخاصة بـ logind.

4.يجب أن تعلن خدمة التحديث DefaultDependencies=no و Requires=sysinit.target و After=sysinit.target و After=system-update-pre.target و Before=system-update.target وتسحب صراحة أي خدمات أخرى تتطلبها.

5.قد يكون من المرغوب فيه تشغيل وحدة مساعدة دائمًا عند الإقلاع في وضع التحديثات غير المتصلة، والتي لا تثبت التحديثات بنفسها. للقيام بذلك، أنشئ ملف .service مع Wants=system-update-pre.target و Before=system-update-pre.target وأضف رابطًا رمزيًا إلى هذا الملف تحت /usr/lib/systemd/system-update.target.wants .

انظر أيضًا

systemd(1), systemd.generator(7), systemd-system-update-generator(8), dnf.plugin.system-upgrade(8)

ملاحظات

1.
السبورة البيضاء لتصميم GNOME
https://wiki.gnome.org/Design/OS/SoftwareUpdates

ترجمة

تُرجمت هذه الصفحة من الدليل بواسطة زايد السعيدي <zayed.alsaidi@gmail.com>

هذه الترجمة هي وثيقة مجانية؛ راجع رخصة جنو العامة الإصدار 3 أو ما بعده للاطلاع على شروط حقوق النشر. لا توجد أي ضمانات.

إذا وجدت أي أخطاء في ترجمة صفحة الدليل هذه، يرجى إرسال بريد إلكتروني إلى قائمة بريد المترجمين: kde-l10n-ar@kde.org.

systemd 261~rc3