{"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\/de\/blog\/administrirovanie\/linux-mnogolikij-kak-rabotat-na-lyubom-distributive","title":{"rendered":"Linux vielf\u00e4ltig: So arbeiten Sie mit jeder Distribution","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Linux vielf\u00e4ltig: So arbeiten Sie mit jeder Distribution\" src=\"\/wp-content\/uploads\/2019\/10\/ee1aaad566204532c974a3ce8f13b915.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEine Anwendung f\u00fcr die Datensicherung zu erstellen, die auf jeder Distribution funktioniert, ist eine komplexe Aufgabe. Um sicherzustellen, dass Veeam Agent for Linux auf Distributionen von Red Hat 6 und Debian 6 bis hin zu OpenSUSE 15.1 und Ubuntu 19.04 funktioniert, m\u00fcssen eine Reihe von Problemen gel\u00f6st werden, insbesondere wenn man bedenkt, dass das Softwareprodukt ein Kernelmodul umfasst.<\/p>\n<p>Der Artikel wurde auf Grundlage eines Vortrags auf der Konferenz <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 ist nicht einfach nur eines der beliebtesten Betriebssysteme. Im Grunde genommen ist es eine Plattform, auf der man etwas Einzigartiges, etwas Eigenes schaffen kann. Daher gibt es von Linux zahlreiche Distributionen, die sich in ihrer Sammlung von Softwarekomponenten unterscheiden. Und hier entsteht ein Problem: Damit das Softwareprodukt auf jeder Distribution funktioniert, m\u00fcssen die Besonderheiten jeder einzelnen beachtet werden.<\/p>\n<h2>Paketmanager. .deb vs .rpm<\/h2>\n<p>\nBeginnen wir mit dem offensichtlichen Problem der Verbreitung des Produkts f\u00fcr verschiedene Distributionen.<br \/>\nDie typischste Methode, Softwareprodukte zu verteilen, besteht darin, ein Paket in ein Repository hochzuladen, damit der im System integrierte Paketmanager es von dort installieren kann.<br \/>\nEs gibt jedoch zwei beliebte Paketformate: <i>rpm<\/i> und <i>deb<\/i>. Das bedeutet, dass wir jedes unterst\u00fctzen m\u00fcssen.<\/p>\n<p>In der Welt der deb-Pakete ist das Kompatibilit\u00e4tsniveau erstaunlich. Dasselbe Paket l\u00e4sst sich sowohl unter Debian 6 als auch unter Ubuntu 19.04 gleich gut installieren und verwenden. Die Standards f\u00fcr den Aufbau von Paketen und deren Handhabung, die in alten Debian-Distributionen festgelegt wurden, sind auch in den modernen Distributionen wie Linux Mint und elementary OS weiterhin relevant. Daher gen\u00fcgt f\u00fcr Veeam Agent for Linux ein deb-Paket f\u00fcr jede Hardwareplattform.<\/p>\n<p>In der Welt der rpm-Pakete hingegen gibt es gro\u00dfe Unterschiede. Erstens, weil es zwei v\u00f6llig unabh\u00e4ngige Distributor wie Red Hat und SUSE gibt, bei denen Kompatibilit\u00e4t keine Rolle spielt. Zweitens haben diese Distributoren Distributionen mit technischer Unterst\u00fctzung und experimentellen Versionen. Auch zwischen diesen besteht keine Notwendigkeit zur Kompatibilit\u00e4t. So haben wir separate Pakete f\u00fcr el6, el7 und el8. Ein separates Paket f\u00fcr Fedora. Pakete f\u00fcr SLES11 und 12 sowie ein separates f\u00fcr openSUSE. Das Hauptproblem liegt in den Abh\u00e4ngigkeiten und den Paketnamen. <\/p>\n<h2>Das Problem der Abh\u00e4ngigkeiten<\/h2>\n<p>\nLeider erscheinen die gleichen Pakete h\u00e4ufig unter unterschiedlichen Namen in verschiedenen Distributionen. Nachfolgend eine unvollst\u00e4ndige Liste der Abh\u00e4ngigkeiten des Pakets veeam.<\/p>\n<p>F\u00fcr EL7:<br \/>\nF\u00fcr 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>\nInfolgedessen ist die Liste der Abh\u00e4ngigkeiten einzigartig f\u00fcr die Distribution. <\/p>\n<p>Es wird problematisch, wenn sich unter dem alten Paketnamen eine neue Version verbirgt. <\/p>\n<p><b>Beispiel:<\/b><\/p>\n<p>In Fedora 24 wurde das Paket <i>ncurses<\/i> von Version 5 auf Version 6 aktualisiert. Unser Produkt wurde speziell mit Version 5 entwickelt, um die Kompatibilit\u00e4t mit \u00e4lteren Distributionen zu gew\u00e4hrleisten. Um die alte Version 5 der Bibliothek unter Fedora 24 zu verwenden, musste das Paket <i>ncurses-compat-libs<\/i>. <\/p>\n<p>Infolgedessen gibt es f\u00fcr Fedora zwei Pakete mit unterschiedlichen Abh\u00e4ngigkeiten. <\/p>\n<p>Es wird interessanter. Nach einem weiteren Update der Distribution ist das Paket <i>ncurses-compat-libs<\/i> mit der Version 5 der Bibliothek nicht mehr verf\u00fcgbar. F\u00fcr den Distributor ist es aufwendig, alte Bibliotheken in die neue Version der Distribution zu integrieren. Nach einer gewissen Zeit trat das Problem auch in den SUSE-Distributionen auf.<\/p>\n<p>Infolgedessen mussten einige Distributionen auf eine explizite Abh\u00e4ngigkeit von <i>ncurses-libs<\/i>, verzichten, und das Produkt wurde so angepasst, dass es mit jeder Version der Bibliothek arbeiten kann.<\/p>\n<p>\u00dcbrigens gibt es in der 8. Version von Red Hat kein Metapakets mehr, <i>python<\/i>, das auf das alte Gute verlinkte. <i>python 2.7<\/i>. Es gibt <i>python2<\/i> und <i>python<\/i>3. <\/p>\n<h2>Alternative zu Paketmanagern<\/h2>\n<p>\nDas Problem mit Abh\u00e4ngigkeiten ist alt und schon lange offensichtlich. Man denke nur an das Dependency-Hell. <br \/>\nVerschiedene Bibliotheken und Anwendungen so zu kombinieren, dass sie stabil funktionieren und nicht in Konflikt geraten, ist genau die Aufgabe, die jeder Linux-Distributor versucht zu l\u00f6sen.<\/p>\n<p>Ein ganz anderes Problem versucht der Paketmanager <b>Snappy<\/b> von Canonical zu l\u00f6sen. Die Grundidee ist: Die Anwendung l\u00e4uft in einer isolierten und vor dem Hauptsystem gesch\u00fctzten Sandbox. Wenn die Anwendung Bibliotheken ben\u00f6tigt, werden diese zusammen mit der Anwendung bereitgestellt.<\/p>\n<p><b>Flatpak<\/b> l\u00e4sst ebenfalls Anwendungen in einer Sandbox laufen, die Linux-Container verwendet. Die Idee der Sandbox wird auch genutzt von <b>AppImage<\/b>.<\/p>\n<p>Diese L\u00f6sungen erm\u00f6glichen es, ein Paket f\u00fcr jede Distribution zu erstellen. Im Fall von <b>Flatpak<\/b> ist die Installation und Ausf\u00fchrung der Anwendung sogar ohne Wissen des Administrators m\u00f6glich.<\/p>\n<p>Das Hauptproblem dabei ist, dass nicht alle Anwendungen in einer Sandbox funktionieren k\u00f6nnen. Einige ben\u00f6tigen direkten Zugriff auf die Plattform. Ich spreche erst gar nicht von Kernelmodulen, die stark vom Kernel abh\u00e4ngen und sich nicht in das Konzept der Sandbox einf\u00fcgen. <\/p>\n<p>Ein zweites Problem ist, dass die in der Enterprise-Umgebung beliebten Distributionen von Red Hat und SUSE noch keine Unterst\u00fctzung f\u00fcr Snappy und Flatpak enthalten. <\/p>\n<p>Daher gibt es Veeam Agent for Linux nicht auf <noindex><a rel=\"nofollow\" href=\"https:\/\/snapcraft.io\/\">snapcraft.io<\/a><\/noindex> noch auf <noindex><a rel=\"nofollow\" href=\"https:\/\/flathub.org\/home\">flathub.org<\/a><\/noindex>.<\/p>\n<p>Abschlie\u00dfend m\u00f6chte ich zum Thema Paketmanager anmerken, dass es die M\u00f6glichkeit gibt, ganz auf Paketmanager zu verzichten, indem bin\u00e4re Dateien und ein Installationsskript in ein Einzelpaket geb\u00fcndelt werden. <\/p>\n<p>Ein solches Bundle erm\u00f6glicht die Erstellung eines gemeinsamen Pakets f\u00fcr verschiedene Distributionen und Plattformen, f\u00fchrt einen interaktiven Installationsprozess durch und erm\u00f6glicht die notwendige Anpassung. Ich habe solche Pakete f\u00fcr Linux nur von VMware gesehen.<\/p>\n<h2>Das Problem der Updates<\/h2>\n<p>\n<img decoding=\"async\" alt=\"Linux vielf\u00e4ltig: So arbeiten Sie mit jeder Distribution\" src=\"\/wp-content\/uploads\/2019\/10\/aa14b10a434c28541574421d97807de7.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nSelbst wenn alle Abh\u00e4ngigkeitsprobleme gel\u00f6st sind, kann das Programm auf derselben Distribution unterschiedlich funktionieren. Das liegt an den Updates.<\/p>\n<p>Es gibt 3 Update-Strategien:<\/p>\n<ul>\n<li>Die einfachste ist, niemals zu aktualisieren. Den Server eingerichtet und vergessen. Warum Updates, wenn alles funktioniert? Die Probleme beginnen beim ersten Anruf beim Support. Der Ersteller der Distribution unterst\u00fctzt nur die aktualisierte Version. <\/li>\n<li>Man kann dem Distributor vertrauen und die automatische Aktualisierung aktivieren. In diesem Fall ist ein Anruf beim Support wahrscheinlich direkt nach einem misslungenen Update.<\/li>\n<li>Die Variante, manuell erst nach Testlauf auf einer Testinfrastruktur zu aktualisieren, ist die sicherste, aber auch die teuerste und aufwendigste. Nicht jeder kann sich das leisten.<\/li>\n<\/ul>\n<p>\nDa verschiedene Benutzer unterschiedliche Update-Strategien anwenden, muss sowohl die neueste Version als auch alle zuvor ver\u00f6ffentlichten unterst\u00fctzt werden. Das kompliziert sowohl den Entwicklungsprozess als auch den Testprozess und bringt den Support in Schwierigkeiten.<\/p>\n<h2>Vielfalt der Hardware-Plattformen<\/h2>\n<p>\nVerschiedene Hardware-Plattformen sind ein Problem, das haupts\u00e4chlich spezifisch f\u00fcr nativen Code ist. Mindestens m\u00fcssen Bin\u00e4rdateien f\u00fcr jede unterst\u00fctzte Plattform erstellt werden.<\/p>\n<p>Im Projekt Veeam Agent for Linux k\u00f6nnen wir einfach nichts RISC-\u00e4hnliches unterst\u00fctzen.<\/p>\n<p>Ich werde nicht ausf\u00fchrlich auf dieses Thema eingehen. Ich m\u00f6chte nur die Hauptprobleme anrei\u00dfen: plattformabh\u00e4ngige Typen wie <code>size_t<\/code>, Datenstruktur-Ausrichtung und Byte-Reihenfolge.<\/p>\n<h2>Statische und\/oder dynamische Verlinkung<\/h2>\n<p>\n<img decoding=\"async\" alt=\"Linux vielf\u00e4ltig: So arbeiten Sie mit jeder Distribution\" src=\"\/wp-content\/uploads\/2019\/10\/dc473aad4ea0818940af7eafdbc641fd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nDie Frage \"Wie soll ich mit Bibliotheken verlinken \u2014 dynamisch oder statisch?\" sollten wir besprechen.<\/p>\n<p>In der Regel verwenden C\/C++-Anwendungen unter Linux dynamisches Linking. Das funktioniert gut, wenn die Anwendung speziell f\u00fcr eine bestimmte Distribution erstellt wurde.<\/p>\n<p>Steht jedoch die Aufgabe an, verschiedene Distributionen mit einer einzigen Bin\u00e4rdatei abzudecken, muss man sich an die \u00e4lteste unterst\u00fctzte Distribution orientieren. F\u00fcr uns ist das Red Hat 6. Es enth\u00e4lt gcc 4.4, das nicht einmal den Standard C++11 vollst\u00e4ndig unterst\u00fctzt. <noindex><a rel=\"nofollow\" href=\"https:\/\/gcc.gnu.org\/projects\/cxx-status.html\">vollst\u00e4ndig<\/a><\/noindex>.<\/p>\n<p>Wir bauen unser Projekt mit gcc 6.3, der C++14 vollst\u00e4ndig unterst\u00fctzt. In diesem Fall m\u00fcssen wir die Bibliotheken libstdc++ und boost f\u00fcr Red Hat 6 mitbringen. Am einfachsten ist es, statisch mit diesen zu linken.<\/p>\n<p>Leider kann nicht mit allen Bibliotheken statisch gelinkt werden.<\/p>\n<p>Erstens m\u00fcssen Systembibliotheken wie <i>libfuse<\/i>, <i>libblkid<\/i> dynamisch gelinkt werden, um sicherzustellen, dass sie mit dem Kernel und seinen Modulen kompatibel sind. <\/p>\n<p>Zweitens gibt es Feinheiten bei den Lizenzen. <\/p>\n<p>Die GPL-Lizenz erlaubt grunds\u00e4tzlich das Linken von Bibliotheken nur mit Open-Source-Code. MIT und BSD erlauben statisches Linking und erlauben das Einf\u00fcgen von Bibliotheken in Projekte. Die LGPL scheint statisches Linking nicht zu widersprechen, verlangt aber, dass die f\u00fcr das Linking ben\u00f6tigten Dateien \u00f6ffentlich zug\u00e4nglich gemacht werden. <\/p>\n<p>Im Allgemeinen sch\u00fctzt die Verwendung von dynamischem Linking davor, etwas zur Verf\u00fcgung stellen zu m\u00fcssen.<\/p>\n<h2>Build von C\/C++-Anwendungen<\/h2>\n<p>\nUm C\/C++-Anwendungen f\u00fcr verschiedene Plattformen und Distributionen zu erstellen, reicht es aus, einen geeignetengcc zu w\u00e4hlen oder zu bauen und Cross-Compiler f\u00fcr spezifische Architekturen zu verwenden sowie das gesamte Set an Bibliotheken zu erstellen. Diese Arbeit ist durchaus umsetzbar, aber recht aufw\u00e4ndig. Und es gibt keine Garantie, dass der gew\u00e4hlte Compiler und die Bibliotheken eine funktionsf\u00e4hige Variante erm\u00f6glichen. <\/p>\n<p>Ein offensichtlicher Vorteil: Die Infrastruktur wird erheblich vereinfacht, da der gesamte Build-Prozess auf einem einzigen Rechner durchgef\u00fchrt werden kann. Au\u00dferdem ist es ausreichend, ein Set von Bin\u00e4rdateien f\u00fcr eine Architektur zu erstellen, und diese k\u00f6nnen in Pakete f\u00fcr verschiedene Distributionen verpackt werden. So werden die Pakete von Veeam f\u00fcr den Veeam Agent f\u00fcr Linux erstellt.<\/p>\n<p>Im Gegensatz zu dieser Variante kann man einfach eine Build-Farm einrichten, das hei\u00dft mehrere Maschinen f\u00fcr den Aufbau. Jede dieser Maschinen sorgt f\u00fcr die Kompilierung der Anwendung und den Build eines Pakets f\u00fcr eine bestimmte Distribution und Architektur. In diesem Fall erfolgt die Kompilierung mit den Mitteln, die der Distributor vorbereitet hat. Das bedeutet, dass die Phasen der Vorbereitung des Compilers und der Auswahl von Bibliotheken entfallen. Dar\u00fcber hinaus kann der Build-Prozess leicht parallelisiert werden. <\/p>\n<p>Es gibt jedoch auch einen Nachteil dieses Ansatzes: F\u00fcr jede Distribution innerhalb einer Architektur m\u00fcssen eigene Bin\u00e4rdateien erstellt werden. Ein weiterer Nachteil ist, dass eine solche Vielzahl von Maschinen verwaltet werden muss, was viel Speicherplatz und RAM ben\u00f6tigt. <\/p>\n<p>So werden KMOD-Pakete des Kernel-Moduls veeamsnap f\u00fcr Red Hat-Distributionen erstellt.<\/p>\n<h2>Open Build Service<\/h2>\n<p>\nDie Kollegen von SUSE haben versucht, einen goldenen Mittelweg in Form eines speziellen Dienstes f\u00fcr die Kompilierung von Anwendungen und den Build von Paketen zu realisieren \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/openbuildservice.org\/\">openbuildservice<\/a><\/noindex>.<\/p>\n<p>Im Grunde genommen handelt es sich um einen Hypervisor, der eine virtuelle Maschine erstellt, in der alle ben\u00f6tigten Pakete installiert werden, die Anwendung kompiliert und das Paket in dieser isolierten Umgebung erstellt wird, bevor die virtuelle Maschine wieder freigegeben wird.<\/p>\n<p><img decoding=\"async\" alt=\"Linux vielf\u00e4ltig: So arbeiten Sie mit jeder Distribution\" src=\"\/wp-content\/uploads\/2019\/10\/93d2a70c589a7186ecef85a7863e59e8.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDer im OpenBuildService implementierte Scheduler bestimmt selbst, wie viele virtuelle Maschinen er f\u00fcr die optimale Build-Geschwindigkeit starten kann. Der integrierte Signaturmechanismus unterzeichnet die Pakete automatisch und l\u00e4dt sie in das integrierte Repository hoch. Das eingebaute Versionsverwaltungssystem speichert die Historie der \u00c4nderungen und Builds. Es bleibt nur noch, die eigenen Quellcodes in dieses System einzuf\u00fcgen. Einen Server muss man nicht unbedingt selbst aufsetzen, man kann auch den Open Service nutzen.<\/p>\n<p>Hier gibt es allerdings ein Problem: Eine solche L\u00f6sung l\u00e4sst sich schwer in die bestehende Infrastruktur integrieren. Zum Beispiel ist keine Versionskontrolle erforderlich, da wir bereits eine f\u00fcr die Quellcodes haben. Der Signaturmechanismus unterscheidet sich: es wird ein spezieller Server verwendet. Ein Repository ist ebenfalls nicht notwendig. <\/p>\n<p>Dar\u00fcber hinaus ist die Unterst\u00fctzung anderer Distributionen \u2014 wie Red Hat \u2014 recht sp\u00e4rlich umgesetzt, was durchaus nachvollziehbar ist.<\/p>\n<p>Ein Vorteil eines solchen Services ist der schnelle Support der n\u00e4chsten Version des SUSE-Distributions. Vor der offiziellen Ank\u00fcndigung des Releases werden die ben\u00f6tigten Pakete f\u00fcr den Build in ein \u00f6ffentliches Repository hochgeladen. In der Liste der verf\u00fcgbaren Distributionen im OpenBuildService erscheint eine neue Version. Wir setzen das H\u00e4kchen, und sie wird zum Build-Plan hinzugef\u00fcgt. So erfolgt die Hinzuf\u00fcgung einer neuen Version der Distribution praktisch mit einem Klick.<\/p>\n<p>In unserer Infrastruktur wird mit OpenBuildService eine Vielzahl von KMP-Paketen des veeamsnap-Kernelmoduls f\u00fcr SUSE-Distributionen erstellt.<\/p>\n<p>Als N\u00e4chstes m\u00f6chte ich mich mit spezifischen Fragen zu Kernelmodulen befassen.<\/p>\n<h2>kernel ABI<\/h2>\n<p>\nLinux-Kernelmodule wurden historisch in Form von Quellcodes verteilt. Der Grund daf\u00fcr ist, dass die Kernelentwickler sich nicht darum k\u00fcmmern, ein stabiles API f\u00fcr Kernelmodule zu unterst\u00fctzen, geschweige denn auf bin\u00e4rer Ebene, auch kABI genannt.<\/p>\n<p>Um ein Modul f\u00fcr den Vanilla-Kernel zu bauen, sind die Header genau dieses Kernels notwendig, und es wird nur auf diesem Kernel funktionieren. <\/p>\n<p>DKMS erm\u00f6glicht die Automatisierung des Build-Prozesses von Modulen bei Kernel-Updates. Infolgedessen verwenden Nutzer des Debian-Repositories (und seiner zahlreichen Verwandten) entweder Kernelmodule aus dem Distributionsrepository oder solche, die mit DKMS aus den Quellen erstellt wurden.<\/p>\n<p>Diese Situation entspricht dem Enterprise-Segment jedoch nicht besonders. Anbieter propriet\u00e4rer Software m\u00f6chten ihre Produkte in Form von kompilierten Bin\u00e4rdateien vertreiben. <\/p>\n<p>Administratoren m\u00f6chten aus Sicherheitsgr\u00fcnden keine Entwicklungstools auf Produktionsservern behalten. Distributoren von Enterprise Linux \u2013 wie Red Hat und SUSE \u2013 haben entschieden, dass sie ihren Nutzern eine stabile kABI bieten k\u00f6nnen. Infolgedessen sind KMOD-Pakete f\u00fcr Red Hat und KMP-Pakete f\u00fcr SUSE entstanden.<\/p>\n<p>Das Wesen dieser L\u00f6sung ist ziemlich einfach. F\u00fcr eine bestimmte Version der Distribution wird die API des Kernels eingefroren. Der Distributor erkl\u00e4rt, dass er z.B. den Kernel 3.10 verwendet und nur Korrekturen und Verbesserungen vornimmt, die die Kernel-Schnittstellen nicht ber\u00fchren. Die f\u00fcr den allerersten Kernel erstellten Module k\u00f6nnen ohne Neukompilierung f\u00fcr alle nachfolgenden verwendet werden.<\/p>\n<p>Red Hat erkl\u00e4rt, dass die kABI-Kompatibilit\u00e4t f\u00fcr das Betriebssystem w\u00e4hrend des gesamten Lebenszyklus gew\u00e4hrleistet ist. Das bedeutet, dass ein f\u00fcr RHEL 6.0 (Release November 2010) erstelltes Modul auch auf der Version 6.10 (Release Juni 2018) funktionieren sollte. Das sind fast 8 Jahre. Nat\u00fcrlich ist diese Aufgabe ziemlich komplex. <br \/>\nWir haben mehrere F\u00e4lle festgestellt, in denen das Modul veeamsnap aufgrund von Problemen mit der kABI-Kompatibilit\u00e4t nicht mehr funktionierte. <\/p>\n<p>Nachdem das f\u00fcr RHEL 7.0 erstellte Modul veeamsnap mit dem Kernel von RHEL 7.5 inkompatibel war, aber dennoch geladen wurde und garantiert den Server zum Absturz brachte, haben wir die kABI-Kompatibilit\u00e4t f\u00fcr RHEL 7 vollst\u00e4ndig aufgegeben. <\/p>\n<p>Derzeit enth\u00e4lt das KMOD-Paket f\u00fcr RHEL 7 eine Version f\u00fcr jede Release-Version und ein Skript, das das Laden des Moduls sicherstellt.<\/p>\n<p>SUSE ist bei der kABI-Kompatibilit\u00e4t vorsichtiger. Sie garantieren die kABI-Kompatibilit\u00e4t nur innerhalb eines Service Packs. <\/p>\n<p>Beispielsweise wurde SLES 12 im September 2014 ver\u00f6ffentlicht. SLES 12 SP1 folgte bereits im Dezember 2015, also nach etwas mehr als einem Jahr. Obwohl beide Releases den Kernel 3.12 verwenden, sind sie kABI-inkompatibel. Offensichtlich ist es erheblich einfacher, eine kABI-Kompatibilit\u00e4t nur \u00fcber ein Jahr aufrechtzuerhalten. Ein j\u00e4hrlicher Zyklus f\u00fcr Kernel-Updates sollte keine Probleme f\u00fcr Modulautoren verursachen. <\/p>\n<p>Dank dieser Politik von SUSE haben wir bei unserem Modul veeamsnap kein einziges Problem mit der kABI-Kompatibilit\u00e4t festgestellt. Allerdings ist die Anzahl der Pakete f\u00fcr SUSE fast um den Faktor zehn h\u00f6her.<\/p>\n<h2>Patches und Backports<\/h2>\n<p>\nObwohl die Distributorinnen und Distributoren bem\u00fcht sind, die kABI-Kompatibilit\u00e4t und die Stabilit\u00e4t des Kernels zu gew\u00e4hrleisten, arbeiten sie auch daran, die Leistung zu verbessern und Fehler in diesem stabilen Kernel zu beheben. <\/p>\n<p>Dabei verfolgen die Entwickelnden des Enterprise Linux-Kernels neben ihren eigenen \u201eFehlerbereinigungen\u201c auch die \u00c4nderungen im Vanilla-Kernel und \u00fcbertragen diese in ihre \u201estabilisierte\u201c Version.<\/p>\n<p>Manchmal f\u00fchrt das zu neuen <noindex><a rel=\"nofollow\" href=\"https:\/\/access.redhat.com\/solutions\/3658111\">Fehlern<\/a><\/noindex>.<\/p>\n<p>Im letzten Release von Red Hat 6 gab es in einem der kleineren Updates einen Fehler. Dieser f\u00fchrte dazu, dass das Modul veeamsnap das System beim Freigeben eines Snapshots garantiert abst\u00fcrzen lie\u00df. Durch den Vergleich der Kernel-Quellcodes vor und nach dem Update haben wir festgestellt, dass das Problem durch einen Backport verursacht wurde. Ein \u00e4hnlicher Fix wurde im Vanilla-Kernel der Version 4.19 umgesetzt. Allerdings funktionierte dieser Fix im Vanilla-Kernel einwandfrei, w\u00e4hrend bei der \u00dcbertragung in das \u201estabilisierte\u201c 2.6.32 Probleme mit Spin-Lock auftraten.<\/p>\n<p>Nat\u00fcrlich kommen Fehler bei jedem vor, aber war es wirklich n\u00f6tig, den Code von 4.19 auf 2.6.32 zu ziehen und dabei die Stabilit\u00e4t zu riskieren? Ich bin mir nicht sicher\u2026<\/p>\n<p>Am \u00e4rgerlichsten ist es, wenn Marketing in das Tauziehen zwischen \u201eStabilit\u00e4t\u201c  \u201eModernisierung\u201c eingreift. Die Marketingabteilung ben\u00f6tigt ein stabiles Kernsystem des aktualisierten Distributionspakets, andererseits sollte es auch in der Leistung besser sein und neue Funktionen haben. Das f\u00fchrt zu seltsamen Kompromissen. <\/p>\n<p>Als ich versuchte, ein Modul mit dem Kernel 4.4 von SLES 12 SP3 zu kompilierten, stellte ich mit \u00dcberraschung fest, dass es Funktionen aus dem Vanilla 4.8 enth\u00e4lt. Meiner Meinung nach \u00e4hnelt die Implementierung der Block-I\/O-Funktionalit\u00e4t des Kernels 4.4 von SLES 12 SP3 mehr dem Kernel 4.8 als der vorherigen stabilen Version 4.4 von SLES 12 SP2. Ich kann nicht beurteilen, wie viel Code von Kernel 4.8 in den SLES 4.4 f\u00fcr SP3 \u00fcbertragen wurde, allerdings kann ich es mit gutem Gewissen nicht mehr als den stabilen 4.4 betiteln. <\/p>\n<p>Das Unangenehmste daran ist, dass man beim Schreiben eines Moduls, das auf verschiedenen Kernen gleich gut funktioniert, nicht mehr auf die Kernelversion vertrauen kann. Man muss auch die Distribution ber\u00fccksichtigen. Gut ist, dass man manchmal auf ein Define zur\u00fcckgreifen kann, das mit neuen Funktionen eingef\u00fchrt wird, aber diese M\u00f6glichkeit ist nicht immer gegeben. <\/p>\n<p>In der Folge wird der Code mit kuriosen Direktiven f\u00fcr die bedingte Kompilierung angereichert.<\/p>\n<p>Es gibt auch Patches, die die dokumentierte API des Kernels \u00e4ndern. <br \/>\nIch stie\u00df auf die Distribution <noindex><a rel=\"nofollow\" href=\"https:\/\/neon.kde.org\/\">KDE neon<\/a><\/noindex> 5.16 und war sehr \u00fcberrascht, dass der Aufruf von lookup_bdev in dieser Kernel-Version die Liste der Eingabeparameter ge\u00e4ndert hat.<\/p>\n<p>Um das Ganze zu kompilieren, musste ich ein Skript in die Makefile einf\u00fcgen, das \u00fcberpr\u00fcft, ob der Parameter mask f\u00fcr die Funktion lookup_bdev vorhanden ist.<\/p>\n<h2>Signatur der Kernelmodule<\/h2>\n<p>\nAber kommen wir zur\u00fcck zur Frage der Paketverteilung.<\/p>\n<p>Einer der Vorteile des stabilen kABI ist, dass Kernelmodule als Bin\u00e4rdatei signiert werden k\u00f6nnen. In diesem Fall kann der Entwickler sicher sein, dass das Modul nicht versehentlich besch\u00e4digt oder absichtlich ver\u00e4ndert wurde. Dies kann mit dem Befehl modinfo \u00fcberpr\u00fcft werden. <\/p>\n<p>Die Red Hat- und SUSE-Distributionen erm\u00f6glichen die \u00dcberpr\u00fcfung der Modulsignatur und laden es nur, wenn das entsprechende Zertifikat im System registriert ist. Das Zertifikat ist der \u00f6ffentliche Schl\u00fcssel, mit dem das Modul signiert wird. Wir verteilen es in Form eines separaten Pakets.<\/p>\n<p>Das Problem hierbei ist, dass die Zertifikate entweder im Kernel integriert sind (die von den Distributionen verwendet werden) oder in den nichtfl\u00fcchtigen EFI-Speicher mit Hilfe eines Tools geschrieben werden m\u00fcssen. <i>mokutil<\/i>. Das Tool <i>mokutil<\/i> bei der Installation des Zertifikats erfordert einen Neustart des Systems und bietet dem Administrator noch vor dem Laden des Betriebssystemkernels an, das Laden des neuen Zertifikats zu genehmigen. <\/p>\n<p>Daher erfordert das Hinzuf\u00fcgen eines Zertifikats physischen Zugriff des Administrators auf das System. Wenn sich die Maschine irgendwo in der Cloud oder einfach auf einem Remote-Server befindet und der Zugang nur \u00fcber das Netzwerk (zum Beispiel \u00fcber ssh) m\u00f6glich ist, wird es unm\u00f6glich sein, ein Zertifikat hinzuzuf\u00fcgen. <\/p>\n<h2>EFI auf virtuellen Maschinen<\/h2>\n<p>\nObwohl EFI schon lange von fast allen Herstellern von Motherboards unterst\u00fctzt wird, kann der Administrator bei der Installation des Systems nicht an die Notwendigkeit von EFI denken, und es k\u00f6nnte deaktiviert sein. <\/p>\n<p>Nicht alle Hypervisoren unterst\u00fctzen EFI. VMWare vSphere unterst\u00fctzt EFI ab Version 5. <br \/>\nMicrosoft Hyper-V hat ebenfalls die Unterst\u00fctzung von EFI erhalten, beginnend mit Hyper-V f\u00fcr Windows Server 2012R2. <\/p>\n<p>Allerdings ist dieser Funktionsumfang in der Standardkonfiguration f\u00fcr Linux-Maschinen deaktiviert, was bedeutet, dass ein Zertifikat nicht installiert werden kann. <\/p>\n<p>In vSphere 6.5 kann die Option <b>Secure Boot<\/b> nur in der alten Version des Web-Interfaces, die \u00fcber Flash funktioniert, gesetzt werden. Das Web-UI auf HTML-5 hinkt momentan stark hinterher.<\/p>\n<h2>Experimentelle Distributionen<\/h2>\n<p>\nZum Schluss betrachten wir die Frage der experimentellen Distributionen und der Distributionen ohne offizielle Unterst\u00fctzung. Einerseits wird man solche Distributionen wahrscheinlich auf Servern ernsthafter Organisationen nicht antreffen. Solche Distributionen haben keine offizielle Unterst\u00fctzung. Daher kann man auch keinen technischen Support f\u00fcr Produkte auf solchen Distributionen bieten. <\/p>\n<p>Jedoch werden solche Distributionen zu einer geeigneten Plattform, um neue experimentelle L\u00f6sungen auszuprobieren. Zum Beispiel Fedora, OpenSUSE Tumbleweed oder unstable Versionen von Debian. Sie sind ziemlich stabil. Es gibt immer neue Programmversionen und immer einen neuen Kernel. Nach einem Jahr k\u00f6nnte diese experimentelle Funktionalit\u00e4t in die aktualisierte Version von RHEL, SLES oder Ubuntu integriert werden. <\/p>\n<p>Wenn also etwas auf einer experimentellen Distribution nicht funktioniert, ist das ein Grund, sich mit dem Problem zu befassen und es zu l\u00f6sen. Man muss darauf vorbereitet sein, dass diese Funktionalit\u00e4t bald auf den Produktionsservern der Benutzer verf\u00fcgbar sein wird.<\/p>\n<p>Die derzeit offiziell unterst\u00fctzten Distributionen f\u00fcr Version 3.0 k\u00f6nnen Sie einsehen. <noindex><a rel=\"nofollow\" href=\"https:\/\/helpcenter.veeam.com\/docs\/agentforlinux\/userguide\/system_requirements.html?ver=30\">hier<\/a><\/noindex>Das tats\u00e4chliche Spektrum der Distributionen, auf denen unser Produkt funktioniert, ist jedoch deutlich breiter.<\/p>\n<p>Pers\u00f6nlich interessierte mich das Experiment mit dem Betriebssystem \u201eElbrus\u201c. Nach der Optimierung des Veeam-Pakets lie\u00df sich unser Produkt installieren und funktionierte einwandfrei. \u00dcber dieses Experiment habe ich auf Habr geschrieben unter <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/veeam\/blog\/447960\/\">Artikel<\/a><\/noindex>. <\/p>\n<p>Die Unterst\u00fctzung neuer Distributionen wird fortgesetzt. Wir erwarten bald die Ver\u00f6ffentlichung von Version 4.0. Eine Beta sollte bald verf\u00fcgbar sein, also bleiben Sie auf dem Laufenden \u00fcber <noindex><a rel=\"nofollow\" href=\"https:\/\/www.veeam.com\/whats-new-linux-agent.html\">whats-new<\/a><\/noindex>!<br \/>\n<br \/>Quelle: <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.1.1 - 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\/de\/blog\/administrirovanie\/linux-mnogolikij-kak-rabotat-na-lyubom-distributive\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"de_DE\" \/>\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\/de\/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 ist vielf\u00e4ltig: So arbeiten Sie mit jeder Distribution | ProHoster","description":"Erstellen Sie eine Anwendung zur Sicherung.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/linux-mnogolikij-kak-rabotat-na-lyubom-distributive","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","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\/de\/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\/de\/wp-json\/wp\/v2\/posts\/38929","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=38929"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/38929\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/29206"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=38929"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=38929"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=38929"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}