© Coloures-pic, Fotolia

Suse verspricht eine starke und zugleich mutige neue SLES-Version: Ein Gnome-Desktop, der Langzeit-Kernel 3.12, Btr-FS als Standarddateisystem, dazu Tools wie Snapper, das Ruby-Yast und ein Geo-HA-Add-on für Suses traditionelle Stärke Hochverfügbarkeit lassen hoffen.

Ein bisschen erinnert die aktuelle Situation an den Werbespot für Geschirrreiniger: Während man in Villa Red Hat und Villa Ubuntu schon feiert, wird in Villa Suse noch hart gearbeitet.

Spät, aber …

Vergleichen mit den roten Hüten und der Truppe von Mark Shuttleworth scheinen die Nürnberger bei der Enterprise-Parade mit ihrem Suse Linux Enterprise Server [1] tatsächlich etwas im Hintertreffen. Ubuntu 14.04 erschien pünktlich im April [2], auch RHEL 7 tritt schon sein Juni 2014 an, den Markt zu erobern [3]. Aber weil Enterprise-Kunden üblicherweise deutlich langfristiger planen als Desktop-User ist der Innovationsdruck nicht so hoch.

Auch sind Admins Gewohnheitstiere: Wer Suse-Systeme kennt, wird nicht ausschließlich deshalb auf Red Hat wechseln, weil dort die neue Enterprise-Distribution schneller fertig ist. Dementsprechend geduldig gebärdete sich die SLES-Gemeinde in der letzten Zeit. Immerhin hat SLES 11 schon mehr als fünf Jahre auf dem Buckel, das letzte Update kam in Form von Service Pack 3 Mitte 2013 [4].

Doch nun hat Suse seine Hausaufgaben gemacht. Seit Mitte Oktober finden sich Release Notes auf der Suse-Webseite [5], mit der offiziellen Dokumentation wollen sich die Nürnberger allerdings noch bis zur finalen Release im vierten Quartal Zeit lassen [6].

Ein grüner USB-Stick auf Reisen

Aber bereits Ende September landete ein grüner USB-Stick mit Suse-Logo exklusiv in der Linux-Magazin-Redaktion. Auf dem lag ein Image, das die aktuelle Vorserienvariante von SLES 12 einschließlich des Plugins für Hochverfügbarkeit enthielt. Da durfte das Linux-Magazin einen ersten Blick auf das werfen, was man sich in Nürnberg ausgedacht hat, um Enterprise-Kunden die nächsten Jahre bei Laune zu halten.

Wie überall bei den langlebigen Enterprise-Distributionen gilt natürlich auch für Suse: Was in der neuen Version von SLES so kaputt ist, dass es sich nicht per Update im Nachhinein korrigieren lässt, hängt dem Support-Team über die nächsten Jahre wie ein Klotz am Bein und nervt außerdem die Admins. Trotzdem kommt SLES 12 mit einigen größeren Veränderungen einher: Unter anderem ist Btr-FS in Zukunft das Standarddateisystem. Mangelnden Mut wollen die SLES-Entwickler sich also offensichtlich nicht nachsagen lassen.

Aller Anfang

In den vorläufigen Release Notes zu SLES 12 stellt Suse gleich klar, dass bereits der Installer verschiedene Modifikationen durchlaufen hat. Wer SLES 11 schon mal installiert hat, würde das aber auch ohne den separaten Hinweis erkennen: Verglichen mit den vorangegangenen Versionen mutet der SLES-12-Installer eher trist an, da farblich sehr dunkel gehalten (Abbildungen 1 und 2). Ob der Hintergrund nur in der Vorserienversion so ist oder ob das tatsächlich das neue Design des SLES-Installers ist, ließ sich kurzfristig nicht mehr klären.

Abbildung 1: Eher für Menschen mit geringen Lichtansprüchen eignet sich der neue SLES-Installer, der aus unerfindlichen Gründen sehr düster geraten ist.

Abbildung 2: Nach der Installation erscheint der gewohnte Bootloader, der die Wahl zwischen normalem Boot und Rettungssystem lässt.

