{"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\/da\/blog\/administrirovanie\/linux-mnogolikij-kak-rabotat-na-lyubom-distributive","title":{"rendered":"Linux er mangefacet: hvordan man arbejder p\u00e5 enhver distribution","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Linux er mangefacet: hvordan man arbejder p\u00e5 enhver distribution\" src=\"\/wp-content\/uploads\/2019\/10\/ee1aaad566204532c974a3ce8f13b915.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAt skabe en sikkerhedskopieringsapplikation, der fungerer p\u00e5 enhver distribution, er en udfordring. For at sikre Veeam Agent for Linux fungerer p\u00e5 distributioner fra Red Hat 6 til Debian 6, helt op til OpenSUSE 15.1 og Ubuntu 19.04, skal man tackle en r\u00e6kke problemer, is\u00e6r n\u00e5r man tager h\u00f8jde for, at produktet indeholder en kernemodul.<\/p>\n<p>Artiklen er baseret p\u00e5 materiale fra et opl\u00e6g p\u00e5 konferencen <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 ikke bare en af de mest popul\u00e6re OS'er. Det er i realiteten en platform, hvor man kan skabe noget unikt, noget eget. Dette har resulteret i mange distributioner af Linux, som adskiller sig ved m\u00e6ngden af softwarekomponenter. Her opst\u00e5r problemet: for at et softwareprodukt kan fungere p\u00e5 enhver distribution, skal man tage hensyn til de specifikke forhold for hver enkelt.<\/p>\n<h2>Pakkeh\u00e5ndterere. .deb vs .rpm<\/h2>\n<p>\nLad os starte med det \u00e5benlyse problem ved distribution af produkter til forskellige distributioner.<br \/>\nDen mest typiske metode til distribution af softwareprodukter er at l\u00e6gge en pakke p\u00e5 et repository, s\u00e5 den indbyggede pakkeh\u00e5ndterer i systemet kan installere den derfra.<br \/>\nMen vi har to popul\u00e6re pakkeformater: <i>rpm<\/i> og <i>deb<\/i>. Det betyder, at vi skal st\u00f8tte hver enkelt.<\/p>\n<p>I deb-pakkernes verden er kompatibilitetsniveauet imponerende. Den samme pakke installeres og fungerer lige godt p\u00e5 b\u00e5de Debian 6 og Ubuntu 19.04. Standarderne for pakkeopbygning og arbejdsgange, der blev lagt i de gamle Debian-distributioner, forbliver relevante i de moderne Linux Mint og elementary OS. Derfor er \u00e9n deb-pakke til hver hardwareplatform tilstr\u00e6kkeligt for Veeam Agent for Linux.<\/p>\n<p>Men i rpm-pakkernes verden er forskellene store. For det f\u00f8rste, fordi der er to helt uafh\u00e6ngige distribut\u00f8rer, Red Hat og SUSE, som ikke beh\u00f8ver at v\u00e6re kompatible. For det andet har disse distribut\u00f8rer distributioner med teknisk support og eksperimentelle. Der er heller ikke behov for kompatibilitet mellem dem. Det resulterer i, at der er specifikke pakker for el6, el7 og el8. Separat pakke til Fedora. Pakker til SLES11 og 12 og en s\u00e6rskilt for openSUSE. Det prim\u00e6re problem er med afh\u00e6ngigheder og pakke-navne. <\/p>\n<h2>Afh\u00e6ngighedsproblemer<\/h2>\n<p>\nDesv\u00e6rre har de samme pakker ofte forskellige navne i forskellige distributioner. Nedenfor er en ufuldst\u00e6ndig liste over afh\u00e6ngigheder 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 resultat er afh\u00e6ngighedslisten unik for distributionen. <\/p>\n<p>Det bliver v\u00e6rre, n\u00e5r en opdateret version begynder at gemme sig under det gamle pakkebetegnelse. <\/p>\n<p><b>Eksempel:<\/b><\/p>\n<p>I Fedora 24 er pakken blevet opdateret <i>ncurses<\/i> fra version 5 til version 6. Vores produkt blev bygget med version 5 for at sikre kompatibilitet med \u00e6ldre distributioner. For at bruge den gamle version 5 af biblioteket i Fedora 24 m\u00e5tte man bruge pakken <i>ncurses-compat-libs<\/i>. <\/p>\n<p>Som resultat f\u00e5r Fedora to pakker med forskellige afh\u00e6ngigheder. <\/p>\n<p>Her bliver det interessant. Efter endnu en opdatering af distributionen bliver pakken <i>ncurses-compat-libs<\/i> med version 5 af biblioteket utilg\u00e6ngelig. For distribut\u00f8ren er det besv\u00e6rligt at tr\u00e6kke gamle biblioteker ind i den nye version af distributionen. Efter noget tid opstod problemet ogs\u00e5 i SUSE-distributionerne.<\/p>\n<p>Som resultat m\u00e5tte nogle distributioner opgive den klare afh\u00e6ngighed fra <i>ncurses-libs<\/i>, og produktet blev justeret, s\u00e5 det kunne arbejde med enhver version af biblioteket.<\/p>\n<p>For resten, i version 8 af Red Hat er der ikke l\u00e6ngere en metapakke <i>python<\/i>, der henviste til den gode gamle <i>python 2.7<\/i>. Der er <i>python2<\/i> og <i>python<\/i>3. <\/p>\n<h2>Alternativ til pakkestyring<\/h2>\n<p>\nProblemet med afh\u00e6ngigheder er gammelt og har l\u00e6nge v\u00e6ret tydeligt. T\u00e6nk bare p\u00e5 Dependency hell. <br \/>\nAt kombinere forskellige biblioteker og applikationer s\u00e5 de stabilt fungerer og ikke konflkterer\u2014det er faktisk dette problem, enhver Linux-distribut\u00f8r fors\u00f8ger at l\u00f8se.<\/p>\n<p>Pakkestyringssystemet <b>Snappy<\/b> fra Canonical. Hovedid\u00e9en: applikationen k\u00f8rer i et isoleret milj\u00f8, beskyttet mod hovedsystemet. Hvis applikationer har brug for biblioteker, leveres de sammen med selve applikationen.<\/p>\n<p><b>Flatpak<\/b> giver ogs\u00e5 mulighed for at k\u00f8re applikationer i et isoleret milj\u00f8 ved hj\u00e6lp af Linux Containere. Sandkasseid\u00e9en anvendes ogs\u00e5 af <b>AppImage<\/b>.<\/p>\n<p>Disse l\u00f8sninger muligg\u00f8r oprettelse af \u00e9n pakke til alle distributioner. I tilf\u00e6lde af at <b>Flatpak<\/b> installation og k\u00f8rsel af applikationen er mulig selv uden administratorens viden.<\/p>\n<p>Hovedproblemet er, at ikke alle applikationer kan k\u00f8re i et isoleret milj\u00f8. Nogle har brug for direkte adgang til platformen. Jeg n\u00e6vner ikke engang kerne-moduler, som er st\u00e6rkt afh\u00e6ngige af kernen og slet ikke passer ind i sandkassekonceptet. <\/p>\n<p>Et andet problem er, at popul\u00e6re enterprise-distributioner fra Red Hat og SUSE endnu ikke underst\u00f8tter Snappy og Flatpak. <\/p>\n<p>Som f\u00f8lge heraf er Veeam Agent for Linux ikke tilg\u00e6ngelig hverken p\u00e5 <noindex><a rel=\"nofollow\" href=\"https:\/\/snapcraft.io\/\">snapcraft.io<\/a><\/noindex> hverken p\u00e5 <noindex><a rel=\"nofollow\" href=\"https:\/\/flathub.org\/home\">flathub.org<\/a><\/noindex>.<\/p>\n<p>Afslutningsvis om sp\u00f8rgsm\u00e5let vedr\u00f8rende pakkeh\u00e5ndtere, bem\u00e6rker jeg, at der er en mulighed for helt at undg\u00e5 pakkeh\u00e5ndtere ved at samle bin\u00e6re filer og installationsscripts i \u00e9n pakke. <\/p>\n<p>S\u00e5dan en bundle g\u00f8r det muligt at skabe \u00e9n samlet pakke til forskellige distributioner og platforme, samt at gennemf\u00f8re en interaktiv installationsproces med den n\u00f8dvendige tilpasning. Jeg har kun st\u00f8dt p\u00e5 s\u00e5danne pakker til Linux fra VMware.<\/p>\n<h2>Problemet med opdateringer<\/h2>\n<p>\n<img decoding=\"async\" alt=\"Linux er mangefacet: hvordan man arbejder p\u00e5 enhver distribution\" src=\"\/wp-content\/uploads\/2019\/10\/aa14b10a434c28541574421d97807de7.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nSelv hvis alle afh\u00e6ngighedsproblemer er l\u00f8st, kan programmet opf\u00f8re sig forskelligt p\u00e5 samme distribution. Det handler om opdateringer.<\/p>\n<p>Der er 3 opdateringsstrategier:<\/p>\n<ul>\n<li>Den enkleste er aldrig at opdatere. Du s\u00e6tter serveren op og glemmer den. Hvorfor opdatere, n\u00e5r alt fungerer? Problemerne begynder ved den f\u00f8rste henvendelse til support. <\/li>\n<li>Man kan stole p\u00e5 distribut\u00f8ren og s\u00e6tte automatisk opdatering op. I s\u00e5 fald er et opkald til supporten sandsynligt straks efter en mislykket opdatering.<\/li>\n<li>Muligheden for manuel opdatering kun efter afpr\u00f8vning p\u00e5 testinfrastruktur er den sikreste, men ogs\u00e5 den dyreste og mest arbejdsintensive. Langt fra alle kan tillade sig dette.<\/li>\n<\/ul>\n<p>\nDa forskellige brugere bruger forskellige opdateringsstrategier, skal man b\u00e5de underst\u00f8tte den nyeste version samt alle tidligere udgivelser. Dette komplicerer b\u00e5de udviklings- og testprocessen og giver hovedpine til supportteamet.<\/p>\n<h2>Mangfoldighed af hardwareplatforme<\/h2>\n<p>\nForskellige hardwareplatforme er et problem, der i h\u00f8j grad er specifikt for native kode. I det mindste skal man samle bin\u00e6rer for hver underst\u00f8ttet platform.<\/p>\n<p>I projektet Veeam Agent for Linux kan vi slet ikke f\u00e5 det til at fungere p\u00e5 nogen RISC-baserede platforme.<\/p>\n<p>Jeg vil ikke g\u00e5 i detaljer med dette sp\u00f8rgsm\u00e5l. Jeg vil kun n\u00e6vne de vigtigste problemer: platformafh\u00e6ngige typer som <code>size_t<\/code>, strukturudj\u00e6vning og byte order.<\/p>\n<h2>Statisk og\/eller dynamisk linking<\/h2>\n<p>\n<img decoding=\"async\" alt=\"Linux er mangefacet: hvordan man arbejder p\u00e5 enhver distribution\" src=\"\/wp-content\/uploads\/2019\/10\/dc473aad4ea0818940af7eafdbc641fd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nMen sp\u00f8rgsm\u00e5let om \"Hvordan linker man med biblioteker - dynamisk eller statisk?\" er v\u00e6rd at diskutere.<\/p>\n<p>Som regel bruger C\/C++ programmer p\u00e5 Linux dynamisk linking. Det fungerer fint, hvis programmet er bygget specifikt til en bestemt distribution.<\/p>\n<p>Hvis m\u00e5let er at d\u00e6kke forskellige distributioner med \u00e9n bin\u00e6r fil, m\u00e5 man orientere sig efter den \u00e6ldste underst\u00f8ttede distribution. For os er det Red Hat 6. Den indeholder gcc 4.4, som endda ikke underst\u00f8tter standarden C++11. <noindex><a rel=\"nofollow\" href=\"https:\/\/gcc.gnu.org\/projects\/cxx-status.html\">helt<\/a><\/noindex>.<\/p>\n<p>Vi bygger vores projekt med gcc 6.3, som fuldt ud underst\u00f8tter C++14. Det vil sige, at vi i dette tilf\u00e6lde m\u00e5 tage biblioteket libstdc++ og boost med til Red Hat 6. Det er nemmest at linke til dem statisk.<\/p>\n<p>Men desv\u00e6rre er det ikke muligt at linke statisk med alle biblioteker.<\/p>\n<p>For det f\u00f8rste, systembiblioteker s\u00e5som <i>libfuse<\/i>, <i>libblkid<\/i> skal linkes dynamisk for at sikre kompatibiliteten med kernen og dens moduler. <\/p>\n<p>For det andet er der en nuance med licenserne. <\/p>\n<p>GPL-licensen tillader i princippet kun at linke biblioteker med open source-kode. MIT og BSD tillader statisk linking og g\u00f8r det muligt at inkludere biblioteker i projektet. Men LGPL virker ikke som om den modsiger statisk linking, men kr\u00e6ver at der stilles de n\u00f8dvendige filer til r\u00e5dighed for linking. <\/p>\n<p>Generelt vil brugen af dynamisk linking beskytte mod behovet for at stille noget til r\u00e5dighed.<\/p>\n<h2>Bygning af C\/C++ applikationer<\/h2>\n<p>\nFor at bygge C\/C++ applikationer til forskellige platforme og distributioner er det tilstr\u00e6kkeligt at finde eller samle en passende version af gcc og bruge cross-compilere til specifikke arkitekturer, samt samle hele bibliotekss\u00e6ttet. Dette arbejde er ganske gennemf\u00f8rligt, men ret besv\u00e6rligt. Og der er ingen garantier for, at den valgte compiler og de valgte biblioteker vil give en fungerende version. <\/p>\n<p>En \u00e5benlys fordel: infrastrukturen bliver meget enklere, da hele byggeprocessen kan udf\u00f8res p\u00e5 \u00e9n maskine. Derudover er det tilstr\u00e6kkeligt at samle \u00e9t s\u00e6t bin\u00e6re filer til \u00e9n arkitektur, og s\u00e5 kan de pakkes i pakker til forskellige distributioner. Det er netop s\u00e5dan, pakkerne til Veeam for Veeam Agent for Linux samles.<\/p>\n<p>Modsat denne mulighed kan man blot forberede en build farm, det vil sige flere maskiner til samling. Hver s\u00e5dan maskine vil s\u00f8rge for kompilering af applikationen og pakkeopbygning til et specifikt distributionssystem og en bestemt arkitektur. I dette tilf\u00e6lde udf\u00f8res kompileringen med de v\u00e6rkt\u00f8jer, som distribut\u00f8ren har forberedt. Det vil sige, at trin med at forberede kompileringsv\u00e6rkt\u00f8jet og v\u00e6lge biblioteker bliver overfl\u00f8digt. Desuden kan byggesprocessen nemt paralleliseres. <\/p>\n<p>Der er dog en ulempe ved denne tilgang: for hver distribution inden for samme arkitektur skal der samles sit eget s\u00e6t bin\u00e6re filer. Ulempen er ogs\u00e5, at et s\u00e5dant antal maskiner skal vedligeholdes, hvilket kr\u00e6ver meget diskplads og RAM. <\/p>\n<p>S\u00e5dan samles KMOD-pakkerne af k\u00e6demodulet veeamsnap til Red Hat-distributioner.<\/p>\n<h2>Open Build Service<\/h2>\n<p>\nKollegaerne fra SUSE fors\u00f8gte at implementere en form for gylden middelvej i form af en speciel service til kompilering af applikationer og pakkeopbygning \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/openbuildservice.org\/\">openbuildservice<\/a><\/noindex>.<\/p>\n<p>I bund og grund er det en hypervisor, der opretter en virtuel maskine, installerer alle n\u00f8dvendige pakker i den, udf\u00f8rer kompileringen af applikationen og pakkeopbygningen i dette isolerede milj\u00f8, hvorefter den virtuelle maskine frig\u00f8res.<\/p>\n<p><img decoding=\"async\" alt=\"Linux er mangefacet: hvordan man arbejder p\u00e5 enhver distribution\" src=\"\/wp-content\/uploads\/2019\/10\/93d2a70c589a7186ecef85a7863e59e8.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPlanl\u00e6gningssystemet implementeret i OpenBuildService vil selv bestemme, hvor mange virtuelle maskiner det kan starte for optimal hastighed i pakkeopbygningen. Den indbyggede signeringsmekanisme vil automatisk signere pakkerne og l\u00e6gge dem i det indbyggede repository. Det indbyggede versionskontrolsystem vil gemme historik over \u00e6ndringer og opbygninger. Man skal blot tilf\u00f8je sine kilder til dette system. Det er heller ikke n\u00f8dvendigt at ops\u00e6tte en server selv, man kan benytte den \u00e5bne.<\/p>\n<p>Her er der dog et problem: en s\u00e5dan kombination passer d\u00e5rligt ind i den eksisterende infrastruktur. For eksempel er versionskontrol ikke n\u00f8dvendig, da vi allerede har vores egne til kilderne. Signeringsmekanismen adskiller sig ogs\u00e5: der bruges en speciel server. Repositoryet er heller ikke n\u00f8dvendigt. <\/p>\n<p>Desuden er underst\u00f8ttelsen af andre distributioner \u2014 for eksempel Red Hat \u2014 ret sparsom, hvilket er helt forst\u00e5eligt.<\/p>\n<p>En fordel ved s\u00e5dan en service er den hurtige support af den nyeste version af SUSE-distributionen. Inden den officielle meddelelse om udgivelsen bliver de n\u00f8dvendige pakker til byggeriet lagt ud p\u00e5 det offentlige repository. I listen over tilg\u00e6ngelige distributioner i OpenBuildService vises den nye. Vi s\u00e6tter et flueben, og den tilf\u00f8jes til byggeplanen. P\u00e5 denne m\u00e5de kan tilf\u00f8jelsen af en ny version af distributionen ske n\u00e6sten med \u00e9t klik.<\/p>\n<p>I vores infrastruktur, der bruger OpenBuildService, samles hele mangfoldigheden af KMP-pakker til veeamsnap-kernemodulet for SUSE-distributioner.<\/p>\n<p>N\u00e6ste vil jeg fokusere p\u00e5 sp\u00f8rgsm\u00e5l, der er specifikke for kernemoduler.<\/p>\n<h2>kernel ABI<\/h2>\n<p>\nLinux kernemoduler har historisk set v\u00e6ret distribueret i form af kildekode. Problemet er, at skaberne af kernen ikke p\u00e5tager sig byrden med at st\u00f8tte en stabil API for kernemoduler, langt mindre p\u00e5 bin\u00e6r niveau, ogs\u00e5 kendt som kABI.<\/p>\n<p>For at bygge et modul til den almindelige kerne er det n\u00f8dvendigt at have netop denne kernes header-filer, og det vil kun fungere p\u00e5 denne kerne. <\/p>\n<p>DKMS muligg\u00f8r automatiseringen af byggeprocessen for moduler ved opdatering af kernen. Som resultat bruger brugere af Debian-repositoriet (og dets mange sl\u00e6gtninge) kernemoduler enten fra distribut\u00f8rens repository eller bygget fra kilden med hj\u00e6lp fra DKMS.<\/p>\n<p>Men en s\u00e5dan situation tilfredsstiller ikke Enterprise-segmentet. Distribut\u00f8rer af propriet\u00e6r kode \u00f8nsker at distribuere deres produkt som samlede bin\u00e6rfiler. <\/p>\n<p>Administratorer \u00f8nsker ikke at have udviklingsv\u00e6rkt\u00f8jer p\u00e5 produktionsservere af sikkerhedsm\u00e6ssige \u00e5rsager. Distribut\u00f8rer af Enterprise Linux \u2014 s\u00e5som Red Hat og SUSE \u2014 har besluttet, at de kan st\u00f8tte en stabil kABI for deres brugere. Resultatet har v\u00e6ret KMOD-pakker til Red Hat og KMP-pakker til SUSE.<\/p>\n<p>Essensen af denne l\u00f8sning er ret simpel. For en bestemt version af distributionen fryses kernen API. Distribut\u00f8ren h\u00e6vder, at de bruger netop kernen, for eksempel version 3.10, og laver kun rettelser og forbedringer, som ikke ber\u00f8rer kerne-gr\u00e6nsefladerne, og moduler bygget til den allerf\u00f8rste kerne kan bruges til alle efterf\u00f8lgende uden rekompilering.<\/p>\n<p>Red Hat erkl\u00e6rer kABI-kompatibilitet for distributionen gennem hele livscyklussen. Det vil sige, at en samlet modul til RHEL 6.0 (udgivelse november 2010) ogs\u00e5 skal fungere p\u00e5 version 6.10 (udgivelse juni 2018). Og det er n\u00e6sten 8 \u00e5r. Naturligvis er det en ret kompleks opgave. <br \/>\nVi har registreret flere tilf\u00e6lde, hvor moduler som f\u00f8lge af problemer med kABI-kompatibilitet oph\u00f8rte med at fungere. <\/p>\n<p>Efter at modulet veeamsnap, der blev bygget til RHEL 7.0, viste sig at v\u00e6re inkompatibelt med kernen fra RHEL 7.5, men alligevel blev indl\u00e6st og garanteret nedbr\u00f8d serveren, opgav vi helt at bruge kABI-kompatibilitet for RHEL 7. <\/p>\n<p>I \u00f8jeblikket indeholder KMOD-pakken til RHEL 7 en samling for hver versionsudgivelse og et script, der sikrer indl\u00e6sning af modulet.<\/p>\n<p>SUSE har taget en mere forsigtig tilgang til sp\u00f8rgsm\u00e5let om kABI-kompatibilitet. De sikrer kABI-kompatibilitet kun inden for en enkelt service pack. <\/p>\n<p>For eksempel blev udgivelsen af SLES 12 i september 2014. Og SLES 12 SP1 kom allerede i december 2015, alts\u00e5 lidt over et \u00e5r senere. Selvom begge udgivelser bruger kerne 3.12, er de kABI-incompatible. Det er tydeligt, at det er langt enklere at opretholde kABI-kompatibilitet i blot et \u00e5r. Den \u00e5rlige cyklus for opdatering af kerne-modulet b\u00f8r ikke forhindre moduludviklerne. <\/p>\n<p>Som f\u00f8lge af denne politik fra SUSE har vi ikke registreret et eneste problem med kABI-kompatibilitet for vores modul veeamsnap. Sandheden er, at antallet af pakker til SUSE er n\u00e6sten en orden st\u00f8rre.<\/p>\n<h2>Patches og backports<\/h2>\n<p>\nSelvom distribut\u00f8rerne fors\u00f8ger at sikre kABI-kompatibilitet og stabilitet i kernen, fors\u00f8ger de ogs\u00e5 at forbedre ydeevnen og rette defekter i denne stabile kerne. <\/p>\n<p>Derudover holder kerneludviklerne for enterprise linux \u00f8je med \u00e6ndringer i den vanille kerne og overf\u00f8rer dem til deres \"stabile\".<\/p>\n<p>Nogle gange f\u00f8rer dette til nye <noindex><a rel=\"nofollow\" href=\"https:\/\/access.redhat.com\/solutions\/3658111\">fejl<\/a><\/noindex>.<\/p>\n<p>I den seneste udgivelse af Red Hat 6 blev der lavet en fejl i en af de mindre opdateringer. Den f\u00f8rte til, at modulet veeamsnap garanteret nedbr\u00f8d systemet ved frigivelse af snapshots. Ved at sammenligne kildekoden til kernen f\u00f8r og efter opdateringen fandt vi, at \u00e5rsagen var backport. En lignende fix blev lavet i vanillekernen version 4.19. Bare i den vanille kerne fungerede denne fix normalt, men da den blev overf\u00f8rt til \"stabile\" 2.6.32 opstod der et problem med spin-locking.<\/p>\n<p>Selvf\u00f8lgelig er fejl noget, som alle og altid oplever, men var det v\u00e6rd at tr\u00e6kke koden fra 4.19 til 2.6.32 og risikere stabiliteten? Jeg er ikke sikker...<\/p>\n<p>Det v\u00e6rste er, n\u00e5r marketing kommer ind i det, mens man tr\u00e6kker i det mentale reb mellem 'stabilitet' og 'modernisering'. Marketingafdelingen skal have en stabil kerne i den opdaterede distribution, samtidig med at den skal v\u00e6re bedre i ydeevne og have nye funktioner. Dette f\u00f8rer til m\u00e6rkelige kompromiser. <\/p>\n<p>Da jeg fors\u00f8gte at samle modulet p\u00e5 kerne 4.4 fra SLES 12 SP3, blev jeg overrasket over at finde funktionaliteten fra den vanilje 4.8. Efter min mening ligner implementeringen af blokindgang\/udgang i kerne 4.4 fra SLES 12 SP3 mere kerne 4.8 end den tidligere stabile 4.4 kerne fra SLES 12 SP2. Jeg vil ikke bed\u00f8mme, hvad procentdelen var af overf\u00f8rt kode fra kerne 4.8 til SLES-4.4 for SP3, men det f\u00f8les for mig sv\u00e6rt at kalde kerne det samme stabile 4.4. <\/p>\n<p>Det mest problematiske ved at skrive et modul, der fungerer lige godt p\u00e5 forskellige kerner, er, at man ikke l\u00e6ngere kan stole p\u00e5 kerneversionen. Man m\u00e5 ogs\u00e5 tage hensyn til distributionen. Det er godt, at man nogle gange kan knytte sig til en define, der kommer med den nye funktionalitet, men s\u00e5dan en mulighed opst\u00e5r ikke altid. <\/p>\n<p>Som f\u00f8lge heraf f\u00e5r koden m\u00e6rkelige betingede kompilationsdirektiver.<\/p>\n<p>Der findes 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 kernelversion \u00e6ndrede listen over indparameterne.<\/p>\n<p>For at kunne samle det, m\u00e5tte jeg i makefile tilf\u00f8je et script, der tjekker, om parameteren mask er til stede for funktionen lookup_bdev.<\/p>\n<h2>Signaturer for kerne-moduler<\/h2>\n<p>\nMen lad os vende tilbage til sp\u00f8rgsm\u00e5let om distribution af pakker.<\/p>\n<p>En af fordelene ved stabil kABI er, at kerne-moduler kan signeres som bin\u00e6re filer. I s\u00e5 fald kan udvikleren v\u00e6re sikker p\u00e5, at modulet ikke er blevet beskadiget ved et uheld eller \u00e6ndret med vilje. Dette kan verificeres med kommandoen modinfo. <\/p>\n<p>Red Hat og SUSE distributioner tillader at kontrollere signaturen af modulet og indl\u00e6se det kun, hvis det tilh\u00f8rende certifikat er registreret i systemet. Certifikatet er en offentlig n\u00f8gle, der bruges til at signere modulet. Vi distribuerer det som en separat pakke.<\/p>\n<p>Problemet her er, at certifikaterne kan enten v\u00e6re indbygget i kernen (de bruges af distribut\u00f8rer) eller skal skrives til den ikke-flygtige EFI-hukommelse ved hj\u00e6lp af en utility. <i>mokutil<\/i>. Utility <i>mokutil<\/i> ved installation af certifikatet kr\u00e6ver en genstart af systemet, og inden kernelens opstart foresl\u00e5r det til administratoren at tillade indl\u00e6sning af det nye certifikat. <\/p>\n<p>Dermed kr\u00e6ver tilf\u00f8jelsen af et certifikat fysisk adgang til systemet fra administratoren. Hvis maskinen er placeret et sted i cloud\u2019en eller blot i en fjern server, og adgangen blot er netv\u00e6rksbaseret (f.eks. via ssh), s\u00e5 vil det ikke v\u00e6re muligt at tilf\u00f8je certifikatet. <\/p>\n<h2>EFI p\u00e5 virtuelle maskiner<\/h2>\n<p>\nSelvom EFI allerede l\u00e6nge har v\u00e6ret underst\u00f8ttet af n\u00e6sten alle producenters bundkort, kan administratoren ved installation af systemet muligvis ikke t\u00e6nke over n\u00f8dvendigheden af 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 fra 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 man kun indstille muligheden <b>Secure Boot<\/b> i den gamle version af webgr\u00e6nsefladen, der k\u00f8rer via Flash. Web UI i HTML-5 halter stadig meget bagefter.<\/p>\n<h2>Eksperimentelle distributioner<\/h2>\n<p>\nOg til sidst lad os se p\u00e5 sp\u00f8rgsm\u00e5let om eksperimentelle distributioner og distributioner uden officiel st\u00f8tte. P\u00e5 den ene side vil man n\u00e6ppe finde s\u00e5danne distributioner p\u00e5 servere i seri\u00f8se organisationer. Der er ingen officiel st\u00f8tte til s\u00e5danne distributioner. Derfor kan man ikke s\u00f8rge for teknisk support af produktet p\u00e5 en s\u00e5dan distribution. <\/p>\n<p>Men s\u00e5danne distributioner bliver en praktisk platform til at afpr\u00f8ve nye eksperimentelle l\u00f8sninger. For eksempel Fedora, OpenSUSE Tumbleweed eller Unstable-versioner af Debian. De er ganske stabile. De har altid nye versioner af programmer og altid en ny kernel. Om et \u00e5r kan denne eksperimentelle funktionalitet findes i den opdaterede RHEL, SLES eller Ubuntu. <\/p>\n<p>S\u00e5 hvis noget ikke fungerer p\u00e5 en eksperimentel distribution, er det en grund til at unders\u00f8ge problemet og l\u00f8se det. Man skal v\u00e6re klar over, at denne funktionalitet snart vil dukke op p\u00e5 brugernes produktionsservere.<\/p>\n<p>Den nuv\u00e6rende liste over officielt underst\u00f8ttede distributioner for version 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 faktiske liste over distributioner, som vores produkt kan k\u00f8re p\u00e5, er meget st\u00f8rre.<\/p>\n<p>Jeg var personligt interesseret i et eksperiment med OS \"Elbrus\". Efter justering af veeam-pakken blev vores produkt installeret og fungerede. Jeg skrev om dette eksperiment p\u00e5 Habra i <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/veeam\/blog\/447960\/\">artikel<\/a><\/noindex>. <\/p>\n<p>Og st\u00f8tten til nye distributioner forts\u00e6tter. Vi forventer snart version 4.0. Betaversionen burde snart v\u00e6re tilg\u00e6ngelig, s\u00e5 hold \u00f8je med <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.3 - 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\/da\/blog\/administrirovanie\/linux-mnogolikij-kak-rabotat-na-lyubom-distributive\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"da_DK\" \/>\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\/da\/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 er mangfoldig: hvordan man arbejder p\u00e5 enhver distribution | ProHoster","description":"Opret en backupapplikation.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/linux-mnogolikij-kak-rabotat-na-lyubom-distributive","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/38929","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=38929"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/38929\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/29206"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=38929"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=38929"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=38929"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}