Installation

Daniel's Disk Tester wird nativ auf Debian betrieben. Direkter Hardwarezugriff (USB-SATA-Bridges, SMART-Passthrough, Hotplug) funktioniert so am zuverlässigsten. Voraussetzung ist ein Debian-System (12 oder 13) mit root-Zugang.

Installation mit einem Befehl

Als root auf dem Zielrechner:

curl -fsSL https://disk-tester.znbw.de/install.sh | sudo bash

Das Skript lädt die aktuelle Version von der Homepage (das Paket ist dort eingebaut, es ist kein GitHub-Zugriff und kein Token nötig), prüft die SHA256-Prüfsumme des Pakets und startet deploy/install.sh aus dem Paket. Das Release-Paket ist fertig gebaut, auf dem Zielsystem wird nichts kompiliert.

Updates und Rollback: siehe Updates.

Installation aus dem Quellcode

Auf dem Zielrechner als root, aus einer Kopie des Repos:

./deploy/install.sh

Das Skript

• installiert fehlende Pakete (smartmontools, e2fsprogs, util-linux, hdparm, nvme-cli, rsync, curl) und Node.js 24 über NodeSource, falls keine passende Node.js-Version (ab 20.9) vorhanden ist,
• legt alles unter /appdata/disk-tester ab (siehe unten),
• führt beim Quellcode-Install npm ci und npm run build aus (beim Release-Paket entfällt das),
• aktiviert und startet den systemd-Dienst disk-tester.

Eine alte Installation unter /opt/disk-tester bzw. /var/lib/disk-tester wird automatisch übernommen. Das Skript ist idempotent: Erneutes Ausführen aktualisiert die Installation, die Daten bleiben erhalten.

Von einem Entwicklungsrechner aus:

deploy/deploy-remote.sh <host>      # z. B. deploy/deploy-remote.sh 10.10.11.98

Das kopiert das Repo per rsync (ohne node_modules, .next, data) nach /appdata/disk-tester/src auf dem Host und startet dort install.sh. Ohne lokales rsync (z. B. Git Bash unter Windows) wird stattdessen tar über ssh verwendet.

Verzeichnisse unter /appdata/disk-tester

Pfad	Inhalt
releases/<version>/	Installierte Versionen. Jedes Update legt ein neues Verzeichnis an, ältere bleiben für den Rollback liegen.
app	Symlink auf die aktive Version unter releases/. Der Dienst startet immer über diesen Pfad.
data/	Einstellungen, bekannte Platten und Job-Historie. Bleibt bei Updates erhalten.
disk-tester.env	Optionale Umgebungsvariablen (Rechte 600, enthält ggf. Passwörter).

Die Basis lässt sich mit der Umgebungsvariable DISK_TESTER_HOME ändern (nur für das Installationsskript).

Dienst verwalten

systemctl status disk-tester
journalctl -u disk-tester -f
systemctl restart disk-tester

Beim Stoppen des Dienstes werden laufende badblocks-Prozesse beendet (KillMode=mixed).

Konfiguration über die Env-Datei

Zusätzliche Umgebungsvariablen stehen in /appdata/disk-tester/disk-tester.env (Format KEY=Wert, eine pro Zeile). Nach Änderungen: systemctl restart disk-tester. install.sh legt eine auskommentierte Vorlage für den Mailserver an.

Variable	Bedeutung	Standard
PORT	HTTP-Port	3000
DISK_TESTER_DATA_DIR	Datenverzeichnis (Einstellungen, Platten, Jobs)	./data (systemd: /appdata/disk-tester/data)
DISK_TESTER_AUTH	HTTP Basic Auth benutzer:passwort; leer = aus	aus
DISK_TESTER_ALLOW_NO_AUTH	1 = bewusst ohne Zugriffsschutz (internes Netz), blendet die Warnung aus	aus
DISK_TESTER_MOCK	1 = simulierte Platten statt echter Hardware	aus
DISK_TESTER_UPDATE_URL	Basis-URL der Update-Schnittstelle	https://disk-tester.znbw.de
DISK_TESTER_UPDATE_CHECK	0 = keine Update-Prüfung	an
SMTP_HOST / SMTP_PORT / SMTP_SECURE	Mailserver, Port (Standard 587), true = TLS ab Verbindungsbeginn (465)	leer = keine Mails
SMTP_USER / SMTP_PASSWORD / SMTP_FROM	Login und Absenderadresse (ohne SMTP_FROM wird SMTP_USER verwendet)	leer
SMTP_TO	Empfänger, die beim ersten Start in die Einstellungen übernommen werden	leer
NODE_ENV	production im Betrieb	–

Die Mail-Einstellungen sind unter Benachrichtigungen beschrieben.

Zugriffsschutz

Die Anwendung läuft als root und kann Platten löschen. Daher nicht ungeschützt ins Internet stellen (Reverse Proxy mit TLS oder VPN).

• DISK_TESTER_AUTH=benutzer:passwort aktiviert HTTP Basic Auth.
• Ohne DISK_TESTER_AUTH zeigt die Oberfläche eine Warnung. Ist der Zugriff im internen Netz bewusst offen, blendet DISK_TESTER_ALLOW_NO_AUTH=1 sie aus.

Hinweis: BIOS-Hotplug für SATA-Ports

Damit am Rechner selbst Platten im laufenden Betrieb erkannt werden, muss Hotplug für die SATA-Ports aktiv sein. Meldet der Kernel für einen leeren Port SStatus 4 (zu sehen mit dmesg | grep -i sstatus), ist der Port per BIOS/UEFI abgeschaltet oder als „nicht hot-plug-fähig“ konfiguriert. Dann im BIOS für den Port die Option Hot Plug aktivieren (je nach Hersteller bei den SATA-Einstellungen, pro Port) und den Port nicht als „External“ oder „Disabled“ stehen lassen. Danach werden neu angesteckte Platten ohne Neustart erkannt.