Das Erstellen einer Sicherungsanwendung, die auf einer beliebigen Distribution ausgeführt wird, ist keine einfache Aufgabe. Um sicherzustellen, dass Veeam Agent für Linux auf Distributionen von RHEL 6 und Debian 6 ausgeführt wird, müssen openSUSE Leap 15.1 und Ubuntu 19.04 eine Reihe von Problemen lösen, insbesondere wenn Sie bedenken, dass das Kernelmodul Teil des Softwareprodukts ist.
Dieser Artikel basiert auf einer Präsentation auf der
LinuxPiter 2019- Konferenz.
Linux ist nicht nur eines der beliebtesten Betriebssysteme. In der Tat ist dies eine Plattform, auf deren Grundlage Sie etwas Einzigartiges tun können, etwas Eigenes. Aus diesem Grund hat Linux viele Distributionen, die sich in einer Reihe von Softwarekomponenten unterscheiden. Und hier tritt das Problem auf: Damit das Softwareprodukt auf jeder Distribution funktioniert, müssen Sie die jeweiligen Eigenschaften berücksichtigen.
Paketmanager. .deb vs .rpm
Beginnen wir mit dem offensichtlichen Problem, das Produkt für verschiedene Distributionen zu vertreiben.
Die typischste Methode zum Verteilen von Softwareprodukten besteht darin, das Paket im Repository abzulegen, damit der im System integrierte Paketmanager es von dort aus installieren kann.
Wir haben jedoch zwei beliebte Paketformate:
rpm und
deb . Also muss jeder unterstützen.
In der Welt der Deb-Pakete ist die Kompatibilität erstaunlich. Das gleiche Paket lässt sich gleich gut installieren und funktioniert sowohl unter Debian 6 als auch unter Ubuntu 19.04. Standards für den Prozess des Erstellens und Arbeitens mit Paketen, die in alten Debian-Distributionen festgelegt sind, bleiben in der neuen Linux Mint und dem elementaren Betriebssystem relevant. Daher ist im Fall von Veeam Agent für Linux ein Deb-Paket für jede Hardwareplattform ausreichend.
Aber in der Welt der Drehzahlpakete sind die Unterschiede groß. Erstens aufgrund der Tatsache, dass es zwei völlig unabhängige Distributoren von Red Hat und SUSE gibt, für die keine Kompatibilität erforderlich ist. Zweitens haben diese Distributoren Distributionen von diesen. Unterstützung und experimentell. Zwischen ihnen ist auch keine Kompatibilität erforderlich. Es stellte sich heraus, dass für el6, el7 und el8 ihre eigenen Pakete. Separates Paket für Fedora. Pakete für SLES11 und 12 und separat für openSUSE. Das Hauptproblem sind Abhängigkeiten und Paketnamen.
Abhängigkeitsproblem
Leider landen dieselben Pakete häufig unter unterschiedlichen Namen in unterschiedlichen Distributionen. Unten finden Sie eine unvollständige Liste der veeam-Paketabhängigkeiten.
Infolgedessen ist die Liste der Abhängigkeiten für die Verteilung eindeutig.
Es wird schlimmer, wenn sich eine aktualisierte Version unter dem alten Paketnamen versteckt.
Ein Beispiel:Fedora 24 hat das
ncurses- Paket von Version 5 auf Version 6 aktualisiert. Unser Produkt wurde mit Version 5 erstellt, um die Kompatibilität mit älteren Distributionen sicherzustellen. Um die alte 5. Version der Bibliothek unter Fedora 24 zu verwenden, musste ich das Paket
ncurses-compatible-libs verwenden .
Infolgedessen werden für Fedora zwei Pakete mit unterschiedlichen Abhängigkeiten angezeigt.
Interessanter. Nach dem nächsten Update des Distributionspakets ist das Paket
ncurses-compatible-libs mit der 5. Version der Bibliothek nicht verfügbar. Für einen Distributor ist es unrentabel, alte Bibliotheken in eine neue Distributionsversion zu ziehen. Nach einiger Zeit wurde das Problem in SUSE-Distributionen wiederholt.
Infolgedessen musste ich bei einigen Distributionen die explizite Abhängigkeit von
ncurses-libs aufgeben und das Produkt so reparieren, dass es mit jeder Version der Bibliothek funktioniert.
Übrigens gibt es in der 8. Version von Red Hat kein
Python -Metapaket mehr, das auf das gute alte
Python 2.7 verweist. Es gibt
Python2 und
Python 3.
Alternative zu Paketmanagern
Das Problem mit Abhängigkeiten ist alt und offensichtlich. Erinnern Sie sich einfach an die Abhängigkeitshölle.
Kombinieren Sie eine Vielzahl von Bibliotheken und Anwendungen, damit alle stabil funktionieren und keine Konflikte auftreten. Tatsächlich versucht jeder Linux-Distributor, dieses Problem zu lösen.
Der Canonical Package Manager
Snappy versucht, dieses Problem ganz anders zu lösen. Die Hauptidee: Die Anwendung wird in einer Sandbox ausgeführt, die vom Hauptsystem isoliert und geschützt ist. Wenn die Anwendung Bibliotheken benötigt, werden diese mit der Anwendung selbst geliefert.
Mit Flatpak können Sie auch Anwendungen in der Sandbox unter Verwendung von Linux-Containern ausführen. Es gibt auch
AppImage , mit dem Sie tragbare Bilder von Programmen erstellen können.
Mit diesen Lösungen können Sie ein Paket für alle Distributionen erstellen. Bei
Flatpak und
AppImage ist die Installation und der Start der Anwendung auch ohne Wissen des Administrators möglich.
Das Hauptproblem besteht darin, dass nicht alle Anwendungen in der Sandbox und ohne
Root- Rechte ausgeführt werden können. Einige benötigen direkten Zugriff auf die Plattform. Ich spreche nicht von Kernelmodulen, die stark vom Kernel abhängig sind und nicht in das Konzept der Sandbox passen.
Das zweite Problem ist, dass die beliebten Distributionen von Red Hat und SUSE in der Unternehmensumgebung Snappy und Flatpak noch nicht unterstützen.
In dieser Hinsicht ist Veeam Agent für Linux weder auf
snapcraft.io noch auf
flathub.org verfügbar .
Am Ende der Frage zu Paketmanagern stelle ich fest, dass es eine Option gibt, Paketmanager vollständig aufzugeben, indem Binärdateien und ein Skript kombiniert werden, um sie in einem Paket zu installieren.
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. Ich bin auf solche Pakete für Linux nur von VMware gestoßen.
Update-Problem
Selbst wenn alle Abhängigkeitsprobleme behoben sind, funktioniert das Programm möglicherweise auf derselben Distribution unterschiedlich. Der Punkt ist in den Updates.
Es gibt 3 Upgrade-Strategien:
- Am einfachsten ist es, niemals zu aktualisieren. Server konfiguriert und vergessen. Warum Updates, wenn alles funktioniert? Probleme treten auf, wenn Sie sich zum ersten Mal an den Support wenden. Der Ersteller der Distribution unterstützt nur eine 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 der manuellen Aktualisierung erst nach dem Ausführen in der Testinfrastruktur ist die zuverlässigste, aber teuerste und zeitaufwändigste. Nicht jeder kann es sich leisten.
Da verschiedene Benutzer unterschiedliche Update-Strategien verwenden, müssen Sie sowohl die neueste als auch alle zuvor veröffentlichten Versionen unterstützen. Dies verkompliziert den Entwicklungsprozess und der Testprozess bereitet dem Support-Service Kopfschmerzen.
Vielzahl von Hardware-Plattformen
Verschiedene Hardwareplattformen sind ein Problem, das weitgehend spezifisch für nativen Code ist. Sie müssen mindestens Binärdateien für jede unterstützte Plattform sammeln.
Im Veeam Agent für Linux-Projekt können wir immer noch nicht mindestens etwas RISC-ähnliches unterstützen.
Ich werde nicht im Detail auf dieses Thema eingehen. Ich werde nur die Hauptprobleme skizzieren: plattformabhängige Typen wie
size_t , Ausrichtung von Strukturen und Bytereihenfolge.
Statische und / oder dynamische Verknüpfung
Und hier ist die Frage: "Wie kann man dynamisch oder statisch auf Bibliotheken verlinken?" eine Diskussion wert.
In der Regel verwenden C / C ++ Linux-Anwendungen dynamische Verknüpfungen. Dies funktioniert hervorragend, wenn die Anwendung speziell für eine bestimmte Distribution erstellt wurde.
Wenn die Aufgabe darin besteht, eine Vielzahl von Distributionen mit einer Binärdatei abzudecken, müssen Sie sich auf die älteste unterstützte Distribution konzentrieren. Für uns ist dies Red Hat 6. Es enthält gcc 4.4, das selbst der C ++ 11-Standard nicht
vollständig unterstützt.
Wir erstellen unser Projekt mit gcc 6.3, das C ++ 14 vollständig unterstützt. In diesem Fall müssen in Red Hat 6 natürlich die libstdc ++ - und die Boost-Bibliothek mitgeschleppt werden. Der einfachste Weg, eine Verknüpfung zu ihnen herzustellen, ist statisch.
Leider können nicht alle Bibliotheken statisch verknüpft werden.
Erstens müssen Systembibliotheken wie
libfuse ,
libblkid dynamisch verknüpft werden, um sicherzustellen, dass sie mit dem Kernel und seinen Modulen kompatibel sind.
Zweitens gibt es eine Subtilität mit Lizenzen.
Die GPL-Lizenzierung erlaubt grundsätzlich die Verknüpfung von Bibliotheken nur mit OpenSource-Code. MIT und BSD ermöglichen die statische Verknüpfung und die Aufnahme von Bibliotheken in das Projekt. LGPL scheint der statischen Verknüpfung jedoch nicht zu widersprechen, sondern erfordert die Freigabe der für die Verknüpfung erforderlichen Dateien.
Im Allgemeinen schützt die Verwendung der dynamischen Verknüpfung vor der 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 kompilieren und Cross-Compiler für bestimmte Architekturen zu verwenden, um den gesamten Satz von Bibliotheken zu sammeln. Diese Arbeit ist durchaus machbar, aber ziemlich mühsam. Es gibt keine Garantie dafür, dass der ausgewählte Compiler und die ausgewählten Bibliotheken eine funktionsfähige Option bieten.
Ein offensichtliches Plus: Die Infrastruktur ist stark vereinfacht, da der gesamte Montageprozess auf einer Maschine durchgeführt werden kann. Darüber hinaus reicht es aus, einen Satz von 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 für Linux erstellt.
Im Gegensatz zu dieser Option können Sie einfach die Buildfarm vorbereiten, dh mehrere Maschinen für die Montage. Jede solche Maschine bietet eine Zusammenstellung der Anwendung und Zusammenstellung des Pakets für eine bestimmte Distribution und eine bestimmte Architektur. In diesem Fall erfolgt die Kompilierung mit den Mitteln, die der Distributor vorbereitet hat. Das heißt, die Compiler-Vorbereitungsphase und die Auswahl der Bibliotheken werden nicht mehr benötigt. Darüber hinaus kann der Montageprozess einfach parallelisiert werden.
Dieser Ansatz hat jedoch ein Minus: Für jede Distribution innerhalb derselben Architektur müssen Sie Ihre eigenen Binärdateien zusammenstellen. Ein Minus ist auch, dass so viele Maschinen gewartet werden müssen, um eine große Menge an Speicherplatz und RAM zuzuweisen.
Auf diese Weise werden die KMOD-Pakete des veeamsnap-Kernelmoduls für Red Hat-Distributionen zusammengestellt.
Open Build Service
SUSE-Kollegen versuchten, einen Mittelweg als speziellen Service zum Kompilieren von Anwendungen und
Erstellen von Paketen zu
implementieren -
openbuildservice .
Tatsächlich ist es ein Hypervisor, der eine virtuelle Maschine erstellt, alle erforderlichen Pakete darin installiert, die Anwendung kompiliert und das Paket in dieser isolierten Umgebung kompiliert. Danach wird eine solche virtuelle Maschine freigegeben.
Der in OpenBuildService implementierte Scheduler bestimmt, wie viele virtuelle Maschinen für die optimale Geschwindigkeit beim Erstellen von Paketen ausgeführt werden können. Der integrierte Signaturmechanismus selbst signiert die Pakete und legt sie im integrierten Repository ab. Das integrierte Versionskontrollsystem speichert den Verlauf von Änderungen und Baugruppen. Es bleibt einfach, Ihren Quellcode zu diesem System hinzuzufügen. Auch der Server selbst muss nicht angehoben werden, aber Sie können den offenen verwenden.
Hier gibt es jedoch ein Problem: Ein solcher Mähdrescher lässt sich nur schwer in die vorhandene Infrastruktur einfügen. Zum Beispiel ist keine Versionskontrolle erforderlich, wir haben bereits eine eigene für die Quellen. Der Signaturmechanismus ist anders: Es wird ein spezieller Server verwendet. Das Repository wird ebenfalls nicht benötigt.
Darüber hinaus ist die Unterstützung für andere Distributionen - zum Beispiel Red Hat - eher schlecht implementiert, was verständlich ist.
Der Vorteil dieses Dienstes ist die schnelle Unterstützung der nächsten Version der SUSE-Distribution. Vor der offiziellen Veröffentlichung werden die für die Montage erforderlichen Pakete in das öffentliche Repository hochgeladen. Eine neue wird in der Liste der verfügbaren Distributionen auf OpenBuildService angezeigt. Wir setzen ein Häkchen und es wird dem Montageplan hinzugefügt. Das Hinzufügen einer neuen Version der Distribution erfolgt somit mit fast einem Klick.
In unserer Infrastruktur stellen wir mithilfe des OpenBuildService die gesamte Vielfalt der KMP-Pakete des veeamsnap-Kernelmoduls für SUSE-Distributionen zusammen.
Darüber hinaus möchte ich auf Kernelmodule eingehen.
Kernel ABI
Linux-Kernelmodule wurden in der Vergangenheit in Quellform verteilt. Tatsache ist, dass sich die Entwickler des Kernels nicht mit der Sorgfalt belasten, eine stabile API für Kernelmodule aufrechtzuerhalten, und dies erst recht auf binärer Ebene als bei kABI.
Um ein Modul für den Vanilla-Kernel zu erstellen, sind Header dieses bestimmten Kernels erforderlich, und es funktioniert nur auf diesem Kern.
Mit DKMS können Sie den Assemblierungsprozess von Modulen beim Aktualisieren des Kernels automatisieren. Infolgedessen verwenden Benutzer des Debian-Repositorys (und seiner vielen Verwandten) Kernelmodule entweder aus dem Distributor-Repository oder werden mithilfe von DKMS aus dem Quellcode zusammengestellt.
Diese Situation ist jedoch im Enterprise-Segment nicht besonders angenehm. Proprietäre Code-Distributoren möchten das Produkt in Form kompilierter Binärdateien vertreiben.
Administratoren möchten aus Sicherheitsgründen keine Entwicklungstools auf Produktionsservern behalten. Enterprise Linux-Distributoren wie Red Hat und SUSE haben entschieden, dass sie ihren Benutzern einen stabilen kABI bieten können. Als Ergebnis wurden KMOD-Pakete für Red Hat und KMP-Pakete für SUSE angezeigt.
Das Wesentliche dieser Lösung ist recht einfach. Die Kernel-API ist für eine bestimmte Version der Distribution eingefroren. Der Distributor erklärt, dass er den Kernel verwendet, z. B. 3.10, und nimmt nur Korrekturen und Verbesserungen vor, die die Kernel-Schnittstellen in keiner Weise beeinflussen. Die für den allerersten Kernel zusammengestellten Module können ohne Neukompilierung für alle nachfolgenden verwendet werden.
Red Hat kündigt die kABI-Kompatibilität für die Verteilung über den gesamten Lebenszyklus an. Das heißt, das zusammengestellte Modul für Rhel 6.0 (Version November 2010) sollte auch mit Version 6.10 (Version Juni 2018) funktionieren. Und das sind fast 8 Jahre. Die Aufgabe ist natürlich ziemlich kompliziert.
Wir haben mehrere Fälle aufgezeichnet, in denen das veeamsnap-Modul aufgrund von Problemen mit der kABI-Kompatibilität 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, aber den Server geladen und garantiert fallen ließ, haben wir uns geweigert, die kABI-Kompatibilität für RHEL 7 im Allgemeinen zu verwenden.
Derzeit enthält das KMOD-Paket für RHEL 7 eine Assembly für jede Release-Version und ein Skript, das das Laden von Modulen ermöglicht.
SUSE ging die kABI-Kompatibilitätsaufgabe genauer an. Sie bieten kABI-Kompatibilität in nur einem Service Pack.
Zum Beispiel fand die Veröffentlichung von SLES 12 im September 2014 statt. Und SLES 12 SP1 ist bereits im Dezember 2015, dh etwas mehr als ein Jahr ist vergangen. Obwohl beide Releases den 3.12-Kernel verwenden, sind sie nicht mit kABI kompatibel. Offensichtlich ist es viel einfacher, die kABI-Kompatibilität nur ein Jahr lang aufrechtzuerhalten. Der jährliche Aktualisierungszyklus des Kernmoduls sollte den Erstellern der Module keine Probleme bereiten.
Aufgrund dieser SUSE-Richtlinie konnten wir keine Probleme mit der kABI-Kompatibilität in unserem veeamsnap-Modul beheben. Die Anzahl der Pakete für SUSE ist zwar fast eine Größenordnung größer.
Patches und Backports
Trotz der Tatsache, dass Distributoren versuchen, die kABI-Kompatibilität und die Kernelstabilität sicherzustellen, versuchen sie auch, die Leistung zu verbessern und Fehler in diesem stabilen Kernel zu beseitigen.
Zusätzlich zu ihrer eigenen „Arbeit an Fehlern“ verfolgen die Entwickler des Enterprise Linux-Kernels Änderungen im Vanilla-Kernel und übertragen sie auf ihren „stabilen“.
Manchmal führt dies zu neuen
Fehlern .
Die neueste Version von Red Hat 6 hat bei einem der kleineren Updates einen Fehler gemacht. Dies führte dazu, dass das veeamsnap-Modul das System garantiert zum Absturz brachte, wenn der Snapshot veröffentlicht wurde. Beim Vergleich der Kernelquellen vor und nach dem Update haben wir herausgefunden, dass der Backport schuld ist. Ein ähnlicher Fix wurde in der Vanillekernversion 4.19 vorgenommen. Aber nur im Vanillekern funktionierte dieser Fix einwandfrei, und beim Übertragen auf den „stabilen“ 2.6.32 gab es ein Problem mit dem Spin-Lock.
Natürlich hat jeder immer Fehler, aber hat es sich gelohnt, den Code von 4.19 auf 2.6.32 zu ziehen, um Stabilität zu riskieren? Ich bin mir nicht sicher ...
Am schlimmsten ist es, wenn Marketing an das Tauziehen gebunden ist: „Stabilität“ <-> „Modernisierung“. Die Marketingabteilung benötigt einerseits den Kern der aktualisierten Distribution, um stabil zu sein, gleichzeitig eine bessere Leistung zu erzielen und neue Funktionen zu haben. 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 von Vanilla 4.8 darin zu finden. Meiner Meinung nach ähnelt die Implementierung von Block-E / A des Kernels 4.4 aus SLES 12 SP3 eher einem 4.8-Kernel als der vorherigen Version des stabilen 4.4-Kernels aus SLES12 SP2. Ich kann nicht beurteilen, wie viel Prozent des Codes vom 4.8-Kernel auf das SLES 4.4 für SP3 übertragen wurden, aber ich habe immer noch keine Chance, den Kernel als denselben stabilen 4.4-Kernel zu bezeichnen.
Das Unangenehmste daran ist, dass Sie sich beim Schreiben eines Moduls, das auf verschiedenen Kernen gleich gut funktioniert, nicht mehr auf die Kernel-Version verlassen können. Wir müssen auch die Verteilung berücksichtigen. Es ist gut, dass Sie sich manchmal auf eine Definition einlassen können, die zusammen mit neuen Funktionen angezeigt wird. Diese Funktion wird jedoch nicht immer angezeigt.
Infolgedessen ist der Code von ausgefallenen Anweisungen zur bedingten Kompilierung umgeben.
Es gibt auch Patches, die die dokumentierte Kernel-API ändern.
Ich bin auf ein
KDE neon 5.16-Distributionskit gestoßen und war sehr überrascht zu sehen, dass der Aufruf von lookup_bdev in dieser Kernelversion die Liste der Eingabeparameter geändert hat.
Um zusammenzukommen, mussten wir dem Makefile ein Skript hinzufügen, das prüft, ob die Funktion lookup_bdev einen Maskenparameter hat.
Signatur der Kernelmodule
Aber 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 geändert wurde. Sie können dies mit dem Befehl modinfo überprüfen.
Mit Red Hat- und SUSE-Distributionen können Sie die Signatur eines Moduls überprüfen und nur herunterladen, wenn das entsprechende Zertifikat im System registriert ist. Das Zertifikat ist der öffentliche Schlüssel, mit dem das Modul signiert wird. Wir vertreiben es als separates Paket.
Das Problem hierbei ist, dass Zertifikate entweder in den Kernel integriert werden können (sie werden von Distributoren verwendet) oder mit dem Dienstprogramm
mokutil in den nichtflüchtigen EFI-Speicher geschrieben werden
müssen . Bei der Installation des Zertifikats
erfordert das Dienstprogramm
mokutil einen Neustart des Systems. Noch bevor der Kernel des Betriebssystems geladen wird, bietet es dem Administrator die Möglichkeit, das Herunterladen des neuen Zertifikats zuzulassen.
Das Hinzufügen eines Zertifikats erfordert daher physischen Zugriff des Administrators auf das System. Befindet sich der Computer irgendwo in der Cloud oder nur in einem Remote-Serverraum und der Zugriff erfolgt nur über das Netzwerk (z. B. über ssh), kann kein Zertifikat hinzugefügt werden.
EFI auf virtuellen Maschinen
Trotz der Tatsache, dass EFI seit langem von fast allen Entwicklern des Motherboards unterstützt wird, denkt der Administrator bei der Installation des Systems möglicherweise nicht über die Notwendigkeit von EFI nach und kann deaktiviert werden.
Nicht alle Hypervisoren unterstützen EFI. VMWare vSphere unterstützt EFI seit Version 5.
Microsoft Hyper-V erhielt auch EFI-Unterstützung, beginnend mit Hyper-V für Windows Server 2012R2.
In der Standardkonfiguration ist diese Funktionalität jedoch für Linux-Computer deaktiviert. Dies bedeutet, dass das Zertifikat nicht installiert werden kann.
In vSphere 6.5 können Sie die Option "
Sicherer Start " nur in der alten Version der Weboberfläche festlegen, die über Flash funktioniert. Die Web-Benutzeroberfläche von HTML-5 liegt weit zurück.
Experimentelle Verteilungen
Betrachten Sie schließlich das Thema experimentelle Verteilungen und Verteilungen ohne offizielle Unterstützung. Einerseits ist es unwahrscheinlich, dass solche Distributionen auf den Servern seriöser Organisationen gefunden werden. Es gibt keine offizielle Unterstützung für solche Distributionen. Daher, um diese bereitzustellen. Produktunterstützung bei einer solchen Distribution ist nicht möglich.
Solche Verteilungen werden jedoch zu einer bequemen Plattform zum Testen neuer experimenteller Lösungen. Zum Beispiel Fedora, OpenSUSE Tumbleweed oder die instabile Version von Debian. Sie sind ziemlich stabil. Sie haben immer neue Versionen von Programmen und immer einen neuen Kernel. Nach einem Jahr kann diese experimentelle Funktionalität im aktualisierten RHEL, SLES oder Ubuntu enthalten sein.
Wenn also etwas mit dem experimentellen Verteilungskit nicht funktioniert, ist dies eine Gelegenheit, das Problem zu lösen und es zu lösen. Sie müssen darauf vorbereitet sein, dass diese Funktionalität bald auf den Produktionsservern der Benutzer angezeigt wird.
Die aktuelle Liste der offiziell unterstützten Distributionen für Version 3.0 finden Sie
hier . Die tatsächliche Liste der Distributionen, an denen unser Produkt arbeiten kann, ist jedoch viel umfangreicher.
Persönlich war ich an einem Experiment mit dem Elbrus OS interessiert. Nach der Aktualisierung des veeam-Pakets wurde unser Produkt installiert und verdient. Über dieses Experiment habe ich in einem
Artikel über Habré geschrieben.
Nun, die Unterstützung für neue Distributionen geht weiter. Wir warten auf die Veröffentlichung von Version 4.0. Beta wird
bald erscheinen, also
seid gespannt auf das Neue !