إن إنشاء تطبيق نسخ احتياطي يعمل على أي توزيعة ليس بالمهمة السهلة. للتأكد من أن Veeam Agent لنظام التشغيل Linux يعمل على التوزيعات من Red Hat 6 وDebian 6 إلى OpenSUSE 15.1 وUbuntu 19.04، يتعين عليك حل مجموعة من المشكلات، لا سيما بالنظر إلى أن منتج البرنامج يتضمن وحدة kernel.
تم إنشاء المقال بناءً على مواد من خطاب ألقاه في المؤتمر .
Linux ليس مجرد أحد أنظمة التشغيل الأكثر شعبية. في الأساس، هذه منصة يمكنك على أساسها إنشاء شيء فريد، شيء خاص بك. بفضل هذا، لدى Linux العديد من التوزيعات التي تختلف في مجموعة مكونات البرامج الخاصة بها. وهنا تبرز مشكلة: لكي يعمل منتج برمجي على أي توزيعة، عليك أن تأخذ في الاعتبار ميزات كل توزيعة.
مدراء الحزم. .deb مقابل .rpm
لنبدأ بالمشكلة الواضحة المتمثلة في توزيع المنتج عبر توزيعات مختلفة.
الطريقة الأكثر شيوعًا لتوزيع منتجات البرامج هي وضع الحزمة في مستودع بحيث يتمكن مدير الحزم المدمج في النظام من تثبيتها من هناك.
ومع ذلك، لدينا تنسيقان شائعان للحزم: دورة في الدقيقة и ديب. وهذا يعني أنه سيتعين على الجميع تقديم الدعم.
في عالم حزم deb، مستوى التوافق مذهل. يتم تثبيت نفس الحزمة وتعمل بشكل جيد على حد سواء على كل من Debian 6 وUbuntu 19.04. تظل معايير عملية بناء الحزم والعمل معها، المنصوص عليها في توزيعات دبيان القديمة، ذات صلة في نظام التشغيل Linux Mint الجديد ونظام التشغيل الأولي. لذلك، في حالة Veeam Agent لنظام التشغيل Linux، تكفي حزمة deb واحدة لكل نظام أساسي للأجهزة.
لكن في عالم حزم rpm، تكون الاختلافات كبيرة. أولاً، نظرًا لوجود موزعين مستقلين تمامًا، وهما Red Hat وSUSE، فإن التوافق بينهما ليس ضروريًا على الإطلاق. ثانياً، يمتلك هؤلاء الموزعون مجموعات توزيع من هؤلاء. الدعم والتجريبية. ليست هناك حاجة للتوافق بينهما أيضًا. اتضح أن el6 وel7 وel8 لديهم باقات خاصة بهم. حزمة منفصلة لفيدورا. حزم SLES11 و12 وحزم منفصلة لـ openSUSE. المشكلة الرئيسية هي التبعيات وأسماء الحزم.
مشكلة التبعية
لسوء الحظ، غالبًا ما تنتهي نفس الحزم تحت أسماء مختلفة في توزيعات مختلفة. فيما يلي قائمة جزئية لتبعيات حزمة veeam.
ل EL7:
بالنسبة لـ SLES 12:
- ليبلكيد
- libgcc
- libstdc ++
- ncurses-libs
- fuse-libs
- ملف libs
- veeamsnap=3.0.2.1185
- libblkid1
- libgcc_s1
- libstdc + + 6
- libmagic1
- libfuse2
- veeamsnap-kmp=3.0.2.1185
ونتيجة لذلك، فإن قائمة التبعيات تكون فريدة للتوزيع.
ما يزداد سوءًا هو عندما يبدأ الإصدار المحدث بالاختباء تحت اسم الحزمة القديمة.
على سبيل المثال:
تم تحديث الحزمة في فيدورا 24 سأركع من الإصدار 5 إلى الإصدار 6. تم تصميم منتجنا باستخدام الإصدار 5 لضمان التوافق مع التوزيعات الأقدم. لاستخدام الإصدار الخامس القديم من المكتبة على Fedora 5، كان علي استخدام الحزمة ncurses-compat-libs.
ونتيجة لذلك، هناك حزمتان لفيدورا، مع تبعيات مختلفة.
علاوة على ذلك أكثر إثارة للاهتمام. بعد تحديث التوزيع التالي، سيتم تحديث الحزمة ncurses-compat-libs مع الإصدار 5 من المكتبة اتضح أنه غير متوفر. يعد قيام الموزع بسحب المكتبات القديمة إلى إصدار جديد من التوزيع أمرًا مكلفًا. وبعد مرور بعض الوقت، تكررت المشكلة في توزيعات SUSE.
ونتيجة لذلك، اضطرت بعض التوزيعات إلى التخلي عن اعتمادها الصريح على ncurses-libsوإصلاح المنتج حتى يتمكن من العمل مع أي إصدار من المكتبة.
بالمناسبة، في الإصدار 8 من Red Hat لم تعد هناك حزمة تعريفية الثعبان، والذي أشار إلى القديم الجيد بيثون 2.7. هناك python2 и الثعبان3.
بديل لمديري الحزم
مشكلة التبعيات قديمة وكانت واضحة منذ فترة طويلة. فقط تذكر جحيم التبعية.
إن الجمع بين المكتبات والتطبيقات المختلفة بحيث تعمل جميعها بثبات ولا تتعارض - في الواقع، هذه هي المهمة التي يحاول أي موزع Linux حلها.
يحاول مدير الحزم حل هذه المشكلة بطريقة مختلفة تمامًا. لاذع من كانونيكال. الفكرة الرئيسية: يعمل التطبيق في بيئة معزولة ومحمية من النظام الرئيسي. إذا كان التطبيق يتطلب مكتبات، فسيتم توفيرها مع التطبيق نفسه.
Flatpak يسمح لك أيضًا بتشغيل التطبيقات في وضع الحماية باستخدام حاويات Linux. يتم أيضًا استخدام فكرة وضع الحماية AppImage.
تتيح لك هذه الحلول إنشاء حزمة واحدة لأي توزيع. في حالة Flatpak يمكن تثبيت التطبيق وتشغيله حتى بدون علم المسؤول.
المشكلة الرئيسية هي أنه لا يمكن تشغيل جميع التطبيقات في وضع الحماية. يحتاج بعض الأشخاص إلى الوصول المباشر إلى المنصة. أنا لا أتحدث حتى عن وحدات kernel، التي تعتمد بشكل صارم على kernel ولا تتناسب مع مفهوم Sandbox.
المشكلة الثانية هي أن التوزيعات الشائعة في بيئة المؤسسات من Red Hat وSUSE لا تحتوي حتى الآن على دعم لـ Snappy وFlatpak.
في هذا الصدد، وكيل Veeam لنظام التشغيل Linux غير متوفر مُطْلَقاً .
في ختام السؤال حول مديري الحزم، أود أن أشير إلى أن هناك خيارًا للتخلي عن مديري الحزم تمامًا من خلال الجمع بين الملفات الثنائية والبرنامج النصي لتثبيتها في حزمة واحدة.
تسمح لك هذه الحزمة بإنشاء حزمة مشتركة واحدة لتوزيعات ومنصات مختلفة، وإجراء عملية تثبيت تفاعلية، وإجراء التخصيص اللازم. لقد واجهت مثل هذه الحزم لنظام التشغيل 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, ليبلكيد من الضروري الارتباط ديناميكيًا لضمان توافقها مع النواة ووحداتها.
ثانيا، هناك دقة مع التراخيص.
يسمح لك ترخيص GPL بشكل أساسي بربط المكتبات باستخدام كود مفتوح المصدر فقط. يسمح معهد ماساتشوستس للتكنولوجيا (MIT) و BSD بالربط الثابت ويسمحان بإدراج المكتبات في المشروع. ولكن لا يبدو أن LGPL يتعارض مع الارتباط الثابت، ولكنه يتطلب مشاركة الملفات الضرورية للربط.
وبشكل عام، فإن استخدام الارتباط الديناميكي سيمنعك من الاضطرار إلى تقديم أي شيء.
بناء تطبيقات C/C++
لبناء تطبيقات C/C++ لمنصات وتوزيعات مختلفة، يكفي تحديد أو إنشاء إصدار مناسب من gcc واستخدام المترجمات المتقاطعة لبنيات محددة وتجميع مجموعة المكتبات بأكملها. هذا العمل ممكن تماما، ولكنه مزعج للغاية. وليس هناك ما يضمن أن المترجم والمكتبات المحددة ستوفر نسخة عملية.
ميزة واضحة: البنية التحتية مبسطة إلى حد كبير، حيث يمكن إكمال عملية البناء بأكملها على جهاز واحد. بالإضافة إلى ذلك، يكفي جمع مجموعة واحدة من الثنائيات لبنية واحدة ويمكنك تجميعها في حزم لتوزيعات مختلفة. هذه هي الطريقة التي يتم بها إنشاء حزم veeam لـ Veeam Agent لنظام التشغيل Linux.
على عكس هذا الخيار، يمكنك ببساطة إعداد مزرعة بناء، أي عدة آلات للتجميع. ستوفر كل آلة تجميع التطبيقات وتجميع الحزم لتوزيع محدد وبنية محددة. وفي هذه الحالة يتم التجميع باستخدام الوسائل التي أعدها الموزع. أي أنه تم التخلص من مرحلة إعداد المترجم واختيار المكتبات. بالإضافة إلى ذلك، يمكن أن تكون عملية البناء متوازية بسهولة.
ومع ذلك، هناك جانب سلبي لهذا النهج: لكل توزيع داخل نفس البنية، سيتعين عليك جمع مجموعتك الخاصة من الملفات الثنائية. عيب آخر هو أن هذا العدد الكبير من الأجهزة يحتاج إلى صيانة ويجب تخصيص قدر كبير من مساحة القرص وذاكرة الوصول العشوائي.
هذه هي الطريقة التي يتم بها تجميع حزم KMOD الخاصة بوحدة veeamsnap kernel لتوزيعات Red Hat.
فتح خدمة البناء
حاول زملاء SUSE تنفيذ حل وسط في شكل خدمة خاصة لتجميع التطبيقات وتجميع الحزم - .
في الأساس، هو برنامج Hypervisor الذي يقوم بإنشاء جهاز افتراضي، وتثبيت جميع الحزم الضرورية فيه، وتجميع التطبيق وبناء الحزمة في هذه البيئة المعزولة، وبعد ذلك يتم إصدار الجهاز الظاهري.
سيحدد برنامج الجدولة المطبق في OpenBuildService عدد الأجهزة الافتراضية التي يمكنه تشغيلها للحصول على سرعة بناء الحزمة المثلى. ستقوم آلية التوقيع المضمنة بتوقيع الحزم وتحميلها إلى المستودع المدمج. سيحفظ نظام التحكم في الإصدار المدمج تاريخ التغييرات والبنيات. كل ما تبقى هو ببساطة إضافة مصادرك إلى هذا النظام. ولا يتعين عليك حتى إعداد الخادم بنفسك؛ يمكنك استخدام خادم مفتوح.
ومع ذلك، هناك مشكلة: من الصعب أن تتناسب هذه الحاصدة مع البنية التحتية الحالية. على سبيل المثال، ليست هناك حاجة للتحكم في الإصدار، فلدينا بالفعل التحكم الخاص بنا فيما يتعلق بأكواد المصدر. آلية التوقيع لدينا مختلفة: فنحن نستخدم خادمًا خاصًا. ليست هناك حاجة أيضا إلى المستودع.
بالإضافة إلى ذلك، يتم تنفيذ دعم التوزيعات الأخرى - على سبيل المثال، Red Hat - بشكل سيء إلى حد ما، وهو أمر مفهوم.
تتمثل ميزة هذه الخدمة في الدعم السريع للإصدار التالي من توزيع SUSE. قبل الإعلان الرسمي عن الإصدار، يتم نشر الحزم اللازمة للتجميع في مستودع عام. تظهر واحدة جديدة في قائمة التوزيعات المتاحة على OpenBuildService. نحدد المربع ويتم إضافته إلى خطة البناء. وبالتالي، فإن إضافة نسخة جديدة من التوزيع تتم بنقرة واحدة تقريبًا.
في بنيتنا التحتية، باستخدام OpenBuildService، يتم تجميع مجموعة كاملة من حزم KMP الخاصة بوحدة veeamsnap kernel لتوزيعات SUSE.
بعد ذلك، أود أن أتطرق إلى المشكلات الخاصة بوحدات kernel.
نواة أبي
تم توزيع وحدات نواة Linux تاريخيًا في شكل مصدر. الحقيقة هي أن منشئي النواة لا يثقلون أنفسهم باهتمام دعم واجهة برمجة تطبيقات مستقرة لوحدات النواة، وخاصة على المستوى الثنائي، والذي يشار إليه أيضًا باسم kABI.
لبناء وحدة نمطية لنواة الفانيليا، تحتاج بالتأكيد إلى رؤوس هذه النواة المحددة، وستعمل فقط على هذه النواة.
يتيح لك DKMS أتمتة عملية بناء الوحدات عند تحديث النواة. ونتيجة لذلك، يستخدم مستخدمو مستودع دبيان (والعديد من أقاربه) وحدات kernel إما من مستودع الموزع أو مجمعة من المصدر باستخدام DKMS.
ومع ذلك، فإن هذا الوضع لا يناسب قطاع المؤسسات بشكل خاص. يرغب موزعو الأكواد الخاصة في توزيع المنتج على شكل ثنائيات مجمعة.
لا يرغب المسؤولون في الاحتفاظ بأدوات التطوير على خوادم الإنتاج لأسباب أمنية. قرر موزعو Enterprise Linux مثل Red Hat وSUSE أنه يمكنهم دعم kABI المستقر لمستخدميهم. وكانت النتيجة حزم KMOD لحزم Red Hat وKMP لـ SUSE.
جوهر هذا الحل بسيط للغاية. بالنسبة لإصدار محدد من التوزيع، يتم تجميد واجهة برمجة تطبيقات kernel. يذكر الموزع أنه يستخدم النواة، على سبيل المثال، 3.10، ويقوم فقط بإجراء التصحيحات والتحسينات التي لا تؤثر على واجهات النواة، ويمكن استخدام الوحدات المجمعة للنواة الأولى لجميع الوحدات اللاحقة دون إعادة الترجمة.
تدعي Red Hat توافق kABI للتوزيع طوال دورة حياته بالكامل. أي أن الوحدة المجمعة لـ rhel 6.0 (إصدار نوفمبر 2010) يجب أن تعمل أيضًا على الإصدار 6.10 (إصدار يونيو 2018). وهذا ما يقرب من 8 سنوات. وبطبيعة الحال، هذه المهمة صعبة للغاية.
لقد سجلنا العديد من الحالات التي توقفت فيها وحدة veeamsnap عن العمل بسبب مشكلات التوافق مع kABI.
بعد أن تبين أن وحدة veeamsnap، التي تم تجميعها لـ RHEL 7.0، غير متوافقة مع النواة من RHEL 7.5، ولكن تم تحميلها وكان مضمونًا تعطل الخادم، فقد تخلينا عن استخدام توافق kABI لـ RHEL 7 تمامًا.
حاليًا، تحتوي حزمة KMOD الخاصة بـ RHEL 7 على تجميع لكل إصدار إصدار وبرنامج نصي يقوم بتحميل الوحدة.
تعاملت SUSE مع مهمة توافق kABI بعناية أكبر. أنها توفر توافق kABI فقط ضمن حزمة خدمة واحدة.
على سبيل المثال، تم إصدار SLES 12 في سبتمبر 2014. وكان SLES 12 SP1 بالفعل في ديسمبر 2015، أي أنه قد مر أكثر من عام بقليل. على الرغم من أن كلا الإصدارين يستخدمان نواة 3.12، إلا أنهما غير متوافقين مع kABI. من الواضح أن الحفاظ على توافق kABI لمدة عام واحد فقط هو أسهل بكثير. يجب ألا تسبب دورة تحديث وحدة kernel السنوية مشاكل لمنشئي الوحدات.
نتيجة لسياسة SUSE هذه، لم نسجل أي مشكلة تتعلق بتوافق kABI في وحدة veeamsnap الخاصة بنا. صحيح أن عدد الحزم الخاصة بـ SUSE يكاد يكون أكبر من حيث الحجم.
بقع وbackports
على الرغم من أن الموزعين يحاولون ضمان توافق kABI واستقرار النواة، إلا أنهم يحاولون أيضًا تحسين الأداء وإزالة عيوب هذه النواة المستقرة.
في الوقت نفسه، بالإضافة إلى "العمل على الأخطاء" الخاصة بهم، يقوم مطورو Linux kernel الخاص بالمؤسسة بمراقبة التغييرات في نواة الفانيليا ونقلها إلى نواةهم "المستقرة".
في بعض الأحيان يؤدي هذا إلى أخرى جديدة .
في الإصدار الأخير من Red Hat 6، حدث خطأ في أحد التحديثات البسيطة. وقد أدى ذلك إلى حقيقة أن وحدة veeamsnap كانت مضمونة لتعطل النظام عند إصدار اللقطة. بعد مقارنة مصادر النواة قبل التحديث وبعده، اكتشفنا أن اللوم يقع على المنفذ الخلفي. تم إجراء إصلاح مماثل في إصدار Vanilla kernel 4.19. كل ما في الأمر أن هذا الإصلاح كان يعمل بشكل جيد في نواة الفانيليا، ولكن عند نقله إلى الإصدار 2.6.32 "المستقر"، ظهرت مشكلة في قفل الدوران.
بالطبع الجميع لديه أخطاء دائمًا، لكن هل كان الأمر يستحق سحب الكود من 4.19 إلى 2.6.32 والمخاطرة بالاستقرار؟.. لست متأكدًا...
أسوأ شيء هو عندما يتورط التسويق في لعبة شد الحبل بين "الاستقرار" و"التحديث". يحتاج قسم التسويق إلى أن يكون جوهر التوزيع المحدث مستقرًا من ناحية، وفي نفس الوقت يكون أفضل في الأداء ويحتوي على ميزات جديدة. وهذا يؤدي إلى تنازلات غريبة.
عندما حاولت إنشاء وحدة نمطية على kernel 4.4 من SLES 12 SP3، تفاجأت بالعثور على وظائف من Vanilla 4.8 فيها. في رأيي، فإن تنفيذ كتلة الإدخال/الإخراج للنواة 4.4 من SLES 12 SP3 يشبه النواة 4.8 أكثر من الإصدار السابق للنواة 4.4 المستقرة من SLES12 SP2. لا يمكنني الحكم على النسبة المئوية للتعليمات البرمجية التي تم نقلها من kernel 4.8 إلى SLES 4.4 لـ SP3، لكن لا يمكنني حتى أن أطلق على kernel نفس الإصدار المستقر 4.4.
الأمر الأكثر إزعاجًا في هذا هو أنه عند كتابة وحدة تعمل بشكل جيد على أنوية مختلفة، لم يعد بإمكانك الاعتماد على إصدار النواة. عليك أيضًا أن تأخذ في الاعتبار التوزيع. من الجيد أنه في بعض الأحيان يمكنك المشاركة في التعريف الذي يظهر مع وظائف جديدة، ولكن هذه الفرصة لا تظهر دائمًا.
ونتيجة لذلك، تصبح التعليمات البرمجية متضخمة مع توجيهات الترجمة الشرطية الغريبة.
هناك أيضًا تصحيحات تعمل على تغيير واجهة برمجة تطبيقات kernel الموثقة.
جئت عبر التوزيع 5.16 وتفاجأت جدًا عندما رأيت أن استدعاء lookup_bdev في إصدار kernel هذا غيّر قائمة معلمات الإدخال.
لتجميعها معًا، كان علي إضافة برنامج نصي إلى ملف التعريف الذي يتحقق مما إذا كانت وظيفة lookup_bdev تحتوي على معلمة قناع.
توقيع وحدات النواة
لكن دعنا نعود إلى مسألة توزيع الحزم.
إحدى مزايا kABI المستقرة هي أنه يمكن توقيع وحدات kernel كملف ثنائي. في هذه الحالة، يمكن للمطور التأكد من أن الوحدة لم تتضرر عن طريق الخطأ أو تم تعديلها عمدا. يمكنك التحقق من ذلك باستخدام الأمر modinfo.
تسمح لك توزيعات Red Hat وSUSE بالتحقق من توقيع الوحدة النمطية وتحميلها فقط إذا كانت الشهادة المقابلة مسجلة على النظام. الشهادة هي المفتاح العام الذي تم توقيع الوحدة به. نقوم بتوزيعها كحزمة منفصلة.
تكمن المشكلة هنا في أنه يمكن إنشاء الشهادات في النواة (يستخدمها الموزعون) أو يجب كتابتها على ذاكرة EFI غير المتطايرة باستخدام أداة مساعدة موكوتيل. جدوى موكوتيل عند تثبيت شهادة، يتطلب منك إعادة تشغيل النظام، وحتى قبل تحميل نواة نظام التشغيل، يطالب المسؤول بالسماح بتحميل شهادة جديدة.
ومن ثم، فإن إضافة شهادة تتطلب وصول المسؤول الفعلي إلى النظام. إذا كان الجهاز موجودًا في مكان ما في السحابة أو ببساطة في غرفة خادم بعيدة ويتم الوصول إليه فقط عبر الشبكة (على سبيل المثال، عبر 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 أو Unstable من Debian. إنها مستقرة تمامًا. لديهم دائمًا إصدارات جديدة من البرامج ونواة جديدة دائمًا. في غضون عام، قد تنتهي هذه الوظيفة التجريبية في RHEL أو SLES أو Ubuntu المحدثة.
لذلك إذا لم يعمل شيء ما على التوزيع التجريبي، فهذا سبب لمعرفة المشكلة وحلها. يجب أن تكون مستعدًا لحقيقة أن هذه الوظيفة ستظهر قريبًا على خوادم الإنتاج الخاصة بالمستخدمين.
يمكنك دراسة القائمة الحالية للتوزيعات المدعومة رسميًا للإصدار 3.0 . لكن القائمة الحقيقية للتوزيعات التي يمكن لمنتجنا أن يعمل عليها هي أوسع بكثير.
أنا شخصياً كنت مهتماً بتجربة نظام التشغيل Elbrus OS. بعد الانتهاء من حزمة veeam، تم تركيب منتجنا وتشغيله. لقد كتبت عن هذه التجربة على حبري في .
حسنًا، يستمر دعم التوزيعات الجديدة. نحن في انتظار إصدار الإصدار 4.0. النسخة التجريبية على وشك الظهور، لذا ترقبوا ذلك !
المصدر: www.habr.com