لینوکس چهره های زیادی دارد: نحوه کار بر روی هر توزیع

ایجاد یک برنامه پشتیبان که روی هر توزیعی کار می کند کار آسانی نیست. برای اطمینان از اینکه Veeam Agent برای لینوکس روی توزیع‌هایی از Red Hat 6 و Debian 6 تا OpenSUSE 15.1 و Ubuntu 19.04 کار می‌کند، باید طیفی از مشکلات را حل کنید، به خصوص با توجه به اینکه محصول نرم‌افزاری شامل یک ماژول هسته است.

مقاله بر اساس مطالب سخنرانی در کنفرانس ایجاد شده است لینوکس پیتر 2019.

لینوکس تنها یکی از محبوب ترین سیستم عامل ها نیست. در اصل، این یک پلت فرم است که بر اساس آن می توانید چیزی منحصر به فرد، چیزی از خود بسازید. به لطف این، لینوکس توزیع‌های زیادی دارد که در مجموعه اجزای نرم‌افزاری متفاوت هستند. و در اینجا یک مشکل ایجاد می شود: برای اینکه یک محصول نرم افزاری در هر توزیعی کار کند، باید ویژگی های هر کدام را در نظر بگیرید.

مدیران بسته .deb در مقابل .rpm

بیایید با مشکل آشکار توزیع محصول در توزیع های مختلف شروع کنیم.
معمولی ترین راه برای توزیع محصولات نرم افزاری این است که بسته را در یک مخزن قرار دهید تا مدیر بسته ساخته شده در سیستم بتواند آن را از آنجا نصب کند.
با این حال، ما دو قالب بسته محبوب داریم: دور در دقیقه и بده. این بدان معناست که همه باید حمایت کنند.

در دنیای بسته های deb، سطح سازگاری شگفت انگیز است. همین بسته بر روی Debian 6 و Ubuntu 19.04 به طور یکسان نصب و کار می کند. استانداردهای فرآیند ساخت بسته‌ها و کار با آن‌ها، که در توزیع‌های قدیمی Debian وضع شده‌اند، همچنان در Linux Mint و سیستم‌عامل ابتدایی مرتبط هستند. بنابراین، در مورد Veeam Agent برای لینوکس، یک بسته deb برای هر پلتفرم سخت افزاری کافی است.

اما در دنیای پکیج های دور در دقیقه، تفاوت ها بسیار زیاد است. اولاً به دلیل وجود دو توزیع کننده کاملاً مستقل Red Hat و SUSE که سازگاری برای آنها کاملاً غیر ضروری است. ثانیاً، این توزیع‌کنندگان کیت‌های توزیع را از آن‌ها دارند. پشتیبانی و تجربی نیازی به سازگاری بین آنها نیز نیست. معلوم شد که el6، el7 و el8 بسته های خاص خود را دارند. بسته جداگانه برای فدورا. بسته هایی برای SLES11 و 12 و یک بسته جداگانه برای openSUSE. مشکل اصلی وابستگی ها و نام بسته ها است.

مشکل وابستگی

متأسفانه، بسته های یکسان اغلب با نام های مختلف در توزیع های مختلف به پایان می رسند. در زیر لیستی جزئی از وابستگی های بسته veeam آورده شده است.

برای EL7:
برای SLES 12:

• libblkid
• libgcc
• libstdc++
• ncurses-libs
• فیوز-libs
• فایل-libs
• veeamsnap=3.0.2.1185

• libblkid1
• libgcc_s1
• libstdc++6
• libmagic1
• libfuse2
• veeamsnap-kmp=3.0.2.1185

در نتیجه، لیست وابستگی ها برای توزیع منحصر به فرد است.

چیزی که بدتر می شود زمانی است که یک نسخه به روز شده شروع به پنهان شدن تحت نام بسته قدیمی می کند.

به عنوان مثال:

بسته در فدورا 24 به روز شده است نفرین از نسخه 5 تا نسخه 6. محصول ما با نسخه 5 ساخته شده است تا از سازگاری با توزیع های قدیمی اطمینان حاصل شود. برای استفاده از نسخه پنجم قدیمی کتابخانه در فدورا 5، مجبور شدم از بسته استفاده کنم ncurses-compat-libs.

