Nid tasg hawdd yw creu cymhwysiad wrth gefn sy'n gweithio ar unrhyw ddosbarthiad. Er mwyn sicrhau bod Veeam Agent for Linux yn gweithio ar ddosbarthiadau o Red Hat 6 a Debian 6, i OpenSUSE 15.1 a Ubuntu 19.04, mae'n rhaid i chi ddatrys ystod o broblemau, yn enwedig o ystyried bod y cynnyrch meddalwedd yn cynnwys modiwl cnewyllyn.
Crëwyd yr erthygl yn seiliedig ar ddeunyddiau o araith yn y gynhadledd .
Nid dim ond un o'r systemau gweithredu mwyaf poblogaidd yw Linux. Yn y bôn, mae hwn yn blatfform ar y sail y gallwch chi wneud rhywbeth unigryw, rhywbeth eich hun. Diolch i hyn, mae gan Linux lawer o ddosbarthiadau sy'n wahanol yn eu set o gydrannau meddalwedd. Ac yma mae problem yn codi: er mwyn i gynnyrch meddalwedd weithredu ar unrhyw ddosbarthiad, mae'n rhaid i chi ystyried nodweddion pob un.
Rheolwyr pecynnau. .deb vs .rpm
Gadewch i ni ddechrau gyda'r broblem amlwg o ddosbarthu'r cynnyrch ar draws gwahanol ddosbarthiadau.
Y ffordd fwyaf nodweddiadol o ddosbarthu cynhyrchion meddalwedd yw rhoi'r pecyn ar ystorfa fel y gall y rheolwr pecyn sydd wedi'i gynnwys yn y system ei osod oddi yno.
Fodd bynnag, mae gennym ddau fformat pecyn poblogaidd: rpm и deb. Mae hyn yn golygu y bydd yn rhaid i bawb gefnogi.
Ym myd pecynnau deb, mae lefel y cydweddoldeb yn anhygoel. Mae'r un pecyn yn gosod ac yn gweithio yr un mor dda ar Debian 6 a Ubuntu 19.04. Mae'r safonau ar gyfer y broses o adeiladu pecynnau a gweithio gyda nhw, a osodwyd mewn hen ddosbarthiadau Debian, yn parhau i fod yn berthnasol yn y Linux Mint newfangled ac OS elfennol. Felly, yn achos Veeam Asiant ar gyfer Linux, mae un pecyn dadleuol ar gyfer pob platfform caledwedd yn ddigonol.
Ond ym myd pecynnau rpm, mae'r gwahaniaethau'n fawr. Yn gyntaf, oherwydd y ffaith bod dau ddosbarthwr cwbl annibynnol, Red Hat a SUSE, y mae cydnawsedd yn gwbl ddiangen ar eu cyfer. Yn ail, mae gan y dosbarthwyr hyn gitiau dosbarthu o'r rheini. cymorth ac arbrofol. Nid oes angen cydnawsedd rhyngddynt ychwaith. Daeth i'r amlwg bod gan el6, el7 ac el8 eu pecynnau eu hunain. Pecyn ar wahân ar gyfer Fedora. Pecynnau ar gyfer SLES11 a 12 ac un ar wahân ar gyfer openSUSE. Y brif broblem yw dibyniaethau ac enwau pecynnau.
Problem dibyniaeth
Yn anffodus, mae'r un pecynnau yn aml yn dod i ben o dan enwau gwahanol mewn gwahanol ddosbarthiadau. Isod mae rhestr rannol o ddibyniaethau pecyn veeam.
Ar gyfer EL7:
Ar gyfer SLES 12:
- libblkid
- libgcc
- libstdc++
- ncurses-libs
- ffiws-libs
- ffeil-libs
- veeamsnap=3.0.2.1185
- libblkid1
- libgcc_s1
- libstdc++6
- libmagic1
- libfuse2
- veeamsnap-kmp=3.0.2.1185
O ganlyniad, mae'r rhestr o ddibyniaethau yn unigryw ar gyfer y dosbarthiad.
Yr hyn sy'n gwaethygu yw pan fydd fersiwn wedi'i diweddaru yn dechrau cuddio o dan yr hen enw pecyn.
Enghraifft:
Mae'r pecyn wedi'i ddiweddaru yn Fedora 24 ncurses o fersiwn 5 i fersiwn 6. Adeiladwyd ein cynnyrch gyda fersiwn 5 i sicrhau ei fod yn gydnaws â dosbarthiadau hŷn. I ddefnyddio'r hen fersiwn 5ed o'r llyfrgell ar Fedora 24, roedd yn rhaid i mi ddefnyddio'r pecyn ncurses-compat-libs.
O ganlyniad, mae dau becyn ar gyfer Fedora, gyda gwahanol ddibyniaethau.
Ymhellach yn fwy diddorol. Ar ôl y diweddariad dosbarthu nesaf, y pecyn ncurses-compat-libs gyda fersiwn 5 o'r llyfrgell mae'n troi allan i fod ar gael. Mae'n ddrud i ddosbarthwr lusgo hen lyfrgelloedd i fersiwn newydd o'r dosbarthiad. Ar ôl peth amser, ailadroddodd y broblem ei hun mewn dosbarthiadau SUSE.
O ganlyniad, bu'n rhaid i rai dosbarthiadau ollwng eu dibyniaeth benodol ar ncurses-libs, a thrwsiwch y cynnyrch fel y gall weithio gydag unrhyw fersiwn o'r llyfrgell.
Gyda llaw, yn fersiwn 8 o Red Hat nid oes pecyn meta bellach python, a gyfeiriodd at yr hen dda python 2.7. Mae yna python2 и python3.
Dewis arall yn lle rheolwyr pecynnau
Mae'r broblem gyda dibyniaethau yn hen ac wedi bod yn amlwg ers tro. Dim ond cofio Dibyniaeth uffern.
I gyfuno amrywiol lyfrgelloedd a chymwysiadau fel eu bod i gyd yn gweithio'n sefydlog ac nad ydynt yn gwrthdaro - mewn gwirionedd, dyma'r dasg y mae unrhyw ddosbarthwr Linux yn ceisio ei datrys.
Mae'r rheolwr pecyn yn ceisio datrys y broblem hon mewn ffordd hollol wahanol. Snap oddi wrth Canonical. Y prif syniad: mae'r cais yn rhedeg mewn blwch tywod wedi'i ynysu a'i ddiogelu rhag y brif system. Os oes angen llyfrgelloedd ar gais, cânt eu cyflenwi gyda'r cais ei hun.
Flatpak hefyd yn caniatáu ichi redeg cymwysiadau mewn blwch tywod gan ddefnyddio Linux Containers. Defnyddir y syniad blwch tywod hefyd AppImage.
Mae'r atebion hyn yn caniatáu ichi greu un pecyn ar gyfer unrhyw ddosbarthiad. Rhag ofn Flatpak mae gosod a lansio'r cais yn bosibl hyd yn oed heb yn wybod i'r gweinyddwr.
Y brif broblem yw na all pob cais redeg mewn blwch tywod. Mae angen mynediad uniongyrchol i'r platfform ar rai pobl. Dydw i ddim hyd yn oed yn sôn am fodiwlau cnewyllyn, sy'n gwbl ddibynnol ar y cnewyllyn ac nad ydynt yn ffitio i mewn i'r cysyniad blwch tywod.
Yr ail broblem yw nad yw dosraniadau sy'n boblogaidd yn yr amgylchedd menter gan Red Hat a SUSE yn cynnwys cefnogaeth i Snappy a Flatpak eto.
Yn hyn o beth, nid yw Asiant Veeam ar gyfer Linux ar gael ddim ymlaen .
I gloi'r cwestiwn am reolwyr pecynnau, hoffwn nodi bod opsiwn i roi'r gorau i reolwyr pecyn yn gyfan gwbl trwy gyfuno ffeiliau deuaidd a sgript ar gyfer eu gosod mewn un pecyn.
Mae bwndel o'r fath yn caniatáu ichi greu un pecyn cyffredin ar gyfer gwahanol ddosbarthiadau a llwyfannau, cynnal proses osod ryngweithiol, gan gyflawni'r addasiad angenrheidiol. Dim ond gan VMware yr wyf wedi dod ar draws pecynnau o'r fath ar gyfer Linux.
Problem diweddaru
Hyd yn oed os caiff yr holl faterion dibyniaeth eu datrys, gall y rhaglen redeg yn wahanol ar yr un dosbarthiad. Mae'n fater o ddiweddariadau.
Mae yna 3 strategaeth diweddaru:
- Yr un symlaf yw peidio byth â diweddaru. Sefydlais y gweinydd ac anghofiais amdano. Pam diweddaru os yw popeth yn gweithio? Mae problemau'n dechrau y tro cyntaf i chi gysylltu â chymorth. Mae crëwr y dosbarthiad yn cefnogi'r datganiad wedi'i ddiweddaru yn unig.
- Gallwch ymddiried yn y dosbarthwr a sefydlu diweddariadau awtomatig. Yn yr achos hwn, mae galwad i gefnogaeth yn debygol yn syth ar ôl diweddariad aflwyddiannus.
- Yr opsiwn o ddiweddaru â llaw dim ond ar ôl ei redeg ar seilwaith prawf yw'r mwyaf dibynadwy, ond drud ac yn cymryd llawer o amser. Ni all pawb ei fforddio.
Gan fod gwahanol ddefnyddwyr yn defnyddio gwahanol strategaethau diweddaru, mae angen cefnogi'r datganiad diweddaraf a phob un a ryddhawyd yn flaenorol. Mae hyn yn cymhlethu'r broses ddatblygu a phrofi ac yn ychwanegu cur pen i'r tîm cymorth.
Amrywiaeth o lwyfannau caledwedd
Mae llwyfannau caledwedd gwahanol yn broblem sy'n benodol i god brodorol i raddau helaeth. Ar y lleiaf, mae'n rhaid i chi gasglu deuaidd ar gyfer pob platfform a gefnogir.
Yn y prosiect Veeam Asiant ar gyfer Linux, ni allwn gefnogi unrhyw beth fel y RISC hwn o hyd.
Ni adaf ar y mater hwn yn fanwl. Dim ond y prif broblemau y byddaf yn eu hamlinellu: mathau o blatfform-ddibynnol, megis size_t, aliniad strwythur a gorchymyn beit.
Cysylltu statig a/neu ddeinamig
Ond y cwestiwn yw "Sut i gysylltu â llyfrgelloedd - yn ddeinamig neu'n statig?" werth ei drafod.
Fel rheol, mae cymwysiadau C / C ++ o dan Linux yn defnyddio cyswllt deinamig. Mae hyn yn gweithio'n wych os yw'r cais wedi'i adeiladu'n benodol ar gyfer dosbarthiad penodol.
Os mai'r dasg yw gorchuddio gwahanol ddosbarthiadau gydag un ffeil ddeuaidd, yna mae'n rhaid i chi ganolbwyntio ar y dosbarthiad hynaf â chymorth. I ni, dyma Red Hat 6. Mae'n cynnwys gcc 4.4, nad yw hyd yn oed y safon C++11 yn ei gefnogi .
Rydym yn adeiladu ein prosiect gan ddefnyddio gcc 6.3, sy'n cefnogi C ++14 yn llawn. Yn naturiol, yn yr achos hwn, ar Red Hat 6 mae'n rhaid i chi gario'r libstdc ++ a rhoi hwb i lyfrgelloedd gyda chi. Y ffordd hawsaf yw cysylltu â nhw yn statig.
Ond gwaetha'r modd, ni ellir cysylltu pob llyfrgell yn statig.
Yn gyntaf, mae llyfrgelloedd system fel libfuse, libblkid mae angen cysylltu'n ddeinamig i sicrhau eu bod yn gydnaws â'r cnewyllyn a'i fodiwlau.
Yn ail, mae cynildeb gyda thrwyddedau.
Yn y bôn, mae'r drwydded GPL yn caniatáu ichi gysylltu llyfrgelloedd â chod ffynhonnell agored yn unig. Mae MIT a BSD yn caniatáu cysylltu statig ac yn caniatáu i lyfrgelloedd gael eu cynnwys mewn prosiect. Ond nid yw'n ymddangos bod y LGPL yn gwrth-ddweud cysylltu statig, ond mae'n mynnu bod y ffeiliau angenrheidiol ar gyfer cysylltu yn cael eu rhannu.
Yn gyffredinol, bydd defnyddio cyswllt deinamig yn eich atal rhag gorfod darparu unrhyw beth.
Adeiladu C/C++ ceisiadau
Er mwyn adeiladu cymwysiadau C / C ++ ar gyfer gwahanol lwyfannau a dosbarthiadau, mae'n ddigon dewis neu adeiladu fersiwn addas o gcc a defnyddio traws-grynhowyr ar gyfer pensaernïaeth benodol a chydosod y set gyfan o lyfrgelloedd. Mae'r gwaith hwn yn eithaf dichonadwy, ond yn eithaf trafferthus. Ac nid oes unrhyw sicrwydd y bydd y casglwr a'r llyfrgelloedd a ddewiswyd yn darparu fersiwn ymarferol.
Mantais amlwg: mae'r seilwaith wedi'i symleiddio'n fawr, oherwydd gellir cwblhau'r broses adeiladu gyfan ar un peiriant. Yn ogystal, mae'n ddigon i gasglu un set o deuaidd ar gyfer un bensaernïaeth a gallwch eu pecynnu yn becynnau ar gyfer gwahanol ddosbarthiadau. Dyma sut mae pecynnau veeam yn cael eu hadeiladu ar gyfer Veeam Agent for Linux.
Yn hytrach na'r opsiwn hwn, gallwch chi baratoi fferm adeiladu, hynny yw, nifer o beiriannau ar gyfer cydosod. Bydd pob peiriant o'r fath yn darparu crynhoad cais a chydosod pecyn ar gyfer dosbarthiad penodol a phensaernïaeth benodol. Yn yr achos hwn, mae'r casgliad yn cael ei wneud gan ddefnyddio'r modd a baratowyd gan y dosbarthwr. Hynny yw, mae'r cam o baratoi'r casglwr a dewis llyfrgelloedd yn cael ei ddileu. Yn ogystal, gellir yn hawdd parallelized y broses adeiladu.
Fodd bynnag, mae yna anfantais i'r dull hwn: ar gyfer pob dosbarthiad o fewn yr un bensaernïaeth, bydd yn rhaid i chi gasglu eich set eich hun o ffeiliau deuaidd. Anfantais arall yw bod angen cynnal nifer mor fawr o beiriannau a rhaid dyrannu llawer iawn o le ar y ddisg a RAM.
Dyma sut mae pecynnau KMOD o'r modiwl cnewyllyn veeamsnap yn cael eu llunio ar gyfer dosbarthiadau Red Hat.
Gwasanaeth Adeiladu Agored
Ceisiodd cydweithwyr o SUSE weithredu rhywfaint o dir canol ar ffurf gwasanaeth arbennig ar gyfer llunio ceisiadau a chydosod pecynnau - .
Yn y bôn, mae'n hypervisor sy'n creu peiriant rhithwir, yn gosod yr holl becynnau angenrheidiol ynddo, yn llunio'r cais ac yn adeiladu'r pecyn yn yr amgylchedd ynysig hwn, ac ar ôl hynny mae'r peiriant rhithwir yn cael ei ryddhau.
Bydd y trefnydd a weithredir yn OpenBuildService yn pennu faint o beiriannau rhithwir y gall eu lansio ar gyfer y cyflymder adeiladu pecyn gorau posibl. Bydd y mecanwaith arwyddo adeiledig yn llofnodi'r pecynnau ac yn eu llwytho i fyny i'r ystorfa adeiledig. Bydd y system rheoli fersiwn adeiledig yn arbed hanes newidiadau ac adeiladau. Y cyfan sydd ar ôl yw ychwanegu eich ffynonellau at y system hon. Nid oes rhaid i chi hyd yn oed sefydlu'r gweinydd eich hun; gallwch ddefnyddio un agored.
Fodd bynnag, mae yna broblem: mae cynaeafwr o'r fath yn anodd ei ffitio i mewn i'r seilwaith presennol. Er enghraifft, nid oes angen rheoli fersiwn; mae gennym ni ein rhai ein hunain ar gyfer codau ffynhonnell yn barod. Mae ein mecanwaith llofnod yn wahanol: rydym yn defnyddio gweinydd arbennig. Nid oes angen ystorfa ychwaith.
Yn ogystal, mae cefnogaeth ar gyfer dosbarthiadau eraill - er enghraifft, Red Hat - yn cael ei weithredu'n eithaf gwael, sy'n ddealladwy.
Mantais gwasanaeth o'r fath yw cefnogaeth gyflym ar gyfer y fersiwn nesaf o'r dosbarthiad SUSE. Cyn y cyhoeddiad swyddogol am y datganiad, mae'r pecynnau angenrheidiol ar gyfer cydosod yn cael eu postio ar ystorfa gyhoeddus. Mae un newydd yn ymddangos yn y rhestr o ddosbarthiadau sydd ar gael ar OpenBuildService. Rydym yn gwirio'r blwch ac yn cael ei ychwanegu at y cynllun adeiladu. Felly, mae ychwanegu fersiwn newydd o'r dosbarthiad yn cael ei wneud mewn bron i un clic.
Yn ein seilwaith, gan ddefnyddio OpenBuildService, mae'r holl amrywiaeth o becynnau KMP o'r modiwl cnewyllyn veeamsnap ar gyfer dosbarthiadau SUSE yn cael eu cydosod.
Nesaf, hoffwn ganolbwyntio ar faterion sy'n benodol i fodiwlau cnewyllyn.
cnewyllyn ABI
Yn hanesyddol, mae modiwlau cnewyllyn Linux wedi'u dosbarthu ar ffurf ffynhonnell. Y ffaith yw nad yw crewyr y cnewyllyn yn faich eu hunain â'r pryder o gefnogi API sefydlog ar gyfer modiwlau cnewyllyn, ac yn enwedig ar y lefel ddeuaidd, y cyfeirir ato ymhellach fel kABI.
I adeiladu modiwl ar gyfer cnewyllyn fanila, yn bendant mae angen penawdau'r cnewyllyn penodol hwn arnoch chi, a dim ond ar y cnewyllyn hwn y bydd yn gweithio.
Mae DKMS yn caniatáu ichi awtomeiddio'r broses o adeiladu modiwlau wrth ddiweddaru'r cnewyllyn. O ganlyniad, mae defnyddwyr y storfa Debian (a'i berthnasau niferus) yn defnyddio modiwlau cnewyllyn naill ai o ystorfa'r dosbarthwr neu wedi'u llunio o ffynhonnell gan ddefnyddio DKMS.
Fodd bynnag, nid yw'r sefyllfa hon yn arbennig o addas ar gyfer y segment Menter. Mae dosbarthwyr cod perchnogol eisiau dosbarthu'r cynnyrch fel deuaidd a luniwyd.
Nid yw gweinyddwyr am gadw offer datblygu ar weinyddion cynhyrchu am resymau diogelwch. Penderfynodd dosbarthwyr Enterprise Linux fel Red Hat a SUSE y gallent gefnogi kABI sefydlog i'w defnyddwyr. Y canlyniad oedd pecynnau KMOD ar gyfer pecynnau Red Hat a KMP ar gyfer SUSE.
Mae hanfod yr ateb hwn yn eithaf syml. Ar gyfer fersiwn benodol o'r dosbarthiad, mae'r API cnewyllyn wedi'i rewi. Mae'r dosbarthwr yn nodi ei fod yn defnyddio'r cnewyllyn, er enghraifft, 3.10, ac yn gwneud cywiriadau a gwelliannau yn unig nad ydynt yn effeithio ar y rhyngwynebau cnewyllyn, a gellir defnyddio'r modiwlau a gasglwyd ar gyfer y cnewyllyn cyntaf ar gyfer pob un dilynol heb ail-grynhoi.
Mae Red Hat yn honni bod kABI yn gydnaws â'r dosbarthiad trwy gydol ei gylch bywyd. Hynny yw, dylai'r modiwl sydd wedi'i ymgynnull ar gyfer rhel 6.0 (rhyddhau Tachwedd 2010) hefyd weithio ar fersiwn 6.10 (rhyddhau Mehefin 2018). Ac mae hyn bron i 8 mlynedd. Yn naturiol, mae'r dasg hon yn eithaf anodd.
Rydym wedi cofnodi sawl achos lle rhoddodd y modiwl veeamsnap y gorau i weithio oherwydd materion cydnawsedd kABI.
Ar ôl i'r modiwl veeamsnap, a luniwyd ar gyfer RHEL 7.0, droi allan i fod yn anghydnaws â'r cnewyllyn o RHEL 7.5, ond fe'i llwythodd a'i warantu i ddamwain y gweinydd, fe wnaethom roi'r gorau i ddefnyddio cydnawsedd kABI ar gyfer RHEL 7 yn gyfan gwbl.
Ar hyn o bryd, mae'r pecyn KMOD ar gyfer RHEL 7 yn cynnwys cynulliad ar gyfer pob fersiwn rhyddhau a sgript sy'n llwytho'r modiwl.
Aeth SUSE at y dasg o gydweddoldeb kABI yn fwy gofalus. Maent yn darparu cydnawsedd kABI o fewn un pecyn gwasanaeth yn unig.
Er enghraifft, rhyddhawyd SLES 12 ym mis Medi 2014. Ac roedd SLES 12 SP1 eisoes ym mis Rhagfyr 2015, hynny yw, mae ychydig yn fwy na blwyddyn wedi mynd heibio. Er bod y ddau ddatganiad yn defnyddio'r cnewyllyn 3.12, maent yn anghydnaws â kABI. Yn amlwg, mae cynnal cydnawsedd kABI am flwyddyn yn unig yn llawer haws. Ni ddylai'r cylch diweddaru modiwl cnewyllyn blynyddol achosi problemau i grewyr modiwlau.
O ganlyniad i'r polisi SUSE hwn, nid ydym wedi cofnodi un broblem gyda chydnawsedd kABI yn ein modiwl veeamsnap. Yn wir, mae nifer y pecynnau ar gyfer SUSE bron yn drefn maint yn fwy.
Clytiau a phorthladdoedd cefn
Er bod dosbarthwyr yn ceisio sicrhau cydnawsedd kABI a sefydlogrwydd cnewyllyn, maent hefyd yn ceisio gwella perfformiad a dileu diffygion y cnewyllyn sefydlog hwn.
Ar yr un pryd, yn ogystal â'u “gwaith ar wallau” eu hunain, mae datblygwyr y fenter cnewyllyn Linux yn monitro newidiadau yn y cnewyllyn fanila ac yn eu trosglwyddo i'w un “sefydlog”.
Weithiau mae hyn yn arwain at rai newydd .
Yn y datganiad diweddaraf o Red Hat 6, gwnaed camgymeriad yn un o'r mân ddiweddariadau. Arweiniodd at y ffaith bod y modiwl veeamsnap yn sicr o chwalu'r system pan ryddhawyd y ciplun. Ar ôl cymharu'r ffynonellau cnewyllyn cyn ac ar ôl y diweddariad, fe wnaethom ddarganfod mai'r backport oedd ar fai. Gwnaethpwyd atgyweiriad tebyg yn y fersiwn cnewyllyn fanila 4.19. Dim ond bod yr atgyweiriad hwn wedi gweithio'n iawn yn y cnewyllyn fanila, ond wrth ei drosglwyddo i'r “sefydlog” 2.6.32, cododd problem gyda'r sbinlock.
Wrth gwrs, mae gan bawb wallau bob amser, ond a oedd yn werth llusgo'r cod o 4.19 i 2.6.32, gan beryglu sefydlogrwydd?... Nid wyf yn siŵr ...
Y peth gwaethaf yw pan fydd marchnata yn cymryd rhan yn y tynnu rhaff rhwng “sefydlogrwydd” a “moderneiddio”. Mae angen i'r adran farchnata fod craidd y dosbarthiad wedi'i ddiweddaru yn sefydlog, ar y naill law, ac ar yr un pryd yn well mewn perfformiad a bod â nodweddion newydd. Mae hyn yn arwain at gyfaddawdau rhyfedd.
Pan geisiais adeiladu modiwl ar gnewyllyn 4.4 o SLES 12 SP3, cefais fy synnu i ddod o hyd i ymarferoldeb o fanila 4.8 ynddo. Yn fy marn i, mae gweithrediad bloc I/O y cnewyllyn 4.4 o SLES 12 SP3 yn debycach i'r cnewyllyn 4.8 na'r datganiad blaenorol o'r cnewyllyn sefydlog 4.4 o SLES12 SP2. Ni allaf farnu pa ganran o god a drosglwyddwyd o gnewyllyn 4.8 i SLES 4.4 ar gyfer SP3, ond ni allaf hyd yn oed alw'r cnewyllyn yr un 4.4 sefydlog.
Y peth mwyaf annymunol am hyn yw, wrth ysgrifennu modiwl a fyddai'n gweithio'r un mor dda ar wahanol gnewyllyn, ni allwch ddibynnu ar y fersiwn cnewyllyn mwyach. Mae'n rhaid i chi hefyd ystyried y dosbarthiad. Mae'n dda weithiau y gallwch chi gymryd rhan mewn diffiniad sy'n ymddangos ynghyd â swyddogaeth newydd, ond nid yw'r cyfle hwn bob amser yn ymddangos.
O ganlyniad, mae'r cod yn gordyfu gyda chyfarwyddebau llunio amodol rhyfedd.
Mae yna hefyd glytiau sy'n newid yr API cnewyllyn wedi'i ddogfennu.
Deuthum ar draws y dosbarthiad 5.16 ac roedd yn syndod mawr i weld bod yr alwad lookup_bdev yn y fersiwn cnewyllyn hwn wedi newid y rhestr o baramedrau mewnbwn.
I'w gael at ei gilydd, roedd yn rhaid i mi ychwanegu sgript at y ffeil makefile sy'n gwirio a oes gan y swyddogaeth lookup_bdev baramedr mwgwd.
Modiwlau cnewyllyn arwyddo
Ond gadewch i ni ddychwelyd at fater dosbarthu pecynnau.
Un o fanteision kABI sefydlog yw y gellir llofnodi modiwlau cnewyllyn fel ffeil ddeuaidd. Yn yr achos hwn, gall y datblygwr fod yn sicr nad yw'r modiwl wedi'i ddifrodi'n ddamweiniol neu wedi'i addasu'n fwriadol. Gallwch wirio hyn gyda'r gorchymyn modinfo.
Mae dosbarthiadau Red Hat a SUSE yn caniatáu ichi wirio llofnod y modiwl a'i lwytho dim ond os yw'r dystysgrif gyfatebol wedi'i chofrestru ar y system. Y dystysgrif yw'r allwedd gyhoeddus ar gyfer llofnodi'r modiwl. Rydym yn ei ddosbarthu fel pecyn ar wahân.
Y broblem yma yw y gall tystysgrifau naill ai gael eu cynnwys yn y cnewyllyn (mae dosbarthwyr yn eu defnyddio) neu rhaid eu hysgrifennu i gof anweddol EFI gan ddefnyddio cyfleustodau mokutil. Cyfleustodau mokutil Wrth osod tystysgrif, mae'n gofyn ichi ailgychwyn y system a, hyd yn oed cyn llwytho cnewyllyn y system weithredu, mae'n annog y gweinyddwr i ganiatáu llwytho tystysgrif newydd.
Felly, mae ychwanegu tystysgrif yn gofyn am fynediad gweinyddwr corfforol i'r system. Os yw'r peiriant wedi'i leoli yn rhywle yn y cwmwl neu yn syml mewn ystafell gweinydd anghysbell a dim ond trwy'r rhwydwaith y ceir mynediad (er enghraifft, trwy ssh), yna bydd yn amhosibl ychwanegu tystysgrif.
EFI ar beiriannau rhithwir
Er gwaethaf y ffaith bod bron pob gweithgynhyrchydd mamfwrdd wedi cefnogi EFI ers tro, wrth osod system, efallai na fydd y gweinyddwr yn meddwl am yr angen am EFI, ac efallai y bydd yn anabl.
Nid yw pob hypervisors yn cefnogi EFI. Mae VMWare vSphere yn cefnogi EFI gan ddechrau o fersiwn 5.
Enillodd Microsoft Hyper-V gefnogaeth EFI hefyd gan ddechrau gyda Hyper-V ar gyfer Windows Server 2012R2.
Fodd bynnag, yn y ffurfweddiad rhagosodedig mae'r swyddogaeth hon wedi'i hanalluogi ar gyfer peiriannau Linux, sy'n golygu na ellir gosod y dystysgrif.
Yn vSphere 6.5, gosodwch yr opsiwn Cychwyn Diogel dim ond yn bosibl yn yr hen fersiwn o'r rhyngwyneb gwe, sy'n rhedeg trwy Flash. Mae UI gwe ar HTML-5 yn dal i fod ymhell ar ei hôl hi.
Dosbarthiadau arbrofol
Ac yn olaf, gadewch i ni ystyried mater dosbarthiadau a dosbarthiadau arbrofol heb gefnogaeth swyddogol. Ar y naill law, mae'n annhebygol y bydd dosbarthiadau o'r fath i'w cael ar weinyddion sefydliadau difrifol. Nid oes unrhyw gefnogaeth swyddogol i ddosbarthiadau o'r fath. Felly, darparwch y rheini. Ni ellir cefnogi'r cynnyrch ar ddosbarthiad o'r fath.
Fodd bynnag, mae dosbarthiadau o'r fath yn dod yn llwyfan cyfleus ar gyfer rhoi cynnig ar atebion arbrofol newydd. Er enghraifft, Fedora, OpenSUSE Tumbleweed neu fersiynau ansefydlog o Debian. Maent yn eithaf sefydlog. Mae ganddyn nhw fersiynau newydd o raglenni bob amser a chnewyllyn newydd bob amser. Mewn blwyddyn, gall y swyddogaeth arbrofol hon ddod i ben mewn RHEL, SLES neu Ubuntu wedi'i ddiweddaru.
Felly os nad yw rhywbeth yn gweithio ar ddosbarthiad arbrofol, mae hwn yn rheswm i ddarganfod y broblem a'i datrys. Mae angen i chi fod yn barod am y ffaith y bydd y swyddogaeth hon yn ymddangos yn fuan ar weinyddion cynhyrchu defnyddwyr.
Gallwch astudio'r rhestr gyfredol o ddosbarthiadau a gefnogir yn swyddogol ar gyfer fersiwn 3.0 . Ond mae'r rhestr wirioneddol o ddosbarthiadau y gall ein cynnyrch weithio arnynt yn llawer ehangach.
Yn bersonol, roedd gen i ddiddordeb yn yr arbrawf gyda'r Elbrus OS. Ar ôl cwblhau'r pecyn veeam, gosodwyd ein cynnyrch ac roedd yn gweithio. Ysgrifennais am yr arbrawf hwn ar Habré yn .
Wel, mae cefnogaeth ar gyfer dosbarthiadau newydd yn parhau. Rydym yn aros i fersiwn 4.0 gael ei ryddhau. Mae Beta ar fin ymddangos, felly cadwch lygad allan !
Ffynhonnell: hab.com