Linux vielfältig: So arbeiten Sie mit jeder Distribution

Eine Anwendung für 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üssen eine Reihe von Problemen gelöst werden, insbesondere wenn man bedenkt, dass das Softwareprodukt ein Kernelmodul umfasst.

Der Artikel wurde auf Grundlage eines Vortrags auf der Konferenz LinuxPiter 2019.

Linux 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üssen die Besonderheiten jeder einzelnen beachtet werden.

Paketmanager. .deb vs .rpm

Beginnen wir mit dem offensichtlichen Problem der Verbreitung des Produkts für verschiedene Distributionen.
Die typischste Methode, Softwareprodukte zu verteilen, besteht darin, ein Paket in ein Repository hochzuladen, damit der im System integrierte Paketmanager es von dort installieren kann.
Es gibt jedoch zwei beliebte Paketformate: rpm und deb. Das bedeutet, dass wir jedes unterstützen müssen.

In der Welt der deb-Pakete ist das Kompatibilitätsniveau erstaunlich. Dasselbe Paket lässt sich sowohl unter Debian 6 als auch unter Ubuntu 19.04 gleich gut installieren und verwenden. Die Standards für 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ügt für Veeam Agent for Linux ein deb-Paket für jede Hardwareplattform.

In der Welt der rpm-Pakete hingegen gibt es große Unterschiede. Erstens, weil es zwei völlig unabhängige Distributor wie Red Hat und SUSE gibt, bei denen Kompatibilität keine Rolle spielt. Zweitens haben diese Distributoren Distributionen mit technischer Unterstützung und experimentellen Versionen. Auch zwischen diesen besteht keine Notwendigkeit zur Kompatibilität. So haben wir separate Pakete für el6, el7 und el8. Ein separates Paket für Fedora. Pakete für SLES11 und 12 sowie ein separates für openSUSE. Das Hauptproblem liegt in den Abhängigkeiten und den Paketnamen.

Das Problem der Abhängigkeiten

Leider erscheinen die gleichen Pakete häufig unter unterschiedlichen Namen in verschiedenen Distributionen. Nachfolgend eine unvollständige Liste der Abhängigkeiten des Pakets veeam.

Für EL7:
Für SLES 12:

• libblkid
• libgcc
• libstdc++
• ncurses-libs
• fuse-libs
• file-libs
• veeamsnap = 3.0.2.1185

• libblkid1
• libgcc_s1
• libstdc++6
• libmagic1
• libfuse2
• veeamsnap-kmp = 3.0.2.1185

Infolgedessen ist die Liste der Abhängigkeiten einzigartig für die Distribution.

Es wird problematisch, wenn sich unter dem alten Paketnamen eine neue Version verbirgt.

Beispiel:

In Fedora 24 wurde das Paket ncurses von Version 5 auf Version 6 aktualisiert. Unser Produkt wurde speziell mit Version 5 entwickelt, um die Kompatibilität mit älteren Distributionen zu gewährleisten. Um die alte Version 5 der Bibliothek unter Fedora 24 zu verwenden, musste das Paket ncurses-compat-libs.

Infolgedessen gibt es für Fedora zwei Pakete mit unterschiedlichen Abhängigkeiten.

Es wird interessanter. Nach einem weiteren Update der Distribution ist das Paket ncurses-compat-libs mit der Version 5 der Bibliothek nicht mehr verfügbar. Für 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.

Infolgedessen mussten einige Distributionen auf eine explizite Abhängigkeit von ncurses-libs, verzichten, und das Produkt wurde so angepasst, dass es mit jeder Version der Bibliothek arbeiten kann.

Übrigens gibt es in der 8. Version von Red Hat kein Metapakets mehr, python, das auf das alte Gute verlinkte. python 2.7. Es gibt python2 und python3.

Alternative zu Paketmanagern

Das Problem mit Abhängigkeiten ist alt und schon lange offensichtlich. Man denke nur an das Dependency-Hell.
Verschiedene 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ösen.

Ein ganz anderes Problem versucht der Paketmanager Snappy von Canonical zu lösen. Die Grundidee ist: Die Anwendung läuft in einer isolierten und vor dem Hauptsystem geschützten Sandbox. Wenn die Anwendung Bibliotheken benötigt, werden diese zusammen mit der Anwendung bereitgestellt.

Flatpak lässt ebenfalls Anwendungen in einer Sandbox laufen, die Linux-Container verwendet. Die Idee der Sandbox wird auch genutzt von AppImage.

Diese Lösungen ermöglichen es, ein Paket für jede Distribution zu erstellen. Im Fall von Flatpak ist die Installation und Ausführung der Anwendung sogar ohne Wissen des Administrators möglich.

