Šajā rakstā tiks atklāts.

Izveidot dublēšanas lietotni, kas darbojas jebkurā izplatījumā — tas ir sarežģīts uzdevums. Lai nodrošinātu Veeam Agent for Linux darbību izplatījumos no Red Hat 6 un Debian 6 līdz OpenSUSE 15.1 un Ubuntu 19.04, ir jārisina daudzas problēmas, īpaši ņemot vērā, ka programmatūras produktā ir iekļauts kodola modulis.

Raksts izveidots, pamatojoties uz uzstāšanos konferencē LinuxPiter 2019.

Linux — tā nav tikai viena no populārākajām OS. Faktiski tā ir platforma, uz kuras var izveidot kaut ko unikālu, kaut ko savu. Šī iemesla dēļ Linux ir daudz izplatījumu, kas atšķiras ar programmatūras komponentu komplektu. Un šeit rodas problēma: lai programmatūras produkts darbotos jebkurā izplatījumā, ir jāpatur prātā katra izplatījuma īpatnības.

Paketēšanas pārvaldnieki. .deb vs .rpm

Sāksim ar acīmredzamo problēmu produkta izplatīšanā dažādos izplatījumos.
Pats tipiskākais veids, kā izplatīt programmatūras produktus, ir augšupielādēt paketi repozitorijā, lai iebūvētais sistēmas paketēšanas pārvaldnieks varētu to no turienes instalēt.
Tomēr mums ir divi populāri pakotņu formāti: rpm un deb. Tas nozīmē, ka būs jāatbalsta katrs.

Deb-pakotņu pasaulē saderības līmenis ir pārsteidzošs. Viena un tā pati pakete vienādi labi tiek instalēta un darbojas gan Debian 6, gan Ubuntu 19.04. Pakotņu veidošanas un apstrādes procesi, kas noteikti vecajos Debian izplatījumos, joprojām ir aktuāli arī modernajos Linux Mint un elementary OS. Tādēļ Veeam Agent for Linux gadījumā pietiek ar vienu deb-paketi katrai aparatūras platformai.

Savukārt rpm-pakotņu pasaulē atšķirības ir lielas. Pirmkārt, tāpēc, ka ir divi pilnīgi neatkarīgi izplatītāji Red Hat un SUSE, kurām nav nepieciešama saderība. Otrkārt, šiem izplatītājiem ir izplatījumi ar tehnisko atbalstu un eksperimentālie. Starp tiem saderība arī nav nepieciešama. Mums ir izveidojušies paketi el6, el7 un el8. Atsevišķa pakete Fedora. Paketes SLES11 un 12 un atsevišķa openSUSE. Galvenā problēma — atkarībās un pakotņu nosaukumos.

Atkarību problēma

Diemžēl vienas un tās pašas paketes bieži ir ar dažādiem nosaukumiem dažādos izplatījumos. Zemāk ir nepilnīgs veeam paketes atkarību saraksts.

EL7 gadījumā:
SLES 12 gadījumā:

• 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

Kā rezultātā atkarību saraksts izrādās unikāls katram izplatījumam.

Sliktāk ir tad, kad zem vecā pakotnes nosaukuma sāk slēpties atjaunināta versija.

IsClosed = 0 AND Canceled = 0 AND Enabled = 0

Fedora 24 ir atjaunināta pakotne ncurses no 5. versijas uz 6. versiju. Mūsu produkts tika veidots tieši ar 5. versiju, lai nodrošinātu saderību ar vecajiem izplatījumiem. Lai izmantotu veco 5. versiju bibliotēkas Fedora 24, bija jāizmanto pakotne ncurses-compat-libs.

Kā rezultātā Fedora parādās divas pakotnes ar dažādām atkarībām.

Tālāk interesantāk. Pēc kārtējā izplatījuma atjauninājuma pakotne ncurses-compat-libs ar 5. versijas bibliotēku izrādās nepieejama. Izplatītājam ir neizdevīgi turēt vecās bibliotēkas jaunajā izplatījumā. Pēc kāda laika problēma atkārtojās arī SUSE izplatījumos.

Kā rezultātā dažiem izplatījumiem nācās atteikties no acīmredzamas atkarības no ncurses-libs, un produktu labot tā, lai tas varētu strādāt ar jebkuru bibliotēkas versiju.

