© Markus Feilner CC-BY-SA 4.0

Dass die Trägerraketen von Satelliten mit großem Gedonner abheben, weiß jeder. Angetrieben von Buzzwords launchte Red Hat mit dem Satellite Server 6 im September seine neueste Lösung fürs Lifecycle Management. Dass die richtige Umlaufbahn noch nicht erreicht ist, geben die Amerikaner gerne zu.

Moderne IT-Setups unterscheiden sich von althergebrachten Ansätzen durch den deutlich höheren Automatisierungsgrad. Eine heute typische Umgebung aus Dutzenden oder gar Hunderten von Rechnern wäre mit den Hausmitteln der Vergangenheit praktisch nicht zu betreuen. Weil diese Erkenntnis bei allen Systemherstellern gereift ist, sind Suse, Canonical und Red Hat schon seit Jahren mit entsprechenden Lösungen auf dem Markt, Linux-Marktführer Red Hat hat vor ein paar Wochen die Version 6 seines Satellite Server [1] veröffentlicht.

Der verspricht umfassendes IT-Management unter einer einheitlichen Oberfläche und startet mit viel Gedonner. Wie es sich gehört, haben die Konstrukteure des Raumschiffs alle möglichen Aggregate gegenüber dem Vorgänger ausgetauscht. Satellite 6 ist denn auch eher ein krachender Neustart als bloße Versionspflege.

Seltsames Marketing

Viele Dinge waren beim Test von Red Hats Satellite 6 anders als beim üblichen Prozedere. Die erste Kuriosität ereignete sich, noch bevor das Produkt die Redaktion überhaupt erreichte: Zwar verschickte Red Hat bereits vor Wochen Marketing-E-Mails, die für Satellite 6 die Werbetrommel rührten. Auf Nachfrage hieß es aber lapidar, dass eine Teststellung für die Presse derzeit nicht zu bekommen sei. Sollte das Linux-Magazin das Produkt tatsächlich für einen Test kaufen müssen? Der Weg wäre ungewöhnlich, aber nicht unmöglich.

Über andere Kontakte der Redaktion gelangten dann doch noch einige ISO-Images des Satelliten in die Hände der Tester, was offenbar wieder nach Raleigh durchdrang: Kurz nach Redaktionsschluss hätte Red Hat (wohl wissend, die Mühlen der Presse nicht mehr aufhalten zu können) doch in einen – späteren – Test eingewilligt.

Doch da war die Neugier der Redaktion bereits geweckt: Warum benahm Red Hat sich so eigenartig? Hatten die Amerikaner in den Betas der neuen Version gefährliche Bugs gefunden, die sie noch vor einem Test korrigieren wollten?

RHEL als Grundlage

Erkunden lassen werden sich die Gründe Red Hats für das Verweigern eines Tests wohl kaum mit letzter Sicherheit. Doch legen die Tests des Linux-Magazins durchaus nahe, dass der Satellite 6 ein paar technische Leichen im Keller hat und von diesen auch weiß. Das Linux-Magazin erfuhr, dass auch Trainer in Red-Hat-Schulungen durchaus vor dem Produkt warnen und dazu raten, auf die 6.1 zu warten. Auch im Test war erst mal Bastelarbeit angesagt.

Konkret gestaltete sich schon das Installieren des Satellite schwierig. Red Hat bietet mehrere Möglichkeiten an, ihn als Software zu erhalten. Dazu gehört auch der Vertriebsweg über eine DVD; diese enthält ein Skript, das sich auf einem fertigen RHEL 6.6 oder RHEL 7 ausführen lassen soll und dann aus dem RHEL einen Satellite macht. Zumindest in der Theorie; in der Praxis war jenes Skript, das sich die Redaktion organisiert hatte, auf der CD nämlich kaputt. Der US-Hersteller kennt das Problem offenbar [2] und auch gefixte Images sind mittlerweile über das Customer-Portal laut Red Hat verfügbar [3].

Sinnvoller ist es sowieso, alle Pakete des Satellite-Servers über das entsprechende Repository und den RHEL-Paketmanager zu installieren. Wer eine Satellite-Lizenz bei Red Hat kauft, erhält die entsprechenden Repo-Informationen automatisch und kann die Nummer 6 mit etwas Glück per Dropdown-Menü deployen.

Horrorskripte

