Izveidot rezerves kopēšanas lietojumprogrammu, kas darbojas jebkurā izplatījumā, ir sarežģīts uzdevums. Lai nodrošinātu Veeam Agent darbību Linux uz Red Hat 6 izplatījumiem un Debian 6, līdz pat OpenSUSE 15.1 un Ubuntu 19.04 versijai ir jārisina virkne problēmu, īpaši ņemot vērā, ka programmatūras produkts ietver kodola moduli.
Raksts tapis, balstoties uz konferencē uzstāšanās materiāliem .
Linux — tā nav tikai viena no populārākajām operētājsistēmām. Tā būtībā ir platforma, uz kuras var izveidot kaut ko unikālu, kaut ko savu. Pateicoties tam, Linux Ir daudz distributīvu, katram no tiem ir atšķirīgs programmatūras komponentu komplekts. Un te nu rodas problēma: lai programmatūras produkts darbotos jebkurā distributīvā, ir jāņem vērā katras konkrētās versijas īpatnības.
Pakešu vadītāji. .deb pret .rpm
Sāksim ar acīmredzamo problēmu, kas saistīta ar produkta izplatīšanu dažādos izplatījumos.
Tipiskākais programmatūras produktu izplatīšanas veids ir pakotnes ievietošana repozitorijā, lai sistēmā iebūvētais pakotņu pārvaldnieks to varētu instalēt no turienes.
Tomēr mums ir divi populāri pakotņu formāti: rpm и deb. Tas nozīmē, ka ikvienam būs jāatbalsta.
Deb pakotņu pasaulē saderības līmenis ir pārsteidzošs. Viena un tā pati pakotne instalējas un darbojas vienlīdz labi abos Debian 6 un tālāk Ubuntu 19.04. Standarti pakotņu veidošanas procesam un darbam ar tiem, kas noteikti vecajā dokumentā Debian sadalījumiem, joprojām ir aktuāli jaunmodīgos Linux Mint un elementary OS. Tāpēc Veeam Agent gadījumā Linux Katrai aparatūras platformai pietiek ar vienu deb pakotni.
Taču apgriezienu skaita pakeš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, kuriem saderība ir pilnīgi nevajadzīga. Otrkārt, šiem izplatītājiem ir izplatīšanas komplekti no tiem. atbalsts un eksperimentāls. Arī starp tām nav nepieciešama saderība. Izrādījās, ka el6, el7 un el8 ir savi iepakojumi. Atsevišķa pakotne Fedora. SLES11 un 12 pakotnes un atsevišķa openSUSE. Galvenā problēma ir atkarības un pakotņu nosaukumi.
Atkarības problēma
Diemžēl vienas un tās pašas pakotnes dažādos izplatījumos bieži nonāk ar dažādiem nosaukumiem. Zemāk ir daļējs veeam pakotņu atkarību saraksts.
EL7:
SLES 12:
- liblkid
- libgcc
- libstdc++
- ncurses-libs
- drošinātājs-libs
- file-libs
- veeamsnap=3.0.2.1185
- liblkid1
- libgcc_s1
- libstdc ++ 6
- libmagic1
- libfuse2
- veeamsnap-kmp=3.0.2.1185
Tā rezultātā atkarību saraksts ir unikāls izplatīšanai.
Sliktāk ir tas, ka atjauninātā versija sāk slēpties zem vecā pakotnes nosaukuma.
Piemērs:
Pakotne ir atjaunināta Fedora 24 ncurs no 5. versijas uz 6. versiju. Mūsu produkts tika izveidots ar 5. versiju, lai nodrošinātu saderību ar vecākiem izplatījumiem. Lai Fedora 5 izmantotu veco bibliotēkas 24. versiju, man bija jāizmanto pakotne ncurses-compat-libs.
Rezultātā Fedora ir divas pakotnes ar dažādām atkarībām.
Vēl interesantāk. Pēc nākamā izplatīšanas atjauninājuma pakotne ncurses-compat-libs ar bibliotēkas 5. versiju izrādās, ka tā nav pieejama. Izplatītājam ir dārgi ievilkt vecās bibliotēkas jaunā izplatīšanas versijā. Pēc kāda laika problēma atkārtojās SUSE izplatījumos.
Tā rezultātā dažiem izplatījumiem bija jāatsakās no tiešās atkarības ncurses-libsun labojiet produktu, lai tas varētu darboties ar jebkuru bibliotēkas versiju.
Starp citu, Red Hat 8. versijā vairs nav meta pakotnes pitons, kas atsaucās uz veco labo python 2.7. Ir python2 и pitons3.
Alternatīva pakotņu pārvaldniekiem
Atkarību problēma ir sena un jau sen ir acīmredzama. Vienkārši atcerieties atkarības elli.
Dažādu bibliotēku un lietojumprogrammu apvienošana, lai tās visas darbotos stabili un nekonfliktētu, faktiski ir uzdevums, ko cenšas atrisināt katrs izplatītājs. Linux.
Pakešu pārvaldnieks mēģina atrisināt šo problēmu pavisam citā veidā. Snappy no Canonical. Galvenā ideja: lietojumprogramma darbojas smilšu kastē, kas izolēta un aizsargāta no galvenās sistēmas. Ja lietojumprogrammai ir nepieciešamas bibliotēkas, tās tiek piegādātas kopā ar pašu lietojumprogrammu.
Flatpak Tas arī ļauj palaist lietojumprogrammas smilškastē, izmantojot Linux Konteineri. Smilškastes ideju izmanto arī AppImage.
Šie risinājumi ļauj izveidot vienu pakotni jebkurai izplatīšanai. Gadījumā, ja Flatpak lietojumprogrammas instalēšana un palaišana ir iespējama pat bez administratora ziņas.
Galvenā problēma ir tā, ka ne visas lietojumprogrammas var darboties smilšu kastē. Dažiem cilvēkiem ir nepieciešama tieša piekļuve platformai. Es pat nerunāju par kodola moduļiem, kas ir stingri atkarīgi no kodola un neietilpst smilšu kastes koncepcijā.
Otra problēma ir tāda, ka uzņēmuma vidē populārie izplatījumi no Red Hat un SUSE vēl neietver Snappy un Flatpak atbalstu.
Šajā sakarā Veeam aģents Linux nav neviena nav ieslēgts .
Noslēdzot jautājumu par pakotņu pārvaldniekiem, vēlos atzīmēt, ka ir iespēja pilnībā atteikties no pakotņu pārvaldniekiem, apvienojot bināros failus un skriptu to instalēšanai vienā pakotnē.
Šis komplekts ļauj izveidot vienu, kopīgu pakotni dažādiem izplatījumiem un platformām, veikt interaktīvu instalēšanas procesu un ieviest nepieciešamo pielāgošanu. Esmu saskāries ar šādām pakotnēm, piemēram, Linux tikai no VMware.
Atjaunināšanas problēma
Pat ja visas atkarības problēmas ir atrisinātas, programma vienā un tajā pašā izplatīšanā var darboties atšķirīgi. Tas ir atjauninājumu jautājums.
Ir 3 atjaunināšanas stratēģijas:
- Vienkāršākais ir nekad neatjaunināt. Es uzstādīju serveri un aizmirsu par to. Kāpēc atjaunināt, ja viss darbojas? Problēmas rodas, pirmo reizi sazinoties ar atbalsta dienestu. Izplatījuma veidotājs atbalsta tikai atjaunināto versiju.
- Varat uzticēties izplatītājam un iestatīt automātiskos atjauninājumus. Šādā gadījumā atbalsta zvans, visticamāk, tūlīt pēc neveiksmīgas atjaunināšanas.
- Manuālas atjaunināšanas iespēja tikai pēc tās palaišanas testa infrastruktūrā ir visdrošākā, taču dārga un laikietilpīga. Ne visi to var atļauties.
Tā kā dažādi lietotāji izmanto dažādas atjaunināšanas stratēģijas, ir jāatbalsta gan jaunākā versija, gan visas iepriekš izlaistas. Tas sarežģī gan izstrādes, gan testēšanas procesu un sagādā galvassāpes atbalsta komandai.
Dažādas aparatūras platformas
Dažādas aparatūras platformas ir problēma, kas lielā mērā ir raksturīga vietējam kodam. Vismaz jums ir jāapkopo binārie faili katrai atbalstītajai platformai.
Veeam aģenta projektā Linux Mēs joprojām nevaram atbalstīt neko RISC līdzīgu.
Sīkāk pie šī jautājuma nekavēšos. Es tikai iezīmēšu galvenās problēmas: no platformas atkarīgie veidi, piemēram, size_t, struktūras izlīdzināšana un baitu secība.
Statiskā un/vai dinamiskā saistīšana
Bet jautājums ir "Kā izveidot saiti ar bibliotēkām - dinamiski vai statiski?" diskusiju vērts.
Parasti C/C++ lietojumprogrammas ir Linux Izmantojiet dinamisko saistīšanu. Tas lieliski darbojas, ja lietojumprogramma ir īpaši izstrādāta konkrētam izplatījumam.
Ja uzdevums ir aptvert dažādus izplatījumus ar vienu bināro failu, tad jākoncentrējas uz vecāko atbalstīto izplatīšanu. Mums tas ir Red Hat 6. Tajā ir gcc 4.4, ko neatbalsta pat C++11 standarts. .
Mēs veidojam savu projektu, izmantojot gcc 6.3, kas pilnībā atbalsta C++14. Protams, šajā gadījumā Red Hat 6 jums ir jānēsā līdzi libstdc++ un jāpalielina bibliotēkas. Vienkāršākais veids ir izveidot saiti ar tiem statiski.
Bet diemžēl ne visas bibliotēkas var saistīt statiski.
Pirmkārt, sistēmas bibliotēkas, piemēram, libfuse, liblkid ir nepieciešams dinamiski saistīt, lai nodrošinātu to saderību ar kodolu un tā moduļiem.
Otrkārt, ar licencēm ir smalkums.
GPL licence pamatā ļauj saistīt bibliotēkas tikai ar atvērtā pirmkoda kodu. MIT un BSD nodrošina statisku saiti un ļauj projektā iekļaut bibliotēkas. Taču šķiet, ka LGPL nav pretrunā ar statisko saistīšanu, bet prasa, lai saistīšanai nepieciešamie faili tiktu koplietoti.
Parasti dinamiskās saistīšanas izmantošana neļaus jums neko nodrošināt.
C/C++ lietojumprogrammu veidošana
Lai izveidotu C/C++ lietojumprogrammas dažādām platformām un izplatījumiem, pietiek atlasīt vai izveidot piemērotu gcc versiju un izmantot savstarpējos kompilatorus konkrētām arhitektūrām un apkopot visu bibliotēku komplektu. Šis darbs ir diezgan iespējams, bet diezgan apgrūtinošs. Un nav garantijas, ka izvēlētais kompilators un bibliotēkas nodrošinās funkcionējošu versiju.
Acīmredzama priekšrocība: infrastruktūra ir ievērojami vienkāršota, jo visu būvēšanas procesu var veikt vienā datorā. Turklāt pietiek izveidot vienu bināro failu komplektu vienai arhitektūrai, un tos var iepakot dažādiem izplatījumiem. Tieši tā Veeam iepako Veeam Agent Linux.
Atšķirībā no šīs iespējas, jūs varat vienkārši sagatavot fermu, tas ir, vairākas mašīnas montāžai. Katra šāda iekārta nodrošinās lietojumprogrammu apkopošanu un pakotņu montāžu konkrētam izplatīšanai un noteiktai arhitektūrai. Šajā gadījumā apkopošana tiek veikta, izmantojot izplatītāja sagatavotos līdzekļus. Tas ir, kompilatora sagatavošanas un bibliotēku atlases posms ir izslēgts. Turklāt veidošanas procesu var viegli paralēli.
Tomēr šai pieejai ir arī negatīva puse: katram izplatījumam vienā un tajā pašā arhitektūrā jums būs jāsavāc savs bināro failu kopums. Vēl viens mīnuss ir tāds, ka ir jāuztur tik liels mašīnu skaits un jāpiešķir daudz vietas diskā un RAM.
Šādi tiek apkopotas veeamsnap kodola moduļa KMOD pakotnes Red Hat izplatījumiem.
Atveriet Build Service
Kolēģi no SUSE mēģināja ieviest kādu vidusceļu īpaša pakalpojuma veidā lietojumprogrammu apkopošanai un pakotņu komplektēšanai - .
Būtībā tas ir hipervizors, kas izveido virtuālo mašīnu, instalē tajā visas nepieciešamās pakotnes, apkopo aplikāciju un izveido pakotni šajā izolētajā vidē, pēc kā tiek atbrīvota virtuālā mašīna.
Pakalpojumā OpenBuildService ieviestais plānotājs noteiks, cik virtuālo mašīnu tas var palaist optimālam pakotņu veidošanas ātrumam. Iebūvētais parakstīšanas mehānisms parakstīs pakotnes un augšupielādēs tās iebūvētajā repozitorijā. Iebūvētā versiju kontroles sistēma saglabās izmaiņu un būvējumu vēsturi. Atliek vienkārši pievienot savus avotus šai sistēmai. Jums pat nav pašam jāiestata serveris; varat izmantot atvērtu.
Tomēr ir problēma: šādu harvesteru ir grūti iekļaut esošajā infrastruktūrā. Piemēram, versiju kontrole nav nepieciešama, mums jau ir savs pirmkods. Mūsu parakstu mehānisms ir atšķirīgs: mēs izmantojam īpašu serveri. Repozitorijs arī nav vajadzīgs.
Turklāt atbalsts citiem izplatījumiem - piemēram, Red Hat - tiek īstenots diezgan vāji, kas ir saprotams.
Šāda pakalpojuma priekšrocība ir ātrs atbalsts nākamajai SUSE izplatīšanas versijai. Pirms oficiālā paziņojuma par izlaišanu komplektācijai nepieciešamās paketes tiek ievietotas publiskajā repozitorijā. OpenBuildService pieejamo izplatījumu sarakstā tiek parādīts jauns. Mēs atzīmējam izvēles rūtiņu, un tas tiek pievienots būvniecības plānam. Tādējādi jaunas izplatīšanas versijas pievienošana tiek veikta gandrīz ar vienu klikšķi.
Mūsu infrastruktūrā, izmantojot OpenBuildService, tiek apkopotas visas veeamsnap kodola moduļa KMP pakotnes SUSE izplatīšanai.
Tālāk es vēlētos pakavēties pie jautājumiem, kas raksturīgi kodola moduļiem.
kodols ABI
Kodola moduļi Linux Vēsturiski tie tika izplatīti pirmkoda veidā. Problēma ir tā, ka kodola veidotāji neuztraucas uzturēt stabilu API kodola moduļiem, vēl jo mazāk binārā līmenī (turpmāk tekstā kABI).
Lai izveidotu moduli vaniļas kodolam, jums noteikti ir nepieciešamas šī konkrētā kodola galvenes, un tas darbosies tikai šajā kodolā.
DKMS ļauj automatizēt moduļu veidošanu kodola atjaunināšanas laikā. Tā rezultātā repozitorija lietotāji Debian (un tā daudzie radinieki) izmanto kodola moduļus vai nu no izplatītāja repozitorija, vai arī kompilēti no avota, izmantojot DKMS.
Tomēr šī situācija nav īpaši piemērota uzņēmumu segmentam. Patentētu kodu izplatītāji vēlas izplatīt produktu kā apkopotus bināros failus.
Administratori drošības apsvērumu dēļ nevēlas glabāt izstrādes rīkus ražošanas serveros. Uzņēmumu izplatītāji Linux — piemēram, Red Hat un SUSE — nolēma, ka var atbalstīt stabilu kABI saviem lietotājiem. Tā rezultātā tika izveidotas KMOD pakotnes Red Hat un KMP pakotnes SUSE.
Šī risinājuma būtība ir pavisam vienkārša. Konkrētai izplatīšanas versijai kodola API ir iesaldēta. Izplatītājs norāda, ka izmanto kodolu, piemēram, 3.10, un veic tikai tādus labojumus un uzlabojumus, kas neietekmē kodola saskarnes, un pašam pirmajam kodolam savāktos moduļus var izmantot visiem nākamajiem bez pārkompilācijas.
Red Hat apgalvo, ka izplatīšanai ir saderīga kABI visā tā dzīves ciklā. Tas nozīmē, ka samontētajam rhel 6.0 modulim (izlaidums 2010. gada novembrī) ir jādarbojas arī versijā 6.10 (izlaidums 2018. gada jūnijā). Un tas ir gandrīz 8 gadi. Protams, šis uzdevums ir diezgan grūts.
Mēs esam reģistrējuši vairākus gadījumus, kad veeamsnap modulis pārstāja darboties kABI saderības problēmu dēļ.
Pēc tam, kad RHEL 7.0 kompilētais veeamsnap modulis izrādījās nesaderīgs ar RHEL 7.5 kodolu, taču tas tika ielādēts un tika garantēta servera avārija, mēs pilnībā atteicāmies no kABI saderības izmantošanas RHEL 7.
Pašlaik KMOD pakotnē RHEL 7 ir komplekts katrai laidiena versijai un skripts, kas ielādē moduli.
SUSE kABI saderības uzdevumam pievērsās rūpīgāk. Tie nodrošina kABI saderību tikai vienā servisa pakotnē.
Piemēram, SLES 12 izlaišana notika 2014. gada septembrī. Un SLES 12 SP1 jau bija 2015. gada decembrī, tas ir, ir pagājis nedaudz vairāk kā gads. Lai gan abos laidienos tiek izmantots 3.12 kodols, tie nav saderīgi ar kABI. Acīmredzot kABI saderības uzturēšana tikai gadu ir daudz vienkāršāka. Ikgadējais kodola moduļa atjaunināšanas cikls nedrīkst radīt problēmas moduļa veidotājiem.
Šīs SUSE politikas rezultātā mēs savā veeamsnap modulī neesam reģistrējuši nevienu kABI saderības problēmu. Tiesa, SUSE pakotņu skaits ir gandrīz par vienu pakāpi lielāks.
Patches un backports
Lai gan izplatītāji cenšas nodrošināt kABI saderību un kodola stabilitāti, viņi arī cenšas uzlabot šī stabilā kodola veiktspēju un novērst defektus.
Tajā pašā laikā uzņēmuma Linux kodola izstrādātāji papildus savam “darbam pie kļūdām” uzrauga izmaiņas vaniļas kodolā un pārsūta tās uz savu “stabilo”.
Dažreiz tas noved pie jauniem .
Red Hat 6 jaunākajā izlaidumā tika pieļauta kļūda vienā no nelielajiem atjauninājumiem. Tas noveda pie tā, ka tika garantēts, ka veeamsnap modulis sabruks sistēmā, kad momentuzņēmums tika atbrīvots. Salīdzinot kodola avotus pirms un pēc atjaunināšanas, mēs noskaidrojām, ka vainojams backport. Līdzīgs labojums tika veikts vaniļas kodola versijā 4.19. Vienkārši šis labojums vaniļas kodolā darbojās labi, taču, pārsūtot to uz “stabilo” 2.6.32, radās problēma ar spinlock.
Protams, visiem vienmēr ir kļūdas, bet vai bija vērts vilkt kodu no 4.19 uz 2.6.32, riskējot ar stabilitāti?.. Neesmu pārliecināts...
Sliktākais ir tad, kad mārketings iesaistās virves vilkšanā starp “stabilitāti” un “modernizāciju”. Mārketinga nodaļai ir nepieciešams, lai atjauninātā izplatīšanas kodols būtu stabils, no vienas puses, un tajā pašā laikā būtu labāks veiktspēja un jaunas funkcijas. Tas noved pie dīvainiem kompromisiem.
Kad es mēģināju izveidot moduli uz kodola 4.4 no SLES 12 SP3, es biju pārsteigts, atklājot tajā vanilla 4.8 funkcionalitāti. Manuprāt, 4.4 kodola bloka I/O ieviešana no SLES 12 SP3 ir vairāk līdzīga 4.8 kodolam nekā iepriekšējai stabilā 4.4 kodola versijai no SLES12 SP2. Es nevaru spriest, cik procentu koda tika pārsūtīts no kodola 4.8 uz SLES 4.4 SP3, bet es pat nevaru saukt kodolu par to pašu stabilo 4.4.
Pats nepatīkamākais ir tas, ka, rakstot moduli, kas vienlīdz labi darbotos dažādos kodolos, vairs nevar paļauties uz kodola versiju. Jāņem vērā arī sadalījums. Ir labi, ka dažreiz jūs varat iesaistīties definīcijā, kas parādās kopā ar jaunu funkcionalitāti, taču šī iespēja ne vienmēr parādās.
Rezultātā kods kļūst aizaugts ar dīvainām nosacījumu kompilācijas direktīvām.
Ir arī ielāpi, kas maina dokumentēto kodola API.
Saskāros ar izplatīšanu 5.16 un bija ļoti pārsteigts, redzot, ka lookup_bdev izsaukums šajā kodola versijā mainīja ievades parametru sarakstu.
Lai to apkopotu, man makefile bija jāpievieno skripts, kas pārbauda, vai funkcijai lookup_bdev ir maskas parametrs.
Kodola moduļu parakstīšana
Bet atgriezīsimies pie pakešu izplatīšanas jautājuma.
Viena no stabila kABI priekšrocībām ir tā, ka kodola moduļus var parakstīt kā bināru failu. Šajā gadījumā izstrādātājs var būt pārliecināts, ka modulis nav nejauši bojāts vai tīši pārveidots. To var pārbaudīt ar komandu modinfo.
Red Hat un SUSE izplatī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 publiskā atslēga, ar kuru modulis ir parakstīts. Mēs to izplatām kā atsevišķu iepakojumu.
Problēma šeit ir tāda, ka sertifikātus var iebūvēt kodolā (izplatītāji tos izmanto), vai arī tie jāieraksta EFI nemainīgajā atmiņā, izmantojot utilītu. mokutil. Lietderība mokutil Instalējot sertifikātu, jums ir jārestartē sistēma un pat pirms operētājsistēmas kodola ielādes administratoram tiek piedāvāts atļaut jauna sertifikāta ielādi.
Tādējādi, lai pievienotu sertifikātu, ir nepieciešama fiziska administratora piekļuve sistēmai. Ja iekārta atrodas kaut kur mākonī vai vienkārši attālā servera telpā un piekļuve notiek tikai caur tīklu (piemēram, caur 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ātesplates ražotāji, uzstādot sistēmu, administrators var nedomāt par EFI nepieciešamību, un tas var tikt atspējots.
Ne visi hipervizori atbalsta EFI. VMWare vSphere atbalsta EFI, sākot no 5. versijas.
Arī Microsoft Hyper-V saņēma EFI atbalstu, sākot ar Hyper-V priekš Windows Server 2012R2.
Tomēr noklusējuma konfigurācijā šī funkcionalitāte ir paredzēta Linux Ierīce ir izslēgta, kas nozīmē, ka sertifikātu nevar instalēt.
Programmā vSphere 6.5 iestatiet opciju Secure Boot iespējams tikai vecajā tīmekļa saskarnes versijā, kas darbojas, izmantojot Flash. Tīmekļa lietotāja interfeiss HTML-5 joprojām ir tālu atpalicis.
Eksperimentālie sadalījumi
Un visbeidzot, apskatīsim jautājumu par eksperimentālu izplatīšanu un izplatīšanu bez oficiāla atbalsta. No vienas puses, šādu izplatīšanu diez vai var atrast nopietnu organizāciju serveros. Šāda veida izplatīšanai nav oficiāla atbalsta. Tāpēc nodrošiniet tos. Produktu nevar atbalstīt šādā izplatīšanā.
Tomēr šādi izplatījumi kļūst par ērtu platformu jaunu eksperimentālu risinājumu izmēģināšanai. Piemēram, Fedora, OpenSUSE Tumbleweed vai Unstable versijas. DebianTie ir diezgan stabili. Tiem vienmēr ir jaunas programmatūras versijas un vienmēr jauns kodols. Gada laikā šī eksperimentālā funkcionalitāte varētu nonākt atjauninātā RHEL, SLES vai citā versijā. Ubuntu.
Tātad, ja eksperimentālā sadalījumā kaut kas nedarbojas, tas ir iemesls, lai noskaidrotu problēmu un to atrisinātu. Jums jābūt gatavam tam, ka šī funkcionalitāte drīzumā parādīsies lietotāju ražošanas serveros.
Varat izpētīt pašreizējo oficiāli atbalstīto izplatījumu sarakstu versijai 3.0 . Taču patiesais izplatījumu saraksts, kuros var darboties mūsu produkts, ir daudz plašāks.
Personīgi mani interesēja eksperiments ar Elbrus OS. Pēc veeam pakotnes pabeigšanas mūsu produkts tika uzstādīts un darbojās. Es rakstīju par šo eksperimentu par Habrē .
Nu, atbalsts jauniem izplatījumiem turpinās. Mēs gaidām versijas 4.0 izlaišanu. Drīzumā parādīsies beta versija, tāpēc sekojiet līdzi !
Avots: www.habr.com
