Mit Red Hat Network Satellite und SUSE Manager gibt es zwei Management-Suiten für die Linux Enterprise-Distributionen Red Hat Enterprise Linux und SUSE Linux Enterprise Server.

Auf den ersten Blick sehen die beiden Produkte gleich aus und auch aus technischer Sicht gibt es starke Ähnlichkeiten, da die Produkte beide auf der selben quelloffenen Software-Kernkomponenten aufbauen: Spacewalk. Spacewalk wurde 2008 durch Red Hat als Open-Source freigegeben und bildet die Basis für den kommerziellen Satellite Server.

Wo genauen liegen also die Unterschiede zwischen den Produkten? Die folgende Tabelle zeigt die Gemeinsamkeiten und Detailunterschiede:

Zentrale Verwaltung von RHEL- und SLES-Systemen mit einer Suite?

Was für Möglichkeiten bestehen für den Fall, dass RHEL- und SLES-Systeme parallel betrieben und zentral verwaltet werden sollen?

Genau die Frage habe ich mir auch gestellt, im Internet recherchiert und über Twitter einen Kontakt zu SUSE geknüpft.

Letztendlich gibt es zwei denkbare Möglichkeiten - ob diese praktikabel sind, liegt im eigenen Ermessen des Administrators.

1.Möglichkeit - SUSE Expanded Support

Im Rahmen des "SUSE Expanded Support" bietet SUSE neben den eigenen SLES-Patches auch digitale Flicken für RHEL. Das Ganze ist für langwierige Migrationen gedacht und soll den Red Hat Support überflüssig machen, da Patches nicht mehr direkt über das Red Hat Network bezogen werden. Die Patches kommen direkt von SUSE, wo sie aus den von Red Hat veröffentlichten Quellcodes übersetzt werden. Letztendlich sollte die Qualität der Software-Pakete die selbe sein, da sie ja dem gleichen Quellcode entspringen - ich persönlich würde es jedoch bevorzugen, meine Distributionspatches auch vom ursprünglichen Distributor zu erhalten.

Wenn man nicht gerade eine Migration plant und lediglich beabsichtigt, das Beste aus beiden "Welten" zu kombinieren, ist dieser Lösungsansatz meiner Meinung nach nicht der Beste.

2.Möglichkeit - mrepo

Eine andere Möglichkeit wäre die Verwendung eines Tools namens mrepo. Dieses Programm legt einen Spiegel eines YUM-Repositories an und stellt so die jeweiligen RPM-Pakete lokal zur Verfügung - laut Webseite soll das auch mit RHN-Kanälen möglich sein. Ich kann mir nur schwer vorstellen, dass diese Lösung lizenzrechtlich unbedenklich ist, da das lokale Vorhalten von RPM-Paketen aus dem RHN ja bewusst erschwert wird. In aller Regel soll das lokale Cachen nur über den RHN Satellite Server erfolgen.

Für Testzwecke wäre das sicherlich eine denkbare Lösung, in produktiven Umgebungen, in welchen ein sauberer Support-Status stets gegeben sein muss, würde ich von diesem Ansatz jedoch Abstand nehmen.

Fazit

Letztendlich handelt es sich bei RHN Satellite und SUSE Manager um identische Produkte (quasi "das Selbe in grün"  😛) - an eine unkomplizierte Kombination von beiden "Welten" ist jedoch leider nicht zu denken.

Das Problem ist dabei weniger technischer, sondern lizenzrechtlicher Natur, wie ich kürzlich in einem Gespräch mit einem SUSE-Mitarbeiter erfahren habe. Die Gründe sind natürlich auch nachvollziehbar - die Hersteller wollen natürlich in erster Linie ihr eigenes Produkt "an den Mann bringen", um konkurrenzfähig zu bleiben.

Wenn man beide Produkte verwendet und eine zentrale Management-Suite sucht, muss man sich meiner Meinung nach entweder für eine Migration der anderen Systemlandschaft entscheiden oder mehr Geld in die Hand nehmen, um beide Produkte parallel zu betreiben. Alternativ kann man sich auch eines Tricks bedienen, um RPM-Pakete aus dem Red Hat Network zwischenzuspeichern und zu verteilen. Wenn es keine Rolle spielt, woher die zu installierenden RHEL-Patches stammen, kann man auch auf den "SUSE Expanded Support" zurückgreifen.

Ich persönlich lege großen Wert auf lückenlosen Support durch den ursprünglichen Distributor und würde mich daher in jedem Fall für die Implementation beider Management-Produkte entscheiden.

Galerie

Anbei noch einige Screenshots der einzelnen Management-Suiten.