Archiv der Kategorie: DCI – Drillings Open Source Eck

Red Hat übernimmt CoreOS

Laut einer recht prominent platzierten Mitteilung wird Red Hat CoreOs übernehmen.

Das Unternehmen CoreOS wurde 2013 gegründet und zählt zu den Pionieren im Bereich Container-basierter Linux-Lösungen. Anfangs gab es eine enge Zusammenarbeit mit Docker; nach Uneinigkeit über die weitere Ausrichtung von Docker ging CoreOS  aber eigene Wege und  hat diverse Produkte entwickelt, wie z. B. die eigene Container-Distribution oder Tectonic, eine auf Kubernetes basierende Container-Managementlösung. Zudem hat CoreOS im Jahr 2014 selbst mit  Quay.io einen Anbieter von Container-Lösungen übernommen.

CoreOS und OpenShift

Red Hat sichert sich damit den Zugriff auf die CoreOS-Technologien, um damit z. B. sein Cloud- und  Virtualisierungsportfolio effizient zu erweitern und um neue Lösungen zu ergänzen.

So sollen z. B. die von CoreOS entwickelte Container-Lösungen und Erweiterungen unter anderem auch in Red Hat OpenShift einfließen. Der Kauf hat aber im Kontext von Docker und im umkämpften Container-Markt sicher auch strategische Gründe.

Mega Deal

Rein wirtschaftlich ist der Kauf von CoreOS mit einem Volumen von 250 Millionen US-Dollar eine der größten je von Red Hat getätigten Akquisitionen. Ob die Übernahme allerdings unter dem Einfluss von Red Hat auch zu einer Öffnung von Tectonic führen wird, lässt sich im Moment noch nicht sagen, wenngleich Red Hat in der Vergangenheit bei ähnlichen Akquisitionen erworbene Technologien häufig der Öffentlichkeit zugänglich gemacht hat.

Suse Studio schließt Morgen

Suse betreibt mit dem Open Build Service und Suse Studio seit geraumer Zeitgleich zwei Dienste mit ähnlicher Zielgruppe. Das Suse Studio diente in erster Linie dem Generieren von Images etwa für die Installation von Linux (nicht nur Suse) auf Hardware, VMs, Containern oder in der Cloud.

Beim Open Build Service hingegen ging es ursprünglich primär um das Generieren von Paketen, obwohl der Dienst  inzwischen ebenfalls  jede Art von Images erstellen kann. Daher kündigte Suse seit Ende des vergangenen Jahres mehrfach die Einstellung von Suse Studio zum 15.02.2018 an und wies auf die Notwendigkeit einer  Migration bestehender Daten hin. Die dazu erforderliche Prozedur lässt sich einem von Suse veröffentlichen Blog-Eintrag entnehmen.

Tipp: Nur nicht erpressen lassen

Sind die eigenen Daten erst wider Willen verschlüsselt und es liegt kein aktuelles Backup vor ist guter Rat nicht nur teuer, sondern bis auf folgenden Tipp oft gar nicht zu bekommen.

Der Ransomware File Decryptor von Trend Micro steht zum kostenfreien Download bereit und ist in der Lage, durch bestimmte Ransomware-Familien unlesbar gemachte Dateien zu entschlüsseln. Derzeit finden sich 27 Erpressertypen auf der „Fahndungsliste“ des Tools.
Der „Ransomware File Decryptor“ wird nicht prophylaktisch installiert, sondern kommt nur zum Einsatz, wenn der Fall der Fälle eingetreten ist. Auch dann wird er nicht installiert. Der Nutzer muss dagegen nur das ZIP-Paket entpacken und die Anwendung „RansomwareFileDecryptor 1.0.1668 MUI.exe“ ausführen. Das Tool fragt dann nach einem Klick auf „Select“, welche Ransomware-Familie die Daten des Nutzers verschlüsselt. Zur Wahl stehen zahlreiche Erpresser mit „Rang und Namen“, etwa WANNACRY, LECHCHIFFRE, CHIMERA oder JIGSAW. Mit „Select & Decrypt“ hingegen, schreitet das Tool gleich zur Tat.