Technisch lässt sich der Installer nichts nachsagen: Wie gewohnt erledigt er seine Arbeit routiniert und installiert ein Basissystem auf der Platte, das der Nutzer danach mit entsprechenden Paketen per Yast in einen der Suse-Flavours verwandelt. Dazu bietet der Installer die Möglichkeit, bereits während der Installation die von Suse erhaltenen Credentials in die Maske einzugeben und das System bei Suse zu registrieren (Abbildung 3).

Abbildung 3: Mittels Eingabe des Registrierungscodes lassen sich in Yast nun Features der Add-on-Module freischalten, was sehr bequem ist.

Dann erscheint im Installer automatisch eine Liste aller verfügbaren Add-ons, die sich auf die gleiche Weise ins System integrieren lassen. Am Ende des Vorgangs steht ein SLES-System, das bereits mit allen verfügbaren Sicherheitsupdates betankt ist und auch die Paketquellen nutzt, auf die der Admin über seine Zugangscodes eine Zugriffsmöglichkeit hat (Abbildung 4).

Abbildung 4: Ebenfalls vorbei sind die Zeiten, in denen Repositories in Yast händisch einzutragen waren. Darum kümmert sich nun der Registration Server.

SLES und SLE

Die Bezeichnung SLES 12 ist eigentlich nicht mehr zutreffend, bezeichnet sie doch automatisch den Suse Linux Enterprise Server und schiebt das von Suse bearbeitete Produkt gleich ab in die Serverecke. Tatsächlich ist das, was Suse der Redaktion zukommen ließ, korrekt eigentlich mit SLE 12 tituliert. Dabei steht der Name SLE für die “Suse Linux Enterprise”-Plattform per se.

Der Server ist in dieser Lesart lediglich ein Add-on auf Basis von SLE. Suse führt die in SLE 11 eingeführte Tradition fort: SLE 12 stellt den Kern dar, auf dessen Basis sich anschließend Produkte wie der Server, der Desktop (wahlweise auch als “Workstation” bezeichnet) und die Suse-typischen Add-ons versammeln – zuerst denken Admins bei der Kategorie freilich an das HA-Add-on.

Ein Meilenstein in Varianten

Red Hat verfolgt im Ansatz ein ähnliches Prinzip, auch wenn die Plattform bei den roten Hüten im Grunde eine vollständige Serverplattform ist. Auf die setzt RH dann einfach Zusatzkomponenten drauf, etwa beim Red Hat Storage Server [7]. Fakt ist: Mit der Idee einer relativ kleinen Kern-Plattform ist Suse in guter Gesellschaft, auch wenn SLE als separates Produkt wohl nicht verfügbar sein wird, darf die Version 12 als wichtiger Meilenstein in die Suse-Geschichte eingehen. An SLE 12 sind Wohl und Wehe von Suse unmittelbar gebunden.

Suse nutzt die Möglichkeit, auf Basis der eigenen Technik-Plattform einzelne Produkte aus dem Boden zu stampfen, erwartungsgemäß konsequent. SLES 12 wird in mehreren Varianten erhältlich sein: Der Klassiker ist natürlich SLES 12, der eigentliche Server. Für SLES 12 gibt es Add-on-Pakete: Hochverfügbarkeit und Geo-Hochverfügbarkeit (also geografisch verteilte Cluster) sowie Add-ons für Suses künftigen Management-Dienst Advanced Systems Management, ein Kit für Software-Entwicklung auf SLES 12 und ein Legacy-Modul für Kompatibilität mit vorangegangenen SLES-Versionen.

Von der Cloud bis zum Desktop

Es gibt ein Public Cloud Module und die Suse Linux Enterprise Workstation Extension, die SLES um einzelne Teile des Enterprise-Desktops erweitert. Hinzu kommen separate Produkte, die auf der Basis von SLE 12 entstanden sind, aber nicht den Server benötigen – typisches Beispiel dafür ist natürlich der Enterprise-Desktop, also SLED.

