لدى Linux العديد من الوجوه: كيفية العمل على أي توزيع

إنشاء تطبيق نسخ احتياطي يعمل على أي توزيع ليس بالمهمة السهلة. للتأكد من أن Veeam Agent for Linux يعمل على توزيعات من RHEL 6 و Debian 6 ، حتى فتح SUSE Leap 15.1 و Ubuntu 19.04 ، يجب عليك حل مجموعة من المشكلات ، خاصةً عندما تفكر في أن kernel module جزء من منتج البرنامج.

تستند هذه المقالة إلى عرض تقديمي في مؤتمر LinuxPiter 2019 .

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

مديري الحزمة. .deb مقابل .rpm

لنبدأ بالمشكلة الواضحة المتمثلة في توزيع المنتج لتوزيعات مختلفة.
تتمثل الطريقة الأكثر شيوعًا لتوزيع منتجات البرامج في وضع الحزمة على المستودع حتى يتمكن مدير الحزمة المدمج في النظام من تثبيتها من هناك.
ومع ذلك ، لدينا تنسيقان للحزم الشائعة: rpm و deb . لذلك ، سيكون الجميع لدعم.

في عالم حزم deb ، مستوى التوافق مذهل. يتم تثبيت نفس الحزمة بنفس القدر وتعمل على كل من Debian 6 و Ubuntu 19.04. تظل معايير عملية بناء الحزم والعمل معها ، والموضحة في توزيعات دبيان القديمة ، ذات صلة بنظام Linux Mint الجديد ونظام التشغيل الأولي. لذلك ، في حالة Veeam Agent for Linux ، تكفي حزمة deb لكل نظام أساسي للأجهزة.

لكن في عالم حزم rpm ، تكون الاختلافات كبيرة. أولاً ، نظرًا لوجود اثنين من الموزعين المستقلين تمامًا لـ Red Hat و SUSE ، ولا حاجة إلى التوافق على الإطلاق. ثانياً ، هؤلاء الموزعون لديهم توزيعات من هؤلاء. الدعم والتجريبية. بينهما ، والتوافق هو أيضا ليست هناك حاجة. اتضح أنه بالنسبة لحزم el6 و el7 و el8 الخاصة بهم. حزمة منفصلة لفيدورا. حزم SLES11 و 12 ومنفصلة لـ openSUSE. المشكلة الرئيسية هي التبعيات وأسماء الحزمة.

مشكلة التبعية

للأسف ، غالبًا ما تنتهي الحزم نفسها بأسماء مختلفة في توزيعات مختلفة. أدناه قائمة جزئية تبعيات حزمة veeam.

نتيجة لذلك ، تعد قائمة التبعيات فريدة للتوزيع.

يزداد الأمر سوءًا عندما يبدأ إصدار محدث في الإخفاء تحت اسم الحزمة القديمة.

مثال:

قام Fedora 24 بتحديث حزمة ncurses من الإصدار 5 إلى الإصدار 6. تم تصميم منتجنا بالإصدار 5 لضمان التوافق مع التوزيعات القديمة. لاستخدام الإصدار الخامس القديم من المكتبة على Fedora 24 ، كان علي استخدام حزمة ncurses-compat-libs .

نتيجة لذلك ، تظهر حزمةان في Fedora ، مع تبعيات مختلفة.

أكثر إثارة للاهتمام. بعد التحديث التالي لحزمة التوزيع ، لا تتوفر حزمة ncurses-compat-libs مع الإصدار الخامس من المكتبة. ليس من المربح أن يقوم الموزع بسحب المكتبات القديمة إلى نسخة توزيع جديدة. بعد مرور بعض الوقت ، تكررت المشكلة في توزيعات SUSE.

كنتيجة لذلك ، بالنسبة لبعض التوزيعات ، اضطررت إلى التخلي عن الاعتماد الصريح على ncurses-libs ، وإصلاح المنتج حتى يتمكن من العمل مع أي إصدار من المكتبة.

بالمناسبة ، في الإصدار الثامن من ريد هات لم يعد هناك حزمة بيثون الوصفية التي أشارت إلى الثعبان القديم الجيد 2.7 . هناك python2 و python 3.

