Passwort Richtline bei VMware Linux Appliances einstellen

Über den Sinn von regelmäßigen Passwortwechseln lässt sich lange streiten. Der Zwang, alle x Tage ein neues Kennwort zu vergeben, welches sich vom vorherigen stark unterscheiden muss, halte ich für kontraproduktiv. Aber das ist ein anderes Thema.

Das Szenari, über das ich sprechen möchte, sieht folgendermaßen aus: eine nicht produktive Labor-Umgebung, bei der immer genau dann das Passwort abgelaufen ist, wenn man gerade wichtigeres zu tun hat. Die Appliance xy zeigt mir den virtellen Mittelfinger und nötigt mich zur Eingabe eines neuen Passwortes, das mindestens 5 klingonische Sonderzeichen enthalten muss. Grrr! Dies ist ein nicht-produktives Lab und ich verwende für alle – ja, alle – Dienste und Logins das gleiche Passwort. Es geht um Machbarkeit – nicht Sicherheit.

Bevor das jetzt jemand falsch versteht: 
Ja, im Live-Betrieb wäre das eine sehr dumme Idee.

Password Expiration

Der erste Schritt ist, die Ablaufzeit des Kennworts auf Null (Achtung! nicht bei VCF!) oder einen sehr langen Zeitraum zu setzen. Standardmäßig setze ich hier 9000 Tage ein. Das sind umgerechnet etwa 24 Jahre und 7 Monate. Das sollte reichen 😉

Oftmals lässt sich dieser Wert nicht in der GUI konfigurieren. Dann ist ist die CLI gefragt. Die Einstellung verbirgt sich bei den meisten Linux Varianten in einer Konfigurationsdatei namens login.defs. Wir können auf der shell eine schnelle Abfrage machen.

cat /etc/login.defs | grep PASS

PASS_MAX_DAYS 90
PASS_MIN_DAYS 0
PASS_MIN_LEN 8
PASS_WARN_AGE 7

Voila! PASS_MAX_DAYS ist unsere Passwort Ablaufzeit.

Zur Veränderung müssen wir den vi verwenden, da nur selten andere Editoren in diesen Systemen verfügbar sind. Aber keine Angst vor vi. De ist eigentlich ganz nett. 🙂 Wir öffnen die Konfiguration mit:

vi /etc/login.defs

Jetzt Ruhe bewahren und nur die Taste i (für insert) drücken. Jetzt suchen wir in der Datei die Zeile mit PASS_MAX_DAYS und ändern den Wert auf beispielsweise 9000. Wer möchte, kann auch das Mindestalter PASS_MIN_DAYS auf 0 setzen. Damit kann das Passwort ohne Wartezeit erneut gewechselt werden.

Um unsere Änderung zu speichern drücken wir die ESC-Taste und danach die Taste mit dem Doppelpunkt. Unten links erscheint ein Doppelpunkt und zeigt, dass wir im Command-Modus sind. Wir geben die Zeichen wq (write, quit) und drücken Enter.

Sonderfall NSX-T mit VCF

Die Ablaufzeit der vordenfinierten Konten admin, root und audit unter NSX-T werden auf der Shell des NSX-Mangers mit einem eigenen Kommando gesetzt. Dazu verbindet man sich per SSH mit der Virtual-IP (VIP) des Management Clusters und wird zum aktuellen Master-Knoten weitergeleitet.

Um die Ablaufzeit der drei Konten auf 9000 Tage festzulegen, gibt man folgende drei Befehle ein:

set user admin password-expiration 9000
set user root password-expiration 9000
set user audit password-expiration 9000

In NSX-T Umgebungen ohne VCF dürfen die Ablaufzeiten der Passwörter ganz deaktiviert werden.

Achtung! bei NSX-T in Verbindung mit VCF führt dies aber zu Problemen beim Upgrade. Der Vollständigkeit halber hier die Befehle zur Deaktivierung:

clear user admin password-expiration
clear user root password-expiration
clear user audit password-expiration

Kontrolle

Die Ablaufzeit in NSX-T kann mit folgenden Kommandos abgefragt werden:

get user admin password-expiration
get user root password-expiration
get user audit password-expiration

Passwort History

Normalerweise reichen die obigen Änderungen aus. Wenn wir aber das Ablaufdatum verpasst haben und beim Login ein neues Passwort setzen mussten, dann können wir nicht wieder auf unser altes Passwort zurück wechseln. Das System merkt sich eine definierte Anzahl vergangener Passworte und erlaubt hier kein Recycling. Aber auch das können wir ändern. In vielen Linux Varianten gibt es dafür den daemon für pluggable authentication modules (pam.d). Die Konfiguration liegt unter /etc/pam.d/common-password. Systeme mit root Zugang können statt dessen auch die Konfiguration in /etc/pam.d/system-password haben.

vi /etc/pam.d/system-password

Hier setze ich den Wert remember=0. Damit kann das Wunschpasswort sofort neu gesetzt werden. Als root User genügt auf der shell das Kommando:

passwd

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.

Ausstattung der Geräterückseite

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. 🙂

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.

Quelle: VMware

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.

Quelle: VMware

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.

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

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.

„Veeam Immutable Backups auf vorhandenen Linux XFS Repositories aktivieren“ weiterlesen