Während von den gerade aufgezählten Modulen die meisten in der SLES-Lizenz enthalten sind, werden für andere Erweiterungen Zusatzgebühren fällig, zum Beispiel für die HA-Erweiterung. Etwas chaotisch wirkt das schon, doch erläutert das Modul von Yast, das die Erweiterungen verwaltet, für jede davon wenigstens, worum es geht und ob die Nutzung über die SLES-Lizenz möglich ist.

Ruby macht alles neu und schnell in Yast

Der erste Boot in das neue System nach der SLES-Installation führt zu einem Gnome-Desktop, der durchaus als aufgeräumt gelten darf. Weil im Test nur die SLES-Extension auf Basis von SLE zum Einsatz kam, fehlten die Komponenten der Workstation und auch jeder andere grafische Schnickschnack. Weil Admins sich dem System in aller Regel ohnehin per SSH nähern werden, ist der Desktop von SLES 12 aber mehr als ausreichend (Abbildung 5).

Abbildung 5: Auf das Nötigste reduziert präsentiert sich der Desktop von SLES 12, bekanntlich spielen auf Servern andere Werte eine Rolle als das UI.

Wollen Admins den SSH-Zugang auf SLES 12 aktivieren, tun sie das vermutlich über Yast. Wenn sie dabei die grafische Version von Yast nutzen, werden sie nicht schlecht staunen: Das Tool ist im Vergleich mit SLE 11 nämlich nicht mehr wiederzuerkennen.

Der Grund dafür ist aufmerksamen Open-Suse-Nutzern bereits bekannt: Suse hatte bereits 2013 beschlossen, Yast vollständig neu zu schreiben. Die alte Version war in der eigenen Programmiersprache YCP (Yast Control – oder auch Programming – Language) verfasst, die viele Yast-Entwickler leid waren [8].

Für den Rewrite fiel die Entscheidung auf eine Standardsprache: Das neue Yast kommt in Ruby daher – und übertrifft den Vorgänger in Sachen Geschwindigkeit deutlich. Allerdings gefiel die Oberfläche des alten Yast den Testern besser, weil sie übersichtlicher daherkommt. Die aktuelle Oberfläche des neuen Yast erinnert dagegen in ihrem Aufbau an das Kontrollzentrum von KDE oder den Einrichtungsdialog von Xfce (Abbildung 6). Wenn entsprechend viele Tiles für einzelne Module vorhanden sind, wird das Fenster schnell unübersichtlich.

Abbildung 6: Yast sieht nach dem Rewrite in Ruby eher den Kontrollzentren der gängigen Desktop-Environments ähnlich als seinem Vorgänger.

Zu viele unerklärliche Yast-Abstürze

Ein weiterer Umstand gab im Test Grund zur Sorge: Das neue Yast stürzte mehrfach bei Aktionen ab, die durchaus alltäglich sind. Beim Versuch, den Geo-Teil des HA-Add-ons zu aktivieren, beschwerte Yast sich zum Beispiel per Fehlermeldung, dass es die angeforderte URL nicht erreichen könnte – um im Anschluss klammheimlich zu verschwinden. Ein ähnliches Malheur ereignete sich bei dem Versuch, ein Online-Update in Gang zu setzen. Yast monierte, dass noch keine Update-Repositories aktiviert seien, bevor es erneut den Dialog zur Registrierung des Systems bei Suse anzeigte – und dann einging.

Das Problem konnten die Tester zwar über das Yast-Modul zur Paketinstallation umgehen, dennoch bleibt zu hoffen, dass Suse zwischen der vorliegenden Version und der fertigen Release des Produkts besonders bei Yast noch mal auf Fehlersuche geht. De facto ist ein Rewrite in Ruby sehr zu begrüßen und es wäre schade, wenn Admins sich wegen mangelnder Qualität vom neuen Yast abwenden.

Snapshots mit Btr-FS

Dass SLE der Kern von SLES ist, rückt ihn natürlich in den Fokus des Interesses. In den Release Notes weist Suse denn auch gewissenhaft darauf hin, dass SLE gleich mehrere elementare Unterschiede zu seinem Vorgänger aufweist: An erster Stelle steht dabei das Dateisystem: SLE kommt mit Btr-FS als Standard fürs Root-FS und ist damit die erste Distribution, die sich in diesem Maße davon abhängig macht.