Starpcitu, 8. versijā Red Hat vairs nav meta-pakotnes python, kas atsaucās uz veco labu python 2.7. Ir python2 un python3.

Alternatīva pakotņu pārvaldniekiem

Problēma ar atkarībām ir sena un jau sen acīmredzama. Atcerēsimies vismaz Dependency hell.
Apvienot dažādas bibliotēkas un lietojumprogrammas tā, lai tās visas stabilitāti strādātu un nesadzītu — īsumā, šo uzdevumu centās risināt ikviens Linux izplatītājs.

Pilnīgi citādi šo problēmu centās risināt pakotņu pārvaldnieks Snappy no Canonical. Galvenā ideja: lietojumprogramma tiek izpildīta izolētā un aizsargātā smilšu kastē. Ja lietojumprogrammai ir nepieciešamas bibliotēkas, tad tās tiek piegādātas kopā ar pašu lietojumprogrammu.

Flatpak tāpat ļauj palaist lietojumprogrammas smilšu kastē, izmantojot Linux Containers. Smilšu kastes ideju izmanto arī AppImage.

Šie risinājumi ļauj izveidot vienu pakotni jebkuriem izplatījumiem. Gadījumā ar Flatpak uzstādīšana un lietojumprogrammas palaišana ir iespējama pat bez administratora zināšanām.

Galvenā problēma ir tā, ka ne visas lietojumprogrammas var darboties smilšu kastē. Dažām nepieciešama tieša piekļuve platformai. Jau nerunājot par kodola moduļiem, kas stingri atkarīgi no kodola un jau nemaz neietilpst smilšu kastes konceptā.

Otrā problēma – populārie enterprise vidē izplatījumi no Red Hat un SUSE vēl nevar atbalstīt Snappy un Flatpak.

Šī iemesla dēļ Veeam Agent for Linux nav ne uz snapcraft.io ne uz flathub.org.

Noslēdzot jautājumu par pakotņu pārvaldniekiem, varu piebilst, ka pastāv iespēja pilnībā atteikties no pakotņu pārvaldniekiem, apvienojot vienā pakotnē binārās failus un skriptu to uzstādīšanai.

Šāda pakotne ļauj izveidot vienu kopīgu pakotni dažādām distribūcijām un platformām, veicot interaktīvu uzstādīšanas procesu ar nepieciešamo pielāgošanu. Esmu saskāries ar tādām pakotnēm Linux vidē tikai no VMware.

Atjauninājumu problēma

Pat ja visas atkarību problēmas ir atrisinātas, programma var darboties atšķirīgi uz viena un tā paša distribūcijas. Problēma slēpjas atjauninājumos.

Ir 3 atjaunināšanas stratēģijas:

• Vienkāršākā ir nekad neatjaunināt. Uzstādiet serveri un aizmirstiet. Kāpēc atjauninājumi, ja viss strādā? Problēmas sākas, sazinoties ar atbalsta dienestu. Distribūcijas veidotājs atbalsta tikai jaunāko laidienu.
• Var uzticēties piegādātājam un iestatīt automātisko atjauninājumu. Šajā gadījumā zvans uz atbalsta dienestu ir iespējams tūlīt pēc neveiksmīga atjauninājuma.
• Rokas atjaunināšanas variants, tikai pēc tā testēšanas testēšanas infrastruktūrā, ir visdrošākais, taču dārgs un darbietilpīgs. Tālu ne visi to var atļauties.

Tā kā dažādi lietotāji izmanto dažādas atjaunināšanas stratēģijas, nepieciešams atbalstīt gan visjaunāko laidienu, gan visus iepriekšējos. Tas apgrūtina gan izstrādes procesu, gan testēšanu, radot galvassāpes atbalsta dienestam.

Dažādība aparatūras platformās

Dažādas aparatūras platformas ir problēma, kas lielā mērā ir specifiska tieši native kodam. Vismaz ir jāveido binārie faili katrai atbalstītai platformai.

Veeam Agent for Linux projektā mēs joprojām nevaram atbalstīt neko līdzīgu RISC.

Par šo jautājumu neizplūdu. Vienīgais, ko varu norādīt, ir galvenās problēmas: platformu atkarīgās tipos, piemēram, size_t, struktūru izlīdzināšana un byte order.

Statiskā un/vai dinamiskā saistīšana