در نتیجه، دو بسته برای فدورا با وابستگی های مختلف وجود دارد.

بیشتر جالب تر. پس از به روز رسانی توزیع بعدی، بسته ncurses-compat-libs با نسخه 5 کتابخانه به نظر می رسد که در دسترس نیست. کشیدن کتابخانه های قدیمی به نسخه جدیدی از توزیع برای یک توزیع کننده گران است. پس از مدتی، این مشکل در توزیع های SUSE تکرار شد.

در نتیجه، برخی از توزیع‌ها مجبور شدند وابستگی صریح خود را به آن کاهش دهند ncurses-libs، و محصول را تعمیر کنید تا بتواند با هر نسخه ای از کتابخانه کار کند.

ضمناً در نسخه 8 Red Hat دیگر پکیج متا وجود ندارد پایتون، که به قدیم خوب اشاره داشت پایتون 2.7. وجود دارد python2 и پایتون3.

جایگزینی برای مدیران بسته

مشکل وابستگی ها قدیمی است و مدت هاست که آشکار شده است. فقط جهنم Dependency را به یاد داشته باشید.
ترکیب کتابخانه ها و برنامه های مختلف به طوری که همه آنها به طور پایدار کار کنند و تضاد نداشته باشند - در واقع، این وظیفه ای است که هر توزیع کننده لینوکس سعی در حل آن دارد.

مدیر بسته سعی می کند این مشکل را به روشی کاملاً متفاوت حل کند. اسنیپت از کانونیکال ایده اصلی: برنامه در یک جعبه ماسه ای ایزوله و محافظت شده از سیستم اصلی اجرا می شود. اگر یک برنامه به کتابخانه نیاز داشته باشد، خود برنامه به آنها ارائه می شود.

تختپاک همچنین به شما اجازه می دهد تا با استفاده از ظروف لینوکس، برنامه ها را در جعبه شنی اجرا کنید. ایده sandbox نیز استفاده می شود AppImage.

این راه حل ها به شما امکان می دهد برای هر توزیع یک بسته ایجاد کنید. در صورت تختپاک نصب و راه اندازی برنامه حتی بدون اطلاع مدیر امکان پذیر است.

مشکل اصلی این است که همه برنامه ها نمی توانند در sandbox اجرا شوند. برخی از افراد نیاز به دسترسی مستقیم به پلتفرم دارند. من حتی در مورد ماژول‌های هسته صحبت نمی‌کنم، که به شدت به هسته وابسته هستند و در مفهوم sandbox نمی گنجند.

مشکل دوم این است که توزیع های محبوب در محیط سازمانی از Red Hat و SUSE هنوز از Snappy و Flatpak پشتیبانی نمی کنند.

در این رابطه، Veeam Agent برای لینوکس در دسترس نیست snapcraft.io نه در flathub.org.

برای پایان دادن به سوال در مورد مدیریت بسته ها، می خواهم توجه داشته باشم که گزینه ای وجود دارد که با ترکیب فایل های باینری و یک اسکریپت برای نصب آنها در یک بسته، به طور کلی مدیران بسته را کنار بگذاریم.

چنین بسته نرم افزاری به شما امکان می دهد یک بسته مشترک برای توزیع ها و پلتفرم های مختلف ایجاد کنید، یک فرآیند نصب تعاملی را انجام دهید و سفارشی سازی لازم را انجام دهید. من فقط با چنین بسته هایی برای لینوکس از VMware مواجه شده ام.

مشکل آپدیت

حتی اگر همه مسائل مربوط به وابستگی حل شود، برنامه ممکن است در یک توزیع متفاوت اجرا شود. موضوع به روز رسانی است.

3 استراتژی به روز رسانی وجود دارد:

• ساده ترین راه این است که هرگز به روز نکنید. من سرور را راه اندازی کردم و آن را فراموش کردم. چرا به روز رسانی اگر همه چیز کار می کند؟ مشکلات از اولین تماس با پشتیبانی شروع می شود. سازنده توزیع فقط از نسخه به روز شده پشتیبانی می کند.
• می‌توانید به توزیع‌کننده اعتماد کنید و به‌روزرسانی‌های خودکار را تنظیم کنید. در این مورد، احتمالاً بلافاصله پس از به‌روزرسانی ناموفق، تماس با پشتیبانی وجود دارد.
• گزینه به روز رسانی دستی تنها پس از اجرای آن بر روی یک زیرساخت آزمایشی قابل اعتمادترین، اما پرهزینه ترین و وقت گیر است. همه نمی توانند آن را بپردازند.

از آنجایی که کاربران مختلف از استراتژی‌های به‌روزرسانی متفاوتی استفاده می‌کنند، لازم است هم از آخرین نسخه و هم همه نسخه‌های منتشر شده قبلی پشتیبانی شود. این امر هم فرآیند توسعه و هم فرآیند آزمایش را پیچیده می کند و سردرد را به تیم پشتیبانی اضافه می کند.

انواع پلتفرم های سخت افزاری

پلتفرم های سخت افزاری مختلف مشکلی هستند که تا حد زیادی مختص کدهای بومی است. حداقل باید برای هر پلتفرم پشتیبانی شده فایل های باینری جمع آوری کنید.

در پروژه Veeam Agent برای لینوکس، ما هنوز نمی توانیم چیزی شبیه به این RISC را پشتیبانی کنیم.

من به جزئیات این موضوع نمی پردازم. من فقط مشکلات اصلی را بیان می کنم: انواع وابسته به پلت فرم، مانند size_t، تراز ساختار و ترتیب بایت.

پیوند استاتیک و/یا پویا

اما سوال این است که "چگونه با کتابخانه ها پیوند برقرار کنیم - به صورت پویا یا ایستا؟" ارزش بحث داره

به عنوان یک قاعده، برنامه های C/C++ تحت لینوکس از پیوند پویا استفاده می کنند. اگر برنامه به طور خاص برای یک توزیع خاص ساخته شده باشد، این عالی عمل می کند.

اگر وظیفه پوشش دادن توزیع های مختلف با یک فایل باینری است، باید روی قدیمی ترین توزیع پشتیبانی شده تمرکز کنید. برای ما، این 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 برای لینوکس ساخته می‌شوند.

در مقابل این گزینه، می توانید به سادگی یک مزرعه بیلد، یعنی چندین ماشین برای مونتاژ آماده کنید. هر یک از این ماشین ها کامپایل برنامه و مونتاژ بسته را برای یک توزیع خاص و یک معماری خاص فراهم می کند. در این مورد، گردآوری با استفاده از ابزار تهیه شده توسط توزیع کننده انجام می شود. یعنی مرحله تهیه کامپایلر و انتخاب کتابخانه ها حذف می شود. علاوه بر این، فرآیند ساخت را می توان به راحتی موازی کرد.

با این حال، یک نقطه ضعف در این رویکرد وجود دارد: برای هر توزیع در یک معماری، شما باید مجموعه ای از فایل های باینری خود را جمع آوری کنید. یکی دیگر از معایب این است که تعداد زیادی از ماشین ها نیاز به نگهداری دارند و مقدار زیادی فضای دیسک و رم باید اختصاص داده شود.

اینگونه است که بسته های KMOD ماژول هسته veeamsnap برای توزیع های Red Hat کامپایل می شوند.

سرویس ساخت را باز کنید

همکاران SUSE سعی کردند حد وسطی را در قالب یک سرویس ویژه برای کامپایل برنامه ها و مونتاژ بسته ها پیاده سازی کنند - openbuildservice.

در اصل، این یک Hypervisor است که یک ماشین مجازی ایجاد می کند، تمام بسته های لازم را در آن نصب می کند، برنامه را کامپایل می کند و بسته را در این محیط ایزوله می سازد و پس از آن ماشین مجازی آزاد می شود.