Wer genau der Schuldige ist erfordert war etwa Recherche-Arbeit, lässt sich aber meist mit Hilfe der gängigen Security-Webseiten ermitteln. Gelingt das nicht, hilft ein Klick auf „I don’t know the ransomware name“ mit etwas Glück trotzdem aus der Patsche.

Let’s Encrypt macht seinen Weg

Laut dem von der Internet Security Research Group vorgelegten  Bericht zur Lage von Let’s Encrypt machen John Aas die Wachstumszahlen für 2017 wie jeden CEO stolz. So konnte beispielsweise die Zahl der aktiven Zertifikate auf derzeit 56 Millionen verdoppelt werden. Die Anzahl der damit verwalteten Domains hat sich mit 61 Millionen sogar fast verdreifacht.

Die Infrastruktur hinter der Certificate Authority (CA) Let’s Encrypt besteht aktuell aus 70 Servern, Switches und Firewalls, wobei man die Speicherkapazitäten ständig an den steigenden Bedarf anpasst. In 2018 soll zudem erstmals auch zehn ältere Server ausgetauscht werden und die Zahl der Mitarbeiter, die sich allein um die Infrastruktur kümmern, soll sich von 5 auf 6 erhöhen.

Trotzdem bleibt dabei der Finanzbedarf von Let’s Encrypt relativ gering. Das Budget für 2018 beträgt rund drei Millionen US-Dollar. Mit einer geplanten Erhöhung des Budgets von rund 13 Prozent können 2018 doppelt so viele Zertifikate ausgestellt werden wie im Vorjahr. Die Haupt-Sponsoren sind Mozilla, Akamai, OVH, Cisco und Google.

Fahrplan 2018

Allgemein wurde 2017 den Aussagen der Mozilla Foundation nach die Zahl der mit HTTPS verschlüsselten Webseiten von 46 auf 67 Prozent gesteigert. Im Verlauf des Jahres 2018 will die hinter Let’s Encrypt stehende ISRG diese Zahlen weiter verbessern. So soll die Anzahl der aktiven Zertifikate sowie der eindeutigen Domains 2018 auf 90, bzw. 120 Millionen gesteigert werden.

Bemerkenswert ist auch, dass das ACME-Protokoll zum Ausstellen von Zertifikaten zur Zeit bereits in die Entwicklerversion des Apache-Server HTTPD implementiert wird und später in auch in die stabile Version HTTPD 2.4.x einfließen soll. Weitere Pläne für 2018 sind z. B. Version 2 des ACME-Protokolls für Ende Februar mit der Unterstützung für Wildcard-Zertifikate. Im weiteren Verlauf des Jahres will Let’s Encrypt ECDSA-Root-Zertifikate einführen, laut Aussage von Aas effizienter als die Algorithmen in RSA sind.

Aas äußert sich in seinem Bericht auch lobend über die Gemeinschaft hinter Let’s Encrypt, die mittlerweile über 60 Clients für Let’s Encrypt bereit gestellt hat.

Neue Container Runtime und neuer Online-Markplatz für Cloud Foundry

Eine der interessantesten Ankündigungen auf dem  Cloud Foundry Summit Europe ist die neue, aus Kubo hervorgegangene Container-Laufzeitumgebung, die auf den Namen Cloud Foundry Container Runtime (CFCR) hört und mehr Auswahlmöglichkeiten bietet.

So können Nutzer jetzt wahlweise Kubernetes oder Application Runtime einsetzen, um ihre Container und Container-Cluster zu verwalten. Ferner unterstützt die neue Container Runtime nun auch Istio und bietet Persistenz in VMware vSphere, Google Cloud Platform (GCP) und Amazon Web Services (AWS).

Online Marktplatz

Außerdem hat die Foundation einen neuen Online-Marktplatz vorgestellt. Dieser erleichtert Nutzern das Finden von Software sowie von Services, Schulungen, Anbietern, Integratoren oder Consultants. Damit richtet sich der neue Marktplatz primär an Nutzer, für die die Cloud Foundry Plattform noch neu ist. Aktuell umfasst der Marktplatz mehr als 600 Lösungen.

 