بديل لمديري الحزم

مشكلة التبعيات قديمة وطويلة الوضوح. فقط تذكر جهنم التبعية.
قم بدمج مجموعة متنوعة من المكتبات والتطبيقات بحيث تعمل جميعها بثبات وعدم تعارضها - في الواقع ، يحاول أي موزع Linux حل هذه المشكلة.

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

يتيح لك Flatpak أيضًا تشغيل التطبيقات في صندوق الحماية باستخدام حاويات Linux. هناك أيضًا AppImage ، والذي يسمح لك بإنشاء صور محمولة للبرامج.

تتيح لك هذه الحلول إنشاء حزمة واحدة لأي توزيعات. في حالة Flatpak و AppImage ، يمكن تثبيت التطبيق وتشغيله حتى بدون علم المسؤول.

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

المشكلة الثانية هي أن التوزيعات الشائعة من Red Hat و SUSE في بيئة المؤسسة لا تدعم Snappy و Flatpak حتى الآن.

في هذا الصدد ، فإن Veeam Agent for Linux ليس على snapcraft.io ولا على flathub.org .

في نهاية السؤال حول مديري الحزم ، لاحظت أن هناك خيارًا للتخلي عن مديري الحزم تمامًا من خلال الجمع بين الملفات الثنائية والبرنامج النصي لتثبيتها في حزمة واحدة.

تتيح لك هذه الحزمة إنشاء حزمة مشتركة واحدة لتوزيعات ومنصات مختلفة ، لتنفيذ عملية تثبيت تفاعلية ، وتنفيذ التخصيص اللازم. صادفت مثل هذه الحزم لنظام Linux فقط من VMware.

تحديث القضية

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

هناك 3 استراتيجيات الترقية:

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

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

مجموعة متنوعة من منصات الأجهزة

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

في مشروع Veeam Agent for Linux ، ما زلنا لا نستطيع دعم شيء على الأقل RISC.

لن أتناول هذه القضية بالتفصيل. سأوضح المشكلات الرئيسية فقط: الأنواع المعتمدة على النظام الأساسي مثل size_t ، ومحاذاة الهياكل ، وترتيب البايت.

ربط ثابت و / أو ديناميكي

وهنا هو السؤال "كيفية الارتباط بالمكتبات - ديناميكيًا أو ثابتًا؟" يستحق المناقشة.

عادةً ، تستخدم تطبيقات C / C ++ Linux ارتباطًا ديناميكيًا. هذا يعمل بشكل رائع إذا تم تصميم التطبيق خصيصًا لتوزيع معين.

إذا كانت المهمة هي تغطية مجموعة متنوعة من التوزيعات بملف ثنائي واحد ، فعليك التركيز على أقدم توزيع مدعوم. بالنسبة لنا ، هذا هو Red Hat 6. إنه يحتوي على gcc 4.4 ، والتي حتى C ++ 11 لا تدعمها بشكل كامل .

نحن نبني مشروعنا باستخدام gcc 6.3 ، والذي يدعم بشكل كامل C ++ 14. بطبيعة الحال ، في هذه الحالة على Red Hat 6 ، يجب سحب libstdc ++ ومكتبة التعزيز. أسهل طريقة لربطها بشكل ثابت.

ولكن للأسف ، لا يمكن ربط جميع المكتبات بشكل ثابت.

أولاً ، يجب ربط مكتبات النظام ، مثل libfuse و libblkid ، ديناميكيًا للتأكد من أنها متوافقة مع النواة والوحدات النمطية الخاصة بها.

ثانيا ، هناك دقة في التراخيص.

يسمح ترخيص GPL بشكل أساسي بربط المكتبات فقط بكود مفتوح المصدر. يعمل كل من MIT و BSD على تمكين الربط الثابت ويسمحان بإدراج المكتبات في المشروع. لكن LGPL لا يبدو أنه يتعارض مع الارتباط الثابت ، ولكنه يتطلب مشاركة الملفات الضرورية للربط.

بشكل عام ، سوف يحمي استخدام الارتباط الديناميكي من الحاجة إلى توفير شيء ما.

بناء تطبيقات C / C ++