Taču jautājums „Kā saistīties ar bibliotēkām — dinamiskā vai statiskā veidā?” ir vērts apspriest.

Parasti C/C++ lietojumprogrammas Linux vidē izmanto dinamisko saistīšanu. Tas lieliski darbojas gadījumā, ja lietojumprogramma ir speciāli izveidota konkrētai distribūcijai.

Ja, ja ir mērķis iekļaut dažādus distribūcijas ar vienu bināro failu, tad ir jāorientējas uz visvecāko atbalstīto distribūciju. Mums tas ir Red Hat 6. Tas satur gcc 4.4, kas pat nepilnīgi atbalsta C++11 standartus. pilnībā.

Mēs veidojam mūsu projektu, izmantojot gcc 6.3, kas pilnībā atbalsta C++14. Protams, šādā gadījumā uz Red Hat 6 ir jānodrošina, ka libstdc++ un boost bibliotēkas tiek iekļautas. Vienkāršāk ir saistīt ar tām statiski.

Diemžēl ne visas bibliotēkas var tikt saistītas statiski.

Vispirms, sistēmas bibliotēkas, piemēram, libfuse, libblkid ir jāsaista dinamiski, lai nodrošinātu to saderību ar kodolu un tā moduļiem.

Otrkārt, ir nianses ar licencēm.

GPL licence principā atļauj saistīt bibliotēkas tikai ar atvērta koda programmām. MIT un BSD atļauj statisko saistīšanu un ļauj iekļaut bibliotēkas projektā. Bet šķiet, ka LGPL nav pret statisko saistīšanu, bet prasa nodrošināt piekļuvi failiem, kas nepieciešami saistīšanai.

Vispārīgi runājot, dinamiskā saistīšana aizsargā no nepieciešamības kaut ko nodrošināt.

C/C++ programmu veidošana

Lai veidotu C/C++ programmas dažādām platformām un distribūcijām, pietiek izvēlēties vai savākt atbilstošu gcc versiju un izmantot krustkompilerus specifiskām arhitektūrām, sagatavot visu bibliotēku komplektu. Šis darbs ir pilnīgi īstenojams, taču diezgan apgrūtinošs. Un nav nekādu garantiju, ka izvēlētais kompilators un bibliotēkas nodrošinās darboties spējīgu versiju.

Acīmredzams ieguvums: infrastruktūra tiek ļoti vienkāršota, jo visu būvniecības procesu var veikt uz vienas mašīnas. Turklāt pietiek sagatavot vienu bināro failu komplektu vienai arhitektūrai, un var tos iepackot pakotēs dažādiem distribūcijām. Tieši tā tiek sagatavotas veeam paketes Veeam Agent for Linux.

Pretrunāšot šim variantam, var vienkārši sagatavot build fermu, proti, vairākas mašīnas kompilēšanai. Katrs šāds dators nodrošinās lietojumprogrammas kompilāciju un pakotnes izveidi konkrētam izplatījumam un noteiktai arhitektūrai. Šādā gadījumā kompilācija tiek veikta ar līdzekļiem, kurus sagatavojis izplatītājs. Tas nozīmē, ka kompilatora sagatavošanas un bibliotēku izvēles posms atkrīt. Turklāt izveides procesu var viegli paralelizēt.

Ir, protams, arī šāda pieejas trūkums: katram izplatījumam vienā arhitektūrā būs jāsavāc savs bināro failu komplekts. Tāpat trūkums ir tas, ka šādus pāru datorus jāapkalpo, jāizvieto liels disks un operatīvā atmiņa.

Tādējādi tiek veidotas KMOD paketes veeamsnap kodola moduliem Red Hat izplatījumiem.

Open Build Service

SUSE kolēģi mēģināja īstenot kādu zelta vidusceļu, izstrādājot īpašu pakalpojumu lietojumprogrammu kompilēšanai un pakotņu izveidei — openbuildservice.

Patiess, šis ir hipervizors, kas izveido virtuālo mašīnu, instalē tajā visus nepieciešamos pakotnē, veic lietojumprogrammas kompilāciju un pakotnes izveidi šajā izolētajā vidē, pēc tam šī virtuālā mašīna tiek atbrīvota.