Kein PR-Gag

Und Suse stellt klar, dass es sich dabei nicht um einen PR-Gag handelt. Die Firma hatte in den letzten Jahren einige Entwicklerressourcen abgestellt, um Btr-FS in SLE sinnvoll zu integrieren. Herausgekommen sind Tools wie Snapper [9], ein überaus pfiffiges Werkzeug, mit dem sich Snapshots über das ganze Dateisystem hinweg anlegen lassen. Weil Btr-FS Snapshots als fixes Feature integriert hat, war es für Suse also nur logisch, auf Btr-FS und nicht auf ein anderes Dateisystem zu setzen.

Snapper erlaubt es dem Admin, Snapshots von beliebigen Dateien, Ordnern oder vom ganzen Dateisystem nach Belieben anzulegen, zu löschen oder als Backup an einem anderen Ort abzulegen. Admins erspart das unter Umständen viel Arbeit: In SLE 12 ist es beispielsweise kein Problem, vor einem System-Update per Snapper einen Snapshot des gesamten Dateisystems anzulegen.

Klappt das Update ohne Schwierigkeiten, freut sich der Admin – und falls das Update schiefgeht, freut er sich auch: Über den Btr-FS-Snapshot kann er jederzeit den Zustand des Systems vor dem Update wiederherstellen. Lediglich »/boot« ist von diesem Mechanismus nicht erfasst: Derzeit ist es noch unmöglich, von einer Btr-FS-Partition zu booten. »/boot« liegt deshalb stets auf einer eigenen Partition und nutzt ein anderes Dateisystem. Falls ein komplettes System-Upgrade also per Snapshot ungeschehen gemacht werden soll, ist ein eventuell installierter Kernel manuell zu entfernen. Mehr Einschränkungen gibt es aber nicht.

Willkommen Systemd!

Unter der SLE-12-Haube haben sich einige Änderungen ergeben, die Admins auf den ersten Blick vermutlich gar nicht wahrnehmen werden. So kommt nicht mehr das angestaubte Sys-V-Init zum Einsatz, sondern Systemd, an dem sich die Geister bekanntlich heftig scheiden. Suse nimmt im SLE-12-Changelog beinahe wehmütig Abschied von System V und bezeichnet es gar als “altehrwürdig”. Dass die Admins dem alten Schinken besonders lange nachtrauern, ist indes zweifelhaft. Im Vergleich zur Vorversion bootet SLE 12 deutlich schneller, weil es diverse Vorgänge parallel abarbeiten kann. Das unterscheidet es maßgeblich von seinem Vorgänger.

Gar nicht gerissen: Der Netzwerkmanager Wicked

Im Fahrwasser von Systemd bringt SLE zwölf zusätzliche Neuerungen mit, ein Beispiel hierfür ist der neue Netzwerkmanager Wicked ([10], Abbildungen 7 und 8). Dabei handelt es sich um eine Eigenentwicklung, die Suse zunächst in Open Suse getestet hat und nun als reif genug für den produktiven Enterprise-Einsatz betrachtet.

Abbildung 7: Zwar wirkt in Yast auf den ersten Blick die Konfiguration des Netzes wie gewohnt, doch ein Blick in die Prozesstabelle zeigt, dass …

Abbildung 8: … auf SLES 12 der neue Netzwerkmanager Wicked die Netzwerkkonfiguration übernimmt, ein eigens zu diesem Zweck geschriebenes Werkzeug.

Oberflächlich betrachtet bleibt alles beim Alten: Nach außen hin lässt sich das Netzwerk über Yast nach wie vor konfigurieren wie zuvor, auch die vorhandenen Konfigurationsdateien von Suse-Systemen kann der Admin weiterhin ohne Einschränkung nutzen. Doch wer sich an Yast vorbei mit der Netzwerkkonfiguration beschäftigen will, zum Beispiel fürs Debugging, muss umdenken. Denn Wicked ist tief in Dbus integriert und kommt mit einem eigenen Kommandozeilen-Werkzeug.

