Linux Archives - ElasticSky

7. Dezember 202214. Dezember 2022

Start- und Reboot-Probleme mit Maxtang NX6412 Mini-PC unter Linux

vExpert Geschenk von Cohesity

Seit kurzer Zeit bin ich im Besitz eines Maxtang NX6412-B11 Mini PCs. Zur VMware Explore EMEA in Barcelona verteilte Cohesity diese Barebones an vExperts. An dieser Stelle nochmal einen herzlichen Dank an Cohesity für ihren Support der Community!

Der lüfterlose MiniPC mit Elkhart Lake Chipsatz ist gut ausgestattet. Er verfügt über 2x 1 Gbit LAN, 1x USB-C (front), 2x USB 3.2 (front), 2x USB 2.0, 2x HDMI 2.0, sowie einen Audio Port.

Der MiniPC wird mein Homelab bereichern. Ich hatte dafür eine Installation der Tanzu-Community-Edition geplant. Leider wurde das Projekt inzwischen von VMware eingestellt und die Entfernung der Pakete aus GitHub angekündigt. 🙁

Bestückung der Hardware

Der Barebone musste noch mit RAM und einer Flashdisk ausgestattet werden. Ich verbaute eine Samsung SSD 860 EVO Series 1TB M.2 SATA und zwei mal 16 GB SO-DIMM DDR4 3200 von Crucial.

Reboot Probleme unter Linux

Mit der SATA SSD und dem RAM war der PC bereit zum booten. Als System wurde ein Ubuntu 22.04 LTS verwendet. Nach Installation wurde ein Reboot gefordert. Dabei schaltete sich der PC jedoch nicht vollständig ab und blieb im Status “Reached target Shutdown” stehen. Der PC musste hart abgeschaltet werden. Auch der Neustart dauerte mehrere Minuten, was für Ubuntu sehr ungewöhnlich ist. Um auszuschließen dass das Problem spezifisch für Ubuntu ist, versuchte ich eine Installation mit Fedora. Das Ergebnis war auch hier das gleiche.

Die Lösung

Nach länger Suche fand ich einen Hinweis der spezifisch für die EHL Hardware Plattform war. Die Lösung ist die Deaktivierung eines Kernelmoduls für den Intel Elkhart Lake SoC Chipsatz. Dazu wird dieses in die Blacklist.conf eingetragen.

sudo vi /etc/modprobe.d/blacklist.conf

Folgende Zeile muss in die blacklist.conf eingefügt werden:

blacklist pinctrl_elkhartlake

Den Editor mit [ESC] [:] wq! (save und exit) verlassen.

update-initramfs –u

Der folgende Shutdown war noch verzögert, jedoch startete das Linux nach dem Neustart innerhalb weniger Sekunden.

Ich hoffe dieser Hinweis hilft meinen vExpert Kollegen. Sharing is caring. 🙂

8. Januar 20227. Dezember 2022

Tanzu Community Edition auf einer Linux VM installieren – Durchmarsch für Einsteiger

Um einen Einblick in VMware Tanzu und Kunernetes zu erhalten benötigt man keinen Enterprise-Cluster. Dank der Tanzu Community Edition (TCE) kann das jetzt jeder selbst ausprobieren – kostenlos. Der Funktionsumpfang ist nicht beschränkt im Vergleich zu kommerziellen Tanzu Versionen. Lediglich auf professionellen Support durch VMware muss man bei der TCE verzichten. Dieser wird über Foren, Slack-Gruppen oder Github durch die Community geleistet. Für einen PoC Cluster oder zum Training auf die CKA Prüfung reicht das vollkommen aus.

Die Bereitstellung geht recht schnell und man hat nach einigen Minuten einen funktionsfähigen Tanzu-Cluster.

TCE Architektur-Varianten

Die TCE kann in zwei Varianten entweder als Standalone-Cluster oder als Managed-Cluster bereitgestellt werden.

Standalone Cluster

Eine schnelle und Ressourcen schonende Art der Bereitstellung ohne Management-Cluster. Ideal für kleine Tests und Demos. Der Standalone-Cluster bietet kein Lifecycle Management. Dafür hat er einen kleinen Fussabdruck und kann auch in kleinen Umgebungen genutzt werden.

Managed Cluster

Wie bei kommerziellen Tanzu-Versionen gibt es einen Management-Cluster und 1 bis n Workload-Cluster. Er verfügt über Lifecycle Management und Cluster-API. Somit kann über deklarative Konfigurationsdateien der Kubernetes Cluster definiert werden. Beispielsweise die Anzahl der Knoten im Management Cluster, die Anzahl der Worker-Nodes, die Version des Ubuntu-Images oder der Kubernetes Version. Cluster-API stellt die Einhaltung der Deklaration sicher. Fällt beispielsweise ein Worker Node aus, so wir dieser automatisch ersetzt.

Durch die Verwendung mehrerer Knoten benötigt der Managed-Cluster natürlich auch deutlich mehr Ressorcen.

Ziele für die Bereitstellung

TCE kann entweder lokal auf der Workstation mit Docker, im eigenen Lab/Datacenter auf vSphere, oder in der Cloud auf Azure oder aws bereitgestellt werden.

Ich habe im Lab ein lizensiertes Tanzu mit vSAN und NSX-T integration eingerichtet. Daher würde TCE auf vSphere hier keinen tieferen Sinn ergeben. Cloud Ressourcen auf aws oder Azure kosten Geld. Daher möchte ich die kleinstmögliche und sparsamste Bereitstellung eines Standalone-Clusters mit Docker beschreiben. Dazu verwende ich eine VM auf VMware-Workstation. Alternativ kann auch ein VMware-Player oder eine andere Art Hypervisor genutzt werden.

