Bei meinem letzten Upgrade der Nextcloud habe ich auf meinem Server auch den Festplattenplatz geprüft und der benutzte Platz kam mir etwas komisch vor – also viel zu viel – der Speicher auf dem Server war zu meiner Überraschung fast voll. Deswegen habe ich ein paar Recherchen durchgeführt, um herauszufinden, wer denn da ungewöhnlich viel Platz benötigt. Der Server stellt nur eine Kommandozeile zur Verfügung. Aber auch damit kannst Du relativ einfach herausfinden, welche Ordner am meisten Platz benötigen. Nextcloud […]

Der Beitrag Nextcloud löscht alte Backups nicht & mysteriöse lu-Ordner in /tmp/ ist von bitblokes.de.

Die Distribution Network Security Toolkit  (NST) richtet sich mit ihren vorinstallierten Werkzeugen an Sicherheitsexperten und Netzwerkadministratoren. Neben dem aufgefrischten Unterbau gibt es im Wesentlichen kleinere Änderungen der Benutzeroberfläche.

Diese kurz WUI genannte Web-Schnittstelle startet ab sofort den Open Vulnerability Assessment Scanner (OpenVAS) und das Greenbone Vulnerability Management (Greenbone GVM) in einem Docker-Container, der jeweils den kompletten Funktionsumfang der Scanner bereitstellt.

Greenbone GVM liegt zudem in der aktuellen Community-Edition bei. Auch die anderen Tools hat das NST-Team auf den neuesten Stand gebracht.

Des Weiteren unterstützt der NST WUI ARP Scan unterstützt den konfigurierten Name Service (NS) Switch Hosts Resolver. Lässt man sich bei Dash-Cam-Videos den Fahrtverlauf auf einer Karte anzeigen, blendet WUI ein Acceleration Overlay ein.

Sämtliche Neuerungen fasst die Meldung auf der Website des Projekts zusammen.

Der Beitrag Network Security Toolkit basiert auf Fedora 38 erschien zuerst auf Linux-Magazin.

Die Distribution für Systemadministratoren nutzt jetzt den Linux Kernel 6.1, bietet sieben neue Programme und frischt das zugrundeliegende Debian-System auf. Verfügbar ist zudem Memtest86+ in der Version 6.10.

Diese aktualisierte Fassung des Hauptspeichertestprogramms bringt eine Fassung für UEFI-Systeme mit, die Finnix 125 im Bootmenü unter „Utilities“ offeriert. Aufgrund fehlender Signaturen lässt es sich allerdings nicht bei aktiviertem Secure Boot anwerfen.

Neu an Bord sind 2048, aespipe, iperf3, ncdu, netcat-traditional, ninvaders und vitetris. Weiterhin verfügbar ist das Paket netcat-openbsd, das auch standardmäßig das Kommando „nc“ stellt. Der Befehl „7z“ ruft im Hintergrund das Tool „7zr“ auf, sofern man nicht explizit das Paket „p7zip-full“ installiert.

„apt update“ holt die Paketinformationen sowohl aus dem „testing“- als auch dem „unstable“-Zweig. Das Apt-Pinning ist jedoch aktiviert, so dass Finnix Pakete aus „testing“ gegenüber denen aus „unstable“ bevorzugt.

Der Beitrag Finnix 125 bietet neue Pakete und Änderungen erschien zuerst auf Linux-Magazin.

Zur üblichen Arbeit eines Systemadministrators gehört der Umgang mit persistentem Speicher (a.k.a. Festplatte), der heutzutage in Form von HDDs, SSDs oder auch NVMes daherkommt. Üblicherweise werden in Produktivsystemen die Platten in einem RAID angeordnet, um bei einem Festplattenausfall die Verfügbarkeit des Systems zu erhöhen. Soll in diesem Zusammenhang allerdings eine Festplatte vor einem drohenden Ausfall manuell aus dem RAID entfernt werden, ist es ratsam, sie vorher sicher zu löschen. In diesem Artikel möchte ich allerdings kurz umschreiben, warum der Hinweis, Backups vor jeglicher Formatierung zu erstellen, so wichtig ist - besonders bei NVMe-Speichern.

Um die gleich folgende Syntax zu verstehen, sei noch gesagt, dass unter Linux ein bestimmtes Schema existiert, wie Festplatten oder eben NVMes angesprochen werden. Bei SCSI- bzw. SATA-Platten kennt man z. B. /dev/sda für die erste erkannte SATA-Festplatte (= sd für den Treiber und a für die Platte) und /dev/sda3 für die dritte Partition (= 3) auf der ersten erkannten SATA-Festplatte. Wichtig ist, dass "erste erkannte Festplatte" genau so relativ verstanden werden muss, wie es klingt. Wird, aus welchem Grund auch immer, eine andere Festplatte zu erst erkannt und ist die Buchstabenzuweisung nicht persistiert, ändert sich über mitunter auch die Zuweisung. Nicht ohne Grunde werden Linux-Nutzer angehalten, mit UUIDs eindeutig identifizierbare Bezeichner für ihre /etc/fstab zu nutzen.