Ob Suse sich mit Wicked einen Gefallen tut, muss sich zeigen – Hardcore-Admins schätzen es meist nicht, wenn neue Tools elementare Aufgaben mit höherer Komplexität versehen als unbedingt nötig.

Kernel 3.12, SLES und SLED

Ansonsten präsentiert sich SLE auf der Höhe der Zeit: Linux 3.12.26 ist zwar insgesamt nicht mehr der neueste Kernel, aber eine LTS-Version und somit das logische Mittel der Wahl für Suse. Alle Serverprogramme liegen wie zu erwarten in hinreichend aktuellen Versionen bei, für Enterprise-Systeme ist die Aktualität der Dienste in aller Regel sowieso nicht das maßgebliche Kriterium. Ergo erlauben sich die Suse-Entwickler hier keinen Lapsus.

Alle bis dato beschriebenen Funktionen beziehen sich auf SLE 12, also die Plattform, die sowohl dem SLED als auch SLES zugrunde liegt. Oben drauf packt Suse dann die Komponenten, die aus der Plattform einen Server oder einen Desktop machen. Beide Ansätze bringen in der Version 12 etliche sehr interessante Neuigkeiten mit sich.

SLED 12: Hallo Gnome?

SLED 12 sorgt für einen ordentlichen Paukenschlag: Als Desktop kommt Gnome 3 inklusive Gnome Shell zum Einsatz, und zwar auch als Standard für Desktops insgesamt. Das verwundert insofern, als dass Suse in den Köpfen vieler Suse-Nutzer eng mit KDE verbunden ist. Über viele Jahre hinweg war KDE der Suse-Standarddesktop. Und in SLED 11 war es den Nutzern überlassen, sich zwischen Gnome 2.4 und KDE 4.1 zu entscheiden. Beide Desktops lagen der Version 11 von SLED gleichberechtigt bei.

Damit ist nun Schluss: SLED 12 kommt wie selbstverständlich mit Gnome 3 und der entsprechenden Shell als Standardumgebung. Pakete für KDE sind weit und breit nirgendwo zu sehen. De facto drückt Suse SLED-Anwendern Gnome 3 also ohne Alternative aufs Auge. Eingedenk der Tatsache, dass Gnome 3 bei der Hälfte der Anwender ungefähr so beliebt ist wie Systemd, ist das eine sehr dramatische Entscheidung – die durchaus Rätsel aufgibt.

Freilich: Enterprise-Systeme sind für den Hersteller nur dann sinnvoll, wenn er den aus ihnen resultierenden Support-Aufwand so gering wie möglich hält. Fakt ist aber auch, dass gerade Nutzer in Europa eher KDE gewöhnt sind, und hier hat Suse verglichen mit dem Red-Hat-dominierten US-Markt noch immer deutlich mehr Anteile. Worin der Grund für die Entscheidung liegt, KDE gleich ganz rauszuwerfen, bleibt ein Rätsel. Dass SLED auf diese Weise ein Erfolg wird, muss das Produkt erst unter Beweis stellen.

SLES 12 für Virtualisierung

Bei SLES 12 präsentieren sich dem Admin im Vergleich zum SLED eher feine und weniger intrusive Änderungen. Doch soll das nicht darüber hinwegtäuschen, dass SLES 12 in vielerlei Hinsicht ein neu gestaltetes Produkt ist. Ein Beispiel liefert die Virtualisierung: Natürlich kommt die Distribution wie gehabt mit Support für alle Standard-Virtualisierer, die am Markt gegenwärtig unterwegs sind, darunter auch KVM.

Offensichtlich will Suse aber auch den Container-Zug nicht verpassen und integriert Container deutlich besser als bei SLES 11. In SLES 12 passiert das auf Grundlage von LXC, das nahtlos auch in Libvirt und damit in die Virtualisierungsverwaltung des Systems integriert ist. Freilich darf auch das zurzeit unvermeidliche Docker nicht fehlen: Es steht als Technology Preview zur Verfügung – wer will, kann die Software also ausprobieren und testen, erhält im Fall des Falles von Suse jedoch keinen Support.