15. Februar 202127. Februar 2021

Veeam Immutable Backups auf vorhandenen Linux XFS Repositories aktivieren

Veeam backup & Replication v11 steht kurz vor der Veröffentlichung. Diese ist für Mittwoch den 24.2.2021 geplant. Partner und Service Provider hatten einige Tage Vorsprung und Zugriff auf den sogenannten RTM Build (ready to manufactoring).

Eine der (wie ich meine) spannensten neuen Funktionen in Version 11 ist die Einführung der sogenannten Immutable Backups. Ich hatte bereits in meinem Beitrag “Strategien zum Schutz von Veeam Backups durch unveränderliche Repository Server mit Linux XFS” berichtet.

Einige von Euch setzen möglicherweise schon Linux Repository Server mit dem XFS Dateisystem und Fastclone produktiv ein und möchten diese nun im die Funktion Immutable-Backups erweitern. Ich werde in diesem Beitrag erklären, wie sich dies mit wenigen Schritten bewerkstelligen lässt.

Schutz aktivieren

Um die Funktion zum Schutz der Backupdaten auf bestehenden XFS Repositories zu aktivieren, müssen wir diese im Veeam Backup Client v11 bearbeiten (Bild unten). Ab Version 11 ist im Abschnitt Repository eine neue Checkbox zu sehen (“make recent backups immutable for [x] days”). Dabei ist 7 Tage der kleinstmögliche Zeitraum für den Schutz. Sobald man die Checkbox aktiviert wird sehr wahrscheinlich eine Benachrichtigung wie unten dargestellt erscheinen. “Unable to set the immutability option: cannot find the transport service on server <your repo server>. Configure the server anyway?“. Wir bestätigen diese mit [Yes].

Wir müssen zur Aktivierung des Immutable Flags den Veeam Transport Service auf dem Ziel neu konfigurieren.

22. Januar 202128. Januar 2021

Strategien zum Schutz von Veeam Backups durch unveränderliche Repository Server mit Linux XFS

Angriffe auf IT-Infrastrukturen sind in letzter Zeit immer raffinierter geworden. Sie verschlüsseln nicht nur Live-Daten und ganze virtuelle Maschinen, sie haben auch gelernt, ganze Backups zu löschen, oder zu verschlüsseln. Dabei spielt es keine Rolle, ob Ihre Online-Backups in einem lokalen Repository, oder auf einem Cloud-Share gespeichert sind. Wenn dieser Fall eintritt und Sie kein Offline Backup wie beispielsweise Tape, oder einen sonstigen Plan B in der Hinterhand haben, werden Sie alt aussehen. Schlimmer noch: Wenn Sie in Ihrem Unternehmen für die Datensicherung verantwortlich sind, müssen Sie sich unangenehmen Fragen seitens der Geschäftsführung stellen.

Nun stellt sich die Frage, wie Sie die Backup-Daten schützen, falls ein Angreifer Zugriff auf Ihren Backup-Server erhält. Sobald er die Zugangsdaten zum Server hat, kann er alles tun, was der Backup-Administrator tun kann. Das Löschen von Backups zum Beispiel. Ein erster Schritt besteht darin, Ihre Backup-Systeme von Ihrer Domain zu trennen. Für den Fall, dass der Domain-Administrator-Account kompromittiert wird, gibt es immer noch eine (kleine) Barriere zwischen Angreifern und Ihren Backup-Systemen. Aber trotzdem werden Sie nie wissen, ob Angreifer Kenntnis von einem Zero-Day-Exploit haben, um Ihren Backup-Server zu übernehmen. Ein besserer Ansatz wäre es, Backups für eine definierte Zeitspanne gegen das Löschen zu schützen. Eine ähnliche Option gibt es bei AWS S3-Buckets, die üblicherweise als Offsite-Sicherungskopien verwendet werden. Das Zurückholen von Offsite-Backups nimmt eine beträchtliche Zeitspanne in Anspruch. Im Falle eines Kryptoangriffs ist die Zeit entscheidend und die Uhr tickt. Wäre es nicht großartig, unveränderliche Backups auf Ihren primären Repositories vor Ort zu haben? Gute Nachrichten. Es gibt Licht am Ende des Tunnels (und ich verspreche, es ist nicht der entgegenkommende Zug).

Unveränderliche (Immutable) Backups

Bevor wir ins Detail gehen, müssen wir klären, was unveränderliche Backups bedeuten. Die Idee ist, dass man einmal schreibt und dann die Dateien (Backups) für eine selbst definierte Zeitspanne geschützt sind. Selbst der Backup-Administrator kann sie nicht löschen, bevor die definierte Zeitspanne verstrichen ist.

Veeam Backup & Replication v11 wird eine native Funktion des Linux XFS-Dateisystems nutzen. XFS kann ein erweitertes Dateiattribut [i] setzen, das die Datei vor Umbenennung, Änderung, Löschung oder Hard-Linking schützt. Der Clou dabei ist, dass Backups mit einem nicht privilegierten Konto übertragen und geschrieben werden und das Immutable-Attribut von einem Dienst auf dem Repository-Server gesetzt und entfernt wird, der erhöhte Rechte hat und auf den von außen nicht zugegriffen werden kann.

Alles, was Sie benötigen, ist ein mit XFS formatiertes Linux-Repository und Veeam Backup & Replication v11, das demnächst erscheinen wird. (Update: Geplantes Erscheinungsdatum ist der 24.02.2021)