{"id":38929,"date":"2019-10-31T22:26:48","date_gmt":"2019-10-31T19:26:48","guid":{"rendered":"https:\/\/prohoster.info\/blog\/linux-mnogolikij-kak-rabotat-na-lyubom-distributive\/"},"modified":"2019-10-31T22:26:48","modified_gmt":"2019-10-31T19:26:48","slug":"linux-mnogolikij-kak-rabotat-na-lyubom-distributive","status":"publish","type":"post","link":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/linux-mnogolikij-kak-rabotat-na-lyubom-distributive","title":{"rendered":"Linux mangfoldig: korleis arbeida p\u00e5 kva som helst distribusjon","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Linux mangfoldig: korleis arbeida p\u00e5 kva som helst distribusjon\" src=\"\/wp-content\/uploads\/2019\/10\/ee1aaad566204532c974a3ce8f13b915.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n\u00c5 lage ei app for sikkerheitskopiering som fungerer p\u00e5 kva som helst distribusjon er ei krevjande oppg\u00e5ve. For \u00e5 sikre at Veeam Agent for Linux fungerer p\u00e5 distribusjonar fr\u00e5 Red Hat 6 til Debian 6, OpenSUSE 15.1 og Ubuntu 19.04, m\u00e5 ein l\u00f8ysa eit spekter av problem, spesielt med tanke p\u00e5 at programvaren inkluderer ein kjerne-modul.<\/p>\n<p>Artikkelen er basert p\u00e5 materiale fr\u00e5 eit foredrag p\u00e5 konferansen <noindex><a rel=\"nofollow\" href=\"https:\/\/linuxpiter.com\/materials\/2636\"> LinuxPiter 2019<\/a><\/noindex>.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nLinux er ikkje berre eitt av dei mest popul\u00e6re operativsystema. I utgangspunktet er det ei plattform der ein kan lage noko unikt, noko eige. Takka vere dette har Linux mange distribusjonar som skil seg fr\u00e5 kvarandre ved hjelp av ei rekkje programvarekomponentar. Her oppst\u00e5r problemet: For at programvaren skal fungere p\u00e5 kva som helst distribusjon, m\u00e5 ein ta omsyn til eigenskapene til kvar enkelt.<\/p>\n<h2>Pakkeh\u00e5ndterarar. .deb vs .rpm<\/h2>\n<p>\nLa oss byrja med det \u00e5penbare problemet med distribusjon av produktet for ulike distribusjonar.<br \/>\nDen mest vanlege m\u00e5ten \u00e5 distribuere programvara p\u00e5 er \u00e5 leggje ut ein pakke i eit repositorium slik at den innebygde pakkeh\u00e5ndteraren i systemet kan installere den derfr\u00e5.<br \/>\nDet er imidlertid to popul\u00e6re pakkformat: <i>rpm<\/i> og <i>deb<\/i>. Det betyr at vi m\u00e5 st\u00f8tte kvar enkelt.<\/p>\n<p>I verda av deb-pakkar er kompabiliteten imponerande. Den same pakken installerer og fungerer like godt p\u00e5 b\u00e5de Debian 6 og Ubuntu 19.04. Standardane for pakkeoppretting og arbeid med dei som blei lagt i tidlege Debian-distribusjonar, er fremdeles relevante ogs\u00e5 i moderne Linux Mint og elementary OS. Difor er det nok med ein deb-pakke for kvar maskinvareplattform for Veeam Agent for Linux.<\/p>\n<p>Derimot er forskjellane i verda av rpm-pakkar store. For det f\u00f8rste fordi det finst to heilt uavhengige distribusjonar, Red Hat og SUSE, som ikkje har noko behov for kompabilitet. For det andre har desse distribusjonane b\u00e5de distribusjonar med teknisk st\u00f8tte og eksperimentelle. Mellom desse er kompabilitet ogs\u00e5 un\u00f8dvendig. Det viser seg at vi har eigne pakkar for el6, el7 og el8. I tillegg ein eigen pakke for Fedora. Pakkar for SLES11 og 12 og ein eigen for openSUSE. Hovudproblemet er avhengigheiter og namn p\u00e5 pakkar. <\/p>\n<h2>Problemet med avhengigheiter<\/h2>\n<p>\nDessverre har dei same pakkane ofte ulike namn i forskjellige distribusjonar. Nedenfor er ein ufullstendig liste over avhengigheiter for veeam-pakken.<\/p>\n<p>For EL7:<br \/>\nFor SLES 12:<\/p>\n<ul>\n<li>libblkid<\/li>\n<li>libgcc<\/li>\n<li>libstdc++<\/li>\n<li>ncurses-libs<\/li>\n<li>fuse-libs<\/li>\n<li>file-libs<\/li>\n<li>veeamsnap = 3.0.2.1185<\/li>\n<\/ul>\n<ul>\n<li>libblkid1<\/li>\n<li>libgcc_s1<\/li>\n<li>libstdc++6<\/li>\n<li>libmagic1<\/li>\n<li>libfuse2<\/li>\n<li>veeamsnap-kmp = 3.0.2.1185<\/li>\n<\/ul>\n<p>\nSom f\u00f8lger av dette blir avhengighetslisten unik for distribusjonen. <\/p>\n<p>Det blir enda verre n\u00e5r en oppdatert versjon begynner \u00e5 skjule seg under det gamle pakkenavnet. <\/p>\n<p><b>Eksempel:<\/b><\/p>\n<p>I Fedora 24 ble pakken oppdatert <i>ncurses<\/i> fra versjon 5 til versjon 6. V\u00e5r produkt ble bygget med versjon 5 for \u00e5 sikre kompatibilitet med gamle distribusjoner. For \u00e5 bruke den gamle versjon 5 av biblioteket p\u00e5 Fedora 24 m\u00e5tte man bruke pakken <i>ncurses-compat-libs<\/i>. <\/p>\n<p>Som et resultat f\u00e5r Fedora to pakker, med forskjellige avhengigheter. <\/p>\n<p>S\u00e5 blir det mer interessant. Etter en ny oppdatering av distribusjonen blir pakken <i>ncurses-compat-libs<\/i> med versjon 5 av biblioteket utilgjengelig. For distribut\u00f8ren er det besv\u00e6rlig \u00e5 trekke gamle biblioteker inn i den nye versjonen av distribusjonen. Etter en tid dukket det samme problemet opp i SUSE-distribusjoner.<\/p>\n<p>Som et resultat m\u00e5tte man for noen distribusjoner gi opp den eksplisitte avhengigheten fra <i>ncurses-libs<\/i>, og produktet m\u00e5tte justeres slik at det kunne fungere med hvilken som helst versjon av biblioteket.<\/p>\n<p>Forresten, i Red Hat versjon 8 finnes ikke lenger meta-pakken <i>python<\/i>, som refererte til den gamle gode <i>python 2.7<\/i>. Det finnes <i>python2<\/i> og <i>python<\/i>3. <\/p>\n<h2>Alternativ til pakkebehandlerne<\/h2>\n<p>\nProblemet med avhengigheter er gammelt og \u00e5penbart. Bare minn om Dependency hell. <br \/>\n\u00c5 samle ulike biblioteker og applikasjoner slik at de alle fungerer stabilt og ikke konflikter \u2014 dette er utvilsomt oppgaven enhver Linux-distribut\u00f8r pr\u00f8ver \u00e5 l\u00f8se.<\/p>\n<p>Helt annerledes fors\u00f8ker pakkebehandleren <b>Snappy<\/b> fra Canonical. Hovedideen: applikasjonen kj\u00f8res i en isolert og beskyttet sandkasse fra hovedsystemet. Hvis applikasjonen trenger biblioteker, leveres de sammen med selve applikasjonen.<\/p>\n<p><b>Flatpak<\/b> lar ogs\u00e5 kj\u00f8re applikasjoner i sandkassen ved bruk av Linux Containers. Ideen om sandkasse brukes ogs\u00e5 av <b>AppImage<\/b>.<\/p>\n<p>Disse l\u00f8sningene gj\u00f8r det mulig \u00e5 lage \u00e9n pakke for alle distribusjoner. N\u00e5r det gjelder <b>Flatpak<\/b> kan installasjon og kj\u00f8ring av applikasjonen skje selv uten administratorens viten.<\/p>\n<p>Hovedproblemet er at ikke alle applikasjoner kan fungere i sandkassen. Noen trenger direkte tilgang til plattformen. Jeg nevner ikke engang kjerne-moduler som er sterkt avhengige av kjernen og ikke passer inn i sandkasse-konseptet. <\/p>\n<p>Det andre problemet er at de popul\u00e6re distribusjonene fra Red Hat og SUSE i enterprise-milj\u00f8et fortsatt ikke st\u00f8tter Snappy og Flatpak. <\/p>\n<p>Som f\u00f8lge av dette er Veeam Agent for Linux verken tilgjengelig p\u00e5 <noindex><a rel=\"nofollow\" href=\"https:\/\/snapcraft.io\/\">snapcraft.io<\/a><\/noindex> eller p\u00e5 <noindex><a rel=\"nofollow\" href=\"https:\/\/flathub.org\/home\">flathub.org<\/a><\/noindex>.<\/p>\n<p>For \u00e5 avslutte sp\u00f8rsm\u00e5let om pakkeadministratorer vil jeg bemerke at det er et alternativ \u00e5 helt slutte \u00e5 bruke pakkeadministratorer, og i stedet samle bin\u00e6rfiler og skripter for installasjon i \u00e9n pakke. <\/p>\n<p>En slik pakke gj\u00f8r det mulig \u00e5 lage \u00e9n felles pakke for forskjellige distribusjoner og plattformer, og gjennomf\u00f8re en interaktiv installasjonsprosess med n\u00f8dvendig tilpasning. Jeg har bare sett slike pakker for Linux fra VMware.<\/p>\n<h2>Problemet med oppdateringer<\/h2>\n<p>\n<img decoding=\"async\" alt=\"Linux mangfoldig: korleis arbeida p\u00e5 kva som helst distribusjon\" src=\"\/wp-content\/uploads\/2019\/10\/aa14b10a434c28541574421d97807de7.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nSelv om alle avhengighetsproblemer er l\u00f8st, kan programmet oppf\u00f8re seg ulikt p\u00e5 samme distribusjon. Det skyldes oppdateringene.<\/p>\n<p>Det finnes 3 strategier for oppdateringer:<\/p>\n<ul>\n<li>Den enkleste er \u00e5 aldri oppdatere. Du konfigurerer serveren og glemmer den. Hvorfor oppdatere n\u00e5r alt fungerer? Problemer begynner s\u00e5 snart du tar kontakt med supporttjenesten. Distribusjonens utvikler st\u00f8tter kun den oppdaterte versjonen. <\/li>\n<li>Du kan stole p\u00e5 distribut\u00f8ren og sette opp automatiske oppdateringer. I s\u00e5 fall er det sannsynlig at du m\u00e5 ringe supporten umiddelbart etter en mislykket oppdatering.<\/li>\n<li>Alternativet med manuell oppdatering kun etter testing i testinfrastrukturen er det sikreste, men det er dyrt og arbeidstungt. Langt fra alle har r\u00e5d til det.<\/li>\n<\/ul>\n<p>\nSiden forskjellige brukere anvender forskjellige oppdateringsstrategier, m\u00e5 b\u00e5de den nyeste utgivelsen og alle tidligere utgivelser st\u00f8ttes. Dette kompliserer b\u00e5de utviklingsprosessen og testingen, og gir supporttjenesten mer hodebry.<\/p>\n<h2>Mangfold av maskinvareplattformer<\/h2>\n<p>\nUlike maskinvareplattformer er et problem som i stor grad er spesifikt for native-kode. Minst m\u00e5 man bygge bin\u00e6rfiler for hver st\u00f8ttet plattform.<\/p>\n<p>I prosjektet Veeam Agent for Linux klarer vi enn\u00e5 ikke \u00e5 st\u00f8tte noe som helst RISC-relatert.<\/p>\n<p>Jeg vil ikke g\u00e5 i dybden p\u00e5 dette temaet. Jeg vil bare nevne de viktigste problemene: plattformavhengige typer, som <code>size_t<\/code>, strukturjustering og byte-rekkef\u00f8lge.<\/p>\n<h2>Statisk og\/eller dynamisk lenking<\/h2>\n<p>\n<img decoding=\"async\" alt=\"Linux mangfoldig: korleis arbeida p\u00e5 kva som helst distribusjon\" src=\"\/wp-content\/uploads\/2019\/10\/dc473aad4ea0818940af7eafdbc641fd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nSp\u00f8rsm\u00e5let \u00abHvordan skal man lenke med biblioteker - dynamisk eller statisk?\u00bb er verdt \u00e5 diskutere.<\/p>\n<p>Som regel bruker C\/C++-applikasjoner p\u00e5 Linux dynamisk linking. Dette fungerer utmerket hvis applikasjonen er bygget spesifikt for en bestemt distribusjon.<\/p>\n<p>Hvis m\u00e5let er \u00e5 dekke ulike distribusjoner med \u00e9n bin\u00e6rfil, m\u00e5 man rette seg etter den eldste st\u00f8ttede distribusjonen. For oss er dette Red Hat 6. Den inneholder gcc 4.4, som ikke engang st\u00f8tter standard C++11 fullt ut. <noindex><a rel=\"nofollow\" href=\"https:\/\/gcc.gnu.org\/projects\/cxx-status.html\">fullstendig<\/a><\/noindex>.<\/p>\n<p>Vi bygger prosjektet v\u00e5rt med gcc 6.3, som st\u00f8tter C++14 fullt ut. I s\u00e5 fall m\u00e5 vi dra med oss libstdc++ og boost-biblioteket p\u00e5 Red Hat 6. Det enkleste er \u00e5 linke til dem statisk.<\/p>\n<p>Men dessverre kan ikke alle biblioteker linkes statisk.<\/p>\n<p>For det f\u00f8rste m\u00e5 systembiblioteker, som <i>libfuse<\/i>, <i>libblkid<\/i> linkes dynamisk for \u00e5 sikre kompatibilitet med kjernen og dens moduler. <\/p>\n<p>For det andre er det en nyanse med lisenser. <\/p>\n<p>GPL-lisensen tillater i prinsippet \u00e5 linke biblioteker kun med opensource-kode. MIT og BSD tillater statisk linking og lar inkludere biblioteker i prosjektet. Derimot synes LGPL ikke \u00e5 motsette seg statisk linking, men krever \u00e5 gi tilgang til filene som er n\u00f8dvendige for linking. <\/p>\n<p>Generelt vil bruk av dynamisk linking beskytte mot behovet for \u00e5 gi noe ut.<\/p>\n<h2>Bygging av C\/C++-applikasjoner<\/h2>\n<p>\nFor \u00e5 bygge C\/C++-applikasjoner for ulike plattformer og distribusjoner, er det tilstrekkelig \u00e5 finne eller bygge en passende versjon av gcc og bruke krysskompilatorer for spesifikke arkitekturer, samt \u00e5 samle hele settet av biblioteker. Dette arbeidet er fullt mulig, men ganske tidkrevende. Og det er ingen garantier for at den valgte kompilatoren og bibliotekene vil gi en fungerende variant. <\/p>\n<p>En \u00e5penbar fordel: infrastrukturen blir sterkt forenklet, da hele byggeprosessen kan utf\u00f8res p\u00e5 \u00e9n maskin. I tillegg er det tilstrekkelig \u00e5 samle ett sett av bin\u00e6rfiler for \u00e9n arkitektur, og s\u00e5 kan de pakkes i pakker for forskjellige distribusjoner. Slik blir veeam-pakkene for Veeam Agent for Linux bygget.<\/p>\n<p>I motsetning til dette alternativet kan man enkelt forberede en bygningsg\u00e5rd, det vil si flere maskiner for bygging. Hver av disse maskinene vil s\u00f8rge for kompilering av applikasjonen og bygging av pakken for en spesifikk distribusjon og bestemt arkitektur. I s\u00e5 fall utf\u00f8res kompileringen med de midlene som distribusjonen har forberedt. Med andre ord,forberedelsestrinnet for kompilatoren og valg av biblioteker faller bort. I tillegg kan byggeprosessen enkelt paralleliseres. <\/p>\n<p>Det er imidlertid en ulempe med en slik tiln\u00e6rming: for hver distribusjon innenfor en arkitektur m\u00e5 man samle sitt eget sett av bin\u00e6rfiler. En annen ulempe er at et s\u00e5 stort antall maskiner m\u00e5 vedlikeholdes, noe som krever mye diskplass og RAM. <\/p>\n<p>Slik blir KMOD-pakkene for veeamsnap-kjernemodulen samlet for Red Hat-distribusjoner.<\/p>\n<h2>Open Build Service<\/h2>\n<p>\nKollegene fra SUSE fors\u00f8kte \u00e5 oppn\u00e5 en slags gullstandard i form av en spesialtjeneste for kompilering av applikasjoner og bygging av pakker \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/openbuildservice.org\/\">openbuildservice<\/a><\/noindex>.<\/p>\n<p>I prinsippet er dette en hypervisor som oppretter en virtuell maskin, installerer alle n\u00f8dvendige pakker, utf\u00f8rer kompilering av applikasjonen og bygging av pakken i dette isolerte milj\u00f8et, hvoretter denne virtuelle maskinen frigj\u00f8res.<\/p>\n<p><img decoding=\"async\" alt=\"Linux mangfoldig: korleis arbeida p\u00e5 kva som helst distribusjon\" src=\"\/wp-content\/uploads\/2019\/10\/93d2a70c589a7186ecef85a7863e59e8.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPlanleggeren innebygd i OpenBuildService vil selv avgj\u00f8re hvor mange virtuelle maskiner den kan starte for optimal hastighet ved pakkebygging. Den innebygde signeringsmekanismen vil automatisk signere pakkene og legge dem ut p\u00e5 den innebygde lagringsplassen. Det innebygde versjonskontrollsystemet vil lagre historikken for endringer og bygg. Det gjenst\u00e5r bare \u00e5 legge inn sine kildefiler i dette systemet. Det er ikke engang n\u00f8dvendig \u00e5 sette opp en server selv, man kan bruke den \u00e5pne.<\/p>\n<p>Men her er det et problem: en slik kombinasjon passer ikke godt inn i den eksisterende infrastrukturen. For eksempel er versjonskontrollen ikke n\u00f8dvendig, da vi allerede har v\u00e5r for kildefilene. Signeringsmekanismen v\u00e5r er annerledes: en spesiell server benyttes. Lagringsplassen er heller ikke n\u00f8dvendig. <\/p>\n<p>I tillegg er st\u00f8tten for andre distribusjoner \u2014 for eksempel Red Hat \u2014 ganske mager, noe som er forst\u00e5elig.<\/p>\n<p>Fordelen med en slik tjeneste er rask st\u00f8tte for den nyeste versjonen av SUSE-distribusjonen. F\u00f8r den offisielle kunngj\u00f8ringen om utgivelsen legges n\u00f8dvendige pakker ut i et offentlig repository. Den nye distribusjonen vises p\u00e5 listen over tilgjengelige distribusjoner i OpenBuildService. Vi setter en hake, og den legges til i byggeplanen. Dermed kan tillegget av en ny distribusjonsversjon gj\u00f8res praktisk talt med ett klikk.<\/p>\n<p>I v\u00e5r infrastruktur, som bruker OpenBuildService, bygges et mangfold av KMP-pakker for veeamsnap-modulen til SUSE-distribusjoner.<\/p>\n<p>Deretter vil jeg gjerne stoppe opp ved sp\u00f8rsm\u00e5l som er spesifikke for kjernemoduler.<\/p>\n<h2>kernel ABI<\/h2>\n<p>\nLinux-kjernemoduler har historisk blitt distribuert som kildekode. \u00c5rsaken er at kjernens utviklere ikke tar seg bryet med \u00e5 opprettholde et stabilt API for kjernemoduler, langt mindre p\u00e5 bin\u00e6rt niv\u00e5, videre kABI.<\/p>\n<p>For \u00e5 bygge en modul for det vanlige kjernen, er det n\u00f8dvendig med header-filer for nettopp denne kjernen, og den vil kun fungere med denne kjernen. <\/p>\n<p>DKMS lar deg automatisere prosessen med \u00e5 bygge moduler ved oppdatering av kjernen. Som et resultat bruker brukere av Debian-repositoryet (og dets mange slektninger) kjernemoduler enten fra distribut\u00f8rens repository eller bygget fra kildekode ved hjelp av DKMS.<\/p>\n<p>Men slik situasjonen er, tilfredsstiller det ikke Enterprise-segmentet s\u00e6rlig godt. Distribusjoner av propriet\u00e6r kode \u00f8nsker \u00e5 distribuere produktet i form av ferdigbygde bin\u00e6rfiler. <\/p>\n<p>Administratorer \u00f8nsker ikke \u00e5 ha utviklingsverkt\u00f8y p\u00e5 produksjonsservere av sikkerhetsmessige \u00e5rsaker. Distribusjoner av Enterprise Linux \u2013 som Red Hat og SUSE \u2013 har besluttet at de kan st\u00f8tte sine brukere med stabil kABI. Som et resultat har KMOD-pakker for Red Hat og KMP-pakker for SUSE dukket opp.<\/p>\n<p>Kjernen i en slik l\u00f8sning er ganske enkel. For en spesifikk versjon av distribusjonen fryses API-et i kjernen. Distribut\u00f8ren erkl\u00e6rer at de bruker en spesifikk kjerne, for eksempel 3.10, og gj\u00f8r bare feilrettinger og forbedringer som ikke ber\u00f8rer kernelgrensesnittene, og moduler bygget for den aller f\u00f8rste kjernen kan brukes for alle p\u00e5f\u00f8lgende uten rekompilering.<\/p>\n<p>Red Hat uttaler at kABI-kompatibilitet for distribusjonen gjelder gjennom hele livssyklusen. Det betyr at en bygget modul for rhel 6.0 (utgivelse november 2010) ogs\u00e5 skal fungere p\u00e5 versjon 6.10 (utgivelse juni 2018). Og dette er nesten 8 \u00e5r. Naturligvis er dette en ganske vanskelig oppgave. <br \/>\nVi har registrert flere tilfeller der modulen veeamsnap sluttet \u00e5 fungere p\u00e5 grunn av problemer med kABI-kompatibiliteten. <\/p>\n<p>Etter at modulen veeamsnap, bygget for RHEL 7.0, viste seg \u00e5 v\u00e6re inkompatibel med kjernen fra RHEL 7.5, men likevel ble lastet inn og garantert krasjet serveren, forkastet vi bruken av kABI-kompatibilitet for RHEL 7 helt. <\/p>\n<p>For \u00f8yeblikket inneholder KMOD-pakken for RHEL 7 en bygging for hver versjon av utgivelsen og et skript som s\u00f8rger for lasting av modulen.<\/p>\n<p>SUSE har tatt en mer forsiktig tiln\u00e6rming til kABI-kompatibilitet. De sikrer kABI-kompatibilitet bare innenfor ett servicepakke. <\/p>\n<p>For eksempel ble utgivelsen SLES 12 lansert i september 2014. Og SLES 12 SP1 kom allerede i desember 2015, alts\u00e5 gikk det litt over ett \u00e5r. Til tross for at begge utgivelser bruker kjerne 3.12, er de kABI-incompatible. Det er \u00e5penbart at det er betydelig enklere \u00e5 opprettholde kABI-kompatibilitet i l\u00f8pet av bare ett \u00e5r. Et \u00e5rlig oppdateringssyklus for modulkjernen b\u00f8r ikke for\u00e5rsake problemer for modulskaperne. <\/p>\n<p>Som et resultat av denne politikken fra SUSE har vi ikke registrert noen problemer med kABI-kompatibilitet med v\u00e5r modul veeamsnap. Faktisk er antallet pakker for SUSE nesten p\u00e5 niv\u00e5 med en orden st\u00f8rre.<\/p>\n<h2>Patch og bakporter<\/h2>\n<p>\nSelv om distribut\u00f8rene pr\u00f8ver \u00e5 sikre kABI-kompatibilitet og stabilitet i kjernen, pr\u00f8ver de ogs\u00e5 \u00e5 forbedre ytelsen og rette opp feil i denne stabile kjernen. <\/p>\n<p>I tillegg til sitt eget \"arbeid med feil\" f\u00f8lger utviklerne av enterprise linux-kjernen med p\u00e5 endringene i vaniljekjernen og overf\u00f8rer dem til sin \"stabile\".<\/p>\n<p>Noen ganger f\u00f8rer dette til nye <noindex><a rel=\"nofollow\" href=\"https:\/\/access.redhat.com\/solutions\/3658111\">feil<\/a><\/noindex>.<\/p>\n<p>I den siste utgivelsen av Red Hat 6 ble det gjort en feil i en av de mindre oppdateringene. Denne f\u00f8rte til at modulen veeamsnap garantert krasjet systemet ved frigj\u00f8ring av et snapshot. Etter \u00e5 ha sammenlignet kildekodene til kjernen f\u00f8r og etter oppdateringen, fant vi ut at det var bakporten som var ansvarlig. En tilsvarende fiks ble utf\u00f8rt i vaniljekjernen versjon 4.19. Men i vaniljekjernen fungerte denne fiksen normalt, mens overf\u00f8ringen til det \"stabile\" 2.6.32 medf\u00f8rte et problem med spin-l\u00e5singen.<\/p>\n<p>Selvf\u00f8lgelig, fejl opst\u00e5r altid for alle, men var det v\u00e6rd at tr\u00e6kke kode fra 4.19 til 2.6.32, risikerende stabiliteten?.. Jeg er ikke sikker\u2026<\/p>\n<p>Det v\u00e6rste er, n\u00e5r marketing ogs\u00e5 blander sig i det at tr\u00e6kke i det str\u00e6k, der handler om \"stabilitet\"\"modernisering\". Marketingafdelingen har brug for, at kernen i den opdaterede distribution er stabil, p\u00e5 den ene side, men samtidig skal den ogs\u00e5 v\u00e6re bedre i ydeevne og have nye funktioner. Dette f\u00f8rer til m\u00e6rkelige kompromisser. <\/p>\n<p>Da jeg pr\u00f8vede at samle modulet p\u00e5 kernen 4.4 fra SLES 12 SP3, blev jeg overrasket over at opdage funktionalitet fra den rene 4.8. Efter min mening ligner implementeringen af blokind- og udgang fra kernen 4.4 fra SLES 12 SP3 mere kernen 4.8 end den tidligere udgave af den stabile 4.4 kerne fra SLES 12 SP2. Jeg vil ikke vurdere, hvad procentdelen af den overf\u00f8rte kode fra kernen 4.8 til SLES' 4.4 for SP3 er, men jeg kan ikke kalde kernen den samme stabile 4.4. <\/p>\n<p>Det mest frustrerende ved at skrive et modul, der fungerer godt p\u00e5 forskellige kerner, er, at man ikke l\u00e6ngere kan stole p\u00e5 kerneversionen. Man skal ogs\u00e5 tage hensyn til distributionen. Heldigvis kan man nogle gange binde sig til en define, som dukker op med den nye funktionalitet, men denne mulighed opst\u00e5r ikke altid. <\/p>\n<p>Resultatet er, at koden bliver fyldt med bizarre preproces directives.<\/p>\n<p>Der er ogs\u00e5 patches, der \u00e6ndrer det dokumenterede API for kernen. <br \/>\nJeg st\u00f8dte p\u00e5 distributionen <noindex><a rel=\"nofollow\" href=\"https:\/\/neon.kde.org\/\">KDE neon<\/a><\/noindex> 5.16 og blev meget overrasket over at se, at kaldet til lookup_bdev i denne kerneversion havde \u00e6ndret listen af indparametre.<\/p>\n<p>For at kunne samle det m\u00e5tte jeg tilf\u00f8je et script til makefile, der kontrollerede, om der var en mask parameter til funktionen lookup_bdev.<\/p>\n<h2>Undertegnelse af kernemoduler<\/h2>\n<p>\nMen lad os vende tilbage til sp\u00f8rgsm\u00e5let om distributionspakker.<\/p>\n<p>En af fordelene ved stabil kABI er, at kernemoduler i form af bin\u00e6re filer kan signeres. P\u00e5 denne m\u00e5de kan udvikleren v\u00e6re sikker p\u00e5, at modulet ikke er blevet beskadiget ved en fejl eller \u00e6ndret bevidst. Dette kan tjekkes med kommandoen modinfo. <\/p>\n<p>Distributioner som Red Hat og SUSE tillader at kontrollere signaturen p\u00e5 modulet og indl\u00e6se det kun, hvis det relevante certifikat er registreret i systemet. Certifikatet er en offentlig n\u00f8gle, som modulet bliver signeret med. Vi distribuerer det som en separat pakke.<\/p>\n<p>Problemet her er, at certifikater enten kan v\u00e6re indbyggede i kernen (de anvendes af distributionsudbydere) eller skal skrives til den ikke-flygtige EFI-hukommelse ved hj\u00e6lp af et v\u00e6rkt\u00f8j. <i>mokutil<\/i>. The utility <i>mokutil<\/i> ved installation af certifikatet kr\u00e6ver det genstart af systemet og tilbydes administratoren at tillade indl\u00e6sning af det nye certifikat f\u00f8r indl\u00e6sning af operativsystemkernen. <\/p>\n<p>S\u00e5ledes kr\u00e6ver tilf\u00f8jelse af certifikatet fysisk adgang til systemet fra administratoren. Hvis maskinen er placeret et sted i skyen eller blot i en fjern server, hvor adgang kun er muligt via netv\u00e6rket (f.eks. via ssh), kan certifikatet ikke tilf\u00f8jes. <\/p>\n<h2>EFI p\u00e5 virtuelle maskiner<\/h2>\n<p>\nSelvom EFI l\u00e6nge har v\u00e6ret underst\u00f8ttet af n\u00e6sten alle producenter af bundkort, kan administratoren ved installation af systemet m\u00e5ske ikke overveje behovet for EFI, og det kan v\u00e6re deaktiveret. <\/p>\n<p>Ikke alle hypervisorer underst\u00f8tter EFI. VMWare vSphere underst\u00f8tter EFI fra version 5. <br \/>\nMicrosoft Hyper-V har ogs\u00e5 f\u00e5et st\u00f8tte for EFI, begyndende med Hyper-V for Windows Server 2012R2. <\/p>\n<p>Men i standardkonfigurationen er denne funktionalitet deaktiveret for Linux-maskiner, hvilket betyder, at certifikatet ikke kan installeres. <\/p>\n<p>I vSphere 6.5 kan du indstille muligheden <b>Secure Boot<\/b> kun i den gamle version af webgr\u00e6nsefladen, som fungerer gennem Flash. Web UI i HTML-5 er stadig meget bagud.<\/p>\n<h2>Eksperimentelle distributioner<\/h2>\n<p>\nOg til sidst vil vi se p\u00e5 sp\u00f8rgsm\u00e5let om eksperimentelle distributioner og distributioner uden officiel st\u00f8tte. P\u00e5 den ene side vil du n\u00e6ppe finde s\u00e5danne distributioner p\u00e5 serverne i seri\u00f8se organisationer. Der er ikke officiel st\u00f8tte til s\u00e5danne distributioner. Derfor kan teknisk support af produktet ikke ydes p\u00e5 en s\u00e5dan distribution. <\/p>\n<p>Men s\u00e5danne distributioner bliver et praktisk forum til at afpr\u00f8ve nye eksperimentelle l\u00f8sninger. For eksempel, Fedora, OpenSUSE Tumbleweed eller Unstable-versioner af Debian. De er ret stabile. De har altid nye versioner af programmerne og altid en ny kerne. Om et \u00e5r kan denne eksperimentelle funktionalitet findes i den opdaterede RHEL, SLES eller Ubuntu. <\/p>\n<p>S\u00e5 hvis noget ikke virker p\u00e5 en eksperimentel distribution, er det en grund til at unders\u00f8ge problemet og l\u00f8se det. Man skal v\u00e6re klar til, at denne funktionalitet snart vil dukke op p\u00e5 production-serverne hos brugerne.<\/p>\n<p>Den eksisterende listen over offisielt st\u00f8ttede distribusjoner for versjon 3.0 kan du studere <noindex><a rel=\"nofollow\" href=\"https:\/\/helpcenter.veeam.com\/docs\/agentforlinux\/userguide\/system_requirements.html?ver=30\">her<\/a><\/noindex>. Men den virkelige listen over distribusjoner som produktet v\u00e5rt kan fungere p\u00e5, er mye bredere.<\/p>\n<p>Personlig var jeg interessert i et eksperiment med operativsystemet \u00abElbrus\u00bb. Etter tilpasning av veeam-pakken ble produktet v\u00e5rt installert og fungerte. Jeg skrev om dette eksperimentet p\u00e5 Habr i <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/veeam\/blog\/447960\/\">artikkelen<\/a><\/noindex>. <\/p>\n<p>St\u00f8tten for nye distribusjoner fortsetter. Vi venter p\u00e5 at versjon 4.0 skal komme. Betaen b\u00f8r snart v\u00e6re tilgjengelig, s\u00e5 f\u00f8lg med p\u00e5 <noindex><a rel=\"nofollow\" href=\"https:\/\/www.veeam.com\/whats-new-linux-agent.html\">whats-new<\/a><\/noindex>!<br \/>\n<br \/>Kilde: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/veeam\/blog\/471226\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0421\u043e\u0437\u0434\u0430\u0442\u044c \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435 \u0434\u043b\u044f \u0440\u0435\u0437\u0435\u0440\u0432\u043d\u043e\u0433\u043e \u043a\u043e\u043f\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f, \u0440\u0430\u0431\u043e\u0442\u0430\u044e\u0449\u0435\u0435 \u043d\u0430 \u043b\u044e\u0431\u043e\u043c \u0434\u0438\u0441\u0442\u0440\u0438\u0431\u0443\u0442\u0438\u0432\u0435 \u2014 \u0437\u0430\u0434\u0430\u0447\u043a\u0430 \u043d\u0435\u043f\u0440\u043e\u0441\u0442\u0430\u044f. \u0427\u0442\u043e\u0431\u044b \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0438\u0442\u044c \u0440\u0430\u0431\u043e\u0442\u0443 Veeam Agent for Linux \u043d\u0430 \u0434\u0438\u0441\u0442\u0440\u0438\u0431\u0443\u0442\u0438\u0432\u0430\u0445 \u043e\u0442 Red Hat 6 \u0438 Debian 6, \u0434\u043e OpenSUSE 15.1 \u0438 Ubuntu 19.04 \u043f\u0440\u0438\u0445\u043e\u0434\u0438\u0442\u0441\u044f \u0440\u0435\u0448\u0430\u0442\u044c \u0441\u043f\u0435\u043a\u0442\u0440 \u043f\u0440\u043e\u0431\u043b\u0435\u043c, \u043e\u0441\u043e\u0431\u0435\u043d\u043d\u043e \u0435\u0441\u043b\u0438 \u0443\u0447\u0435\u0441\u0442\u044c, \u0447\u0442\u043e \u0432 \u0441\u043e\u0441\u0442\u0430\u0432 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u043e\u0433\u043e \u043f\u0440\u043e\u0434\u0443\u043a\u0442\u0430 \u0432\u0445\u043e\u0434\u0438\u0442 \u043c\u043e\u0434\u0443\u043b\u044c \u044f\u0434\u0440\u0430. \u0421\u0442\u0430\u0442\u044c\u044f \u0441\u043e\u0437\u0434\u0430\u043d\u0430 \u043f\u043e \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u0430\u043c \u0432\u044b\u0441\u0442\u0443\u043f\u043b\u0435\u043d\u0438\u044f \u043d\u0430 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":29206,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-38929","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.5 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0421\u043e\u0437\u0434\u0430\u0442\u044c \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435 \u0434\u043b\u044f \u0440\u0435\u0437\u0435\u0440\u0432\u043d\u043e\u0433\u043e.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/linux-mnogolikij-kak-rabotat-na-lyubom-distributive\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.5\" \/>\n\t\t<meta property=\"og:locale\" content=\"nn_NO\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47Linux \u043c\u043d\u043e\u0433\u043e\u043b\u0438\u043a\u0438\u0439: \u043a\u0430\u043a \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c \u043d\u0430 \u043b\u044e\u0431\u043e\u043c \u0434\u0438\u0441\u0442\u0440\u0438\u0431\u0443\u0442\u0438\u0432\u0435 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0421\u043e\u0437\u0434\u0430\u0442\u044c \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435 \u0434\u043b\u044f \u0440\u0435\u0437\u0435\u0440\u0432\u043d\u043e\u0433\u043e.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/linux-mnogolikij-kak-rabotat-na-lyubom-distributive\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:26:48+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:26:48+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Linux har mange ansikter: hvordan jobbe p\u00e5 hvilken som helst distribusjon | ProHoster","description":"Opprett en backup-app.","canonical_url":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/linux-mnogolikij-kak-rabotat-na-lyubom-distributive","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nn_NO","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Linux \u043c\u043d\u043e\u0433\u043e\u043b\u0438\u043a\u0438\u0439: \u043a\u0430\u043a \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c \u043d\u0430 \u043b\u044e\u0431\u043e\u043c \u0434\u0438\u0441\u0442\u0440\u0438\u0431\u0443\u0442\u0438\u0432\u0435 | ProHoster","og:description":"\u0421\u043e\u0437\u0434\u0430\u0442\u044c \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435 \u0434\u043b\u044f \u0440\u0435\u0437\u0435\u0440\u0432\u043d\u043e\u0433\u043e.","og:url":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/linux-mnogolikij-kak-rabotat-na-lyubom-distributive","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:26:48+00:00","article:modified_time":"2019-10-31T19:26:48+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"38929","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-23 23:59:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:00:26","updated":"2026-01-23 23:59:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts\/38929","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/comments?post=38929"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts\/38929\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media\/29206"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media?parent=38929"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/categories?post=38929"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/tags?post=38929"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}