Dieses Verfahren anzustreben lohnt sich, erspart sich der Admin dann doch auch die beiden Horrorskripte, die ganz am Ende zu einer funktionierenden Satellite-Installation führen sollen (Abbildungen 1 und 2). Beim ersten Installationsversuch scheiterte das »katello-install« -Skript so nachhaltig, dass schließlich nur noch eine Neuinstallation des kompletten Systems half.

Abbildung 1: Die Installation von Satellite 6 auf RHEL 7 gestaltet sich äußerst rustikal, wenn sie von der Original-DVD erfolgt – per Shellskript.

Abbildung 2: Ohne Patch ging bei der CD, die die Redaktion auf Umwegen erhalten hatte, nichts. Mittlerweile ist das Problem bei den Red-Hat-Images angeblich repariert.

Versuch zwei führte nach einigen Aufrufen des Skripts zwar zum Erfolg, doch die zwischendurch angezeigten Fehler waren für die Tester alles andere als nachvollziehbar. Letztlich stand jedoch eine fertige Satellite-6-Instanz zum Testen zur Verfügung (Abbildung 3). Enterprise-ready geht anders. Hier muss Red Hat nachbessern und auch für die Satellite-Installation von CD oder DVD eine Möglichkeit schaffen, ein GUI zu nutzen.

Abbildung 3: Geschafft: Nach der Satellite-Installation präsentiert sich das Frontend im Webbrowser.

Der technische Unterbau

Satellite 6 ist ein Aufsatz für Red Hat Enterprise Linux. Der Admin darf sich dabei aussuchen, ob er RHEL 6 oder RHEL 7 verwenden möchte. Wer eine Satellite-Installation neu aufsetzt, wird wohl zu RHEL 7 [4] greifen, weil es neuere Software bietet und deutlich längeren Support. Überdies ist die RHEL-Version des Satellite-Servers nicht ausschlaggebend dafür, ob sich ein spezifischer Node von Satellite verwalten lässt. Läuft der Server auf RHEL 7, spielen auch RHEL-6-Clients mit dem Server zusammen.

Mit der Spin-off-Taktik machte Red Hat in der Vergangenheit gute Erfahrungen. Das Linux-Magazin hat die typische Red-Hat-Taktik dabei bereits einige Male beleuchtet, beispielsweise anhand des Storage-Servers [5], der auch ein RHEL mit Zusatzpaketen ist. Anders als beim RHSS gibt es vom Satellite jedoch keine fertige Appliance. Wer diese haben will, beginnt mit einem fertigen RHEL und installiert darauf die Satellite-typischen Aufsätze. Damit liegt Red Hat im Trend: Suse gibt für den SLE eine ganz ähnliche Marschrichtung vor, sodass aus SLE einerseits SLES und auf der anderen Seite SLED hervorgeht [6]. Auch Canonical macht mit: Die Basis für Appliances ist jeweils die neueste LTS-Release.

Tatsächlich geht es bei Satellite 6 sehr viel weniger um den Unterbau der Software selbst, sondern um seine Funktionen. Satellite ist für Red Hat der Fuß im Markt des Servermanagements.

Ganz konkret soll Satellite also ab Werk all jene Funktionen liefern, mit denen Admins ein großes Netzwerk aus Computern und zusätzlicher Hardware sinnvoll und insbesondere bequem administrieren können. Dem Linux-Admin fallen in Sachen Automatisierung automatisch Stichworte ein wie Puppet [7], Chef [8], Foreman [9], Bare Metal Deployment, die automatische Pflege von Updates und vieles mehr.

Abbildung 4: Im Satelliten hat der Admin die Wahl zwischen einer Vielzahl verschiedener Organisationseinheiten.

Historische Neuerungen

Um zu verstehen, warum Satellite 6 als Wagnis für Red Hat gelten darf, ist ein Blick in die Geschichte des Projekts hilfreich. Bis dato nutzte Red Hat in seinen Satellite-Produkten eine Eigenentwicklung namens Spacewalk [10]. Red Hat hat Spacewalk zu einer Zeit erfunden, als von Puppet & Co. noch keine Rede war. Es ist deutlich älter, als es die meisten Admins zu glauben bereit sind: Bereits 2001 taten erste Versionen auf Red-Hat-Systemen ihren Dienst.