ESXi-Driver Rollup

Bestimmt ist das jedem ESXi-Admin schon einmal passiert. Klappt das Update eines ESXi-Host aus welchen Gründen auch immer nicht, kann dieser in nicht mehr korrekt gestartet werden und ist nicht mehr erreichbar.

Zwar könnte man dann immer noch mit wenigen Handgriffen ein Neuinstallation initiieren, aber je nachdem, wie aufwendig das Rekonstruieren der eigenen Host-Konfiguration ist und je individueller das jeweilige Boot-Image war, desto länger dauert dieser Vorgang. Wohl dem, der über eine Enterprise-Plus-Lizenz und das Faeture Host-Profiles verfügt und dieses auch nutzt. Es geht aber auch einfacher:

Driver Rollback

VMware gibt nämlich ESXi-Admins eine  Möglichkeit an die Hand, mit wenigen Handgriffen auf die Version „vor“ einem Upgrade oder Update zurück zu wechseln.

Das klappt allerdings maximal für den vorherigen Stand,  zwei oder mehr Versionen zurück funktioniert leider nicht.

Um den Vorgang einzuleiten, drückt  man am Start-Bildschirm Strg+R und zwar noch  bevor das System anfängt, die einzelnen Module zu laden. Nach Prüfung der Version zu der zurück gewechselt werden soll, kann der Vorgang mit Strg+Y ( auf deutscher Tastatur „Z“) eingeleitet werden.

ESXi-Boot-Image sichern

Das Booten eines ESXi-Hosts vom USB-Stick gehört neben Autodeploy zu den beliebtesten Start-Verfahren und wird von VMware auch voll unterstützt. Da lokale Platten in ESXi-Host – sieht man mal von VSAN ab – mehr oder weniger nutzlos sind, betreibt man einen ESXI-Host heute in der Regel diskless. Für das Starten des Hypervisors genügt ein 8GB USB-Stick, sofern man etwas Reserve für den Scratch-Bereich einplant; minimal tun es auch 4GB beim Standard-Partitions-Layout.

Und das Beste daran: das Start-Image lässt sich mit ESX-Bordmitteln sehr einfach für den Notfall wegsichern, den bekanntlich sind USB-Sticks nicht besonders langlebig. Zum Einsatz kommt das gute alte Linux-dd, das auch die ESXi-Shell dank busybox beherrscht. Anschließend kann man aus dem dd-Image bei Bedarf jederzeit einen neuen Boot-Stick klonen.

ESXi-Desaster-Recovery

Dieser DR-Workaround ist sehr komfortabel auch wenn es natürlich andere Möglichkeiten gibt. Mit Autodeploy kann man bekanntlich auf eine Installation von ESXI auf Datenträgern auch ganz verzichten. Ferner kann ein ESXI-Host auch aus dem SAN booten und das Neuaufsetzen eines ESXI-Servers aus dem Installations-ISO dauert ja auch nicht ewig, sofern man die eigene ESXi-Config vorher z. B. mit Hilfe von Host-Profilen gesichert hat.

Auch Distributed vSwitche lassen über den Web Client komfortabel sichern und nach dem Neuaufsetzen eines Hosts wieder einspielen. Nichts davon geht jedoch so schnell und komfortabel, wir das Kopieren den kompletten USB-Sticks in ein Image. Und das geht wie folgt

Zunächst legt man auf einem für den betreffenden ESXi-Host zugänglichen Datastore ein Zielverzeichnis an. Im Beispiel verwenden wir einen NFS-Datastore, der auf ein freigegebenes Verzeichnis auf einem SAN-Gerät verweist. Der zugehörige Pfad aus Sicht des ESXi-Hosts lautet im Beispiel /vmfs/volumes/73ce4fbc-10a9189c/Backup-Bootdevices.

Das Anlegen des Verzeichnisses kann wahlweise im Datastore-Browser des Web- oder Hosts-Clients erfolgen, auf der Kommandozeile mit „mkdir“ oder mit Hilfe eines grafischen SFTP-Client.