Bei NVMe ist das scheinbar ähnlich, auch wenn es hier einen Zusatz gibt. Eine Partition auf einem NVMe-Gerät, das alleine in einem Rechner steckt (d. h. nur eine NVMe ist eingebaut) könnte /dev/nvme0n1p3 heißen. Hier bedeutet die Syntax, dass es sich um die dritte Partition (p3) auf dem ersten Namespace (n1) hinter dem Controller mit der Nummer 0, handelt, das über den NVMe-Treiber angesprochen wird. NVMes verfügen mit Namespaces über eine weitere Abstraktionsschicht, sodass der NVMe-Controller seinen Storage in Namespaces unterteilen kann, die jeweils über eine eigene Partitionstabelle verfügen.

Im administrativen Umgang arbeitet man oft mit mehreren Block-Devices, einerseits der "Platte selber", klassischerweise einer /dev/sda, und den Partitionen, also /dev/sda3. Bei NVMe ist die "Platte selber" in den allermeisten Fällen ein Namespace, also /dev/nvme0n1 und NICHT /dev/nvme0.

Es gibt allerdings ein Szenario, wo man mal den Controller direkt ansprechen muss: beim Kommando nvme format. Hier gibt es eine Syntax, wo als Argument das NVMe-Device, also der Controller, angesprochen und der Namespace per Option übergeben wird. Ich durfte nun erleben, wie das sehr, sehr schiefgehen kann.

Wer nämlich glaubt, dass man von /dev/nvme1n1 auf den Controller /dev/nvme1 schließen kann, irrt sich gewaltig. Diese beiden Bezeichner haben streng genommen nichts miteinander zu tun. Und so kann es dazu führen, dass wenn

• man zwei NVMe-Devices hat
• /dev/nvme1n1 behalten und
• /dev/nvme0n1 mittels nvme format /dev/nvme0 -n 1 löschen möchte,

man sich potenziell den Boden unter den Füßen wegzieht und die eigentlich zu behaltende NVMe löscht - was nach der Formatierung mit der netten Fehlermeldung bash: <executable>: cannot execute binary file: Exec format error quitiiert wird, wenn man das nächste Kommando in der Bash aufrufen will.

Der Zusammenhang wird zwischen /dev/nvmeX und /dev/nvmeYn1 nämlich - NVMe Multpathing sei dank - dynamisch gewählt. Und ich bin nicht der einzige, dem das aufgefallen ist. Normalerweise hängen die Bezeichner zusammen, aber wenn man beim Tausch der NVMes zwischendurch Reboots durchführen muss, kann sich die Reihenfolge schon mal verdrehen - aber eben nur halb.

Und so muss man manuell nachprüfen, welches Device wirklich hinter dem Block-Device eines Namespaces steckt:

me@server:~$ ls -l /sys/block/nvme1n1/device
lrwxrwxrwx 1 root root 0 Aug 31 19:43 /sys/block/nvme1n1/device -> ../../nvme0

In diesem Fall steckt hinter /dev/nvme1n1 das Device /dev/nvme0. Muss man beachten.

Dies hat übrigens nicht nur auf das Formatieren Auswirkungen: auch die SMART-Überwachung zeigt für /dev/nvme0n1 und /dev/nvme0 völlig unterschiedliche Resultate an. An dieser Stelle ist mir übrigens erst aufgefallen, dass der Zusammenhang zwischen den Devices mitunter nicht-systematisch gewählt werden könnte.

Was lernen wir daraus? Neue Treiber, wie in unserem Fall nvme, bringen neue Herausforderungen mit. Es ist gut, sich jedes Mal, wenn man seine Produktivsysteme mit neuen Fähigkeiten ausstattet, mit der Dokumentation und dem Standard hinter dem Treiber zu beschäftigen. Darüber hinaus - und das ist noch viel wichtiger - sollte man jederzeit auf seine Backups als zusätzliches Sicherheitsnetz achten, weil es immer etwas geben wird, was man übersieht. In meinem Fall hatte ich Glück, weil der betroffene Server aus der Testumgebung stammte und das Formatieren der falschen Platte nur vernachlässigbare Auswirkungen hätte - ich bin aber froh, auf diesem Umstand aufmerksam geworden zu sein und wollte euch an dieser Stelle einfach "vorwarnen".