Damals ging es maßgeblich darum, in Unternehmensnetzwerken die gleiche Experience zu bieten, die Red Hats Network auch offiziell ermöglichte. Das umfasst eine ganze Reihe äußerst praktischer Funktionen, beispielsweise lokale Spiegelserver für RPM-Updates, von denen alle lokalen Server dann installieren können und so die Leitung nicht unnötig verstopfen.

Mit der Zeit erweiterten die Entwickler aus Raleigh Spacewalk um diverse Funktionen, beispielsweise das License-Management einzelner Systeme oder die zentrale, per Mausklick durchführbare Paketinstallation. Red Hat hatte sich damit ein kleines Management-Framework gebaut, das für grundlegende Aufgaben gut zu gebrauchen war.

Dass die große Zeit der zentralisierten Werkzeuge erst noch kommen würde, war damals nicht abzusehen. Mit dem Aufkommen von Puppet, Chef, Ansible und vielen anderen Lösungen aber wirkte Spacewalk immer mehr, als sei es aus der Zeit gefallen. Im Satellite 6 setzt Red Hat an, diesen Missstand zu beheben: Spacewalk ist Geschichte – unter der Haube werkelt nun eine Reihe wohlbekannter Werkzeuge, die insgesamt einen deutlich größeren Funktionsumfang bieten, als Spacewalk es je gekonnt hätte.

Gleichzeitig ist Red Hat in Zeitnot: Der Suse Manager [11] oder MaaS (Metal as a Service, [12]) samt Canonicals Landscape-Programm knabbern an dem Marktsegment, auf das auch Satellite abzielt. Die Kombination aus Radikalumbau und Zeitdruck ist also eine durchaus explosive. Ginge beim Launchen etwas schief, wäre bei Red Hat wohl ordentlich Feuer unterm Dach. Vielleicht erklärt das auch die Nervosität im Vorfeld.

Gelungener Start

Zum Glück für Red Hat jedoch scheint die Operation zu gelingen. Satellite 6 (laut Hersteller ein “umfassendes Lifecycle-Management”) setzt auf bekannte Komponenten wie Puppet, Foreman und Git. Ab der Installation einer Maschine im Rack soll der Admin den Server per Satellite verwalten können, Updates installieren sich idealerweise automatisch – überhaupt bereiten die virtuellen Systeme nur Aufwand, den der Satellite augenblicklich abfängt.

Damit das so klappt, hat man in Raleigh einige Open-Source-Projekte miteinander verknotet. Den kompletten Workflow-Teil des Konfigurationsmanagements wickelt im Satellite 6 das Gespann aus Puppet und Foreman ab. Das ist durchaus beachtenswert, denn Red Hat steht eigentlich im Verdacht, an einer eher schweren Form des Not-invented-here-Syndroms zu leiden und im Fall des Falles gern auch selbst zum Editor zu greifen, um draufloszuprogrammieren.

Verwunderung löste Puppet im Test auch deshalb aus, weil Red Hat den Schwerpunkt auf dem amerikanischen Markt hat, in dem Chef besser etabliert zu sein scheint. Andererseits passt Puppet in die übrige Red-Hat-Strategie: So kommt der Puppenspieler auch in Red Hats Open-Stack-Distribution zum Einsatz, die ihn durch diverse, von Red Hat selbst geschriebene Module erweitert.

Puppet werkelt nur unter der Haube, falls der Admin mit ihm also nicht in Kontakt kommen möchte, muss er das auch nicht. Die Module für Satellite sind jedenfalls vorinstalliert. Falls Admins den vollständigen Funktionsumfang von Puppet brauchen, bietet Satellite aber auch dazu die Möglichkeit: Das in Satellite 6 verbaute Puppet ist im Hintergrund direkt mit Puppetforge verbunden. Und wer eigene Module nutzt, kann diese ebenfalls integrieren: Git gehört zusätzlich zum Lieferumfang von Satellite 6, sodass der Checkout aus entfernten Repositories ebenso möglich ist.

Nicht minder wichtig im Gespann ist Foreman. Für ein vollständiges, umfassendes Lifecycle-Management darf jener Teil nicht fehlen, der aus nackter Hardware überhaupt erst ein vollständiges Mitglied der lokalen Installation macht. Weil Satellite ausschließlich auf Red Hat als zu verwaltendes Gastsystem setzt, muss also Red Hat Enterprise Linux auf die neuen Kisten kommen (neben RHEL gehen nur Cloud-VMs auf Amazon oder im Rahmen von Open-Stack-Clouds, doch dazu später mehr).