OpenBuildService īstenotais plānotājs pats noteiks, cik virtuālo mašīnu tas var palaist, lai nodrošinātu optimālu pakotņu izveides ātrumu. Iebūvētais parakstīšanas mehānisms pats parakstīs pakotnes un ievietos tās iebūvētajā repozitorijā. Iebūvētā versiju kontroles sistēma saglabās izmaiņu un izveides vēsturi. Atliek tikai pievienot šai sistēmai savus avotus. Pat servera paaugstināšana nav obligāta, var izmantot atvērtu.

Tomēr šeit ir problēma: šāds kombains grūti iekļaujas esošajā infrastruktūrā. Piemēram, versiju kontrole nav nepieciešama, mums jau ir sava avotiem. Parakstīšanas mehānisms mūsu gadījumā atšķiras: tiek izmantots īpašs servers. Repozitorijs arī nav nepieciešams.

Turklāt citu izplatījumu atbalsts — piemēram, Red Hat — ir realizēts diezgan nabadzīgi, kas ir visai saprotami.

Šāda pakalpojuma priekšrocība ir ātra jaunākās SUSE izplatīšanas versijas atbalsts. Pirms oficiālās paziņošanas par izlaišanu nepieciešamās būvēšanas pakotnes tiek publicētas publiskajā repozitorijā. Jaunā izplatīšana tiek pievienota pieejamo izplatījumu sarakstam OpenBuildService. Ievietojam atzīmi, un tā tiek pievienota būvēšanas plānam. Tādējādi jaunās izplatīšanas versijas pievienošana notiek gandrīz ar vienu klikšķi.

Mūsu infrastruktūrā, izmantojot OpenBuildService, tiek būvēts viss KMP pakotņu klāsts veeamsnap moduļiem SUSE izplatījumiem.

Tālāk es vēlētos pievērsties jautājumiem, kas ir specifiski tieši kodola moduļiem.

kernel ABI

Linux kodola moduļi vēsturiski tika izplatīti kā avota kodi. Proti, kodola autori neuzņemas atbildību par stabila API atbalstu kodola moduļiem, īpaši binārā līmenī, tālāk kABI.

Lai uzbūvētu moduli vaniļas kodolam, ir obligāti nepieciešami tieši šī kodola header faili, un tas darbosies tikai uz šī kodola.

DKMS ļauj automatizēt moduļu būvēšanas procesu, atjauninot kodolu. Rezultātā Debian repozitoriju lietotāji (un viņa neskaitāmie radinieki) izmanto vai nu kodola moduļus no distributora repozitorija, vai no avotiem, kas tiek būvēti ar DKMS palīdzību.

Tomēr šāda situācija neapmierina Enterprise segmentu. Proprietāro kodu izplatītāji vēlas izplatīt produktu kā sagatavotus bināros failus.

Administratori nevēlas turēt izstrādes rīkus produkcijas serveros drošības apsvērumu dēļ. Enterprise Linux disponenti, piemēram, Red Hat un SUSE, ir nolēmuši, ka viņi spēs nodrošināt stabilu kABI saviem lietotājiem. Rezultātā tika izveidoti KMOD pakotnes Red Hat un KMP pakotnes SUSE.

Šāda risinājuma būtība ir diezgan vienkārša. Konkretizētai izplatīšanas versijai kodola API tiek sasaldēts. Distributors apgalvo, ka izmanto tieši kodolu, piemēram, 3.10, un veic tikai labojumus un uzlabojumus, kas nekādā veidā neietekmē kodola interfeisus, un sākotnējā kodola moduļi var tikt izmantoti visām nākamajām versijām bez pārbūves.

Red Hat paziņo par kABI saderību savam izsniegumam visa dzīves cikla laikā. Tas nozīmē, ka savāktais modulis RHEL 6.0 (izdots 2010. gada novembrī) arī darbosies versijā 6.10 (izdota 2018. gada jūnijā). Tas ir gandrīz 8 gadi. Protams, šis uzdevums ir diezgan sarežģīts.
Mēs esam reģistrējuši vairākus gadījumus, kad modulis veeamsnap pārstāja darboties kABI saderības problēmu dēļ.

Pēc tam, kad modulis veeamsnap, kas tika savākts RHEL 7.0, izrādījās nesaderīgs ar RHEL 7.5 kodolu, taču turpināja startēt un garantēti krita serveri, mēs atteicāmies no kABI saderības izmantošanas RHEL 7 vispār.

Pašlaik KMOD pakotne RHEL 7 satur savākšanu katrai izlaišanas versijai un skriptu, kas nodrošina moduļa ielādi.