Maria DB ist jetzt voll integriert

Wer MySQL auf SLES einsetzt, muss bei SLES 12 umdenken: Maria DB gehört ab jetzt zum Lieferumfang dazu und ist “fully integrated”, also im Rahmen von Support-Verträgen vollständig abgedeckt. Datenbank-Admins brauchen nun jedoch keinen Schreck zu kriegen, denn Maria DB versteht sich selbst als “Drop-in-Replacement” für MySQL: Wo vorher MySQL lief, lässt sich Maria DB also einfach starten. Bei SLES 12 heißen sogar die Bibliothek-Pakete Libmysql und sind nur anhand ihrer Version (10.0) überhaupt als Maria DB zu identifizieren. Was technisch durchaus bedeutsam ist, dürfte sich auf den Alltag des Admin also vorerst kaum auswirken.

Desktop oder Server?

Wie eng SLE, SLED und SLES miteinander verwoben sind, macht die “Workstation Extension for SLES 12” deutlich. De facto handelt es sich dabei nämlich nur um ein zusätzliches Repository, das SLES um die Pakete aus SLED erweitert, die ab Werk fehlen. Um die Workstation Extension zu nutzen, ist eine echte SLED-Lizenz notwendig.

Wofür das gut sein soll, erklärt Suse gleich selbst: Wer die Funktionen eines SLES benötigt, aber den Rechner als Workstation einsetzen möchte, erhält über das SLES-Add-on alle nötigen Features. Das ist durchaus pfiffig, weil der avisierte Use Case valide ist: Gelegentlich sollen auf Maschinen, die Desktops sind, tatsächlich Server-Applikationen laufen – die in Desktop-Distributionen aber meist nicht zum Lieferumfang gehören. Abbildung 9 zeigt den Screen Saver von SLES 12 bei der Arbeit.

Abbildung 9: Obwohl das UI bei SLES 12 nur eine untergeordnete Rolle spielt, erfährt der Admin auch per Bildschirmschoner, dass neue Updates bereit für die Installation sind.

Zusätzlich zu SLES 12 bietet Suse noch die Add-ons für (Geo-)HA und Public Clouds an. Das HA-Plugin ist ein alter Bekannter, der bereits bei SLES 11 als Dauergast im Einsatz war. In ihm enthalten sind die Komponenten, die Admins für Hochverfügbarkeits-Cluster brauchen: Pacemaker und Corosync sowie der Klebstoff, der jene Komponenten zusammenhält und aus ihnen einen HA-Cluster formt. Suse hat ein traditionell inniges Verhältnis zum HA-Stack: Andrew Beekhof, der Hauptautor von Pacemaker, stand schließlich mehrere Jahre in Chamäleon-Diensten, bevor die roten Hüte ihn abwarben.

Die HA-Extension entspricht allerdings weithin dem, was Admins schon aus SLES 11 kennen; neu ist lediglich ein kleines Werkzeug, das beim Setup eines Pacemaker-Clusters assistieren und diesen möglichst schnell bereit für den Einsatz machen soll.

Hochverfügbarkeit und Geo-HA

Interessanter ist da jenes Add-on für das HA-Add-on, das Geo-HA für SLES möglich macht. Geografische Hochverfügbarkeit unterscheidet sich von klassischer, lokaler HA in mehreren Punkten. Denn zentrale Faktoren wie Replikation, die auf lokalen Strecken problemlos funktioniert, werden auf WAN-Strecken echte Herausforderungen. Sind mehrere Rechenzentren im Spiel, stellen sich noch andere komplizierte Fragen: Welches Rechenzentrum soll beispielsweise aktiv sein, wenn zwei Rechenzentren eines HA-Setups den Blickkontakt verlieren? Wer entscheidet darüber, welcher Datensatz und welche Seite aktuell ist und welche das Nachsehen hat?

Booth

