{"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\/nl\/blog\/administrirovanie\/linux-mnogolikij-kak-rabotat-na-lyubom-distributive","title":{"rendered":"Linux veelzijdig: hoe te werken met elke distributie","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Linux veelzijdig: hoe te werken met elke distributie\" src=\"\/wp-content\/uploads\/2019\/10\/ee1aaad566204532c974a3ce8f13b915.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEen applicatie voor back-up cre\u00ebren die op elke distributie werkt, is een uitdagende taak. Om de werking van Veeam Agent for Linux op distributies van Red Hat 6 en Debian 6 tot OpenSUSE 15.1 en Ubuntu 19.04 te waarborgen, moeten we een reeks problemen oplossen, vooral gezien het feit dat de software een kernelmodule bevat.<\/p>\n<p>Dit artikel is gebaseerd op een presentatie op de conferentie <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 is niet zomaar een van de populairste besturingssystemen. In wezen is het een platform waarop iets unieks, iets eigens kan worden gemaakt. Daarom zijn er talloze Linux-distributies die verschillen in hun set van softwarecomponenten. Hier doet zich een probleem voor: om ervoor te zorgen dat de software op elke distributie functioneert, moeten de unieke kenmerken van elk in aanmerking worden genomen.<\/p>\n<h2>Pakketbeheerders. .deb vs .rpm<\/h2>\n<p>\nLaten we beginnen met het voor de hand liggende probleem van de distributie van het product voor verschillende distributies.<br \/>\nDe meest typische manier om softwareproducten te distribueren is door een pakket op een repository te plaatsen, zodat de ingebouwde pakketbeheerder van het systeem het daaruit kan installeren.<br \/>\nEr zijn echter twee populaire pakketformaten: <i>rpm<\/i> en <i>deb<\/i>. Dat betekent dat we elk moeten ondersteunen.<\/p>\n<p>In de wereld van deb-pakketten is het niveau van compatibiliteit verbazingwekkend. E\u00e9n en hetzelfde pakket kan even goed worden ge\u00efnstalleerd en werken op zowel Debian 6 als Ubuntu 19.04. De standaarden voor het bouwen van pakketten en het werken ermee, die in oude Debian-distributies zijn vastgelegd, blijven relevant in de hippe Linux Mint en elementary OS. Daarom is het in het geval van Veeam Agent for Linux voldoende om \u00e9\u00e9n deb-pakket voor elk hardwareplatform te hebben.<\/p>\n<p>In de wereld van rpm-pakketten zijn de verschillen groot. Ten eerste, omdat er twee volledig onafhankelijke distributeurs zijn, Red Hat en SUSE, waarvoor compatibiliteit helemaal niet nodig is. Ten tweede hebben deze distributeurs distributies met technische ondersteuning en experimentele versies. Tussen hen is compatibiliteit ook niet noodzakelijk. We eindigen met dat er voor el6, el7 en el8 eigen pakketten zijn. Een aparte pakket voor Fedora. Pakketten voor SLES11 en 12 en een aparte voor openSUSE. Het belangrijkste probleem ligt bij de afhankelijkheden en de namen van de pakketten. <\/p>\n<h2>Afhankelijkheidsproblemen<\/h2>\n<p>\nHelaas komen dezelfde pakketten vaak onder verschillende namen voor in verschillende distributies. Hieronder een onvolledige lijst van de afhankelijkheden van het pakket veeam.<\/p>\n<p>Voor EL7:<br \/>\nVoor 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>\nAls gevolg hiervan is de lijst met afhankelijkheden uniek voor de distributie. <\/p>\n<p>Slechter wordt het wanneer een nieuwe versie zich onder de oude pakketnaam verbergt. <\/p>\n<p><b>Voorbeeld:<\/b><\/p>\n<p>In Fedora 24 is het pakket bijgewerkt <i>ncurses<\/i> van versie 5 naar versie 6. Ons product was specifiek gebouwd op versie 5 om compatibiliteit met oudere distributies te waarborgen. Om gebruik te maken van de oude versie 5 van de bibliotheek op Fedora 24, moest het pakket <i>ncurses-compat-libs<\/i>. <\/p>\n<p>Daarom heeft Fedora nu twee pakketten met verschillende afhankelijkheden. <\/p>\n<p>Het wordt interessanter. Na opnieuw een update van de distributie is het pakket <i>ncurses-compat-libs<\/i> met de versie 5 van de bibliotheek niet meer beschikbaar. Voor de distributeur is het kostbaar om oude bibliotheken naar een nieuwe versie van de distributie te slepen. Na enige tijd deed het probleem zich ook voor in de SUSE-distributies.<\/p>\n<p>Daarom moesten voor sommige distributies expliciete afhankelijkheden van <i>ncurses-libs<\/i>, worden opgegeven, en het product aangepast worden zodat het met elke versie van de bibliotheek kan werken.<\/p>\n<p>Overigens, in versie 8 van Red Hat is er geen meta-pakket meer <i>python<\/i>, dat verwees naar de oude vertrouwde <i>python 2.7<\/i>. Er is <i>python2<\/i> en <i>python<\/i>3. <\/p>\n<h2>Een alternatief voor pakketbeheerders<\/h2>\n<p>\nHet probleem met afhankelijkheden is al oud en voor de hand liggend. Denk bijvoorbeeld aan Dependency hell. <br \/>\nVerschillende bibliotheken en applicaties integreren zodat ze allemaal stabiel functioneren en niet met elkaar conflicteren - dat is de uitdaging die elke Linux-distributeur probeert op te lossen.<\/p>\n<p>De pakketbeheerder probeert dit probleem heel anders op te lossen <b>Snappy<\/b> van Canonical. Het belangrijkste idee is: de applicatie draait in een ge\u00efsoleerde en van het hoofdsysteem beschermde sandbox. Als de applicatie bibliotheken nodig heeft, worden deze samen met de applicatie geleverd.<\/p>\n<p><b>Flatpak<\/b> maakt ook het draaien van applicaties in een sandbox mogelijk, met gebruik van Linux Containers. Het concept van een sandbox wordt ook gebruikt door <b>AppImage<\/b>.<\/p>\n<p>Deze oplossingen maken het mogelijk om \u00e9\u00e9n pakket voor alle distributies te cre\u00ebren. In het geval van <b>Flatpak<\/b> is installatie en uitvoering van de applicatie zelfs mogelijk zonder medeweten van de administrator.<\/p>\n<p>Het grote probleem is dat niet alle applicaties in een sandbox kunnen draaien. Sommige vereisen directe toegang tot het platform. Ik heb het nog niet eens over kernelmodules die sterk afhankelijk zijn van de kernel en zich helemaal niet in het sandboxconcept laten inpassen. <\/p>\n<p>Een tweede probleem is dat populaire enterprise-distributies van Red Hat en SUSE nog geen ondersteuning bieden voor Snappy en Flatpak. <\/p>\n<p>Daarom is Veeam Agent for Linux niet beschikbaar op <noindex><a rel=\"nofollow\" href=\"https:\/\/snapcraft.io\/\">snapcraft.io<\/a><\/noindex> of <noindex><a rel=\"nofollow\" href=\"https:\/\/flathub.org\/home\">flathub.org<\/a><\/noindex>.<\/p>\n<p>Tot slot, over het onderwerp pakketbeheerders wil ik opmerken dat het mogelijk is om helemaal zonder pakketbeheerders te werken door binaire bestanden en een installatiescript in \u00e9\u00e9n pakket samen te voegen. <\/p>\n<p>Zo'n bundle maakt het mogelijk om \u00e9\u00e9n algemeen pakket te cre\u00ebren voor verschillende distributies en platforms, waarbij een interactieve installatieproces mogelijk is met de benodigde aanpassingen. Ik ben dergelijke pakketten voor Linux alleen tegengekomen van VMware.<\/p>\n<h2>Het probleem met updates<\/h2>\n<p>\n<img decoding=\"async\" alt=\"Linux veelzijdig: hoe te werken met elke distributie\" src=\"\/wp-content\/uploads\/2019\/10\/aa14b10a434c28541574421d97807de7.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nZelfs als alle afhankelijkheidsproblemen zijn opgelost, kan de software verschillend functioneren op dezelfde distributie. Dit komt door de updates.<\/p>\n<p>Er zijn drie update-strategie\u00ebn:<\/p>\n<ul>\n<li>De eenvoudigste is om nooit te updaten. Je stelt de server in en vergeet het. Waarom updates, als alles werkt? Problemen ontstaan bij de eerste aanvraag bij de klantenservice. De maker van de distributie ondersteunt alleen de bijgewerkte release. <\/li>\n<li>Je kunt vertrouwen op de distributeur en automatische updates instellen. In dat geval is een telefoontje naar de klantenservice waarschijnlijk onmiddellijk na een mislukte update.<\/li>\n<li>De optie voor handmatige updates alleen na het testen op de testinfrastructuur is de meest zekere, maar ook de duurste en meest arbeidsintensievere. Niet iedereen kan zich dat veroorloven.<\/li>\n<\/ul>\n<p>\nOmdat verschillende gebruikers verschillende update-strategie\u00ebn toepassen, moet je zowel de nieuwste release als alle eerder uitgebrachte versies ondersteunen. Dit bemoeilijkt zowel het ontwikkelings- als het testproces, en voegt hoofdpijn toe aan de klantenservice.<\/p>\n<h2>Diversiteit aan hardwareplatformen<\/h2>\n<p>\nVerschillende hardwareplatformen vormen een probleem dat voor een groot deel specifiek is voor native code. Minstens moet je binaire bestanden samenstellen voor elk ondersteund platform.<\/p>\n<p>In het project Veeam Agent for Linux kunnen we niets RISC-achtigs ondersteunen.<\/p>\n<p>Ik zal hier niet te diep op ingaan. Ik wil slechts de belangrijkste problemen benoemen: platformafhankelijke typen, zoals <code>size_t<\/code>, structurering en byte order.<\/p>\n<h2>Statische en\/of dynamische linking<\/h2>\n<p>\n<img decoding=\"async\" alt=\"Linux veelzijdig: hoe te werken met elke distributie\" src=\"\/wp-content\/uploads\/2019\/10\/dc473aad4ea0818940af7eafdbc641fd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nDe vraag \"Hoe te linken met bibliotheken - dynamisch of statisch?\" verdient bespreking.<\/p>\n<p>In de regel maken C\/C++-toepassingen onder Linux gebruik van dynamische koppeling. Dit werkt uitstekend als de toepassing specifiek is opgebouwd voor een bepaald distributie.<\/p>\n<p>Als de bedoeling is om verschillende distributies met \u00e9\u00e9n binaire file te dekken, moet men zich richten op de oudste ondersteunde distributie. Voor ons is dat Red Hat 6. Deze bevat gcc 4.4, dat zelfs de standaard C++11 niet ondersteunt. <noindex><a rel=\"nofollow\" href=\"https:\/\/gcc.gnu.org\/projects\/cxx-status.html\">fully<\/a><\/noindex>.<\/p>\n<p>Wij bouwen ons project met gcc 6.3, dat C++14 volledig ondersteunt. Uiteraard betekent dit dat we op Red Hat 6 de libstdc++-bibliotheek en boost mee moeten nemen. De eenvoudigste manier is om statisch met hen te linken.<\/p>\n<p>Maar helaas kunnen niet alle bibliotheken statisch worden gekoppeld.<\/p>\n<p>Ten eerste moeten systeembibliotheken, zoals <i>libfuse<\/i>, <i>libblkid<\/i> dynamisch worden gekoppeld om compatibiliteit met de kernel en zijn modules te waarborgen. <\/p>\n<p>Ten tweede zijn er nuances met licenties. <\/p>\n<p>De GPL-licentie staat in principe alleen het linken van bibliotheken met opensource-code toe. MIT en BSD staan statische koppeling toe en maken het mogelijk om bibliotheken in een project op te nemen. De LGPL lijkt daarentegen geen bezwaar te hebben tegen statische koppeling, maar vereist dat de bestanden die nodig zijn voor het linken openbaar worden gemaakt. <\/p>\n<p>In het algemeen zal gebruik van dynamische koppeling de noodzaak om iets te verstrekken vermijden.<\/p>\n<h2>Bouwen van C\/C++-toepassingen<\/h2>\n<p>\nVoor het bouwen van C\/C++-toepassingen voor verschillende platforms en distributies is het voldoende om een juiste versie van gcc te kiezen of te bouwen en gebruik te maken van cross-compilers voor specifieke architecturen, en om de volledige set bibliotheken te bouwen. Dit werk is goed uitvoerbaar, maar behoorlijk omslachtig. En er zijn geen garanties dat de gekozen compiler en bibliotheken een werkbare versie zullen leveren. <\/p>\n<p>Een duidelijk voordeel: de infrastructuur wordt sterk vereenvoudigd, aangezien het hele bouwproces op \u00e9\u00e9n machine kan worden uitgevoerd. Bovendien is het voldoende om \u00e9\u00e9n set binaire bestanden voor \u00e9\u00e9n architectuur te bouwen en kunnen deze in pakketten voor verschillende distributies worden verpakt. Dit is precies hoe de pakketten van veeam voor Veeam Agent voor Linux worden gebouwd.<\/p>\n<p>In tegenstelling tot deze optie kun je eenvoudig een buildfarm opzetten, dat wil zeggen meerdere machines voor het compileren. Elke machine zorgt voor de compilatie van de applicatie en de bundeling van het pakket voor een specifieke distributie en bepaald architectuur. In dat geval wordt de compilatie uitgevoerd met de middelen die de distributeur heeft voorbereid. Dit betekent dat de voorbereiding van de compiler en het selecteren van bibliotheken niet nodig zijn. Bovendien kan het assemblageproces gemakkelijk worden parallel verwerkt. <\/p>\n<p>Er is echter ook een nadeel aan deze aanpak: voor elke distributie binnen \u00e9\u00e9n architectuur moet een eigen set binaire bestanden worden samengesteld. Een ander nadeel is dat een dergelijk aantal machines onderhouden moet worden, wat veel schijfruimte en RAM vereist. <\/p>\n<p>Op deze manier worden KMOD-pakketten van de kernelmodule veeamsnap voor Red Hat-distributies samengesteld.<\/p>\n<h2>Open Build Service<\/h2>\n<p>\nCollega's van SUSE hebben geprobeerd een tussenoplossing te realiseren in de vorm van een speciale service voor het compileren van applicaties en het samenstellen van pakketten \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/openbuildservice.org\/\">openbuildservice<\/a><\/noindex>.<\/p>\n<p>Het is in wezen een hypervisor die een virtuele machine cre\u00ebert, alle benodigde pakketten installeert, de applicatie compileert en het pakket in deze ge\u00efsoleerde omgeving samenstelt. Vervolgens wordt die virtuele machine vrijgegeven.<\/p>\n<p><img decoding=\"async\" alt=\"Linux veelzijdig: hoe te werken met elke distributie\" src=\"\/wp-content\/uploads\/2019\/10\/93d2a70c589a7186ecef85a7863e59e8.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDe planner in OpenBuildService bepaalt zelf hoeveel virtuele machines hij kan starten voor optimale snelheid van het samenstellen van pakketten. Het ingebouwde ondertekenmechanisme ondertekent automatisch de pakketten en plaatst ze in de ingebouwde repository. Het ingebouwde versiecontrolesysteem houdt een geschiedenis bij van wijzigingen en builds. Het enige dat je hoeft te doen is je source code aan deze systemen toe te voegen. Het is zelfs niet nodig om zelf een server op te zetten, je kunt gebruikmaken van een open server.<\/p>\n<p>Er is echter een probleem: zo'n combi past moeilijk in de bestaande infrastructuur. Bijvoorbeeld, versiecontrole is niet nodig, we hebben al onze eigen voor de source code. Ons ondertekenmechanisme verschilt: we gebruiken een speciale server. Een repository is ook niet nodig. <\/p>\n<p>Bovendien is de ondersteuning voor andere distributies \u2014 bijvoorbeeld Red Hat \u2014 nogal beperkt, wat goed te begrijpen is.<\/p>\n<p>Een van de voordelen van deze service is de snelle ondersteuning van de nieuwste versie van de SUSE-distributie. Voordat de offici\u00eble aankondiging van de release plaatsvindt, worden de benodigde pakketten voor de bouw al op een openbaar repository geplaatst. In de lijst van beschikbare distributies op OpenBuildService verschijnt er een nieuwe. We zetten een vinkje en deze wordt toegevoegd aan het bouwplan. Zo kan de nieuwe versie van de distributie vrijwel met \u00e9\u00e9n klik worden toegevoegd.<\/p>\n<p>In onze infrastructuur worden met behulp van OpenBuildService alle vari\u00ebteiten van KMP-pakketten van de veeamsnap-kernelmodule voor SUSE-distributies samengesteld.<\/p>\n<p>Daarna wil ik stilstaan bij kwesties die specifiek zijn voor kernelmodules.<\/p>\n<h2>kernel ABI<\/h2>\n<p>\nLinux-kernelmodules worden historisch gezien verspreid als broncode. Het probleem is dat de makers van de kernel zich niet druk maken om het ondersteunen van een stabiele API voor kernelmodules, laat staan op binair niveau, verder kABI.<\/p>\n<p>Om een module voor de vanilla kernel te bouwen, zijn de headers van precies deze kernel nodig, en hij zal alleen op deze kernel functioneren. <\/p>\n<p>DKMS maakt het mogelijk om het proces van het bouwen van modules te automatiseren bij een kernupdate. Als gevolg hiervan gebruiken gebruikers van de Debian-repository (en zijn vele afgeleiden) kernelmodules ofwel uit de distributie-repository, ofwel samengesteld vanuit de bron met behulp van DKMS.<\/p>\n<p>Echter, deze situatie bevalt de Enterprise-segment niet echt. Verspreiders van propri\u00ebtaire code willen het product in de vorm van gebundelde binaries distribueren. <\/p>\n<p>Beheerders willen geen ontwikkeltools op production-servers houden uit veiligheidsredenen. Distributeurs van Enterprise Linux \u2013 zoals Red Hat en SUSE \u2013 hebben besloten dat ze voor hun gebruikers een stabiele kABI kunnen ondersteunen. Hierdoor zijn er KMOD-pakketten voor Red Hat en KMP-pakketten voor SUSE ontstaan.<\/p>\n<p>De essentie van deze oplossing is vrij eenvoudig. Voor een specifieke versie van de distributie wordt de kernel API bevroren. De distributeur geeft aan dat hij precies deze kernel gebruikt, bijvoorbeeld 3.10, en alleen correcties en verbeteringen aanbrengt die de interfaces van de kernel niet be\u00efnvloeden, terwijl de modules die voor de eerste kernel zijn samengesteld, voor alle latere versies zonder recompilatie kunnen worden gebruikt.<\/p>\n<p>Red Hat stelt kABI-compatibiliteit voor de distributie gedurende de hele levenscyclus. Dit betekent dat een opgebouwde module voor RHEL 6.0 (release november 2010) ook moet werken op versie 6.10 (release juni 2018). Dit is bijna 8 jaar. Natuurlijk is deze taak behoorlijk complex. <br \/>\nWe hebben verschillende gevallen geregistreerd waarin de module veeamsnap stopte met werken vanwege problemen met de kABI-compatibiliteit. <\/p>\n<p>Nadat de module veeamsnap, opgebouwd voor RHEL 7.0, incompatibel bleek met de kernel van RHEL 7.5, maar toch ladend was en gegarandeerd de server liet crashen, hebben we besloten om helemaal geen gebruik meer te maken van kABI-compatibiliteit voor RHEL 7. <\/p>\n<p>Op dit moment bevat het KMOD-pakket voor RHEL 7 een build voor elke versie van de release en een script dat zorgt voor het laden van de module.<\/p>\n<p>SUSE benaderde de kABI-compatibiliteit voorzichtig. Ze zorgen alleen voor kABI-compatibiliteit binnen \u00e9\u00e9n service pack. <\/p>\n<p>Bijvoorbeeld, de release SLES 12 vond plaats in september 2014. En SLES 12 SP1 volgde al in december 2015, dus maar iets meer dan een jaar later. Ondanks dat beide releases kernel 3.12 gebruiken, zijn ze kABI-incompatibel. Het is duidelijk dat het aanzienlijk eenvoudiger is om kABI-compatibiliteit gedurende slechts een jaar te onderhouden. Een jaarlijkse cyclus van modulekernelupdates mag geen problemen opleveren voor moduleontwikkelaars. <\/p>\n<p>Als gevolg van deze beleidslijn van SUSE hebben we geen enkele probleem met de kABI-compatibiliteit van onze module veeamsnap vastgesteld. Feitelijk is het aantal pakketten voor SUSE bijna een orde van grootte groter.<\/p>\n<h2>Patches en backports<\/h2>\n<p>\nHoewel distributeurs proberen kABI-compatibiliteit en stabiliteit van de kernel te waarborgen, proberen ze ook de prestaties te verbeteren en defecten in deze stabiele kernel te verhelpen. <\/p>\n<p>Daarnaast, naast hun eigen \u2018foutoplossingen\u2019, volgen de ontwikkelaars van de enterprise linux-kernel de wijzigingen in de vanilla kernel en dragen ze deze over naar hun \u2018stabiele\u2019 versie.<\/p>\n<p>Soms leidt dit tot nieuwe <noindex><a rel=\"nofollow\" href=\"https:\/\/access.redhat.com\/solutions\/3658111\">fouten<\/a><\/noindex>.<\/p>\n<p>In de laatste release van Red Hat 6 was er een fout in een van de minor updates. Dit leidde ertoe dat de module veeamsnap gegarandeerd het systeem liet crashen bij het vrijgeven van een snapshot. Door de bronnen van de kernel voor en na de update te vergelijken, ontdekten we dat de oorzaak een backport was. Een soortgelijke fix was aangebracht in de vanilla kernel versie 4.19. Alleen werkte deze fix goed in de vanilla kernel, maar ontstond er een probleem met spin-locks bij de overdracht naar de \u2018stabiele\u2019 2.6.32.<\/p>\n<p>Natuurlijk komen fouten voor bij iedereen en altijd, maar was het de moeite waard om de code van 4.19 naar 2.6.32 te slepen, terwijl je de stabiliteit op het spel zet?.. Ik ben er niet zeker van...<\/p>\n<p>Het slechtste is wanneer marketing betrokken raakt bij de trekkracht tussen 'stabiliteit'  'modernisering'. De marketingafdeling heeft nodig dat de kernel van de ge\u00fcpdatete distributie stabiel is, aan de ene kant, en tegelijkertijd beter presteert en nieuwe functies heeft. Dit leidt tot vreemde compromissen. <\/p>\n<p>Toen ik probeerde een module te bouwen op kernel 4.4 van SLES 12 SP3, ontdekte ik tot mijn verbazing functionaliteit uit de vanille 4.8. Naar mijn mening is de implementatie van block I\/O in de kernel 4.4 van SLES 12 SP3 meer in lijn met kernel 4.8 dan met de vorige release van de stabiele 4.4 kernel van SLES 12 SP2. Hoeveel van de code van kernel 4.8 is overgezet naar de SLES-kernel 4.4 voor SP3 durf ik niet te zeggen, maar om de kernel nog steeds als stabiele 4.4 te beschouwen, lukt me dat niet. <\/p>\n<p>Het meest frustrerende is dat je bij het schrijven van een module die op verschillende kernels even goed werkt, niet meer op de kernelversie kunt vertrouwen. Je moet ook rekening houden met de distributie. Gelukkig kun je soms steunen op een define die samen met nieuwe functionaliteit verschijnt, maar die mogelijkheid is niet altijd beschikbaar. <\/p>\n<p>Als resultaat groeit de code met bizarre conditionele compilatiedirectieven.<\/p>\n<p>Er zijn ook patches die de gedocumenteerde API van de kernel veranderen. <br \/>\nIk kwam een distributie tegen <noindex><a rel=\"nofollow\" href=\"https:\/\/neon.kde.org\/\">KDE neon<\/a><\/noindex> 5.16 en was zeer verrast te zien dat de aanroep van lookup_bdev in deze kernelversie de lijst met invoerparameters heeft gewijzigd.<\/p>\n<p>Om te kunnen bouwen, moest ik een script aan de makefile toevoegen dat controleert of er een mask-parameter is voor de functie lookup_bdev.<\/p>\n<h2>Ondertekening van kernelmodules<\/h2>\n<p>\nMaar laten we terugkeren naar de kwestie van het verspreiden van pakketten.<\/p>\n<p>Een van de voordelen van een stabiele kABI is dat kernelmodules in de vorm van een binair bestand ondertekend kunnen worden. In dit geval kan de ontwikkelaar er zeker van zijn dat de module niet per ongeluk is beschadigd of opzettelijk is gewijzigd. Dit kan worden gecontroleerd met het commando modinfo. <\/p>\n<p>De distributies Red Hat en SUSE staan toe om de handtekening van de module te controleren en deze alleen te laden als het bijbehorende certificaat in het systeem is geregistreerd. Het certificaat is de publieke sleutel waarmee de module is ondertekend. We verspreiden het als een afzonderlijk pakket.<\/p>\n<p>Het probleem is dat certificaten ofwel in de kernel zijn ingebouwd (deze worden gebruikt door distributeurs), of in het non-volatile geheugen van EFI moeten worden geschreven met behulp van een utility. <i>mokutil<\/i>. Hulpprogramma <i>mokutil<\/i> bij het installeren van het certificaat vraagt het om het systeem opnieuw op te starten en voordat de kernel van het besturingssysteem wordt geladen, vraagt het de beheerder om toestemming te geven voor het laden van het nieuwe certificaat. <\/p>\n<p>Daarom vereist het toevoegen van een certificaat fysieke toegang van de beheerder tot het systeem. Als de machine zich ergens in de cloud bevindt of gewoon op een externe server staat en de toegang alleen via het netwerk (bijvoorbeeld via ssh) mogelijk is, is het niet mogelijk om het certificaat toe te voegen. <\/p>\n<h2>EFI op virtuele machines<\/h2>\n<p>\nOndanks dat EFI al lange tijd door bijna alle moederbordfabrikanten wordt ondersteund, kan de beheerder bij het installeren van het systeem niet nadenken over de noodzaak van EFI, waardoor deze mogelijk is uitgeschakeld. <\/p>\n<p>Niet alle hypervisors ondersteunen EFI. VMWare vSphere ondersteunt EFI sinds versie 5. <br \/>\nMicrosoft Hyper-V kreeg ook ondersteuning voor EFI, te beginnen met Hyper-V voor Windows Server 2012R2. <\/p>\n<p>Echter, in de standaardconfiguratie is deze functionaliteit voor Linux-machines uitgeschakeld, wat betekent dat het certificaat niet kan worden ge\u00efnstalleerd. <\/p>\n<p>In vSphere 6.5 kan de optie <b>Secure Boot<\/b> alleen worden ingesteld via de oude versie van de webinterface die via Flash werkt. De Web UI op HTML-5 loopt momenteel sterk achter.<\/p>\n<h2>Experimentele distributies<\/h2>\n<p>\nTot slot bekijken we de kwestie van experimentele distributies en distributies zonder offici\u00eble ondersteuning. Aan de ene kant zijn zulke distributies waarschijnlijk niet te vinden op de servers van serieuze organisaties. Er is geen offici\u00eble ondersteuning voor zulke distributies. Daarom kan technische ondersteuning van het product op zo'n distributie niet worden gegarandeerd. <\/p>\n<p>Toch worden dergelijke distributies een handige plek om nieuwe experimentele oplossingen uit te proberen. Bijvoorbeeld Fedora, OpenSUSE Tumbleweed of ongebruikelijke versies van Debian. Ze zijn vrij stabiel. Ze bevatten altijd nieuwe versies van software en altijd een nieuwe kernel. Over een jaar kan deze experimentele functionaliteit in de bijgewerkte RHEL, SLES of Ubuntu verschijnen. <\/p>\n<p>Dus als iets niet werkt op een experimentele distributie, is dat een reden om het probleem te onderzoeken en op te lossen. Men moet voorbereid zijn op het feit dat deze functionaliteit binnenkort beschikbaar zal zijn op de productie-servers van gebruikers.<\/p>\n<p>De huidige lijst met officieel ondersteunde distributies voor versie 3.0 kunt u bestuderen <noindex><a rel=\"nofollow\" href=\"https:\/\/helpcenter.veeam.com\/docs\/agentforlinux\/userguide\/system_requirements.html?ver=30\">hier<\/a><\/noindex>. Maar de werkelijke lijst met distributies waarop ons product kan werken, is veel breder.<\/p>\n<p>Persoonlijk vond ik het experiment met het besturingssysteem 'Elbrus' interessant. Na aanpassing van het veeam-pakket werd ons product ge\u00efnstalleerd en werkte het. Over dit experiment heb ik geschreven op Habr in <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/veeam\/blog\/447960\/\">artikel<\/a><\/noindex>. <\/p>\n<p>De ondersteuning voor nieuwe distributies gaat echter door. We verwachten spoedig versie 4.0. De b\u00e8taversie zou binnenkort beschikbaar moeten komen, dus houd de <noindex><a rel=\"nofollow\" href=\"https:\/\/www.veeam.com\/whats-new-linux-agent.html\">whats-new<\/a><\/noindex>!<br \/>\n<br \/>Bron: <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\/nl\/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=\"nl_NL\" \/>\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\/nl\/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 is veelzijdig: hoe te werken op elke distributie | ProHoster","description":"Een back-up applicatie cre\u00ebren.","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/linux-mnogolikij-kak-rabotat-na-lyubom-distributive","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","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\/nl\/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\/nl\/wp-json\/wp\/v2\/posts\/38929","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=38929"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/38929\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/29206"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=38929"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=38929"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=38929"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}