Foreman ist in Puppet-Sprech ein so genannter ENC, ein External Node Classifier. Oder auf Deutsch: Foreman baut auf Puppet auf, nutzt Puppet aber nur als Werkzeug und fügt selbst eigene Funktionen hinzu. Beispielsweise kommt Foreman mit einem PXE-Installer: Der Admin legt in Foreman selbst den Host samt MAC-Adresse an und stellt sicher, dass der Server mittels PXE nach Bootimages sucht. Das passende Image liefert im Anschluss Foreman selbst – und kombiniert mit Kickstart-Files wird aus der frischen Hardware augenblicklich ein RHEL-Server.

Anschließend sorgen die in Puppet vorhandenen Manifeste dafür, dass der Server die Software und die Konfiguration erhält, die der Admin gern hätte. Dabei setzt Satellite 6 übrigens nicht auf das Foreman-GUI, sondern hat Foreman stattdessen nahtlos in Contentview integriert, das sich überall in Satellite 6 um die Außenwirkung kümmert.

Das Gespann aus Puppet und Foreman machte im Test einen guten Eindruck, und weil Red Hat nun auf Standardkomponenten setzt, eröffnen sich dem Admin an dieser Stelle neue Möglichkeiten. Ein Satellite 6, der mit zusätzlichen Modulen für Puppet aufgebohrt ist, übertrifft die Spacewalk-Hampelei von früher jedenfalls dramatisch in Sachen Funktionalität und Komfort.

Katello

Für Foreman hat Red Hat eine Anwendung namens Katello [13] entwickelt, die Foreman um Funktionen des Lifecycle-Managements erweitern. De facto legt sich Katello als Management-Framework um Puppet und Foreman und erweitert es um ein Füllhorn voller sinnvoller Features. Der Katello-Funktionsumfang ist beeindruckend.

Ein Beispiel dafür ist die Contentverwaltung. Content bezeichnet im Katello-Workflow entweder Puppet-Module oder RPM-Pakete. Hier begegnet Admins abermals die Funktion, die bereits bei den ersten Satellite-Versionen zum Standard in Sachen Funktionalität gehörte, nämlich das Bereithalten spezifischer RPMs auf lokalen Systemen.

Indem der Admin Repositories anlegt, sorgt er dafür, dass Clients RPM-Pakete vom Satellite-Server beziehen und nicht mehr aus dem Internet. Wer obendrein noch lokale RPM-Pakete hat (also selbst gebaute), kann in Katello auch für diese entsprechende Repositories anlegen und sie den verwalteten Servern unterjubeln. Im Hintergrund nutzt Katello Pulp [14], das sich um die gesamte Infrastruktur für Yum-Repositories kümmert und diese anhand der Vorgaben von Katello anlegt.

Capsules als USP

Ein anderes markantes Beispiel für den Katello-Funktionsumfang sind die Capsules: Der Capsule-Server, der zu Katello gehört (Abbildung 5), schnürt ein fertiges Paket aus DHCP, Bind, Puppet und anderen Diensten, die sich im Anschluss in eine virtuelle Katello-Umgebung auf neuen Hosts per Mausklick installieren. Zu einer Satellite-Instanz können dabei viele Capsule-Server gehören, die auch auf anderer Hardware laufen. Setzt der Admin auf eine solche Struktur, speisen sich die einzelnen Puppet-Server aus der Capsule, die ihre Konfiguration wiederum direkt aus Satellite erhält.

Abbildung 5: Red Hat beweist Humor: Der Capsule-Server lauscht zwar auf Port 9090, doch wer mit ihm reden will, erhält nur eine Mini-Anleitung.

Katello verwaltet gleichzeitig problemlos mehrere der virtuellen Umgebungen. Damit trägt Red Hat dem Umstand Rechnung, dass es gewachsene Setups gibt und nicht nur Cloudumgebungen, die auf dem Reißbrett entstanden sind. Wer in seinem Datacenter verschiedene Setups zu betreiben hat, kann diese als unterschiedliche Umgebungen in Katello sinnvoll verwalten. Überdies kümmert sich Katello mittels Pulp darum, dass in einer Satellite-Installation lokale Mirrors der meistgenutzten Repos von RPM-Paketen angelegt werden.