SUSE pie kABI saderības uzdevuma ir piesardzīgāka. Tie nodrošina kABI saderību tikai viena servisa pakotnē.

Piemēram, SLES 12 izlaišana notika 2014. gada septembrī. Savukārt SLES 12 SP1 jau 2015. gada decembrī, tātad pagāja nedaudz vairāk nekā gads. Neskatoties uz to, ka abas versijas izmanto kodolu 3.12, tās nav kABI saderīgas. Acīmredzot, uzturēt kABI saderību vien tikai gadu ir ievērojami vieglāk. Gada modifikasiem kodola nesadarībai nevajadzētu radīt problēmas moduļu izstrādātājiem.

Galu galā, tādas politikas dēļ, ko piekopj SUSE, mēs neesam reģistrējuši nevienu kABI saderības problēmu mūsu modulim veeamsnap. Patiesībā, arī pakotņu skaits SUSE ir gandrīz par vienu kārtu lielāks.

Iegultie labojumi un atpakaļpārnesumi

Neskatoties uz to, ka izplatītāji cenšas nodrošināt kABI saderību un kodola stabilitāti, tie arī cenšas uzlabot veiktspēju un novērst stabilā kodola defektus.

Tajā pašā laikā, izņemot paša «klasikalistus» kodola izstrādātāji enterprise Linux seko izmaiņām vaniļas kodolā un pārnes tās uz savu «stabilo» versiju.

Dažkārt tas noved pie jauniem defektiem.

Pēdējā Red Hat 6 izlaidumā vienā no mazajām atjauninājumiem bija pieļauta kļūda. Tā radīja situāciju, kad modulis veeamsnap garantēti izraisa sistēmas sabrukšanu, kad tiek atbrīvots snapshots. Salīdzinot kodola avotus pirms un pēc atjaunināšanas, mēs noskaidrojām, ka viss bija atkarīgs no atpakaļpārcelšanas. Līdzīgs labojums tika veikts vaniļas kodolam 4.19. Bet vaniļas kodolā šis labojums darbojās normāli, kamēr to pārnesa uz «stabilo» 2.6.32 radās problēma ar spin-lock.

Protams, kļūdas rodas visiem un vienmēr, bet vai bija vērts vilkt kodu no 4.19 uz 2.6.32, riskējot ar stabilitāti?.. Es neesmu pārliecināts...

Sliktākā situācija ir tad, kad pie stīgas «stabilitāte»«modernizācija» pieslēdzas mārketings. Mārketinga nodaļai ir nepieciešams, lai atjaunotā sadalījuma kods būtu stabils, no vienas puses, un vienlaikus labāks veiktspējā un ar jaunām funkcijām. Tas noved pie dīvainiem kompromisiem.

Kad es mēģināju izveidot moduli uz kodola 4.4 no SLES 12 SP3, es ar pārsteigumu atklāju tajā funkcionalitāti no standarta 4.8. Manuprāt, bloķētā ievade/izvade kodolā 4.4 no SLES 12 SP3 vairāk atbilst kodolam 4.8 nekā iepriekšējai stabilā 4.4 versijai no SLES12 SP2. Es nevaru spriest, kāds bija pārvietotā koda procents no kodola 4.8 uz SLES-ovsku 4.4 SP3, taču saukt kodolu par stabilu 4.4 man valoda neļauj.

Visnepatīkamākais ir tas, ka rakstot moduli, kas vienādi labi strādātu uz dažādiem kodoliem, vairs nevar paļauties uz kodola versiju. Ir jāņem vērā arī sadalījums. Ir labi, ka dažreiz var paļauties uz definīciju, kas parādās kopā ar jauno funkcionalitāti, taču šāda iespēja ne vienmēr ir pieejama.

Rezultātā kods apaug ar dīvainām nosacītās kompilācijas direktīvām.

Sastopami arī ielāpi, kas maina dokumentēto kodola API.
Uzgāju sadalījumu KDE neon 5.16 un biju ļoti pārsteigts, redzot, ka izsaukuma lookup_bdev šajā kodola versijā tika mainīti ieejas parametru saraksts.

Lai izveidotos, nācās makefile pievienot skriptu, kas pārbauda, vai ir parametrs mask funkcijā lookup_bdev.

Kodolmoduļu paraksts