لإنشاء تطبيقات C / C ++ للأنظمة الأساسية والتوزيعات المختلفة ، يكفي تحديد أو تجميع إصدار مناسب من gcc واستخدام برامج تجميعية لبنيات محددة ، لجمع مجموعة كاملة من المكتبات. هذا العمل ممكن جدا ، لكنه مزعج نوعا ما. ولا توجد ضمانات بأن المترجم والمكتبات المحددة ستوفر خيارًا عمليًا.

ميزة إضافية واضحة: البنية التحتية مبسطة إلى حد كبير ، حيث يمكن تنفيذ عملية التجميع بأكملها على جهاز واحد. بالإضافة إلى ذلك ، يكفي جمع مجموعة واحدة من الملفات الثنائية لبنية واحدة ويمكنك حزمها في حزم لتوزيعات مختلفة. هذه هي الطريقة التي يتم بها بناء حزم veeam لـ Veeam Agent for Linux.

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

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

بهذه الطريقة ، يتم تجميع حزم KMOD لوحدة veeamsnap kernel لتوزيعات Red Hat.

خدمة بناء مفتوحة

حاول زملاء SUSE تطبيق بعض الطرق الوسطى كخدمة خاصة لتجميع التطبيقات وبناء الحزم - openbuildservice .

في الواقع ، هو برنامج hypervisor يقوم بإنشاء جهاز ظاهري ، ويقوم بتثبيت جميع الحزم اللازمة فيه ، ويجمع التطبيق ويجمع الحزمة في هذه البيئة المعزولة ، وبعد ذلك يتم تحرير هذا الجهاز الظاهري.



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

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

بالإضافة إلى ذلك ، يتم تنفيذ دعم التوزيعات الأخرى - على سبيل المثال ، ريد هات - بشكل سيء إلى حد ما ، وهذا أمر مفهوم.

ميزة هذه الخدمة هي الدعم السريع للإصدار التالي من توزيع SUSE. قبل إعلان الإصدار الرسمي ، يتم تحميل الحزم المطلوبة للتجميع إلى المستودع العام. تظهر واحدة جديدة في قائمة التوزيعات المتاحة على OpenBuildService. نضع علامة ويضاف إلى خطة التجميع. وبالتالي ، تتم إضافة إصدار جديد من التوزيع بنقرة واحدة تقريبًا.

في بنيتنا الأساسية ، باستخدام OpenBuildService ، نقوم بتجميع مجموعة كاملة من حزم KMP لوحدة veeamsnap kernel لتوزيعات SUSE.

علاوة على ذلك ، أود أن أتطرق إلى القضايا الخاصة بوحدات kernel.

نواة أبي

تاريخيا تم توزيع وحدات kernel Linux في شكل مصدر. الحقيقة هي أن منشئي النواة لا يثقلون أنفسهم بالحفاظ على واجهة برمجة تطبيقات مستقرة لوحدات kernel ، وحتى أكثر من ذلك على المستوى الثنائي ، ثم kABI.

لإنشاء وحدة نمطية لنواة الفانيليا ، يلزم رؤوس هذه النواة المحددة ، وستعمل فقط على هذا النواة.

يسمح لك DKMS بأتمتة عملية تجميع الوحدات عند تحديث النواة. نتيجة لذلك ، يستخدم مستخدمو مستودع دبيان (والعديد من أقاربه) وحدات kernel إما من مستودع الموزع أو يتم تجميعها من المصدر باستخدام DKMS.

ومع ذلك ، هذا الموقف غير مريح بشكل خاص مع شريحة Enterprise. يرغب موزعو رموز الملكية في توزيع المنتج في شكل ثنائيات مترجمة.

لا يريد المسؤولون الاحتفاظ بأدوات التطوير على خوادم الإنتاج لأسباب أمنية. قرر موزعو Enterprise Linux - مثل Red Hat و SUSE - إمكانية الحفاظ على kABI الثابت لمستخدميهم. نتيجة لذلك ، ظهرت حزم KMOD لحزم Red Hat و KMP لـ SUSE.

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

