Eine Backup-Anwendung zu erstellen, die auf jedem Distribution funktioniert, ist eine anspruchsvolle Aufgabe. Um Veeam Agent for Linux auf Distributionen von Red Hat 6 bis Debian 6, bis hin zu OpenSUSE 15.1 und Ubuntu 19.04 zum Laufen zu bringen, müssen wir eine Vielzahl von Problemen lösen, insbesondere wenn man bedenkt, dass das Produkt ein Kernel-Modul beinhaltet.
Der Artikel basiert auf Materialien eines Vortrags auf der Konferenz .
Linux ist nicht nur eines der populärsten Betriebssysteme. Es ist im Grunde eine Plattform, auf der man etwas Einzigartiges, etwas Eigenes schaffen kann. Daher gibt es viele Distributionen von Linux, die sich in der Auswahl der Softwarekomponenten unterscheiden. Das bringt ein Problem mit sich: Damit ein Produkt auf jeder Distribution funktioniert, müssen die Besonderheiten jeder einzelnen berücksichtigt werden.
Paketmanager. .deb vs .rpm
Beginnen wir mit dem offensichtlichen Problem der Verbreitung von Produkten für verschiedene Distributionen.
Der typischste Weg, Softwareprodukte zu verteilen, besteht darin, ein Paket in ein Repository zu legen, damit der im System integrierte Paketmanager es von dort installieren kann.
Es gibt jedoch zwei gängige Paketformaten: rpm und deb. Das bedeutet, dass jede Unterstützung notwendig sein wird.
In der Welt der deb-Pakete ist die Kompatibilität erstaunlich hoch. Ein und dasselbe Paket lässt sich sowohl auf Debian 6 als auch auf Ubuntu 19.04 problemlos installieren und nutzen. Die Standards für den Aufbau und die Verwaltung von Paketen, die in älteren Debian-Distributionen festgelegt wurden, bleiben auch in den modernen Distributionen wie Linux Mint und elementary OS relevant. Daher benötigt der Veeam Agent for Linux nur ein deb-Paket für jede Hardwareplattform.
In der Welt der rpm-Pakete hingegen sind die Unterschiede erheblich. Erstens gibt es zwei völlig unabhängige Distributoren, Red Hat und SUSE, für die Kompatibilität keine Rolle spielt. Zweitens besitzen diese Distributoren sowohl Distributionen mit technischer Unterstützung als auch experimentelle. Auch hier ist Kompatibilität nicht erforderlich. So haben wir letztendlich verschiedene Pakete für el6, el7 und el8. Außerdem ein separates Paket für Fedora und verschiedene Pakete für SLES11 und 12 sowie ein eigenes für openSUSE. Das Hauptproblem liegt in den Abhängigkeiten und den Paketnamen.
Das Problem der Abhängigkeiten
Leider treten häufig die gleichen Pakete unter verschiedenen Namen in unterschiedlichen Distributionen auf. Unten finden Sie 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
Das Ergebnis ist, dass die Liste der Abhängigkeiten für die Distribution einzigartig ist.
Schlimmer wird es, wenn sich unter dem alten Paketnamen eine aktualisierte Version verbirgt.
Beispiel:
In Fedora 24 wurde das Paket ncurses von Version 5 auf Version 6 aktualisiert. Unser Produkt wurde speziell mit der Version 5 erstellt, um die Kompatibilität mit älteren Distributionen zu gewährleisten. Um die alte Version 5 der Bibliothek in Fedora 24 zu nutzen, musste das Paket ncurses-compat-libs.
verwendet werden. Infolgedessen erscheinen für Fedora zwei Pakete mit unterschiedlichen Abhängigkeiten.
Es wird noch 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 kostspielig, alte Bibliotheken in die neue Version der Distribution zu ziehen. Nach einiger Zeit trat das Problem auch in den SUSE-Distributionen wieder auf.
Als Ergebnis musste für einige Distributionen auf eine explizite Abhängigkeit von ncurses-libsverzichtet werden, und das Produkt wurde so angepasst, dass es mit jeder Version der Bibliothek funktionieren kann.
Übrigens gibt es in der 8. Version von Red Hat kein Metapaket mehr, Pythondas auf das gute alte python 2.7Außerdem gibt es ein python2 verwies. und Python3.
Alternativen zu Paketmanagern
Das Problem mit Abhängigkeiten ist altbekannt. Man erinnere sich nur an den Begriff "Dependency Hell".
Die Herausforderung besteht darin, verschiedene Bibliotheken und Anwendungen so zu kombinieren, dass sie stabil arbeiten und nicht miteinander in Konflikt geraten – genau das versucht jeder Linux-Distributor zu bewältigen.
Eine ganz andere Herangehensweise bietet der Paketmanager Snappy von Canonical. Der Grundgedanke: Die Anwendung wird in einer isolierten und vom Hauptsystem geschützten Sandbox ausgeführt. Wenn eine Anwendung Bibliotheken benötigt, werden diese zusammen mit der Anwendung bereitgestellt.
Flatpak was ebenfalls das Ausführen von Anwendungen in einer Sandbox unter Verwendung von Linux-Containern ermöglicht. Dieses Konzept wird auch von AppImage.
Diese Lösungen ermöglichen die Erstellung eines Pakets für alle Distributionen. Im Fall von Flatpak kann die Installation und der Start der Anwendung sogar ohne Wissen des Administrators erfolgen.
Das Hauptproblem besteht darin, dass nicht alle Anwendungen in einer Sandbox funktionieren können. Einige benötigen direkten Zugang zur Plattform. Ganz zu schweigen von Kernelmodulen, die stark vom Kernel abhängen und somit nicht in das Sandbox-Konzept passen.
Ein weiteres Problem ist, dass beliebte Enterprise-Distributionen von Red Hat und SUSE bisher keine Unterstützung für Snappy und Flatpak enthalten.
Daher ist der Veeam Agent für Linux weder auf noch auf .
Abschließend möchte ich im Zusammenhang mit Paketmanagern erwähnen, dass es die Möglichkeit gibt, vollständig auf Paketmanager zu verzichten, indem man die Binärdateien und das Skript zur Installation in einem Paket zusammenführt.
Ein solches Bundle ermöglicht es, ein gemeinsames Paket für verschiedene Distributionen und Plattformen zu erstellen, den Installationsprozess interaktiv zu gestalten und notwendige Anpassungen vorzunehmen. Ich habe solche Pakete für Linux nur von VMware gesehen.
Das Problem der Updates
Selbst wenn alle Abhängigkeitsprobleme gelöst sind, kann die Software auf derselben Distribution unterschiedlich funktionieren. Ursache sind die Updates.
Es gibt drei Update-Strategien:
- Die einfachste ist, nie zu aktualisieren. Man hat den Server konfiguriert und vergessen. Warum Updates, wenn alles funktioniert? Probleme beginnen beim ersten Anruf beim Support. Der Ersteller der Distribution unterstützt nur die aktualisierte Version.
- Man kann dem Distributor vertrauen und automatische Updates einrichten. In diesem Fall ist ein Anruf beim Support wahrscheinlich, sofort nach einem fehlgeschlagenen Update.
- Die manuelle Aktualisierung nach einer Testphase in der Infrastruktur ist die sicherste, jedoch auch die kostspieligste und arbeitsintensivste Option. Nicht jeder kann sich das leisten.
Da verschiedene Nutzer unterschiedliche Aktualisierungsstrategien anwenden, müssen sowohl die neueste Version als auch alle zuvor veröffentlichten unterstützt werden. Das verkompliziert sowohl den Entwicklungsprozess als auch die Testphase und sorgt für zusätzlichen Stress im Support-Team.
Vielfalt der Hardwareplattformen
Diverse Hardwareplattformen sind ein Problem, das in hohem Maße spezifisch für nativen Code ist. Mindestens einmal müssen Binärdateien für jede unterstützte Plattform erstellt werden.
Im Projekt Veeam Agent für Linux können wir einfach nichts RISC-ähnliches unterstützen.
Ich werde nicht im Detail auf dieses Thema eingehen. Ich möchte nur die wichtigsten Probleme anreißen: plattformabhängige Typen wie size_t, Struktur-Alignment und Byte-Reihenfolge.
Statische und/oder dynamische Verlinkung
Die Frage "Wie verlinkt man mit Bibliotheken - dynamisch oder statisch?" sollte diskutiert werden.
In der Regel verwenden C/C++-Anwendungen unter Linux dynamische Bindung. Das funktioniert hervorragend, 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 der ältesten unterstützten Distribution orientieren. In unserem Fall ist das Red Hat 6. Es enthält gcc 4.4, das nicht einmal den Standard C++11 unterstützt. .
Wir kompilieren unser Projekt mit gcc 6.3, das C++14 vollständig unterstützt. Daher müssen wir in diesem Fall die Bibliotheken libstdc++ und Boost mit Red Hat 6 mitbringen. Am einfachsten ist es, statisch mit ihnen zu verlinken.
Leider kann nicht mit allen Bibliotheken statisch verlinkt werden.
Einerseits müssen Systembibliotheken wie libfuse, libblkid dynamisch gebunden werden, um die Kompatibilität mit dem Kernel und seinen Modulen sicherzustellen.
Zweitens gibt es eine Feinheit bei den Lizenzen.
Die GPL-Lizenz erlaubt grundsätzlich das Linken von Bibliotheken nur mit Open-Source-Code. MIT- und BSD-Lizenzen ermöglichen die statische Verknüpfung und erlauben das Einbinden von Bibliotheken in ein Projekt. Hingegen scheint die LGPL keine Einwände gegen statische Verknüpfungen zu haben, fordert jedoch, dass die zur Verknüpfung benötigten Dateien öffentlich zugänglich gemacht werden.
Im Allgemeinen schützt die Verwendung von dynamischer Verknüpfung davor, etwas zur Verfügung stellen zu müssen.
Kompilierung von C/C++-Anwendungen
Um C/C++-Anwendungen für verschiedene Plattformen und Distributionen zu kompilieren, genügt es, eine passende Version von gcc auszuwählen oder zusammenzustellen und Cross-Compiler für spezifische Architekturen zu verwenden sowie das gesamte Set an Bibliotheken zu erstellen. Diese Arbeit ist durchaus machbar, aber recht aufwendig. Und es gibt keine Garantien, dass der gewählte Compiler und die Bibliotheken eine funktionierende Variante gewährleisten.
Ein offensichtlicher Vorteil: Die Infrastruktur wird erheblich vereinfacht, da der gesamte Kompilierungsprozess auf einer Maschine durchgeführt werden kann. Darüber hinaus genügt es, ein Set von Binärdateien für eine Architektur zu erstellen und diese in Pakete für verschiedene Distributionen zu verpacken. Genau so werden die Pakete von Veeam für den Veeam Agent for Linux erstellt.
Im Gegensatz zu dieser Option kann man einfach eine Build-Farm einrichten, also mehrere Maschinen für die Kompilierung. Jede dieser Maschinen wird die Anwendung kompilieren und das Paket für ein bestimmtes Betriebssystem und eine spezifische Architektur erstellen. In diesem Fall erfolgt die Kompilierung mit den Mitteln, die der Distributor bereitgestellt hat. Das heißt, die Phase der Vorbereitung des Compilers und die Auswahl der Bibliotheken entfallen. Zudem kann der Bauprozess leicht parallelisiert werden.
Es gibt jedoch einen Nachteil bei diesem Ansatz: Für jedes Betriebssystem innerhalb einer Architektur muss ein eigenes Set von Binärdateien erstellt werden. Ein weiterer Nachteil ist, dass eine Vielzahl von Maschinen gewartet werden muss, was viel Speicherplatz und Arbeitsspeicher erfordert.
Auf diese Weise werden KMOD-Pakete des Kernmoduls veeamsnap für Red Hat-Distributionen erstellt.
Open Build Service
Das Team von SUSE hat versucht, einen Mittelweg zu finden, indem es einen speziellen Dienst zur Kompilierung von Anwendungen und zur Erstellung von Paketen entwickelt hat — .
Im Grunde genommen handelt es sich um einen Hypervisor, der eine virtuelle Maschine erstellt, alle erforderlichen Pakete installiert, die Anwendung kompiliert und das Paket in dieser isolierten Umgebung erstellt, bevor die virtuelle Maschine freigegeben wird.
Der in OpenBuildService implementierte Planer wird selbstständig bestimmen, wie viele virtuelle Maschinen er für eine optimale Paketbaugeschwindigkeit starten kann. Der integrierte Signaturmechanismus signiert die Pakete automatisch und legt sie im integrierten Repository ab. Das integrierte Versionskontrollsystem speichert die Historie der Änderungen und Builds. Es bleibt nur, die eigenen Quellcodes in dieses System hinzuzufügen. Es ist nicht einmal notwendig, einen eigenen Server zu betreiben, sondern man kann einen öffentlichen nutzen.
Hier gibt es allerdings ein Problem: Ein solcher Kompressor lässt sich schwer in die bestehende Infrastruktur integrieren. Zum Beispiel ist keine Versionskontrolle erforderlich, da wir bereits unsere für die Quellcodes haben. Unser Signaturmechanismus weicht ab: Es wird ein spezieller Server verwendet. Auch ein Repository ist nicht nötig.
Darüber hinaus ist die Unterstützung anderer Distributionen – zum Beispiel Red Hat – ziemlich spärlich umgesetzt, was durchaus nachvollziehbar ist.
Ein Vorteil dieses Services ist die schnelle Unterstützung der neuesten Version des SUSE-Distributionspakets. Vor der offiziellen Veröffentlichung werden die erforderlichen Pakete im öffentlichen Repository bereitgestellt. In der Liste der verfügbaren Distributionen auf OpenBuildService erscheint ein neuer Eintrag. Wir setzen ein Häkchen, und er wird in den Build-Plan aufgenommen. So kann die Hinzufügung einer neuen Version der Distribution praktisch mit einem Klick erfolgen.
In unserer Infrastruktur wird mit OpenBuildService eine Vielzahl von KMP-Paketen des veeamsnap-Kernelmoduls für SUSE-Distributionen erstellt.
Nun möchte ich auf spezifische Fragen eingehen, die speziell für Kernelmodule relevant sind.
kernel ABI
Linux-Kernelmodule wurden historisch als Quelltexte verbreitet. Die Tatsache ist, dass die Kernel-Entwickler sich nicht um die Unterstützung einer stabilen API für Kernelmodule kümmern, geschweige denn auf binärer Ebene, auch bekannt als kABI.
Um ein Modul für den Vanilla-Kernel zu kompilieren, benötigt man unbedingt die Header genau dieses Kernels, und es wird nur auf diesem Kernel funktionieren.
DKMS automatisiert den Prozess des Zusammenbaus von Modulen bei Kernel-Updates. Dadurch verwenden Benutzer des Debian-Repositories (und seiner zahlreichen Verwandten) entweder Kernel-Module aus dem Distributeur-Repository oder solche, die mit DKMS aus den Quellcodes erstellt werden.
Diese Situation ist jedoch für den Enterprise-Sektor nicht besonders zufriedenstellend. Anbieter proprietärer Software möchten ihr Produkt in Form von vorgefertigten Binärdateien vertreiben.
Administratoren möchten aus Sicherheitsgründen keine Entwicklungswerkzeuge auf Produktionsservern halten. Anbieter von Enterprise Linux, wie Red Hat und SUSE, haben entschieden, dass sie für ihre Benutzer eine stabile kABI unterstützen können. Infolgedessen wurden KMOD-Pakete für Red Hat und KMP-Pakete für SUSE eingeführt.
Die Grundsätze dieser Lösung sind ziemlich einfach. Für eine bestimmte Version des Distributionssystems wird die API des Kernels eingefroren. Der Anbieter erklärt, dass er genau den Kernel, beispielsweise 3.10, verwendet und nur Fehlerbehebungen und Verbesserungen vornimmt, die die Kernelfunktionen nicht beeinträchtigen. Die für den ursprünglichen Kernel kompilierten Module können ohne erneute Kompilierung für alle nachfolgenden Versionen verwendet werden.
Red Hat gibt an, dass die kABI-Kompatibilität für die Distribution während des gesamten Lebenszyklus besteht. Das bedeutet, dass ein für RHEL 6.0 (Release November 2010) erstelltes Modul auch mit der Version 6.10 (Release Juni 2018) funktionieren sollte. Das sind fast 8 Jahre. Natürlich ist diese Aufgabe ziemlich kompliziert.
Wir haben mehrere Fälle dokumentiert, 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 nicht kompatibel war, jedoch geladen wurde und garantiert den Server abstürzen ließ, haben wir die Nutzung der kABI-Kompatibilität für RHEL 7 grundsätzlich aufgegeben.
Aktuell enthält das KMOD-Paket für RHEL 7 eine Build für jede Version des Releases und ein Skript, das das Laden des Moduls sicherstellt.
SUSE ist bei der kABI-Kompatibilität vorsichtiger vorgegangen. Sie gewährleisten die kABI-Kompatibilität nur innerhalb eines Service Packs.
Zum Beispiel fand die Veröffentlichung von SLES 12 im September 2014 statt. SLES 12 SP1 folgte bereits im Dezember 2015, was also etwas mehr als ein Jahr später ist. Obwohl beide Versionen den Kernel 3.12 verwenden, sind sie kABI-in-kompatibel. Offensichtlich ist es viel einfacher, die kABI-Kompatibilität nur über ein Jahr hinweg aufrechtzuerhalten. Ein jährlicher Update-Zyklus für das Kernmodul sollte keine Probleme für die Modulentwickler verursachen.
Dank dieser Politik von SUSE haben wir keine Probleme mit der kABI-Kompatibilität für unser Modul veeamsnap festgestellt. Es ist jedoch zu erwähnen, dass die Anzahl der Pakete für SUSE fast um den Faktor zehn höher ist.
Patches und Backports
Auch wenn die Distributor*innen sich bemühen, die kABI-Kompatibilität und die Stabilität des Kernels zu gewährleisten, streben sie gleichzeitig an, die Leistung zu verbessern und Fehler in diesem stabilen Kernel zu beheben.
Zusätzlich zur eigenen „Fehlerbehebung“ verfolgen die Entwickler des Enterprise-Linux-Kernels die Änderungen im Vanilla-Kernel und übernehmen diese in ihr „stabiles“ System.
Das führt manchmal zu neuen .
Im letzten Release von Red Hat 6 gab es in einem der kleineren Updates einen Fehler. Dieser führte dazu, dass das Veeamsnap-Modul das System beim Freigeben von Snapshots zuverlässig zum Absturz brachte. Durch den Vergleich der Quellcodes des Kernels vor und nach dem Update konnten wir feststellen, dass ein Backport dafür verantwortlich war. Ein ähnlicher Fix wurde im Vanilla-Kernel der Version 4.19 vorgenommen. Nur funktionierte dieser Fix im Vanilla-Kernel einwandfrei, während es beim Übertragen in das 'stabile' 2.6.32 zu Problemen mit der Spin-Sperrung kam.
Natürlich treten Fehler immer und überall auf, aber war es wirklich notwendig, den Code von 4.19 nach 2.6.32 zu ziehen und dabei die Stabilität zu riskieren? Ich bin mir nicht sicher...
Das Schlimmste ist, wenn das Marketing in das Tauziehen zwischen 'Stabilität' 'Modernisierung' eingreift. Die Marketingabteilung möchte, dass der Kernel des aktualisierten Distributors stabil ist und gleichzeitig bessere Leistung und neue Funktionen bietet. Dies führt zu seltsamen Kompromissen.
Als ich versuchte, ein Modul auf dem 4.4-Kernel von SLES 12 SP3 zu erstellen, war ich überrascht, Funktionen aus dem Vanilla 4.8 zu entdecken. Meiner Meinung nach ähnelt die Implementierung des blockbasierten I/O im 4.4-Kernel 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-Kernel 4.4 für SP3 übernommen wurde, aber es fällt mir schwer, diesen Kernel weiterhin als stabilen 4.4 zu bezeichnen.
Das Unangenehmste dabei ist, dass man bei der Erstellung eines Moduls, das auf verschiedenen Kernen gleichermaßen gut funktioniert, nicht mehr auf die Kernelversion vertrauen kann. Man muss auch die Distribution berücksichtigen. Es ist gut, dass man manchmal auf eine Define zurückgreifen kann, die mit neuen Funktionen kommt, aber diese Möglichkeit ist nicht immer gegeben.
Infolgedessen wird der Code mit seltsamen Bedingungs-Kompatibilitätsdirektiven überladen.
Es gibt auch Patches, die die dokumentierte API des Kerns ändern.
Ich stieß auf die Distribution 5.16 und war sehr überrascht, dass der Aufruf von lookup_bdev in dieser Kernelversion die Liste der Eingabeparameter geändert hat.
Um alles zusammenzustellen, musste ein Skript in die Makefile hinzugefügt werden, das überprüft, ob der Parameter mask in der Funktion lookup_bdev vorhanden ist.
Signatur von Kernmodulen
Lassen Sie uns aber zum Thema der Paketverteilung zurückkehren.
Ein Vorteil des stabilen kABI ist, dass Kernmodule als Binärdatei signiert werden können. Auf diese Weise 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 Distributionen Red Hat und SUSE ermöglichen die Überprüfung der Signatur eines Moduls 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 als separates Paket.
Das Problem ist hier, dass die Zertifikate entweder in den Kernel eingebettet sein können (die von den Distributoren verwendet werden) oder in den nicht-flüchtigen Speicher EFI mit Hilfe des Tools mokutil. Das Tool mokutil fordert beim Installieren des Zertifikats einen Neustart des Systems an und bietet dem Administrator noch vor dem Laden des Betriebssystemkernels die Möglichkeit, das Laden des neuen Zertifikats zu genehmigen.
Das Hinzufügen eines Zertifikats erfordert also physischen Zugriff des Administrators auf das System. Wenn die Maschine in der Cloud oder einfach in einem entfernten Rechenzentrum steht und der Zugriff nur über das Netzwerk (z. B. über SSH) möglich ist, kann das Zertifikat nicht hinzugefügt werden.
EFI bei virtuellen Maschinen
Obwohl EFI bereits seit Langem von nahezu allen Motherboard-Herstellern unterstützt wird, könnte der Administrator bei der Installation des Systems die Notwendigkeit von EFI übersehen, wodurch es deaktiviert sein könnte.
Nicht alle Hypervisoren unterstützen EFI. VMWare vSphere unterstützt EFI ab Version 5.
Microsoft Hyper-V hat ebenfalls Unterstützung für EFI, beginnend mit Hyper-V für Windows Server 2012R2.
In der Standardkonfiguration ist diese Funktion für Linux-Maschinen jedoch deaktiviert, was bedeutet, dass das Zertifikat nicht installiert werden kann.
In vSphere 6.5 kann die Option Secure Boot nur in der alten Version der Weboberfläche, die über Flash funktioniert, eingestellt werden. Die HTML-5 Web UI hinkt noch hinterher.
Experimentelle Distributionen
Abschließend betrachten wir das Thema experimenteller Distributionen und Distributionen ohne offizielle Unterstützung. Einerseits sind solche Distributionen in den Servern ernsthafter Organisationen kaum anzutreffen. Diese Distributionen haben keine offizielle Unterstützung. Daher kann auch keine technische Unterstützung für ein Produkt auf einer solchen Distribution bereitgestellt werden.
Dennoch bieten solche Distributionen eine praktische Plattform, um neue experimentelle Lösungen auszuprobieren. Zum Beispiel Fedora, OpenSUSE Tumbleweed oder die Unstable-Versionen von Debian. Sie sind ziemlich stabil. Sie enthalten stets die neuesten Programmversionen und immer einen aktualisierten Kernel. Nach einem Jahr könnte diese experimentelle Funktionalität in der aktualisierten Version von RHEL, SLES oder Ubuntu integriert sein.
Wenn also etwas auf einer experimentellen Distribution nicht funktioniert, ist das ein Grund, das Problem zu untersuchen und zu lösen. Man sollte darauf vorbereitet sein, dass diese Funktionalität bald auf den Produktionsservern der Benutzer verfügbar sein wird.
Die derzeit verfügbaren Liste der offiziell unterstützten Distributionen für Version 3.0 können Sie hier einsehen . Allerdings ist die tatsächliche Liste der Distributionen, auf denen unser Produkt betrieben werden kann, wesentlich umfassender.
Persönlich fand ich das Experiment mit dem Betriebssystem „Elbrus“ interessant. Nach der Überarbeitung des Veeam-Pakets konnte unser Produkt installiert und zum Laufen gebracht werden. Über dieses Experiment habe ich auf Habr geschrieben in .
Die Unterstützung neuer Distributionen geht weiter. Wir erwarten die Veröffentlichung der Version 4.0. Bald sollte die Beta erscheinen, also bleibt dran an !
Quelle: habr.com