Die Zielsysteme von Satellite

Während vorherige Versionen von Satellite vorgeblich auf RHEL & Co. abzielten, gibt sich die Version 6 des Produkts nicht mehr so zugeknöpft. Zwar richtet sich die Software noch immer vorrangig an die eingefleischten Admins von Red-Hat-Software, doch ist es mit Satellite 6 auch möglich, VMs in Cloudumgebungen zu starten. Beispielhaft seien Open Stack sowie EC2 von Amazon erwähnt: Per Mausklick provisioniert Satellite 6 auch solche virtuellen Server, die in einer öffentlichen Cloud laufen statt auf einem lokalen Server.

Auf diese Weise entsteht ein interessanter Kreislauf. Zur Erinnerung: Praktisch sämtliche Appliances von Red Hat basieren im Kern auf RHEL, sodass sie alle sich aus Satellite heraus konfigurieren und nutzen lassen. Wer beispielsweise eine Open-Stack-Cloud auf Basis des passenden Produkts von Red Hat betreibt, kann die dazugehörenden Nodes ebenfalls durch den Satellite-Server verwalten lassen. Das Beispiel macht besonders deutlich, dass der Satellite in Version 6 als komplette Managementlösung konzipiert ist, um nahezu jedes Benutzerszenario abzudecken.

Im Dashboard des Satelliten (Abbildung 6) lassen sich übrigens auch im Betriebssysteme-Abschnitt zusätzliche Betriebssysteme definieren. Katello unterstützt distributionsspezifische Details wie Preseed-Konfigurationen bei Systemen, die per Debian-Installer installiert werden, oder Kickstart-Settings bei allem, was RHEL-kompatibel ist (Abbildung 7).

Abbildung 6: Im »Operating System«-Abschnitt des Dashboard lassen sich verschiedene Betriebssysteme anlegen, zum Beispiel auch Debian.

Abbildung 7: In der Übersicht der Betriebssysteme zeigt Satellite auch an, wie viele Hosts zu jedem OS gehören.

Subscription-Management mit Candlepin

Red Hat setzt bei seinen Enterprise-Produkten bekanntlich auf Schlüssel, mit denen eine Installation von RHEL einem Nutzer innerhalb des Kundenportals von Red Hat zuzuordnen ist. Wer ein RHEL mit der Option auf Online-Updates betreiben möchte, muss dazu eine Basic Subscription haben. Die enthält zwar keinen Support, reicht für viele Einsatzzwecke aber trotzdem aus.

Wer einen Pool von RHEL-Servern betreibt, wie es bei einer Satellite-Installation früher oder später der Fall sein wird, hat das gleiche Problem in vielfacher Ausführung. Satellite bietet dem Admin deshalb an, sich um das Management der Subscriptions selbst zu kümmern. Eine Software namens Candlepin verbindet sich mit dem Customer-Portal von Red Hat, um zu sehen, welche Lizenzen für einen spezifischen Account zur Verfügung stehen.

Mittels Candlepin in Katello lassen sich die Clients einer Installation von Satellite automatisch mit den Lizenzen eines solchen Pools ausstatten. Über das Candlepin-GUI in Satellite erhält der Admin umfangreichen Zugriff auf Managementfunktionen, die in Verbindung mit Subscriptions stehen; wenn er beispielsweise eine RHEL-Installation durch eine andere ersetzt, überträgt er per Candlepin-GUI den Lizenzschlüssel von der alten auf die neue VM.

Änderungen überwachen

Im Kontext des Cloud Computing hat sich eine Analogie verbreitet, die den Unterschied zwischen herkömmlichen Setups und Clouds verdeutlicht: Kätzchen sind einzeln gepflegte Installationen mit spezifischer Ausgabe; Herdenvieh ist hingegen eine anonyme Masse von VMs, die sich voneinander nur durch unterschiedliche Hostnamen trennen lassen.

In großen Scale-out-Setups sollten aber nicht nur die VMs möglichst identisch sein, sondern auch die physikalischen Maschinen. Kristian Köhntopp prägte das Mantra, dass es dabei bereits ein Problem sei, sich auf einem Host per SSH einzuloggen. Dann sei nämlich klar, dass entweder die Automatisierung oder das Logging nicht richtig funktioniert.