Danach muss man die passende Geräte-Datei für das USB-Gerät ermitteln, der als „if“-Parameter für das dd-Kommando dient. Auch das geht wahlweise an der ESXi-Shell oder via SSH mit ….

ls -la /dev/disks/ | grep mpx

oder man schaut einfach mal in die Storage-Adapter Ansicht für den USB-Controller im Web Client.

Nun steht der Verwendung des dd-Kommandos mit den Parametern „if“ (Input File) und „of“ (das eben angelegte Sicherungsverzeichnis nichts mehr im Wege:

dd if=/dev/disks/<USB-Device> of=/vmfs/volumes/<Datastore>/<Ordner>/<Name>.img

im Beispiel:

dd if=/dev/disks/ mpx.vmhba33:C0:T0:L0 of=/vmfs/volumes/73ce4fbc-10a9189c/Backup-Bootdevices/hv1.img

Anschließend kann man das Image auf einem beliebigen Rechner zur Weiterverarbeitung herunterladen. Auch das kann wahlweise mit dem Datastore-Browser des Web Clients oder wie im Beispiel mit einem SFTP-Client erfolgen:

Danach kann man das Image auf einen Windows-Rechner z. B. mit einem Tool wie Rufus auf einen neuen USB-Stick schreiben, der um Komplikationen zu vermeiden, die gleich Größe haben sollte. Etwaige vorhandene Partitionen sind vorher zu löschen. Es spricht natürlich auch nichts dagegen, auch für das Zurückschreiben dd zu benutzen.

OpenShift Container Platform 3.6

Red Hat OpenShift Container Platform 3.6 ist die jüngste Version von Red Hats, auf Kubernetes 1.6 und integrierter Docker-Runtime basierenden Container Application Platform für den Unternehmenseinsatz.

Die PaaS erlaubt es Nutzern auf Basis von Docker und Kubernetes, schnell und einfach Applikationen und Services in Hybrid- und Multi-Cloud-Umgebungen konsistent bereit zu stellen.

PCI-DSS-Leitfaden

Neu in OpenShift Container Platform ist unter anderem auch ein Leitfaden zur Anwendung von PCI-DSS (Payment Card Industrie) mit detaillierten Netzwerkrichtlinien. Die Funktion adressiert Unternehmen, die Kreditkarteninformationen verarbeiten, speichern und übertragen müssen. Im Prinzip erläutert der Leitfadem, wie sich die Anforderungen des Payment Card Industry Data Security Standard mit Applikationen in Red Hat OpenShift Container Platform umsetzen lassen.

Ferner unterstützt die Plattform jetzt bis zu 2000 Nodes und 250 Pods pro Node, statt vorher 1000 Nodes. Weitere neue Features sorgen für mehr Sicherheit im Host-System und in der Container-Infrastruktur. So lassen sich Container mit vertrauliche Informationen verschlüsseln und signieren, also sicher auf einem Backend-Speichersystem ablegen. Ferner lässt sich in der neuen Version der Einsatz von Signaturen, etwa bei Bildinhalten, verpflichtend machen.

NetworkPolicy

Darüber hinaus zeigt Red Hat in einer Vorschau die Erweiterungen der NetworkPolicy. NetworkPolicies können detailliert festlegen, wie Applikationen miteinander kommunizieren und welche Netzwerkressourcen sie bereitstellen. So können Anwender schon beim Bereitstellen von Services definieren, wer eine bestimmte Applikation im Netzwerk nutzen darf.

Container Native Storage

Mit dem auf Gluster Storage basierenden Container Native Storage stellt Red Hat zudem einen hochverfügbaren Speicher bereit, der sich wahlweise über die OpenShift Registry aber auch als direkt einsetzbarer persistenter Speicher bei der Erstinstallation von OpenShift einsetzen lässt. Nutzer können so kurzlebige, in Container gepackte Anwendungen auf dem gleichen System mit persistentem Storage verwenden, was letztendlich Ressourcen einspart.

Hat Service Broker und Service Catalog

Sollen Unternehmen Anwendungen über Public- und Private-Cloud-Services und physischen Ressourcen hinweg nutzen können, muss die unterliegende Plattform die Konsistenz dieser Anwendungen gewährleisten und zudem dafür sorgen, dass die den Applikationen zugrunde liegenden Services von vielen Plattformen aus zugänglich sein.
In Openshift 3.6 sorgen eine Reihe neuer Funktionen dafür, dass diese Services leicht auffindbar und einsetzbar sind, z. B. mit Hilfe der ebenfalls als Preview eingestuften Features Service Broker und Service Catalog. Sie unterstützen Nutzer beim Provisionieren und Einbinden von Services in ihre OpenShift-Applikationen, wobei es egal ist, ob die Services im eigenen Rechenzentrum oder in der Cloud laufen.

Mit Hilfe des Service Catalogs lassen sich dann Endpunkte (Broker), welche die verschiedenen Services verwalten, über OpenShift oder Kubernetes konsumieren.

Zudem ermöglicht der ebenfalls als Vorschau klassifizierte OpenShift Template Broker Anwendern, OpenShift Templates über die Benutzeroberfläche des neuen Service Catalogs auszuwählen und in Multi-Container-Application Services von OpenShift zu verwenden. So steht z. B. der ebenfalls als Preview der Ansible Playbook Broker zur Verfügung. Er erlaubt Anwendern, Ansible Playbooks in Application Services von OpenShift einzufügen und Applikationen zu verknüpfen.

OpenShift Online Next Generation

Unternehmen können mit einer PaaS-Plattform wie OpenShift Entwicklungsprojekte beschleunigen und produktiver machen. Die PaaS-Plattfom der Wahl muss neben einer hohen Verfügbarkeit dynamisch skalieren und eine automatische Provisionierung bieten.

Red Hats OpenShift war initial als PaaS gestartet, wird von Red hat aber heute als Container-Runtime-Plattform, die auch PaaS-Elemente beinhaltet, vermarktet.  Red Hat bietet OpenShift in vier Dareichungsformen verfügbar:  OpenShift Online ist den von Red Hat betriebene Public-Cloud-Online-Service. Darüber hinaus gibt es noch OpenShift Container Platform (ehemals OpenShift Enterprise), die installierbare Unternehmens-Version von OpenShift Origin (den Quellen der Community-Version) und Open Shift Dedicated, eine auf Amazon Web Services (AWS) oder Google Cloud Platform (GCP) gehostete Managed-Private-Cluster-Version von OpenShift.

OpenShift aus der Red-Hat-Cloud

OpenShift Online basiert genau wie die Red Hat OpenShift Container-Plattform auf Linux-Containern und Kubernetes und erlaubt Entwicklern eine einfaches und schnelles Erstellen und Einsetzen von Cloud-Anwendungen in einer öffentlichen Cloud.

Nach Angabe von Red Hat wurde OpenShift Online in den nunmehr sechs Jahren seit dem Start von hunderttausenden von Entwicklern genutzt. Die Plattform unterstützt inzwischen zahlreiche Programmiersprachen, darunter Java, Node.js, .NET, Ruby, Python und PHP. Als Datenbanken stehen MariaDB, MySQL, MongoDB und PostgreSQL in den unterschiedlichen Versionen bereit. Zudem können Entwickler mit beliebigen Frameworks arbeiten, wie Eclipse, Spring Boot, Node.js, Vert.x und ab jetzt auch mit Red Hat JBoss Middleware.

Was ist neu?

Mit Hilfe des Source-To-Image (S2I)-Frameworks lassen sich jetzt so genannte reproduzierbare Container-Images kreieren. Entwickler müssen so keine Docker-Images mehr erstellen oder verwalten und müssen sich daher auch nicht mehr mit Docker auseinandersetzen.

Entwickler, die trotzdem eine grafische Entwicklungsumgebung einsetzen möchten, können das dank der neuen Integrationsmodule mit Eclipse, Red Hat JBoss Developer Studio oder Titanium Studio tun.
Die neue Generation von OpenShift Online ermöglicht nach Aussage von Red Hat außerdem zahlreiche Vereinfachungen beim Starten der Container. Im einfachsten Fall genügt bereits ein einzelner Klick oder ein „git push“, zumindest wenn keine Notwendigkeit besteht, den Lebenszyklus des Containers im Detail zu steuern.
Ferner kann Open Shift Online Anwendungen jetzt automatisch skalieren. So lassen sich bei für automatische Skalierung „designten“ Anwendungen Lastspitzen durch das Starten zusätzlicher Instanzen abfangen.
Die ebenfalls neue OpenShift Application Services machen die Fähigkeiten aus dem Red Hat JBoss Middleware-Portfolio als Cloud-basierte Dienste auf OpenShift verfügbar.

Red Hat OpenShift Online ist in zwei Varianten verfügbar. Die kostenlose Variante „Starter“ bietet 1 GB RAM und 1 GB Datenspeicher für 1 Projekt. Bei der „Pro-Version zahlt man pro Monat und Gigabyte RAM und Speicher. Sie erlaubt bis zu 10 Projekte und startet mit 2 GB RAM und 10o GB Storage für 50 US$/Monat. Der Dienst wird in rund 200 Ländern angeboten.

Fedora 26 erschienen

Unter Kennern kein Geheimnis ist, dass Fedora von Red-Hat-Entwicklern und Red Hat nahe stehenden Entwicklern – Fedora ist natürlich ein Community-Projekt – als Test- und Spielwiese für Red Hat Enterprise Linux genutzt wird.

Erfreuliche Neuerungen in Fedora 26 gibt es beim Anaconda-Installer. Das Partitionieren der Festplatte gelingt mit einem neuen Partitionierwerkzeug „Blivet-gui“ jetzt deutlich komfortabler. Dessen Benutzeroberfläche ähnelt der von Gparted. Als Kernel kommt immer noch 4.11.8 zum Einsatz, erst in naher Zukunft soll ein Wechsel auf 4.12 folgen. Der Paketmanager DNF ist nun in Version 2.5 an Bord, die nicht nur Fehler behebt, sondern auch viele neue Funktionen bietet.

Fedora Workstation mit Gnome 3.24

Die Workstation-Variante von Fedora nutzt als Desktop-Umgebung Gnome 3.24; es gibt aber auch Spins mit Cinnamon, KDE, Mate, LXDE, SOAS oder Xfce und sogar ein Neues mit LXQt.

Zu den interessantesten Neuerungen der Workstation-Version (es gibt auch „Server“ und „Cloud“) von Fedora 26 gehört ein so genannter Nachtmodus namens „Night Line“. Er passt abends die Bildschirmfarben an. Ferner wartet Fedora 26 Workstation mit einer optimieren Nachrichtenzentrale und vielen kleineren Verbesserungen auf.

Zu den erwähnenswerten Paket-Aktualisierungen gehören NetworkManager 1.8, Firefox 54 und LibreOffice 5.3.4. Ein Novum für Fedora ist, dass Nutzer nun auch ohne Nachrüstpakete aus Epel&Co MP3-Dateien direkt nach dem Installieren von Fedora abspielen und auch erzeugen können. „Schuld“ daran sind die abgelaufenen Patente. Für Programmierer sind gcc 7.1, Golang 1.8, Python 3.6, Ruby 2.4 und PHP 7.1 erwähnenswert. Die GNU C Bibliothek ist in Version 2.25 dabei.

Neu in Fedora 26 ist auch ein verbessertes Caching der User- und Group-Informationen sowie ein verbesserter Umgang mit Debug-Informationen. Nicht mehr dabei ist der Synaptics-Treiber „xorg-x11-drv-synaptics, der ab der aktuellen Version durch die Libinput-Variante ersetzt wird.

In Bezug auf die Server-Version ist noch zu ergänzen, dass der Cyrus IMAP Server nun auf Version 3 und OpenVPN auf die Version 2.4.3 klettern. Interessant ist auch, dass Docker nun standardmäßig OverlayFS über den Overlay2-Treiber verwendet, was die Performance steigern soll.

Weitere Informationen findet man in der offizielle Ankündigung.