Har qanday tarqatishda ishlaydigan zaxira ilovasini yaratish oson ish emas. Linux uchun Veeam Agent Red Hat 6 va Debian 6, OpenSUSE 15.1 va Ubuntu 19.04 distributivlarida ishlashini ta'minlash uchun siz bir qator muammolarni hal qilishingiz kerak, ayniqsa dasturiy mahsulot yadro modulini o'z ichiga oladi.
Maqola konferensiyadagi nutqi materiallari asosida yaratilgan .
Linux eng mashhur operatsion tizimlardan biri emas. Aslida, bu platforma bo'lib, uning asosida siz o'ziga xos, o'ziga xos narsalarni yaratishingiz mumkin. Buning yordamida Linuxda dasturiy ta'minot komponentlari to'plamida farq qiluvchi ko'plab tarqatishlar mavjud. Va bu erda muammo tug'iladi: dasturiy mahsulot har qanday tarqatishda ishlashi uchun siz har birining xususiyatlarini hisobga olishingiz kerak.
Paket menejerlari. .deb va .rpm
Keling, mahsulotni turli xil tarqatishlar bo'yicha taqsimlashning aniq muammosidan boshlaylik.
Dasturiy ta'minot mahsulotlarini tarqatishning eng odatiy usuli bu paketni omborga joylashtirishdir, shunda tizimga o'rnatilgan paket menejeri uni o'sha erdan o'rnatishi mumkin.
Biroq, bizda ikkita mashhur paket formati mavjud: rpm и deb nomlangan. Bu shuni anglatadiki, hamma qo'llab-quvvatlashi kerak.
Deb paketlari dunyosida moslik darajasi hayratlanarli. Xuddi shu paket Debian 6 va Ubuntu 19.04 da bir xil darajada yaxshi o'rnatiladi va ishlaydi. Eski Debian distributivlarida belgilangan paketlarni yaratish va ular bilan ishlash standartlari yangi Linux Mint va elementar OTda dolzarbligicha qolmoqda. Shuning uchun, Linux uchun Veeam Agent bo'lsa, har bir apparat platformasi uchun bitta deb to'plami etarli.
Ammo rpm paketlari dunyosida farqlar juda katta. Birinchidan, ikkita mutlaqo mustaqil distribyutorlar mavjudligi sababli, Red Hat va SUSE, ular uchun moslik mutlaqo keraksiz. Ikkinchidan, ushbu distribyutorlar ulardan tarqatish to'plamlariga ega. qo'llab-quvvatlash va eksperimental. Ularning o'rtasida ham moslik kerak emas. Ma'lum bo'lishicha, el6, el7 va el8 o'z paketlariga ega. Fedora uchun alohida paket. SLES11 va 12 uchun paketlar va openSUSE uchun alohida paketlar. Asosiy muammo - bu bog'liqliklar va paket nomlari.
Qaramlik muammosi
Afsuski, bir xil paketlar ko'pincha turli tarqatishlarda turli nomlar ostida tugaydi. Quyida veeam paketiga bog'liqliklarning qisman ro'yxati keltirilgan.
EL7 uchun:
SLES 12 uchun:
- libblkid
- libgcc
- libstdc++
- ncurses-libs
- sug'urta bloklari
- fayl kutubxonalari
- veeamsnap=3.0.2.1185
- libblkid1
- libgcc_s1
- libstdc++6
- libmagic1
- libfuse2
- veeamsnap-kmp=3.0.2.1185
Natijada, bog'liqliklar ro'yxati tarqatish uchun noyobdir.
Eng yomoni, yangilangan versiya eski paket nomi ostida yashirinishni boshlaganida.
Misol:
Paket Fedora 24 da yangilandi hamshiralar 5-versiyadan 6-versiyagacha. Bizning mahsulotimiz eski tarqatishlar bilan mosligini taʼminlash uchun 5-versiya bilan yaratilgan. Fedora 5-da kutubxonaning eski 24-versiyasidan foydalanish uchun men paketdan foydalanishim kerak edi ncurses-compat-libs.
Natijada, Fedora uchun turli xil bog'liqliklarga ega bo'lgan ikkita paket mavjud.
Yana qiziqroq. Keyingi tarqatish yangilanishidan so'ng, paket ncurses-compat-libs kutubxonaning 5-versiyasi bilan u mavjud emas. Distribyutor uchun eski kutubxonalarni tarqatishning yangi versiyasiga sudrab borish qimmatga tushadi. Biroz vaqt o'tgach, muammo SUSE tarqatishlarida takrorlandi.
Natijada, ba'zi tarqatishlar o'zlarining aniq qaramligini yo'qotishlari kerak edi ncurses-libs, va mahsulotni kutubxonaning istalgan versiyasi bilan ishlashi uchun tuzating.
Aytgancha, Red Hat-ning 8-versiyasida endi meta-paket yo'q python, bu yaxshi eskilikni nazarda tutgan piton 2.7. Bor python2 и python3.
Paket menejerlariga muqobil
Bog'liqlar bilan bog'liq muammo eski va uzoq vaqtdan beri aniq. Faqat qaramlik do'zaxini eslang.
Har xil kutubxonalar va ilovalarni birlashtirish, shunda ularning barchasi barqaror ishlaydi va ziddiyatli bo'lmaydi - aslida bu har qanday Linux distribyutori hal qilishga harakat qiladigan vazifadir.
Paket menejeri bu muammoni butunlay boshqacha tarzda hal qilishga harakat qiladi. Zerikkan Canonical dan. Asosiy g'oya: dastur asosiy tizimdan izolyatsiya qilingan va himoyalangan qum qutisida ishlaydi. Agar ilova kutubxonalarni talab qilsa, ular ilovaning o'zi bilan ta'minlanadi.
Yumshoq shuningdek, Linux konteynerlari yordamida ilovalarni sinov muhitida ishga tushirishga imkon beradi. Sandbox g'oyasi ham qo'llaniladi AppImage.
Ushbu echimlar har qanday tarqatish uchun bitta paketni yaratishga imkon beradi. bo'lsa Yumshoq ilovani o'rnatish va ishga tushirish hatto administratorning xabarisiz ham mumkin.
Asosiy muammo shundaki, barcha ilovalar sinov muhitida ishlay olmaydi. Ba'zi odamlar platformaga to'g'ridan-to'g'ri kirishlari kerak. Men yadroga qat'iy bog'liq bo'lgan va sandbox kontseptsiyasiga mos kelmaydigan yadro modullari haqida gapirmayapman.
Ikkinchi muammo shundaki, Red Hat va SUSE-dan korporativ muhitda mashhur bo'lgan tarqatishlar hali Snappy va Flatpak-ni qo'llab-quvvatlamaydi.
Shu munosabat bilan Linux uchun Veeam Agent mavjud emas yoqilmagan .
Paket menejerlari haqidagi savolni yakunlash uchun shuni ta'kidlashni istardimki, ikkilik fayllar va ularni bitta paketga o'rnatish uchun skriptni birlashtirib, paket menejerlaridan butunlay voz kechish imkoniyati mavjud.
Bunday to'plam sizga turli xil distribyutorlar va platformalar uchun bitta umumiy paketni yaratishga, kerakli sozlashni amalga oshirgan holda interaktiv o'rnatish jarayonini amalga oshirishga imkon beradi. Men Linux uchun bunday paketlarni faqat VMware'dan uchratdim.
Yangilash muammosi
Agar barcha qaramlik muammolari hal qilingan bo'lsa ham, dastur bir xil taqsimotda boshqacha ishlashi mumkin. Bu yangilanishlar masalasi.
3 ta yangilash strategiyasi mavjud:
- Eng oddiy narsa hech qachon yangilanmaslikdir. Men serverni o'rnatdim va bu haqda unutdim. Agar hamma narsa ishlayotgan bo'lsa, nima uchun yangilash kerak? Muammolar birinchi marta qo'llab-quvvatlash xizmatiga murojaat qilganingizda boshlanadi. Tarqatish yaratuvchisi faqat yangilangan nashrni qo'llab-quvvatlaydi.
- Siz distribyutorga ishonishingiz va avtomatik yangilanishlarni o'rnatishingiz mumkin. Bunday holda, muvaffaqiyatsiz yangilanishdan so'ng darhol qo'llab-quvvatlash xizmatiga qo'ng'iroq qilish mumkin.
- Sinov infratuzilmasida ishga tushirilgandan keyingina qo'lda yangilash varianti eng ishonchli, ammo qimmat va ko'p vaqt talab qiladi. Hamma ham bunga qodir emas.
Turli xil foydalanuvchilar turli xil yangilash strategiyalarini qo'llaganligi sababli, eng so'nggi versiyani ham, ilgari chiqarilganlarni ham qo'llab-quvvatlash kerak. Bu ishlab chiqish va sinov jarayonini murakkablashtiradi va qo'llab-quvvatlash guruhiga bosh og'rig'ini qo'shadi.
Har xil apparat platformalari
Turli xil apparat platformalari asosan mahalliy kodga xos bo'lgan muammodir. Hech bo'lmaganda har bir qo'llab-quvvatlanadigan platforma uchun ikkilik fayllarni to'plashingiz kerak.
Linux uchun Veeam Agent loyihasida biz hali ham ushbu RISC kabi hech narsani qo'llab-quvvatlay olmaymiz.
Bu masalaga batafsil to‘xtalmayman. Men faqat asosiy muammolarni ko'rsataman: platformaga bog'liq turlar, masalan size_t, strukturani tekislash va bayt tartibi.
Statik va/yoki dinamik ulanish
Ammo savol "Kutubxonalar bilan qanday bog'lanish kerak - dinamik yoki statik?" muhokama qilishga arziydi.
Qoida tariqasida, Linux ostidagi C/C++ ilovalari dinamik ulanishdan foydalanadi. Agar dastur maxsus tarqatish uchun yaratilgan bo'lsa, bu juda yaxshi ishlaydi.
Agar vazifa bitta ikkilik fayl bilan turli xil tarqatishlarni qoplash bo'lsa, unda siz eng qadimgi qo'llab-quvvatlanadigan tarqatishga e'tibor qaratishingiz kerak. Biz uchun bu Red Hat 6. Unda gcc 4.4 mavjud, hatto C++ 11 standarti ham qo'llab-quvvatlamaydi. .
Biz loyihamizni C++ 6.3 ni to'liq qo'llab-quvvatlaydigan gcc 14 yordamida quramiz. Tabiiyki, bu holda, Red Hat 6-da siz libstdc++ ni olib yurishingiz va kutubxonalarni kuchaytirishingiz kerak. Eng oson yo'li ular bilan statik bog'lanishdir.
Afsuski, barcha kutubxonalarni statik ravishda bog'lab bo'lmaydi.
Birinchidan, tizim kutubxonalari, masalan libfuse, libblkid yadro va uning modullari bilan mos kelishini ta'minlash uchun dinamik bog'lanish zarur.
Ikkinchidan, litsenziyalar bilan bir noziklik bor.
GPL litsenziyasi asosan kutubxonalarni faqat ochiq kodli kod bilan bog'lash imkonini beradi. MIT va BSD statik ulanishga imkon beradi va kutubxonalarni loyihaga kiritishga imkon beradi. Lekin LGPL statik ulanishga zid ko'rinmaydi, lekin ulanish uchun zarur bo'lgan fayllarni baham ko'rishni talab qiladi.
Umuman olganda, dinamik bog'lanishdan foydalanish sizni biror narsa taqdim etishdan saqlaydi.
C/C++ dasturlarini yaratish
Turli platformalar va distribyutsiyalar uchun C/C++ ilovalarini yaratish uchun gcc ning mos versiyasini tanlash yoki qurish va muayyan arxitekturalar uchun o‘zaro kompilyatorlardan foydalanish va butun kutubxonalar to‘plamini yig‘ish kifoya. Bu ish juda mumkin, ammo juda mashaqqatli. Va tanlangan kompilyator va kutubxonalar ishlaydigan versiyani taqdim etishiga kafolat yo'q.
Aniq afzallik: infratuzilma juda soddalashtirilgan, chunki butun qurish jarayoni bitta mashinada bajarilishi mumkin. Bundan tashqari, bitta arxitektura uchun bitta ikkilik to'plamini to'plash kifoya va siz ularni turli xil tarqatishlar uchun paketlarga to'plashingiz mumkin. Linux uchun Veeam Agent uchun veeam paketlari shunday yaratilgan.
Ushbu variantdan farqli o'laroq, siz oddiygina qurilish fermasini, ya'ni yig'ish uchun bir nechta mashinalarni tayyorlashingiz mumkin. Har bir bunday mashina ma'lum bir tarqatish va ma'lum bir arxitektura uchun ilovalarni kompilyatsiya qilish va paketlarni yig'ishni ta'minlaydi. Bunday holda, kompilyatsiya distribyutor tomonidan tayyorlangan vositalar yordamida amalga oshiriladi. Ya'ni kompilyatorni tayyorlash va kutubxonalarni tanlash bosqichi chiqarib tashlanadi. Bunga qo'shimcha ravishda, qurish jarayoni osongina parallellashtirilishi mumkin.
Biroq, bu yondashuvning salbiy tomoni bor: bir xil arxitekturadagi har bir tarqatish uchun siz o'zingizning ikkilik fayllar to'plamini to'plashingiz kerak bo'ladi. Yana bir kamchilik shundaki, bunday ko'p sonli mashinalarni saqlash va katta hajmdagi disk maydoni va RAMni ajratish kerak.
Red Hat tarqatish uchun veeamsnap yadro modulining KMOD paketlari shunday tuzilgan.
Qurilish xizmatini oching
SUSE hamkasblari ilovalarni kompilyatsiya qilish va paketlarni yig'ish uchun maxsus xizmat ko'rinishida o'rta darajani amalga oshirishga harakat qilishdi - .
Aslida, bu virtual mashinani yaratadigan, unga barcha kerakli paketlarni o'rnatadigan, ilovani kompilyatsiya qiladigan va paketni ushbu izolyatsiya qilingan muhitda quradigan gipervisor, shundan so'ng virtual mashina chiqariladi.
OpenBuildService-da amalga oshirilgan rejalashtiruvchi optimal paketlarni yaratish tezligi uchun qancha virtual mashinani ishga tushirishi mumkinligini aniqlaydi. O'rnatilgan imzolash mexanizmi paketlarni imzolaydi va ularni o'rnatilgan omborga yuklaydi. O'rnatilgan versiyani boshqarish tizimi o'zgarishlar va tuzilishlar tarixini saqlaydi. Qolgan narsa shunchaki manbalaringizni ushbu tizimga qo'shishdir. Serverni o'zingiz sozlashingiz shart emas, siz ochiq serverdan foydalanishingiz mumkin.
Biroq, muammo bor: bunday kombaynni mavjud infratuzilmaga sig'dirish qiyin. Masalan, versiyani boshqarish kerak emas; bizda allaqachon manba kodlari uchun o'zimiz bor. Bizning imzo mexanizmimiz boshqacha: biz maxsus serverdan foydalanamiz. Ombor ham kerak emas.
Bundan tashqari, boshqa tarqatishlarni qo'llab-quvvatlash - masalan, Red Hat - juda yomon amalga oshirilgan, bu tushunarli.
Bunday xizmatning afzalligi SUSE tarqatishning keyingi versiyasini tezkor qo'llab-quvvatlashdir. Chiqarish rasmiy e'lon qilinishidan oldin, yig'ish uchun zarur bo'lgan paketlar umumiy omborga joylashtiriladi. OpenBuildService-da mavjud tarqatishlar ro'yxatida yangisi paydo bo'ladi. Biz katakchani belgilaymiz va u qurilish rejasiga qo'shiladi. Shunday qilib, tarqatishning yangi versiyasini qo'shish deyarli bir marta bosish bilan amalga oshiriladi.
Bizning infratuzilmamizda OpenBuildService-dan foydalangan holda, SUSE tarqatish uchun veeamsnap yadro modulining barcha xilma-xil KMP paketlari yig'ilgan.
Keyinchalik, yadro modullariga xos bo'lgan masalalarga to'xtalib o'tmoqchiman.
yadro ABI
Linux yadro modullari tarixan manba shaklida tarqatilgan. Gap shundaki, yadro yaratuvchilari yadro modullari uchun barqaror API-ni qo'llab-quvvatlash tashvishini o'z zimmalariga yuklamaydilar va ayniqsa ikkilik darajada, keyinchalik kABI deb ataladi.
Vanil yadrosi uchun modul yaratish uchun sizga aniq ushbu yadroning sarlavhalari kerak bo'ladi va u faqat shu yadroda ishlaydi.
DKMS yadroni yangilashda modullarni qurish jarayonini avtomatlashtirish imkonini beradi. Natijada, Debian ombori foydalanuvchilari (va uning ko'plab qarindoshlari) distributorning omboridan yoki DKMS yordamida manbadan tuzilgan yadro modullaridan foydalanadilar.
Biroq, bu holat Enterprise segmentiga juda mos kelmaydi. Xususiy kod distribyutorlari mahsulotni kompilyatsiya qilingan ikkilik sifatida tarqatmoqchi.
Administratorlar xavfsizlik sababli ishlab chiqarish vositalarini ishlab chiqarish serverlarida saqlashni xohlamaydilar. Red Hat va SUSE kabi Enterprise Linux distribyutorlari o'z foydalanuvchilari uchun barqaror kABI-ni qo'llab-quvvatlashga qaror qilishdi. Natijada Red Hat uchun KMOD paketlari va SUSE uchun KMP paketlari paydo bo'ldi.
Ushbu yechimning mohiyati juda oddiy. Tarqatishning ma'lum bir versiyasi uchun yadro APIsi muzlatilgan. Distribyutor, masalan, 3.10 yadrosidan foydalanishini va faqat yadro interfeyslariga ta'sir qilmaydigan tuzatishlar va yaxshilanishlarni amalga oshirishini ta'kidlaydi va birinchi yadro uchun to'plangan modullar barcha keyingi modullar uchun qayta kompilyatsiyasiz ishlatilishi mumkin.
Red Hat butun umri davomida tarqatish uchun kABI muvofiqligini da'vo qiladi. Ya'ni, rhel 6.0 uchun yig'ilgan modul (2010 yil noyabr oyida chiqarilgan) 6.10 versiyasida ham ishlashi kerak (2018 yil iyuni). Va bu deyarli 8 yil. Tabiiyki, bu vazifa juda qiyin.
Biz veeamsnap moduli kABI muvofiqligi bilan bog'liq muammolar tufayli ishlamay qolgan bir nechta holatlarni qayd etdik.
RHEL 7.0 uchun tuzilgan veeamsnap moduli RHEL 7.5 yadrosi bilan mos kelmaydigan boʻlib chiqdi, lekin u yuklangan va serverni ishdan chiqarishi kafolatlanganidan soʻng, biz RHEL 7 uchun kABI muvofiqligidan foydalanishdan butunlay voz kechdik.
Hozirda RHEL 7 uchun KMOD to'plami har bir nashr versiyasi uchun yig'ilish va modulni yuklaydigan skriptni o'z ichiga oladi.
SUSE kABI muvofiqligi vazifasiga yanada ehtiyotkorlik bilan yondashdi. Ular kABI mosligini faqat bitta xizmat paketi doirasida ta'minlaydi.
Misol uchun, SLES 12 ning chiqarilishi 2014 yil sentyabr oyida bo'lib o'tdi. SLES 12 SP1 esa 2015 yil dekabr oyida edi, ya'ni bir yildan bir oz ko'proq vaqt o'tdi. Ikkala versiya ham 3.12 yadrosidan foydalansa ham, ular kABIga mos kelmaydi. Shubhasiz, bir yil davomida kABI muvofiqligini saqlab qolish ancha oson. Yadro modulining yillik yangilanish davri modul yaratuvchilar uchun muammo tug‘dirmasligi kerak.
Ushbu SUSE siyosati natijasida biz veeamsnap modulimizda kABI muvofiqligi bilan bog'liq birorta muammo qayd etmadik. To'g'ri, SUSE uchun paketlar soni deyarli kattaroqdir.
Yamalar va orqa portlar
Distribyutorlar kABI muvofiqligi va yadro barqarorligini ta'minlashga harakat qilsalar ham, ular ish faoliyatini yaxshilashga va ushbu barqaror yadroning kamchiliklarini bartaraf etishga harakat qilishadi.
Shu bilan birga, o'zlarining "xatolar ustida ishlash" dan tashqari, Linux yadrosi ishlab chiquvchilari vanil yadrosidagi o'zgarishlarni kuzatib boradilar va ularni "barqaror" ga o'tkazadilar.
Ba'zan bu yangilariga olib keladi .
Red Hat 6-ning so'nggi versiyasida kichik yangilanishlardan birida xatolik yuz berdi. Bu veeamsnap moduli snapshot chiqarilganda tizimni ishdan chiqarishi kafolatlanganligiga olib keldi. Yangilanishdan oldin va keyin yadro manbalarini taqqoslab, biz backport aybdor ekanligini aniqladik. Xuddi shunday tuzatish vanil yadrosining 4.19 versiyasida ham amalga oshirildi. Shunchaki, bu tuzatish vanil yadrosida yaxshi ishladi, lekin uni "barqaror" 2.6.32 ga o'tkazishda spinlock bilan muammo paydo bo'ldi.
Albatta, har kimda doim xato bo'ladi, lekin barqarorlikni xavf ostiga qo'yib, kodni 4.19 dan 2.6.32 gacha sudrab borishga arziydimi?.. Ishonchim komil emas...
Eng yomoni, marketing "barqarorlik" va "modernizatsiya" o'rtasidagi tortishuvga aralashsa. Marketing bo'limi bir tomondan barqaror bo'lishi va ayni paytda ishlashda yaxshiroq bo'lishi va yangi xususiyatlarga ega bo'lishi uchun yangilangan tarqatishning yadrosiga muhtoj. Bu g'alati murosaga olib keladi.
SLES 4.4 SP12 dan 3 yadrosida modul yaratishga harakat qilganimda, undagi vanil 4.8 dan funksionallikni topib hayron qoldim. Menimcha, SLES 4.4 SP12 dan 3 yadrosining blokli kiritish-chiqarish bloki SLES4.8 SP4.4 dan barqaror 12 yadroning oldingi versiyasiga qaraganda 2 yadroga koʻproq oʻxshaydi. Kodning necha foizi SP4.8 uchun yadro 4.4 dan SLES 3 ga o'tkazilganligini aniqlay olmayman, lekin yadroni bir xil barqaror 4.4 deb ham atay olmayman.
Buning eng yoqimsiz tomoni shundaki, turli yadrolarda teng darajada yaxshi ishlaydigan modul yozishda siz endi yadro versiyasiga tayanolmaysiz. Siz tarqatishni ham hisobga olishingiz kerak. Ba'zida siz yangi funksionallik bilan birga paydo bo'ladigan ta'rifga qo'shilishingiz yaxshi, lekin bu imkoniyat har doim ham paydo bo'lmaydi.
Natijada, kod g'alati shartli kompilyatsiya direktivalari bilan to'lib ketadi.
Hujjatlangan yadro API-ni o'zgartiruvchi yamoqlar ham mavjud.
Men taqsimotga duch keldim 5.16 va ushbu yadro versiyasidagi lookup_bdev chaqiruvi kirish parametrlari ro'yxatini o'zgartirganini ko'rib juda hayron bo'ldi.
Uni birlashtirish uchun makefile fayliga search_bdev funksiyasida niqob parametri bor-yo‘qligini tekshiradigan skript qo‘shishim kerak edi.
Yadro modullarini imzolash
Ammo paketlarni taqsimlash masalasiga qaytaylik.
Barqaror kABI ning afzalliklaridan biri yadro modullari ikkilik fayl sifatida imzolanishi mumkin. Bunday holda, ishlab chiquvchi modul tasodifan shikastlanmagan yoki ataylab o'zgartirilmaganligiga ishonch hosil qilishi mumkin. Buni modinfo buyrug'i bilan tekshirishingiz mumkin.
Red Hat va SUSE distributivlari modul imzosini tekshirish va uni faqat tegishli sertifikat tizimda ro‘yxatdan o‘tgan bo‘lsa yuklash imkonini beradi. Sertifikat modul imzolangan ochiq kalitdir. Biz uni alohida paket sifatida tarqatamiz.
Muammo shundaki, sertifikatlar yadroga o'rnatilishi mumkin (distribyutorlar ulardan foydalanadi) yoki yordamchi dastur yordamida EFI o'zgarmas xotirasiga yozilishi kerak. mokutil. Qulaylik mokutil Sertifikatni o'rnatishda u tizimni qayta ishga tushirishni talab qiladi va hatto operatsion tizim yadrosini yuklashdan oldin ham administratordan yangi sertifikatni yuklashga ruxsat berishni taklif qiladi.
Shunday qilib, sertifikat qo'shish tizimga jismoniy administrator kirishini talab qiladi. Agar mashina bulutning biron bir joyida yoki oddiygina uzoq server xonasida joylashgan bo'lsa va kirish faqat tarmoq orqali (masalan, ssh orqali) bo'lsa, unda sertifikat qo'shib bo'lmaydi.
Virtual mashinalarda EFI
EFI uzoq vaqtdan beri deyarli barcha anakart ishlab chiqaruvchilari tomonidan qo'llab-quvvatlanayotganiga qaramay, tizimni o'rnatishda ma'mur EFIga ehtiyoj haqida o'ylamasligi mumkin va u o'chirib qo'yilishi mumkin.
Barcha gipervisorlar EFI-ni qo'llab-quvvatlamaydi. VMWare vSphere 5-versiyadan boshlab EFI-ni qo'llab-quvvatlaydi.
Microsoft Hyper-V, shuningdek, Windows Server 2012R2 uchun Hyper-V-dan boshlab EFI-ni qo'llab-quvvatladi.
Biroq, standart konfiguratsiyada bu funksiya Linux mashinalari uchun o'chirib qo'yilgan, ya'ni sertifikatni o'rnatib bo'lmaydi.
vSphere 6.5 da opsiyani o'rnating Xavfsiz yuklash faqat Flash orqali ishlaydigan veb-interfeysning eski versiyasida mumkin. HTML-5 da Web UI hali ham ancha orqada.
Eksperimental taqsimotlar
Va nihoyat, rasmiy yordamisiz eksperimental tarqatish va tarqatish masalasini ko'rib chiqaylik. Bir tomondan, bunday tarqatishlarni jiddiy tashkilotlarning serverlarida topish mumkin emas. Bunday tarqatish uchun rasmiy yordam yo'q. Shuning uchun ularni taqdim eting. Bunday tarqatishda mahsulotni qo'llab-quvvatlab bo'lmaydi.
Biroq, bunday tarqatishlar yangi eksperimental echimlarni sinab ko'rish uchun qulay platformaga aylanadi. Masalan, Fedora, OpenSUSE Tumbleweed yoki Debianning beqaror versiyalari. Ular ancha barqaror. Ularda har doim dasturlarning yangi versiyalari va har doim yangi yadro mavjud. Bir yil ichida bu eksperimental funksiya yangilangan RHEL, SLES yoki Ubuntu bilan yakunlanishi mumkin.
Shunday qilib, agar biror narsa eksperimental taqsimotda ishlamasa, bu muammoni aniqlash va uni hal qilish uchun sababdir. Tez orada ushbu funksiya foydalanuvchilarning ishlab chiqarish serverlarida paydo bo'lishiga tayyor bo'lishingiz kerak.
3.0 versiyasi uchun rasmiy ravishda qo'llab-quvvatlanadigan tarqatishlarning joriy ro'yxatini o'rganishingiz mumkin . Ammo mahsulotimiz ishlashi mumkin bo'lgan tarqatishlarning haqiqiy ro'yxati ancha kengroq.
Shaxsan meni Elbrus OS bilan tajriba qiziqtirdi. Veeam paketini tugatgandan so'ng, mahsulotimiz o'rnatildi va ishladi. Men bu tajriba haqida Habré-da yozganman .
Xo'sh, yangi tarqatishlarni qo'llab-quvvatlash davom etmoqda. Biz 4.0 versiyasi chiqishini kutmoqdamiz. Beta-versiyasi paydo bo'ladi, shuning uchun ehtiyot bo'ling !
Manba: www.habr.com