Das Hauptproblem dabei ist, dass nicht alle Anwendungen in einer Sandbox funktionieren können. Einige benötigen direkten Zugriff auf die Plattform. Ich spreche erst gar nicht von Kernelmodulen, die stark vom Kernel abhängen und sich nicht in das Konzept der Sandbox einfügen.

Ein zweites Problem ist, dass die in der Enterprise-Umgebung beliebten Distributionen von Red Hat und SUSE noch keine Unterstützung für Snappy und Flatpak enthalten.

Daher gibt es Veeam Agent for Linux nicht auf snapcraft.io noch auf flathub.org.

Abschließend möchte ich zum Thema Paketmanager anmerken, dass es die Möglichkeit gibt, ganz auf Paketmanager zu verzichten, indem binäre Dateien und ein Installationsskript in ein Einzelpaket gebündelt werden.

Ein solches Bundle ermöglicht die Erstellung eines gemeinsamen Pakets für verschiedene Distributionen und Plattformen, führt einen interaktiven Installationsprozess durch und ermöglicht die notwendige Anpassung. Ich habe solche Pakete für Linux nur von VMware gesehen.

Das Problem der Updates

Selbst wenn alle Abhängigkeitsprobleme gelöst sind, kann das Programm auf derselben Distribution unterschiedlich funktionieren. Das liegt an den Updates.

Es gibt 3 Update-Strategien:

• 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ützt nur die aktualisierte Version.
• Man kann dem Distributor vertrauen und die automatische Aktualisierung aktivieren. In diesem Fall ist ein Anruf beim Support wahrscheinlich direkt nach einem misslungenen Update.
• 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.

Da verschiedene Benutzer unterschiedliche Update-Strategien anwenden, muss sowohl die neueste Version als auch alle zuvor veröffentlichten unterstützt werden. Das kompliziert sowohl den Entwicklungsprozess als auch den Testprozess und bringt den Support in Schwierigkeiten.

Vielfalt der Hardware-Plattformen

Verschiedene Hardware-Plattformen sind ein Problem, das hauptsächlich spezifisch für nativen Code ist. Mindestens müssen Binärdateien für jede unterstützte Plattform erstellt werden.

Im Projekt Veeam Agent for Linux können wir einfach nichts RISC-ähnliches unterstützen.

Ich werde nicht ausführlich auf dieses Thema eingehen. Ich möchte nur die Hauptprobleme anreißen: plattformabhängige Typen wie size_t, Datenstruktur-Ausrichtung und Byte-Reihenfolge.

Statische und/oder dynamische Verlinkung

Die Frage "Wie soll ich mit Bibliotheken verlinken — dynamisch oder statisch?" sollten wir besprechen.

In der Regel verwenden C/C++-Anwendungen unter Linux dynamisches Linking. Das funktioniert gut, wenn die Anwendung speziell für eine bestimmte Distribution erstellt wurde.

Steht jedoch die Aufgabe an, verschiedene Distributionen mit einer einzigen Binärdatei abzudecken, muss man sich an die älteste unterstützte Distribution orientieren. Für uns ist das Red Hat 6. Es enthält gcc 4.4, das nicht einmal den Standard C++11 vollständig unterstützt. vollständig.

Wir bauen unser Projekt mit gcc 6.3, der C++14 vollständig unterstützt. In diesem Fall müssen wir die Bibliotheken libstdc++ und boost für Red Hat 6 mitbringen. Am einfachsten ist es, statisch mit diesen zu linken.

Leider kann nicht mit allen Bibliotheken statisch gelinkt werden.

Erstens müssen Systembibliotheken wie libfuse, libblkid dynamisch gelinkt werden, um sicherzustellen, dass sie mit dem Kernel und seinen Modulen kompatibel sind.

Zweitens gibt es Feinheiten bei den Lizenzen.

Die GPL-Lizenz erlaubt grundsätzlich das Linken von Bibliotheken nur mit Open-Source-Code. MIT und BSD erlauben statisches Linking und erlauben das Einfügen von Bibliotheken in Projekte. Die LGPL scheint statisches Linking nicht zu widersprechen, verlangt aber, dass die für das Linking benötigten Dateien öffentlich zugänglich gemacht werden.

Im Allgemeinen schützt die Verwendung von dynamischem Linking davor, etwas zur Verfügung stellen zu müssen.

Build von C/C++-Anwendungen

