Kuunda programu chelezo ambayo inafanya kazi kwenye usambazaji wowote sio kazi rahisi. Ili kuhakikisha Wakala wa Veeam wa Linux anafanya kazi kwenye usambazaji kutoka Red Hat 6 na Debian 6, hadi OpenSUSE 15.1 na Ubuntu 19.04, unapaswa kutatua matatizo mbalimbali, hasa kwa kuzingatia kwamba bidhaa ya programu inajumuisha moduli ya kernel.
Nakala hiyo iliundwa kwa msingi wa nyenzo kutoka kwa hotuba kwenye mkutano huo .
Linux sio moja tu ya mifumo maarufu ya uendeshaji. Kimsingi, hii ni jukwaa kwa msingi ambao unaweza kutengeneza kitu cha kipekee, kitu chako mwenyewe. Shukrani kwa hili, Linux ina usambazaji wengi ambao hutofautiana katika seti yao ya vipengele vya programu. Na hapa tatizo linatokea: ili bidhaa ya programu ifanye kazi kwenye usambazaji wowote, unapaswa kuzingatia vipengele vya kila mmoja.
Wasimamizi wa vifurushi. .deb dhidi ya .rpm
Wacha tuanze na shida dhahiri ya kusambaza bidhaa katika usambazaji tofauti.
Njia ya kawaida ya kusambaza bidhaa za programu ni kuweka kifurushi kwenye hifadhi ili msimamizi wa kifurushi kilichojengwa kwenye mfumo aweze kukisakinisha kutoka hapo.
Walakini, tunayo fomati mbili maarufu za kifurushi: rpm ΠΈ mkazo. Hii inamaanisha kuwa kila mtu atalazimika kuunga mkono.
Katika ulimwengu wa vifurushi vya deni, kiwango cha utangamano ni cha kushangaza. Kifurushi sawa husakinisha na kufanya kazi sawa kwa Debian 6 na Ubuntu 19.04. Viwango vya mchakato wa kujenga vifurushi na kufanya kazi navyo, vilivyowekwa katika usambazaji wa zamani wa Debian, vinabaki kuwa muhimu katika Linux Mint mpya na OS ya msingi. Kwa hivyo, katika kesi ya Wakala wa Veeam kwa Linux, kifurushi kimoja cha deni kwa kila jukwaa la vifaa kinatosha.
Lakini katika ulimwengu wa vifurushi vya rpm, tofauti ni kubwa. Kwanza, kwa sababu ya ukweli kwamba kuna wasambazaji wawili wa kujitegemea kabisa, Red Hat na SUSE, ambayo utangamano hauhitajiki kabisa. Pili, wasambazaji hawa wana vifaa vya usambazaji kutoka kwa hizo. msaada na majaribio. Hakuna haja ya utangamano kati yao pia. Ilibadilika kuwa el6, el7 na el8 wana vifurushi vyao. Kifurushi tofauti cha Fedora. Vifurushi vya SLES11 na 12 na tofauti ya openSUSE. Shida kuu ni utegemezi na majina ya vifurushi.
Tatizo la utegemezi
Kwa bahati mbaya, vifurushi sawa mara nyingi huishia chini ya majina tofauti katika usambazaji tofauti. Ifuatayo ni orodha ya sehemu ya utegemezi wa kifurushi cha veeam.
kwa EL7:
Kwa SLES 12:
- libblkid
- libgcc
- libstdc++
- ncurses-libs
- fuse-libs
- faili-libs
- veeamsnap=3.0.2.1185
- libblkid1
- libgcc_s1
- libstdc++6
- libmagic1
- libfuse2
- veeamsnap-kmp=3.0.2.1185
Kama matokeo, orodha ya utegemezi ni ya kipekee kwa usambazaji.
Kinachozidi kuwa mbaya zaidi ni wakati toleo lililosasishwa linapoanza kujificha chini ya jina la kifurushi cha zamani.
Mfano:
Kifurushi kimesasishwa katika Fedora 24 laana kutoka toleo la 5 hadi toleo la 6. Bidhaa yetu iliundwa kwa toleo la 5 ili kuhakikisha upatanifu na usambazaji wa zamani. Kutumia toleo la zamani la 5 la maktaba kwenye Fedora 24, ilibidi nitumie kifurushi ncurses-compat-libs.
Kama matokeo, kuna vifurushi viwili vya Fedora, na utegemezi tofauti.
Zaidi ya kuvutia zaidi. Baada ya sasisho linalofuata la usambazaji, kifurushi ncurses-compat-libs kwa toleo la 5 la maktaba inageuka kuwa haipatikani. Ni ghali kwa msambazaji kuburuta maktaba kuu hadi kwenye toleo jipya la usambazaji. Baada ya muda, shida ilijirudia katika usambazaji wa SUSE.
Kama matokeo, usambazaji fulani ulilazimika kuacha utegemezi wao wazi ncurses-libs, na urekebishe bidhaa ili iweze kufanya kazi na toleo lolote la maktaba.
Kwa njia, katika toleo la 8 la Red Hat hakuna tena kifurushi cha meta python, ambayo inahusu zamani nzuri chatu 2.7. Kuna python2 ΠΈ python3.
Mbadala kwa wasimamizi wa vifurushi
Shida ya utegemezi ni ya zamani na imekuwa dhahiri kwa muda mrefu. Kumbuka tu kuzimu ya Kutegemea.
Ili kuchanganya maktaba mbalimbali na maombi ili wote wafanye kazi kwa utulivu na wasipingane - kwa kweli, hii ndiyo kazi ambayo msambazaji yeyote wa Linux anajaribu kutatua.
Meneja wa mfuko anajaribu kutatua tatizo hili kwa njia tofauti kabisa. Snappy kutoka kwa Canonical. Wazo kuu: programu inaendesha kwenye sanduku la mchanga lililotengwa na kulindwa kutoka kwa mfumo mkuu. Ikiwa programu inahitaji maktaba, hutolewa na programu yenyewe.
Flatpak pia hukuruhusu kuendesha programu kwenye kisanduku cha mchanga kwa kutumia Vyombo vya Linux. Wazo la sanduku la mchanga pia hutumiwa AppImage.
Suluhisho hizi hukuruhusu kuunda kifurushi kimoja kwa usambazaji wowote. Katika kesi ya Flatpak ufungaji na uzinduzi wa programu inawezekana hata bila ujuzi wa msimamizi.
Shida kuu ni kwamba sio programu zote zinaweza kukimbia kwenye sanduku la mchanga. Watu wengine wanahitaji ufikiaji wa moja kwa moja kwenye jukwaa. Sizungumzi hata juu ya moduli za kernel, ambazo zinategemea sana kernel na haziingii kwenye dhana ya sandbox.
Shida ya pili ni kwamba usambazaji maarufu katika mazingira ya biashara kutoka Red Hat na SUSE bado hauna msaada kwa Snappy na Flatpak.
Katika suala hili, Wakala wa Veeam wa Linux hapatikani sio juu .
Kuhitimisha swali kuhusu wasimamizi wa vifurushi, ningependa kutambua kuwa kuna chaguo la kuwaacha wasimamizi wa vifurushi kabisa kwa kuchanganya faili za binary na hati ya kuzisakinisha kwenye kifurushi kimoja.
Kifungu kama hicho hukuruhusu kuunda kifurushi kimoja cha kawaida kwa usambazaji na majukwaa tofauti, fanya mchakato wa usakinishaji unaoingiliana, ukifanya ubinafsishaji unaohitajika. Nimekutana tu na vifurushi kama hivyo vya Linux kutoka VMware.
Tatizo la kusasisha
Hata kama masuala yote ya utegemezi yatatatuliwa, programu inaweza kukimbia tofauti kwenye usambazaji sawa. Ni suala la sasisho.
Kuna mikakati 3 ya sasisho:
- Rahisi zaidi ni kutosasisha kamwe. Nilianzisha seva na kuisahau. Kwa nini usasishe ikiwa kila kitu kitafanya kazi? Matatizo huanza mara ya kwanza unapowasiliana na usaidizi. Muundaji wa usambazaji anatumia toleo lililosasishwa pekee.
- Unaweza kumwamini msambazaji na kusanidi sasisho otomatiki. Katika kesi hii, simu ya usaidizi inawezekana mara tu baada ya sasisho lisilofanikiwa.
- Chaguo la uppdatering mwongozo tu baada ya kukimbia kwenye miundombinu ya mtihani ni ya kuaminika zaidi, lakini ya gharama kubwa na ya muda. Sio kila mtu anayeweza kumudu.
Kwa kuwa watumiaji tofauti hutumia mikakati tofauti ya sasisho, ni muhimu kuauni toleo la hivi punde na zote zilizotolewa hapo awali. Hii inatatiza mchakato wa ukuzaji na majaribio na huongeza maumivu ya kichwa kwa timu ya usaidizi.
Aina mbalimbali za majukwaa ya vifaa
Majukwaa tofauti ya maunzi ni tatizo ambalo kwa kiasi kikubwa ni mahususi kwa msimbo asilia. Kwa uchache, unapaswa kukusanya jozi kwa kila jukwaa linalotumika.
Katika mradi wa Veeam Agent kwa Linux, bado hatuwezi kutumia kitu chochote kama RISC hii.
Sitakaa juu ya suala hili kwa undani. Nitaelezea tu shida kuu: aina zinazotegemea jukwaa, kama vile size_t, upatanishi wa muundo na mpangilio wa baiti.
Kuunganisha tuli na/au kwa nguvu
Lakini swali ni "Jinsi ya kuunganishwa na maktaba - kwa nguvu au kwa takwimu?" yenye thamani ya kujadiliwa.
Kama sheria, programu za C/C++ chini ya Linux hutumia kuunganisha kwa nguvu. Hii inafanya kazi vizuri ikiwa programu imejengwa mahsusi kwa usambazaji maalum.
Ikiwa kazi ni kufunika usambazaji mbalimbali na faili moja ya binary, basi unapaswa kuzingatia usambazaji wa zamani zaidi unaotumika. Kwa sisi, hii ni Red Hat 6. Ina gcc 4.4, ambayo hata kiwango cha C++11 hakiungi mkono. .
Tunaunda mradi wetu kwa kutumia gcc 6.3, ambayo inasaidia kikamilifu C++14. Kwa kawaida, katika kesi hii, kwenye Red Hat 6 lazima ubeba libstdc++ na kuongeza maktaba nawe. Njia rahisi ni kuwaunganisha kwa takwimu.
Lakini ole, sio maktaba zote zinaweza kuunganishwa kwa takwimu.
Kwanza, maktaba za mfumo kama vile libfuse, libblkid inahitajika kuunganishwa kwa nguvu ili kuhakikisha utangamano wao na kernel na moduli zake.
Pili, kuna ujanja na leseni.
Leseni ya GPL kimsingi hukuruhusu kuunganisha maktaba na msimbo wa opensource pekee. MIT na BSD huruhusu kuunganisha tuli na kuruhusu maktaba kujumuishwa katika mradi. Lakini LGPL haionekani kupingana na uunganisho tuli, lakini inahitaji faili zinazohitajika kuunganishwa zishirikiwe.
Kwa ujumla, kutumia kuunganisha kwa nguvu kutakuzuia kutoa chochote.
Kuunda programu za C/C++
Ili kuunda programu za C/C++ kwa majukwaa na usambazaji tofauti, inatosha kuchagua au kujenga toleo linalofaa la gcc na kutumia vikusanyaji mtambuka kwa usanifu maalum na kukusanya seti nzima ya maktaba. Kazi hii inawezekana kabisa, lakini shida kabisa. Na hakuna uhakika kwamba mkusanyaji aliyechaguliwa na maktaba atatoa toleo linalofanya kazi.
Faida dhahiri: miundombinu imerahisishwa sana, kwani mchakato mzima wa ujenzi unaweza kukamilika kwenye mashine moja. Kwa kuongeza, inatosha kukusanya seti moja ya binaries kwa usanifu mmoja na unaweza kuzifunga kwenye vifurushi kwa usambazaji tofauti. Hivi ndivyo vifurushi vya veeam vinavyoundwa kwa Wakala wa Veeam kwa Linux.
Kinyume na chaguo hili, unaweza tu kuandaa shamba la kujenga, yaani, mashine kadhaa za kusanyiko. Kila mashine kama hiyo itatoa mkusanyiko wa programu na mkusanyiko wa kifurushi kwa usambazaji maalum na usanifu maalum. Katika kesi hii, mkusanyiko unafanywa kwa kutumia njia zilizoandaliwa na msambazaji. Hiyo ni, hatua ya kuandaa mkusanyaji na kuchagua maktaba imeondolewa. Kwa kuongeza, mchakato wa kujenga unaweza kusawazishwa kwa urahisi.
Kuna, hata hivyo, upande wa chini wa mbinu hii: kwa kila usambazaji ndani ya usanifu sawa, itabidi kukusanya seti yako ya faili za binary. Hasara nyingine ni kwamba idadi hiyo kubwa ya mashine inahitaji kudumishwa na kiasi kikubwa cha nafasi ya diski na RAM lazima ipewe.
Hivi ndivyo vifurushi vya KMOD vya moduli ya kernel ya veeamsnap hukusanywa kwa usambazaji wa Red Hat.
Fungua Huduma ya Kujenga
Wenzake kutoka SUSE walijaribu kutekeleza msingi wa kati katika mfumo wa huduma maalum ya kuandaa programu na kukusanya vifurushi - .
Kimsingi, ni hypervisor ambayo inaunda mashine ya kawaida, inasanikisha vifurushi vyote muhimu ndani yake, inakusanya programu na kujenga kifurushi katika mazingira haya ya pekee, baada ya hapo mashine ya kawaida hutolewa.
Kiratibu kilichotekelezwa katika OpenBuildService kitabainisha ni mashine ngapi pepe zinazoweza kuzindua kwa kasi bora ya ujenzi wa kifurushi. Utaratibu wa kusaini uliojengewa ndani utatia saini vifurushi na kuzipakia kwenye hazina iliyojengewa ndani. Mfumo wa udhibiti wa toleo la kujengwa utahifadhi historia ya mabadiliko na hujenga. Kilichobaki ni kuongeza tu vyanzo vyako kwenye mfumo huu. Sio lazima hata usanidi seva mwenyewe; unaweza kutumia iliyo wazi.
Hata hivyo, kuna tatizo: kivunaji kama hicho ni vigumu kutoshea katika miundombinu iliyopo. Kwa mfano, udhibiti wa toleo hauhitajiki; tayari tuna yetu wenyewe kwa misimbo ya chanzo. Utaratibu wetu wa saini ni tofauti: tunatumia seva maalum. Hifadhi pia haihitajiki.
Kwa kuongeza, usaidizi wa usambazaji mwingine - kwa mfano, Red Hat - unatekelezwa badala ya vibaya, ambayo inaeleweka.
Faida ya huduma kama hiyo ni msaada wa haraka kwa toleo linalofuata la usambazaji wa SUSE. Kabla ya tangazo rasmi la kutolewa, vifurushi vinavyohitajika kwa mkusanyiko vinawekwa kwenye hazina ya umma. Mpya inaonekana katika orodha ya usambazaji unaopatikana kwenye OpenBuildService. Tunaangalia sanduku na imeongezwa kwenye mpango wa kujenga. Kwa hivyo, kuongeza toleo jipya la usambazaji hufanywa kwa karibu mbofyo mmoja.
Katika miundombinu yetu, kwa kutumia OpenBuildService, aina nzima ya vifurushi vya KMP vya moduli ya kernel ya veeamsnap kwa usambazaji wa SUSE hukusanywa.
Ifuatayo, ningependa kukaa juu ya maswala maalum kwa moduli za kernel.
punje ABI
Module za Linux kernel kihistoria zimesambazwa katika fomu ya chanzo. Ukweli ni kwamba waundaji wa kernel hawajitwi na wasiwasi wa kuunga mkono API thabiti ya moduli za kernel, na haswa katika kiwango cha binary, kinachojulikana zaidi kama kABI.
Ili kujenga moduli ya kernel ya vanilla, hakika unahitaji vichwa vya kernel hii, na itafanya kazi tu kwenye kernel hii.
DKMS hukuruhusu kubinafsisha mchakato wa kujenga moduli wakati wa kusasisha kernel. Kama matokeo, watumiaji wa hazina ya Debian (na jamaa zake nyingi) hutumia moduli za kernel kutoka kwa hazina ya msambazaji au zilizokusanywa kutoka kwa chanzo kwa kutumia DKMS.
Hata hivyo, hali hii haifai hasa sehemu ya Biashara. Wasambazaji wa kanuni za umiliki wanataka kusambaza bidhaa kama jozi zilizokusanywa.
Wasimamizi hawataki kuweka zana za usanidi kwenye seva za uzalishaji kwa sababu za usalama. Wasambazaji wa Enterprise Linux kama vile Red Hat na SUSE waliamua kwamba wanaweza kutumia kABI thabiti kwa watumiaji wao. Matokeo yake yalikuwa vifurushi vya KMOD vya Red Hat na vifurushi vya KMP vya SUSE.
Kiini cha suluhisho hili ni rahisi sana. Kwa toleo maalum la usambazaji, API ya kernel imegandishwa. Msambazaji anasema kwamba anatumia kernel, kwa mfano, 3.10, na hufanya masahihisho tu na maboresho ambayo hayaathiri miingiliano ya kernel, na moduli zilizokusanywa kwa kernel ya kwanza zinaweza kutumika kwa zote zinazofuata bila kurudisha.
Red Hat inadai uoanifu wa kABI kwa usambazaji katika mzunguko wake wote wa maisha. Hiyo ni, moduli iliyokusanywa ya rhel 6.0 (kutolewa Novemba 2010) inapaswa pia kufanya kazi kwenye toleo la 6.10 (kutolewa Juni 2018). Na hii ni karibu miaka 8. Kwa kawaida, kazi hii ni ngumu sana.
Tumerekodi matukio kadhaa ambapo moduli ya veeamsnap iliacha kufanya kazi kwa sababu ya matatizo ya uoanifu wa kABI.
Baada ya moduli ya veeamsnap, iliyotungwa kwa RHEL 7.0, kugeuka kuwa haioani na kernel kutoka RHEL 7.5, lakini ilipakia na kuhakikishiwa kuharibu seva, tuliacha matumizi ya uoanifu wa kABI kwa RHEL 7 kabisa.
Kwa sasa, kifurushi cha KMOD cha RHEL 7 kina mkusanyiko kwa kila toleo la toleo na hati inayopakia moduli.
SUSE ilishughulikia kazi ya upatanifu wa kABI kwa uangalifu zaidi. Wanatoa utangamano wa kABI tu ndani ya pakiti moja ya huduma.
Kwa mfano, kutolewa kwa SLES 12 kulifanyika mnamo Septemba 2014. Na SLES 12 SP1 ilikuwa tayari mnamo Desemba 2015, yaani, zaidi ya mwaka umepita. Ingawa matoleo yote mawili yanatumia 3.12 kernel, hayaendani na kABI. Ni wazi, kudumisha utangamano wa kABI kwa mwaka mmoja tu ni rahisi zaidi. Mzunguko wa kila mwaka wa kusasisha moduli ya kernel haipaswi kusababisha matatizo kwa waundaji wa moduli.
Kutokana na sera hii ya SUSE, hatujarekodi tatizo hata moja la uoanifu wa kABI katika sehemu yetu ya veeamsnap. Kweli, idadi ya vifurushi vya SUSE ni karibu amri ya ukubwa zaidi.
Patches na backports
Ingawa wasambazaji hujaribu kuhakikisha upatanifu wa kABI na uthabiti wa kernel, pia hujaribu kuboresha utendakazi na kuondoa kasoro za punje hii thabiti.
Wakati huo huo, pamoja na "kazi yao juu ya makosa," watengenezaji wa biashara ya Linux kernel hufuatilia mabadiliko kwenye kernel ya vanilla na kuwahamisha kwa "imara" yao.
Wakati mwingine hii inasababisha mpya .
Katika toleo la hivi punde la Red Hat 6, kosa lilifanywa katika moja ya sasisho ndogo. Ilisababisha ukweli kwamba moduli ya veeamsnap ilihakikishiwa kuharibu mfumo wakati snapshot ilitolewa. Baada ya kulinganisha vyanzo vya kernel kabla na baada ya sasisho, tuligundua kuwa uwanja wa nyuma ndio wa kulaumiwa. Marekebisho sawa yalifanywa katika toleo la vanilla kernel 4.19. Ni kwamba marekebisho haya yalifanya kazi vizuri katika kernel ya vanilla, lakini wakati wa kuihamisha kwenye "imara" 2.6.32, tatizo liliondoka na spinlock.
Kwa kweli, kila mtu ana makosa kila wakati, lakini ilikuwa inafaa kuvuta nambari kutoka 4.19 hadi 2.6.32, kuhatarisha utulivu? .. Sina hakika ...
Jambo baya zaidi ni wakati uuzaji unapohusika katika kuvuta kamba kati ya "utulivu" na "kisasa". Idara ya uuzaji inahitaji msingi wa usambazaji uliosasishwa kuwa thabiti, kwa upande mmoja, na wakati huo huo kuwa bora katika utendaji na kuwa na huduma mpya. Hii inasababisha maelewano ya ajabu.
Nilipojaribu kuunda moduli kwenye kernel 4.4 kutoka SLES 12 SP3, nilishangaa kupata utendaji kutoka kwa vanilla 4.8 ndani yake. Kwa maoni yangu, utekelezaji wa block I/O wa 4.4 kernel kutoka SLES 12 SP3 ni sawa na kernel 4.8 kuliko kutolewa hapo awali kwa kernel 4.4 kutoka SLES12 SP2. Siwezi kuhukumu ni asilimia ngapi ya msimbo ulihamishwa kutoka kernel 4.8 hadi SLES 4.4 kwa SP3, lakini siwezi hata kuita kernel sawa 4.4.
Jambo lisilo la kufurahisha zaidi juu ya hili ni kwamba wakati wa kuandika moduli ambayo ingefanya kazi sawa kwenye kokwa tofauti, huwezi kutegemea tena toleo la kernel. Pia unapaswa kuzingatia usambazaji. Ni vizuri kwamba wakati mwingine unaweza kushiriki katika ufafanuzi unaoonekana pamoja na utendaji mpya, lakini fursa hii haionekani kila wakati.
Kwa hivyo, msimbo unakuwa na maagizo ya kushangaza ya ujumuishaji wa masharti.
Pia kuna viraka vinavyobadilisha API ya kernel iliyoandikwa.
Nilikutana na usambazaji 5.16 na nilishangaa sana kuona kwamba simu ya lookup_bdev katika toleo hili la kernel ilibadilisha orodha ya vigezo vya ingizo.
Ili kuiweka pamoja, ilibidi niongeze hati kwenye faili ambayo huangalia ikiwa kazi ya lookup_bdev ina parameta ya mask.
Kusaini moduli za kernel
Lakini wacha turudi kwenye suala la usambazaji wa kifurushi.
Mojawapo ya faida za kABI thabiti ni kwamba moduli za kernel zinaweza kusainiwa kama faili ya binary. Katika kesi hii, msanidi programu anaweza kuwa na uhakika kwamba moduli haijaharibiwa kwa bahati mbaya au kubadilishwa kwa makusudi. Unaweza kuangalia hii na modinfo amri.
Usambazaji wa Red Hat na SUSE hukuruhusu kuangalia saini ya moduli na kuipakia tu ikiwa cheti kinacholingana kimesajiliwa kwenye mfumo. Cheti ni ufunguo wa umma ambao moduli imetiwa saini. Tunaisambaza kama kifurushi tofauti.
Shida hapa ni kwamba cheti zinaweza kujengwa ndani ya kernel (wasambazaji wanazitumia) au lazima ziandikwe kwa kumbukumbu isiyo ya tete ya EFI kwa kutumia matumizi. mokutil. Huduma mokutil Wakati wa kusakinisha cheti, inakuhitaji kuwasha upya mfumo na, hata kabla ya kupakia kerneli ya mfumo wa uendeshaji, inamshauri msimamizi kuruhusu upakiaji wa cheti kipya.
Kwa hivyo, kuongeza cheti kunahitaji ufikiaji wa msimamizi wa mwili kwa mfumo. Ikiwa mashine iko mahali fulani kwenye wingu au tu kwenye chumba cha seva ya mbali na ufikiaji ni kupitia mtandao tu (kwa mfano, kupitia ssh), basi haitawezekana kuongeza cheti.
EFI kwenye mashine pepe
Licha ya ukweli kwamba EFI imeungwa mkono kwa muda mrefu na karibu wazalishaji wote wa bodi ya mama, wakati wa kufunga mfumo, msimamizi hawezi kufikiri juu ya haja ya EFI, na inaweza kuwa imezimwa.
Sio hypervisors zote zinazounga mkono EFI. VMWare vSphere inasaidia EFI kuanzia toleo la 5.
Microsoft Hyper-V pia ilipata usaidizi wa EFI kuanzia Hyper-V kwa Windows Server 2012R2.
Hata hivyo, katika usanidi chaguo-msingi utendakazi huu umezimwa kwa mashine za Linux, kumaanisha kuwa cheti hakiwezi kusakinishwa.
Katika vSphere 6.5, weka chaguo Boot salama inawezekana tu katika toleo la zamani la kiolesura cha wavuti, kinachoendesha kupitia Flash. UI ya Wavuti kwenye HTML-5 bado iko nyuma sana.
Usambazaji wa majaribio
Na hatimaye, hebu fikiria suala la usambazaji wa majaribio na usambazaji bila msaada rasmi. Kwa upande mmoja, usambazaji kama huo hauwezekani kupatikana kwenye seva za mashirika makubwa. Hakuna usaidizi rasmi kwa usambazaji kama huo. Kwa hiyo, toa hizo. Bidhaa haiwezi kutumika kwenye usambazaji kama huo.
Hata hivyo, usambazaji kama huu huwa jukwaa rahisi la kujaribu suluhu mpya za majaribio. Kwa mfano, Fedora, OpenSUSE Tumbleweed au matoleo yasiyo thabiti ya Debian. Wao ni imara kabisa. Daima huwa na matoleo mapya ya programu na daima kernel mpya. Baada ya mwaka mmoja, utendakazi huu wa majaribio unaweza kuishia katika RHEL, SLES au Ubuntu iliyosasishwa.
Kwa hiyo ikiwa kitu haifanyi kazi kwenye usambazaji wa majaribio, hii ndiyo sababu ya kutambua tatizo na kutatua. Unahitaji kuwa tayari kwa ukweli kwamba utendakazi huu utaonekana hivi karibuni kwenye seva za uzalishaji za watumiaji.
Unaweza kusoma orodha ya sasa ya usambazaji unaotumika rasmi kwa toleo la 3.0 . Lakini orodha halisi ya usambazaji ambayo bidhaa yetu inaweza kufanya kazi ni pana zaidi.
Binafsi, nilipendezwa na majaribio na Elbrus OS. Baada ya kukamilisha kifurushi cha veeam, bidhaa yetu iliwekwa na kufanya kazi. Niliandika kuhusu jaribio hili kwa Habre in .
Kweli, msaada kwa usambazaji mpya unaendelea. Tunasubiri toleo la 4.0 kutolewa. Beta inakaribia kuonekana, kwa hivyo endelea kufuatilia !
Chanzo: mapenzi.com