İstənilən paylamada işləyən ehtiyat proqram yaratmaq asan məsələ deyil. Linux üçün Veeam Agent-in Red Hat 6 və Debian 6-dan OpenSUSE 15.1 və Ubuntu 19.04-ə qədər distributorlarda işləməsini təmin etmək üçün, xüsusən proqram məhsulunun nüvə modulunu ehtiva etdiyini nəzərə alsaq, bir sıra problemləri həll etməlisiniz.
Məqalə konfransdakı çıxışın materialları əsasında hazırlanıb .
Linux yalnız ən populyar əməliyyat sistemlərindən biri deyil. Əslində, bu, özünəməxsus, özünəməxsus bir şey edə biləcəyiniz bir platformadır. Bunun sayəsində Linux proqram komponentləri dəsti ilə fərqlənən çoxlu paylamalara malikdir. Və burada bir problem yaranır: proqram məhsulunun istənilən paylamada işləməsi üçün hər birinin xüsusiyyətlərini nəzərə almaq lazımdır.
Paket menecerləri. .deb vs .rpm
Məhsulun müxtəlif paylamalar üzrə paylanmasının aşkar problemindən başlayaq.
Proqram məhsullarını yaymağın ən tipik yolu paketi sistemə daxil edilmiş paket meneceri onu oradan quraşdıra bilməsi üçün depoya yerləşdirməkdir.
Bununla belə, iki məşhur paket formatımız var: rpm и deb. Bu o deməkdir ki, hamı dəstək olmalıdır.
Deb paketləri dünyasında uyğunluq səviyyəsi heyrətamizdir. Eyni paket həm Debian 6, həm də Ubuntu 19.04-də eyni dərəcədə yaxşı quraşdırır və işləyir. Köhnə Debian distributivlərində təsbit edilmiş paketlərin qurulması və onlarla işləmək prosesinin standartları yeni yaradılan Linux Mint və elementar ƏS-də aktual olaraq qalır. Buna görə, Linux üçün Veeam Agent vəziyyətində, hər bir aparat platforması üçün bir deb paketi kifayətdir.
Ancaq rpm paketləri dünyasında fərqlər böyükdür. Birincisi, uyğunluğun tamamilə lazımsız olduğu Red Hat və SUSE adlı iki tamamilə müstəqil distribyutorun olması səbəbindən. İkincisi, bu distribyutorların onlardan paylama dəstləri var. dəstək və eksperimental. Onların arasında uyğunluğa da ehtiyac yoxdur. Məlum oldu ki, el6, el7 və el8-in öz paketləri var. Fedora üçün ayrıca paket. SLES11 və 12 üçün paketlər və openSUSE üçün ayrıca paketlər. Əsas problem asılılıqlar və paket adlarıdır.
Asılılıq problemi
Təəssüf ki, eyni paketlər çox vaxt müxtəlif paylamalarda fərqli adlar altında bitir. Aşağıda veeam paketindən asılılıqların qismən siyahısı verilmişdir.
EL7 üçün:
SLES 12 üçün:
- libblkid
- libgcc
- libstdc++
- ncurses-libs
- qoruyucu bloklar
- fayl libləri
- veeamsnap=3.0.2.1185
- libblkid1
- libgcc_s1
- libstdc++6
- libmagic1
- libfuse2
- veeamsnap-kmp=3.0.2.1185
Nəticədə, asılılıqların siyahısı paylanma üçün unikaldır.
Daha da pisləşən odur ki, yenilənmiş versiya köhnə paket adı altında gizlənməyə başlayır.
Misal:
Paket Fedora 24-də yeniləndi tibb bacıları 5-ci versiyadan 6-cı versiyaya qədər. Məhsulumuz köhnə paylamalarla uyğunluğu təmin etmək üçün 5-ci versiya ilə hazırlanmışdır. Fedora 5-də kitabxananın köhnə 24-ci versiyasını istifadə etmək üçün paketdən istifadə etməli oldum ncurses-compat-libs.
Nəticədə, Fedora üçün müxtəlif asılılıqlara malik iki paket var.
Daha da maraqlı. Növbəti paylama yeniləməsindən sonra paket ncurses-compat-libs kitabxananın 5-ci versiyası ilə o, mövcud deyil. Distribyutor üçün köhnə kitabxanaları paylamanın yeni versiyasına sürükləmək baha başa gəlir. Bir müddət sonra problem SUSE paylamalarında təkrarlandı.
Nəticədə, bəzi paylamalar açıq-aşkar asılılığını azaltmalı oldu ncurses-libs, və məhsulu elə düzəldin ki, o, kitabxananın istənilən versiyası ilə işləyə bilsin.
Yeri gəlmişkən, Red Hat-ın 8-ci versiyasında artıq meta paket yoxdur python, yaxşı köhnə istinad edən piton 2.7. Var python2 и python3.
Paket menecerlərinə alternativ
Asılılıqla bağlı problem köhnədir və çoxdan aydındır. Yalnız asılılıq cəhənnəmini xatırlayın.
Müxtəlif kitabxanaları və proqramları birləşdirmək ki, hamısı sabit işləyir və ziddiyyət təşkil etmir - əslində bu, hər hansı bir Linux distribyutorunun həll etməyə çalışdığı vəzifədir.
Paket meneceri bu problemi tamamilə fərqli şəkildə həll etməyə çalışır. Sadə Canonical-dan. Əsas fikir: proqram əsas sistemdən təcrid olunmuş və qorunan sandboxda işləyir. Tətbiq üçün kitabxanalar tələb olunursa, onlar proqramın özü ilə təchiz edilir.
Düzəldici həmçinin Linux Konteynerlərindən istifadə edərək proqramları sandboxda işə salmağa imkan verir. Sandbox ideyası da istifadə olunur AppImage.
Bu həllər istənilən paylama üçün bir paket yaratmağa imkan verir. halda Düzəldici tətbiqin quraşdırılması və işə salınması hətta administratorun xəbəri olmadan da mümkündür.
Əsas problem odur ki, bütün proqramlar sandboxda işləyə bilməz. Bəzi insanların platformaya birbaşa çıxışı lazımdır. Mən hətta nüvədən ciddi şəkildə asılı olan və sandbox konsepsiyasına uyğun gəlməyən kernel modullarından danışmıram.
İkinci problem ondan ibarətdir ki, Red Hat və SUSE-dən müəssisə mühitində məşhur olan paylamalar hələ Snappy və Flatpak dəstəyini ehtiva etmir.
Bu baxımdan Linux üçün Veeam Agent mövcud deyil deyil .
Paket menecerləri haqqında sualı yekunlaşdırmaq üçün qeyd etmək istərdim ki, ikili faylları və onları bir paketə quraşdırmaq üçün skripti birləşdirərək paket menecerlərindən tamamilə imtina etmək imkanı var.
Belə bir paket müxtəlif paylamalar və platformalar üçün bir ümumi paket yaratmağa, lazımi fərdiləşdirməni həyata keçirərək interaktiv quraşdırma prosesini həyata keçirməyə imkan verir. Mən yalnız VMware-dən Linux üçün belə paketlərlə qarşılaşmışam.
Yeniləmə problemi
Bütün asılılıq məsələləri həll olunsa belə, proqram eyni paylamada fərqli şəkildə işləyə bilər. Bu yeniləmələr məsələsidir.
3 yeniləmə strategiyası var:
- Ən sadəsi heç vaxt yeniləməməkdir. Serveri quraşdırdım və onu unutdum. Hər şey işləyirsə niyə yeniləyin? Dəstəklə ilk əlaqə saxladığınız zaman problemlər başlayır. Dağıtım yaradıcısı yalnız yenilənmiş buraxılışı dəstəkləyir.
- Siz distribyutora etibar edə və avtomatik yeniləmələri qura bilərsiniz. Bu halda, uğursuz yeniləmədən dərhal sonra dəstək çağırışı ola bilər.
- Yalnız sınaq infrastrukturunda işə salındıqdan sonra əl ilə yeniləmə seçimi ən etibarlı, lakin bahalı və vaxt aparan seçimdir. Hər kəs bunu ödəyə bilməz.
Fərqli istifadəçilər fərqli yeniləmə strategiyalarından istifadə etdikləri üçün həm ən son buraxılışı, həm də əvvəllər buraxılmışları dəstəkləmək lazımdır. Bu, həm inkişaf, həm də sınaq prosesini çətinləşdirir və dəstək komandasına baş ağrısı əlavə edir.
Müxtəlif avadanlıq platformaları
Fərqli aparat platformaları əsasən yerli koda xas olan problemdir. Ən azı, hər bir dəstəklənən platforma üçün ikili faylları toplamaq lazımdır.
Linux üçün Veeam Agent layihəsində biz hələ də bu RISC kimi heç nəyi dəstəkləyə bilmirik.
Bu məsələnin üzərində ətraflı dayanmayacağam. Mən yalnız əsas problemləri qeyd edəcəyəm: platformadan asılı növlər, məsələn size_t, strukturun düzülməsi və bayt sırası.
Statik və/və ya dinamik əlaqə
Ancaq sual "Kitabxanalarla necə əlaqə qurmaq olar - dinamik və ya statik?" müzakirə etməyə dəyər.
Bir qayda olaraq, Linux altında C/C++ proqramları dinamik keçiddən istifadə edir. Tətbiq xüsusi bir paylama üçün qurulmuşdursa, bu əla işləyir.
Tapşırıq müxtəlif paylamaları bir ikili fayl ilə əhatə etməkdirsə, o zaman ən köhnə dəstəklənən paylamaya diqqət yetirməlisiniz. Bizim üçün bu Red Hat 6-dır. Onun tərkibində gcc 4.4 var, hətta C++ 11 standartı da bunu dəstəkləmir .
Layihəmizi C++ 6.3-ü tam dəstəkləyən gcc 14 istifadə edərək qururuq. Təbii ki, bu halda, Red Hat 6-da libstdc++ daşımalı və kitabxanaları gücləndirməlisiniz. Ən asan yol, onlarla statik əlaqə yaratmaqdır.
Ancaq təəssüf ki, bütün kitabxanalar statik olaraq əlaqələndirilə bilməz.
Birincisi, kimi sistem kitabxanaları libfuse, libblkid onların nüvə və onun modulları ilə uyğunluğunu təmin etmək üçün dinamik əlaqə yaratmaq lazımdır.
İkincisi, lisenziyalarla bağlı bir incəlik var.
GPL lisenziyası əsasən kitabxanaları yalnız açıq mənbə kodu ilə əlaqələndirməyə imkan verir. MIT və BSD statik əlaqələndirməyə imkan verir və kitabxanaların layihəyə daxil edilməsinə imkan verir. Lakin LGPL statik əlaqəyə zidd görünmür, lakin əlaqə üçün lazım olan faylların paylaşılmasını tələb edir.
Ümumiyyətlə, dinamik keçiddən istifadə sizi hər hansı bir şey təmin etmək məcburiyyətində qalmayacaqdır.
C/C++ proqramlarının qurulması
Müxtəlif platformalar və paylamalar üçün C/C++ proqramlarını qurmaq üçün gcc-nin uyğun versiyasını seçmək və ya qurmaq və xüsusi arxitekturalar üçün çarpaz tərtibçilərdən istifadə etmək və bütün kitabxana dəstini yığmaq kifayətdir. Bu iş olduqca mümkündür, lakin olduqca əziyyətlidir. Seçilmiş kompilyator və kitabxanaların işlək versiyanı təmin edəcəyinə heç bir zəmanət yoxdur.
Aşkar bir üstünlük: infrastruktur çox sadələşdirilmişdir, çünki bütün tikinti prosesi bir maşında tamamlana bilər. Bundan əlavə, bir arxitektura üçün bir binar dəsti toplamaq kifayətdir və onları müxtəlif paylamalar üçün paketlərə paketləyə bilərsiniz. Linux üçün Veeam Agent üçün veeam paketləri belə qurulur.
Bu seçimdən fərqli olaraq, sadəcə bir tikinti ferması, yəni montaj üçün bir neçə maşın hazırlaya bilərsiniz. Hər bir belə maşın müəyyən bir paylama və xüsusi bir arxitektura üçün proqram tərtibini və paketlərin yığılmasını təmin edəcəkdir. Bu halda kompilyasiya distribyutor tərəfindən hazırlanmış vasitələrdən istifadə etməklə həyata keçirilir. Yəni kompilyatorun hazırlanması və kitabxanaların seçilməsi mərhələsi aradan qaldırılır. Bundan əlavə, tikinti prosesi asanlıqla paralelləşdirilə bilər.
Bununla belə, bu yanaşmanın mənfi tərəfi var: eyni arxitektura daxilində hər bir paylama üçün öz ikili fayl dəstinizi toplamalı olacaqsınız. Başqa bir dezavantaj odur ki, belə çox sayda maşın saxlanılmalı və böyük miqdarda disk sahəsi və RAM ayrılmalıdır.
Red Hat paylamaları üçün veeamsnap nüvə modulunun KMOD paketləri belə tərtib edilir.
Quraşdırma Xidmətini açın
SUSE-dən olan həmkarları ərizələrin tərtib edilməsi və paketlərin yığılması üçün xüsusi xidmət şəklində bəzi orta səviyyəni həyata keçirməyə çalışdılar - .
Əslində, bu, virtual maşın yaradan, bütün lazımi paketləri quraşdıran, tətbiqi tərtib edən və bu təcrid olunmuş mühitdə paketi quran, bundan sonra virtual maşın buraxılan hipervizordur.
OpenBuildService-də həyata keçirilən planlaşdırıcı optimal paket qurma sürəti üçün neçə virtual maşını işə sala biləcəyini müəyyən edəcək. Daxili imzalama mexanizmi paketləri imzalayacaq və onları daxili repozitoriyaya yükləyəcək. Daxili versiyaya nəzarət sistemi dəyişikliklərin və qurulmaların tarixini saxlayacaq. Qalan yalnız mənbələrinizi bu sistemə əlavə etməkdir. Hətta serveri özünüz qurmaq məcburiyyətində deyilsiniz; açıq serverdən istifadə edə bilərsiniz.
Bununla belə, bir problem var: belə kombaynları mövcud infrastruktura sığdırmaq çətindir. Məsələn, versiyaya nəzarət lazım deyil, mənbə kodları üçün artıq özümüz var. İmza mexanizmimiz fərqlidir: biz xüsusi serverdən istifadə edirik. Repozitoriya da lazım deyil.
Bundan əlavə, digər paylamalara dəstək - məsələn, Red Hat - kifayət qədər zəif həyata keçirilir, bu başa düşüləndir.
Belə bir xidmətin üstünlüyü SUSE paylanmasının növbəti versiyası üçün sürətli dəstəkdir. Buraxılış rəsmi elan edilməzdən əvvəl yığılmaq üçün lazım olan paketlər ictimai repozitoriyada yerləşdirilir. OpenBuildService-də mövcud paylamalar siyahısında yenisi görünür. Qutunu yoxlayırıq və tikinti planına əlavə olunur. Beləliklə, paylamanın yeni versiyasının əlavə edilməsi demək olar ki, bir kliklə həyata keçirilir.
OpenBuildService istifadə edərək infrastrukturumuzda SUSE paylamaları üçün veeamsnap nüvə modulunun bütün müxtəlif KMP paketləri yığılmışdır.
Sonra, nüvə modullarına xas olan məsələlər üzərində dayanmaq istərdim.
nüvə ABI
Linux nüvə modulları tarixən mənbə şəklində paylanmışdır. Fakt budur ki, nüvənin yaradıcıları nüvə modulları üçün sabit API-ni dəstəkləmək narahatlığı ilə yüklənmirlər və xüsusilə ikili səviyyədə, daha sonra kABI olaraq adlandırılır.
Vanil nüvəsi üçün modul qurmaq üçün mütləq bu xüsusi nüvənin başlıqlarına ehtiyacınız var və o, yalnız bu nüvədə işləyəcək.
DKMS, nüvəni yeniləyərkən modulların qurulması prosesini avtomatlaşdırmağa imkan verir. Nəticədə, Debian repozitoriyasının istifadəçiləri (və onun bir çox qohumları) ya distribyutorun deposundan, ya da DKMS-dən istifadə edərək mənbədən tərtib edilmiş kernel modullarından istifadə edirlər.
Bununla belə, bu vəziyyət Müəssisə seqmentinə xüsusilə uyğun gəlmir. Mülkiyyət kodu distribyutorları məhsulu tərtib edilmiş ikili fayllar kimi yaymaq istəyirlər.
İnzibatçılar təhlükəsizlik səbəbi ilə inkişaf alətlərini istehsal serverlərində saxlamaq istəmirlər. Red Hat və SUSE kimi Enterprise Linux distribyutorları öz istifadəçiləri üçün stabil kABI-ni dəstəkləyə biləcəklərinə qərar verdilər. Nəticə Red Hat üçün KMOD paketləri və SUSE üçün KMP paketləri oldu.
Bu həllin mahiyyəti olduqca sadədir. Yayımın xüsusi versiyası üçün kernel API dondurulur. Distribyutor bildirir ki, o, nüvədən istifadə edir, məsələn, 3.10 və yalnız kernel interfeyslərinə təsir etməyən düzəlişlər və təkmilləşdirmələr edir və ilk nüvə üçün toplanmış modullar bütün sonrakılar üçün yenidən tərtib edilmədən istifadə edilə bilər.
Red Hat, bütün ömrü boyu paylanması üçün kABI uyğunluğunu iddia edir. Yəni, rhel 6.0 (noyabr 2010-cu il buraxılışı) üçün yığılmış modul 6.10 versiyasında da işləməlidir (buraxılış iyun 2018). Və bu, demək olar ki, 8 ildir. Təbii ki, bu iş olduqca çətindir.
Biz veeamsnap modulunun kABI uyğunluğu problemlərinə görə işini dayandırdığı bir neçə hal qeydə almışıq.
RHEL 7.0 üçün tərtib edilmiş veeamsnap modulunun RHEL 7.5 nüvəsi ilə uyğunsuz olduğu ortaya çıxdı, lakin o, yükləndi və serverin çökməsinə zəmanət verildi, biz RHEL 7 üçün kABI uyğunluğunun istifadəsindən tamamilə imtina etdik.
Hal-hazırda, RHEL 7 üçün KMOD paketində hər buraxılış versiyası üçün montaj və modulu yükləyən skript var.
SUSE, kABI uyğunluğu vəzifəsinə daha diqqətlə yanaşdı. Onlar yalnız bir xidmət paketi daxilində kABI uyğunluğunu təmin edirlər.
Məsələn, SLES 12-nin buraxılışı 2014-cü ilin sentyabrında baş verdi. SLES 12 SP1 isə artıq 2015-ci ilin dekabrında idi, yəni bir ildən bir qədər çox vaxt keçdi. Hər iki buraxılış 3.12 nüvəsini istifadə etsə də, onlar kABI-yə uyğun gəlmir. Aydındır ki, kABI uyğunluğunu cəmi bir il saxlamaq daha asandır. Kernel modulunun illik yeniləmə dövrü modul yaradıcıları üçün problem yaratmamalıdır.
Bu SUSE siyasətinin nəticəsi olaraq, veeamsnap modulumuzda kABI uyğunluğu ilə bağlı heç bir problem qeydə almamışıq. Düzdür, SUSE üçün paketlərin sayı demək olar ki, daha böyükdür.
Yamalar və arxa portlar
Distribyutorlar kABI uyğunluğunu və nüvənin sabitliyini təmin etməyə çalışsalar da, həm də performansını yaxşılaşdırmağa və bu sabit nüvənin qüsurlarını aradan qaldırmağa çalışırlar.
Eyni zamanda, öz "səhvlər üzərində işləmək" ilə yanaşı, Linux kernel müəssisəsinin tərtibatçıları vanil nüvəsindəki dəyişiklikləri izləyir və onları "sabit" birinə köçürür.
Bəzən bu, yenilərinə gətirib çıxarır .
Red Hat 6-nın son buraxılışında kiçik yeniləmələrdən birində səhvə yol verildi. Bu, veeamsnap modulunun snapshot buraxıldığı zaman sistemin çökməsinə zəmanət verilməsinə səbəb oldu. Yeniləmədən əvvəl və sonra nüvə mənbələrini müqayisə etdikdən sonra arxa portun günahkar olduğunu bildik. Bənzər bir düzəliş vanil nüvəsinin 4.19 versiyasında edildi. Sadəcə olaraq, bu düzəliş vanil nüvəsində yaxşı işlədi, lakin onu "stabil" 2.6.32-ə köçürərkən spinlock ilə problem yarandı.
Təbii ki, hər kəsin həmişə səhvləri olur, amma sabitliyi riskə ataraq kodu 4.19-dan 2.6.32-yə çəkməyə dəyərdimi?.. Əmin deyiləm...
Ən pisi odur ki, marketinq “sabitlik” və “modernləşmə” arasında çəkişməyə qarışır. Marketinq departamentinin bir tərəfdən sabit olması, eyni zamanda performans baxımından daha yaxşı olması və yeni xüsusiyyətlərə malik olması üçün yenilənmiş paylamanın nüvəsinə ehtiyacı var. Bu, qəribə kompromislərə gətirib çıxarır.
SLES 4.4 SP12-dən nüvə 3-də modul qurmağa çalışarkən, orada vanil 4.8-dən funksionallıq tapdığım üçün təəccübləndim. Fikrimcə, SLES 4.4 SP12-dən 3 nüvəsinin blok giriş/çıxış tətbiqi SLES4.8 SP4.4-dən stabil 12 nüvənin əvvəlki buraxılışından daha çox 2 nüvəyə bənzəyir. SP4.8 üçün kernel 4.4-dən SLES 3-ə kodun neçə faizinin köçürüldüyünü mühakimə edə bilmirəm, lakin nüvəni eyni stabil 4.4 adlandıra bilmirəm.
Bunun ən xoşagəlməz cəhəti odur ki, müxtəlif ləpələrdə eyni dərəcədə yaxşı işləyəcək modul yazarkən siz artıq kernel versiyasına etibar edə bilməzsiniz. Bölməni də nəzərə almalısınız. Bəzən yeni funksionallıqla birlikdə görünən bir tərifdə iştirak edə biləcəyiniz yaxşıdır, lakin bu fürsət həmişə görünmür.
Nəticədə, kod qəribə şərti tərtib direktivləri ilə böyüyür.
Sənədləşdirilmiş kernel API-ni dəyişdirən yamaqlar da var.
Dağıtımla rastlaşdım 5.16 və bu nüvə versiyasında lookup_bdev çağırışının giriş parametrlərinin siyahısını dəyişdiyini görəndə çox təəccübləndim.
Onu bir araya gətirmək üçün makefile-a lookup_bdev funksiyasının maska parametrinin olub-olmadığını yoxlayan skript əlavə etməli oldum.
Kernel modullarının imzalanması
Amma gəlin paketlərin paylanması məsələsinə qayıdaq.
Stabil kABI-nin üstünlüklərindən biri nüvə modullarının ikili fayl kimi imzalana bilməsidir. Bu halda, tərtibatçı modulun təsadüfən zədələnmədiyinə və ya qəsdən dəyişdirilmədiyinə əmin ola bilər. Bunu modinfo əmri ilə yoxlaya bilərsiniz.
Red Hat və SUSE paylamaları modulun imzasını yoxlamağa və yalnız müvafiq sertifikat sistemdə qeydiyyatdan keçdikdə onu yükləməyə imkan verir. Sertifikat modulun imzalandığı açıq açardır. Ayrı bir paket kimi paylayırıq.
Burada problem ondadır ki, sertifikatlar ya nüvəyə daxil edilə bilər (distribyutorlar onlardan istifadə edirlər) və ya yardımçı proqramdan istifadə edərək EFI uçucu olmayan yaddaşa yazılmalıdırlar. mokutil. Utility mokutil Sertifikat quraşdırarkən o, sistemi yenidən yükləməyinizi tələb edir və hətta əməliyyat sisteminin nüvəsini yükləməzdən əvvəl inzibatçıdan yeni sertifikatın yüklənməsinə icazə verməsini təklif edir.
Beləliklə, sertifikat əlavə etmək sistemə fiziki administrator girişini tələb edir. Maşın buludda və ya sadəcə uzaq bir server otağında yerləşirsə və giriş yalnız şəbəkə vasitəsilə (məsələn, ssh vasitəsilə) olarsa, sertifikat əlavə etmək mümkün olmayacaq.
Virtual maşınlarda EFI
EFI-nin uzun müddətdir ki, demək olar ki, bütün anakart istehsalçıları tərəfindən dəstəklənməsinə baxmayaraq, bir sistem quraşdırarkən, idarəçi EFI ehtiyacı barədə düşünməyə bilər və onu söndürə bilər.
Bütün hipervizorlar EFI-ni dəstəkləmir. VMWare vSphere 5-ci versiyadan başlayaraq EFI-ni dəstəkləyir.
Microsoft Hyper-V, həmçinin Windows Server 2012R2 üçün Hyper-V-dən başlayaraq EFI dəstəyi qazandı.
Bununla belə, standart konfiqurasiyada bu funksiya Linux maşınları üçün qeyri-aktivdir, yəni sertifikat quraşdırıla bilməz.
vSphere 6.5-də seçimi təyin edin Təhlükəsiz Boot yalnız Flash vasitəsilə işləyən veb interfeysinin köhnə versiyasında mümkündür. HTML-5-də Web UI hələ də çox geridədir.
Eksperimental paylamalar
Və nəhayət, rəsmi dəstək olmadan eksperimental paylamalar və paylamalar məsələsini nəzərdən keçirək. Bir tərəfdən, ciddi təşkilatların serverlərində belə paylamalara rast gəlmək mümkün deyil. Bu cür paylamalar üçün rəsmi dəstək yoxdur. Ona görə də bunları təmin edin. Məhsul belə bir paylamada dəstəklənə bilməz.
Bununla belə, bu cür paylamalar yeni eksperimental həlləri sınamaq üçün əlverişli platformaya çevrilir. Məsələn, Fedora, OpenSUSE Tumbleweed və ya Debian-ın Qeyri-sabit versiyaları. Onlar kifayət qədər sabitdirlər. Onların həmişə proqramların yeni versiyaları və həmişə yeni nüvəsi olur. Bir ildən sonra bu eksperimental funksionallıq yenilənmiş RHEL, SLES və ya Ubuntu ilə başa çata bilər.
Beləliklə, bir şey eksperimental paylamada işləmirsə, bu problemi anlamaq və həll etmək üçün bir səbəbdir. Bu funksiyanın tezliklə istifadəçilərin istehsal serverlərində görünəcəyinə hazır olmalısınız.
Siz 3.0 versiyası üçün rəsmi dəstəklənən paylamaların cari siyahısını öyrənə bilərsiniz . Lakin məhsulumuzun işləyə biləcəyi paylamaların real siyahısı daha genişdir.
Şəxsən mən Elbrus OS ilə təcrübə ilə maraqlandım. veeam paketini tamamladıqdan sonra məhsulumuz quraşdırıldı və işlək oldu. Bu təcrübə haqqında Habré-də yazdım .
Yaxşı, yeni paylamalara dəstək davam edir. 4.0 versiyasının buraxılmasını gözləyirik. Beta görünmək üzrədir, ona görə də diqqətli olun !
Mənbə: www.habr.com