Krijimi i një aplikacioni për backup që funksionon në çdo distribucion është një detyrë e vështirë. Për të siguruar funksionimin e Veeam Agent për Linux në distribucione nga Red Hat 6 dhe Debian 6 deri në OpenSUSE 15.1 dhe Ubuntu 19.04, duhet të zgjidhen një sërë problemesh, veçanërisht nëse merret parasysh se produkti përfshin një modul bërthamor.
Artikulli është krijuar sipas materialeve të prezantimit në konferencë .
Linux nuk është vetëm një nga sistemet operative më të njohura. Në thelb, ajo është një platformë mbi të cilën mund të krijoni diçka unike, diçka tuajën. Falë kësaj, Linux ka shumë distribucione që dallohen nga grupi i komponenteve softuerike. Dhe këtu shfaqet një problem: për të siguruar që produkti të funksionojë në çdo distribucion, duhet të merret parasysh veçoritë e secilit.
Menaxherët e paketave. .deb vs .rpm
Le të fillojmë me problemin e dukshëm të shpërndarjes së produktit për distribucione të ndryshme.
Mënyra më tipike e shpërndarjes së produkteve softuerike është të ngarkohet një paketë në repository, në mënyrë që menaxheri i paketave i përfshirë në sistem të mund ta instalojë atë nga aty.
Megjithatë, formatet popullore të paketave që kemi janë dy: rpm dhe deb. Pra, do të duhet të mbështesim secilin.
Në botën e pakove deb, niveli i kompatibilitetit është mbresëlënës. E njëjta paketë funksionon po aq mirë si në Debian 6 ashtu edhe në Ubuntu 19.04. Standardet e procesit të ndërtimit të pakove dhe punës me to, të vendosura në distribucionet e vjetra të Debian, mbeten të vlefshme edhe në Linux Mint dhe elementary OS. Prandaj, për Veeam Agent for Linux mjafton një deb-paketë për secilën platformë harduerike.
Ndërkohë, në botën e pakove rpm, ndryshimet janë të mëdha. Së pari, për shkak se ekzistojnë dy distribues krejtësisht të pavarur, Red Hat dhe SUSE, për të cilët nuk nevojitet aspak kompatibiliteti. Së dyti, këta distribues kanë distribucione me mbështetje teknike dhe eksperimentale. Midis tyre, gjithashtu nuk është e nevojshme të ketë kompatibilitet. Ne kemi arritur që për el6, el7 dhe el8 të kemi paketa të veçanta. Një paketë veçmas për Fedora. Paketa për SLES11 dhe 12 dhe një e veçantë për openSUSE. Problemi kryesor është në varësitë dhe emrat e pakove.
Problemi i varësive
Fatkeqësisht, të njëjtat paketa shpesh ndodhen me emra të ndryshëm në distribucionet e ndryshme. Më poshtë është një listë jo të plotë 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 rezultat, lista e varësive rezulton e veçantë për distribucionin.
Në raste më të këqija, një version i ri fshihet pas emrit të vjetër të paketës.
Shembuj:
Në Fedora 24, paketa u përmirësua ncurses nga versioni 5 në versionin 6. Produkti ynë u ndërtua pikërisht me versionin e 5-të, për të siguruar përputhshmërinë me distribucionet e vjetra. Për të përdorur versionin e vjetër të 5-të të bibliotekës në Fedora 24, duhej të përdorej paketa ncurses-compat-libs.
Si rezultat, për Fedora shfaqen dy paketa, me varësi të ndryshme.
Më pas bëhet më interesante. Pas një azhurnimi tjetër të distribucionit, paketa ncurses-compat-libs me versionin e 5-të të bibliotekës bëhet e paaksesueshme. Për distribuitorin, është e kushtueshme të ruajë bibliotekat e vjetra në versionin e ri të distribucionit. Pas disa kohësh, problemi u përsërit edhe në distribucionet SUSE.
Si rezultat, për disa distribucione duhej të hiqej varësia e drejtpërdrejtë nga ncurses-libs, dhe produkti të përmirësohej në mënyrë që të funksiononte me çdo version të bibliotekës.
Kujdes, në versionin 8 të Red Hat nuk ka më meta-paketën python, e cila i referohej të vjetër i mirë python 2.7. Ekziston python2 dhe python3.
Alternativa për menaxherët e paketave
Problemi me varësitë është i vjetër dhe i njohur. Mjafton të kujtojmë 'Dependency hell'.
Të kombinojnë biblioteka dhe aplikacione të ndryshme në mënyrë që të funksionojnë stabilisht dhe pa konflikte — pozita e kësaj detyre përpiqet të zgjidhë çdo shpërndarës Linux.
Ndryshe e trajton këtë problem menaxheri i paketave Snappy nga Canonical. Ideja kryesore: aplikacioni ekzekutohet në një sandbox të izoluar dhe të mbrojtur nga sistemi kryesor. Nëse aplikacionit i nevojiten biblioteka, ato vijnë së bashku me aplikacionin.
Flatpak po ashtu lejon ekzekutimin e aplikacioneve në sandbbox duke përdorur Linux Containers. Ideja e sandbbox-it përdoret gjithashtu nga AppImage.
Këto zgjidhje lejojnë krijimin e një pakete për çdo shpërndarje. Në rastin e Flatpak instalimi dhe ekzekutimi i aplikacionit është e mundur edhe pa dijen e administratorit.
Problemi kryesor është se jo të gjitha aplikacionet mund të punojnë në sandbbox. Disa kanë nevojë për qasje të drejtpërdrejtë në platformë. Nuk po flas për modulet e bërthamës, të cilat varen drejtpërdrejt nga bërthama dhe nuk integrohen në konceptin e sandbbox-it.
Problemi i dytë është se distribucionet popullore në ambientin 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 ndodhet as në as në .
Në përfundim të çështjes për menaxherët e paketave, do të theksoj se ka një mundësi për të hequr dorë krejtësisht nga menaxherët e paketave, duke bashkuar në një paketë skedarët binarë dhe skriptin për instalimin e tyre.
Një bundle e tillë lejon krijimin e një pakete të vetme për distribucionet dhe platformat e ndryshme, duke realizuar një proces interaktiv instalimi duke bërë personalizimin e nevojshëm. Kam hasur në këto paketa për Linux vetëm nga VMware.
Problemi i përditësimeve
Madje nëse të gjitha problemet me varësitë zgjidhen, programi mund të funksionojë ndryshe në të njëjtin sistem distribucioni. Kjo ndodh për shkak të përditësimeve.
Ekzistojnë 3 strategji për përditësimin:
- E th simplest – kurrë mos përditëso. E konfigurove serverin dhe e harrove. Pse përditësime, nëse gjithçka funksionon? Problemet fillojnë me kontaktin e parë në shërbimin e mbështetjes. Krijuesi i distribucionit mbështet vetëm versionin e përditësuar.
- Mund të besoni distributorin dhe të konfiguroni përditësimin automatike. Në këtë rast, telefonata në shërbimin e mbështetjes është e mundshme menjëherë pas një përditësimi të dështuar.
- Opsioni i përditësimit manual pas provës në infrastrukturën testuese është më i sigurt, por i shtrenjtë dhe kërkon shumë punë. Jo të gjitha mund ta lejojnë veten.
Dukeqë përdorues të ndryshëm përdorin strategji të ndryshme për përditësimin, duhet të mbështetet si versioni më i ri, ashtu edhe të gjitha versionet e mëparshme të lëshuara. Kjo komplikon procesin e zhvillimit dhe testimit, duke shtuar dhimbje koke për shërbimin e mbështetjes.
Diferenca e platformave harduerike
Platformat e ndryshme harduerike janë një problem, kryesisht i veçantë për kodin native. Të paktën, duhet të grumbullohen binarët për çdo platformë të mbështetur.
Në projektin Veeam Agent për Linux ende nuk mund të mbështesim asgjë të tillë si RISC.
Nuk do të ndalem në këtë çështje në detaje. Do të theksoj vetëm problemet kryesore: llojet e varura nga platforma, si size_t, përputhja e strukturave dhe rendi i bajtave.
Lidhja statike dhe/apo dinamike
Poroshtja "Si të lidhemi me bibliotekat - në mënyrë dinamike apo statike?" ia vlen të diskutohet.
Si rregull, aplikacionet C/C++ nën Linux përdorin lidhjen dinamike. Kjo funksionon mirë nëse aplikacioni është ndërtuar posaçërisht për një distribucion të caktuar.
Nëse qëllimi është të përfshihet një gamë e gjerë distribuimesh me një skedar binar, atëherë duhet të fokusohemi në distribucionin më të vjetër të mbështetur. Për ne, ky është Red Hat 6. Ai përmban gcc 4.4, i cili as nuk mbështet standardin C++11. .
Ne e ndërtojmë projektin tonë me gcc 6.3, i cili mbështet plotësisht C++14. Natyrisht, në një rast të tillë, për Red Hat 6 duhet të sjellim bibliotekën libstdc++ dhe boost me vete. Më e thjeshta është të lidhemi me to në mënyrë statike.
Por fatkeqësisht, jo të gjitha bibliotekat mund të lidhen statikisht.
Së pari, bibliotekat sistemore, si libfuse, libblkid duhen lidhur në mënyrë dinamike, për t'u siguruar në përputhshmërinë e tyre me bërthamën dhe modulat e saj.
Së dyti, ka një nuancë me licencat.
Licenca GPL në parim lejon lidhjen e biblioteka vetëm me kod opensource. MIT dhe BSD lejojnë lidhjen statike dhe ndezin biblioteka në projekt. Ndërsa LGPL duket se nuk e kundërshton lidhjen statike, por kërkon që të ofrohen në publik skedarët e nevojshëm për lidhje.
Në përgjithësi, përdorimi i lidhjes dinamike do të sigurojë që të mos keni nevojë të ofroni asgjë.
Ndërtimi i aplikacioneve C/C++
Për të ndërtuar aplikacione C/C++ për platforma dhe distribuime të ndryshme, mjafton të zgjidhni ose të grumbulloni gcc-në e duhur dhe të përdorni kompilatorë të kryqëzuar për arkitekturat specifike, dhe të grumbulloni të gjithë setin e bibliotikave. Ky është një proces i realizueshëm, por mjaft i mundimshëm. Dhe nuk ka ndonjë garanci që kompilatori dhe bibliotekat e zgjedhura do të sigurojnë një version funksional.
Pika e dukshme: infrastruktura ndjeshëm thjeshtohet, pasi e gjithë procedura e ndërtimit mund të realizohet në një makinë. Për më tepër, mjafton të krijoni një set të vetëm të skedarëve binarë për një arkitekturë dhe mund t'i paketoni ato në paketa për distribuime të ndryshme. Kështu krijohen paketat veeam për Veeam Agent për Linux.
Në vend të këtij varianti, mund të përgatiten thjesht fermat e build-it, domethënë disa makina për ndërtimin. Çdo makinë e tillë do të sigurojë kompaktimin e aplikacionit dhe ndërtimin e paketës për shpërndarjen e caktuar dhe arkitekturën e caktuar. Në këtë rast, kompaktimi bëhet me mjete që ka përgatitur shpërndarësi. Kështu, faza e përgatitjes së kompajlerit dhe përzgjedhja e bibliotekave eliminohen. Për më tepër, procesi i ndërtimit mund të parajtohet lehtësisht.
Ka, për të vërtetë, edhe një disavantazh të këtij qasjeje: për çdo shpërndarje brenda një arkitekture do të duhet të ndërtohet një set i veçantë i skedarëve binarë. Një tjetër disavantazh është se duhet të shërbehet një numër i tillë makinerish, duke alokuar një sasi të madhe hapësire disk dhe memorie operative.
Kështu krijohen paketat KMOD të modulit të kernelit veeamsnap për shpërndarjet Red Hat.
Open Build Service
Kolegët nga SUSE kanë provuar të realizojnë një mesatare të artë në formën e shërbimit të veçantë për kompaktimin e aplikacioneve dhe ndërtimin e pakove — .
Në thelb, është një hipervizor që krijon një makinë virtuale, instalon në të të gjitha paketat e nevojshme, ekzekuton compilimin e aplikacionit dhe ndërtimin e paketës në këtë ambient të izoluar, pas së cilës kjo makinë virtuale lirohet.
Planifikuesi i implementuar në OpenBuildService do të përcaktojë se sa makina virtuale mund të aktivizohen për një shpejtësi optimale të ndërtimit të paketave. Mekanizmi i integruar i nënshkrimit do të nënshkruajë automatikisht paketat dhe do t'i publikojë ato në një depot të integruar. Sistemi i brendshëm i kontrollit të versioneve do të ruajë historikun e ndryshimeve dhe ndërtimeve. Mjafton thjesht të shtoni burimet tuaja brenda këtij sistemi. As që është e nevojshme të ngrihet një server, mund të përdorni një të hapur.
Megjithatë, këtu ka një problem: një kombinat i tillë është i vështirë për t'u integruar në infrastrukturën ekzistuese. Për shembull, kontrolli i versioneve nuk është i nevojshëm, ne tashmë kemi një për burimet tona. Mekanizmi i nënshkrimit ndryshon: përdoret një server i veçantë. Një depo gjithashtu nuk është e nevojshme.
Për më tepër, mbështetje për distribucione të tjera — për shembull, Red Hat — është e implementuar mjaft dobët, e cila është krejtësisht e kuptueshme.
Avantazhi i këtij shërbimi është mbështetje e shpejtë për versionin e radhës të distribucionit SUSE. Deri në shpalljen zyrtare të lansimit, paketat e nevojshme për ndërtimin publikohen në depo publike. Një i ri shfaqet në listën e distribucioneve të disponueshme në OpenBuildService. Aktivizojmë kutinë, dhe ai shtohet në planin e ndërtimit. Kështu, shtimi i një versioni të ri të distribucionit realizohet praktikisht me një klikim.
Në infrastrukturën tonë, duke përdorur OpenBuildService, ndërtohen të gjitha llojet e paketave KMP të modulit të bërthamës veeamsnap për distribucionet SUSE.
Në vazhdim, do të doja të ndalesha te çështjet që janë specifike për modulët e bërthamës.
kernel ABI
Modulët e bërthamës Linux historikisht janë shpërndarë në formën e kodit burimor. Kjo pasi krijuesit e bërthamës nuk shqetësohen për mbështetje të një API stabil për modulët e bërthamës, e as në nivelin binar, më pas kABI.
Për të ndërtuar një modul për bërthamën vanilla, nevojiten patjetër header-at e këtij bërthame, dhe ai do të funksionojë vetëm mbi këtë bërthamë.
DKMS automatizojnë procesin e ndërtimit të moduleve gjatë përditësimit të bërthamës. Si rezultat, përdoruesit e depozitës Debian (dhe të shumë llojeve të saj) përdorin modulet e bërthamës, ose nga depozita e shpërndarësit, ose të ndërtuara nga burimi me ndihmën e DKMS.
Megjithatë, kjo situatë nuk i kënaq shumë segmentin Enterprise. Shpërndarësit e kodeve të pronësishme dëshirojnë të shpërndajnë produktin në formën e binarëve të ndërtuar.
Administratoret nuk duan të mbajnë mjete zhvillimi në serverët production për arsye sigurie. Shpërndarësit e Enterprise Linux — si Red Hat dhe SUSE — kanë vendosur se për përdoruesit e tyre mund të mbështesin një kABI të qëndrueshme. Si rezultat, u krijuan paketat KMOD për Red Hat dhe paketat KMP për SUSE.
Thelbi i një zgjidhjeje të tillë është mjaft i thjeshtë. Për një version të caktuar të shpërndarjes, API i bërthamës ngrihet. Shpërndarësi deklaron se përdor bërthamën, për shembull, 3.10, dhe bën vetëm korrigjime dhe përmirësime që nuk ndikon aspak në ndërfaqet e bërthamës, dhe modulet e ndërtuara për bërthamën e parë mund të përdoren për të gjitha të ardhshmet pa nevojën e ripërpunimit.
Red Hat deklaron kABI përputhshmërinë për shpërndarjen gjatë të gjithë ciklit të saj të jetës. Kjo do të thotë që moduli i ndërtuar për rhel 6.0 (lëshimi në nëntor 2010) gjithashtu duhet të funksionojë në versionin 6.10 (lëshimi në qershor 2018). Dhe kjo është pothuajse 8 vjet. Sigurisht, kjo është një detyrë mjaft e komplikuar.
Ne kemi regjistruar disa raste kur moduli veeamsnap ndaloi së funksionuari për shkak të problemeve me përshtatshmërinë e kABI.
Pasi që moduli veeamsnap, i ndërtuar për RHEL 7.0, u tregua i papërshtatshëm me bërthamën nga RHEL 7.5, por përkundrazi ngarkohej dhe garantonte rënien e serverit, ne hoqëm dorë nga përdorimi i përshtatshmërisë kABI për RHEL 7 në tërësi.
Aktualisht, paketa KMOD për RHEL 7 përmban një ndërtim për çdo version lëshimi dhe një skript që siguron ngarkimin e modulit.
SUSE e qëndroi ndaj problemit të përshtatshmërisë kABI me më shumë kujdes. Ata sigurojnë përshtatshmërinë kABI vetëm brenda një service pack.
Për shembull, publikimi i SLES 12 ndodhi në shtator 2014. Ndërsa SLES 12 SP1 doli në dhjetor 2015, që do të thotë se kaluan pak më shumë se një vit. Megjithatë, edhe pse të dy publikimet përdorin kernelin 3.12, ato janë të papajtueshme me kABI. Është e qartë se mbajtja e kABI të pajtueshëm për vetëm një vit është shumë më e lehtë. Cikli vjetor i përditësimeve të modulit të kernelit nuk duhet të shkaktojë probleme për krijuesit e moduleve.
Si rezultat i kësaj politike të SUSE, ne nuk përcollëm asnjë problem me pajtueshmërinë e kABI në modulit tonë veeamsnap. Megjithatë, numri i paketave për SUSE është pothuajse një rend më i madh.
Patch dhe backport
Megjithëse distributorët përpiqen të sigurojnë pajtueshmërinë kABI dhe stabilitetin e kernelit, ata gjithashtu përpiqen të përmirësojnë performancën dhe të eliminojnë defektet e këtij kernelit stabil.
Në të njëjtën kohë, përveç "punës së tyre mbi gabimet", zhvilluesit e kernelit enterprise linux ndjekin ndryshimet në kernelin vanilla dhe i transferojnë ato në kernelin e tyre "stabil".
ndonjëherë kjo çon në .
Në versionin e fundit të Red Hat 6, njëra nga azhornimet minor kishte një gabim. Kjo shkaktoi që moduli veeamsnap të çonte gjithmonë në rënie të sistemit kur shpërndante snapshotin. Duke krahasuar burimet e bërthamës përpara dhe pas azhornimit, zbuluam se shkaku ishte backport. Një rregullim i ngjashëm ishte bërë në bërthamën vanilla versioni 4.19. Por në bërthamën vanilla, ky rregullim funksiononte normalisht, ndërsa gjatë transferimit të tij në bërthamën 'stabile' 2.6.32 u shfaq një problem me bllokimin spin.
Sigurisht, gabime ndodhin te të gjithë dhe gjithmonë, por a ishte vërtet e nevojshme të merrej kodi nga 4.19 në 2.6.32, duke rrezikuar stabilitetin?.. Nuk jam i sigurt...
Më e keqja është kur reklamimi përfshihet në tërheqjen e telasë 'stabilitet' 'modernizim'. Departamenti i marketingut ka nevojë që bërthama e distribucionit të azhornuar të jetë e qëndrueshme, nga njëra anë, dhe në të njëjtën kohë të jetë më e mirë në performancë dhe të ketë tipare të reja. Kjo sjell kompromise të çuditshme.
Kur bëra përpjekjen për të grumbulluar modul në bërthamën 4.4 të SLES 12 SP3, me étonim zbulova se kishte funksionalitete nga bërthama e pastër 4.8. Sipas mendimit tim, implementimi i hyrjes/dalitjes bllok të bërthamës 4.4 të SLES 12 SP3 më shumë i ngjan 4.8 sesa lëshimi i mëparshëm të bërthamës stabil 4.4 të SLES 12 SP2. Sa përqindje e kodit të transferuar nga bërthama 4.8 në 4.4 të SLES-ës për SP3, nuk mund ta gjykoj, por nuk më vjen mirë ta quaj bërthamën ende të stabil 4.4.
Më e pakëndshmja në këtë është se gjatë shkruarjes së një moduli që do të punonte njësoj mirë në bërthama të ndryshme, nuk mund të mbështetesh më në versionin e bërthamës. Duhet të marrësh parasysh gjithashtu distribuimin. Mirë që ndonjëherë mund të lidhesh me një definicion që shfaqet me funksionalitetin e ri, megjithatë kjo mundësi nuk është gjithmonë e pranishme.
Si pasojë, kodi mbushet me direktiva kur është e nevojshme për kompilimin e kushtëzuar.
Takohen gjithashtu dhe patch-e që ndryshojnë API-në e dokumentuar të bërthamës.
Kisha rënë në prangat e një distribuimi 5.16 dhe isha shumë i habitur kur pashë se thirja lookup_bdev në këtë version të bërthamës kishte ndryshuar listën e parametrave hyrës.
Për t'u mbledhur, duhej të shtohej një skript në makefile që kontrollon nëse ka një parametër mask në funksionin lookup_bdev.
Nënshkrimi i moduleve të bërthamës
Por le të kthehemi te çështja e shpërndarjes së pakove.
Një nga përfitimet e kABI-t stabil është që modulet e bërthamës në formatin binar mund të nënshkruhen. Në këtë rast, zhvilluesi mund të jetë i sigurt se moduli nuk është dëmtuar aksidentalisht ose ndryshuar qëllimisht. Këtë mund ta kontrolloni me komandën modinfo.
Distribucionet Red Hat dhe SUSE lejojnë të kontrollohet nënshkrimi i modulit dhe ta ngarkoni atë vetëm nëse sistemi ka regjistruar certifikatën përkatëse. Certifikata është çelësi publik me të cilin nënshkruhet moduli. Ne e shpërndajmë atë si një paketë të veçantë.
Problemi këtu është se certifikatat mund të jenë ose të përfshirë në bërthamë (ato përdoren nga shpërndarësit), ose duhet të regjistrohen në memorinë jo-volatile EFI me ndihmën e utilitarit mokutil. Utilitari mokutil gjatë instalimit të certifikatës kërkon një rinisje të sistemit dhe para ngarkimit të bërthamës së sistemit operativ i propozon administratorit të lejojë ngarkimin e certifikatës së re.
Pra kjo, shtimi i një certifikate kërkon qasje fizike të administratorit në sistem. Nëse makina ndodhet diku në re ose thjesht në një server të largët me qasje vetëm përmes rrjetit (për shembull, përmes ssh), atëherë do të jetë e pamundur të shtoni certifikatën.
EFI në makina virtuale
Pavarësisht se EFI mbështetet gjerësisht nga prodhuesit e pllakave nënë për një kohë të gjatë, gjatë instalimit të sistemit, administratori mund të mos mendojë për nevojën e EFI-së, dhe ai mund të jetë i ç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 parazgjedhur, ky funksionalitet për makinat Linux është i çaktivizuar, që do të thotë se certifikata nuk mund të instalohet.
Në vSphere 6.5, vendosni opsionin Secure Boot mund të bëhet vetëm në versionin e vjetër të ndërfaqes së uebit, e cila punon përmes Flash. UI-u Web në HTML-5 ende është shumë prapa.
Distribucione eksperimentale
Në fund, le të shqyrtojmë çështjen e distribucioneve eksperimentale dhe atyre pa mbështetje zyrtare. Në njërën anë, është e vështirë të gjejmë këto distribucione në serverët e organizatave serioze. Këto distribucione nuk kanë mbështetje zyrtare. Prandaj, nuk është e mundur të sigurohet mbështetje teknike për produktin në një distribuim të tillë.
Megjithatë, këto distribucione shërbejnë si një platformë e përshtatshme për të provuar zgjidhje të reja eksperimentale. Për shembull, Fedora, OpenSUSE Tumbleweed ose versionet e paqëndrueshme të Debian. Ato janë mjaft të qëndrueshme. Aty 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ë përditësuar.
Prandaj, nëse diçka nuk funksionon në një distribuim eksperimental, kjo është një mundësi për të hetuar problemin dhe për ta zgjidhur atë. Duhet të jemi të gatshëm që ky funksionalitet do të shfaqet së shpejti në serverët e prodhimit të përdoruesve.
Lista e aktualizuar e distribucioneve zyrtarisht të mbështetur për versionin 3.0 mund të studiohet . Por lista e vërtetë e distribucioneve në të cilat produkti ynë mund të funksionojë është shumë më e gjerë.
Mua për mua, eksperimenti me sistemin operativ «Elbrus» ishte i interesant. Pasi u përmirësua paketa veeam, produkti ynë u instalua dhe filloi të punojë. Për këtë eksperiment shkruajta në Habra në .
Ndërkohë, mbështetja për distribucione të reja vazhdon. Po presim të dalë versioni 4.0. Padyshim që duhet të shfaqet beta, prandaj qëndroni të informuar për !
Burimi: habr.com
