ProHoster > Blogs > Administrācija > Linux ir daudz seju: kā strādāt pie jebkura izplatīŔanas

Linux ir daudz seju: kā strādāt pie jebkura izplatīŔanas

Linux ir daudz seju: kā strādāt pie jebkura izplatīŔanas

Dublējuma lietojumprogrammas izveide, kas darbojas jebkurā izplatÄ«Å”anā, nav viegls uzdevums. Lai nodroÅ”inātu, ka Veeam Agent for Linux darbojas izplatÄ«jumos no Red Hat 6 un Debian 6 lÄ«dz OpenSUSE 15.1 un Ubuntu 19.04, jums ir jāatrisina virkne problēmu, jo Ä«paÅ”i ņemot vērā to, ka programmatÅ«ras produktā ir iekļauts kodola modulis.

Raksts tapis, balstoties uz konferencē uzstāŔanās materiāliem Linux Peter 2019.

Linux ir ne tikai viena no populārākajām operētājsistēmām. BÅ«tÄ«bā Ŕī ir platforma, uz kuras pamata jÅ«s varat izveidot kaut ko unikālu, kaut ko savu. Pateicoties tam, Linux ir daudz distribÅ«ciju, kas atŔķiras pēc programmatÅ«ras komponentu komplekta. Un Å”eit rodas problēma: lai programmatÅ«ras produkts darbotos jebkurā izplatÄ«Å”anā, jums ir jāņem vērā katras funkcijas.

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 tiek instalēta un darbojas vienlÄ«dz labi gan Debian 6, gan Ubuntu 19.04. Standarti pakotņu veidoÅ”anas procesam un darbam ar tām, kas noteikti vecajos Debian izplatÄ«jumos, joprojām ir aktuāli jaunizveidotajā Linux Mint un elementārajā OS. Tāpēc Veeam Agent for Linux gadÄ«jumā pietiek ar vienu deb pakotni katrai aparatÅ«ras platformai.

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.
Apvienot dažādas bibliotēkas un lietojumprogrammas, lai tās visas darbotos stabili un nekonfliktētu ā€“ patiesÄ«bā tas ir uzdevums, ko mēģina atrisināt jebkurÅ” Linux izplatÄ«tājs.

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 ļauj arÄ« palaist lietojumprogrammas smilÅ”kastē, izmantojot Linux konteinerus. Tiek izmantota arÄ« smilÅ”u kastes ideja 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 Agent for Linux nav pieejams snapcraft.io nav ieslēgts flathub.org.

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ē.

Šāds komplekts ļauj izveidot vienu kopÄ«gu paketi dažādiem izplatÄ«jumiem un platformām, veikt interaktÄ«vu instalÄ“Å”anas procesu, veicot nepiecieÅ”amo pielāgoÅ”anu. Ar Ŕādām Linux pakotnēm esmu sastapies tikai no VMware.

AtjaunināŔanas problēma

Linux ir daudz seju: kā strādāt pie jebkura izplatīŔanas
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.

Projektā Veeam Agent for Linux mēs joprojām nevaram atbalstÄ«t neko lÄ«dzÄ«gu Å”im RISC.

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

Linux ir daudz seju: kā strādāt pie jebkura izplatīŔanas
Bet jautājums ir "Kā izveidot saiti ar bibliotēkām - dinamiski vai statiski?" diskusiju vērts.

Parasti C/C++ lietojumprogrammas operētājsistēmā Linux izmanto dinamisko saistÄ«Å”anu. Tas darbojas lieliski, ja lietojumprogramma ir Ä«paÅ”i izstrādāta konkrētam izplatÄ«Å”anai.

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. pilnÄ«gi.

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 veidoÅ”anas procesu var pabeigt vienā maŔīnā. Turklāt vienai arhitektÅ«rai pietiek savākt vienu bināro failu kopu, un jÅ«s varat tos iepakot pakotnēs dažādiem izplatÄ«jumiem. Šādi tiek veidotas veeam pakotnes Veeam Agent for 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 - openbuildservice.

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.

Linux ir daudz seju: kā strādāt pie jebkura izplatīŔanas

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

Linux kodola moduļi vēsturiski ir izplatÄ«ti avota formā. Fakts ir tāds, ka kodola veidotāji neapgrÅ«tina sevi ar rÅ«pēm par stabilas API atbalstÄ«Å”anu kodola moduļiem, un jo Ä«paÅ”i binārajā lÄ«menÄ«, ko turpmāk dēvē par 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Å”anas procesu kodola atjaunināŔanas laikā. Rezultātā Debian repozitorija lietotāji (un daudzi tā radinieki) izmanto kodola moduļus vai nu no izplatÄ«tāja repozitorija, vai 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. Enterprise Linux izplatÄ«tāji, piemēram, Red Hat un SUSE, nolēma, ka viņi varētu atbalstÄ«t stabilu kABI saviem lietotājiem. Rezultāts bija 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 kļūdas.

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 KDE neons 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.
Microsoft Hyper-V arī ieguva EFI atbalstu, sākot ar Hyper-V operētājsistēmai Windows Server 2012R2.

Tomēr noklusējuma konfigurācijā Ŕī funkcionalitāte ir atspējota Linux iekārtām, 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 Ŕādas izplatÄ«Å”anas kļūst par ērtu platformu jaunu eksperimentālu risinājumu izmēģināŔanai. Piemēram, Fedora, OpenSUSE Tumbleweed vai Debian nestabilās versijas. Tie ir diezgan stabili. Viņiem vienmēr ir jaunas programmu versijas un vienmēr jauns kodols. Gada laikā Ŕī eksperimentālā funkcionalitāte var nonākt atjauninātā RHEL, SLES vai 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 Å”eit. 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ē raksts.

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 kas jauns!

Avots: www.habr.com

Pievieno komentāru