Systemd 260: TPM2، والعزل، والقدرات الجديدة في لينكس

دليل الأجهزة » أدلة الشراء » Systemd 260: TPM2، والعزل، والقدرات الجديدة في لينكس

مع إطلاق systemd 260، تخطو توزيعات لينكس خطوةً هامةً أخرى نحو بيئةٍ أكثر حداثةً وأمانًا، مُصممة خصيصًا للبيئات السحابية والافتراضية والأتمتة. لا يقتصر هذا الإصدار على تحسين التفاصيل فحسب، بل يُدخل تغييراتٍ جوهريةً على عمليات الإقلاع، وإدارة الخدمات، والشبكات، واستخدام TPM2 لضمان سلامة البيانات وتشفيرها، بالإضافة إلى إمكانيات الحماية على مستوى القرص.

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

وداعًا نهائيًا لنظام System V والاعتماد الكامل على محركات الأقراص الأصلية

من أبرز التغييرات في نظام systemd 260 هو الإزالة الكاملة لدعم نصوص System V البرمجية . كانت عملية الإقلاع التقليدية القائمة على /etc/init.d قد تم التخلي عنها تدريجياً لسنوات، ولكنها الآن اختفت فعلياً من كود systemd.

هذا يعني إزالة المكونات المسؤولة عن الربط بين نصوص SysV والوحدات الأصلية: لم تعد المكونات systemd-rc-local-generator وrc-local.service وsystemd-sysv-generator وsystemd-sysv-install موجودة. ونتيجةً لذلك، لن تعمل أي خدمة تعتمد على هذه الآليات القديمة على الأنظمة التي تستخدم systemd 260.

أثناء عملية التنظيف، تمّ تصنيف العديد من خيارات بناء Meson على أنها قديمة أو إزالتها. تمّ نقل الخيارات -Drc-local= و-Dsysvinit-path= و-Dsysvrcnd-path= إلى الأرشيف، بينما تمّ حذف خيارات أخرى مثل -Dintegration-tests= و-Dcryptolib= نهائيًا. هذا يُرسل رسالة واضحة: يجب الآن التعامل مع كل شيء بواسطة الوحدات الأصلية وبنية systemd الحديثة.

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

متطلبات أعلى لنواة النظام والتركيز على البيئات الحالية

يرفع الإصدار الجديد معايير نواة النظام: فمن الآن فصاعدًا، أصبح الحد الأدنى لإصدار لينكس المدعوم هو 5.10 ، متجاوزًا بذلك الإصدارات القديمة جدًا مثل 5.4. علاوة على ذلك، يشير المشروع إلى أنه من الأفضل للمستخدمين العمل على نواة 5.14 أو أحدث ، ويوصي تحديدًا بسلسلة 6.6 للاستفادة الكاملة من جميع الميزات المتاحة.

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

على النقيض تمامًا، تميل توزيعات الإصدارات المتجددة مثل Arch Linux وopenSUSE Tumbleweed، الشائعة جدًا بين الراغبين في الحصول على أحدث الميزات، إلى دمج نواة جديدة وفروع جديدة من systemd بسرعة. بينما تحافظ توزيعات أخرى، مثل Fedora، على درجة من الاستقرار في الإصدار الرئيسي من systemd طوال دورة حياة كل إصدار، مما يتيح وقتًا أطول للتخطيط لعمليات الترقية.

دعم TPM2، وسلامة الإقلاع، ودعم SRK المتقدم

يُعدّ تكامل نظام systemd مع وحدة TPM2 (وحدة النظام الأساسي الموثوقة 2.0) أحد أبرز المجالات التي يشهد فيها النظام تطوراً ملحوظاً . تسمح هذه الشريحة، الشائعة بشكل متزايد في اللوحات الأم الحديثة المزودة بواجهة UEFI وفي الأجهزة متوسطة وعالية الأداء، بربط البيانات السرية بحالة النظام، وقياس مراحل الإقلاع، وفتح وحدات التخزين المشفرة تلقائياً عندما تكون بيئة التشغيل سليمة.