تعلن Red Hat عن توافق kABI للتوزيع طوال دورة الحياة. وهذا يعني أن الوحدة المجمعة لـ rhel 6.0 (إصدار نوفمبر 2010) يجب أن تعمل أيضًا على الإصدار 6.10 (إصدار يونيو 2018). وهذا ما يقرب من 8 سنوات. بطبيعة الحال ، فإن المهمة معقدة إلى حد ما.
سجلنا العديد من الحالات عندما توقفت وحدة veeamsnap عن العمل بسبب مشاكل التوافق مع kABI.

بعد أن تبين أن وحدة veeamsnap التي تم تجميعها لـ RHEL 7.0 غير متوافقة مع kernel من RHEL 7.5 ، لكن تم تحميلها وضمان إلقاء الخادم ، رفضنا استخدام توافق kABI لـ RHEL 7 بشكل عام.

حاليًا ، تحتوي حزمة KMOD لـ RHEL 7 على تجميع لكل إصدار من إصدارات البرنامج النصي الذي يوفر تحميل الوحدة.

اقترب SUSE من مهمة توافق kABI بمزيد من الدقة. أنها توفر توافق kABI في حزمة خدمة واحدة فقط.

على سبيل المثال ، تم إصدار SLES 12 في سبتمبر 2014. و SLES 12 المزود بحزمة الخدمة SP1 موجود بالفعل في ديسمبر 2015 ، أي أنه قد مضى أكثر من عام بقليل. على الرغم من أن كلا الإصدارين يستخدم 3.12 kernel ، إلا أنهما غير متوافقين مع kABI. من الواضح أن الحفاظ على توافق kABI لمدة عام واحد أسهل بكثير. يجب ألا تتسبب دورة تحديث الوحدة الأساسية السنوية في حدوث مشكلات لمنشئي الوحدات النمطية.

كنتيجة لسياسة SUSE هذه ، لم نحل أي مشاكل في توافق kABI في وحدة veeamsnap الخاصة بنا. صحيح أن عدد الحزم لـ SUSE يكاد يكون ترتيبًا بحجم أكبر.

بقع و backports

على الرغم من حقيقة أن الموزعين يحاولون ضمان توافق kABI واستقرار kernel ، إلا أنهم يحاولون أيضًا تحسين الأداء والقضاء على العيوب في هذا النواة المستقرة.

علاوة على ذلك ، بالإضافة إلى "العمل على الأخطاء" الخاص بهم ، يتغير مطورو مسار linux kernel للمؤسسة في نواة الفانيليا وينقلونها إلى مستواهم "المستقر".

هذا يؤدي في بعض الأحيان إلى أخطاء جديدة.

أحدث إصدار من Red Hat 6 خطأً في أحد التحديثات الطفيفة. أدى ذلك إلى حقيقة أن وحدة veeamsnap كانت مضمونة لتعطل النظام عند إصدار اللقطة. بمقارنة مصادر kernel قبل التحديث وبعده ، اكتشفنا أن backport كان السبب. تم إجراء إصلاح مشابه في إصدار الفانيليا kernel 4.19. ولكن فقط في قلب الفانيليا ، كان هذا الإصلاح جيدًا ، وعند نقله إلى 2.6.32 "المستقر" ، كانت هناك مشكلة في قفل الدوران.

بالطبع ، كل شخص لديه دائمًا أخطاء ، لكن هل كان الأمر يستحق سحب الكود من 4.19 إلى 2.6.32 ، هل أنت مجازفة بالاستقرار؟ .. لست متأكدًا ...

والأسوأ من ذلك كله ، عندما يرتبط التسويق بسحب الحرب "الاستقرار" <-> "التحديث". يحتاج قسم التسويق إلى أن يكون جوهر التوزيع المحدث مستقراً ، من ناحية ، وفي الوقت نفسه يكون أفضل في الأداء وله ميزات جديدة. هذا يؤدي إلى حلول وسط غريبة.

عندما حاولت بناء وحدة نمطية على 4.4 نواة من SLES 12 SP3 ، فوجئت بالعثور على وظيفة من فانيليا 4.8 فيه. في رأيي ، فإن تطبيق الكتلة I / O من kernel 4.4 من SLES 12 SP3 يشبه 4.8 kernel مقارنة بالإصدار السابق من 4.4 kernel المستقر من SLES12 SP2. لا يمكنني الحكم على النسبة المئوية من الكود الذي تم نقله من 4.8 kernel إلى SLES 4.4 لـ SP3 ، لكن لا يزال لدي فرصة للاتصال بـ kernel بنفس مستقر 4.4.

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

