Ang paglikha ng backup na application na gumagana sa anumang pamamahagi ay hindi madaling gawain. Upang matiyak na gumagana ang Veeam Agent para sa Linux sa mga distribusyon mula sa Red Hat 6 at Debian 6, hanggang sa OpenSUSE 15.1 at Ubuntu 19.04, kailangan mong lutasin ang isang hanay ng mga problema, lalo na kung isasaalang-alang na ang produkto ng software ay may kasamang kernel module.
Ang artikulo ay nilikha batay sa mga materyales mula sa isang talumpati sa kumperensya .
Ang Linux ay hindi lamang isa sa pinakasikat na operating system. Sa pangkalahatan, ito ay isang platform kung saan maaari kang gumawa ng isang bagay na natatangi, isang bagay na sa iyo. Dahil dito, ang Linux ay may maraming mga distribusyon na naiiba sa kanilang hanay ng mga bahagi ng software. At narito ang isang problema ay lumitaw: upang ang isang produkto ng software ay gumana sa anumang pamamahagi, kailangan mong isaalang-alang ang mga tampok ng bawat isa.
Mga manager ng package. .deb vs .rpm
Magsimula tayo sa malinaw na problema ng pamamahagi ng produkto sa iba't ibang distribusyon.
Ang pinakakaraniwang paraan upang ipamahagi ang mga produkto ng software ay ilagay ang package sa isang repository upang mai-install ito ng manager ng package na binuo sa system mula doon.
Gayunpaman, mayroon kaming dalawang sikat na format ng package: rpm ΠΈ deb. Nangangahulugan ito na ang lahat ay kailangang sumuporta.
Sa mundo ng mga pakete ng deb, ang antas ng pagiging tugma ay kamangha-manghang. Ang parehong pakete ay nag-i-install at gumagana nang maayos sa parehong Debian 6 at Ubuntu 19.04. Ang mga pamantayan para sa proseso ng pagbuo ng mga pakete at pagtatrabaho sa kanila, na inilatag sa mga lumang distribusyon ng Debian, ay nananatiling may-katuturan sa newfangled Linux Mint at elementary OS. Samakatuwid, sa kaso ng Veeam Agent para sa Linux, isang deb package para sa bawat hardware platform ay sapat.
Ngunit sa mundo ng mga pakete ng rpm, ang mga pagkakaiba ay malaki. Una, dahil sa katotohanan na mayroong dalawang ganap na independiyenteng mga distributor, ang Red Hat at SUSE, kung saan ang pagiging tugma ay ganap na hindi kailangan. Pangalawa, ang mga distributor na ito ay may mga distribution kit mula sa mga iyon. suporta at eksperimental. Hindi rin kailangan ng compatibility sa pagitan nila. May kanya-kanyang package pala ang el6, el7 at el8. Hiwalay na pakete para sa Fedora. Mga package para sa SLES11 at 12 at isang hiwalay na isa para sa openSUSE. Ang pangunahing problema ay dependencies at mga pangalan ng package.
Problema sa dependency
Sa kasamaang palad, ang parehong mga pakete ay madalas na napupunta sa ilalim ng iba't ibang mga pangalan sa iba't ibang mga distribusyon. Nasa ibaba ang isang bahagyang listahan ng mga dependency ng pakete ng 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
Bilang resulta, ang listahan ng mga dependency ay natatangi para sa pamamahagi.
Ang mas malala ay kapag ang isang na-update na bersyon ay nagsimulang magtago sa ilalim ng lumang pangalan ng package.
Halimbawa:
Ang package ay na-update sa Fedora 24 ncurses mula sa bersyon 5 hanggang sa bersyon 6. Ang aming produkto ay ginawa gamit ang bersyon 5 upang matiyak ang pagiging tugma sa mas lumang mga pamamahagi. Upang magamit ang lumang ika-5 na bersyon ng library sa Fedora 24, kailangan kong gamitin ang package ncurses-compat-libs.
Bilang resulta, mayroong dalawang pakete para sa Fedora, na may magkakaibang mga dependency.
Higit pang mas kawili-wili. Pagkatapos ng susunod na pag-update ng pamamahagi, ang package ncurses-compat-libs sa bersyon 5 ng aklatan ito ay lumalabas na hindi magagamit. Mahal para sa isang distributor na i-drag ang mga lumang aklatan sa isang bagong bersyon ng pamamahagi. Pagkaraan ng ilang panahon, naulit ang problema sa mga pamamahagi ng SUSE.
Bilang resulta, ang ilang mga distribusyon ay kailangang ihinto ang kanilang tahasang pagdepende sa ncurses-libs, at ayusin ang produkto upang gumana ito sa anumang bersyon ng library.
Siyanga pala, sa bersyon 8 ng Red Hat ay wala nang meta package python, na tumutukoy sa mabuting matanda sawa 2.7. Mayroong python2 ΠΈ python3.
Alternatibo sa mga manager ng package
Ang problema sa mga dependency ay luma at matagal nang halata. Tandaan lamang ang Dependency hell.
Upang pagsamahin ang iba't ibang mga aklatan at application upang gumana ang lahat nang matatag at hindi magkasalungat - sa katunayan, ito ang gawain na sinusubukang lutasin ng sinumang distributor ng Linux.
Sinusubukan ng manager ng package na lutasin ang problemang ito sa ibang paraan. Malinaw mula sa Canonical. Ang pangunahing ideya: ang application ay tumatakbo sa isang sandbox na nakahiwalay at protektado mula sa pangunahing sistema. Kung ang isang aplikasyon ay nangangailangan ng mga aklatan, ang mga ito ay ibinibigay sa mismong aplikasyon.
Flatpak nagbibigay-daan din sa iyo na magpatakbo ng mga application sa isang sandbox gamit ang Linux Containers. Ginagamit din ang ideya ng sandbox AppImage.
Binibigyang-daan ka ng mga solusyong ito na lumikha ng isang pakete para sa anumang pamamahagi. Kung sakali Flatpak ang pag-install at paglunsad ng application ay posible kahit na walang kaalaman ng administrator.
Ang pangunahing problema ay hindi lahat ng mga application ay maaaring tumakbo sa isang sandbox. Ang ilang mga tao ay nangangailangan ng direktang pag-access sa platform. Hindi ko rin pinag-uusapan ang tungkol sa mga module ng kernel, na mahigpit na nakadepende sa kernel at hindi akma sa konsepto ng sandbox.
Ang pangalawang problema ay ang mga distribusyon na sikat sa kapaligiran ng enterprise mula sa Red Hat at SUSE ay hindi pa naglalaman ng suporta para sa Snappy at Flatpak.
Kaugnay nito, ang Veeam Agent para sa Linux ay hindi magagamit hindi talaga .
Upang tapusin ang tanong tungkol sa mga tagapamahala ng pakete, nais kong tandaan na mayroong isang opsyon na ganap na iwanan ang mga tagapamahala ng pakete sa pamamagitan ng pagsasama-sama ng mga binary file at isang script para sa pag-install ng mga ito sa isang pakete.
Ang ganitong bundle ay nagbibigay-daan sa iyo upang lumikha ng isang karaniwang pakete para sa iba't ibang mga pamamahagi at platform, magsagawa ng isang interactive na proseso ng pag-install, na isinasagawa ang kinakailangang pagpapasadya. Nakatagpo lang ako ng mga ganitong pakete para sa Linux mula sa VMware.
I-update ang problema
Kahit na ang lahat ng mga isyu sa dependency ay nalutas, ang programa ay maaaring tumakbo nang iba sa parehong pamamahagi. Ito ay tungkol sa mga update.
Mayroong 3 mga diskarte sa pag-update:
- Ang pinakasimpleng isa ay hindi kailanman mag-update. Nag-set up ako ng server at nakalimutan ko ito. Bakit mag-update kung gumagana ang lahat? Magsisimula ang mga problema sa unang pagkakataon na makipag-ugnayan ka sa suporta. Sinusuportahan lang ng gumawa ng pamamahagi ang na-update na release.
- Maaari kang magtiwala sa distributor at mag-set up ng mga awtomatikong pag-update. Sa kasong ito, ang isang tawag sa suporta ay malamang na kaagad pagkatapos ng isang hindi matagumpay na pag-update.
- Ang opsyon ng manu-manong pag-update lamang pagkatapos patakbuhin ito sa isang pagsubok na imprastraktura ay ang pinaka-maaasahan, ngunit mahal at nakakaubos ng oras. Hindi lahat ay kayang bayaran ito.
Dahil ang iba't ibang mga user ay gumagamit ng iba't ibang mga diskarte sa pag-update, ito ay kinakailangan upang suportahan ang parehong pinakabagong release at lahat ng naunang inilabas na mga bago. Ginagawa nitong kumplikado ang proseso ng pagbuo at pagsubok at nagdaragdag ng pananakit ng ulo sa team ng suporta.
Iba't ibang mga platform ng hardware
Ang iba't ibang mga platform ng hardware ay isang problema na higit na partikular sa native code. Sa pinakamababa, kailangan mong mangolekta ng mga binary para sa bawat suportadong platform.
Sa proyekto ng Veeam Agent para sa Linux, hindi pa rin namin masusuportahan ang anumang tulad nitong RISC.
Hindi ko na tatalakayin nang detalyado ang isyung ito. Ibabalangkas ko lamang ang mga pangunahing problema: mga uri na umaasa sa platform, tulad ng size_t, pagkakahanay ng istraktura at pagkakasunud-sunod ng byte.
Static at/o dynamic na pag-link
Ngunit ang tanong ay "Paano mag-link sa mga aklatan - dynamic o statically?" sulit na pag-usapan.
Bilang panuntunan, ang mga C/C++ na application sa ilalim ng Linux ay gumagamit ng dynamic na pag-link. Ito ay mahusay na gumagana kung ang application ay partikular na binuo para sa isang partikular na pamamahagi.
Kung ang gawain ay upang masakop ang iba't ibang mga distribusyon gamit ang isang binary file, pagkatapos ay kailangan mong tumuon sa pinakalumang suportadong pamamahagi. Para sa amin, ito ay Red Hat 6. Naglalaman ito ng gcc 4.4, na kahit na ang pamantayang C++11 ay hindi sinusuportahan .
Binubuo namin ang aming proyekto gamit ang gcc 6.3, na ganap na sumusuporta sa C++14. Naturally, sa kasong ito, sa Red Hat 6 kailangan mong dalhin ang libstdc++ at i-boost ang mga library kasama mo. Ang pinakamadaling paraan ay ang pag-link sa kanila nang static.
Ngunit sayang, hindi lahat ng mga aklatan ay maaaring i-link nang static.
Una, ang mga library ng system tulad ng libfuse, libblkid kinakailangang mag-link nang pabago-bago upang matiyak ang kanilang pagiging tugma sa kernel at sa mga module nito.
Pangalawa, mayroong isang subtlety sa mga lisensya.
Ang lisensya ng GPL ay karaniwang nagbibigay-daan sa iyo upang i-link ang mga aklatan gamit lamang ang opensource code. Pinapayagan ng MIT at BSD ang static na pag-link at pinapayagan ang mga aklatan na maisama sa isang proyekto. Ngunit ang LGPL ay tila hindi sumasalungat sa static na pag-link, ngunit nangangailangan na ang mga file na kinakailangan para sa pag-link ay ibahagi.
Sa pangkalahatan, ang paggamit ng dynamic na pag-link ay pipigil sa iyo na magbigay ng anuman.
Pagbuo ng mga C/C++ na application
Upang bumuo ng mga C/C++ na application para sa iba't ibang platform at distribusyon, sapat na ang pumili o bumuo ng angkop na bersyon ng gcc at gumamit ng mga cross-compiler para sa mga partikular na arkitektura at tipunin ang buong hanay ng mga aklatan. Ang gawaing ito ay lubos na magagawa, ngunit medyo mahirap. At walang garantiya na ang napiling compiler at mga aklatan ay magbibigay ng magagamit na bersyon.
Isang halatang kalamangan: ang imprastraktura ay lubos na pinasimple, dahil ang buong proseso ng pagbuo ay maaaring makumpleto sa isang makina. Bilang karagdagan, ito ay sapat na upang mangolekta ng isang hanay ng mga binary para sa isang arkitektura at maaari mong i-package ang mga ito sa mga pakete para sa iba't ibang mga distribusyon. Ito ay kung paano binuo ang mga pakete ng veeam para sa Veeam Agent para sa Linux.
Bilang kabaligtaran sa pagpipiliang ito, maaari ka lamang maghanda ng isang build farm, iyon ay, ilang mga makina para sa pagpupulong. Ang bawat naturang makina ay magbibigay ng compilation ng application at package assembly para sa isang partikular na pamamahagi at isang partikular na arkitektura. Sa kasong ito, ang compilation ay isinasagawa gamit ang mga paraan na inihanda ng distributor. Iyon ay, ang yugto ng paghahanda ng compiler at pagpili ng mga aklatan ay tinanggal. Bilang karagdagan, ang proseso ng pagbuo ay madaling maiparallelize.
Gayunpaman, mayroong isang downside sa diskarteng ito: para sa bawat pamamahagi sa loob ng parehong arkitektura, kakailanganin mong kolektahin ang iyong sariling hanay ng mga binary file. Ang isa pang kawalan ay ang ganoong malaking bilang ng mga makina ay kailangang mapanatili at isang malaking halaga ng puwang sa disk at RAM ay dapat na inilalaan.
Ito ay kung paano pinagsama-sama ang mga pakete ng KMOD ng veeamsnap kernel module para sa mga pamamahagi ng Red Hat.
Buksan ang Build Service
Sinubukan ng mga kasamahan mula sa SUSE na ipatupad ang ilang gitnang lupa sa anyo ng isang espesyal na serbisyo para sa pag-compile ng mga aplikasyon at pag-assemble ng mga pakete - .
Mahalaga, ito ay isang hypervisor na lumilikha ng isang virtual machine, nag-i-install ng lahat ng kinakailangang mga pakete sa loob nito, pinagsama-sama ang application at bubuo ng package sa nakahiwalay na kapaligiran na ito, pagkatapos kung saan ang virtual machine ay inilabas.
Ang scheduler na ipinatupad sa OpenBuildService ay tutukuyin kung gaano karaming mga virtual machine ang maaari nitong ilunsad para sa pinakamainam na bilis ng pagbuo ng package. Pipirmahan ng built-in na mekanismo sa pag-sign ang mga package at ia-upload ang mga ito sa built-in na repository. Ise-save ng built-in na version control system ang kasaysayan ng mga pagbabago at build. Ang natitira na lang ay idagdag lamang ang iyong mga mapagkukunan sa system na ito. Hindi mo na kailangang i-set up ang server mismo; maaari kang gumamit ng bukas.
Mayroong, gayunpaman, ang isang problema: ang naturang harvester ay mahirap na magkasya sa umiiral na imprastraktura. Halimbawa, hindi kailangan ang version control; mayroon na kaming sarili para sa mga source code. Ang aming mekanismo ng lagda ay iba: gumagamit kami ng isang espesyal na server. Hindi rin kailangan ng repositoryo.
Bilang karagdagan, ang suporta para sa iba pang mga pamamahagi - halimbawa, Red Hat - ay ipinatupad sa halip na hindi maganda, na naiintindihan.
Ang bentahe ng naturang serbisyo ay mabilis na suporta para sa susunod na bersyon ng pamamahagi ng SUSE. Bago ang opisyal na anunsyo ng pagpapalabas, ang mga pakete na kailangan para sa pagpupulong ay ipapaskil sa isang pampublikong imbakan. Lumilitaw ang isang bago sa listahan ng mga magagamit na distribusyon sa OpenBuildService. Sinusuri namin ang kahon at idinagdag ito sa plano ng pagbuo. Kaya, ang pagdaragdag ng bagong bersyon ng pamamahagi ay ginagawa sa halos isang pag-click.
Sa aming imprastraktura, gamit ang OpenBuildService, ang buong iba't ibang KMP package ng veeamsnap kernel module para sa mga pamamahagi ng SUSE ay pinagsama-sama.
Susunod, gusto kong pag-isipan ang mga isyung partikular sa mga kernel module.
kernel ABI
Ang mga module ng kernel ng Linux ay dating ipinamahagi sa source form. Ang katotohanan ay ang mga tagalikha ng kernel ay hindi nagpapabigat sa kanilang sarili sa pag-aalala sa pagsuporta sa isang matatag na API para sa mga kernel module, at lalo na sa binary level, na higit pang tinutukoy bilang kABI.
Upang bumuo ng isang module para sa isang vanilla kernel, tiyak na kailangan mo ang mga header ng partikular na kernel na ito, at gagana lamang ito sa kernel na ito.
Pinapayagan ka ng DKMS na i-automate ang proseso ng pagbuo ng mga module kapag ina-update ang kernel. Bilang resulta, ang mga user ng Debian repository (at ang maraming kamag-anak nito) ay gumagamit ng kernel modules mula sa distributor ng repository o na-compile mula sa source gamit ang DKMS.
Gayunpaman, ang sitwasyong ito ay hindi partikular na angkop sa Enterprise segment. Nais ng mga proprietary code distributor na ipamahagi ang produkto bilang pinagsama-samang mga binary.
Hindi nais ng mga administrator na panatilihin ang mga tool sa pag-develop sa mga server ng produksyon para sa mga kadahilanang pangseguridad. Nagpasya ang mga distributor ng Enterprise Linux tulad ng Red Hat at SUSE na maaari nilang suportahan ang matatag na kABI para sa kanilang mga user. Ang resulta ay KMOD packages para sa Red Hat at KMP packages para sa SUSE.
Ang kakanyahan ng solusyon na ito ay medyo simple. Para sa isang partikular na bersyon ng pamamahagi, ang kernel API ay naka-freeze. Sinasabi ng distributor na ginagamit niya ang kernel, halimbawa, 3.10, at gumagawa lamang ng mga pagwawasto at pagpapahusay na hindi nakakaapekto sa mga interface ng kernel, at ang mga module na nakolekta para sa pinakaunang kernel ay maaaring gamitin para sa lahat ng kasunod nang walang recompilation.
Inaangkin ng Red Hat ang kABI compatibility para sa pamamahagi sa buong lifecycle nito. Ibig sabihin, ang naka-assemble na module para sa rhel 6.0 (release November 2010) ay dapat ding gumana sa bersyon 6.10 (release June 2018). At ito ay halos 8 taon. Naturally, ang gawaing ito ay medyo mahirap.
Nagtala kami ng ilang kaso kung saan huminto sa paggana ang module ng veeamsnap dahil sa mga isyu sa compatibility ng kABI.
Matapos ang module ng veeamsnap, na pinagsama-sama para sa RHEL 7.0, lumabas na hindi tugma sa kernel mula sa RHEL 7.5, ngunit nag-load ito at ginagarantiyahan na mag-crash ang server, tinalikuran namin ang paggamit ng kABI compatibility para sa RHEL 7 nang buo.
Sa kasalukuyan, ang KMOD package para sa RHEL 7 ay naglalaman ng isang pagpupulong para sa bawat bersyon ng paglabas at isang script na naglo-load ng module.
Nilapitan ni SUSE ang gawain ng kABI compatibility nang mas maingat. Nagbibigay lamang sila ng kABI compatibility sa loob ng isang service pack.
Halimbawa, ang pagpapalabas ng SLES 12 ay naganap noong Setyembre 2014. At ang SLES 12 SP1 ay nasa Disyembre 2015 na, iyon ay, mahigit isang taon na ang lumipas. Kahit na ang parehong release ay gumagamit ng 3.12 kernel, ang mga ito ay kABI incompatible. Malinaw, ang pagpapanatili ng kABI compatibility sa loob lamang ng isang taon ay mas madali. Ang taunang ikot ng pag-update ng kernel module ay hindi dapat magdulot ng mga problema para sa mga tagalikha ng module.
Bilang resulta ng patakarang ito ng SUSE, wala kaming naitala na isang problema sa kABI compatibility sa aming veeamsnap module. Totoo, ang bilang ng mga pakete para sa SUSE ay halos isang order ng magnitude na mas malaki.
Mga patch at backport
Bagama't sinusubukan ng mga distributor na tiyakin ang pagkakatugma ng kABI at katatagan ng kernel, sinusubukan din nilang pagbutihin ang pagganap at alisin ang mga depekto ng matatag na kernel na ito.
Kasabay nito, bilang karagdagan sa kanilang sariling "trabaho sa mga error," sinusubaybayan ng mga developer ng enterprise Linux kernel ang mga pagbabago sa vanilla kernel at inilipat ang mga ito sa kanilang "stable" na isa.
Minsan ito ay humahantong sa mga bago .
Sa pinakabagong paglabas ng Red Hat 6, isang pagkakamali ang nagawa sa isa sa mga menor de edad na pag-update. Ito ay humantong sa katotohanan na ang module ng veeamsnap ay garantisadong mag-crash sa system kapag inilabas ang snapshot. Ang pagkakaroon ng paghahambing ng mga mapagkukunan ng kernel bago at pagkatapos ng pag-update, nalaman namin na ang backport ang dapat sisihin. Ang isang katulad na pag-aayos ay ginawa sa bersyon ng vanilla kernel 4.19. Ito ay lamang na ang pag-aayos na ito ay gumana nang maayos sa vanilla kernel, ngunit kapag inilipat ito sa "stable" 2.6.32, isang problema ang lumitaw sa spinlock.
Siyempre, lahat ng tao ay laging may mga error, ngunit sulit bang i-drag ang code mula 4.19 hanggang 2.6.32, na nanganganib sa katatagan?.. Hindi ako sigurado...
Ang pinakamasama ay kapag ang marketing ay nasangkot sa tug-of-war sa pagitan ng "katatagan" at "modernisasyon." Ang departamento ng marketing ay nangangailangan ng core ng na-update na pamamahagi upang maging matatag, sa isang banda, at sa parehong oras ay mas mahusay sa pagganap at magkaroon ng mga bagong tampok. Ito ay humahantong sa mga kakaibang kompromiso.
Nang sinubukan kong bumuo ng isang module sa kernel 4.4 mula sa SLES 12 SP3, nagulat ako na makahanap ng functionality mula sa vanilla 4.8 dito. Sa aking opinyon, ang block I/O na pagpapatupad ng 4.4 kernel mula sa SLES 12 SP3 ay mas katulad ng 4.8 kernel kaysa sa nakaraang release ng stable 4.4 kernel mula sa SLES12 SP2. Hindi ko mahuhusgahan kung anong porsyento ng code ang inilipat mula sa kernel 4.8 hanggang SLES 4.4 para sa SP3, ngunit hindi ko man lang matawagan ang kernel ng parehong stable na 4.4.
Ang pinaka-hindi kasiya-siyang bagay tungkol dito ay kapag nagsusulat ng isang module na pantay na gagana sa iba't ibang mga kernel, hindi ka na makakaasa sa bersyon ng kernel. Kailangan mo ring isaalang-alang ang pamamahagi. Mabuti na kung minsan ay maaari kang makisali sa isang kahulugan na lumalabas kasama ng bagong pag-andar, ngunit ang pagkakataong ito ay hindi palaging lumalabas.
Bilang resulta, ang code ay napuno ng kakaibang conditional compilation na mga direktiba.
Mayroon ding mga patch na nagbabago sa dokumentadong kernel API.
Nadatnan ko ang pamamahagi 5.16 at labis na nagulat nang makitang binago ng lookup_bdev na tawag sa bersyon ng kernel na ito ang listahan ng mga parameter ng input.
Upang maisama ito, kinailangan kong magdagdag ng script sa makefile na nagsusuri kung ang lookup_bdev function ay may mask parameter.
Pagpirma ng mga kernel module
Ngunit bumalik tayo sa isyu ng pamamahagi ng pakete.
Ang isa sa mga bentahe ng matatag na kABI ay ang mga kernel module ay maaaring mapirmahan bilang isang binary file. Sa kasong ito, makatitiyak ang developer na ang module ay hindi aksidenteng nasira o sadyang binago. Maaari mong suriin ito gamit ang modinfo command.
Hinahayaan ka ng mga pamamahagi ng Red Hat at SUSE na suriin ang lagda ng module at i-load lamang ito kung ang kaukulang sertipiko ay nakarehistro sa system. Ang sertipiko ay ang pampublikong susi kung saan nilagdaan ang module. Ibinahagi namin ito bilang isang hiwalay na pakete.
Ang problema dito ay ang mga sertipiko ay maaaring itayo sa kernel (ginagamit ito ng mga distributor) o dapat na isulat sa EFI non-volatile memory gamit ang isang utility mokutil. Kagamitan mokutil Kapag nag-i-install ng isang sertipiko, hinihiling sa iyo na i-reboot ang system at, kahit na bago i-load ang kernel ng operating system, sinenyasan ang administrator na payagan ang pag-load ng isang bagong sertipiko.
Kaya, ang pagdaragdag ng isang sertipiko ay nangangailangan ng pisikal na pag-access ng administrator sa system. Kung ang makina ay matatagpuan sa isang lugar sa cloud o sa isang malayong silid ng server at ang pag-access ay sa pamamagitan lamang ng network (halimbawa, sa pamamagitan ng ssh), kung gayon imposibleng magdagdag ng isang sertipiko.
EFI sa mga virtual machine
Sa kabila ng katotohanan na ang EFI ay matagal nang sinusuportahan ng halos lahat ng mga tagagawa ng motherboard, kapag nag-i-install ng isang system, maaaring hindi isipin ng administrator ang pangangailangan para sa EFI, at maaaring hindi ito pinagana.
Hindi lahat ng hypervisors ay sumusuporta sa EFI. Sinusuportahan ng VMWare vSphere ang EFI simula sa bersyon 5.
Nakakuha din ang Microsoft Hyper-V ng suporta sa EFI simula sa Hyper-V para sa Windows Server 2012R2.
Gayunpaman, sa default na configuration ay hindi pinagana ang functionality na ito para sa mga Linux machine, na nangangahulugang hindi ma-install ang certificate.
Sa vSphere 6.5, itakda ang opsyon Secure Boot posible lamang sa lumang bersyon ng web interface, na tumatakbo sa pamamagitan ng Flash. Ang Web UI sa HTML-5 ay malayo pa rin.
Mga pang-eksperimentong pamamahagi
At sa wakas, isaalang-alang natin ang isyu ng mga pang-eksperimentong pamamahagi at pamamahagi nang walang opisyal na suporta. Sa isang banda, ang mga naturang pamamahagi ay malamang na hindi matagpuan sa mga server ng mga seryosong organisasyon. Walang opisyal na suporta para sa mga naturang pamamahagi. Samakatuwid, ibigay ang mga iyon. Ang produkto ay hindi maaaring suportahan sa naturang pamamahagi.
Gayunpaman, ang mga naturang pamamahagi ay nagiging isang maginhawang plataporma para sa pagsubok ng mga bagong pang-eksperimentong solusyon. Halimbawa, Fedora, OpenSUSE Tumbleweed o Unstable na bersyon ng Debian. Medyo stable sila. Palagi silang may mga bagong bersyon ng mga programa at palaging isang bagong kernel. Sa isang taon, maaaring mapunta ang pang-eksperimentong functionality na ito sa isang na-update na RHEL, SLES o Ubuntu.
Kaya kung ang isang bagay ay hindi gumagana sa isang pang-eksperimentong pamamahagi, ito ay isang dahilan upang malaman ang problema at malutas ito. Kailangan mong maging handa para sa katotohanan na ang pagpapaandar na ito ay malapit nang lumitaw sa mga server ng produksyon ng mga user.
Maaari mong pag-aralan ang kasalukuyang listahan ng mga opisyal na sinusuportahang pamamahagi para sa bersyon 3.0 . Ngunit ang totoong listahan ng mga pamamahagi kung saan maaaring gumana ang aming produkto ay mas malawak.
Sa personal, interesado ako sa eksperimento sa Elbrus OS. Matapos i-finalize ang veeam package, na-install at gumagana ang aming produkto. Sumulat ako tungkol sa eksperimentong ito sa HabrΓ© sa .
Buweno, nagpapatuloy ang suporta para sa mga bagong pamamahagi. Naghihintay kami para sa bersyon 4.0 na mailabas. Malapit nang lumitaw ang Beta, kaya bantayan !
Pinagmulan: www.habr.com