Bet atgriezīsimies pie jautājuma par pakotņu izplatīšanu.

Viens no stabilā kABI priekšrocībām ir tas, ka kodola moduļus binārā faila veidā var parakstīt. Šādā gadījumā izstrādātājs var būt pārliecināts, ka modulis nav nejauši bojāts vai apzināti izmainīts. To var pārbaudīt ar komandu modinfo.

Red Hat un SUSE sadalījumi ļauj pārbaudīt moduļa parakstu un ielādēt to tikai tad, ja sistēmā ir reģistrēts attiecīgais sertifikāts. Sertifikāts ir publiskais atslēga, ar kuru paraksta moduli. Mēs to izplatām kā atsevišķu pakotni.

Problēma ir tāda, ka sertifikāti var būt vai nu iebūvēti kodolā (tos izmanto izplatītāji), vai arī tie jāieraksta enerģijas neatkarīgā EFI atmiņā, izmantojot utilītu. mokutil. Rīks mokutil Sertifikāta uzstādīšanas laikā ir nepieciešama sistēmas restartēšana, un vēl pirms operētājsistēmas kodola ielādes tiek piedāvāts administratoram atļaut jaunā sertifikāta ielādi.

Tādējādi sertifikāta pievienošanai ir nepieciešama administratora fiziska piekļuve sistēmai. Ja mašīna atrodas kaut kur mākoņos vai vienkārši attālinātā serverī, un piekļuve ir tikai pa tīklu (piemēram, pa ssh), tad sertifikātu pievienot nebūs iespējams.

EFI virtuālajās mašīnās

Neskatoties uz to, ka EFI jau sen atbalsta gandrīz visi mātesplatņu ražotāji, uzstādot sistēmu, administrators var nepadomāt par EFI nepieciešamību, un tas var būt izslēgts.

Ne visi hipervizori atbalsta EFI. VMWare vSphere atbalsta EFI, sākot no versijas 5.
Microsoft Hyper-V arī ir ieguvis EFI atbalstu, sākot ar Hyper-V Windows Server 2012R2.

Tomēr noklusējuma konfigurācijā šī funkcionalitāte Linux mašīnām ir atslēgta, tāpēc sertifikātu uzstādīt nav iespējams.

vSphere 6.5 opciju Secure Boot var iestatīt tikai vecajā versijā tīmekļa saskarnes, kas darbojas caur Flash. HTML-5 tīmekļa saskarne joprojām ievērojami atpaliek.

Eksperimentālās distribūcijas

Un visbeidzot aplūkosim eksperimentālo distribūciju un distribūciju bez oficiālas atbalsta jautājumu. No vienas puses, šādas distribūcijas, visticamāk, netiks sastaptas nopietnu organizāciju serveros. Oficiāla atbalsta šādām distribūcijām nav. Tāpēc tehnisko atbalstu šādam produktam nodrošināt nav iespējams.

Tomēr šādas distribūcijas kļūst par ērtiem laukumiem jauno eksperimentālo risinājumu izmēģināšanai. Piemēram, Fedora, OpenSUSE Tumbleweed vai Debian nestabila versija. Tās ir diezgan stabilas. Tajās vienmēr ir jaunas programmu versijas un vienmēr jauns kodols. Pēc gada šī eksperimentālā funkcionalitāte var parādīties atjauninātajā RHEL, SLES vai Ubuntu.

Tātad, ja kaut kas nedarbojas eksperimentālajā distribūcijā, tas ir iemesls izpētīt problēmu un to atrisināt. Jābūt gatavam tam, ka šī funkcionalitāte drīz parādīsies lietotāju ražotāja serveros.

Eso, kas šobrīd ir oficiāli atbalstītu izplatījumu saraksts versijai 3.0, varat izpētīt šeit. Tomēr reālais izplatījumu saraksts, uz kuriem mūsu produkts var strādāt, ir ievērojami plašāks.

Man personīgi bija interesants eksperimentēt ar OS "Elbrus". Pēc veidlapas veidošanas ar veeam mūsu produkts tika uzstādīts un strādāja. Par šo eksperimentu es rakstīju Habrā rakstā.

Jaunāku izplatījumu atbalsts turpinās. Mēs gaidām versijas 4.0 iznākšanu. Līdz drīz parādīsies beta versija, tāpēc sekojiet līdzi whats-new!

Avots: habr.com