يُعزز نظام Systemd 260 هذا التكامل بإضافة أدوات وخدمات تُغطي مراحل مختلفة من عملية الإقلاع. ومن أهم مكوناته systemd-tpm2-setup ، المسؤول عن إعداد البنية التحتية حول مفتاح الجذر التخزيني (SRK) الخاص بوحدة TPM . ويُشكل هذا المفتاح الأساس التشفيري لتأمين الاتصال مع الشريحة ولتخزين البيانات السرية الأخرى بشكل آمن.

أثناء عملية الإقلاع، تُميّز مرحلتان: مرحلة مبكرة جدًا في نظام initrd، وأخرى في نظام الجذر. في المرحلة الأولى، تتحقق خدمة تُسمى "إعداد مفتاح الأمان TPM المبكر" مما إذا كان مفتاح الأمان مُخزّنًا في وحدة TPM، وإذا لم يكن موجودًا، تُنشئه وتُتيحه مؤقتًا في المسار /run/systemd/tpm2-srk-public-key.* . لاحقًا، بمجرد تحميل نظام الملفات الفعلي، تُوحّد الخدمة مفتاح الأمان وتتحقق من تطابق المفتاح المُخزّن في /var/lib/systemd/tpm2-srk-public-key.pem مع المفتاح الموجود في وحدة TPM.

في الحالات المُهيأة جيدًا، ستظهر سجلات النظام مثل "تم تخزين SRK بالفعل في وحدة TPM" ورسائل تُشير إلى أن حجم SRK يُطابق الحجم المُتوقع. مع ذلك، إذا لم يتم تهيئة البيئة بشكل صحيح (على سبيل المثال، في الإعدادات التي تستخدم Yocto أو على لوحات مثل Raspberry Pi مع وحدة TPM تعتمد على SPI وطرق إقلاع مُخصصة مثل U-Boot والإقلاع المُقاس)، فقد تنشأ حالات يفشل فيها systemd في إنشاء هذه الملفات ضمن /var/lib/systemd، مما يُثير الشكوك حول ما إذا كان SRK قد تم تكوينه بشكل صحيح.

عند تغيير حالة وحدة TPM، أو تعديل الأقسام، أو تغيير تسلسل الإقلاع، قد لا تكون السياسة المرتبطة بها صالحة. في مثل هذه الحالات، يوصي بعض المسؤولين بمسح خانة TPM أو السياسة وإعادة تسجيل المفتاح ، باتباع إجراءات مشابهة لتلك الموضحة في أدلة تشفير القرص باستخدام TPM في بيئات مثل openSUSE، والتي تشرح بالتفصيل كيفية إعادة إنشاء سياسة PCR وإعادة ربط فتح وحدة التخزين.

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

يتم تعزيز التكامل مع بنية قياس الإقلاع بشكل أكبر من خلال وحدات محددة مثل systemd-pcrextend ، التي تسجل أحداثًا مثل "enter-initrd" و"leave-initrd" و"sysinit" و"ready" في سجلات PCR المختلفة (مثل PCR 11). يتيح هذا التسلسل من الامتدادات لوحدة TPM تجميع سجل قابل للتحقق تشفيرياً لعملية الإقلاع، والذي يمكن استخدامه بعد ذلك لسياسات الإقلاع الموثوق أو لتقنية UKI (صور النواة الموحدة) للتحقق من حالة الجهاز قبل إصدار المفاتيح.

إجراءات أمنية وعزل الخدمات باستخدام نظام systemd

لا يقتصر دور Systemd على بدء العمليات فحسب، بل يوفر أيضًا مجموعة شاملة من توجيهات الحماية المعزولة لعزل الخدمات والحد من الأضرار في حال حدوث اختراق. يعتمد هذا النهج الدفاعي المتعدد الطبقات على مجموعات التحكم (cgroups) ومساحات الأسماء وقدرات النواة وفلاتر استدعاءات النظام (seccomp).

لتقييم أمان خدمة معينة، يتضمن نظام systemd أداة systemd-analyze الأمنية . عند تشغيلها، تُنشئ تقريرًا يتضمن درجة تعرض أمني تتراوح من 0 إلى 10، حيث تشير الدرجة الأقل إلى أمان أفضل. يُفصّل التقرير إجراءات الحماية المُفعّلة أو المُعطّلة (مثل عزل الشبكة، والوصول إلى نظام الملفات، والوصول إلى الجهاز، إلخ)، مما يُسهّل تحديد الإعدادات المفقودة والتحقق مما إذا كانت التغييرات تُحسّن الدرجة بالفعل.