Pacemaker selbst bringt für Setups dieser Art nicht alle benötigten Funktionen mit. Suse liefert jene Features im HA-Geo-Add-on nach: In Form von Booth [11] steht ein Pacemaker-Add-on zur Verfügung, das eben auch mehrere RZs im Cluster logisch abbildet und entsprechend verwaltet. Booth arbeitet dabei mit internen Tickets und macht sich die Funktionalität zunutze, die Pacemaker bietet: Eine Site darf einen Service nur dann betreiben, wenn sie ein entsprechendes Ticket von Booth erhalten hat (in Pacemaker-Sprech “Location Constraint”).

Die Gültigkeit eines Tickets ist jedoch begrenzt, sodass Booth das Ticket regelmäßig erneuern muss. Fällt eine Site aus, die zuletzt das aktuelle Ticket hatte, merkt Pacemaker automatisch, dass der Dienst nicht mehr läuft, und stattet die verbliebene Site mit einem neuen Ticket aus. Damit dieses Prinzip funktioniert, muss Booth allerdings an einem dritten Standort laufen, der beide Sites unabhängig voneinander sieht. Nur so kann Booth seine Rolle als Quorum Tiebreaker wahrnehmen.

Obwohl der gesamte Vorgang kompliziert klingt, ist Suse für Booth ausdrücklich zu loben – besser als in SLES 12 ist Geo-Clustering mit Linux gegenwärtig wohl nirgends implementiert.

Lob für HA-Integration

Suse präsentiert mit SLE 12 eine Plattform, die sowohl SLES 12 als auch SLED 12 Sympathien einbringen dürfte. Von den eingangs erwähnten Bugs in Yast abgesehen hat sich das System im Test als robust präsentiert. Gerade im Hinblick auf den Yast-Rewrite sei nochmals ausdrücklich dazu gesagt, dass der Redaktion lediglich eine Vorserienversion von SLE 12 vorlag, aber noch nicht das fertige Produkt. Jedenfalls scheint Suse aus dem Feedback von SLES 11 gelernt zu haben und schickt SLES 12 nun in deutlich mehr Testläufe.

SLES 12 als Produkt überzeugt ebenfalls: Die Distribution punktet eher mit sinnvollen und hilfreichen Funktionen als mit den ganz großen Veränderungen. “Unaufgeregt” trifft als Beschreibung ganz gut, denn obwohl eine elementare Komponente durch eine andere ersetzt worden ist – die Rede ist vom Wechsel von Sys-V-Init hinzu Systemd –, entstehen den Admins daraus keine unabsehbaren Konsequenzen.

Wicked hinterlässt Fragezeichen

Ähnliches gilt für das Netzwerktool Wicked, dessen Bedienung im Test ein paar Fragezeichen über den Tester-Köpfen hinterließ, sich insgesamt aber sinnvoll einsetzen und auch umgehen lässt. Die verfügbaren Add-ons wie jenes für (Geo-)HA und die SLES-Workstation-Erweiterung tun ein Übriges, um in SLES eine solide Computing-Plattform zu sehen.

Etwas weniger eindeutig fällt das Urteil hingegen für SLED aus, das auch auf der SLE-12-Plattform basiert. Ein späterer Test wird zeigen, was bei SLED wirklich hinter der Fassade steckt. Letzte Meldung: Seit dem 27. Oktober kann sich jeder selbst ein Bild von SLE 12 machen.

Funktioniert Gnome als Enterprise-Desktop?

Fest steht: Der Ansatz, einen Enterprise-Desktop auf einem modifizierten Gnome 3 aufzubauen, birgt Risiken für Suse, weil sein Publikum mehrheitlich KDE gewohnt ist. Bleibt abzuwarten, ob sich die Entscheidung als gut oder schlecht erweist – mutig ist sie.

Der Autor

Martin Gerhard Loschwitz arbeitet als Cloud Architect bei Sys Eleven. Er beschäftigt sich dort intensiv mit den Themen Open Stack, Distributed Storage und Puppet. Außerdem pflegt er in seiner Freizeit Pacemaker für Debian.