It meitsjen fan in reservekopy-applikaasje dy't wurket op elke distribúsje is gjin maklike taak. Om te garandearjen dat Veeam Agent foar Linux wurket op distribúsjes fan Red Hat 6 en Debian 6, nei OpenSUSE 15.1 en Ubuntu 19.04, moatte jo in ferskaat oan problemen oplosse, benammen yn betinken dat it softwareprodukt in kernelmodule omfettet.
It artikel is makke op basis fan materialen fan in taspraak op 'e konferinsje .
Linux is net allinich ien fan 'e populêrste bestjoeringssystemen. Yn essinsje is dit in platfoarm op basis wêrfan jo wat unyk kinne meitsje, wat fan jo eigen. Hjirmei hat Linux in protte distribúsjes dy't ferskille yn har set fan softwarekomponinten. En hjir ûntstiet in probleem: om in softwareprodukt te funksjonearjen op elke distribúsje, moatte jo rekken hâlde mei de funksjes fan elk.
Pakketbehearders. .deb tsjin .rpm
Litte wy begjinne mei it foar de hân lizzende probleem fan it fersprieden fan it produkt oer ferskate distribúsjes.
De meast typyske manier om softwareprodukten te fersprieden is it pakket op in repository te pleatsen sadat de yn it systeem ynboude pakketbehearder it dêrwei kin ynstallearje.
Wy hawwe lykwols twa populêre pakketformaten: rpm и deb. Dit betsjut dat elkenien sil stypje moatte.
Yn 'e wrâld fan deb-pakketten is it nivo fan kompatibiliteit geweldig. Itselde pakket ynstallearret en wurket like goed op sawol Debian 6 as Ubuntu 19.04. De noarmen foar it proses fan it bouwen fan pakketten en wurkje mei har, fêstlein yn âlde Debian-distribúsjes, bliuwe relevant yn 'e nijmoadrige Linux Mint en elemintêre OS. Dêrom, yn it gefal fan Veeam Agent foar Linux, is ien deb-pakket foar elk hardwareplatfoarm genôch.
Mar yn 'e wrâld fan rpm-pakketten binne de ferskillen grut. As earste, troch it feit dat d'r twa folslein ûnôfhinklike distributeurs binne, Red Hat en SUSE, wêrfoar kompatibiliteit folslein net nedich is. Twad, dizze distributeurs hawwe distribúsjekits fan dy. stipe en eksperiminteel. D'r is ek gjin ferlet fan kompatibiliteit tusken har. It die bliken dat el6, el7 en el8 har eigen pakketten hawwe. Apart pakket foar Fedora. Pakketten foar SLES11 en 12 en in aparte foar openSUSE. It wichtichste probleem is ôfhinklikens en pakketnammen.
Ofhinklikens probleem
Spitigernôch einigje deselde pakketten faak ûnder ferskillende nammen yn ferskate distribúsjes. Hjirûnder is in diellist fan veeam-pakketôfhinklikens.
Foar EL7:
Foar SLES 12:
- libbe
- libgcc
- libstdc++
- ncurses-libs
- fuse-libs
- triem-libs
- veeamsnap=3.0.2.1185
- libbe1
- libgcc_s1
- libstdc++6
- libmagic1
- libfy 2
- veeamsnap-kmp=3.0.2.1185
As resultaat is de list mei ôfhinklikens unyk foar de distribúsje.
Wat slimmer wurdt is as in bywurke ferzje begjint te ferbergjen ûnder de âlde pakketnamme.
Foarbyld:
It pakket is bywurke yn Fedora 24 ncurses fan ferzje 5 oant ferzje 6. Us produkt is boud mei ferzje 5 om te soargjen foar komptabiliteit mei âldere distribúsjes. Om de âlde 5e ferzje fan 'e bibleteek op Fedora 24 te brûken, moast ik it pakket brûke ncurses-compat-libs.
As gefolch binne d'r twa pakketten foar Fedora, mei ferskate ôfhinklikens.
Fierder mear nijsgjirrich. Nei de folgjende ferdieling update, it pakket ncurses-compat-libs mei ferzje 5 fan de bibleteek docht bliken dat it net beskikber is. It is djoer foar in distributeur in slepe âlde biblioteken yn in nije ferzje fan de distribúsje. Nei in skoftke werhelle it probleem himsels yn SUSE-distribúsjes.
As resultaat moasten guon distribúsjes har eksplisite ôfhinklikens opjaan ncurses-libs, en reparearje it produkt sadat it kin wurkje mei elke ferzje fan 'e bibleteek.
Trouwens, yn ferzje 8 fan Red Hat is d'r gjin metapakket mear python, dy't ferwiisde nei it goede âlde python 2.7... dêr is python2 и python3.
Alternatyf foar pakketbehearders
It probleem mei ôfhinklikens is âld en hat al lang dúdlik west. Unthâld gewoan Dependency hel.
Om ferskate bibleteken en applikaasjes te kombinearjen sadat se allegear stabyl wurkje en net konflikt - yn feite is dit de taak dy't elke Linux-distributeur besiket op te lossen.
De pakketbehearder besiket dit probleem op in folslein oare manier op te lossen. Snappy út Canonical. It haadidee: de applikaasje rint yn in sânbak isolearre en beskerme fan it haadsysteem. As in applikaasje biblioteken fereasket, wurde se levere mei de applikaasje sels.
Flatpak lit jo ek applikaasjes útfiere yn in sânbak mei Linux Containers. It idee fan sânbak wurdt ek brûkt AppImage.
Dizze oplossingen kinne jo ien pakket meitsje foar elke distribúsje. Yn it gefal dat Flatpak ynstallaasje en lansearring fan 'e applikaasje is mooglik sels sûnder de kennis fan de behearder.
It wichtichste probleem is dat net alle applikaasjes kinne rinne yn in sânbak. Guon minsken hawwe direkte tagong ta it platfoarm nedich. Ik ha it net iens oer kernelmodules, dy't strikt ôfhinklik binne fan 'e kernel en net passe yn it sânbakkonsept.
It twadde probleem is dat distribúsjes populêr yn 'e ûndernimmingsomjouwing fan Red Hat en SUSE noch gjin stipe foar Snappy en Flatpak befetsje.
Yn dit ferbân is Veeam Agent foar Linux net beskikber net oan .
Om de fraach oer pakketbehearders ôf te sluten, wol ik opmerke dat d'r in opsje is om pakketbehearders hielendal te ferlitten troch binêre bestannen en in skript te kombinearjen om se yn ien pakket te ynstallearjen.
Sa'n bondel lit jo ien mienskiplik pakket meitsje foar ferskate distribúsjes en platfoarms, in ynteraktyf ynstallaasjeproses útfiere, de nedige oanpassing útfiere. Ik haw allinich sokke pakketten foar Linux fan VMware tsjinkaam.
Update probleem
Sels as alle ôfhinklikensproblemen binne oplost, kin it programma oars op deselde distribúsje rinne. It is in kwestje fan updates.
D'r binne 3 updatestrategyen:
- De ienfâldichste is om nea bywurkje. Ik sette de tsjinner op en fergeat it. Wêrom bywurkje as alles wurket? Problemen begjinne de earste kear dat jo kontakt opnimme mei stipe. De makker fan 'e distribúsje stipet allinich de bywurke release.
- Jo kinne de distributeur fertrouwe en automatyske updates ynstelle. Yn dit gefal is in oprop om stipe wierskynlik direkt nei in mislearre update.
- De opsje fan hânmjittich bywurkjen pas nei it útfieren fan it op in testynfrastruktuer is de meast betroubere, mar djoer en tiidslinend. Net elkenien kin it betelje.
Om't ferskate brûkers ferskate updatestrategyen brûke, is it needsaaklik om sawol de lêste release as alle earder útbrochte te stypjen. Dit komplisearret sawol de ûntwikkeling as it testproses en foeget hoofdpijn ta oan it stipeteam.
Ferskaat oan hardware platfoarms
Ferskillende hardwareplatfoarms binne in probleem dat foar in grut part spesifyk is foar native koade. Op syn minst moatte jo binaries sammelje foar elk stipe platfoarm.
Yn it Veeam Agent foar Linux-projekt kinne wy noch neat as dizze RISC stypje.
Ik sil net yn detail oer dizze kwestje stean. Ik sil allinne sketse de wichtichste problemen: platfoarm-ôfhinklike typen, lykas size_t, struktuer ôfstimming en byte folchoarder.
Statyske en/of dynamyske keppeling
Mar de fraach is "Hoe kinne jo ferbine mei biblioteken - dynamysk as statysk?" wurdich te besprekken.
As regel brûke C / C ++ applikaasjes ûnder Linux dynamyske keppeling. Dit wurket geweldich as de applikaasje spesifyk boud is foar in spesifike distribúsje.
As de taak is om ferskate distribúsjes te dekken mei ien binêre triem, dan moatte jo rjochtsje op 'e âldste stipe distribúsje. Foar ús is dit Red Hat 6. It befettet gcc 4.4, dy't sels de C++11-standert net stipet .
Wy bouwe ús projekt mei gcc 6.3, dy't C++14 folslein stipet. Natuerlik moatte jo yn dit gefal op Red Hat 6 de libstdc ++ drage en bibleteken mei jo stimulearje. De maklikste manier is om har statysk te keppeljen.
Mar helaas, net alle bibleteken kinne statysk keppele wurde.
As earste, systeembiblioteken lykas libfuse, libbe it is nedich om dynamysk te keppeljen om har kompatibiliteit te garandearjen mei de kernel en har modules.
Twadder is der in subtiliteit mei lisinsjes.
De GPL-lisinsje lit jo yn prinsipe allinich biblioteken keppelje mei opensource-koade. MIT en BSD tastean statyske keppeling en tastean biblioteken wurde opnommen yn in projekt. Mar de LGPL liket statyske keppeling net yn tsjinspraak, mar fereasket dat de bestannen dy't nedich binne foar keppeljen wurde dield.
Yn 't algemien sil it brûken fan dynamyske keppeling foarkomme dat jo neat moatte leverje.
Bouwe C / C ++ applikaasjes
Om C/C++-applikaasjes foar ferskate platfoarms en distribúsjes te bouwen, is it genôch om in gaadlike ferzje fan gcc te selektearjen of te bouwen en cross-compilers te brûken foar spesifike arsjitektuer en de hiele set fan bibleteken te sammeljen. Dit wurk is frij mooglik, mar frij lestich. En d'r is gjin garânsje dat de selektearre gearstaller en bibleteken in wurkbere ferzje leverje.
In fanselssprekkend foardiel: de ynfrastruktuer is sterk ferienfâldige, om't it heule bouproses op ien masine kin wurde foltôge. Derneist is it genôch om ien set binaries te sammeljen foar ien arsjitektuer en jo kinne se yn pakketten ferpakke foar ferskate distribúsjes. Dit is hoe't veeam-pakketten binne boud foar Veeam Agent foar Linux.
Yn tsjinstelling ta dizze opsje, kinne jo gewoan tariede in build pleats, dat is, ferskate masines foar gearkomste. Elts sa'n masine sil foarsjen applikaasje kompilaasje en pakket gearkomste foar in spesifike distribúsje en in spesifike arsjitektuer. Yn dit gefal, kompilaasje wurdt útfierd mei help fan middels taret troch de distributeur. Dat is, it poadium fan it tarieden fan de gearstaller en it selektearjen fan biblioteken wurdt elimineare. Derneist kin it bouproses maklik parallelisearre wurde.
D'r is lykwols in neidiel oan dizze oanpak: foar elke distribúsje binnen deselde arsjitektuer moatte jo jo eigen set fan binêre bestannen sammelje. In oar neidiel is dat sa'n grut oantal masines moatte wurde ûnderhâlden en in grutte hoemannichte skiifromte en RAM moatte wurde tawiisd.
Dit is hoe't KMOD-pakketten fan 'e veeamsnap-kernelmodule wurde kompilearre foar Red Hat-distribúsjes.
Open Build Service
Kollega's fan SUSE besochten wat middengrûn út te fieren yn 'e foarm fan in spesjale tsjinst foar it kompilearjen fan applikaasjes en it gearstallen fan pakketten - .
Yn essinsje is it in hypervisor dy't in firtuele masine makket, alle nedige pakketten dêryn ynstalleart, de applikaasje kompilearret en it pakket yn dizze isolearre omjouwing bout, wêrnei't de firtuele masine wurdt frijlitten.
De planner ymplementearre yn OpenBuildService sil bepale hoefolle firtuele masines it kin lansearje foar optimale pakketbousnelheid. It ynboude ûndertekeningsmeganisme sil de pakketten tekenje en uploade nei it ynboude repository. It ynboude ferzjekontrôlesysteem sil de skiednis fan feroaringen en builds bewarje. Alles wat oerbliuwt is gewoan jo boarnen ta te foegjen oan dit systeem. Jo hoege de tsjinner net iens sels yn te stellen; jo kinne in iepen brûke.
Der is wol in probleem: sa'n harvester is dreech yn te passen yn de besteande ynfrastruktuer. Bygelyks, ferzje kontrôle is net nedich; wy hawwe al ús eigen foar boarne koades. Us hantekeningmeganisme is oars: wy brûke in spesjale server. In repository is ek net nedich.
Derneist wurdt stipe foar oare distribúsjes - bygelyks Red Hat - nochal min ymplementearre, wat te begripen is.
It foardiel fan sa'n tsjinst is rappe stipe foar de folgjende ferzje fan 'e SUSE-distribúsje. Foardat de offisjele oankundiging fan 'e frijlitting, wurde de pakketten nedich foar montage pleatst op in iepenbier repository. In nije ferskynt yn 'e list mei beskikbere distribúsjes op OpenBuildService. Wy kontrolearje it fakje en it wurdt tafoege oan it bouplan. Sa, it tafoegjen fan in nije ferzje fan de distribúsje wurdt dien yn hast ien klik.
Yn ús ynfrastruktuer, mei OpenBuildService, wurdt it heule ferskaat oan KMP-pakketten fan 'e veeamsnap-kernelmodule foar SUSE-distribúsjes gearstald.
Folgjende, ik soe graach wenje op saken spesifyk foar kernel modules.
kernel ABI
Linux kernel modules binne histoarysk ferspraat yn boarne foarm. It feit is dat de makkers fan 'e kearn harsels net belêste mei de soarch fan it stypjen fan in stabile API foar kernelmodules, en benammen op it binêre nivo, fierder oantsjutten as kABI.
Om in module te bouwen foar in vanille kernel, hawwe jo perfoarst de kopteksten fan dizze bepaalde kernel nedich, en it sil allinich wurkje op dizze kernel.
DKMS lit jo it proses fan it bouwen fan modules automatisearje by it bywurkjen fan de kernel. As resultaat brûke brûkers fan it Debian-repository (en syn protte sibben) kernelmodules út it repository fan de distributeur of kompilearre út boarne mei DKMS.
Dizze situaasje past lykwols net benammen by it Enterprise-segment. Proprietêre koade-distributeurs wolle it produkt fersprieden as kompilearre binaries.
Behearders wolle om feiligensredenen gjin ûntwikkelingsark op produksjeservers hâlde. Enterprise Linux-distributeurs lykas Red Hat en SUSE besletten dat se stabile kABI koene stypje foar har brûkers. It resultaat wie KMOD-pakketten foar Red Hat en KMP-pakketten foar SUSE.
De essinsje fan dizze oplossing is frij simpel. Foar in spesifike ferzje fan 'e distribúsje is de kernel API beferzen. De distributeur stelt dat hy brûkt de kearn, bygelyks, 3.10, en makket allinnich korreksjes en ferbetterings dy't net beynfloedzje de kernel ynterfaces, en de modules sammele foar de alderearste kearn kin brûkt wurde foar alle folgjende sûnder recompilation.
Red Hat beweart kABI-kompatibiliteit foar de distribúsje yn har heule libbenssyklus. Dat is, de gearstalde module foar rhel 6.0 (release novimber 2010) moat ek wurkje op ferzje 6.10 (release juny 2018). En dit is hast 8 jier. Fansels, dizze taak is hiel dreech.
Wy hawwe ferskate gefallen opnommen wêr't de veeamsnap-module stoppe mei wurkjen fanwege kABI-kompatibiliteitsproblemen.
Nei't de veeamsnap-module, kompilearre foar RHEL 7.0, ynkompatibel bleek mei de kernel fan RHEL 7.5, mar it laden en waard garandearre om de tsjinner te crashen, ferlitte wy it gebrûk fan kABI-kompatibiliteit foar RHEL 7 hielendal.
Op it stuit befettet it KMOD-pakket foar RHEL 7 in gearkomste foar elke releaseferzje en in skript dat de module lade.
SUSE benadere de taak fan kABI-kompatibiliteit foarsichtiger. Se leverje kABI-kompatibiliteit allinich binnen ien servicepakket.
Bygelyks, de frijlitting fan SLES 12 fûn plak yn septimber 2014. En SLES 12 SP1 wie al yn desimber 2015, dat is, in bytsje mear as in jier is foarby. Sels hoewol beide releases de 3.12-kernel brûke, binne se kABI-ynkompatibel. Fansels is it behâld fan kABI-kompatibiliteit foar mar in jier folle makliker. De jierlikse fernijingssyklus fan kernelmodule soe gjin problemen moatte feroarsaakje foar module-skeppers.
As gefolch fan dit SUSE-belied hawwe wy gjin inkeld probleem opnommen mei kABI-kompatibiliteit yn ús veeamsnap-module. Wier, it oantal pakketten foar SUSE is hast in folchoarder fan grutte grutter.
Patches en backports
Hoewol distributeurs besykje kABI-kompatibiliteit en kernelstabiliteit te garandearjen, besykje se ek de prestaasjes te ferbetterjen en defekten fan dizze stabile kernel te eliminearjen.
Tagelyk, neist har eigen "wurk oan flaters", kontrolearje de ûntwikkelders fan 'e Enterprise Linux kernel feroarings yn' e vanille kernel en oerdrage se nei har "stabile" ien.
Soms liedt dit ta nije .
Yn 'e lêste release fan Red Hat 6 waard in flater makke yn ien fan' e lytse updates. It late ta it feit dat de veeamsnap-module garandearre waard om it systeem te crashen as de snapshot waard frijlitten. Nei it fergelykjen fan de kernelboarnen foar en nei de fernijing, fûnen wy út dat de efterport de skuld wie. In ferlykbere fix waard makke yn 'e vanille kernel ferzje 4.19. It is gewoan dat dizze fix goed wurke yn 'e vanille kernel, mar doe't it oerbrocht nei de "stabile" 2.6.32, ûntstie in probleem mei de spinlock.
Fansels hat elkenien altyd flaters, mar wie it de muoite wurdich om de koade fan 4.19 nei 2.6.32 te slepen, risiko's foar stabiliteit? .. Ik bin der net wis fan ...
It slimste is as marketing belutsen rekket yn it toulûken tusken "stabiliteit" en "modernisearring". De marketingôfdieling moat de kearn fan 'e bywurke distribúsje stabyl wêze, oan' e iene kant, en tagelyk better yn prestaasjes en hawwe nije funksjes. Dit liedt ta frjemde kompromissen.
Doe't ik besocht te bouwen fan in module op kernel 4.4 út SLES 12 SP3, Ik wie ferrast te finen funksjonaliteit fan vanille 4.8 yn it. Yn myn miening is de blok I / O-ymplemintaasje fan 'e 4.4-kernel fan SLES 12 SP3 mear ferlykber mei de 4.8-kernel as de foarige release fan' e stabile 4.4-kernel fan SLES12 SP2. Ik kin net oardielje hokker persintaazje fan koade waard oerdroegen fan kernel 4.8 nei SLES 4.4 foar SP3, mar ik kin net iens neame de kearn deselde stâle 4.4.
It meast ûnnoflike ding hjirfan is dat jo by it skriuwen fan in module dy't like goed wurkje soe op ferskate kernels, jo net langer op 'e kearnferzje kinne fertrouwe. Jo moatte ek rekken hâlde mei de ferdieling. It is goed dat jo soms kinne belutsen wurde by in definysje dy't ferskynt tegearre mei nije funksjonaliteit, mar dizze kâns ferskynt net altyd.
As gefolch, de koade wurdt oergroeid mei nuvere betingsten kompilaasje rjochtlinen.
D'r binne ek patches dy't de dokuminteare kernel API feroarje.
Ik kaam de ferdieling tsjin 5.16 en wie tige ferrast om te sjen dat de lookup_bdev-oprop yn dizze kearnferzje de list mei ynfierparameters feroare.
Om it tegearre te krijen, moast ik in skript tafoegje oan it makefile dat kontrolearret oft de lookup_bdev-funksje in maskerparameter hat.
Undertekenje kernel modules
Mar litte wy weromgean nei de kwestje fan pakketferdieling.
Ien fan 'e foardielen fan stabile kABI is dat kernelmodules kinne wurde tekene as in binêre triem. Yn dit gefal kin de ûntwikkelder der wis fan wêze dat de module net per ongeluk beskeadige is of mei opsetsin wizige is. Jo kinne dit kontrolearje mei it kommando modinfo.
Red Hat- en SUSE-distribúsjes kinne jo de hantekening fan 'e module kontrolearje en allinich laden as it oerienkommende sertifikaat is registrearre op it systeem. It sertifikaat is de iepenbiere kaai wêrmei't de module tekene is. Wy ferspriede it as in apart pakket.
It probleem hjir is dat sertifikaten kinne wurde ynboud yn 'e kearn (distributeurs brûke se) of moatte wurde skreaun nei EFI net-flechtich ûnthâld mei help fan in hulpprogramma mokutil. Utility mokutil By it ynstallearjen fan in sertifikaat fereasket it dat jo it systeem opnij starte en, sels foardat de kernel fan it bestjoeringssysteem laden wurdt, freget de behearder om it laden fan in nij sertifikaat ta te stean.
Sa, it tafoegjen fan in sertifikaat fereasket fysike behearder tagong ta it systeem. As de masine earne yn 'e wolk leit of gewoan yn in tsjinner op ôfstân en tagong is allinich fia it netwurk (bygelyks fia ssh), dan sil it ûnmooglik wêze om in sertifikaat ta te foegjen.
EFI op firtuele masines
Nettsjinsteande it feit dat EFI al lang is stipe troch hast alle moederbordfabrikanten, by it ynstallearjen fan in systeem, kin de behearder net tinke oer de needsaak foar EFI, en it kin útskeakele wurde.
Net alle hypervisors stypje EFI. VMWare vSphere stipet EFI fanôf ferzje 5.
Microsoft Hyper-V krige ek EFI-stipe te begjinnen mei Hyper-V foar Windows Server 2012R2.
Yn 'e standertkonfiguraasje is dizze funksjonaliteit lykwols útskeakele foar Linux-masines, wat betsjut dat it sertifikaat net ynstalleare kin.
Yn vSphere 6.5, set de opsje Secure Boot allinnich mooglik yn de âlde ferzje fan it web ynterface, dat rint fia Flash. Web UI op HTML-5 is noch fier efter.
Eksperimintele distribúsjes
En as lêste, litte wy it probleem beskôgje fan eksperimintele distribúsjes en distribúsjes sûnder offisjele stipe. Oan 'e iene kant binne sokke distribúsjes net wierskynlik te finen op' e servers fan serieuze organisaasjes. D'r is gjin offisjele stipe foar sokke distribúsjes. Dêrom, foarsjen dy. It produkt kin net stipe wurde op sa'n distribúsje.
Sokke distribúsjes wurde lykwols in handich platfoarm foar it útprobearjen fan nije eksperimintele oplossingen. Bygelyks, Fedora, OpenSUSE Tumbleweed of Unstable ferzjes fan Debian. Se binne frij stabyl. Se hawwe altyd nije ferzjes fan programma's en altyd in nije kernel. Yn in jier kin dizze eksperimintele funksjonaliteit einigje yn in bywurke RHEL, SLES of Ubuntu.
Dus as wat net wurket op in eksperimintele distribúsje, is dit in reden om it probleem út te finen en it op te lossen. Jo moatte taret wêze op it feit dat dizze funksjonaliteit ynkoarten sil ferskine op 'e produksjeservers fan brûkers.
Jo kinne de hjoeddeistige list fan offisjeel stipe distribúsjes studearje foar ferzje 3.0 . Mar de echte list mei distribúsjes wêrop ús produkt kin wurkje is folle breder.
Persoanlik wie ik ynteressearre yn it eksperimint mei it Elbrus OS. Nei it finalisearjen fan it veeam-pakket, waard ús produkt ynstalleare en wurke. Ik skreau oer dit eksperimint op Habré yn .
No, stipe foar nije distribúsjes giet troch. Wy wachtsje op ferzje 4.0 om frijlitten te wurden. Beta stiet op it punt om te ferskinen, dus hâld in each út !
Boarne: www.habr.com