Að búa til varaforrit sem virkar á hvaða dreifingu sem er er ekkert auðvelt verkefni. Til að tryggja að Veeam Agent fyrir Linux virki á dreifingu frá Red Hat 6 og Debian 6, til OpenSUSE 15.1 og Ubuntu 19.04, verður þú að leysa margvísleg vandamál, sérstaklega í ljósi þess að hugbúnaðarvaran inniheldur kjarnaeiningu.
Greinin var unnin út frá efni úr ræðu á ráðstefnunni .
Linux er ekki bara eitt vinsælasta stýrikerfið. Í meginatriðum er þetta vettvangur sem byggir á því að þú getur búið til eitthvað einstakt, eitthvað þitt eigið. Þökk sé þessu hefur Linux margar dreifingar sem eru mismunandi hvað varðar hugbúnaðarhluta. Og hér kemur upp vandamál: Til þess að hugbúnaðarvara virki á hvaða dreifingu sem er, verður þú að taka tillit til eiginleika hvers og eins.
Pakkastjórar. .deb á móti .rpm
Við skulum byrja á því augljósa vandamáli að dreifa vörunni yfir mismunandi dreifingar.
Dæmigerðasta leiðin til að dreifa hugbúnaðarvörum er að setja pakkann á geymslu þannig að pakkastjórinn sem er innbyggður í kerfið geti sett hann upp þaðan.
Hins vegar höfum við tvö vinsæl pakkasnið: rpm и deb. Þetta þýðir að allir verða að styðja.
Í heimi deb pakka er samhæfnistigið ótrúlegt. Sami pakki setur upp og virkar jafn vel á bæði Debian 6 og Ubuntu 19.04. Staðlarnir fyrir ferlið við að búa til pakka og vinna með þá, sem mælt er fyrir um í gömlum Debian dreifingum, halda áfram að gilda í nýjustu Linux Mint og grunnstýrikerfi. Þess vegna, þegar um Veeam Agent fyrir Linux er að ræða, nægir einn deb pakki fyrir hvern vélbúnaðarvettvang.
En í heimi rpm pakka er munurinn mikill. Í fyrsta lagi vegna þess að það eru tveir algjörlega óháðir dreifingaraðilar, Red Hat og SUSE, sem eindrægni er algjörlega óþarfi. Í öðru lagi hafa þessir dreifingaraðilar dreifingarsett úr þeim. stuðningur og tilraunastarfsemi. Það er engin þörf á samhæfni á milli þeirra heldur. Það kom í ljós að el6, el7 og el8 eru með sína eigin pakka. Sér pakki fyrir Fedora. Pakkar fyrir SLES11 og 12 og sérstakt fyrir openSUSE. Helsta vandamálið er ósjálfstæði og pakkanöfn.
Ósjálfstæði vandamál
Því miður enda sömu pakkarnir oft undir mismunandi nöfnum í mismunandi dreifingum. Hér að neðan er listi að hluta yfir háð veeam pakka.
Fyrir EL7:
Fyrir SLES 12:
- libblkid
- libgcc
- libstdc++
- ncurses-libs
- fuse-libs
- skrá-libs
- veeamsnap=3.0.2.1185
- libblkid1
- libgcc_s1
- libstdc++6
- libmagic1
- libfuse2
- veeamsnap-kmp=3.0.2.1185
Þar af leiðandi er listinn yfir ósjálfstæði einstakur fyrir dreifinguna.
Það sem versnar er þegar uppfærð útgáfa byrjar að fela sig undir gamla pakkanafninu.
Dæmi:
Pakkinn hefur verið uppfærður í Fedora 24 ncurses frá útgáfu 5 til útgáfu 6. Varan okkar var smíðuð með útgáfu 5 til að tryggja samhæfni við eldri dreifingar. Til að nota gömlu 5. útgáfuna af bókasafninu á Fedora 24 þurfti ég að nota pakkann ncurses-compat-libs.
Fyrir vikið eru tveir pakkar fyrir Fedora, með mismunandi ósjálfstæði.
Enn meira áhugavert. Eftir næstu dreifingaruppfærslu, pakkinn ncurses-compat-libs með útgáfu 5 af bókasafninu reynist það ekki vera tiltækt. Það er dýrt fyrir dreifingaraðila að draga gömul bókasöfn inn í nýja útgáfu af dreifingunni. Eftir nokkurn tíma endurtók vandamálið sig í SUSE dreifingum.
Fyrir vikið þurftu sumar dreifingar að hætta að vera ósjálfbjarga háðar ncurses-libs, og laga vöruna þannig að hún geti unnið með hvaða útgáfu sem er af bókasafninu.
Við the vegur, í útgáfu 8 af Red Hat er ekki lengur meta pakki python, sem vísaði til hins gamla góða Python 2.7. Það er python2 и python3.
Valkostur við pakkastjóra
Vandamálið með ósjálfstæði er gamalt og hefur lengi verið augljóst. Mundu bara Dependency helvíti.
Að sameina ýmis bókasöfn og forrit þannig að þau virki öll stöðugt og stangist ekki á - í raun er þetta verkefnið sem allir Linux dreifingaraðilar reyna að leysa.
Pakkastjórinn reynir að leysa þetta vandamál á allt annan hátt. Snigill frá Canonical. Meginhugmyndin: forritið keyrir í sandkassa sem er einangrað og varið frá aðalkerfinu. Ef forrit krefst bókasöfn fylgja þeim með forritinu sjálfu.
Flatpak gerir þér einnig kleift að keyra forrit í sandkassa með Linux ílátum. Sandkassahugmyndin er líka notuð AppImage.
Þessar lausnir gera þér kleift að búa til einn pakka fyrir hvaða dreifingu sem er. Ef um er að ræða Flatpak uppsetning og ræsing forritsins er möguleg jafnvel án vitundar stjórnandans.
Helsta vandamálið er að ekki geta öll forrit keyrt í sandkassa. Sumir þurfa beinan aðgang að pallinum. Ég er ekki einu sinni að tala um kjarnaeiningar, sem eru algjörlega háðar kjarnanum og passa ekki inn í sandkassahugtakið.
Annað vandamálið er að dreifingar vinsælar í fyrirtækjaumhverfinu frá Red Hat og SUSE innihalda ekki enn stuðning fyrir Snappy og Flatpak.
Í þessu sambandi er Veeam Agent fyrir Linux ekki í boði ekki á .
Til að ljúka spurningunni um pakkastjóra vil ég taka fram að það er möguleiki á að hætta alveg við pakkastjóra með því að sameina tvöfaldar skrár og skriftu til að setja þær upp í einn pakka.
Slík búnt gerir þér kleift að búa til einn sameiginlegan pakka fyrir mismunandi dreifingar og vettvang, framkvæma gagnvirkt uppsetningarferli, framkvæma nauðsynlega aðlögun. Ég hef bara rekist á svona pakka fyrir Linux frá VMware.
Uppfærsluvandamál
Jafnvel þótt öll ávanamál séu leyst, gæti forritið keyrt öðruvísi á sömu dreifingu. Þetta er spurning um uppfærslur.
Það eru 3 uppfærsluaðferðir:
- Einfaldast er að uppfæra aldrei. Ég setti upp serverinn og gleymdi því. Til hvers að uppfæra ef allt virkar? Vandamál byrja í fyrsta skipti sem þú hefur samband við þjónustudeild. Höfundur dreifingarinnar styður aðeins uppfærða útgáfu.
- Þú getur treyst dreifingaraðilanum og sett upp sjálfvirkar uppfærslur. Í þessu tilviki er líklega símtal til stuðnings strax eftir misheppnaða uppfærslu.
- Möguleikinn á handvirkri uppfærslu aðeins eftir að hafa keyrt hana á prófunarinnviði er áreiðanlegastur, en dýr og tímafrekur. Það hafa ekki allir efni á því.
Þar sem mismunandi notendur nota mismunandi uppfærsluaðferðir er nauðsynlegt að styðja bæði nýjustu útgáfuna og allar áður gefnar út. Þetta flækir bæði þróunar- og prófunarferlið og bætir höfuðverk við stuðningsteymið.
Fjölbreytt vélbúnaðarkerfi
Mismunandi vélbúnaðarpallar eru vandamál sem er að mestu leyti sérstakt fyrir innfæddan kóða. Að minnsta kosti þarftu að safna tvöfaldur fyrir hvern studd vettvang.
Í Veeam Agent for Linux verkefninu getum við samt ekki stutt neitt eins og þetta RISC.
Ég ætla ekki að fjölyrða um þetta mál í smáatriðum. Ég mun aðeins útlista helstu vandamálin: vettvangsháðar tegundir, svo sem size_t, röðun uppbyggingar og bæta röð.
Statísk og/eða kraftmikil tenging
En spurningin er "Hvernig á að tengja við bókasöfn - virkt eða kyrrstætt?" þess virði að ræða.
Að jafnaði nota C/C++ forrit undir Linux kraftmikla tengingu. Þetta virkar frábærlega ef forritið er byggt sérstaklega fyrir ákveðna dreifingu.
Ef verkefnið er að ná yfir ýmsar dreifingar með einni tvíundarskrá, þá verður þú að einbeita þér að elstu studdu dreifingunni. Fyrir okkur er þetta Red Hat 6. Það inniheldur gcc 4.4, sem jafnvel C++11 staðallinn styður ekki .
Við byggjum verkefnið okkar með því að nota gcc 6.3, sem styður C++14 að fullu. Auðvitað, í þessu tilfelli, á Red Hat 6 þarftu að hafa libstdc++ og auka bókasöfn með þér. Auðveldasta leiðin er að tengja við þá statískt.
En því miður er ekki hægt að tengja öll bókasöfn með kyrrstöðu.
Í fyrsta lagi kerfissöfn eins og libfuse, libblkid það er nauðsynlegt að tengja á virkan hátt til að tryggja samhæfni þeirra við kjarnann og einingar hans.
Í öðru lagi er lúmskt með leyfi.
GPL leyfið leyfir þér í grundvallaratriðum að tengja bókasöfn aðeins með opnum kóða. MIT og BSD leyfa truflanir tengingar og leyfa bókasöfnum að vera með í verkefni. En LGPL virðist ekki stangast á við kyrrstæða tengingu, heldur krefst þess að skrám sem nauðsynlegar eru til tengingar sé deilt.
Almennt séð, með því að nota kraftmikla tengingu, kemur í veg fyrir að þú þurfir að veita neitt.
Byggja C/C++ forrit
Til að smíða C/C++ forrit fyrir mismunandi kerfa og dreifingu er nóg að velja eða smíða viðeigandi útgáfu af gcc og nota krossþýðendur fyrir sérstakan arkitektúr og setja saman allt safnið af bókasöfnum. Þessi vinna er alveg framkvæmanleg, en nokkuð erfið. Og það er engin trygging fyrir því að valinn þýðandi og bókasöfn muni veita nothæfa útgáfu.
Augljós kostur: innviðirnir eru mjög einfaldaðir þar sem hægt er að klára allt byggingarferlið á einni vél. Að auki er nóg að safna einu setti af tvöföldum fyrir einn arkitektúr og þú getur pakkað þeim í pakka fyrir mismunandi dreifingu. Svona eru veeam pakkar smíðaðir fyrir Veeam Agent fyrir Linux.
Öfugt við þennan valkost geturðu einfaldlega undirbúið byggingabæ, það er nokkrar vélar til samsetningar. Hver slík vél mun útvega forritasamsetningu og pakkasamsetningu fyrir ákveðna dreifingu og sérstakan arkitektúr. Í þessu tilviki fer samantektin fram með aðferðum sem dreifingaraðilinn hefur útbúið. Það er, stigið að undirbúa þýðandann og velja bókasöfn er eytt. Að auki er auðvelt að samsíða byggingarferlið.
Það er hins vegar galli við þessa nálgun: fyrir hverja dreifingu innan sama arkitektúrs verður þú að safna þínu eigin setti af tvíundarskrám. Annar ókostur er að viðhalda þarf svo miklum fjölda véla og úthluta miklu plássi og vinnsluminni.
Svona eru KMOD pakkar af veeamsnap kjarnaeiningunni settir saman fyrir Red Hat dreifingu.
Opnaðu byggingaþjónustu
Samstarfsmenn frá SUSE reyndu að innleiða einhvern milliveg í formi sérstakrar þjónustu til að setja saman forrit og setja saman pakka - .
Í meginatriðum er það hypervisor sem býr til sýndarvél, setur upp alla nauðsynlega pakka í henni, setur saman forritið og smíðar pakkann í þessu einangraða umhverfi, eftir það er sýndarvélin gefin út.
Tímaáætlunin sem er útfærð í OpenBuildService mun ákvarða hversu margar sýndarvélar hann getur ræst fyrir hámarkshraða pakkabyggingar. Innbyggða undirritunarkerfið mun undirrita pakkana og hlaða þeim upp í innbyggðu geymsluna. Innbyggt útgáfustýringarkerfið mun vista sögu breytinga og smíða. Allt sem er eftir er einfaldlega að bæta heimildum þínum við þetta kerfi. Þú þarft ekki einu sinni að setja upp netþjóninn sjálfur; þú getur notað opinn.
Það er hins vegar vandamál: Slík uppskerutæki er erfitt að passa inn í núverandi innviði. Til dæmis er útgáfustýring ekki þörf; við höfum nú þegar okkar eigin fyrir frumkóða. Undirskriftarkerfi okkar er öðruvísi: við notum sérstakan netþjón. Geymsla er heldur ekki þörf.
Að auki er stuðningur við aðrar dreifingar - til dæmis Red Hat - frekar illa útfærðar, sem er skiljanlegt.
Kosturinn við slíka þjónustu er skjótur stuðningur við næstu útgáfu af SUSE dreifingunni. Fyrir opinbera tilkynningu um útgáfuna eru pakkarnir sem nauðsynlegir eru til samsetningar settir á opinbera geymslu. Ný birtist á listanum yfir tiltækar dreifingar á OpenBuildService. Við haka í reitinn og hann er bætt við byggingaráætlunina. Þannig er bætt við nýrri útgáfu af dreifingunni með næstum einum smelli.
Í innviðum okkar, með því að nota OpenBuildService, er allt úrval KMP pakka af veeamsnap kjarnaeiningunni fyrir SUSE dreifingar sett saman.
Næst langar mig að staldra við málefni sem eru sérstaklega við kjarnaeiningar.
kjarna ABI
Linux kjarnaeiningum hefur í gegnum tíðina verið dreift í upprunaformi. Staðreyndin er sú að höfundar kjarnans íþyngja sér ekki með áhyggjum af því að styðja við stöðugt API fyrir kjarnaeiningar, og sérstaklega á tvíundarstigi, frekar nefnt kABI.
Til að búa til einingu fyrir vanillukjarna þarftu örugglega hausana á þessum tiltekna kjarna, og það mun aðeins virka á þessum kjarna.
DKMS gerir þér kleift að gera sjálfvirkan ferlið við að byggja einingar þegar þú uppfærir kjarnann. Þess vegna nota notendur Debian geymslunnar (og margir ættingjar hennar) kjarnaeiningar annaðhvort úr geymslu dreifingaraðilans eða settar saman úr uppruna með DKMS.
Hins vegar hentar þetta ástand ekki sérstaklega Enterprise-hlutanum. Dreifingaraðilar með sérkóða vilja dreifa vörunni sem samansettum tvíþættum.
Stjórnendur vilja ekki hafa þróunarverkfæri á framleiðsluþjónum af öryggisástæðum. Enterprise Linux dreifingaraðilar eins og Red Hat og SUSE ákváðu að þeir gætu stutt stöðugt kABI fyrir notendur sína. Niðurstaðan var KMOD pakkar fyrir Red Hat og KMP pakkar fyrir SUSE.
Kjarninn í þessari lausn er frekar einfaldur. Fyrir tiltekna útgáfu af dreifingunni er kjarna API frosinn. Dreifingaraðilinn tekur fram að hann noti kjarnann, til dæmis 3.10, og gerir aðeins leiðréttingar og endurbætur sem hafa ekki áhrif á kjarnaviðmótin og einingarnar sem safnað er fyrir fyrsta kjarnann er hægt að nota fyrir alla síðari án endursamsetningar.
Red Hat heldur því fram að kABI samhæfi dreifinguna í gegnum allan lífsferilinn. Það er að segja að samsetta einingin fyrir rhel 6.0 (útgáfa nóvember 2010) ætti einnig að virka á útgáfu 6.10 (útgáfa júní 2018). Og þetta eru næstum 8 ár. Auðvitað er þetta verkefni frekar erfitt.
Við höfum skráð nokkur tilvik þar sem veeamsnap einingin hætti að virka vegna kABI-samhæfisvandamála.
Eftir að veeamsnap einingin, unnin fyrir RHEL 7.0, reyndist vera ósamrýmanleg kjarnanum frá RHEL 7.5, en hún hleðst inn og var tryggt að þjónninn hrundi, hættum við alfarið að nota kABI samhæfni fyrir RHEL 7.
Eins og er, inniheldur KMOD pakkinn fyrir RHEL 7 samsetningu fyrir hverja útgáfuútgáfu og skriftu sem hleður einingunni.
SUSE fór varlega í verkefnið kABI samhæfni. Þeir veita kABI samhæfni aðeins innan eins þjónustupakka.
Til dæmis, útgáfa SLES 12 átti sér stað í september 2014. Og SLES 12 SP1 var þegar í desember 2015, það er aðeins meira en ár er liðið. Jafnvel þó að báðar útgáfurnar noti 3.12 kjarnann eru þær kABI ósamrýmanlegar. Augljóslega er miklu auðveldara að viðhalda kABI samhæfni í aðeins eitt ár. Hin árlega uppfærsluferill kjarnaeiningar ætti ekki að valda vandamálum fyrir höfunda eininga.
Sem afleiðing af þessari SUSE stefnu höfum við ekki skráð eitt einasta vandamál með kABI samhæfni í veeamsnap einingunni okkar. Að vísu er fjöldi pakka fyrir SUSE næstum stærðargráðu meiri.
Plástrar og bakhliðar
Þrátt fyrir að dreifingaraðilar reyni að tryggja kABI eindrægni og kjarnastöðugleika, reyna þeir einnig að bæta árangur og útrýma göllum þessa stöðuga kjarna.
Á sama tíma, auk þeirra eigin „vinnu við villur“, fylgjast þróunaraðilar Linux fyrirtækjakjarna með breytingum á vanillukjarnanum og flytja þær yfir í „stöðuga“ þeirra.
Stundum leiðir þetta til nýrra .
Í nýjustu útgáfu Red Hat 6 voru mistök gerð í einni af minniháttar uppfærslunum. Það leiddi til þess að tryggt var að veeamsnap einingin hrundi kerfinu þegar skyndimyndin var birt. Eftir að hafa borið saman kjarnaheimildirnar fyrir og eftir uppfærsluna komumst við að því að bakportinu var um að kenna. Svipuð lagfæring var gerð í vanillukjarna útgáfu 4.19. Það er bara það að þessi lagfæring virkaði fínt í vanillukjarnanum, en þegar hann var fluttur yfir í „stöðugleikann“ 2.6.32 kom upp vandamál með snúningslásinn.
Auðvitað eru alltaf allir með villur, en var það þess virði að draga kóðann frá 4.19 í 2.6.32, hætta á stöðugleika?.. ég er ekki viss...
Það versta er þegar markaðssetning tekur þátt í togstreitu milli „stöðugleika“ og „nútímavæðingar“. Markaðsdeildin þarf að kjarni uppfærðrar dreifingar sé annars vegar stöðugur og á sama tíma betri í afköstum og nýrri eiginleika. Þetta leiðir til undarlegra málamiðlana.
Þegar ég reyndi að byggja einingu á kjarna 4.4 frá SLES 12 SP3, kom mér á óvart að finna virkni frá vanillu 4.8 í henni. Að mínu mati er blokk I/O útfærslan á 4.4 kjarnanum frá SLES 12 SP3 líkari 4.8 kjarnanum en fyrri útgáfan af stöðugum 4.4 kjarnanum frá SLES12 SP2. Ég get ekki dæmt um hvaða prósentu af kóða var flutt úr kjarna 4.8 í SLES 4.4 fyrir SP3, en ég get ekki einu sinni kallað kjarnann sama stöðugan 4.4.
Það óþægilegasta við þetta er að þegar þú skrifar einingu sem myndi virka jafn vel á mismunandi kjarna geturðu ekki lengur treyst á kjarnaútgáfuna. Einnig þarf að taka tillit til dreifingarinnar. Það er gott að stundum geturðu tekið þátt í skilgreiningu sem birtist ásamt nýrri virkni, en þetta tækifæri birtist ekki alltaf.
Fyrir vikið verður kóðinn ofvaxinn af undarlegum skilyrtum samantektartilskipunum.
Það eru líka plástrar sem breyta skjalfestu kjarna API.
Ég rakst á dreifinguna 5.16 og var mjög hissa að sjá að lookup_bdev kallið í þessari kjarnaútgáfu breytti listanum yfir innsláttarfæribreytur.
Til að ná því saman þurfti ég að bæta skriftu við makefile sem athugar hvort lookup_bdev fallið hafi mask breytu.
Undirritun kjarnaeiningar
En snúum okkur aftur að útgáfu pakkadreifingar.
Einn af kostunum við stöðugt kABI er að hægt er að undirrita kjarnaeiningar sem tvíundarskrá. Í þessu tilviki getur verktaki verið viss um að einingin hafi ekki verið skemmd fyrir slysni eða breytt af ásetningi. Þú getur athugað þetta með modinfo skipuninni.
Red Hat og SUSE dreifingar gera þér kleift að athuga undirskrift einingarinnar og hlaða henni aðeins ef samsvarandi vottorð er skráð á kerfið. Vottorðið er opinberi lykillinn sem einingin er undirrituð með. Við dreifum því sem sérstakan pakka.
Vandamálið hér er að vottorð er annað hvort hægt að byggja inn í kjarnann (dreifingaraðilar nota þau) eða verða að vera skrifuð í EFI óstöðugt minni með því að nota tól mokutil. Gagnsemi mokutil Þegar þú setur upp vottorð krefst það þess að þú endurræsir kerfið og, jafnvel áður en stýrikerfiskjarna er hlaðið, biður stjórnandinn um að leyfa hleðslu á nýju vottorði.
Þannig að bæta við vottorði krefst líkamlegs stjórnandaaðgangs að kerfinu. Ef vélin er staðsett einhvers staðar í skýinu eða einfaldlega í ytra netþjónaherbergi og aðgangur er aðeins í gegnum netið (til dæmis í gegnum ssh), þá verður ómögulegt að bæta við vottorði.
EFI á sýndarvélum
Þrátt fyrir þá staðreynd að EFI hefur lengi verið stutt af næstum öllum móðurborðsframleiðendum, þegar kerfi er sett upp, gæti stjórnandinn ekki hugsað um þörfina fyrir EFI og það gæti verið óvirkt.
Það eru ekki allir hypervisorar sem styðja EFI. VMWare vSphere styður EFI frá og með útgáfu 5.
Microsoft Hyper-V fékk einnig EFI stuðning og byrjaði með Hyper-V fyrir Windows Server 2012R2.
Hins vegar, í sjálfgefna stillingu, er þessi virkni óvirk fyrir Linux vélar, sem þýðir að ekki er hægt að setja upp vottorðið.
Í vSphere 6.5, stilltu valkostinn Öruggt stígvél aðeins mögulegt í gömlu útgáfunni af vefviðmótinu, sem keyrir í gegnum Flash. Vefviðmót á HTML-5 er enn langt á eftir.
Tilraunadreifingar
Og að lokum skulum við íhuga málið með tilraunadreifingu og dreifingu án opinbers stuðnings. Annars vegar er ólíklegt að slíkar dreifingar finnist á netþjónum alvarlegra stofnana. Það er enginn opinber stuðningur við slíkar dreifingar. Því gefðu þær. Ekki er hægt að styðja vöruna við slíka dreifingu.
Hins vegar verða slíkar dreifingar hentugur vettvangur til að prófa nýjar tilraunalausnir. Til dæmis, Fedora, OpenSUSE Tumbleweed eða Óstöðugar útgáfur af Debian. Þeir eru nokkuð stöðugir. Þeir eru alltaf með nýjar útgáfur af forritum og alltaf nýjan kjarna. Eftir eitt ár gæti þessi tilraunavirkni endað í uppfærðri RHEL, SLES eða Ubuntu.
Þannig að ef eitthvað virkar ekki á tilraunadreifingu er þetta ástæða til að finna út vandamálið og leysa það. Þú þarft að vera tilbúinn fyrir þá staðreynd að þessi virkni mun brátt birtast á framleiðsluþjónum notenda.
Þú getur skoðað núverandi lista yfir opinberlega studdar dreifingar fyrir útgáfu 3.0 . En raunverulegur listi yfir dreifingar sem varan okkar getur unnið á er miklu breiðari.
Persónulega hafði ég áhuga á tilrauninni með Elbrus OS. Eftir að hafa gengið frá veeam pakkanum var varan okkar sett upp og virkað. Ég skrifaði um þessa tilraun á Habré í .
Jæja, stuðningur við nýjar dreifingar heldur áfram. Við erum að bíða eftir útgáfu 4.0 til að koma út. Beta er um það bil að birtast, svo fylgstu með !
Heimild: www.habr.com