Um C/C++-Anwendungen für verschiedene Plattformen und Distributionen zu erstellen, reicht es aus, einen geeignetengcc zu wählen oder zu bauen und Cross-Compiler für spezifische Architekturen zu verwenden sowie das gesamte Set an Bibliotheken zu erstellen. Diese Arbeit ist durchaus umsetzbar, aber recht aufwändig. Und es gibt keine Garantie, dass der gewählte Compiler und die Bibliotheken eine funktionsfähige Variante ermöglichen.

Ein offensichtlicher Vorteil: Die Infrastruktur wird erheblich vereinfacht, da der gesamte Build-Prozess auf einem einzigen Rechner durchgeführt werden kann. Außerdem ist es ausreichend, ein Set von Binärdateien für eine Architektur zu erstellen, und diese können in Pakete für verschiedene Distributionen verpackt werden. So werden die Pakete von Veeam für den Veeam Agent für Linux erstellt.

Im Gegensatz zu dieser Variante kann man einfach eine Build-Farm einrichten, das heißt mehrere Maschinen für den Aufbau. Jede dieser Maschinen sorgt für die Kompilierung der Anwendung und den Build eines Pakets für 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über hinaus kann der Build-Prozess leicht parallelisiert werden.

Es gibt jedoch auch einen Nachteil dieses Ansatzes: Für jede Distribution innerhalb einer Architektur müssen eigene Binärdateien erstellt werden. Ein weiterer Nachteil ist, dass eine solche Vielzahl von Maschinen verwaltet werden muss, was viel Speicherplatz und RAM benötigt.

So werden KMOD-Pakete des Kernel-Moduls veeamsnap für Red Hat-Distributionen erstellt.

Open Build Service

Die Kollegen von SUSE haben versucht, einen goldenen Mittelweg in Form eines speziellen Dienstes für die Kompilierung von Anwendungen und den Build von Paketen zu realisieren — openbuildservice.

Im Grunde genommen handelt es sich um einen Hypervisor, der eine virtuelle Maschine erstellt, in der alle benötigten Pakete installiert werden, die Anwendung kompiliert und das Paket in dieser isolierten Umgebung erstellt wird, bevor die virtuelle Maschine wieder freigegeben wird.

Der im OpenBuildService implementierte Scheduler bestimmt selbst, wie viele virtuelle Maschinen er für die optimale Build-Geschwindigkeit starten kann. Der integrierte Signaturmechanismus unterzeichnet die Pakete automatisch und lädt sie in das integrierte Repository hoch. Das eingebaute Versionsverwaltungssystem speichert die Historie der Änderungen und Builds. Es bleibt nur noch, die eigenen Quellcodes in dieses System einzufügen. Einen Server muss man nicht unbedingt selbst aufsetzen, man kann auch den Open Service nutzen.

Hier gibt es allerdings ein Problem: Eine solche Lösung lässt sich schwer in die bestehende Infrastruktur integrieren. Zum Beispiel ist keine Versionskontrolle erforderlich, da wir bereits eine für die Quellcodes haben. Der Signaturmechanismus unterscheidet sich: es wird ein spezieller Server verwendet. Ein Repository ist ebenfalls nicht notwendig.

Darüber hinaus ist die Unterstützung anderer Distributionen — wie Red Hat — recht spärlich umgesetzt, was durchaus nachvollziehbar ist.

Ein Vorteil eines solchen Services ist der schnelle Support der nächsten Version des SUSE-Distributions. Vor der offiziellen Ankündigung des Releases werden die benötigten Pakete für den Build in ein öffentliches Repository hochgeladen. In der Liste der verfügbaren Distributionen im OpenBuildService erscheint eine neue Version. Wir setzen das Häkchen, und sie wird zum Build-Plan hinzugefügt. So erfolgt die Hinzufügung einer neuen Version der Distribution praktisch mit einem Klick.

In unserer Infrastruktur wird mit OpenBuildService eine Vielzahl von KMP-Paketen des veeamsnap-Kernelmoduls für SUSE-Distributionen erstellt.

Als Nächstes möchte ich mich mit spezifischen Fragen zu Kernelmodulen befassen.

kernel ABI

Linux-Kernelmodule wurden historisch in Form von Quellcodes verteilt. Der Grund dafür ist, dass die Kernelentwickler sich nicht darum kümmern, ein stabiles API für Kernelmodule zu unterstützen, geschweige denn auf binärer Ebene, auch kABI genannt.

Um ein Modul für den Vanilla-Kernel zu bauen, sind die Header genau dieses Kernels notwendig, und es wird nur auf diesem Kernel funktionieren.

DKMS ermöglicht 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.