In Satellite 6 findet sich mit dem Namen Drift Remediation eine Funktion, die dem Wildwuchs im Rechenzentrum Einhalt gebieten soll. Satellite 6 kann per Mausklick ein verwaltetes System auf einen Ursprungszustand zurücksetzen und lokale Änderungen überschreiben. Dem Admin will Red Hat so das sichere Gefühl geben, stets zu wissen, was ein System tut und wie es sich verhält.

Automatische Server-Erkennung

Innerhalb einer Computing-Umgebung erhält freilich auch das Thema Discovery Gewicht. Noch komfortabler als der zuvor beschriebene Workflow ist ein anderer, bei dem der Admin einem neuen Server nicht mal mehr eine Rolle per Webinterface explizit zuweisen muss. Satellite 6 kommt mit einem Dienst daher, der das möglich machen soll: Die Discovery-Funktion scannt das Netz automatisch noch Hosts, die Discovery noch nicht kennt. Auf der Grundlage verschiedener Settings entscheidet der Admin dann, ob er die Systeme in die Satellite-Verwaltung aufnehmen möchte und wie diese konfiguriert sein sollen.

Vielleicht ein allzu ambitionierter Umbau

Red Hat hat sich in Satellite 6 viel vorgenommen. Das Produkt erhält ein neues Fundament und setzt nun auf Standardwerkzeuge wie Puppet oder Git. Dem Sonderweg, den Red Hat in Form von Spacewalk gegangen ist, setzt die Version 6 des Satellite ein Ende.

Der radikale Umbau birgt freilich Gefahren, nicht überall gelingt es Red Hat, sie mit Erfolg zu umschiffen. Die Release Notes für die Version 6.0 des Satellite etwa enthielten zu Redaktionsschluss bereits eine ganze Reihe Errata mit einer Liste bekannter Probleme.

Auch die Installationsroutine, die zumindest bei der Stand-alone-Variante des Satellite sehr rustikal daherkommt, vermittelt nicht das von Red Hat eigentlich gewohnte Enterprise-Feeling. Die Amerikaner werden hier in naher Zukunft noch einiges nachbessern müssen, wenn sie Kunden nicht beim ersten Kontakt mit dem sechsten Satelliten verschrecken wollen.

Schatten, aber auch Licht

Doch ist es nicht so, als gäbe es beim Satellite 6 nur Schatten. Hat der Admin sich durch die Installation gekämpft, weiß das Produkt in vielerlei Hinsicht zu überzeugen. Den radikalen Umbau sieht man der Software zwar an, weil das Webinterface anders erscheint als noch in der Vorversion. Insgesamt wirkt der neue Satellite aber nicht, als handle es sich um eine offene Baustelle.

Die Funktionsvielfalt des Produkts überzeugt: Durch das Gespann aus Puppet und Git, ergänzt um Katello mit seinen Komponenten Capsule und Candlepin, bietet der Satellite eine deutlich größere Vielfalt als es bisher der Fall war.

Obendrein integriert sich Satellite nahtlos in die anderen Red-Hat-Produkte der Gegenwart: Wer beispielsweise eine Open-Stack-Wolke auf Basis von Red Hat betreibt, kann auch die Nodes dieser Installation nahtlos in Satellite übernehmen. So positioniert sich Satellite 6 als mächtige Alternative zu MaaS und Juju sowie zum Suse Manager. Wer den Satellite 5 nutzt, sollte sich den Satellite 6 jedenfalls genauer ansehen.

Preise ja, aber keine Eval

Für bis zu 50 virtuelle oder physische Satellite-Clientmaschinen gibt es eine Subskription zum Preis von etwa 5000 Euro, die Unlimited-Variante kostet etwa das Doppelte. Problematisch bei der Kostenermittlung ist nur das ebenfalls notwendige Zusatzpaket namens Smart Management Addon, das es ab 150 Euro gibt, schnell aber auch 500 Euro erreicht und nur individuell errechenbar ist. Aber in Sachen Lizenzwirrwarr sind die potenziellen Satellite-Kunden ja von Microsoft, Oracle oder VMware deutlich Schlimmeres gewohnt.

Eine Eval ist bis zum Redaktionsschluss allerdings nur beim Vertriebsteam zu bekommen, per Klick im Portal steht sie noch nicht zur Verfügung. Vielleicht war die Pressemitteilung, die die Rothüte am 10. September 2014 in den Himmel schossen, einfach ein wenig vorschnell.

Der Autor

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