بدلاً من تعديل الوحدة الأصلية - والتي ستُفقد في تحديثات الحزمة المستقبلية - يُوصى بإنشاء تجاوز en /etc/systemd/system/mi-servicio.service.d/ باستخدام ملف، على سبيل المثال، sandbox.confبعد تعديله، ما عليك سوى إعادة تحميل التكوين باستخدام systemctl daemon-loading وأعد تشغيل الخدمة حتى تدخل القيود الجديدة حيز التنفيذ.

على مستوى نظام الملفات، يُعد أحد أهم الخيارات هو نظام الحماية =قيم مثل strict, full o true يقومون بتثبيت أجزاء مختلفة من الشجرة في وضع القراءة فقط. والممارسة المعتادة، كلما أمكن ذلك، هي استخدام ProtectSystem=strictهذا يجعل /usr و/boot و/efi و/etc للقراءة فقط بالنسبة للخدمة. إذا احتاج تطبيق ما إلى الكتابة إلى أدلة محددة، فإنه يُسمح له بالقيام بذلك باستخدام ReadWritePaths=/path في الوحدة.

لتعزيز الخصوصية بشكل أكبر، يُنصح أيضًا بتقييد الوصول إلى مجلدات المستخدمين باستخدام `ProtectHome=true` ، مما يمنع الخدمة من قراءة `/home` أو `/root` أو `/run/user`. بالإضافة إلى ذلك، يُنشئ `PrivateTmp=true` مساحات `/tmp` و`/var/tmp` معزولة، مما يمنع إمكانية وصول العمليات المختلفة إلى الملفات المؤقتة.

في قسم الأجهزة، يُخفي الخيار `PrivateDevices=true` شجرة `/dev` الفعلية ويستبدلها بمجموعة صغيرة من الأجهزة الوهمية الآمنة (null، zero، random، إلخ). إذا احتاج محرك أقراص إلى جهاز معين (على سبيل المثال، منفذ تسلسلي أو كتلة قرص)، فيمكن منحه صلاحية الوصول باستخدام `DeviceAllow=/dev/xxx rw` أو في وضع القراءة فقط.

تُعد الشبكة أيضاً عاملاً رئيسياً. PrivateNetwork=true يتم إنشاء مساحة اسم شبكة معزولة، بحيث لا يتبقى سوى عنوان الاسترجاع؛ ولن ترى الخدمة واجهات فعلية ولن تتمكن من التواصل مع العالم الخارجي. بدلاً من ذلك، يمكنك تقييد عائلات العناوين التي يمكنها استخدامها عن طريق RestrictAddressFamilies=يسمح فقط بـ AF_INET و AF_INET6 لبروتوكول IPv4/IPv6، و AF_UNIX للمقابس المحلية أو حتى none لإضفاء الطابع الياباني الكامل على قدرات الشبكة.

فيما يتعلق بالصلاحيات، يُعدّ التوجيه `NoNewPrivileges=true` من أقوى التوجيهات، إذ يمنع العملية من اكتساب صلاحيات جديدة عبر ملفات setuid الثنائية أو تغييرات الصلاحيات. باختصار، حتى لو نفّذت الخدمة شيفرةً برمجيةً ضعيفة، فلن تتمكن من الوصول إلى صلاحيات الجذر عبر الآليات التقليدية. وبالاقتران مع `CapabilityBoundingSet=` ، الذي يُحدّد قائمة الصلاحيات المسموح بها بدقة (على سبيل المثال، `CAP_NET_BIND_SERVICE` فقط للاستماع على المنافذ ذات الصلاحيات المحدودة)، يتم تقليل مساحة الهجوم إلى أدنى حد.

وللمضي قدمًا، يسمح نظام systemd بتصفية استدعاءات النظام باستخدام SystemCallFilter=بدلاً من الاحتفاظ بقائمة يدوية لاستدعاءات النظام، يتم استخدام مجموعات محددة مسبقًا، مثل @system-service, @network-io, @basic-io أو رفض مجموعات مثل ~@privileged. مع systemd-analyze syscall-filter من الممكن فحص المكالمات المحددة التي تنتمي إلى كل مجموعة. وهذا يسمح بإنشاء ملف تعريف تنفيذ محدود للغاية، على غرار ما توفره بيئة اختبار مخصصة.

