Krijimi i një aplikacioni rezervë që funksionon në çdo shpërndarje nuk është detyrë e lehtë. Për të siguruar që Veeam Agent për Linux punon në shpërndarjet nga Red Hat 6 dhe Debian 6, tek OpenSUSE 15.1 dhe Ubuntu 19.04, ju duhet të zgjidhni një sërë problemesh, veçanërisht duke pasur parasysh që produkti softuer përfshin një modul kernel.
Artikulli u krijua në bazë të materialeve nga një fjalim në konferencë .
Linux nuk është vetëm një nga sistemet operative më të njohura. Në thelb, kjo është një platformë mbi bazën e së cilës mund të bëni diçka unike, diçka tuajën. Falë kësaj, Linux ka shumë shpërndarje që ndryshojnë në grupin e tyre të komponentëve të softuerit. Dhe këtu lind një problem: në mënyrë që një produkt softuer të funksionojë në çdo shpërndarje, duhet të merrni 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 nëpër shpërndarje të ndryshme.
Mënyra më tipike për të shpërndarë produktet softuerike është vendosja e paketës në një depo, në mënyrë që menaxheri i paketave të integruar në sistem të mund ta instalojë atë nga atje.
Sidoqoftë, ne kemi dy formate të njohura të paketave: rpm и debutuese. Kjo do të thotë që të gjithë do të duhet të mbështesin.
Në botën e paketave deb, niveli i përputhshmërisë është i mahnitshëm. E njëjta paketë instalon dhe funksionon njësoj mirë si në Debian 6 ashtu edhe në Ubuntu 19.04. Standardet për procesin e ndërtimit të paketave dhe punës me to, të përcaktuara në shpërndarjet e vjetra të Debian-it, mbeten të rëndësishme në Linux Mint të ri dhe OS elementare. Prandaj, në rastin e Veeam Agent për Linux, mjafton një paketë deb për secilën platformë harduerike.
Por në botën e paketave të rpm, dallimet janë të mëdha. Së pari, për faktin se ekzistojnë dy shpërndarës krejtësisht të pavarur, Red Hat dhe SUSE, për të cilët përputhshmëria është krejtësisht e panevojshme. Së dyti, këta shpërndarës kanë komplete shpërndarjeje nga ato. mbështetëse dhe eksperimentale. Nuk ka nevojë as për pajtueshmëri mes tyre. Doli që el6, el7 dhe el8 kanë paketat e tyre. Paketa e veçantë për Fedora. Paketat për SLES11 dhe 12 dhe një të veçantë për openSUSE. Problemi kryesor janë varësitë dhe emrat e paketave.
Problemi i varësisë
Fatkeqësisht, të njëjtat paketa shpesh përfundojnë me emra të ndryshëm në shpërndarje të ndryshme. Më poshtë është një listë e pjesshme e varësive të paketës veeam.
Për EL7:
Për SLES 12:
- libblkid
- libgcc
- libstdc++
- ncurses-libs
- siguresave-libs
- skedar-libs
- veeamsnap=3.0.2.1185
- libblkid1
- libgcc_s1
- libstdc++6
- libmagjike1
- libfuse2
- veeamsnap-kmp=3.0.2.1185
Si rezultat, lista e varësive është unike për shpërndarjen.
Ajo që përkeqësohet është kur një version i përditësuar fillon të fshihet nën emrin e vjetër të paketës.
Shembull:
Paketa është përditësuar në Fedora 24 mallkime nga versioni 5 në versionin 6. Produkti ynë është ndërtuar 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 të 5-të të bibliotekës në Fedora 24, më duhej të përdorja paketën ncurses-compat-libs.
Si rezultat, ekzistojnë dy paketa për Fedora, me varësi të ndryshme.
Më tej më interesante. Pas përditësimit të ardhshëm të shpërndarjes, paketa ncurses-compat-libs me versionin 5 të bibliotekës rezulton të jetë i padisponueshëm. Është e shtrenjtë për një shpërndarës të tërheqë bibliotekat e vjetra në një version të ri të shpërndarjes. Pas ca kohësh, problemi u përsërit në shpërndarjet SUSE.
Si rezultat, disa shpërndarjeve iu desh të hiqnin varësinë e tyre të qartë nga ncurses-libs, dhe rregulloni produktin në mënyrë që të mund të funksionojë me çdo version të bibliotekës.
Nga rruga, në versionin 8 të Red Hat nuk ka më një paketë meta piton, që i referohej të vjetrës së mirë python 2.7... ka python2 и piton3.
Alternativë për menaxherët e paketave
Problemi me varësitë është i vjetër dhe ka qenë prej kohësh i dukshëm. Vetëm mbani mend ferrin e Varësisë.
Për të kombinuar biblioteka dhe aplikacione të ndryshme në mënyrë që të gjitha të funksionojnë në mënyrë të qëndrueshme dhe të mos bien ndesh - në fakt, kjo është detyra që çdo shpërndarës Linux përpiqet të zgjidhë.
Menaxheri i paketave përpiqet ta zgjidhë këtë problem në një mënyrë krejtësisht të ndryshme. i gjallë nga Canonical. Ideja kryesore: aplikacioni funksionon në një sandbox të izoluar dhe të mbrojtur nga sistemi kryesor. Nëse një aplikacion kërkon biblioteka, ato pajisen me vetë aplikacionin.
Flatpak gjithashtu ju lejon të ekzekutoni aplikacione në një sandbox duke përdorur Linux Containers. Përdoret gjithashtu ideja e sandbox AppImage.
Këto zgjidhje ju lejojnë të krijoni një paketë për çdo shpërndarje. Në rast se Flatpak instalimi dhe nisja e aplikacionit është e mundur edhe pa dijeninë e administratorit.
Problemi kryesor është se jo të gjitha aplikacionet mund të ekzekutohen në një sandbox. Disa njerëz kanë nevojë për qasje të drejtpërdrejtë në platformë. Nuk po flas as për modulet e kernelit, të cilat varen rreptësisht nga kerneli dhe nuk përshtaten në konceptin e sandbox.
Problemi i dytë është se shpërndarjet e njohura në mjedisin e ndërmarrjes nga Red Hat dhe SUSE nuk përmbajnë ende mbështetje për Snappy dhe Flatpak.
Në këtë drejtim, Veeam Agent për Linux nuk është i disponueshëm jo në .
Për të përfunduar pyetjen në lidhje me menaxherët e paketave, do të doja të vëreja se ekziston një mundësi për të braktisur plotësisht menaxherët e paketave duke kombinuar skedarët binare dhe një skript për instalimin e tyre në një paketë.
Një paketë e tillë ju lejon të krijoni një paketë të përbashkët për shpërndarje dhe platforma të ndryshme, të kryeni një proces instalimi interaktiv, duke kryer personalizimin e nevojshëm. Kam hasur vetëm paketa të tilla për Linux nga VMware.
Problemi me përditësimin
Edhe nëse zgjidhen të gjitha çështjet e varësisë, programi mund të funksionojë ndryshe në të njëjtën shpërndarje. Bëhet fjalë për përditësime.
Ekzistojnë 3 strategji të përditësimit:
- Më e thjeshta është të mos përditësoni kurrë. Vendosa serverin dhe e harrova. Pse të përditësoni nëse gjithçka funksionon? Problemet fillojnë herën e parë kur kontaktoni mbështetjen. Krijuesi i shpërndarjes mbështet vetëm versionin e përditësuar.
- Mund t'i besoni shpërndarësit dhe të konfiguroni përditësimet automatike. Në këtë rast, një thirrje për mbështetje ka të ngjarë menjëherë pas një përditësimi të pasuksesshëm.
- Opsioni i përditësimit manual vetëm pas ekzekutimit të tij në një infrastrukturë testimi është më i besueshmi, por i kushtueshëm dhe kërkon kohë. Jo të gjithë mund ta përballojnë atë.
Meqenëse përdorues të ndryshëm përdorin strategji të ndryshme përditësimi, është e nevojshme të mbështetet si versioni më i fundit ashtu edhe të gjitha ato të lëshuara më parë. Kjo e ndërlikon procesin e zhvillimit dhe testimit dhe i shton dhimbje koke ekipit mbështetës.
Shumëllojshmëri platformash harduerike
Platforma të ndryshme harduerike janë një problem që është kryesisht specifik për kodin vendas. Së paku, ju duhet të grumbulloni binare për secilën platformë të mbështetur.
Në projektin Veeam Agent for Linux, ne ende nuk mund të mbështesim asgjë si ky RISC.
Nuk do të ndalem në këtë çështje në detaje. Unë do të përshkruaj vetëm problemet kryesore: llojet e varura nga platforma, si p.sh size_t, rreshtimi i strukturës dhe renditja e bajteve.
Lidhje statike dhe/ose dinamike
Por pyetja është "Si të lidheni me bibliotekat - në mënyrë dinamike apo statike?" ja vlen te diskutohet.
Si rregull, aplikacionet C/C++ nën Linux përdorin lidhje dinamike. Kjo funksionon mirë nëse aplikacioni është ndërtuar posaçërisht për një shpërndarje specifike.
Nëse detyra është të mbuloni shpërndarje të ndryshme me një skedar binar, atëherë duhet të përqendroheni në shpërndarjen më të vjetër të mbështetur. Për ne, ky është Red Hat 6. Ai përmban gcc 4.4, të cilin as standardi C++11 nuk e mbështet .
Ne ndërtojmë projektin tonë duke përdorur gcc 6.3, i cili mbështet plotësisht C++14. Natyrisht, në këtë rast, në Red Hat 6 duhet të mbani me vete libstdc++ dhe të rritni bibliotekat. Mënyra më e lehtë është lidhja me to në mënyrë statike.
Por mjerisht, jo të gjitha bibliotekat mund të lidhen në mënyrë statike.
Së pari, bibliotekat e sistemit si p.sh libfuse, libblkid është e nevojshme të lidhen në mënyrë dinamike për të siguruar përputhshmërinë e tyre me kernelin dhe modulet e tij.
Së dyti, ka një hollësi me licencat.
Licenca GPL në thelb ju lejon të lidhni bibliotekat vetëm me kodin me burim të hapur. MIT dhe BSD lejojnë lidhjen statike dhe lejojnë që bibliotekat të përfshihen në një projekt. Por LGPL nuk duket se kundërshton lidhjen statike, por kërkon që skedarët e nevojshëm për lidhje të ndahen.
Në përgjithësi, përdorimi i lidhjeve dinamike do t'ju pengojë të ofroni ndonjë gjë.
Ndërtimi i aplikacioneve C/C++
Për të ndërtuar aplikacione C/C++ për platforma dhe shpërndarje të ndryshme, mjafton të zgjidhni ose të ndërtoni një version të përshtatshëm të gcc dhe të përdorni ndër-përpilues për arkitektura specifike dhe të montoni të gjithë grupin e bibliotekave. Kjo punë është mjaft e realizueshme, por mjaft e mundimshme. Dhe nuk ka asnjë garanci që përpiluesi dhe bibliotekat e zgjedhura do të ofrojnë një version të zbatueshëm.
Një avantazh i dukshëm: infrastruktura është shumë e thjeshtuar, pasi i gjithë procesi i ndërtimit mund të kryhet në një makinë. Përveç kësaj, mjafton të mblidhni një grup binare për një arkitekturë dhe mund t'i paketoni në paketa për shpërndarje të ndryshme. Kështu ndërtohen paketat veeam për Veeam Agent për Linux.
Për dallim nga ky opsion, thjesht mund të përgatisni një fermë ndërtimi, domethënë disa makina për montim. Çdo makinë e tillë do të sigurojë përpilimin e aplikacionit dhe montimin e paketave për një shpërndarje specifike dhe një arkitekturë specifike. Në këtë rast, përpilimi kryhet duke përdorur mjetet e përgatitura nga distributori. Kjo do të thotë, faza e përgatitjes së përpiluesit dhe përzgjedhjes së bibliotekave eliminohet. Përveç kësaj, procesi i ndërtimit mund të paralelizohet lehtësisht.
Sidoqoftë, kjo qasje ka një anë negative: për secilën shpërndarje brenda së njëjtës arkitekturë, do t'ju duhet të grumbulloni grupin tuaj të skedarëve binare. Një tjetër disavantazh është se një numër kaq i madh i makinave duhet të mirëmbahen dhe duhet të ndahet një sasi e madhe e hapësirës në disk dhe RAM.
Kështu përpilohen paketat KMOD të modulit të kernelit veeamsnap për shpërndarjet Red Hat.
Hapni Shërbimin e Ndërtimit
Kolegët nga SUSE u përpoqën të zbatojnë një terren të mesëm në formën e një shërbimi special për përpilimin e aplikacioneve dhe montimin e paketave - .
Në thelb, është një hipervizor që krijon një makinë virtuale, instalon të gjitha paketat e nevojshme në të, përpilon aplikacionin dhe ndërton paketën në këtë mjedis të izoluar, pas së cilës makina virtuale lëshohet.
Planifikuesi i implementuar në OpenBuildService do të përcaktojë se sa makina virtuale mund të nisë për shpejtësi optimale të ndërtimit të paketave. Mekanizmi i integruar i nënshkrimit do të nënshkruajë paketat dhe do t'i ngarkojë ato në depon e integruar. Sistemi i integruar i kontrollit të versionit do të ruajë historinë e ndryshimeve dhe ndërtimeve. Gjithçka që mbetet është thjesht të shtoni burimet tuaja në këtë sistem. Ju as nuk duhet ta konfiguroni vetë serverin; mund të përdorni një të hapur.
Megjithatë, ekziston një problem: një korrëse e tillë është e vështirë të përshtatet në infrastrukturën ekzistuese. Për shembull, kontrolli i versionit nuk është i nevojshëm; ne tashmë kemi kodet tona burimore. Mekanizmi ynë i nënshkrimit është i ndryshëm: ne përdorim një server të veçantë. Një depo gjithashtu nuk është e nevojshme.
Për më tepër, mbështetja për shpërndarjet e tjera - për shembull, Red Hat - zbatohet mjaft dobët, gjë që është e kuptueshme.
Avantazhi i një shërbimi të tillë është mbështetja e shpejtë për versionin tjetër të shpërndarjes SUSE. Para shpalljes zyrtare të lëshimit, paketat e nevojshme për montim vendosen në një depo publike. Një i ri shfaqet në listën e shpërndarjeve të disponueshme në OpenBuildService. Ne kontrollojmë kutinë dhe shtohet në planin e ndërtimit. Kështu, shtimi i një versioni të ri të shpërndarjes bëhet pothuajse me një klik.
Në infrastrukturën tonë, duke përdorur OpenBuildService, është mbledhur e gjithë shumëllojshmëria e paketave KMP të modulit të kernelit veeamsnap për shpërndarjet SUSE.
Më pas, do të doja të ndalem në çështje specifike për modulet e kernelit.
bërthama ABI
Modulet e kernelit Linux historikisht janë shpërndarë në formën e burimit. Fakti është se krijuesit e kernelit nuk e ngarkojnë veten me shqetësimin e mbështetjes së një API të qëndrueshme për modulet e kernelit, dhe veçanërisht në nivelin binar, të referuar më tej si kABI.
Për të ndërtuar një modul për një kernel vanilje, ju duhen patjetër kokat e këtij kernel të veçantë dhe do të funksionojë vetëm në këtë kernel.
DKMS ju lejon të automatizoni procesin e ndërtimit të moduleve kur përditësoni kernelin. Si rezultat, përdoruesit e depove Debian (dhe shumë të afërm të tij) përdorin module kernel ose nga depoja e shpërndarësit ose të përpiluara nga burimi duke përdorur DKMS.
Megjithatë, kjo situatë nuk i përshtatet veçanërisht segmentit të Ndërmarrjeve. Shpërndarësit e kodit të pronarit dëshirojnë ta shpërndajnë produktin si binare të përpiluara.
Administratorët nuk duan të mbajnë mjetet e zhvillimit në serverët e prodhimit për arsye sigurie. Shpërndarësit e Enterprise Linux si Red Hat dhe SUSE vendosën që ata të mund të mbështesin kABI të qëndrueshëm për përdoruesit e tyre. Rezultati ishin paketat KMOD për paketat Red Hat dhe KMP për SUSE.
Thelbi i kësaj zgjidhjeje është mjaft i thjeshtë. Për një version specifik të shpërndarjes, API i kernelit është i ngrirë. Shpërndarësi deklaron se ai përdor kernelin, për shembull, 3.10, dhe bën vetëm korrigjime dhe përmirësime që nuk ndikojnë në ndërfaqet e kernelit, dhe modulet e mbledhura për kernelin e parë mund të përdoren për të gjitha ato të mëvonshme pa ripërpilim.
Red Hat pretendon përputhshmërinë e kABI për shpërndarjen gjatë gjithë ciklit të saj jetësor. Kjo do të thotë, moduli i montuar për rhel 6.0 (lëshimi në nëntor 2010) duhet të funksionojë gjithashtu në versionin 6.10 (lëshimi në qershor 2018). Dhe kjo është pothuajse 8 vjet. Natyrisht, kjo detyrë është mjaft e vështirë.
Ne kemi regjistruar disa raste kur moduli veeamsnap pushoi së punuari për shkak të problemeve të përputhshmërisë kABI.
Pasi moduli veeamsnap, i përpiluar për RHEL 7.0, doli të ishte i papajtueshëm me kernelin nga RHEL 7.5, por u ngarkua dhe u garantua se do të prishte serverin, ne braktisëm fare përdorimin e përputhshmërisë kABI për RHEL 7.
Aktualisht, paketa KMOD për RHEL 7 përmban një asamble për çdo version lëshimi dhe një skript që ngarkon modulin.
SUSE iu afrua detyrës së përputhshmërisë kABI me më shumë kujdes. Ato ofrojnë përputhshmëri me kABI vetëm brenda një pakete shërbimi.
Për shembull, lëshimi i SLES 12 u zhvillua në shtator 2014. Dhe SLES 12 SP1 ishte tashmë në dhjetor 2015, domethënë ka kaluar pak më shumë se një vit. Edhe pse të dy lëshimet përdorin kernelin 3.12, ato janë të papajtueshme me kABI. Natyrisht, mbajtja e pajtueshmërisë me kABI për vetëm një vit është shumë më e lehtë. Cikli vjetor i përditësimit të modulit të kernelit nuk duhet të shkaktojë probleme për krijuesit e moduleve.
Si rezultat i kësaj politike SUSE, ne nuk kemi regjistruar asnjë problem të vetëm me përputhshmërinë e kABI në modulin tonë veeamsnap. Vërtetë, numri i paketave për SUSE është pothuajse një rend i madhësisë më i madh.
Patches dhe backports
Megjithëse distributorët përpiqen të sigurojnë përputhshmërinë e kABI dhe stabilitetin e kernelit, ata gjithashtu përpiqen të përmirësojnë performancën dhe të eliminojnë defektet e këtij kerneli të qëndrueshëm.
Në të njëjtën kohë, përveç "punës së tyre për gabimet", zhvilluesit e ndërmarrjes kernel Linux monitorojnë ndryshimet në kernelin e vaniljes dhe i transferojnë ato në atë "të qëndrueshme" të tyre.
Ndonjëherë kjo çon në të reja .
Në versionin e fundit të Red Hat 6, u bë një gabim në një nga përditësimet e vogla. Kjo çoi në faktin se moduli veeamsnap ishte i garantuar për të rrëzuar sistemin kur u publikua fotografia. Pasi krahasuam burimet e kernelit para dhe pas përditësimit, zbuluam se fajin e kishte porta e pasme. Një rregullim i ngjashëm është bërë në versionin 4.19 të bërthamës së vaniljes. Thjesht ky rregullim funksionoi mirë në bërthamën e vaniljes, por kur e transferonim në 2.6.32 "të qëndrueshme", u shfaq një problem me spinlock.
Sigurisht, të gjithë kanë gjithmonë gabime, por a ia vlente të zvarritesh kodin nga 4.19 në 2.6.32, duke rrezikuar stabilitetin?.. Nuk jam i sigurt...
Gjëja më e keqe është kur marketingu përfshihet në tërheqjen e luftës midis "stabilitetit" dhe "modernizimit". Departamenti i marketingut ka nevojë që thelbi i shpërndarjes së përditësuar të jetë i qëndrueshëm, nga njëra anë, dhe në të njëjtën kohë të jetë më i mirë në performancë dhe të ketë veçori të reja. Kjo çon në kompromise të çuditshme.
Kur u përpoqa të ndërtoj një modul në kernel 4.4 nga SLES 12 SP3, u befasova kur gjeta funksionalitet nga vanilja 4.8 në të. Sipas mendimit tim, implementimi i bllokut I/O i kernelit 4.4 nga SLES 12 SP3 është më i ngjashëm me kernelin 4.8 sesa lëshimi i mëparshëm i kernelit të qëndrueshëm 4.4 nga SLES12 SP2. Nuk mund të gjykoj se cila përqindje e kodit u transferua nga kerneli 4.8 në SLES 4.4 për SP3, por nuk mund ta quaj as kernelin të njëjtin stabil 4.4.
Gjëja më e pakëndshme për këtë është se kur shkruani një modul që do të funksiononte po aq mirë në kernele të ndryshme, nuk mund të mbështeteni më në versionin e kernelit. Ju gjithashtu duhet të merrni parasysh shpërndarjen. Është mirë që ndonjëherë mund të përfshiheni në një përkufizim që shfaqet së bashku me funksionalitetin e ri, por kjo mundësi nuk shfaqet gjithmonë.
Si rezultat, kodi bëhet i tejmbushur me direktiva të çuditshme të përpilimit të kushtëzuar.
Ka gjithashtu arna që ndryshojnë API-në e dokumentuar të kernelit.
Kam hasur në shpërndarjen 5.16 dhe u habit shumë kur pa se thirrja lookup_bdev në këtë version të kernelit ndryshoi listën e parametrave të hyrjes.
Për t'i bashkuar, më duhej të shtoja një skript në skedarin e krijuar që kontrollon nëse funksioni lookup_bdev ka një parametër maskë.
Nënshkrimi i moduleve të kernelit
Por le të kthehemi te çështja e shpërndarjes së paketave.
Një nga avantazhet e kABI të qëndrueshme është se modulet e kernelit mund të nënshkruhen si skedar binar. Në këtë rast, zhvilluesi mund të jetë i sigurt se moduli nuk është dëmtuar ose modifikuar qëllimisht. Ju mund ta kontrolloni këtë me komandën modinfo.
Shpërndarjet Red Hat dhe SUSE ju lejojnë të kontrolloni nënshkrimin e modulit dhe ta ngarkoni atë vetëm nëse certifikata përkatëse është e regjistruar në sistem. Certifikata është çelësi publik me të cilin është nënshkruar moduli. E shpërndajmë si paketë të veçantë.
Problemi këtu është se certifikatat ose mund të ndërtohen në kernel (shpërndarësit i përdorin ato) ose duhet të shkruhen në memorien e paqëndrueshme EFI duke përdorur një mjet. mokutil. Shërbimet mokutil Kur instaloni një certifikatë, ju kërkon të rindizni sistemin dhe, edhe përpara se të ngarkoni kernelin e sistemit operativ, i kërkon administratorit të lejojë ngarkimin e një certifikate të re.
Kështu, shtimi i një certifikate kërkon akses fizik të administratorit në sistem. Nëse makina ndodhet diku në cloud ose thjesht në një dhomë të largët të serverit dhe qasja është vetëm përmes rrjetit (për shembull, përmes ssh), atëherë do të jetë e pamundur të shtoni një certifikatë.
EFI në makinat virtuale
Përkundër faktit se EFI është mbështetur prej kohësh nga pothuajse të gjithë prodhuesit e motherboard-it, kur instaloni një sistem, administratori mund të mos mendojë për nevojën për EFI dhe mund të çaktivizohet.
Jo të gjithë hipervizorët mbështesin EFI. VMWare vSphere mbështet EFI duke filluar nga versioni 5.
Microsoft Hyper-V gjithashtu fitoi mbështetje EFI duke filluar me Hyper-V për Windows Server 2012R2.
Megjithatë, në konfigurimin e paracaktuar ky funksion është i çaktivizuar për makinat Linux, që do të thotë se certifikata nuk mund të instalohet.
Në vSphere 6.5, vendosni opsionin Boot Sigurt e mundur vetëm në versionin e vjetër të ndërfaqes në internet, i cili funksionon përmes Flash. Ueb UI në HTML-5 është ende shumë prapa.
Shpërndarjet eksperimentale
Dhe së fundi, le të shqyrtojmë çështjen e shpërndarjeve dhe shpërndarjeve eksperimentale pa mbështetje zyrtare. Nga njëra anë, shpërndarje të tilla nuk ka gjasa të gjenden në serverët e organizatave serioze. Nuk ka asnjë mbështetje zyrtare për shpërndarje të tilla. Prandaj, jepini ato. Produkti nuk mund të mbështetet në një shpërndarje të tillë.
Sidoqoftë, shpërndarje të tilla bëhen një platformë e përshtatshme për të provuar zgjidhje të reja eksperimentale. Për shembull, versionet Fedora, OpenSUSE Tumbleweed ose Unstable të Debian. Janë mjaft të qëndrueshme. Ata kanë gjithmonë versione të reja të programeve dhe gjithmonë një kernel të ri. Brenda një viti, ky funksionalitet eksperimental mund të përfundojë në një RHEL, SLES ose Ubuntu të përditësuar.
Pra, nëse diçka nuk funksionon në një shpërndarje eksperimentale, kjo është një arsye për të kuptuar problemin dhe për ta zgjidhur atë. Duhet të përgatiteni për faktin se ky funksionalitet do të shfaqet së shpejti në serverët e prodhimit të përdoruesve.
Ju mund të studioni listën aktuale të shpërndarjeve të mbështetura zyrtarisht për versionin 3.0 . Por lista reale e shpërndarjeve në të cilat produkti ynë mund të funksionojë është shumë më e gjerë.
Personalisht, unë u interesova për eksperimentin me Elbrus OS. Pas finalizimit të paketës veeam, produkti ynë u instalua dhe funksionoi. Kam shkruar për këtë eksperiment në Habré in .
Epo, mbështetja për shpërndarjet e reja vazhdon. Ne jemi në pritje të lëshimit të versionit 4.0. Beta është gati të shfaqet, prandaj kini kujdes !
Burimi: www.habr.com