زمانبندی پیاده سازی شده در OpenBuildService تعیین می کند که چند ماشین مجازی می تواند برای سرعت ساخت بسته بهینه راه اندازی کند. مکانیزم امضای داخلی بسته ها را امضا کرده و آنها را در مخزن داخلی آپلود می کند. سیستم کنترل نسخه داخلی تاریخچه تغییرات و ساخت ها را ذخیره می کند. تنها چیزی که باقی می ماند این است که به سادگی منابع خود را به این سیستم اضافه کنید. شما حتی نیازی به راه اندازی سرور ندارید، می توانید از یک سرور باز استفاده کنید.

با این حال، یک مشکل وجود دارد: چنین دروگر به سختی در زیرساخت های موجود قرار می گیرد. به عنوان مثال، کنترل نسخه مورد نیاز نیست؛ ما قبلاً کدهای منبع خود را داریم. مکانیسم امضای ما متفاوت است: ما از یک سرور ویژه استفاده می کنیم. یک مخزن نیز مورد نیاز نیست.

علاوه بر این، پشتیبانی از سایر توزیع ها - به عنوان مثال، Red Hat - نسبتا ضعیف اجرا می شود، که قابل درک است.

مزیت چنین سرویسی پشتیبانی سریع از نسخه بعدی توزیع SUSE است. قبل از اعلام رسمی انتشار، بسته های لازم برای مونتاژ در یک مخزن عمومی قرار می گیرند. توزیع جدیدی در لیست توزیع های موجود در OpenBuildService ظاهر می شود. کادر را علامت می زنیم و به پلان ساخت اضافه می شود. بنابراین، افزودن یک نسخه جدید از توزیع تقریباً با یک کلیک انجام می شود.

در زیرساخت ما، با استفاده از OpenBuildService، کل بسته های KMP ماژول هسته veeamsnap برای توزیع های SUSE مونتاژ می شود.

در مرحله بعد، من می خواهم در مورد مسائل مربوط به ماژول های هسته صحبت کنم.

هسته ABI

ماژول های هسته لینوکس در طول تاریخ به شکل منبع توزیع شده اند. واقعیت این است که سازندگان هسته دغدغه حمایت از یک API پایدار برای ماژول‌های هسته، و به ویژه در سطح باینری، که بیشتر به عنوان kABI نامیده می‌شود، را به دوش نمی‌کشند.

برای ساخت یک ماژول برای یک هسته وانیلی، قطعاً به هدرهای این هسته خاص نیاز دارید و فقط روی این هسته کار می کند.

DKMS به شما امکان می دهد هنگام به روز رسانی هسته، فرآیند ساخت ماژول ها را خودکار کنید. در نتیجه، کاربران مخزن دبیان (و بسیاری از خویشاوندان آن) از ماژول های هسته یا از مخزن توزیع کننده یا کامپایل شده از منبع با استفاده از DKMS استفاده می کنند.

با این حال، این وضعیت به ویژه برای بخش Enterprise مناسب نیست. توزیع کنندگان کد اختصاصی می خواهند محصول را به صورت باینری های کامپایل شده توزیع کنند.

مدیران به دلایل امنیتی نمی خواهند ابزارهای توسعه را روی سرورهای تولید نگه دارند. توزیع کنندگان لینوکس سازمانی مانند Red Hat و SUSE تصمیم گرفتند که می توانند kABI پایدار را برای کاربران خود پشتیبانی کنند. نتیجه بسته‌های KMOD برای Red Hat و بسته‌های KMP برای SUSE بود.

ماهیت این راه حل بسیار ساده است. برای یک نسخه خاص از توزیع، هسته API ثابت است. توزیع کننده بیان می کند که از هسته مثلاً 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 فقط برای یک سال بسیار ساده تر است. چرخه به‌روزرسانی سالانه ماژول هسته نباید برای سازندگان ماژول مشکلی ایجاد کند.

در نتیجه این خط مشی SUSE، ما هیچ مشکلی در مورد سازگاری kABI در ماژول veeamsnap خود ثبت نکرده ایم. درست است، تعداد بسته های SUSE تقریباً یک مرتبه بزرگتر است.

پچ ها و بک پورت ها