Diese Situation entspricht dem Enterprise-Segment jedoch nicht besonders. Anbieter proprietärer Software möchten ihre Produkte in Form von kompilierten Binärdateien vertreiben.

Administratoren möchten aus Sicherheitsgründen keine Entwicklungstools auf Produktionsservern behalten. Distributoren von Enterprise Linux – wie Red Hat und SUSE – haben entschieden, dass sie ihren Nutzern eine stabile kABI bieten können. Infolgedessen sind KMOD-Pakete für Red Hat und KMP-Pakete für SUSE entstanden.

Das Wesen dieser Lösung ist ziemlich einfach. Für eine bestimmte Version der Distribution wird die API des Kernels eingefroren. Der Distributor erklärt, dass er z.B. den Kernel 3.10 verwendet und nur Korrekturen und Verbesserungen vornimmt, die die Kernel-Schnittstellen nicht berühren. Die für den allerersten Kernel erstellten Module können ohne Neukompilierung für alle nachfolgenden verwendet werden.

Red Hat erklärt, dass die kABI-Kompatibilität für das Betriebssystem während des gesamten Lebenszyklus gewährleistet ist. Das bedeutet, dass ein für 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ürlich ist diese Aufgabe ziemlich komplex.
Wir haben mehrere Fälle festgestellt, in denen das Modul veeamsnap aufgrund von Problemen mit der kABI-Kompatibilität nicht mehr funktionierte.

Nachdem das für 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ät für RHEL 7 vollständig aufgegeben.

Derzeit enthält das KMOD-Paket für RHEL 7 eine Version für jede Release-Version und ein Skript, das das Laden des Moduls sicherstellt.

SUSE ist bei der kABI-Kompatibilität vorsichtiger. Sie garantieren die kABI-Kompatibilität nur innerhalb eines Service Packs.

Beispielsweise wurde SLES 12 im September 2014 veröffentlicht. 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ät nur über ein Jahr aufrechtzuerhalten. Ein jährlicher Zyklus für Kernel-Updates sollte keine Probleme für Modulautoren verursachen.

Dank dieser Politik von SUSE haben wir bei unserem Modul veeamsnap kein einziges Problem mit der kABI-Kompatibilität festgestellt. Allerdings ist die Anzahl der Pakete für SUSE fast um den Faktor zehn höher.

Patches und Backports

Obwohl die Distributorinnen und Distributoren bemüht sind, die kABI-Kompatibilität und die Stabilität des Kernels zu gewährleisten, arbeiten sie auch daran, die Leistung zu verbessern und Fehler in diesem stabilen Kernel zu beheben.

Dabei verfolgen die Entwickelnden des Enterprise Linux-Kernels neben ihren eigenen „Fehlerbereinigungen“ auch die Änderungen im Vanilla-Kernel und übertragen diese in ihre „stabilisierte“ Version.

Manchmal führt das zu neuen Fehlern.

Im letzten Release von Red Hat 6 gab es in einem der kleineren Updates einen Fehler. Dieser führte dazu, dass das Modul veeamsnap das System beim Freigeben eines Snapshots garantiert abstürzen ließ. Durch den Vergleich der Kernel-Quellcodes vor und nach dem Update haben wir festgestellt, dass das Problem durch einen Backport verursacht wurde. Ein ähnlicher Fix wurde im Vanilla-Kernel der Version 4.19 umgesetzt. Allerdings funktionierte dieser Fix im Vanilla-Kernel einwandfrei, während bei der Übertragung in das „stabilisierte“ 2.6.32 Probleme mit Spin-Lock auftraten.

Natürlich kommen Fehler bei jedem vor, aber war es wirklich nötig, den Code von 4.19 auf 2.6.32 zu ziehen und dabei die Stabilität zu riskieren? Ich bin mir nicht sicher…

Am ärgerlichsten ist es, wenn Marketing in das Tauziehen zwischen „Stabilität“ „Modernisierung“ eingreift. Die Marketingabteilung benötigt ein stabiles Kernsystem des aktualisierten Distributionspakets, andererseits sollte es auch in der Leistung besser sein und neue Funktionen haben. Das führt zu seltsamen Kompromissen.

Als ich versuchte, ein Modul mit dem Kernel 4.4 von SLES 12 SP3 zu kompilierten, stellte ich mit Überraschung fest, dass es Funktionen aus dem Vanilla 4.8 enthält. Meiner Meinung nach ähnelt die Implementierung der Block-I/O-Funktionalität 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ür SP3 übertragen wurde, allerdings kann ich es mit gutem Gewissen nicht mehr als den stabilen 4.4 betiteln.

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ücksichtigen. Gut ist, dass man manchmal auf ein Define zurückgreifen kann, das mit neuen Funktionen eingeführt wird, aber diese Möglichkeit ist nicht immer gegeben.