تشمل الإعدادات الأخرى ذات الصلة: `ProtectKernelTunables=true` ، الذي يمنع تعديل معلمات النواة في `/proc/sys` و`/sys`؛ و`ProtectKernelModules=true` ، الذي يمنع تحميل أو إلغاء تحميل الوحدات النمطية؛ و`ProtectKernelLogs=true` ، الذي يمنع قراءة سجلات النواة؛ و` ProtectControlGroups=true` ، الذي يمنع الكتابة إلى تسلسل cgroups الهرمي. يعمل كل هذا بسلاسة مع إمكانيات عزل المستخدم الجديدة مثل ` PrivateUsers=full` ، الذي تم تحديثه في الإصدار 260 ليشمل النطاق الكامل لمعرفات المستخدم، مما يلغي الحاجة إلى الحلول البديلة السابقة لبيئات systemd المتداخلة.

المستخدمون الخاصون، وxaccess، وضوابط الوصول الجديدة للأجهزة

تم دمج آلية PrivateUsers ، المصممة للسماح بتشغيل الخدمات في نطاق معرف مستخدم معزول، في systemd 260. يُتيح الخيار PrivateUsers=full الآن ربط النطاق الكامل للمعرفات، مما يُبسط الأمور في الحاويات وعلى الأنظمة التي تحتوي على مثيلات systemd متداخلة تستند إلى إصدارات أقدم (قبل 257). وقد أدى هذا التحسين إلى التخلص من الحيل التي كانت تُستخدم سابقًا للكشف عن هذه المثيلات القديمة.

في الوقت نفسه، قدمت مكونات مثل systemd-logind و systemd-udevd مفهوم xaccess . تُكمل هذه الآلية منطق uaccess التقليدي ، الذي يمنح الوصول إلى أجهزة معينة (مثل الصوت أو الفيديو) للمستخدمين الذين لديهم جلسات رسومات أمامية على الجهاز المحلي. باستخدام xaccess، يمكن تفويض الصلاحيات إلى مستخدمين عن بُعد لديهم جلسات مُحددة ، بحيث يمكن، على سبيل المثال، للمستخدم المتصل عبر سطح المكتب البعيد الوصول إلى أجهزة عرض GPU المحلية دون منح صلاحيات واسعة للنظام بأكمله.

يتضمن تكوين هذه الجلسات متغيرات بيئية يتم عرضها عبر PAM، وتحديدًا PAMXDG_SESSION_EXTRA_DEVICE_ACCESS= ، مما يسمح بتحديد الأجهزة المحددة المشمولة في هذه العملية. يتوافق هذا النهج بشكل كبير مع متطلبات الامتثال التنظيمي وحماية البيانات في الاتحاد الأوروبي، حيث يُشترط توفير مستوى عالٍ من الدقة وإمكانية التتبع للوصول إلى الأجهزة الحساسة.

mstack و systemd-mstack وأدوات الحاويات الجديدة

في مجال الحاويات، يقدم نظام systemd 260 الوظائف التالية مستاك وأمر مرتبط به، systemd-mstackتتمثل الفكرة وراء mstack في السماح بتحديد تراكب استنادًا إلى بنية دليل خاص يسمى .mstack/، والذي يتبع مواصفات محددة لتنظيم طبقاته.

تُسهّل أداة سطر الأوامر الجديدة، systemd-mstack، التعامل التفاعلي مع حزم أنظمة الملفات هذه، مما يُضيف مرونةً عند إعداد بيئات متعددة الطبقات للحاويات أو الخدمات المعزولة للغاية. وترتبط هذه الوظيفة أيضًا بتحسينات في systemd-importd ، التي تُوسّع دعمها لتنزيل وإدارة صور OCI ، مما يُعزز دور systemd كمحرك للحاويات والعزل، وهو أمر شائع جدًا بين مُزودي الخدمات السحابية الأوروبيين ومنصات الاستضافة الحديثة.

الشبكة: التكامل مع مدير المودم وخيارات الأداء الجديدة