نتيجة لذلك ، يحيط بالكود توجيهات رائعة للتجميع الشرطي.

هناك أيضًا تصحيحات تغير واجهة برمجة تطبيقات kernel الموثقة.
صادفت مجموعة توزيع KDE neon 5.16 وفوجئت جدًا برؤية مكالمة lookup_bdev في إصدار kernel هذا غيرت قائمة معلمات الإدخال.

للالتقاء ، اضطررنا إلى إضافة برنامج نصي في makefile يتحقق مما إذا كانت وظيفة lookup_bdev تحتوي على معلمة قناع.

توقيع وحدات النواة

ولكن العودة إلى مسألة توزيع الحزمة.

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

تتيح لك توزيعات Red Hat و SUSE التحقق من توقيع وحدة ما وتنزيلها فقط إذا كانت الشهادة المناسبة مسجلة في النظام. الشهادة هي المفتاح العمومي الذي يتم بواسطته توقيع الوحدة. نوزعه كحزمة منفصلة.

المشكلة هنا هي أن الشهادات يمكن دمجها في النواة (يتم استخدامها من قبل الموزعين) ، أو يجب كتابتها على ذاكرة EFI غير متقلبة باستخدام الأداة المساعدة mokutil . عند تثبيت الشهادة ، تتطلب الأداة المساعدة mokutil إعادة تشغيل النظام وحتى قبل تحميل نواة نظام التشغيل ، فإنها تتيح للمسؤول السماح بتنزيل الشهادة الجديدة.

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

EFI على الأجهزة الافتراضية

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

ليس كل برامج Hypervisor تدعم EFI. يدعم VMWare vSphere EFI منذ الإصدار 5.
تلقى Microsoft Hyper-V أيضًا دعم EFI ، بدءًا من Hyper-V لنظام التشغيل Windows Server 2012R2.

ومع ذلك ، في التكوين الافتراضي ، يتم تعطيل هذه الوظيفة لأجهزة Linux ، مما يعني أنه لا يمكن تثبيت الشهادة.

في الإصدار vSphere 6.5 ، يمكنك ضبط خيار التمهيد الآمن فقط في الإصدار القديم من واجهة الويب التي تعمل عبر Flash. واجهة الويب على HTML-5 متخلفة.

توزيعات تجريبية

وأخيراً ، فكر في مسألة التوزيعات والتوزيعات التجريبية دون دعم رسمي. من ناحية ، من غير المرجح أن توجد مثل هذه التوزيعات على خوادم المنظمات الجادة. لا يوجد دعم رسمي لمثل هذه التوزيعات. لذلك ، لتوفير تلك. دعم المنتج على مثل هذا التوزيع غير ممكن.

ومع ذلك ، فإن مثل هذه التوزيعات تصبح منصة مناسبة لاختبار الحلول التجريبية الجديدة. على سبيل المثال ، Fedora أو OpenSUSE Tumbleweed أو الإصدار غير المستقر من دبيان. أنها مستقرة جدا. لديهم دائما إصدارات جديدة من البرامج ودائما نواة جديدة. بعد عام ، قد تكون هذه الوظيفة التجريبية في RHEL أو SLES أو Ubuntu المحدثة.

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

يمكن العثور هنا على القائمة الحالية للتوزيعات المدعومة رسميًا للإصدار 3.0. لكن قائمة التوزيعات الحقيقية التي يستطيع منتجنا العمل عليها أوسع بكثير.

شخصياً ، كنت مهتمًا بتجربة مع Elbrus OS. بعد تحديث حزمة veeam ، تم تثبيت منتجنا والحصول عليه. عن هذه التجربة كتبت عن حبري في مقال .

حسنًا ، يستمر دعم التوزيعات الجديدة. نحن في انتظار الافراج عن الإصدار 4.0. الإصدار التجريبي على وشك الظهور ، لذا ترقبوا ما هو جديد !