اگرچه توزیع کنندگان سعی می کنند از سازگاری kABI و پایداری هسته اطمینان حاصل کنند، اما سعی می کنند عملکرد را بهبود بخشند و عیوب این هسته پایدار را برطرف کنند.

در همان زمان، توسعه دهندگان هسته لینوکس سازمانی، علاوه بر "کار بر روی خطاها" خود، تغییرات هسته وانیلی را نظارت کرده و آنها را به هسته "پایدار" خود منتقل می کنند.

گاهی اوقات این منجر به موارد جدید می شود اشتباهات.

در آخرین نسخه Red Hat 6، اشتباهی در یکی از آپدیت های جزئی رخ داده است. این منجر به این واقعیت شد که ماژول veeamsnap هنگام انتشار عکس فوری، سیستم را از کار می‌اندازد. با مقایسه منابع هسته قبل و بعد از به روز رسانی، متوجه شدیم که backport مقصر بوده است. اصلاح مشابهی در نسخه 4.19 هسته وانیلی ایجاد شد. فقط این درست است که در هسته وانیلی به خوبی کار می کرد، اما هنگام انتقال آن به "پایدار" 2.6.32، مشکلی با اسپینلاک ایجاد شد.

البته همه همیشه خطا دارند، اما آیا ارزش این را داشت که کد را از 4.19 به 2.6.32 بکشید و ثبات را به خطر بیندازید؟.. مطمئن نیستم...

بدترین چیز زمانی است که بازاریابی درگیر کشمکش بین «ثبات» و «مدرن‌سازی» می‌شود. بخش بازاریابی نیاز دارد که هسته توزیع به روز شده از یک طرف پایدار باشد و در عین حال عملکرد بهتری داشته باشد و ویژگی های جدید داشته باشد. این منجر به سازش های عجیب می شود.

وقتی سعی کردم یک ماژول بر روی هسته 4.4 از SLES 12 SP3 بسازم، از یافتن عملکرد وانیلی 4.8 در آن شگفت زده شدم. به نظر من، اجرای بلوک ورودی/خروجی هسته 4.4 از SLES 12 SP3 بیشتر شبیه هسته 4.8 است تا نسخه قبلی هسته پایدار 4.4 از SLES12 SP2. من نمی توانم قضاوت کنم که چه درصدی از کد از هسته 4.8 به SLES 4.4 برای SP3 منتقل شده است، اما حتی نمی توانم هسته را همان stabil 4.4 بنامم.

ناخوشایندترین چیز در مورد این است که هنگام نوشتن ماژولی که به همان اندازه روی هسته های مختلف کار می کند، دیگر نمی توانید به نسخه هسته اعتماد کنید. شما همچنین باید توزیع را در نظر بگیرید. خوب است که گاهی اوقات می توانید درگیر تعریفی شوید که همراه با عملکرد جدید ظاهر می شود، اما این فرصت همیشه ظاهر نمی شود.

در نتیجه، کد با دستورات کامپایل شرطی عجیب و غریب بیش از حد رشد می کند.

همچنین وصله هایی وجود دارند که API اسناد هسته را تغییر می دهند.
با توزیع مواجه شدم KDE نئون 5.16 و بسیار متعجب شدم که دیدم فراخوانی lookup_bdev در این نسخه کرنل لیست پارامترهای ورودی را تغییر داده است.

برای جمع‌آوری آن، باید یک اسکریپت به makefile اضافه می‌کردم که بررسی می‌کند آیا تابع lookup_bdev پارامتر mask دارد یا خیر.

امضای ماژول های هسته

اما به بحث توزیع بسته ها برگردیم.

یکی از مزایای kABI پایدار این است که ماژول های هسته را می توان به عنوان یک فایل باینری امضا کرد. در این مورد، توسعه دهنده می تواند مطمئن باشد که ماژول به طور تصادفی آسیب ندیده یا عمداً تغییر نکرده است. می توانید با دستور modinfo این را بررسی کنید.

توزیع‌های Red Hat و SUSE به شما امکان می‌دهند امضای ماژول را بررسی کرده و آن را تنها در صورتی بارگذاری کنید که گواهی مربوطه در سیستم ثبت شده باشد. گواهینامه کلید عمومی است که ماژول با آن امضا شده است. ما آن را به عنوان یک بسته جداگانه توزیع می کنیم.