على مستوى الشبكة، يواصل نظام systemd-networkd اكتساب أهمية متزايدة. ومن أبرز ميزاته الجديدة تكامله مع ModemManager عبر بروتوكول "simple connect" ، مما يسمح بإدارة أجهزة المودم واتصالات الهاتف المحمول مباشرةً من networkd دون الحاجة إلى أدوات خارجية.

ولدعم هذا التدفق، تمت إضافة قسم جديد. إلى ملفات التكوين، مع معلمات مثل APN=, AllowedAuthenticationMechanisms=, User=, Password=, IPFamily=, AllowRoaming=, PIN=, OperatorId=, RouteMetric= y UseGateway=وهذا يسهل عمليات النشر في المناطق الريفية أو البيئات التي تعتمد فيها الاتصالات على شبكات الهاتف المحمولوهي موجودة بكثرة في بعض مناطق أوروبا حيث لا تتوفر دائمًا الألياف الضوئية أو خطوط الهاتف الأرضية عالية الجودة.

من حيث الأداء، تتضمن ملفات systemd-networkd .link خيارات جديدة خاصة بأجهزة الإيثرنت. تشمل هذه الخيارات ScatterGather وScatterGatherFragmentList وTCPECNSegmentationOffload وTCPMangleIdSegmentationOffload وGenericReceiveOffloadList وGenericReceiveOffloadUDPForwarding . تتيح هذه الخيارات ضبطًا دقيقًا لتفريغ العمل إلى الأجهزة وبرامج التشغيل، وهو أمر بالغ الأهمية في شبكات الشركات ومراكز البيانات ومزودي الخدمات الذين يحتاجون إلى تقليل كل جزء من الثانية من زمن الاستجابة.

علاوة على ذلك، يمكن لواجهات Varlink وJSON الخاصة بـ systemd-networkd الآن عرض عناوين IP بتنسيق سهل القراءة (سلاسل نصية) مع الحفاظ على تمثيلها كمصفوفة أعداد صحيحة. هذا يُسهّل التكامل مع لوحات معلومات المراقبة، وبرامج إدارة النظام، أو أدوات الطرف الثالث التي لا ترغب في التعامل مع التنسيقات الرقمية غير البديهية.

قابلية نقل الخدمة، والآلات الافتراضية المؤقتة، والخدمات غير المميزة

يكتسب مكون systemd-portabled ، المسؤول عن إدارة الخدمات "المحمولة" المعبأة في صور، قدرةً مثيرةً للاهتمام: إذ أصبح بإمكانه الآن العمل كخدمة على مستوى المستخدم . وهذا يعني أن المستخدمين غير المتميزين، في جلساتهم العادية، يمكنهم تشغيل وإدارة الخدمات المحمولة ضمن مساحتهم الخاصة دون الحاجة إلى استخدام sudo أو امتيازات إضافية.

علاوة على ذلك، بدءًا من هذا الإصدار، يُمكن لـ portabled إنشاء سياسات وقفل الصورة المرتبطة بخدمة محمولة ، مما يمنع تعديل تلك الصورة دون إعادة ربطها. يتيح هذا للمستخدمين إعداد بيئات مستقلة ذاتيًا مع ضمانات إضافية لعدم قابلية التغيير، وهي ميزة جذابة بشكل خاص للمختبرات وبيئات التطوير وبيئات الاختبار المعزولة.

من جهة أخرى، يُوسّع systemd-vmspawn ، الأداة المصممة لتشغيل الأجهزة الافتراضية بشكل متكامل مع systemd، قدراته للتسجيل في systemd-machined ضمن جلسة المستخدم . كما يُقدّم خيار `-ephemeral` لإنشاء أجهزة افتراضية مؤقتة تُحذف تلقائيًا عند انتهاء استخدامها. يُعدّ هذا حلاً مثاليًا لخطوط أنابيب التكامل المستمر/التسليم المستمر (CI/CD)، والفصول الدراسية الافتراضية، والمنصات التعليمية الأوروبية التي تتطلب إنشاء وحذف الأجهزة الافتراضية بسرعة وبشكل مُتحكّم به.

تحكم دقيق في وحدة المعالجة المركزية والذاكرة وجدولة المهام باستخدام SCHED_EXT وTHP

