Ang paghimo og backup nga aplikasyon nga magamit sa bisan unsang pag-apod-apod dili sayon ββnga buluhaton. Aron masiguro nga ang Veeam Agent para sa Linux nagtrabaho sa mga pag-apod-apod gikan sa Red Hat 6 ug Debian 6, hangtod sa OpenSUSE 15.1 ug Ubuntu 19.04, kinahanglan nimo nga sulbaron ang lainlaing mga problema, labi na kung gikonsiderar nga ang produkto sa software naglakip sa usa ka module sa kernel.
Ang artikulo gihimo base sa mga materyal gikan sa usa ka pakigpulong sa komperensya .
Ang Linux dili lang usa sa labing inila nga operating system. Sa tinuud, kini usa ka plataporma nga gibase sa kung diin mahimo nimo ang usa ka butang nga talagsaon, usa ka butang nga imong kaugalingon. Salamat niini, ang Linux adunay daghang mga distribusyon nga lahi sa ilang hugpong sa mga sangkap sa software. Ug dinhi mitungha ang usa ka problema: aron ang usa ka produkto sa software molihok sa bisan unsang pag-apod-apod, kinahanglan nimo nga tagdon ang mga bahin sa matag usa.
Mga tagdumala sa package. .deb batok .rpm
Magsugod kita sa klaro nga problema sa pag-apod-apod sa produkto sa lainlaing mga pag-apod-apod.
Ang labing kasagaran nga paagi sa pag-apod-apod sa mga produkto sa software mao ang pagbutang sa package sa usa ka repository aron ang tagdumala sa package nga gitukod sa sistema maka-install niini gikan didto.
Bisan pa, kami adunay duha ka sikat nga mga format sa pakete: rpm ΠΈ deb. Kini nagpasabot nga ang tanan kinahanglang mosuporta.
Sa kalibutan sa mga pakete sa deb, ang lebel sa pagkaangay talagsaon. Ang parehas nga pakete nag-install ug parehas nga nagtrabaho sa parehong Debian 6 ug Ubuntu 19.04. Ang mga sumbanan alang sa proseso sa pagtukod sa mga pakete ug pagtrabaho uban kanila, nga gibutang sa daan nga mga distribusyon sa Debian, nagpabilin nga may kalabutan sa bag-ong Linux Mint ug elementarya nga OS. Busa, sa kaso sa Veeam Agent for Linux, igo na ang usa ka deb package alang sa matag hardware platform.
Apan sa kalibutan sa mga pakete sa rpm, ang mga kalainan maayo. Una, tungod sa kamatuoran nga adunay duha ka hingpit nga independente nga mga distributor, Red Hat ug SUSE, diin ang pagkaangay dili kinahanglan. Ikaduha, kini nga mga distributor adunay mga kit sa pag-apod-apod gikan sa mga. suporta ug eksperimento. Dili usab kinahanglan ang pagkaangay tali kanila. Kini nahimo nga ang el6, el7 ug el8 adunay ilang kaugalingon nga mga pakete. Lahi nga pakete alang sa Fedora. Mga pakete alang sa SLES11 ug 12 ug usa ka bulag alang sa openSUSE. Ang panguna nga problema mao ang mga dependency ug mga ngalan sa package.
Problema sa pagsalig
Ikasubo, ang parehas nga mga pakete kanunay nga natapos sa lainlaing mga ngalan sa lainlaing mga pag-apod-apod. Sa ubos usa ka partial nga lista sa mga dependency sa pakete sa veeam.
Para sa EL7:
Para sa SLES 12:
- 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
Ingon usa ka sangputanan, ang lista sa mga dependency talagsaon alang sa pag-apod-apod.
Ang nagkagrabe mao kung ang usa ka na-update nga bersyon nagsugod sa pagtago sa ilawom sa daan nga ngalan sa pakete.
Pananglitan:
Ang pakete gi-update sa Fedora 24 mga ncurses gikan sa bersyon 5 hangtod sa bersyon 6. Ang among produkto gitukod nga adunay bersyon 5 aron masiguro ang pagkaangay sa mga daan nga distribusyon. Aron magamit ang daan nga ika-5 nga bersyon sa librarya sa Fedora 24, kinahanglan nako nga gamiton ang pakete ncurses-compat-libs.
Ingon usa ka sangputanan, adunay duha nga mga pakete alang sa Fedora, nga adunay lainlaing mga dependency.
Dugang nga mas makapaikag. Pagkahuman sa sunod nga pag-update sa pag-apod-apod, ang package ncurses-compat-libs nga adunay bersyon 5 sa librarya kini nahimo nga dili magamit. Kini mahal alang sa usa ka tig-apod-apod sa pag-drag sa daan nga mga librarya ngadto sa usa ka bag-ong bersyon sa pag-apod-apod. Human sa pipila ka panahon, ang problema gisubli sa iyang kaugalingon sa SUSE distributions.
Ingon usa ka sangputanan, ang pipila nga mga pag-apod-apod kinahanglan nga ihulog ang ilang klaro nga pagsalig ncurses-libs, ug ayohon ang produkto aron kini magamit sa bisan unsang bersyon sa librarya.
Pinaagi sa dalan, sa bersyon 8 sa Red Hat wala na usa ka pakete sa meta python, nga nagtumong sa maayo nga tigulang sawa sa 2.7. Adunay python2 ΠΈ python3.
Alternatibo sa mga managers sa package
Ang problema sa mga dependency daan na ug dugay na nga klaro. Hinumdomi lang ang Dependency hell.
Aron makombinar ang lainlaing mga librarya ug aplikasyon aron silang tanan molihok nga lig-on ug dili magkasumpaki - sa tinuud, kini ang tahas nga gisulayan nga sulbaron sa bisan unsang distributor sa Linux.
Ang tagdumala sa pakete naningkamot sa pagsulbad niini nga problema sa lahi nga paagi. Snappy gikan sa Canonical. Ang panguna nga ideya: ang aplikasyon nagdagan sa usa ka sandbox nga nahimulag ug gipanalipdan gikan sa panguna nga sistema. Kung ang usa ka aplikasyon nanginahanglan mga librarya, gihatagan sila sa aplikasyon mismo.
Ang Flatpak nagtugot usab kanimo sa pagpadagan sa mga aplikasyon sa usa ka sandbox gamit ang Linux Containers. Gigamit usab ang ideya sa sandbox AppImage.
Kini nga mga solusyon nagtugot kanimo sa paghimo og usa ka pakete alang sa bisan unsang pag-apod-apod. Sa kaso sa Ang Flatpak Ang pag-instalar ug paglansad sa aplikasyon posible bisan kung wala ang kahibalo sa tagdumala.
Ang nag-unang problema mao nga dili tanan nga mga aplikasyon mahimong modagan sa usa ka sandbox. Ang ubang mga tawo nanginahanglan direkta nga pag-access sa plataporma. Wala ako maghisgot bahin sa mga modulo sa kernel, nga hugot nga nagsalig sa kernel ug dili mohaum sa konsepto sa sandbox.
Ang ikaduha nga problema mao nga ang mga distribusyon nga popular sa palibot sa negosyo gikan sa Red Hat ug SUSE wala pa adunay suporta alang sa Snappy ug Flatpak.
Niini nga bahin, ang Veeam Agent alang sa Linux wala magamit dili gyud .
Aron tapuson ang pangutana bahin sa mga managers sa package, gusto nakong timan-an nga adunay kapilian nga biyaan ang mga managers sa package pinaagi sa paghiusa sa mga binary file ug usa ka script alang sa pag-install niini sa usa ka pakete.
Ang ingon nga usa ka bugkos nagtugot kanimo sa paghimo sa usa ka sagad nga pakete alang sa lainlaing mga pag-apod-apod ug mga platform, paghimo usa ka interactive nga proseso sa pag-install, nga himuon ang kinahanglan nga pag-customize. Nakasugat ra ko sa ingon nga mga pakete alang sa Linux gikan sa VMware.
Pag-update sa problema
Bisan kung ang tanan nga mga isyu sa pagsalig nasulbad, ang programa mahimo nga lahi sa pagdagan sa parehas nga pag-apod-apod. Kini mahitungod sa mga update.
Adunay 3 nga mga estratehiya sa pag-update:
- Ang pinakasimple mao ang dili pag-update. Gipahimutang nako ang server ug nakalimtan nako kini. Ngano nga mag-update kung ang tanan molihok? Ang mga problema magsugod sa unang higayon nga imong kontakon ang suporta. Ang tiglalang sa pag-apod-apod nagsuporta lamang sa gi-update nga pagpagawas.
- Makasalig ka sa tig-apod-apod ug mag-set up sa mga awtomatikong update. Sa kini nga kaso, ang usa ka tawag sa suporta lagmit diha-diha dayon pagkahuman sa usa ka dili malampuson nga pag-update.
- Ang kapilian sa manwal nga pag-update lamang human sa pagpadagan niini sa usa ka pagsulay nga imprastraktura mao ang labing kasaligan, apan mahal ug makahurot sa panahon. Dili tanan makasarang niini.
Tungod kay lain-laing mga tiggamit sa paggamit sa lain-laing mga update nga mga estratehiya, kini mao ang gikinahanglan nga sa pagsuporta sa duha sa pinaka-ulahing release ug sa tanan nga kaniadto gipagawas nga mga. Gikomplikado niini ang proseso sa pag-uswag ug pagsulay ug nagdugang mga labad sa ulo sa grupo sa suporta.
Nagkalainlain nga mga platform sa hardware
Ang lainlaing mga platform sa hardware usa ka problema nga labi ka espesipiko sa lumad nga code. Sa labing gamay, kinahanglan nimo nga mangolekta mga binary alang sa matag gisuportahan nga plataporma.
Sa proyekto sa Veeam Agent para sa Linux, dili gihapon kami makasuporta sa bisan unsa nga sama niini nga RISC.
Dili ko maghisgot niini nga isyu sa detalye. I-outline ra nako ang mga nag-unang problema: mga tipo nga nagsalig sa plataporma, sama sa size_t, pag-align sa istruktura ug han-ay sa byte.
Static ug/o dinamikong pagsumpay
Apan ang pangutana mao ang "Unsaon pag-link sa mga librarya - dinamiko o static?" angay nga hisgutan.
Ingon sa usa ka lagda, ang C/C++ nga mga aplikasyon ubos sa Linux naggamit ug dinamikong pagsumpay. Maayo kini kung ang aplikasyon gitukod alang sa usa ka piho nga pag-apod-apod.
Kung ang tahas mao ang pagtabon sa lainlaing mga pag-apod-apod sa usa ka binary file, nan kinahanglan nimo nga ipunting ang labing karaan nga gisuportahan nga pag-apod-apod. Alang kanamo, kini ang Red Hat 6. Naglangkob kini sa gcc 4.4, nga bisan ang C ++ 11 nga sumbanan wala mosuporta .
Gitukod namo ang among proyekto gamit ang gcc 6.3, nga hingpit nga nagsuporta sa C++14. Natural, sa kini nga kaso, sa Red Hat 6 kinahanglan nimo nga dad-on ang libstdc ++ ug ipataas ang mga librarya uban kanimo. Ang labing kadali nga paagi mao ang pag-link sa kanila sa static.
Apan alaot, dili tanan nga mga librarya mahimong ma-link sa statically.
Una, ang mga librarya sa sistema sama sa libfuse, libblkid kinahanglan nga mag-link sa dinamikong paagi aron masiguro ang ilang pagkaangay sa kernel ug sa mga module niini.
Ikaduha, adunay usa ka subtlety sa mga lisensya.
Ang lisensya sa GPL sa batakan nagtugot kanimo sa pag-link sa mga librarya lamang sa opensource code. Gitugotan sa MIT ug BSD ang static linking ug gitugotan ang mga librarya nga maapil sa usa ka proyekto. Apan ang LGPL ingon og dili supak sa static linking, apan nagkinahanglan nga ang mga file nga gikinahanglan alang sa linking ipaambit.
Sa kinatibuk-an, ang paggamit sa dinamikong pag-link makapugong kanimo sa paghatag bisan unsa.
Pagtukod ug C/C++ nga mga aplikasyon
Aron makatukod ug C/C++ nga mga aplikasyon alang sa lain-laing mga plataporma ug mga distribusyon, igo na ang pagpili o paghimo og angay nga bersyon sa gcc ug paggamit sa mga cross-compiler alang sa piho nga mga arkitektura ug pag-assemble sa tibuok set sa mga librarya. Kini nga trabaho mahimo ra, apan lisud kaayo. Ug walay garantiya nga ang pinili nga compiler ug mga librarya maghatag ug magamit nga bersyon.
Usa ka dayag nga bentaha: ang imprastraktura gipasimple kaayo, tungod kay ang tibuuk nga proseso sa pagtukod mahimong makompleto sa usa ka makina. Dugang pa, igo na ang pagkolekta sa usa ka hugpong sa mga binary alang sa usa ka arkitektura ug mahimo nimo kining i-package sa mga pakete alang sa lainlaing mga pag-apod-apod. Ingon niini ang paghimo sa mga pakete sa veeam alang sa Veeam Agent para sa Linux.
Sukwahi sa kini nga kapilian, mahimo ka lamang mag-andam sa usa ka pagtukod nga umahan, nga mao, daghang mga makina alang sa asembliya. Ang matag ingon nga makina maghatag ug aplikasyon compilation ug package assembly alang sa usa ka piho nga pag-apod-apod ug usa ka piho nga arkitektura. Sa kini nga kaso, ang pagtipon gihimo gamit ang mga paagi nga giandam sa distributor. Kana mao, ang yugto sa pag-andam sa compiler ug pagpili sa mga librarya giwagtang. Dugang pa, ang proseso sa pagtukod dali nga maparehas.
Adunay, bisan pa, usa ka kakulangan sa kini nga pamaagi: alang sa matag pag-apod-apod sa parehas nga arkitektura, kinahanglan nimo nga kolektahon ang imong kaugalingon nga set sa binary nga mga file. Ang laing disbentaha mao nga ang ingon ka daghan nga mga makina kinahanglan nga mamentinar ug usa ka dako nga kantidad sa disk space ug RAM kinahanglan nga igahin.
Ingon niini kung giunsa ang mga pakete sa KMOD sa veeamsnap kernel module gitipon alang sa mga pag-apod-apod sa Red Hat.
Buksan ang Serbisyo sa Pagtukod
Ang mga kauban gikan sa SUSE misulay sa pagpatuman sa pipila ka tunga-tunga sa porma sa usa ka espesyal nga serbisyo alang sa pag-compile sa mga aplikasyon ug pag-assemble sa mga pakete - .
Sa tinuud, kini usa ka hypervisor nga nagmugna usa ka virtual nga makina, nag-install sa tanan nga kinahanglan nga mga pakete niini, nag-compile sa aplikasyon ug nagtukod sa package sa kini nga nahilit nga palibot, pagkahuman gibuhian ang virtual machine.
Ang scheduler nga gipatuman sa OpenBuildService maoy magdeterminar kon pila ka mga virtual machine ang mahimo niini nga ilusad alang sa labing maayo nga katulin sa pagtukod sa pakete. Ang built-in nga mekanismo sa pagpirma mopirma sa mga pakete ug i-upload kini sa built-in nga repository. Ang built-in nga bersyon sa pagkontrol nga sistema magtipig sa kasaysayan sa mga pagbag-o ug pagtukod. Ang nahabilin mao lang ang pagdugang sa imong mga gigikanan sa kini nga sistema. Dili nimo kinahanglan nga i-set up ang server sa imong kaugalingon; mahimo nimong gamiton ang usa nga bukas.
Adunay, bisan pa, usa ka problema: ang ingon nga tig-ani lisud nga mohaum sa kasamtangan nga imprastraktura. Pananglitan, dili kinahanglan ang pagkontrol sa bersyon; naa na miy kaugalingon para sa mga source code. Lahi ang among mekanismo sa pirma: naggamit kami usa ka espesyal nga server. Dili usab kinahanglan ang usa ka repositoryo.
Dugang pa, ang suporta alang sa ubang mga pag-apod-apod - pananglitan, ang Red Hat - gipatuman nga dili maayo, nga masabtan.
Ang bentaha sa ingon nga serbisyo mao ang paspas nga suporta alang sa sunod nga bersyon sa pag-apod-apod sa SUSE. Sa wala pa ang opisyal nga pagpahibalo sa pagpagawas, ang mga pakete nga gikinahanglan alang sa asembliya gibutang sa usa ka publiko nga tipiganan. Usa ka bag-o ang makita sa lista sa magamit nga mga pag-apod-apod sa OpenBuildService. Gisusi namo ang kahon ug gidugang kini sa plano sa pagtukod. Sa ingon, ang pagdugang usa ka bag-ong bersyon sa pag-apod-apod nahimo sa hapit usa ka pag-klik.
Sa among imprastraktura, gamit ang OpenBuildService, ang tibuok klase sa KMP packages sa veeamsnap kernel module para sa SUSE distributions gitigom.
Sunod, gusto nako nga maghisgot bahin sa mga isyu nga piho sa mga module sa kernel.
kernel ABI
Ang mga module sa Linux kernel sa kasaysayan naapod-apod sa gigikanan nga porma. Ang kamatuoran mao nga ang mga tiglalang sa kernel dili palas-anon sa ilang mga kaugalingon uban sa kabalaka sa pagsuporta sa usa ka lig-on nga API alang sa kernel modules, ug ilabi na sa binary nga lebel, dugang nga gitawag nga kABI.
Aron makahimo og module alang sa usa ka vanilla kernel, siguradong kinahanglan nimo ang mga header niining partikular nga kernel, ug kini magamit lamang niini nga kernel.
Gitugotan ka sa DKMS nga i-automate ang proseso sa pagtukod og mga module kung gi-update ang kernel. Ingon nga resulta, ang mga tiggamit sa Debian repository (ug ang daghang mga paryente) naggamit sa kernel modules gikan sa repository sa distributor o gihugpong gikan sa tinubdan gamit ang DKMS.
Bisan pa, kini nga kahimtang dili labi ka angay sa bahin sa Enterprise. Ang proprietary code distributors gusto nga ipang-apod-apod ang produkto isip mga binary nga gihugpong.
Ang mga tigdumala dili gusto nga magpadayon sa mga himan sa pag-uswag sa mga server sa produksiyon alang sa mga hinungdan sa seguridad. Ang mga tig-apod-apod sa Enterprise Linux sama sa Red Hat ug SUSE nakahukom nga ilang suportahan ang stable nga kABI alang sa ilang mga tiggamit. Ang resulta mao ang KMOD packages para sa Red Hat ug KMP packages para sa SUSE.
Ang diwa sa kini nga solusyon yano ra. Alang sa usa ka piho nga bersyon sa pag-apod-apod, ang kernel API gi-frozen. Ang tig-apod-apod nag-ingon nga gigamit niya ang kernel, pananglitan, 3.10, ug naghimo lamang sa mga pagkorihir ug pagpaayo nga dili makaapekto sa mga interface sa kernel, ug ang mga module nga nakolekta alang sa una nga kernel mahimong magamit alang sa tanan nga nagsunod nga walaβy pag-recompilation.
Giangkon sa Red Hat ang kABI compatibility alang sa pag-apod-apod sa tibuok nga lifecycle niini. Kana mao, ang gitigum nga module alang sa rhel 6.0 (pagpagawas sa Nobyembre 2010) kinahanglan usab nga magtrabaho sa bersyon 6.10 (pagpagawas sa Hunyo 2018). Ug kini hapit 8 ka tuig. Siyempre, kini nga buluhaton lisud kaayo.
Nakarekord kami daghang mga kaso diin ang module sa veeamsnap mihunong sa pagtrabaho tungod sa mga isyu sa pagkaangay sa kABI.
Pagkahuman sa module sa veeamsnap, nga giipon alang sa RHEL 7.0, nahimo nga dili katugma sa kernel gikan sa RHEL 7.5, apan kini gikarga ug gigarantiyahan nga ma-crash ang server, gibiyaan namon ang paggamit sa kABI compatibility alang sa RHEL 7 sa hingpit.
Sa pagkakaron, ang KMOD nga pakete alang sa RHEL 7 naglangkob sa usa ka asembliya alang sa matag bersyon sa pagpagawas ug usa ka script nga nagkarga sa module.
Ang SUSE miduol sa tahas sa kABI compatibility nga mas maampingon. Naghatag sila og kABI compatibility lamang sulod sa usa ka service pack.
Pananglitan, ang pagpagawas sa SLES 12 nahitabo niadtong Septiyembre 2014. Ug ang SLES 12 SP1 niadto pang Disyembre 2015, sa ato pa, kapin sa usa ka tuig ang milabay. Bisan kung ang duha nga pagpagawas naggamit sa 3.12 kernel, sila dili magkatugma sa kABI. Dayag, ang pagmintinar sa kABI compatibility sulod lang sa usa ka tuig mas sayon. Ang tinuig nga siklo sa pag-update sa module sa kernel kinahanglan dili magpahinabog mga problema sa mga tiglalang sa module.
Ingon usa ka sangputanan sa kini nga palisiya sa SUSE, wala kami natala nga usa ka problema sa kABI compatibility sa among veeamsnap module. Tinuod, ang gidaghanon sa mga pakete alang sa SUSE hapit usa ka han-ay sa kadako nga mas dako.
Mga patch ug backport
Bisan kung gisulayan sa mga tig-apod-apod nga masiguro ang pagkaangay sa kABI ug kalig-on sa kernel, gisulayan usab nila nga mapaayo ang pasundayag ug mawagtang ang mga depekto sa kini nga lig-on nga kernel.
Sa parehas nga oras, dugang sa ilang kaugalingon nga "pagtrabaho sa mga sayup," ang mga nag-develop sa Linux kernel nag-monitor sa mga pagbag-o sa vanilla kernel ug gibalhin kini sa ilang "stable" nga usa.
Usahay kini mosangpot sa mga bag-o .
Sa pinakabag-o nga pagpagawas sa Red Hat 6, usa ka sayup ang nahimo sa usa sa mga menor de edad nga pag-update. Misangpot kini sa kamatuoran nga ang module sa veeamsnap gigarantiyahan nga ma-crash ang sistema sa dihang gipagawas ang snapshot. Kung itandi ang mga gigikanan sa kernel sa wala pa ug pagkahuman sa pag-update, nahibal-an namon nga ang backport ang mabasol. Ang susama nga pag-ayo gihimo sa vanilla kernel nga bersyon 4.19. Kini ra nga kini nga pag-ayo nagtrabaho nga maayo sa vanilla kernel, apan kung gibalhin kini sa "stable" 2.6.32, usa ka problema ang mitungha sa spinlock.
Siyempre, ang tanan kanunay adunay mga kasaypanan, apan takus ba kini sa pag-drag sa code gikan sa 4.19 ngadto sa 2.6.32, nga nagpameligro sa kalig-on?.. Dili ko sigurado...
Ang pinakagrabe nga butang mao kung ang pagpamaligya maapil sa tug-of-war tali sa "stability" ug "modernization". Ang departamento sa marketing nagkinahanglan sa kinauyokan sa updated distribution aron mahimong lig-on, sa usa ka bahin, ug sa samang higayon mas maayo sa performance ug adunay bag-ong mga bahin. Kini modala ngadto sa katingad-an nga mga pagkompromiso.
Sa diha nga ako misulay sa pagtukod sa usa ka module sa kernel 4.4 gikan sa SLES 12 SP3, ako natingala sa pagpangita sa gamit gikan sa vanilla 4.8 niini. Sa akong opinyon, ang block I/O nga pagpatuman sa 4.4 kernel gikan sa SLES 12 SP3 mas susama sa 4.8 kernel kay sa miaging pagpagawas sa stable 4.4 kernel gikan sa SLES12 SP2. Dili nako mahukman kung unsa nga porsyento sa code ang gibalhin gikan sa kernel 4.8 ngadto sa SLES 4.4 para sa SP3, apan dili nako matawag ang kernel nga parehas nga stable nga 4.4.
Ang labing dili maayo nga butang bahin niini mao nga kung nagsulat usa ka module nga parehas nga molihok sa lainlaing mga kernel, dili ka na makasalig sa bersyon sa kernel. Kinahanglan mo usab nga tagdon ang pag-apod-apod. Maayo nga usahay makaapil ka sa usa ka kahulugan nga makita kauban ang bag-ong pagpaandar, apan kini nga oportunidad dili kanunay nga makita.
Ingon usa ka sangputanan, ang kodigo napuno sa mga katingad-an nga kondisyon sa pag-compile nga mga direktiba.
Adunay usab mga patch nga nagbag-o sa dokumentado nga kernel API.
Nakaabot ko sa distribution 5.16 ug natingala kaayo sa pagkakita nga ang lookup_bdev nga tawag sa kini nga kernel nga bersyon nagbag-o sa lista sa mga parameter sa input.
Aron mahiusa kini, kinahanglan nako nga idugang ang usa ka script sa makefile nga nagsusi kung ang function sa lookup_bdev adunay maskara nga parameter.
Pagpirma sa kernel modules
Apan mobalik kita sa isyu sa pag-apod-apod sa pakete.
Usa sa mga bentaha sa stable nga kABI mao nga ang kernel modules mahimong mapirmahan isip binary file. Sa kini nga kaso, ang developer makasiguro nga ang module wala aksidente nga nadaot o gituyo nga giusab. Mahimo nimong susihon kini gamit ang modinfo command.
Ang mga pag-apod-apod sa Red Hat ug SUSE nagtugot kanimo nga susihon ang pirma sa module ug i-load kini kung ang katugbang nga sertipiko narehistro sa sistema. Ang sertipiko mao ang publiko nga yawe diin ang module gipirmahan. Giapod-apod namon kini ingon usa ka bulag nga pakete.
Ang problema dinhi mao nga ang mga sertipiko mahimong matukod sa kernel (gigamit kini sa mga tig-apod-apod) o kinahanglan nga isulat sa EFI non-volatile memory gamit ang usa ka utility. mokutil. Utility mokutil Kung mag-install ug sertipiko, kinahanglan nimo nga i-reboot ang sistema ug, bisan sa wala pa i-load ang kernel sa operating system, giaghat ang tagdumala nga tugutan ang pagkarga sa usa ka bag-ong sertipiko.
Sa ingon, ang pagdugang usa ka sertipiko nanginahanglan pisikal nga pag-access sa tagdumala sa sistema. Kung ang makina nahimutang sa usa ka dapit sa panganod o sa usa ka hilit nga lawak sa server ug ang pag-access pinaagi lamang sa network (pananglitan, pinaagi sa ssh), nan imposible nga makadugang usa ka sertipiko.
EFI sa mga virtual machine
Bisan pa sa kamatuoran nga ang EFI dugay na nga gisuportahan sa halos tanan nga mga tiggama sa motherboard, sa diha nga ang pag-instalar sa usa ka sistema, ang tagdumala mahimo nga dili maghunahuna mahitungod sa panginahanglan alang sa EFI, ug kini mahimong disabled.
Dili tanang hypervisors nagsuporta sa EFI. Gisuportahan sa VMWare vSphere ang EFI sugod sa bersyon 5.
Ang Microsoft Hyper-V nakakuha usab og suporta sa EFI sugod sa Hyper-V alang sa Windows Server 2012R2.
Bisan pa, sa default nga pag-configure kini nga pag-andar gi-disable alang sa mga makina sa Linux, nga nagpasabut nga ang sertipiko dili ma-install.
Sa vSphere 6.5, itakda ang kapilian Secure Boot posible lamang sa daan nga bersyon sa web interface, nga nagdagan pinaagi sa Flash. Ang Web UI sa HTML-5 layo pa kaayo.
Mga eksperimento nga pag-apod-apod
Ug sa katapusan, atong tagdon ang isyu sa eksperimento nga pag-apod-apod ug pag-apod-apod nga walay opisyal nga suporta. Sa usa ka bahin, ang ingon nga mga pag-apod-apod dili tingali makit-an sa mga server sa mga seryoso nga organisasyon. Walay opisyal nga suporta alang sa maong mga pag-apod-apod. Busa, ihatag ang mga. Ang produkto dili masuportahan sa ingon nga pag-apod-apod.
Bisan pa, ang ingon nga mga pag-apod-apod nahimong usa ka kombenyente nga plataporma alang sa pagsulay sa bag-ong mga solusyon sa eksperimento. Pananglitan, Fedora, OpenSUSE Tumbleweed o Unstable nga mga bersyon sa Debian. Medyo stable sila. Kanunay silang adunay bag-ong mga bersyon sa mga programa ug kanunay usa ka bag-ong kernel. Sa usa ka tuig, kini nga eksperimento nga pagpaandar mahimong mahuman sa usa ka updated nga RHEL, SLES o Ubuntu.
Busa kung ang usa ka butang dili molihok sa usa ka eksperimento nga pag-apod-apod, kini usa ka hinungdan aron mahibal-an ang problema ug masulbad kini. Kinahanglan nga andam ka alang sa kamatuoran nga kini nga pag-andar sa dili madugay makita sa mga server sa produksiyon sa mga tiggamit.
Mahimo nimong tun-an ang kasamtangan nga listahan sa opisyal nga gisuportahan nga mga distribusyon alang sa bersyon 3.0 . Apan ang tinuud nga lista sa mga pag-apod-apod diin mahimoβg molihok ang among produkto labi ka lapad.
Sa personal, interesado ako sa eksperimento sa Elbrus OS. Pagkahuman sa pagtapos sa pakete sa veeam, ang among produkto na-install ug nagtrabaho. Gisulat ko ang bahin sa kini nga eksperimento sa HabrΓ© sa .
Aw, ang suporta alang sa bag-ong mga pag-apod-apod nagpadayon. Naghulat kami alang sa bersyon 4.0 nga ipagawas. Hapit na magpakita ang Beta, busa pagbantay !
Source: www.habr.com