Varmuuskopiosovelluksen luominen, joka toimii missä tahansa jakelussa, ei ole helppo tehtävä. Varmistaaksesi, että Veeam Agent for Linux toimii jakeluissa Red Hat 6:sta ja Debian 6:sta OpenSUSE 15.1:een ja Ubuntu 19.04:ään, sinun on ratkaistava joukko ongelmia, etenkin kun otetaan huomioon, että ohjelmistotuote sisältää ydinmoduulin.
Artikkeli on luotu konferenssissa pidetyn puheen materiaalien pohjalta .
Linux ei ole vain yksi suosituimmista käyttöjärjestelmistä. Pohjimmiltaan tämä on alusta, jonka pohjalta voit tehdä jotain ainutlaatuista, jotain omaa. Tämän ansiosta Linuxilla on monia jakeluita, jotka eroavat ohjelmistokomponenteistaan. Ja tässä syntyy ongelma: jotta ohjelmistotuote toimisi missä tahansa jakelussa, sinun on otettava huomioon kunkin tuotteen ominaisuudet.
Pakettien ylläpitäjät. .deb vs .rpm
Aloitetaan ilmeisestä ongelmasta, joka liittyy tuotteen jakeluun eri jakeluissa.
Tyypillisin tapa jaella ohjelmistotuotteita on laittaa paketti arkistoon, jotta järjestelmään sisäänrakennettu paketinhallinta voi asentaa sen sieltä.
Meillä on kuitenkin kaksi suosittua pakettimuotoa: rpm и debytantti. Tämä tarkoittaa, että kaikkien on tuettava.
Deb-pakettien maailmassa yhteensopivuuden taso on hämmästyttävä. Sama paketti asentuu ja toimii yhtä hyvin sekä Debian 6:ssa että Ubuntu 19.04:ssä. Vanhoissa Debian-jakeluissa määritellyt pakettien rakennusprosessin ja niiden kanssa työskentelyn standardit ovat edelleen merkityksellisiä uudessa Linux Mintissä ja peruskäyttöjärjestelmässä. Siksi Veeam Agent for Linuxin tapauksessa yksi deb-paketti kutakin laitteistoalustaa kohti riittää.
Mutta rpm-pakettien maailmassa erot ovat suuria. Ensinnäkin, koska on olemassa kaksi täysin itsenäistä jakelijaa, Red Hat ja SUSE, joille yhteensopivuus on täysin tarpeetonta. Toiseksi näillä jakelijoilla on jakelusarjoja niistä. tukea ja kokeellista. Niiden välillä ei myöskään tarvita yhteensopivuutta. Kävi ilmi, että el6:lla, el7:llä ja el8:lla on omat paketit. Erillinen paketti Fedoralle. Paketit SLES11:lle ja 12:lle sekä erillinen openSUSE:lle. Suurin ongelma ovat riippuvuudet ja pakettien nimet.
Riippuvuus ongelma
Valitettavasti samat paketit päätyvät usein eri nimille eri jakeluissa. Alla on osittainen luettelo veeam-pakettien riippuvuuksista.
EL7:lle:
SLES 12:lle:
- libblkid
- libgcc
- libstdc++
- ncurses-libs
- sulake-libs
- file-libs
- veeamsnap=3.0.2.1185
- libblkid1
- libgcc_s1
- libstdc ++ 6
- libmagic1
- libfuse2
- veeamsnap-kmp = 3.0.2.1185
Tämän seurauksena riippuvuusluettelo on ainutlaatuinen jakelulle.
Pahempaa on, kun päivitetty versio alkaa piiloutua vanhan paketin nimen alle.
Esimerkiksi:
Paketti on päivitetty Fedora 24:ään nurssit versiosta 5 versioon 6. Tuotteemme on rakennettu version 5 kanssa yhteensopivuuden varmistamiseksi vanhempien jakelujen kanssa. Käyttääkseni kirjaston vanhaa 5. versiota Fedora 24:ssä minun oli käytettävä pakettia ncurses-compat-libs.
Tämän seurauksena Fedoralle on olemassa kaksi pakettia, joilla on erilaiset riippuvuudet.
Vielä mielenkiintoisempaa. Seuraavan jakelupäivityksen jälkeen paketti ncurses-compat-libs kirjaston versiolla 5 se ei ole käytettävissä. Jakelijalle on kallista vetää vanhoja kirjastoja jakelun uuteen versioon. Jonkin ajan kuluttua ongelma toistui SUSE-jakeluissa.
Tämän seurauksena jotkin jakelut joutuivat luopumaan selkeästä riippuvuudestaan ncurses-libs, ja korjaa tuote niin, että se toimii minkä tahansa kirjaston version kanssa.
Muuten, Red Hatin versiossa 8 ei ole enää metapakettia pytonkäärme, joka viittasi vanhaan hyvään python-2.7. On olemassa python2 и pytonkäärme3.
Vaihtoehto paketinhaltijoille
Riippuvuusongelma on vanha ja ollut ilmeinen jo pitkään. Muista vain riippuvuushelvetti.
Erilaisten kirjastojen ja sovellusten yhdistäminen niin, että ne kaikki toimivat vakaasti eivätkä ole ristiriidassa - itse asiassa tämä on tehtävä, jonka jokainen Linux-jakelija yrittää ratkaista.
Paketinhallinta yrittää ratkaista tämän ongelman täysin eri tavalla. Reipas Canonicalista. Pääidea: sovellus toimii hiekkalaatikossa, joka on eristetty ja suojattu pääjärjestelmästä. Jos sovellus vaatii kirjastoja, ne toimitetaan itse sovelluksen mukana.
Flatpak Voit myös ajaa sovelluksia hiekkalaatikossa Linux-säilöillä. Myös hiekkalaatikkoidea on käytössä AppImage.
Näiden ratkaisujen avulla voit luoda yhden paketin mille tahansa jakelulle. Siinä tapauksessa Flatpak sovelluksen asennus ja käynnistäminen on mahdollista myös ilman järjestelmänvalvojan tietämystä.
Suurin ongelma on, että kaikki sovellukset eivät voi toimia hiekkalaatikossa. Jotkut ihmiset tarvitsevat suoran pääsyn alustalle. En edes puhu ydinmoduuleista, jotka ovat tiukasti ytimestä riippuvaisia eivätkä sovi hiekkalaatikkokonseptiin.
Toinen ongelma on, että Red Hatin ja SUSE:n yritysympäristössä suositut jakelut eivät vielä sisällä tukea Snappylle ja Flatpakille.
Tältä osin Veeam Agent for Linux ei ole saatavilla Ei lainkaan .
Paketinhaltijoihin liittyvän kysymyksen päätteeksi haluaisin huomauttaa, että paketinhallinnat voidaan hylätä kokonaan yhdistämällä binaaritiedostot ja komentosarja niiden asentamiseksi yhdeksi paketiksi.
Tällaisen paketin avulla voit luoda yhden yhteisen paketin eri jakeluille ja alustoille, suorittaa interaktiivisen asennusprosessin ja suorittaa tarvittavat mukautukset. Olen törmännyt tällaisiin Linux-paketteihin vain VMwarelta.
Päivitys ongelma
Vaikka kaikki riippuvuusongelmat olisi ratkaistu, ohjelma voi toimia eri tavalla samassa jakelussa. Kyse on päivityksistä.
Päivitysstrategioita on kolme:
- Yksinkertaisin on olla päivittämättä koskaan. Asensin palvelimen ja unohdin sen. Miksi päivittää, jos kaikki toimii? Ongelmat alkavat, kun otat ensimmäisen kerran yhteyttä tukeen. Jakelun luoja tukee vain päivitettyä julkaisua.
- Voit luottaa jakelijaan ja määrittää automaattiset päivitykset. Tässä tapauksessa puhelintukeen soitetaan todennäköisesti välittömästi epäonnistuneen päivityksen jälkeen.
- Mahdollisuus päivittää manuaalisesti vasta sen jälkeen, kun se on suoritettu testiinfrastruktuurissa, on luotettavin, mutta kallein ja aikaa vievä. Kaikilla ei ole siihen varaa.
Koska eri käyttäjät käyttävät erilaisia päivitysstrategioita, on välttämätöntä tukea sekä uusinta julkaisua että kaikkia aiemmin julkaistuja. Tämä vaikeuttaa sekä kehitys- että testausprosessia ja lisää päänsärkyä tukitiimille.
Erilaisia laitteistoalustoja
Erilaiset laitteistoympäristöt ovat ongelma, joka liittyy suurelta osin alkuperäiseen koodiin. Sinun on kerättävä vähintään binaarit jokaiselle tuetulle alustalle.
Veeam Agent for Linux -projektissa emme edelleenkään voi tukea mitään tämän kaltaista RISC:tä.
En käsittele tätä asiaa yksityiskohtaisesti. Kerron vain pääongelmat: alustasta riippuvaiset tyypit, kuten size_t, rakenteen tasaus ja tavujärjestys.
Staattinen ja/tai dynaaminen linkitys
Mutta kysymys kuuluu "Kuinka yhdistää kirjastoihin - dynaamisesti tai staattisesti?" keskustelun arvoinen.
Pääsääntöisesti Linuxin C/C++-sovellukset käyttävät dynaamista linkitystä. Tämä toimii hyvin, jos sovellus on rakennettu erityisesti tiettyä jakelua varten.
Jos tehtävänä on kattaa eri jakelut yhdellä binääritiedostolla, sinun on keskityttävä vanhimpaan tuettuun jakeluun. Meille tämä on Red Hat 6. Se sisältää gcc 4.4:n, jota edes C++11-standardi ei tue .
Rakennamme projektimme gcc 6.3:lla, joka tukee täysin C++14:ää. Luonnollisesti tässä tapauksessa Red Hat 6:ssa sinun on kannettava libstdc++ ja tehostuskirjastot mukanasi. Helpoin tapa on linkittää niihin staattisesti.
Mutta valitettavasti kaikkia kirjastoja ei voida linkittää staattisesti.
Ensinnäkin järjestelmäkirjastot, kuten libfuse, libblkid on tarpeen linkittää dynaamisesti varmistaakseen niiden yhteensopivuuden ytimen ja sen moduulien kanssa.
Toiseksi, lisensseihin liittyy hienovaraisuutta.
GPL-lisenssi sallii periaatteessa linkittää kirjastoja vain avoimen lähdekoodin avulla. MIT ja BSD mahdollistavat staattisen linkityksen ja mahdollistavat kirjastojen sisällyttämisen projektiin. Mutta LGPL ei näytä olevan ristiriidassa staattisen linkityksen kanssa, vaan edellyttää linkittämistä varten tarvittavien tiedostojen jakamista.
Yleensä dynaamisen linkityksen käyttäminen estää sinua antamasta mitään.
C/C++ sovellusten rakentaminen
C/C++-sovellusten rakentamiseen eri alustoille ja jakeluille riittää, että valitset tai rakennat sopivan gcc-version ja käytät ristiinkääntäjiä tietyille arkkitehtuureille ja koomme koko kirjastosarjan. Tämä työ on melko mahdollista, mutta melko hankalaa. Eikä ole mitään takeita siitä, että valittu kääntäjä ja kirjastot tarjoavat toimivan version.
Ilmeinen etu: infrastruktuuri yksinkertaistuu huomattavasti, koska koko rakennusprosessi voidaan suorittaa yhdellä koneella. Lisäksi riittää kerätä yksi sarja binääriä yhdelle arkkitehtuurille ja voit pakata ne paketeiksi eri jakeluille. Näin veeam-paketit rakennetaan Veeam Agent for Linuxille.
Toisin kuin tämä vaihtoehto, voit yksinkertaisesti valmistella rakennustilan, toisin sanoen useita koneita kokoonpanoa varten. Jokainen tällainen kone tarjoaa sovellusten kokoamisen ja pakettien kokoonpanon tietylle jakelulle ja tietylle arkkitehtuurille. Tässä tapauksessa kokoaminen suoritetaan jakelijan valmistamilla keinoilla. Eli kääntäjän valmisteluvaihe ja kirjastojen valinta jää pois. Lisäksi rakennusprosessi voidaan helposti rinnastaa.
Tällä lähestymistavalla on kuitenkin haittapuoli: jokaista jakelua varten saman arkkitehtuurin sisällä sinun on kerättävä oma joukko binaaritiedostoja. Toinen haittapuoli on, että niin suurta määrää koneita on ylläpidettävä ja paljon levytilaa ja RAM-muistia on varattava.
Näin veeamsnap-ydinmoduulin KMOD-paketit käännetään Red Hat -jakeluille.
Avaa Build Service
SUSE-kollegat yrittivät toteuttaa jonkinlaisen keskitien erityispalvelun muodossa sovellusten kokoamiseen ja pakettien kokoamiseen - .
Pohjimmiltaan se on hypervisor, joka luo virtuaalikoneen, asentaa siihen kaikki tarvittavat paketit, kokoaa sovelluksen ja rakentaa paketin tähän eristettyyn ympäristöön, minkä jälkeen virtuaalikone vapautetaan.
OpenBuildServicessä toteutettu aikataulutin määrittää, kuinka monta virtuaalikonetta se voi käynnistää optimaalisen paketinrakennusnopeuden saavuttamiseksi. Sisäänrakennettu allekirjoitusmekanismi allekirjoittaa paketit ja lataa ne sisäänrakennettuun arkistoon. Sisäänrakennettu versionhallintajärjestelmä tallentaa muutos- ja versiohistorian. Jäljelle jää vain lisäämällä lähteesi tähän järjestelmään. Sinun ei tarvitse edes määrittää palvelinta itse, voit käyttää avointa palvelinta.
On kuitenkin olemassa ongelma: tällaista harvesteria on vaikea sovittaa olemassa olevaan infrastruktuuriin. Esimerkiksi versionhallintaa ei tarvita, meillä on jo oma lähdekoodimme. Allekirjoitusmekanismimme on erilainen: käytämme erityistä palvelinta. Arkistoa ei myöskään tarvita.
Lisäksi tuki muille jakeluille - esimerkiksi Red Hat - on toteutettu melko huonosti, mikä on ymmärrettävää.
Tällaisen palvelun etuna on nopea tuki SUSE-jakelun seuraavalle versiolle. Ennen julkaisun virallista ilmoitusta kokoonpanoon tarvittavat paketit asetetaan julkiseen arkistoon. Uusi ilmestyy OpenBuildServicen saatavilla olevien jakelujen luetteloon. Valitsemme valintaruudun ja se lisätään rakennussuunnitelmaan. Näin ollen jakelun uuden version lisääminen tapahtuu melkein yhdellä napsautuksella.
Infrastruktuurissamme on koottu OpenBuildServicen avulla kaikki veeamsnap-ydinmoduulin KMP-paketit SUSE-jakeluille.
Seuraavaksi haluaisin keskittyä ytimen moduuleisiin liittyviin ongelmiin.
ydin ABI
Linux-ytimen moduuleja on historiallisesti jaettu lähdemuodossa. Tosiasia on, että ytimen luojat eivät kuormita itseään huolehtimalla vakaan API:n tukemisesta ydinmoduuleille ja erityisesti binääritasolla, jota kutsutaan edelleen kABI:ksi.
Jotta voit rakentaa moduulin vaniljaytimelle, tarvitset ehdottomasti tämän ytimen otsikot, ja se toimii vain tässä ytimessä.
DKMS:n avulla voit automatisoida moduulien rakennusprosessin, kun päivität ydintä. Tämän seurauksena Debian-varaston käyttäjät (ja sen monet sukulaiset) käyttävät ydinmoduuleja joko jakelijan arkistosta tai DKMS:n avulla käännettynä lähteestä.
Tämä tilanne ei kuitenkaan sovi erityisesti Enterprise-segmentille. Omistuskoodin jakelijat haluavat jaella tuotetta käännettyinä binäärinä.
Järjestelmänvalvojat eivät halua pitää kehitystyökaluja tuotantopalvelimilla turvallisuussyistä. Enterprise Linux -jakelijat, kuten Red Hat ja SUSE, päättivät tukea käyttäjilleen vakaata kABI:ta. Tuloksena oli KMOD-paketit Red Hatille ja KMP-paketit SUSElle.
Tämän ratkaisun ydin on melko yksinkertainen. Tietyssä jakeluversiossa ytimen API on jäädytetty. Jakelija ilmoittaa käyttävänsä ydintä, esimerkiksi 3.10:tä, ja tekee vain korjauksia ja parannuksia, jotka eivät vaikuta ytimen rajapintoihin, ja aivan ensimmäiseen ytimeen kerättyjä moduuleja voidaan käyttää kaikissa myöhemmissä ilman uudelleenkääntämistä.
Red Hat väittää kABI-yhteensopivuuden jakelulle koko sen elinkaaren ajan. Toisin sanoen rhel 6.0:n (julkaisu marraskuussa 2010) kootun moduulin pitäisi toimia myös versiossa 6.10 (julkaisu kesäkuussa 2018). Ja tästä on kohta 8 vuotta. Luonnollisesti tämä tehtävä on melko vaikea.
Olemme tallentaneet useita tapauksia, joissa veeamsnap-moduuli lakkasi toimimasta kABI-yhteensopivuusongelmien vuoksi.
Kun RHEL 7.0:lle käännetty veeamsnap-moduuli osoittautui yhteensopimattomaksi RHEL 7.5:n ytimen kanssa, mutta se latautui ja taatusti kaatui palvelimen, hylkäsimme kABI-yhteensopivuuden käytön RHEL 7:lle kokonaan.
Tällä hetkellä RHEL 7:n KMOD-paketti sisältää kokoonpanon jokaiselle julkaisuversiolle ja komentosarjan, joka lataa moduulin.
SUSE lähestyi kABI-yhteensopivuuden tehtävää huolellisemmin. Ne tarjoavat kABI-yhteensopivuuden vain yhdessä Service Pack -paketissa.
Esimerkiksi SLES 12:n julkaisu tapahtui syyskuussa 2014. Ja SLES 12 SP1 oli jo joulukuussa 2015, eli hieman yli vuosi on kulunut. Vaikka molemmat julkaisut käyttävät 3.12-ydintä, ne eivät ole kABI-yhteensopivia. On selvää, että kABI-yhteensopivuuden ylläpitäminen vain vuoden ajan on paljon helpompaa. Vuosittaisen ytimen moduulin päivitysjakson ei pitäisi aiheuttaa ongelmia moduulien luojille.
Tämän SUSE-käytännön seurauksena emme ole tallentaneet yhtäkään kABI-yhteensopivuuden ongelmaa veeamsnap-moduulissamme. Totta, SUSE-pakettien määrä on melkein suuruusluokkaa suurempi.
Patch ja backports
Vaikka jakelijat yrittävät varmistaa kABI-yhteensopivuuden ja ytimen vakauden, he yrittävät myös parantaa suorituskykyä ja eliminoida tämän vakaan ytimen viat.
Samaan aikaan oman "virhetyönsä" lisäksi yritys-Linux-ytimen kehittäjät seuraavat vaniljaytimen muutoksia ja siirtävät ne "vakaaseen" ytimeensä.
Joskus tämä johtaa uusiin .
Red Hat 6:n uusimmassa julkaisussa yhdessä pienessä päivityksessä tehtiin virhe. Se johti siihen, että veeamsnap-moduuli kaatui järjestelmän, kun tilannekuva julkaistiin. Verrattuamme ytimen lähteitä ennen päivitystä ja sen jälkeen huomasimme, että taustaportti oli syyllinen. Samanlainen korjaus tehtiin vanilla-ytimen versiossa 4.19. Tämä korjaus toimi vain hyvin vaniljaytimessä, mutta siirrettäessä sitä "vakaalle" 2.6.32:lle, ilmaantui ongelma spinlockin kanssa.
Tietysti jokaisella on aina virheitä, mutta kannattiko vetää koodia 4.19:stä 2.6.32:een vakautta vaarantaen?... En ole varma...
Pahinta on, kun markkinointi osallistuu "vakauden" ja "modernisoinnin" väliseen köydenvetoon. Markkinointiosasto tarvitsee päivitetyn jakelun ytimen olevan toisaalta vakaa ja samalla suorituskyvyltään parempi ja uusia ominaisuuksia. Tämä johtaa kummallisiin kompromisseihin.
Kun yritin rakentaa moduulia ytimeen 4.4 SLES 12 SP3:sta, yllätyin siitä, että löysin siinä toimintoja vanilla 4.8:sta. Mielestäni SLES 4.4 SP12:n 3-ytimen lohko-I/O-toteutus on enemmän samankaltainen kuin 4.8-ytimen kuin SLES4.4 SP12:n vakaan 2-ytimen edellinen julkaisu. En voi arvioida, kuinka monta prosenttia koodista siirrettiin ytimestä 4.8 SLES 4.4:ään SP3:lle, mutta en voi edes kutsua ydintä samaksi vakaaksi 4.4:ksi.
Epämiellyttävintä tässä on se, että kirjoitettaessa moduulia, joka toimisi yhtä hyvin eri ytimillä, et voi enää luottaa ytimen versioon. Sinun on myös otettava huomioon jakelu. On hyvä, että joskus voit osallistua määritelmään, joka ilmestyy uusien toimintojen mukana, mutta tämä mahdollisuus ei aina tule näkyviin.
Seurauksena koodista tulee outoja ehdollisia käännösdirektiivejä.
On myös korjaustiedostoja, jotka muuttavat dokumentoitua ytimen API:ta.
Törmäsin jakeluun 5.16 ja olin hyvin yllättynyt nähdessäni, että lookup_bdev-kutsu tässä ydinversiossa muutti syöttöparametrien luetteloa.
Saadakseni sen yhteen, minun piti lisätä skripti make-tiedostoon, joka tarkistaa, onko lookup_bdev-funktiolla maskiparametri.
Ytimen moduulien allekirjoittaminen
Mutta palataanpa pakettien jakeluun.
Yksi vakaan kABI:n eduista on, että ydinmoduulit voidaan allekirjoittaa binääritiedostoina. Tässä tapauksessa kehittäjä voi olla varma, ettei moduulia ole vahingossa vaurioitunut tai muutettu tarkoituksella. Voit tarkistaa tämän modinfo-komennolla.
Red Hat- ja SUSE-jakeluissa voit tarkistaa moduulin allekirjoituksen ja ladata sen vain, jos vastaava varmenne on rekisteröity järjestelmään. Varmenne on julkinen avain, jolla moduuli on allekirjoitettu. Jaamme sen erillisenä pakettina.
Ongelmana tässä on se, että varmenteet voidaan joko rakentaa ytimeen (jakelijat käyttävät niitä) tai ne täytyy kirjoittaa EFI:n haihtumattomaan muistiin apuohjelman avulla. mokutil. Apuohjelma mokutil Kun asennat varmenteen, se vaatii järjestelmän uudelleenkäynnistyksen ja jopa ennen käyttöjärjestelmän ytimen lataamista kehottaa järjestelmänvalvojaa sallimaan uuden varmenteen lataamisen.
Näin ollen varmenteen lisääminen vaatii fyysisen järjestelmänvalvojan pääsyn järjestelmään. Jos kone sijaitsee jossain pilvessä tai yksinkertaisesti etäpalvelinhuoneessa ja pääsy tapahtuu vain verkon kautta (esimerkiksi ssh:n kautta), varmenteen lisääminen on mahdotonta.
EFI virtuaalikoneissa
Huolimatta siitä, että lähes kaikki emolevyvalmistajat ovat pitkään tukeneet EFI:tä, järjestelmän asennuksen yhteydessä järjestelmänvalvoja ei välttämättä ajattele EFI:n tarvetta ja se voidaan poistaa käytöstä.
Kaikki hypervisorit eivät tue EFI:tä. VMWare vSphere tukee EFI:tä versiosta 5 alkaen.
Microsoft Hyper-V sai myös EFI-tuen alkaen Hyper-V:stä Windows Server 2012R2:lle.
Oletuskokoonpanossa tämä toiminto on kuitenkin poistettu käytöstä Linux-koneissa, mikä tarkoittaa, että varmennetta ei voi asentaa.
Aseta vaihtoehto vSphere 6.5:ssä Secure Boot mahdollista vain web-käyttöliittymän vanhassa versiossa, joka toimii Flashin kautta. HTML-5:n verkkokäyttöliittymä on vielä kaukana.
Kokeelliset jakaumat
Ja lopuksi, tarkastellaan kysymystä kokeellisista jakeluista ja jakeluista ilman virallista tukea. Toisaalta tällaisia jakeluja ei todennäköisesti löydy vakavien organisaatioiden palvelimilta. Tällaisille jakeluille ei ole virallista tukea. Siksi tarjoa ne. Tuotetta ei voi tukea tällaisessa jakelussa.
Tällaisista jakeluista tulee kuitenkin kätevä alusta kokeilla uusia kokeellisia ratkaisuja. Esimerkiksi Fedora, OpenSUSE Tumbleweed tai Debianin epävakaat versiot. Ne ovat melko vakaita. Heillä on aina uudet versiot ohjelmista ja aina uusi ydin. Vuoden kuluttua tämä kokeellinen toiminnallisuus saattaa päätyä päivitettyyn RHEL-, SLES- tai Ubuntuun.
Joten jos jokin ei toimi kokeellisessa jakelussa, tämä on syy selvittää ongelma ja ratkaista se. Sinun on varauduttava siihen, että tämä toiminto ilmestyy pian käyttäjien tuotantopalvelimille.
Voit tarkastella nykyistä luetteloa virallisesti tuetuista jakeluista versiolle 3.0 . Mutta todellinen luettelo jakeluista, joissa tuotteemme voi toimia, on paljon laajempi.
Itse olin kiinnostunut kokeilusta Elbrus-käyttöjärjestelmällä. Veam-paketin viimeistelyn jälkeen tuotteemme oli asennettu ja toimi. Kirjoitin tästä kokeesta Habreen vuonna .
No, tuki uusille jakeluille jatkuu. Odotamme version 4.0 julkaisua. Beta on ilmestymässä, joten pidä silmällä !
Lähde: will.com