Krijimi i një aplikacioni për backup që funksionon në çdo distribucion është një sfidë e vështirë. Për të garantuar funksionimin e Veeam Agent për Linux në distribucionet nga Red Hat 6 dhe Debian 6, deri në OpenSUSE 15.1 dhe Ubuntu 19.04, duhet të zgjidhen një sërë problemesh, sidomos duke pasur parasysh se produkti përmban një moduli të bërthamës.
Artikulli është krijuar sipas materialeve të prezantimit në konferencën .
Linux-i nuk është vetëm një nga sistemet operative më të njohura. Në thelb, është një platformë mbi të cilën mund të krijoni diçka unike, diçka tuajën. Falë kësaj, Linux ka shumë distribuime që dallohen për nga grupi i komponenteve programore. Dhe këtu lind problemi: për të siguruar që produkti programor të funksionojë në çdo distribucion, është e nevojshme të merren në konsideratë veçoritë e secilit.
Menaxherët e paketave. .deb vs .rpm
Le të fillojmë me problemin e dukshëm të përhapjes së produktit për distribuime të ndryshme.
Mënyra më tipike e shpërndarjes së produkteve programore është të ngarkohet një paketë në një depo, në mënyrë që menaxheri i paketave e ndërtuar në sistem të mund ta instaloje atë nga aty.
Megjithatë, formatet e njohura të paketave janë dy: rpm dhe deb. Kështu, do të duhet të mbështetet çdo një.
Në botën e paketave deb, niveli i përputhshmërisë është mbresëlënëse. I njëjti paketë instalohet dhe funksionon po njësoj mirë si në Debian 6 ashtu edhe në Ubuntu 19.04. Standardet e procesit të ndërtimit të paketimeve dhe punës me to, të vendosura në distribuime të vjetra Debian, mbeten aktuale edhe në distribucionet më moderne si Linux Mint dhe elementary OS. Prandaj, për Veeam Agent për Linux, mjafton një paketë deb për çdo platformë harduerike.
Ndërsa në botën e paketave rpm, dallimet janë të mëdha. Së pari, për shkak se ekzistojnë dy distributora krejtësisht të pavarur, Red Hat dhe SUSE, për të cilët nuk nevojitet përputhshmëri. Së dyti, këta distributora kanë distribuime me mbështetje teknike dhe eksperimentale. Midis tyre, përputhshmëria gjithashtu nuk është e nevojshme. Kemi përfunduar se për el6, el7 dhe el8 ka paketat e veta. Një paketë e veçantë për Fedora. Paketat për SLES11 dhe 12 dhe një e veçantë për openSUSE. Problemi kryesor është në varësitë dhe emrat e paketave.
Problemi i varësive
Për fat të keq, shumë herë paketat e njëjta shfaqen me emra të ndryshëm në distribuime të ndryshme. Më poshtë është një listë e pakët e varësive të paketës veeam.
Për EL7:
Për SLES 12:
- libblkid
- libgcc
- libstdc++
- ncurses-libs
- fuse-libs
- file-libs
- veeamsnap = 3.0.2.1185
- libblkid1
- libgcc_s1
- libstdc++6
- libmagic1
- libfuse2
- veeamsnap-kmp = 3.0.2.1185
Si pasojë, lista e varësive rezulton të jetë unik për shpërndarjen.
Ka raste kur një version i ri i përditësuar fshihet pas emrit të vjetër të paketës.
Shembulli:
Në Fedora 24, paketa u përditësua ncurses nga versioni 5 në versionin 6. Produkti ynë është ndërtuar pikërisht me versionin 5, për të siguruar përputhshmëri me shpërndarjet më të vjetra. Për të përdorur versionin e vjetër 5 të bibliotekës në Fedora 24, duhej të përdorej paketa ncurses-compat-libs.
Si pasojë, për Fedora shfaqen dy paketa, me varësi të ndryshme.
Më pas bëhet më interesante. Pas përditësimit të fundit të shpërndarjes, paketa ncurses-compat-libs me versionin 5 të bibliotekës nuk është e dispozueshme. Për distributorin është një ngarkesë për të sjellë bibliotekat e vjetra në versionin e ri të shpërndarjes. Pas një kohe, problemi u përsërit edhe në shpërndarjet SUSE.
Si pasojë, për disa shpërndarje duhej të heqeshim dorë nga varësia e qartë nga ncurses-libs, dhe produkti u përmirësua në mënyrë që të funksiononte me çdo version të bibliotekës.
Për më tepër, në versionin 8 të Red Hat nuk ka më paketën meta python, e cila referohej në të vjetrin e mirë python 2.7. Ka python2 dhe python3.
Alternativa për menaxherët e pakot
Problemi me varësitë është i vjetër dhe prej kohësh i dukshëm. Kujtojmë pak nga concepti Dependency hell.
Të bashkosh bibliotekat dhe aplikacionet në një mënyrë që të gjitha të funksionojnë qëndrojnë pa probleme dhe pa konflikt – kjo është detyra që çdo distributor Linux përpiqet ta zgjidhë.
Tejet ndryshe e trajton këtë problem menaxheri i pakove Snappy i Canonical. Ideja kryesore: aplikacioni ekzekutohet në një rërë të izoluar dhe të mbrojtur nga sistemi kryesor. Nëse aplikacionit i nevojiten biblioteka, ato ofrohen së bashku me vetë aplikacionin.
Flatpak po ashtu lejon ekzekutimin e aplikacioneve në rërë duke përdorur Linux Containers. Ideja e rërës përdoret gjithashtu nga AppImage.
Këto zgjidhje lejojnë krijimin e një pakete për çdo shpërndarje. Në rastin me Flatpak instalimi dhe ekzekutimi i aplikacionit është i mundur edhe pa dijen e administratorit.
Problemi kryesor është që jo të gjitha aplikacionet mund të funksionojnë në rërë. Disa kanë nevojë për qasje direkte në platformë. Nuk flas për modulet e kernelit, të cilat janë ngushtësisht të lidhura me kernelin dhe nuk përshtaten në konceptin e rërës.
Problemi i dytë – shpërndarjet e njohura në mjedisin enterprise nga Red Hat dhe SUSE ende nuk përmbajnë mbështetje për Snappy dhe Flatpak.
Për këtë arsye, Veeam Agent for Linux nuk është as në asnjë .
Në përfundim të çështjes për menaxherët e paketeve, dua të theksoj se ekziston një mundësi për t'u hequr plotësisht nga menaxherët e paketeve, duke kombinuar në një paketë skedarët binarë dhe skriptet për instalimin e tyre.
Një bundle i tillë lejon krijimin e një pakete të vetme për distribucione dhe placa të ndryshme, duke ofruar një proces interaktiv instalimi me përshtatje të nevojshme. Kam hasur në këto paketa për Linux vetëm nga VMware.
Problemi i azhurnimeve
Edhe nëse të gjitha problemet me varësitë janë zgjidhur, programi mund të funksionojë ndryshe në të njëjtin shpërndarje. Problemi qëndron te azhurnimet.
Ka 3 strategji azhurnimi:
- Strategjia më e thjeshtë – të mos azhurnosh kurrë. E ke konfiguruar serverin dhe harrove. Pse azhurnimet, nëse gjithçka funksionon? Problemet fillojnë sapo bëhet një thirrje në shërbimin e mbështetjes. Krijuesi i shpërndarjes mbështet vetëm versionin e azhurnuar.
- Mund të besosh shpërndarësin dhe të konfigurosh azhurnim automatik. Në këtë rast, një telefonatë në shërbimin e mbështetjes është e mundur menjëherë pas një azhurnimi të dështuar.
- Mundësia e azhurnimit manual vetëm pas provave në infrastrukturën testuese – është më e sigurt, por e kushtueshme dhe e punës shumë. Larg të gjithëve është e mundur ta përballojnë atë.
Përsaqë përdorues të ndryshëm aplikojnë strategji të ndryshme azhurnimi, është e nevojshme të mbështeten si versioni më i ri, ashtu edhe të gjitha versionet e lëshuara më parë. Kjo e komplikon procesin e zhvillimit dhe testimit, duke shtuar dhimbje koke për shërbimin e mbështetjes.
Larmia e platformave harduerike
Platforma të ndryshme harduerike – kjo është një problem, për shumë arsye specifik për kodin native. Të paktën, duhet të mblidhen binarë për çdo platformë të mbështetur.
Në projektin Veeam Agent for Linux ne ende nuk mund të mbështesim ndonjë gjë të tillë RISC-ove.
Nuk do të ndalem në këtë çështje. Do të theksoj vetëm problemet kryesore: llojet e varura nga platforma, siç janë size_t, përputhshmëria e strukturave dhe rendi i byte.
Lidhja statike dhe/apo dinamike
Por pyetja "Si të lidhen me bibliotekat - dinamike ose statike?" meritojnë të diskutohet.
Në pergjithësi, aplikacionet C/C++ për Linux përdorin lidhje dinamike. Kjo funksionon shkëlqyeshëm nëse aplikacioni mbledh për specificisht për një shpërndarje të veçantë.
Nëse qëllimi është të mbulohet një gamë e ndryshme distributionsh me një skedar binar, atëherë duhet të përqendrohemi në distribution-in më të vogël të mbështetur. Për ne, kjo është Red Hat 6. Ai përmban gcc 4.4, i cili nuk e mbështet as standardin C++11. .
Ne e ndërtojmë projektin tonë me gcc 6.3, i cili mbështet plotësisht C++14. Natyrisht, në këtë rast, në Red Hat 6 na duhet të sjellim bibliotekën libstdc++ dhe boost bashkë. Më e lehtë është të lidhemi me to në mënyrë statike.
Por fatkeqësisht, jo me të gjitha bibliotekat mund të lidhemi në mënyrë statike.
Së pari, biblioteka sistemore, të tilla si libfuse, libblkid duhet të lidhen në mënyrë dinamike, për t'u siguruar në përputhshmëri me bërthamën dhe modulet e saj.
Së dyti, ka një nuancë me licencat.
Licenca GPL në parim lejon lidhjen e bibliotekave vetëm me kod opensource. MIT dhe BSD lejojnë lidhjen statike dhe lejojnë përfshirjen e bibliotekave në projekt. Ndërsa LGPL, duket se nuk e kundërshton lidhjen statike, por kërkon që të ofrohen në akses të përgjithshëm skedarët e nevojshëm për lidhjen.
Në përgjithësi, përdorimi i lidhjes dinamike do të sigurojë nga nevoja për të ofruar diçka.
Ndërtimi i aplikacioneve C/C++
Për ndërtimin e aplikacioneve C/C++ për platforma dhe distributionsh të ndryshme, mjafton të zgjedhim ose të ndërtuam gcc-në e duhur dhe të përdorim cross-compilers për arkitekturën specifike, si dhe të ndërtosh të gjithë setin e bibliotekave. Ky proces është i realizueshëm, por mjaft i lodhshëm. Dhe nuk ka asnjë garanci që kompiliatori dhe bibliotekat e zgjedhura do t'u ofrojnë një variant funksional.
Një përparësi e dukshme: infrastruktura thjeshtohet ndjeshëm, pasi i gjithë procesi i ndërtimit mund të kryhet në një makinë të vetme. Për më tepër, mjafton të ndërtojmë një grup skedash binarësh për një arkitekturë dhe mund t'i paketojmë në paketat për distributionsh të ndryshme. Kështu krijohen paketat veeam për Veeam Agent for Linux.
Në vend të këtij varianti, mund të përgatisim një fermë ndërtimi, që do të thotë disa makina për ndërtim. Çdo makinë e tillë do të sigurojë kompaktimin e aplikacionit dhe ndërtimin e paketës për një shpërndarje të caktuar dhe një arkitekturë të veçantë. Në këtë rast, kompaktimi kryhet me mjetet që përgatiti shpërndarësi. Kështu, faza e përgatitjes së kompjuterit dhe përzgjedhjes së bibliotekave hiqet. Për më tepër, procesi i ndërtimit mund të shpërndahet lehtësisht.
Megjithatë, ka një disavantazh të këtij qasjeje: për çdo shpërndarje brenda një arkitekture do të duhet të ndërtohet një grup i veçantë skedarësh binarë. Një disavantazh tjetër është se një numër kaq i madh makinash duhet të mbikqyret, duke alokuar një sasi të madhe hapësire disku dhe memories operative.
Kështu ndërtohen pakot KMOD të modulit të bërthamës veeamsnap për shpërndarjet Red Hat.
Open Build Service
Kolegët nga SUSE përpoqën të realizojnë një mesatare të artë në formën e një shërbimi të veçantë për kompaktimin e aplikacioneve dhe ndërtimin e pakove — .
Në thelb, ky është një hipervizor që krijon një makinë virtuale, instalon në të të gjithë paketat e nevojshme, kryen kompaktimin e aplikacionit dhe ndërtimin e paketës në këtë mjedis të izoluar, pas së cilës kjo makinë virtuale lirohet.
Planifikuesi i realizuar në OpenBuildService vetë do të përcaktojë se sa makina virtuale mund të fillojë për shpejtësinë optimale të ndërtimit të pakove. Mekanizmi i ndërtuar për nënshkrim do të nënshkruajë vetë paketat dhe do t’i ngarkojë ato në depozitat e integruara. Sistemi i ndërtuar i kontrollit të versioneve do të ruajë historikun e ndryshimeve dhe ndërtimit. Ngelen vetëm t'i shtosh këtij sistemi burimet e tua. Nuk është e nevojshme të ngre një server vetë, por mund të shfrytëzosh atë të hapur.
Megjithatë, këtu ka një problem: një makinë e tillë është e vështirë të integrohet në infrastrukturën ekzistuese. Për shembull, kontrolli i versioneve nuk është i nevojshëm, ne tashmë kemi tonin për burimet. Mekanizmi i nënshkrimit është ndryshe: përdoret një server i veçantë. Depozita gjithashtu nuk është e nevojshme.
Përveç kësaj, mbështetja për shpërndarje të tjera — për shembull, Red Hat — është realizuar mjaft dobët, gjë që është plotësisht e kuptueshme.
Pikë e fortë e këtij shërbimi është suporti i shpejtë për versionin e radhës të distribucionit SUSE. Para shpalljes zyrtare të lëshimit, paketat e nevojshme për ndërtim publikohen në depo të hapura. Një e re shfaqet në listën e distribucioneve të disponueshme në OpenBuildService. Vendosim shenjën dhe ajo shtohet në planin e ndërtimit. Kështu, shtimi i një versioni të ri të distribucionit kryhet praktikisht me një klik të vetëm.
Në infrastrukturën tonë, duke përdorur OpenBuildService, ndërtohet tërë varianti i paketave KMP për modulën e bërthamës veeamsnap për distribucionet SUSE.
Tani do të doja të ndalesha te çështjet që janë specifike për modulet e bërthamës.
kernel ABI
Modulet e bërthamës Linux historikisht shpërndaheshin në formën e teksteve të burimit. Kjo është për shkak se krijuesit e bërthamës nuk e shqetësojnë veten me përkushtimin për të mbështetur një API të qëndrueshëm për modulet e bërthamës, e aq më pak në nivelin binar, që quhet kABI.
Për të ndërtuar një modul për bërthamën vanilje, nevojiten patjetër header-a të kësaj bërthame, dhe ai do të funksionojë vetëm në këtë bërthamë.
DKMS lejon automatizimin e procesit të ndërtimit të moduleve gjatë përditësimit të bërthamës. Si rezultat, përdoruesit e depozitës Debian (dhe të afërm të saj) përdorin modulet e bërthamës ose nga depoja e distribuesit, ose të ndërtuara nga burimet me ndihmën e DKMS.
Megjithatë, kjo situatë nuk e kënaq shumë segmentin Enterprise. Shpërndarësit e kodit proprietar dëshirojnë të shpërndajnë produktin në formën e binarëve të ndërtuar.
Administruesit nuk duan të mbajnë mjete zhvillimi në serverat e prodhimit për arsye sigurie. Distribuesit e Enterprise Linux — si Red Hat dhe SUSE — kanë vendosur se për përdoruesit e tyre, ata do të mbështesin një kABI të qëndrueshëm. Si rezultat, janë shfaqur paketat KMOD për Red Hat dhe paketat KMP për SUSE.
Thelbi i këtij zgjidhjeje është mjaft i thjeshtë. Për një version të caktuar të distribucionit, API i bërthamës ngrihet. Distribuesi shpall se po përdor vetë bërthamën, për shembull, 3.10, dhe bën vetëm rregullime dhe përmirësime që nuk prekin ndonjë mënyrë interface-t e bërthamës, dhe modulet e ndërtuara për bërthamën e parë mund të përdoren për të gjitha ato të mëvonshme pa i ripunuar.
Red Hat deklaron se mbështetja për kABI do të jetë e disponueshme për shpërndarjen gjatë gjithë ciklit të jetës. Kjo do të thotë se moduli i ndërtuar për rhel 6.0 (lëshimi në nëntor 2010) duhet të funksionojë gjithashtu edhe në versionin 6.10 (lëshimi në qershor 2018). Kjo është pothuajse 8 vjet. Natyrisht, ky është një detyrë mjaft e komplikuar.
Ne kemi regjistruar disa raste kur për shkak të problemeve me përputhshmërinë e kABI, moduli veeamsnap ka ndaluar së funksionuari.
Pas këtij rasti, moduli veeamsnap, i ndërtuar për RHEL 7.0, rezultoi se nuk ishte i përputhshëm me kernën nga RHEL 7.5, por megjithatë ngarkohej dhe garantonte rënien e serverit, ne u tërhoqëm nga përdorimi i përputhshmërisë së kABI për RHEL 7 në përgjithësi.
Aktualisht, paketa KMOD për RHEL 7 përmban një ndërtim për çdo version të lëshimit dhe një skript që garanton ngarkimin e modulit.
SUSE iu qas detyrës së përputhshmërisë së kABI më me kujdes. Ata ofrojnë përputhshmëri të kABI vetëm brenda një pakete shërbimi.
Për shembull, lëshimi SLES 12 u bë në nëntor 2014. Ndërsa SLES 12 SP1 u publikua në dhjetor 2015, që do të thotë se kaloi pak më shumë se një vit. Megjithëse të dy lëshimet përdorin kernin 3.12, ato janë të papërputhshme me kABI. Është e qartë se mbështetja e përputhshmërisë së kABI vetëm për një vit është dukshëm më e lehtë. Cikli vjetor i përditësimit të modulit të kernit nuk duhet të shkaktojë probleme për krijuesit e moduleve.
Si rezultat i kësaj politike të SUSE, ne nuk kemi regjistruar ndonjë problem me përputhshmërinë e kABI për modulin tonë veeamsnap. Megjithatë, numri i paketave për SUSE është pothuajse një rend më i lartë.
Patch-e dhe bckport-e
Megjithëse shpërndarësit përpiqen të ofrojnë përputhshmëri të kABI dhe stabilitet të kernit, ata gjithashtu përpiqen të përmirësojnë performancën dhe të eliminojnë defektet e këtij kerni stabil.
Po ashtu, përveç "punës mbi gabimet" vetjake, zhvilluesit e kernit enterprise linux ndjekin ndryshimet në kernin vanilla dhe i переносin ato në "stabilin" e tyre.
Ndonjëherë kjo shkakton gabime të reja. .
Në lëshimin më të fundit të Red Hat 6, një nga përditësimet më të vogla kishte një defekt. Kjo çoi në atë që moduli veeamsnap garantonte rënien e sistemit gjatë çlirimit të snapshot-it. Duke krahasuar burimet e kernit para dhe pas përditësimit, ne zbuluam se problemin e shkaktonte backport-i. Një korrektim i ngjashëm u bë në kernin vanilla version 4.19. Megjithatë, në kernin vanilla ky korrektim funksionoi siç duhet, por gjatë transferimit në "stabilin" 2.6.32 u shfaq një problem me bllokimin e spin.
Sigurisht, gabimet ndodhin te gjithëve dhe gjithmonë, por a kishte vlerë të tërhiqnim kodin nga 4.19 në 2.6.32, duke rrezikuar stabilitetin?.. Nuk jam i sigurt...
Më e keqja është se kur marketingu lidhet me tërheqjen e litarit "stabilitet" "modernizim". Departamenti i marketingut ka nevojë që bërthama e distribucionit të përditësuar të jetë e stabilizuar, nga njëra anë, dhe në të njëjtën kohë të ketë performancë më të mirë dhe funksione të reja. Kjo çon në kompromise të çuditshme.
Kur provova të ndërtoja një modul në bërthamën 4.4 të SLES 12 SP3, u befasova kur zbulova funksionalitetin nga bërthama e zakonshme 4.8. Sipas mendimit tim, realizimi i hyrjes/shtypjes bllok është shumë më i afërt me bërthamën 4.8, sesa me lëshimin e mëparshëm të stabilizuar 4.4 nga SLES 12 SP2. Nuk guxoj të gjykoj se cila ishte përqindja e kodit të transferuar nga bërthama 4.8 në SLES-in 4.4 për SP3, megjithatë, nuk mund ta quaj bërthamën ende si 4.4 të stabilizuar.
Më e pakëndshme është se kur krijoni një modul që funksionon njësoj mirë në bërthama të ndryshme, nuk mund të mbështeteni më në versionin e bërthamës. Duhet të merrni parasysh edhe distribucionin. Fatmirësisht, ndonjëherë mund të lidhni një definicion që shfaqet në të njëjtën kohë me funksionalitetin e ri, por kjo mundësi nuk shfaqet gjithmonë.
Si rezultat, kodi mbushet me direktiva të çuditshme të kompilimit të kushteve.
Takohen edhe patch-e që ndryshojnë API-në e dokumentuar të bërthamës.
Natyra e distribucionit 5.16 dhe u befasova shumë që thirrja lookup_bdev në këtë version bërthame ndryshoi listën e parametrave hyrës.
Për t'u ndërtuar, më duhej të shtoja në makefile një skenar që kontrollonte nëse ekzistonte parametri mask tek funksioni lookup_bdev.
Nënshkrimi i moduleve të bërthames
Por le të kthehemi te çështja e shpërndarjes së pakove.
Një nga përfitimet kryesore të kABI të stabilizuar është se modulet e bërthames në formë skedari binar mund të nënshkruhen. Në këtë rast, zhvilluesi mund të jetë i sigurt që moduli nuk është dëmtuar rastësisht ose ndryshuar qëllimisht. Këtë mund ta kontrolloni me komandën modinfo.
Distribucionet Red Hat dhe SUSE lejojnë kontrollin e nënshkrimit të modulit dhe ngarkimin e tij vetëm nëse në sistem është regjistruar certifikata përkatëse. Certifikata përbëhet nga një çelës publik, i cili nënshkruan modulit. Ne e shpërndajmë atë në formën e një pakete të veçantë.
Problemi këtu është se certifikatat mund të jenë ose të integruara në bërthamë (ato përdoren nga distributorët), ose duhet të shkruhen në memorie jo fragile EFI me anë të një utilitari. mokutil. Vegla mokutil kur instaloni certifikatën kërkon që të riblokuhet sistemi dhe madje para se të ngarkohet bërthama e sistemit operativ ofron administratorit mundësinë për të lejuar ngarkimin e një certifikate të re.
Pra, shtimi i certifikatës kërkon qasje fizike të administratorit në sistem. Nëse makineria ndodhet diku në cloud ose thjesht në një server të largët dhe qasja bëhet vetëm përmes rrjetit (p.sh., përmes ssh), atëherë do të jetë e pamundur të shtoni certifikatën.
EFI në makinat virtuale
Megjithëse EFI është mbështetur për një kohë të gjatë nga shumica e krijuesve të pllakave të nënëmërtesës, gjatë instalimit të sistemit, administratori mund të mos e ketë menduar nevojën për EFI, dhe ai mund të jetë çaktivizuar.
Nuk të gjithë hipervizorët mbështesin EFI. VMWare vSphere mbështet EFI që nga versioni 5.
Microsoft Hyper-V gjithashtu ka marrë mbështetje për EFI, që nga Hyper-V për Windows Server 2012R2.
Megjithatë, në konfigurimin e defolt, kjo funksionalitet për makinat Linux është çaktivizuar, kështu që nuk është e mundur të instalohet certifikata.
Në vSphere 6.5, mund të caktoni opsionin Secure Boot vetëm në versionin e vjetër të ndërfaqes për internet, e cila funksionon përmes Flash. UI në HTML-5 për momentin është shumë mbrapa.
Distribucione eksperimentale
Dhe për fund, le të shqyrtojmë çështjen e distribucioneve eksperimentale dhe atyre që nuk kanë mbështetje zyrtare. Nga një anë, është e vështirë të hasim në këto distribucione në serverët e organizatave serioze. Nuk ka mbështetje zyrtare për këto distribucione. Prandaj, nuk është e mundur të ofrohet mbështetje teknike për produktin në një distribucion të tillë.
Megjithatë, këto distribucione bëhen një platformë e përshtatshme për të provuar zgjidhje të reja eksperimentale. Për shembull, Fedora, OpenSUSE Tumbleweed ose versionet e Pamundura të Debian. Ato janë mjaft stabile. Në to gjithmonë ka versione të reja të programeve dhe gjithmonë një bërthamë të re. Pas një viti, ky funksionalitet eksperimental mund të përfshihet në RHEL, SLES ose Ubuntu të azhurnuar.
Pra, nëse diçka nuk funksionon në një distribucion eksperimental - kjo është një arsyetim për të kuptuar problemin dhe për ta zgjidhur. Duhet të jeni të gatshëm që ky funksionalitet shpejt do të shfaqet në serverët e prodhimit të përdoruesve.
Lista aktuale e distribucioneve të mbështetura zyrtarisht për versionin 3.0 mund ta shikoni . Por lista reale e distribucioneve në të cilat produkti ynë është i aftë të punojë është shumë më e gjerë.
Më interesonte eksperimenti me OS «Elbrus». Pas përmirësimit të paketës Veeam, produkti ynë u instalua dhe punoi. Për këtë eksperimento kam shkruar në Habr në .
Ndërkohë, mbështetja për distribucionet e reja vazhdon. Priten versioni 4.0. Po shfaqet një beta, kështu që mbajini sytë nga !
Burimi: habr.com