مشکل اینجاست که گواهی ها می توانند یا در هسته ساخته شوند (توزیع کنندگان از آنها استفاده می کنند) یا باید با استفاده از یک ابزار در حافظه غیر فرار EFI نوشته شوند. موکوتیل. سودمند موکوتیل هنگام نصب یک گواهی، از شما می خواهد که سیستم را راه اندازی مجدد کنید و حتی قبل از بارگیری هسته سیستم عامل، از سرپرست می خواهد که اجازه بارگیری گواهی جدید را بدهد.

بنابراین، افزودن گواهی نیاز به دسترسی مدیر فیزیکی به سیستم دارد. اگر دستگاه در جایی در ابر یا به سادگی در یک اتاق سرور راه دور قرار داشته باشد و دسترسی فقط از طریق شبکه باشد (مثلاً از طریق ssh)، اضافه کردن گواهی غیرممکن خواهد بود.

EFI در ماشین های مجازی

علیرغم اینکه EFI برای مدت طولانی توسط تقریباً همه سازندگان مادربرد پشتیبانی می شود، ممکن است هنگام نصب یک سیستم، مدیر به نیاز به EFI فکر نکند و ممکن است غیرفعال شود.

همه هایپروایزرها از EFI پشتیبانی نمی کنند. VMWare vSphere از EFI از نسخه 5 پشتیبانی می کند.
Microsoft Hyper-V همچنین با شروع Hyper-V برای Windows Server 2012R2 از EFI پشتیبانی کرد.

با این حال، در پیکربندی پیش‌فرض این عملکرد برای ماشین‌های لینوکس غیرفعال است، به این معنی که گواهی را نمی‌توان نصب کرد.

در vSphere 6.5، گزینه را تنظیم کنید بوت امن فقط در نسخه قدیمی رابط وب که از طریق Flash اجرا می شود امکان پذیر است. رابط کاربری وب در HTML-5 هنوز خیلی عقب است.

توزیع های تجربی

و در نهایت، اجازه دهید موضوع توزیع های آزمایشی و توزیع های بدون پشتیبانی رسمی را در نظر بگیریم. از یک طرف، بعید است که چنین توزیع هایی در سرورهای سازمان های جدی یافت شود. هیچ پشتیبانی رسمی برای چنین توزیع هایی وجود ندارد. بنابراین، آنها را ارائه دهید. محصول در چنین توزیعی قابل پشتیبانی نیست.

با این حال، چنین توزیع هایی به یک پلت فرم مناسب برای آزمایش راه حل های تجربی جدید تبدیل می شوند. به عنوان مثال، فدورا، OpenSUSE Tumbleweed یا نسخه های ناپایدار دبیان. آنها کاملاً پایدار هستند. آنها همیشه نسخه های جدید برنامه ها و همیشه یک هسته جدید دارند. در عرض یک سال، این عملکرد آزمایشی ممکن است به یک RHEL، SLES یا اوبونتو به‌روز شود.

بنابراین اگر چیزی در یک توزیع آزمایشی کار نمی کند، این دلیلی برای کشف مشکل و حل آن است. باید برای این واقعیت آماده باشید که این قابلیت به زودی در سرورهای تولید کاربران ظاهر می شود.

می توانید لیست فعلی توزیع های رسمی پشتیبانی شده برای نسخه 3.0 را مطالعه کنید اینجا. اما فهرست واقعی توزیع‌هایی که محصول ما می‌تواند روی آنها کار کند بسیار گسترده‌تر است.

من شخصاً به آزمایش با سیستم عامل Elbrus علاقه مند بودم. پس از نهایی شدن بسته veeam، محصول ما نصب شد و کار کرد. من در مورد این آزمایش در Habré نوشتم مقاله.

خوب، پشتیبانی از توزیع های جدید ادامه دارد. منتظر انتشار نسخه 4.0 هستیم. بتا در شرف ظهور است، بنابراین مراقب باشید چه خبر!

منبع: www.habr.com