يتناول نظام Systemd 260 أيضًا التحكم في الأداء من خلال سياسات جديدة. خيار الخدمة سياسة جدولة وحدة المعالجة المركزية = الآن اقبل القيمة ext، مما يؤدي إلى تفعيل المجدول SCHED_EXTيفتح هذا المخطط البديل الباب أمام تجارب مع سياسات تخطيط مختلفة وفقًا لمعايير النواة، وهو أمر قد يكون ذا أهمية في مختبرات البحث والتطوير أو في عمليات النشر المتخصصة للغاية.

في قسم الذاكرة، ستجد `MemoryTHP=` ، الذي يتيح لك إدارة استخدام صفحات الذاكرة الضخمة الشفافة (THP) على مستوى كل خدمة على حدة. فبدلاً من إعداد عام على مستوى النظام، يمكنك تحديد ما إذا كان ينبغي لوحدة معينة استخدام THP، أو تعطيلها، أو اعتماد أوضاع وسيطة. بالنسبة للتطبيقات الحيوية في قطاعات البنوك والتأمين والحكومة، يمكن لهذا التحكم الدقيق أن يُحدث فرقًا كبيرًا في زمن الاستجابة واستهلاك الذاكرة والأداء.

أوامر جديدة في systemctl واستخدام موسع لـ Varlink

يُضاف إلى أمر systemctl المألوف أمرٌ جديد: enqueue-marked . يستدعي هذا الأمر داخليًا دالة EnqueueMarkedJobs() في D-Bus ، مما يسمح بالعمل مع قوائم انتظار المهام والخدمات المُعلّمة مسبقًا. قد يبدو هذا تفصيلًا بسيطًا، لكنه بالنسبة لفرق العمليات التي تُدير مزارع خوادم واسعة النطاق، يُعد أداةً إضافية لتحسين عمليات النشر والأتمتة.

بالتوازي مع ذلك، يواصل المشروع توسيع استخدام Varlink كآلية اتصال بين المكونات. توفر أجزاء كثيرة من systemd واجهات Varlink مستقرة، مما يسهل التكامل مع الأدوات الخارجية، ولوحات المعلومات المخصصة، أو عوامل المراقبة التي تتطلب وصولاً منظماً إلى معلومات النظام.

حقول تعريف النظام وتجربة المستخدم

من الميزات الجديدة الغريبة ولكنها مفيدة لبعض التوزيعات إدخال الحقل FANCY_NAME= في الأرشيف /etc/os-releaseيشبه هذا الحقل PRETTY_NAME، ولكنه يسمح تسلسلات ANSI وأحرف Unicode الأكثر تفصيلاًوبفضل ذلك، يمكن تقديم التوزيعات والإصدارات المحددة بأسماء أكثر جاذبية أو تميزاً.

يمكن الاطلاع على قيمة FANCY_NAME من خلال مدير systemd، باستخدام systemd-hostnamed أو عن طريق الاستعلام باستخدام hostnamectl . على الرغم من أنه تغيير بسيط، إلا أنه في بيئات سطح المكتب ولوحات الإدارة الرسومية، قد يكون مفيدًا لتحديد النظام المُدار بسرعة، خاصةً عند التعامل مع العديد من الإصدارات المشتقة.

وثائق خاصة بوكلاء الذكاء الاصطناعي وسير عمل المراجعة بمساعدة الحاسوب

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

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

يوجد بجانب ملف AGENTS.md ملف آخر يُسمى CLAUDE.md ، يشير صراحةً إلى الملف السابق، وهو مصمم لتوجيه أداة Claude Code، إحدى أكثر أدوات المساعدة في التطوير القائمة على الذكاء الاصطناعي استخدامًا. وبهذه الطريقة، يدمج المشروع الذكاء الاصطناعي بشكلٍ صريح في دورة تطويره.

بالإضافة إلى ذلك، يتضمن الملف ملف تهيئة. claude-review.ymlحيث يتم تحديد كيفية مراجعة عملية تحليل طلبات التغيير (طلبات السحب) بمساعدة كود كلود. في هذا السياق، يُطلب من المساهمات التي استخدمت الذكاء الاصطناعي دمج ملصقات الإفصاح كما Co-developed-by في الرقع، مما يترك دليلاً على أن أداة آلية قد شاركت في إنشاء الكود.

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