Das Erstellen einer Backup-Anwendung, die auf jeder Distribution funktioniert, ist keine leichte Aufgabe. Um sicherzustellen, dass Veeam Agent für Linux auf Distributionen von Red Hat 6 und Debian 6 bis hin zu OpenSUSE 15.1 und Ubuntu 19.04 funktioniert, müssen Sie eine Reihe von Problemen lösen, insbesondere wenn man bedenkt, dass das Softwareprodukt ein Kernelmodul enthält.
Der Artikel wurde auf der Grundlage von Materialien aus einer Rede auf der Konferenz erstellt .
Linux ist nicht nur eines der beliebtesten Betriebssysteme. Im Wesentlichen handelt es sich hierbei um eine Plattform, auf deren Grundlage Sie etwas Einzigartiges, etwas Eigenes schaffen können. Aus diesem Grund gibt es unter Linux viele Distributionen, die sich in ihren Softwarekomponenten unterscheiden. Und hier entsteht ein Problem: Damit ein Softwareprodukt auf einer beliebigen Distribution funktioniert, müssen Sie die jeweiligen Funktionen berücksichtigen.
Paketmanager. .deb vs. .rpm
Beginnen wir mit dem offensichtlichen Problem der Verteilung des Produkts auf verschiedene Distributionen.
Die gängigste Art, Softwareprodukte zu verteilen, besteht darin, das Paket in einem Repository abzulegen, damit der in das System integrierte Paketmanager es von dort aus installieren kann.
Wir haben jedoch zwei beliebte Paketformate: rpm и deb. Das bedeutet, dass jeder mithelfen muss.
In der Welt der Deb-Pakete ist der Grad der Kompatibilität erstaunlich. Das gleiche Paket lässt sich unter Debian 6 und Ubuntu 19.04 installieren und funktioniert gleich gut. Die in alten Debian-Distributionen festgelegten Standards für den Prozess der Paketerstellung und der Arbeit mit ihnen bleiben auch im neuen Linux Mint und Elementary OS relevant. Daher ist im Fall von Veeam Agent für Linux ein Deb-Paket für jede Hardwareplattform ausreichend.
Aber in der Welt der RPM-Pakete sind die Unterschiede groß. Erstens aufgrund der Tatsache, dass es mit Red Hat und SUSE zwei völlig unabhängige Distributoren gibt, für die eine Kompatibilität völlig unnötig ist. Zweitens verfügen diese Händler über Vertriebskits von diesen. Unterstützung und experimentell. Es besteht auch kein Bedarf an Kompatibilität zwischen ihnen. Es stellte sich heraus, dass el6, el7 und el8 ihre eigenen Pakete haben. Separates Paket für Fedora. Pakete für SLES11 und 12 und ein separates für openSUSE. Das Hauptproblem sind Abhängigkeiten und Paketnamen.
Abhängigkeitsproblem
Leider landen dieselben Pakete in verschiedenen Distributionen häufig unter unterschiedlichen Namen. Nachfolgend finden Sie eine unvollständige Liste der Veeam-Paketabhängigkeiten.
Für EL7:
Für SLES 12:
- libblkid
- libgcc
- libstdc ++
- ncurses-libs
- Fuse-Libs
- Datei-Libs
- veeamsnap=3.0.2.1185
- libblkid1
- libgcc_s1
- libstdc + + 6
- libmagic1
- libfuse2
- veeamsnap-kmp=3.0.2.1185
Daher ist die Liste der Abhängigkeiten für die Verteilung eindeutig.
Was noch schlimmer wird, ist, wenn eine aktualisierte Version beginnt, sich unter dem alten Paketnamen zu verstecken.
Beispiel:
Das Paket wurde in Fedora 24 aktualisiert Flüche von Version 5 auf Version 6. Unser Produkt wurde mit Version 5 erstellt, um die Kompatibilität mit älteren Distributionen sicherzustellen. Um die alte 5. Version der Bibliothek auf Fedora 24 nutzen zu können, musste ich das Paket verwenden ncurses-compat-libs.
Daher gibt es für Fedora zwei Pakete mit unterschiedlichen Abhängigkeiten.
Noch interessanter. Nach dem nächsten Distributions-Update wird das Paket ncurses-compat-libs Mit Version 5 der Bibliothek stellt sich heraus, dass sie nicht verfügbar ist. Für einen Distributor ist es teuer, alte Bibliotheken in eine neue Version der Distribution zu ziehen. Nach einiger Zeit wiederholte sich das Problem bei SUSE-Distributionen.
Infolgedessen mussten einige Distributionen ihre explizite Abhängigkeit von aufgeben ncurses-libs, und reparieren Sie das Produkt, sodass es mit jeder Version der Bibliothek funktionieren kann.
In Version 8 von Red Hat gibt es übrigens kein Metapaket mehr python, was sich auf das gute Alte bezog Python 2.7. Gibt es python2 и python3.
Alternative zu Paketmanagern
Das Problem mit Abhängigkeiten ist alt und seit langem offensichtlich. Denken Sie nur an die Abhängigkeitshölle.
Verschiedene Bibliotheken und Anwendungen so zu kombinieren, dass sie alle stabil funktionieren und nicht in Konflikt geraten – genau das ist die Aufgabe, die jeder Linux-Distributor zu lösen versucht.
Der Paketmanager versucht dieses Problem auf ganz andere Weise zu lösen. Bissig von Canonical. Die Grundidee: Die Anwendung läuft in einer Sandbox, isoliert und geschützt vom Hauptsystem. Wenn eine Anwendung Bibliotheken benötigt, werden diese mit der Anwendung selbst bereitgestellt.
Flatpak ermöglicht Ihnen auch die Ausführung von Anwendungen in einer Sandbox mithilfe von Linux-Containern. Auch die Sandbox-Idee kommt zum Einsatz AppImage.
Mit diesen Lösungen können Sie ein Paket für jede Distribution erstellen. Im Falle von Flatpak Installation und Start der Anwendung sind auch ohne Wissen des Administrators möglich.
Das Hauptproblem besteht darin, dass nicht alle Anwendungen in einer Sandbox ausgeführt werden können. Manche Menschen benötigen direkten Zugang zur Plattform. Ich spreche nicht einmal von Kernelmodulen, die streng vom Kernel abhängig sind und nicht in das Sandbox-Konzept passen.
Das zweite Problem besteht darin, dass die im Unternehmensumfeld beliebten Distributionen von Red Hat und SUSE noch keine Unterstützung für Snappy und Flatpak enthalten.
In diesem Zusammenhang ist Veeam Agent für Linux nicht verfügbar gar nicht .
Um die Frage zu Paketmanagern abzuschließen, möchte ich darauf hinweisen, dass es eine Option gibt, Paketmanager ganz aufzugeben, indem Binärdateien und ein Skript für deren Installation in einem Paket kombiniert werden.
Mit einem solchen Bundle können Sie ein gemeinsames Paket für verschiedene Distributionen und Plattformen erstellen, einen interaktiven Installationsprozess durchführen und die erforderlichen Anpassungen vornehmen. Solche Pakete für Linux kenne ich bisher nur von VMware.
Update-Problem
Selbst wenn alle Abhängigkeitsprobleme behoben sind, kann es sein, dass das Programm auf derselben Distribution unterschiedlich ausgeführt wird. Es geht um Updates.
Es gibt 3 Update-Strategien:
- Die einfachste Möglichkeit besteht darin, niemals zu aktualisieren. Ich habe den Server eingerichtet und vergessen. Warum aktualisieren, wenn alles funktioniert? Probleme treten bereits auf, wenn Sie sich zum ersten Mal an den Support wenden. Der Ersteller der Distribution unterstützt nur die aktualisierte Version.
- Sie können dem Distributor vertrauen und automatische Updates einrichten. In diesem Fall ist ein Anruf beim Support wahrscheinlich unmittelbar nach einem erfolglosen Update.
- Die Option einer manuellen Aktualisierung erst nach der Ausführung auf einer Testinfrastruktur ist die zuverlässigste, aber teuerste und zeitaufwändigste Option. Nicht jeder kann es sich leisten.
Da verschiedene Benutzer unterschiedliche Update-Strategien verwenden, ist es notwendig, sowohl die neueste als auch alle zuvor veröffentlichten Versionen zu unterstützen. Dies verkompliziert sowohl den Entwicklungs- als auch den Testprozess und bereitet dem Support-Team Kopfzerbrechen.
Verschiedene Hardwareplattformen
Unterschiedliche Hardwareplattformen stellen ein Problem dar, das weitgehend spezifisch für nativen Code ist. Sie müssen mindestens Binärdateien für jede unterstützte Plattform sammeln.
Im Veeam Agent for Linux-Projekt können wir so etwas wie dieses RISC immer noch nicht unterstützen.
Ich werde mich nicht im Detail mit diesem Thema befassen. Ich werde nur die Hauptprobleme skizzieren: plattformabhängige Typen, wie z size_t, Strukturausrichtung und Bytereihenfolge.
Statische und/oder dynamische Verlinkung
Die Frage ist jedoch: „Wie verknüpft man Bibliotheken – dynamisch oder statisch?“ eine Diskussion wert.
C/C++-Anwendungen unter Linux verwenden in der Regel dynamisches Linking. Dies funktioniert hervorragend, wenn die Anwendung speziell für eine bestimmte Distribution erstellt wurde.
Wenn die Aufgabe darin besteht, verschiedene Distributionen mit einer Binärdatei abzudecken, müssen Sie sich auf die älteste unterstützte Distribution konzentrieren. Für uns ist das Red Hat 6. Es enthält gcc 4.4, was selbst der C++11-Standard nicht unterstützt .
Wir erstellen unser Projekt mit gcc 6.3, das C++14 vollständig unterstützt. In diesem Fall müssen Sie unter Red Hat 6 natürlich die Bibliotheken libstdc++ und boost mit sich führen. Am einfachsten ist es, sie statisch zu verlinken.
Aber leider können nicht alle Bibliotheken statisch verknüpft werden.
Erstens Systembibliotheken wie libfuse, libblkid Um die Kompatibilität mit dem Kernel und seinen Modulen sicherzustellen, ist eine dynamische Verknüpfung erforderlich.
Zweitens gibt es eine Feinheit bei Lizenzen.
Die GPL-Lizenz erlaubt grundsätzlich die Verknüpfung von Bibliotheken nur mit Open-Source-Code. MIT und BSD ermöglichen die statische Verknüpfung und die Einbindung von Bibliotheken in ein Projekt. Doch die LGPL scheint der statischen Verlinkung nicht zu widersprechen, sondern verlangt, dass die für die Verlinkung notwendigen Dateien geteilt werden.
Im Allgemeinen erspart Ihnen die Verwendung der dynamischen Verlinkung die Notwendigkeit, etwas bereitzustellen.
Erstellen von C/C++-Anwendungen
Um C/C++-Anwendungen für verschiedene Plattformen und Distributionen zu erstellen, reicht es aus, eine geeignete Version von gcc auszuwählen oder zu erstellen, Cross-Compiler für bestimmte Architekturen zu verwenden und den gesamten Bibliothekssatz zusammenzustellen. Diese Arbeit ist durchaus machbar, aber ziemlich mühsam. Und es gibt keine Garantie dafür, dass der ausgewählte Compiler und die ausgewählten Bibliotheken eine funktionsfähige Version bereitstellen.
Ein offensichtlicher Vorteil: Die Infrastruktur wird stark vereinfacht, da der gesamte Build-Prozess auf einer Maschine durchgeführt werden kann. Darüber hinaus reicht es aus, einen Satz Binärdateien für eine Architektur zu sammeln, und Sie können sie in Pakete für verschiedene Distributionen packen. So werden Veeam-Pakete für Veeam Agent for Linux erstellt.
Im Gegensatz zu dieser Option können Sie einfach eine Build-Farm, also mehrere Maschinen, für den Zusammenbau vorbereiten. Jede dieser Maschinen bietet Anwendungskompilierung und Paketassemblierung für eine bestimmte Distribution und eine bestimmte Architektur. In diesem Fall erfolgt die Zusammenstellung mit den vom Händler bereitgestellten Mitteln. Das heißt, die Phase der Vorbereitung des Compilers und der Auswahl von Bibliotheken entfällt. Darüber hinaus kann der Build-Prozess einfach parallelisiert werden.
Dieser Ansatz hat jedoch einen Nachteil: Für jede Distribution innerhalb derselben Architektur müssen Sie Ihre eigenen Binärdateien sammeln. Ein weiterer Nachteil besteht darin, dass eine so große Anzahl von Maschinen gewartet werden muss und viel Speicherplatz und RAM zugewiesen werden muss.
Auf diese Weise werden KMOD-Pakete des Veeamsnap-Kernelmoduls für Red Hat-Distributionen kompiliert.
Öffnen Sie den Builddienst
Kollegen von SUSE haben versucht, einen Mittelweg in Form eines speziellen Dienstes zum Kompilieren von Anwendungen und Zusammenstellen von Paketen umzusetzen - .
Im Wesentlichen handelt es sich um einen Hypervisor, der eine virtuelle Maschine erstellt, alle erforderlichen Pakete darin installiert, die Anwendung kompiliert und das Paket in dieser isolierten Umgebung erstellt, wonach die virtuelle Maschine freigegeben wird.
Der in OpenBuildService implementierte Planer bestimmt, wie viele virtuelle Maschinen gestartet werden können, um eine optimale Paketerstellungsgeschwindigkeit zu erzielen. Der integrierte Signaturmechanismus signiert die Pakete und lädt sie in das integrierte Repository hoch. Das integrierte Versionskontrollsystem speichert den Verlauf von Änderungen und Builds. Jetzt müssen Sie nur noch Ihre Quellen zu diesem System hinzufügen. Sie müssen den Server nicht einmal selbst einrichten, sondern können einen offenen verwenden.
Allerdings gibt es ein Problem: Eine solche Erntemaschine lässt sich nur schwer in die bestehende Infrastruktur integrieren. Beispielsweise ist keine Versionskontrolle erforderlich; wir haben bereits eine eigene für Quellcodes. Unser Signaturmechanismus ist anders: Wir verwenden einen speziellen Server. Ein Repository ist ebenfalls nicht erforderlich.
Darüber hinaus ist die Unterstützung anderer Distributionen – beispielsweise Red Hat – verständlicherweise eher dürftig umgesetzt.
Der Vorteil eines solchen Dienstes ist die schnelle Unterstützung der nächsten Version der SUSE-Distribution. Vor der offiziellen Ankündigung der Veröffentlichung werden die für die Assemblierung erforderlichen Pakete in einem öffentlichen Repository bereitgestellt. Eine neue erscheint in der Liste der verfügbaren Distributionen auf OpenBuildService. Wir aktivieren das Kontrollkästchen und es wird dem Bauplan hinzugefügt. Somit ist das Hinzufügen einer neuen Version der Distribution mit fast einem Klick erledigt.
In unserer Infrastruktur wird mithilfe von OpenBuildService die gesamte Vielfalt an KMP-Paketen des Veeamsnap-Kernelmoduls für SUSE-Distributionen zusammengestellt.
Als Nächstes möchte ich auf Kernelmodul-spezifische Probleme eingehen.
Kernel-ABI
Linux-Kernelmodule wurden in der Vergangenheit in Quellform verteilt. Tatsache ist, dass sich die Kernel-Ersteller nicht mit der Sorge belasten, eine stabile API für Kernel-Module zu unterstützen, insbesondere auf der Binärebene, im Folgenden als kABI bezeichnet.
Um ein Modul für einen Vanilla-Kernel zu erstellen, benötigen Sie auf jeden Fall die Header dieses bestimmten Kernels, und es funktioniert nur auf diesem Kernel.
Mit DKMS können Sie den Prozess der Modulerstellung beim Aktualisieren des Kernels automatisieren. Daher verwenden Benutzer des Debian-Repositorys (und seiner vielen Verwandten) Kernel-Module entweder aus dem Repository des Distributors oder mit DKMS aus dem Quellcode kompiliert.
Diese Situation passt jedoch nicht besonders zum Enterprise-Segment. Proprietäre Code-Distributoren möchten das Produkt als kompilierte Binärdateien vertreiben.
Aus Sicherheitsgründen möchten Administratoren Entwicklungstools nicht auf Produktionsservern aufbewahren. Enterprise-Linux-Distributoren wie Red Hat und SUSE entschieden, dass sie stabiles kABI für ihre Benutzer unterstützen könnten. Das Ergebnis waren KMOD-Pakete für Red Hat und KMP-Pakete für SUSE.
Der Kern dieser Lösung ist recht einfach. Für eine bestimmte Version der Distribution ist die Kernel-API eingefroren. Der Distributor gibt an, dass er den Kernel, beispielsweise 3.10, verwendet und nur Korrekturen und Verbesserungen vornimmt, die sich nicht auf die Kernel-Schnittstellen auswirken, und dass die für den allerersten Kernel gesammelten Module für alle folgenden ohne Neukompilierung verwendet werden können.
Red Hat behauptet, dass die Distribution über den gesamten Lebenszyklus hinweg mit kABI kompatibel ist. Das heißt, das zusammengestellte Modul für rhel 6.0 (Veröffentlichung November 2010) sollte auch auf Version 6.10 (Veröffentlichung Juni 2018) funktionieren. Und das sind fast 8 Jahre. Natürlich ist diese Aufgabe ziemlich schwierig.
Wir haben mehrere Fälle registriert, in denen das Veeamsnap-Modul aufgrund von kABI-Kompatibilitätsproblemen nicht mehr funktionierte.
Nachdem sich herausstellte, dass das für RHEL 7.0 kompilierte Veeamsnap-Modul nicht mit dem Kernel von RHEL 7.5 kompatibel war, es aber geladen wurde und den Server garantiert zum Absturz brachte, haben wir die Verwendung der kABI-Kompatibilität für RHEL 7 ganz aufgegeben.
Derzeit enthält das KMOD-Paket für RHEL 7 eine Assembly für jede Release-Version und ein Skript, das das Modul lädt.
SUSE ging die Aufgabe der kABI-Kompatibilität sorgfältiger an. Sie bieten kABI-Kompatibilität nur innerhalb eines Service Packs.
Beispielsweise erfolgte die Veröffentlichung von SLES 12 im September 2014. Und SLES 12 SP1 erschien bereits im Dezember 2015, also ist etwas mehr als ein Jahr vergangen. Obwohl beide Versionen den 3.12-Kernel verwenden, sind sie kABI-inkompatibel. Offensichtlich ist es viel einfacher, die kABI-Kompatibilität nur ein Jahr lang aufrechtzuerhalten. Der jährliche Aktualisierungszyklus des Kernelmoduls sollte den Modulerstellern keine Probleme bereiten.
Aufgrund dieser SUSE-Richtlinie haben wir kein einziges Problem mit der kABI-Kompatibilität in unserem Veeamsnap-Modul festgestellt. Zwar ist die Anzahl der Pakete für SUSE fast eine Größenordnung höher.
Patches und Backports
Obwohl Distributoren versuchen, die kABI-Kompatibilität und Kernel-Stabilität sicherzustellen, versuchen sie auch, die Leistung zu verbessern und Fehler dieses stabilen Kernels zu beseitigen.
Gleichzeitig überwachen die Entwickler des Enterprise-Linux-Kernels zusätzlich zu ihrer eigenen „Arbeit an Fehlern“ Änderungen im Vanilla-Kernel und übertragen sie auf ihren „stabilen“ Kernel.
Manchmal führt dies zu neuen .
In der neuesten Version von Red Hat 6 wurde in einem der kleineren Updates ein Fehler gemacht. Dies führte dazu, dass das Veeamsnap-Modul bei der Veröffentlichung des Snapshots garantiert zum Absturz des Systems führte. Beim Vergleich der Kernel-Quellen vor und nach dem Update stellten wir fest, dass der Backport schuld war. Ein ähnlicher Fix wurde in der Vanilla-Kernel-Version 4.19 vorgenommen. Es ist nur so, dass dieser Fix im Vanilla-Kernel einwandfrei funktionierte, aber bei der Übertragung auf den „stabilen“ 2.6.32 trat ein Problem mit dem Spinlock auf.
Natürlich hat jeder immer Fehler, aber hat es sich gelohnt, den Code von 4.19 auf 2.6.32 zu ziehen und die Stabilität zu gefährden? Ich bin mir nicht sicher ...
Das Schlimmste ist, wenn sich das Marketing auf das Tauziehen zwischen „Stabilität“ und „Modernisierung“ einlässt. Die Marketingabteilung benötigt einerseits einen stabilen Kern der aktualisierten Distribution, andererseits eine bessere Leistung und neue Funktionen. Dies führt zu seltsamen Kompromissen.
Als ich versuchte, ein Modul auf Kernel 4.4 von SLES 12 SP3 zu erstellen, war ich überrascht, darin Funktionalität von Vanilla 4.8 zu finden. Meiner Meinung nach ähnelt die Block-I/O-Implementierung des 4.4-Kernels von SLES 12 SP3 eher dem 4.8-Kernel als der vorherigen Version des stabilen 4.4-Kernels von SLES12 SP2. Ich kann nicht beurteilen, wie viel Prozent des Codes von Kernel 4.8 auf SLES 4.4 für SP3 übertragen wurden, aber ich kann den Kernel nicht einmal als stabil 4.4 bezeichnen.
Das Unangenehmste daran ist, dass man sich beim Schreiben eines Moduls, das auf verschiedenen Kerneln gleich gut funktionieren würde, nicht mehr auf die Kernel-Version verlassen kann. Sie müssen auch die Verteilung berücksichtigen. Es ist gut, dass man sich manchmal auf eine Definition einlassen kann, die zusammen mit neuen Funktionen erscheint, aber diese Möglichkeit bietet sich nicht immer.
Infolgedessen wird der Code mit seltsamen Anweisungen zur bedingten Kompilierung überwuchert.
Es gibt auch Patches, die die dokumentierte Kernel-API ändern.
Ich bin auf die Distribution gestoßen 5.16 und war sehr überrascht, dass der Aufruf von lookup_bdev in dieser Kernel-Version die Liste der Eingabeparameter geändert hat.
Um es zusammenzubringen, musste ich dem Makefile ein Skript hinzufügen, das prüft, ob die Funktion „lookup_bdev“ einen Maskenparameter hat.
Signieren von Kernelmodulen
Aber kommen wir zurück zum Thema Paketverteilung.
Einer der Vorteile von stabilem kABI besteht darin, 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. Sie können dies mit dem Befehl modinfo überprüfen.
Mit Red Hat- und SUSE-Distributionen können Sie die Signatur des Moduls nur dann überprüfen und laden, wenn das entsprechende Zertifikat auf dem System registriert ist. Das Zertifikat ist der öffentliche Schlüssel, mit dem das Modul signiert wird. Wir vertreiben es als separates Paket.
Das Problem besteht darin, dass Zertifikate entweder in den Kernel integriert werden können (Distributoren verwenden sie) oder mithilfe eines Dienstprogramms in den nichtflüchtigen EFI-Speicher geschrieben werden müssen mokutil. Dienstprogramm mokutil Bei der Installation eines Zertifikats ist ein Neustart des Systems erforderlich und der Administrator wird bereits vor dem Laden des Betriebssystemkerns aufgefordert, das Laden eines neuen Zertifikats zuzulassen.
Daher erfordert das Hinzufügen eines Zertifikats physischen Administratorzugriff auf das System. Wenn sich die Maschine irgendwo in der Cloud oder einfach in einem Remote-Serverraum befindet und der Zugriff nur über das Netzwerk (z. B. per SSH) erfolgt, ist das Hinzufügen eines Zertifikats nicht möglich.
EFI auf virtuellen Maschinen
Obwohl EFI seit langem von fast allen Motherboard-Herstellern unterstützt wird, denkt der Administrator bei der Installation eines Systems möglicherweise nicht an die Notwendigkeit von EFI und es kann deaktiviert werden.
Nicht alle Hypervisoren unterstützen EFI. VMWare vSphere unterstützt EFI ab Version 5.
Microsoft Hyper-V erhielt ab Hyper-V für Windows Server 2012R2 auch EFI-Unterstützung.
In der Standardkonfiguration ist diese Funktionalität jedoch für Linux-Maschinen deaktiviert, was bedeutet, dass das Zertifikat nicht installiert werden kann.
Legen Sie in vSphere 6.5 die Option fest SICHERES BOOTEN nur in der alten Version des Webinterfaces möglich, die über Flash läuft. Die Web-Benutzeroberfläche auf HTML-5 liegt noch weit zurück.
Experimentelle Verteilungen
Und schließlich betrachten wir das Problem experimenteller Distributionen und Distributionen ohne offizielle Unterstützung. Einerseits ist es unwahrscheinlich, dass solche Distributionen auf den Servern seriöser Organisationen zu finden sind. Es gibt keine offizielle Unterstützung für solche Distributionen. Stellen Sie diese daher bereit. Das Produkt kann von einer solchen Distribution nicht unterstützt werden.
Allerdings werden solche Distributionen zu einer bequemen Plattform zum Ausprobieren neuer experimenteller Lösungen. Zum Beispiel Fedora, OpenSUSE Tumbleweed oder Unstable-Versionen von Debian. Sie sind recht stabil. Sie haben immer neue Programmversionen und immer einen neuen Kernel. In einem Jahr könnte diese experimentelle Funktionalität in einem aktualisierten RHEL, SLES oder Ubuntu landen.
Wenn also bei einer experimentellen Distribution etwas nicht funktioniert, ist das ein Grund, das Problem herauszufinden und zu lösen. Sie müssen darauf vorbereitet sein, dass diese Funktionalität bald auf den Produktionsservern der Benutzer verfügbar sein wird.
Sie können die aktuelle Liste der offiziell unterstützten Distributionen für Version 3.0 einsehen . Aber die tatsächliche Liste der Distributionen, auf denen unser Produkt funktionieren kann, ist viel umfangreicher.
Persönlich interessierte mich das Experiment mit dem Elbrus OS. Nachdem wir das Veeam-Paket fertiggestellt hatten, war unser Produkt installiert und funktionierte. Ich habe über dieses Experiment auf Habré geschrieben .
Nun, die Unterstützung für neue Distributionen geht weiter. Wir warten auf die Veröffentlichung der Version 4.0. Die Betaversion steht kurz vor der Veröffentlichung, also halten Sie die Augen offen !
Source: habr.com