In der Folge wird der Code mit kuriosen Direktiven für die bedingte Kompilierung angereichert.

Es gibt auch Patches, die die dokumentierte API des Kernels ändern.
Ich stieß auf die Distribution KDE neon 5.16 und war sehr überrascht, dass der Aufruf von lookup_bdev in dieser Kernel-Version die Liste der Eingabeparameter geändert hat.

Um das Ganze zu kompilieren, musste ich ein Skript in die Makefile einfügen, das überprüft, ob der Parameter mask für die Funktion lookup_bdev vorhanden ist.

Signatur der Kernelmodule

Aber kommen wir zurück zur Frage der Paketverteilung.

Einer der Vorteile des stabilen kABI ist, dass Kernelmodule als Binärdatei signiert werden können. In diesem Fall kann der Entwickler sicher sein, dass das Modul nicht versehentlich beschädigt oder absichtlich verändert wurde. Dies kann mit dem Befehl modinfo überprüft werden.

Die Red Hat- und SUSE-Distributionen ermöglichen die Überprüfung der Modulsignatur und laden es nur, wenn das entsprechende Zertifikat im System registriert ist. Das Zertifikat ist der öffentliche Schlüssel, mit dem das Modul signiert wird. Wir verteilen es in Form eines separaten Pakets.

Das Problem hierbei ist, dass die Zertifikate entweder im Kernel integriert sind (die von den Distributionen verwendet werden) oder in den nichtflüchtigen EFI-Speicher mit Hilfe eines Tools geschrieben werden müssen. mokutil. Das Tool mokutil 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.

Daher erfordert das Hinzufügen 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 über das Netzwerk (zum Beispiel über ssh) möglich ist, wird es unmöglich sein, ein Zertifikat hinzuzufügen.

EFI auf virtuellen Maschinen

Obwohl EFI schon lange von fast allen Herstellern von Motherboards unterstützt wird, kann der Administrator bei der Installation des Systems nicht an die Notwendigkeit von EFI denken, und es könnte deaktiviert sein.

Nicht alle Hypervisoren unterstützen EFI. VMWare vSphere unterstützt EFI ab Version 5.
Microsoft Hyper-V hat ebenfalls die Unterstützung von EFI erhalten, beginnend mit Hyper-V für Windows Server 2012R2.

Allerdings ist dieser Funktionsumfang in der Standardkonfiguration für Linux-Maschinen deaktiviert, was bedeutet, dass ein Zertifikat nicht installiert werden kann.

In vSphere 6.5 kann die Option Secure Boot nur in der alten Version des Web-Interfaces, die über Flash funktioniert, gesetzt werden. Das Web-UI auf HTML-5 hinkt momentan stark hinterher.

Experimentelle Distributionen

Zum Schluss betrachten wir die Frage der experimentellen Distributionen und der Distributionen ohne offizielle Unterstützung. Einerseits wird man solche Distributionen wahrscheinlich auf Servern ernsthafter Organisationen nicht antreffen. Solche Distributionen haben keine offizielle Unterstützung. Daher kann man auch keinen technischen Support für Produkte auf solchen Distributionen bieten.

Jedoch werden solche Distributionen zu einer geeigneten Plattform, um neue experimentelle Lösungen 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önnte diese experimentelle Funktionalität in die aktualisierte Version von RHEL, SLES oder Ubuntu integriert werden.

Wenn also etwas auf einer experimentellen Distribution nicht funktioniert, ist das ein Grund, sich mit dem Problem zu befassen und es zu lösen. Man muss darauf vorbereitet sein, dass diese Funktionalität bald auf den Produktionsservern der Benutzer verfügbar sein wird.

Die derzeit offiziell unterstützten Distributionen für Version 3.0 können Sie einsehen. hierDas tatsächliche Spektrum der Distributionen, auf denen unser Produkt funktioniert, ist jedoch deutlich breiter.

Persönlich interessierte mich das Experiment mit dem Betriebssystem „Elbrus“. Nach der Optimierung des Veeam-Pakets ließ sich unser Produkt installieren und funktionierte einwandfrei. Über dieses Experiment habe ich auf Habr geschrieben unter Artikel.

Die Unterstützung neuer Distributionen wird fortgesetzt. Wir erwarten bald die Veröffentlichung von Version 4.0. Eine Beta sollte bald verfügbar sein, also bleiben Sie auf dem Laufenden über whats-new!

Quelle: habr.com