Transparenzhinweis: Der Entwurf dieses Artikels wurde mithilfe der Mistral-KI Le Chat erstellt und von mir redigiert.

Versteckte CLI-Optionen: Warum Entwickler sie nutzen – und warum das umstritten ist

In der Welt der Open-Source-Software gibt es eine Praxis, die immer wieder für Diskussionen sorgt: das Verstecken von CLI-Optionen (Command Line Interface). Diese Optionen sind oft nicht in der offiziellen Dokumentation aufgeführt, werden aber dennoch im Code implementiert – sei es für Debugging-Zwecke, als Notlösung für spezielle Anwendungsfälle oder als „Geheimtipp“ für erfahrene Nutzer.

Ein Beispiel ist der Commit im xfsprogs-Projekt, der die Erstellung von XFS-Dateisystemen kleiner als 300 MB standardmäßig blockiert. Gleichzeitig wurde eine undokumentierte Option (--unsupported) eingeführt, um diese Beschränkung zu umgehen – allerdings ohne Hinweis in der Manpage mkfs.xfs(8) oder Hilfeausgabe.

Doch warum tun Entwickler das? Und welche Vor- und Nachteile hat diese Praxis für Nutzer, Maintainer und die Community?

Warum versteckte CLI-Optionen existieren

1. Flexibilität für Entwickler und Tester

• Debugging & Testing: Versteckte Optionen ermöglichen es Entwicklern, spezielle Testumgebungen zu simulieren oder Fehler zu reproduzieren, ohne die Stabilität der Software für Endnutzer zu gefährden.
• Beispiel: Im xfsprogs-Commit wird die 300-MB-Beschränkung für automatisierte Tests (fstests) deaktiviert, wenn bestimmte Umgebungsvariablen gesetzt sind. Das verhindert, dass Hunderte von Tests angepasst werden müssen.

2. Schnelle Lösungen für Nischenprobleme

• Manchmal gibt es seltene Anwendungsfälle, die so selten sind, dass eine offizielle Unterstützung nicht sinnvoll erscheint.
• Beispiel: Die Option --unsupported für mkfs.xfs, da diese im Normalbetrieb gefährliche Folgen, wie den Verlust von Leistung und Redundanz, haben können.

3. Vermeidung von Missbrauch

• Manche Optionen sind potenziell gefährlich (z. B. das Umgehen von Sicherheitsprüfungen). Durch das Verstecken sollen nur Nutzer mit entsprechendem Wissen darauf zugreifen.

Die Kehrseite der Medaille: Warum versteckte Optionen problematisch sind

1. Mangelnde Transparenz

• Open Source lebt von Transparenz und Gemeinschaft. Versteckte Optionen widersprechen diesem Prinzip: Nutzer wissen nicht, welche Möglichkeiten es gibt, und können die Software nicht voll ausschöpfen und damit nicht uneingeschränkt nutzen.
• Frage: Wenn eine Option (nur in seltenen Ausnahmefällen) nützlich ist, warum sollte sie nicht dokumentiert werden?

2. Wartungsaufwand und „Technical Debt“

• Undokumentierte Features werden schnell zu „Technical Debt“: Neue Entwickler kennen sie nicht, Nutzer stoßen zufällig darauf und die Optionen werden nie offiziell unterstützt, obwohl sie vielleicht weit verbreitet sind.
• Beispiel: Im Linux-Kernel gibt es zahlreiche obskure Kernel-Parameter, die nur in Mailinglisten oder alten Foren erwähnt werden.

3. Frustration für Nutzer

• Nutzer, die auf ein Problem stoßen, finden keine Lösung in der Dokumentation, obwohl diese vielleicht existiert. Das führt zu unnötigen Support-Anfragen oder Workarounds.
• Beispiel: „Für eigene Tests möchte ich XFS-Dateisysteme kleiner 300 MB erstellen. Bis ich die Option --unsupported im Quelltext gefunden habe, war mir dies nicht möglich, ohne eine veraltete Version von xfsprogs zu nutzen.“

Deine Meinung zählt: Sollten versteckte CLI-Optionen abgeschafft werden?

Die Diskussion um versteckte Optionen ist auch eine Frage der Philosophie: Sollte Open-Source-Software maximale Freiheit bieten – auch auf Kosten von Komplexität? Oder sollte sie benutzerfreundlich sein und nur offizielle, getestete Features anbieten?

Was denkst du?

• Hast du schon einmal von einer versteckten CLI-Option profitiert oder dich über das Fehlen einer Dokumentation geärgert?
• Sollten Projekte wie xfsprogs alle Optionen offenlegen, selbst wenn sie offiziell nicht unterstützt und im IT-Betrieb gefährlich sind?
• Oder ist es in Ordnung, wenn Entwickler „Hintertüren“ für spezielle Fälle einbauen?

Teile deine Erfahrung in den Kommentaren!

Geschäftsführer Alexander Pockrandt verlässt die doppelte Führungsspitze des Zentrums für Digitale Souveränität. Leonhard Kugler wird gemeinsam mit Pamela Krosta-Hardl die Geschäfte führen.

Wer meinem Blog folgt und, wie im Artikel „PHP 7.4 FPM auf PHP 8.1 FPM für Nextcloud“, die externe PHP-Quelle von https://deb.sury.org/ eingebaut hat und später der Anleitung „PHP 8.2 FPM für Nextcloud 28“ gefolgt ist, könnte noch auf PHP 8.2 FPM hängen geblieben sein. Da sich diese Version im Status Security fixes only befindet, ist ein Wechsel auf eine höhere Version absolut empfehlenswert. Diese PHP-Version lässt sich recht einfach auf PHP 8.4 FPM umstellen. Unter dem Raspberry Pi OS ist das mit wenigen Befehlen erledigt. In diesem Beitrag zeige ich kurz, wie man PHP 8.2 deaktiviert, PHP 8.4 installiert und Nextcloud anschließend mit der neuen Version betreibt.

Vor der Umstellung empfiehlt es sich, ein Backup der Installation und der Datenbank anzulegen. Außerdem sollte geprüft werden, ob die eingesetzten Apps bereits mit Nextcloud 33 und PHP 8.4 kompatibel sind.

Installierte PHP-Version prüfen

Das System sollte zunächst auf den aktuellen Stand gebracht werden:

sudo apt update && sudo apt upgrade

Jetzt prüfen, welche PHP-Version aktuell aktiv ist:

php -v

Falls Apache mit PHP-FPM genutzt wird, lohnt sich auch ein Blick auf die aktiven Module und Konfigurationen.

PHP 8.4 und benötigte Module installieren

Wer von PHP 8.2 auf PHP 8.4 wechselt, installiert zunächst die neue Version samt der für Nextcloud üblichen Erweiterungen:

sudo apt update

sudo apt install php8.4 php8.4-mbstring php8.4-gd php8.4-curl php8.4-imagick php8.4-intl php8.4-bcmath php8.4-gmp php8.4-mysql php8.4-zip php8.4-xml php8.4-apcu libapache2-mod-php8.4 php8.4-bz2 php8.4-redis

PHP 8.2 deaktivieren und PHP 8.4 aktivieren

Nun wird PHP 8.2 deaktiviert und PHP 8.4 aktiviert:

sudo update-alternatives --config php

sudo update-alternatives --config php
Es gibt 7 Auswahlmöglichkeiten für die Alternative php (welche /usr/bin/php bereitstellen).

  Auswahl      Pfad                  Priorität Status
------------------------------------------------------------
  0            /usr/bin/php.default   100       automatischer Modus
  1            /usr/bin/php.default   100       manueller Modus
  2            /usr/bin/php7.4        74        manueller Modus
  3            /usr/bin/php8.1        81        manueller Modus
* 4            /usr/bin/php8.2        82        manueller Modus
  5            /usr/bin/php8.3        83        manueller Modus
  6            /usr/bin/php8.4        84        manueller Modus
  7            /usr/bin/php8.5        85        manueller Modus

Hier die entsprechende Nummer eingeben – in diesem Fall die 6 für PHP 8.4:

sudo update-alternatives --config php
Es gibt 7 Auswahlmöglichkeiten für die Alternative php (welche /usr/bin/php bereitstellen).

  Auswahl      Pfad                  Priorität Status
------------------------------------------------------------
  0            /usr/bin/php.default   100       automatischer Modus
  1            /usr/bin/php.default   100       manueller Modus
  2            /usr/bin/php7.4        74        manueller Modus
  3            /usr/bin/php8.1        81        manueller Modus
  4            /usr/bin/php8.2        82        manueller Modus
  5            /usr/bin/php8.3        83        manueller Modus
* 6            /usr/bin/php8.4        84        manueller Modus
  7            /usr/bin/php8.5        85        manueller Modus

Die Abfrage der Version zeigt, ob die Umstellung auf PHP 8.4 angenommen wurde.

php -v

PHP 8.4 FPM starten und Apache neu laden

Anschließend wird der neue FPM-Dienst aktiviert und gestartet:

sudo a2disconf php8.2-fpm
sudo apt install php8.4-fpm
sudo a2enconf php8.4-fpm

Der Neustart des Webservers aktiviert nun die aktuelle PHP-Version:

sudo service apache2 restart

Nextcloud-Konfiguration

Sollten in Nextcloud anschließend wieder die bekannten Fehlermeldungen erscheinen, sind diese am besten Schritt für Schritt abzuarbeiten. Dazu werden zunächst die neue php.ini geöffnet:

sudo nano /etc/php/8.4/fpm/php.ini

und anschließend die Werte für memory_limit sowie session.gc_maxlifetime gemäß den Empfehlungen angepasst:

memory_limit = 512M
session.gc_maxlifetime = 3600

Am Ende der php.ini werden außerdem noch die Einstellungen für den Zwischenspeicher OPcache ergänzt:

opcache.enable=1
opcache.interned_strings_buffer=64
opcache.max_accelerated_files=10000
opcache.memory_consumption=256
opcache.save_comments=1
opcache.revalidate_freq=1

Zur Optimierung von PHP 8.4 FPM können speziell auf einem Raspberry Pi 5 mit 8 GB RAM in der Datei www.conf

sudo nano /etc/php/8.4/fpm/pool.d/www.conf

die folgenden Werte angepasst werden. Standardmäßig stehen dort in der Regel:

pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3

Diese werden dann auf folgende Werte geändert:

pm = dynamic
pm.max_children = 200
pm.start_servers = 20
pm.min_spare_servers = 10
pm.max_spare_servers = 30

Anschließend wird der Dienst neu gestartet:

sudo service php8.4-fpm restart

Danach muss in der apcu.ini noch das Command Line Interface (CLI) des PHP-Caches aktiviert werden. Dazu die Datei öffnen:

sudo nano /etc/php/8.4/mods-available/apcu.ini

und am Ende folgende Zeile ergänzen:

apc.enable_cli=1

Ist dies geschehen, wird der Webserver ein letztes Mal neu gestartet:

sudo service apache2 restart

Nextcloud prüfen

Danach sollte die Nextcloud-Instanz im Browser aufgerufen werden. Unter Administrationseinstellungen / System lässt sich kontrollieren, ob die neue PHP-Version erkannt wurde.

Zur Sicherheit zusätzlich die Logdateien von Apache, PHP-FPM und Nextcloud prüfen.

Fazit

Die Umstellung von PHP 8.2 auf PHP 8.4-fpm für Nextcloud 32 ist unter Raspberry Pi OS schnell erledigt. Wichtig ist vor allem, die benötigten PHP-Module zu installieren und anschließend die alte FPM-Konfiguration sauber durch die neue zu ersetzen.

Der Beitrag PHP 8.4 FPM für Nextcloud 33 erschien zuerst auf intux.de.

Anfang Oktober 2025 hat das Raspberry Pi OS ein Upgrade auf Version 13 mit dem Codenamen Trixie erhalten. Dies setzt die Serverbetreiber wieder einmal mächtig unter Druck, obwohl Bookworm noch weitere Jahre unterstützt wird. Die Entwickler empfehlen eine Neuinstallation. Es ist immer von Vorteil, ein Betriebssystem wie im Falle von Trixie neu und somit sauber aufzusetzen. Da ich aber seit Jahren eine gut funktionierende Nextcloud-Instanz auf meinem Raspberry Pi pflege, die ich in meinem Alltag produktiv einsetze, wäre es zu schade, noch einmal ganz von vorn anfangen zu müssen. Aus diesem Grund war ich auf der Suche nach einem funktionierenden Tutorial für das anstehende OS-Upgrade. Schon beim Umstieg auf Bookworm war der Blog von Sascha Syring sehr hilfreich. Also hoffte ich auch dieses Mal, wieder hier fündig zu werden. Der Artikel „Raspberry Pi OS – Update von Bookworm (12) auf Trixie (13)“ von Sascha beschreibt einmal mehr die genaue Vorgehensweise.

Ich konnte somit alles 1:1 mit meinem System umsetzen. Hier nun alle Schritte mit den entsprechenden Erläuterungen.

Bevor es jedoch losgeht, noch ein wichtiger Hinweis:

Denkt bitte daran, vorher ein Backup zu erstellen! Das Upgrade birgt nicht zu unterschätzende Gefahren.

Upgrade auf Trixie

Zuerst sollte man dafür sorgen, das System inklusive Kernel und aller Abhängigkeiten auf den neuesten Stand zu bringen. Hierzu führt man folgenden Befehl aus:

sudo apt update && sudo apt full-upgrade

Vorbereitend wurde in meinem Fall die alte PHP-Fremd-Quelle deaktiviert.

Hierzu setzt man eine Raute (#) vor den Eintrag, öffnet dazu die php.list mit einem Editor

sudo nano /etc/apt/sources.list.d/php.list

und kommentiert die Zeile entsprechend aus:

#deb https://packages.sury.org/php/ bullseye main

Danach werden die hauseigenen Quellen des Raspberry Pi OS auf Trixie umgestellt:

sudo nano /etc/apt/sources.list

Hierzu wird in allen Quellen wie folgt bookworm durch trixie ersetzt:

deb http://deb.debian.org/debian trixie main contrib non-free non-free-firmware
deb http://security.debian.org/debian-security trixie-security main contrib non-free non-free-firmware
deb http://deb.debian.org/debian trixie-updates main contrib non-free non-free-firmware

Das Gleiche führt man analog hier durch:

sudo nano /etc/apt/sources.list.d/raspi.list

deb http://archive.raspberrypi.org/debian/ trixie main

Da beim ersten Versuch des Upgrades noch einiges schieflief, möchte ich an dieser Stelle darauf hinweisen, dass das Entfernen folgender Pakete für das Gelingen extrem wichtig ist!

sudo apt purge -y raspberrypi-ui-mods
sudo apt purge -y lxplug-batt
sudo apt purge -y lxplug-cpu

Ist dies erledigt, startet man via

sudo apt update && sudo apt full-upgrade

das eigentliche Upgrade. Hierzu ist noch zu erwähnen, dass bei den Abfragen zu alten Konfigurationen diese erhalten bleiben sollen. An diesen Stellen also bitte immer die Vorgabe (N) während der Installation wählen.

Die Pakete rpd-wayland-all und rpd-x-all werden noch nachinstalliert:

sudo apt install rpd-wayland-all rpd-x-all

Aufgeräumt wird mit:

sudo apt autoremove
sudo apt clean

und das System wird neu gestartet:

sudo reboot now

Überprüfung

Nach dem Neustart sollte der Befehl

sudo cat /etc/os-release

nun Folgendes ausgeben:

PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
NAME="Debian GNU/Linux"
VERSION_ID="13"
VERSION="13 (trixie)"
VERSION_CODENAME=trixie
DEBIAN_VERSION_FULL=13.4
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

Feintuning

Da der NetworkManager nach dem Neustart noch nicht arbeitet, sollte er mit

sudo systemctl enable NetworkManager && sudo systemctl start NetworkManager

aktiviert und gestartet werden.

PHP-Quelle wieder einbinden

Am Anfang der Anleitung hatte ich die PHP-Quelle auskommentiert. Das machen wir nun wieder rückgängig. Erscheint nun nach einem Update der Hinweis, dass der zugehörige Schlüssel abgelaufen ist, löscht man diesen, lädt den aktuellen herunter und liest ihn neu ein.

sudo rm -f /usr/share/keyrings/deb.sury.org-php.gpg
sudo curl -sSLo /etc/apt/trusted.gpg.d/sury-php.gpg https://packages.sury.org/php/apt.gpg

Die Paketquellen werden nun abermals eingelesen und das System aktualisiert:

sudo apt update && sudo apt upgrade

Da die PHP-Quelle allerdings noch nicht für Trixie optimiert ist, ersetzt man auch hier bookworm bzw. bullseye durch trixie:

sudo nano /etc/apt/sources.list.d/php.list

#deb https://packages.sury.org/php/ bullseye main

Ein weiteres Mal werden die Paketquellen eingelesen und das System aktualisiert:

sudo apt update && sudo apt upgrade

Ist dies geschehen, ist das Upgrade von Raspberry Pi OS Version 12 auf 13 abgeschlossen.

Viel Erfolg bei der Umsetzung!

Der Beitrag Raspberry Pi OS Bookworm -> Trixie erschien zuerst auf intux.de.

Thunderbird stellt seine Entwicklung neu auf und zeigt mehr Offenheit. Die Macher veröffentlichen erstmals öffentliche Roadmaps, die auch für weniger technikaffine Nutzer verständlich bleiben. Damit soll klarer werden, wohin sich der Mailclient in den kommenden Jahren bewegt. Das Projekt erlebt derzeit eine Phase großer Veränderungen. Neben Windows, macOS und Linux wächst Thunderbird seit der Übernahme […]

Der Beitrag Thunderbird zeigt klare Zukunftspläne erschien zuerst auf fosstopia.

63% Prozent der befragten europäischen Unternehmen verwenden Open-Source-Software.

GNOME 48.10 wurde vom GNOME Projekt veröffentlicht und markiert den letzten Wartungsschritt dieser Serie. Die Aktualisierung bringt viele gezielte Fehlerbehebungen, die den Desktop spürbar stabiler machen. Mehrere Kernkomponenten erhalten Verbesserungen, die sich direkt im Alltag bemerkbar machen. GNOME Shell reagiert nun zuverlässiger nach dem Aufwachen des Systems. Probleme mit der Tastaturauswahl und der Navigation in […]

Der Beitrag GNOME 48.10 schließt die Serie mit wichtigen Korrekturen ab erschien zuerst auf fosstopia.

Mozilla hat Thunderbird 149 veröffentlicht und liefert ein Update mit spürbaren Verbesserungen. Nutzer können nun einzelne Kontakte exportieren und so Adressbücher leichter sichern. Markierte Nachrichten in EWS Konten bleiben zudem endlich auf allen Geräten erhalten. Neue Adressbücher entstehen nun direkt im Account Hub. Die Einrichtung wirkt dadurch klarer und zentraler. Viele Fehler im Verfassen-Fenster wurden […]

Der Beitrag Thunderbird 149 bringt viele wichtige Korrekturen erschien zuerst auf fosstopia.

Die neue Version 3.5 des OpenShot Video Editor bringt große Verbesserungen in der Performance mit schnellerer Timeline, verbesserter Audiobearbeitung und mehr Stabilität.

Open-Source-Entwickler sind durch KI-Meldungen massiv überlastet. Die Linux Foundation und Tech-Unternehmen kündigen nun Hilfe an.

Software-Beschaffung für öffentliche Verwaltungsbehörden sind durch die EVB-IT geregelt.

Das beliebte Open-Source-Bildbearbeitungstool GIMP veröffentlicht ein Jahr nach Beginn der Entwicklungsphase die Version 3.2.

Ab September 2026 müssen sich Entwickler bei Google registrieren, damit ihre Apps auf Android-Geräten installiert werden können.

GitHub Store ist ein kostenfreier Open-Source-App-Store, der plattformübergreifendes Herunterladen und Installieren direkt von GitHub anbietet.

sudo-rs hat sich zum Ziel gesetzt, einen Ersatz für das klassische sudo bereitzustellen. Dabei setzt das Projekt auf Rust, um eine "safety oriented and memory safe implementation" zu realisieren.

Hintergrund

Kurz zum Hintergrund: sudo unterscheidet sich von normalen Kommandos dadurch, dass das setuid-Flag der Binary gesetzt ist und das Programm beim Aufruf direkt mit Root-Rechten gestartet wird. Die Privilege Escalation ist wiederum die Voraussetzung dafür, dass ein Nutzer nach erfolgreicher Authentifizierung Root-Rechte annehmen kann. Sind jedoch im sudo-Programm selbst Bugs vorhanden, wird die Rechteerweiterung zum Sicherheitsrisiko. Wichtig an dieser Stelle: Privilege Escalation bezeichnet zunächst nur die Technik. Sie tritt häufig als Folge von Sicherheitslücken auf, hat aber auch legitime Einsatzszenarien.

Die gesamte Sicherheit hängt also von den Werkzeugen ab, die über setuid-Privilegien verfügen. Genau hier möchte sudo-rs ansetzen und eine Implementierung anbieten, die vom Speichersicherheitsmodell von Rust profitiert, um das Risiko bisher unentdeckter Sicherheitslücken in der Speicherverwaltung zu reduzieren.

Neue Darstellung von Passwörtern

Dass sudo-rs kein vollständiges Drop-in-Replacement wird, zeigt die Änderung, dass Passwörter nun standardmäßig in der Konsole maskiert angezeigt werden. Bisher hat sudo jegliche Ausgabe unterdrückt.

Administratoren, die dieses Verhalten abstellen wollen, können Defaults !pwfeedback in die sudoers-Datei einfügen. Das ist insbesondere dann relevant, wenn andere Programme davon abhängen, z. B. in Unit-Tests.

Die spannende Frage, die sich hierbei natürlich stellt, betrifft die Sicherheit. Natürlich ergibt sich ein neuer Seitenkanal, da ein Angreifer, der auf den Bildschirm schauen kann, die Länge des Passworts erfährt. Dabei sollte man allerdings im Hinterkopf behalten, dass bereits vor 25 Jahren demonstriert wurde, dass aus SSH-Sitzungen anhand der Paket-Timings während der Tastenanschläge Passwörter rekonstruiert werden können. Für einen Angreifer mit Fähigkeiten zur Massenüberwachung ergeben sich demnach keine grundlegend neuen Informationen.

Mit Ubuntu 26.04 LTS dabei

sudo-rs wurde bereits in Ubuntu 25.10 eingeführt. Ubuntu 26.04 wird damit der erste LTS-Release sein, der das neue Tooling nutzt.

Im August 2025 hat Google angekündigt ↗, dass es ab September 2026 nicht mehr möglich sein wird, Anwendungen für die Android-Plattform zu entwickeln, ohne sich zuvor bei Google registriert zu haben.

Ab September 2026 müssen alle Android-Apps von bestätigten Entwicklern registriert werden, damit sie auf zertifizierten Android-Geräten installiert werden können.

Euer adminForge Team

Das Betreiben der Dienste, Webseite und Server machen wir gerne, kostet aber leider auch Geld. Unterstütze unsere Arbeit mit einer Spende und diskutiere ins unserem Chat mit.

by adminForge.

Einerseits senkt das Vibe Coding die Eintrittsschwelle und ermöglicht auch weniger erfahrenen Entwicklern die Mitarbeit, andererseits wächst der Aufwand in der Qualitätskontrolle und beim…

Aus Open Collective Europe wird Open Source Europe. Die Plattform weitet ihren Fokus aus und möchte das Open-Source-Ökosystem insgesamt in Europa und darüber hinaus ausbauen und stärken.

Es ist grundsätzlich sinnvoll, den Gesundheitszustand einer Festplatte im Blick zu behalten. Wie man fehlerhafte Sektoren erkennt, habe ich im Artikel „Überprüfung auf fehlerhafte Sektoren“ erläutert. Eine weitere Möglichkeit bietet die Self-Monitoring, Analysis and Reporting Technology, kurz S.M.A.R.T., die es ermöglicht, HDDs und SSDs zu überwachen. Diese Daten können je nach Ausstattung der Festplatten und des Betriebssystems ausgelesen werden.

Hierfür wird auf Linux-Systemen das Tool smartmontools benötigt. Die ausgelesenen Daten liefern wertvolle Hinweise auf mögliche Probleme mit dem Medium – bevor es zu einem Ausfall kommt.

Installation

Unter Debian-basierten Systemen ist smartmontools in den Paketquellen enthalten und schnell installiert:

sudo apt install smartmontools

S.M.A.R.T.-Werte abfragen

Um die aktuellen Werte eines Laufwerks auszulesen, genügt folgender Befehl:

sudo smartctl -a /dev/sdX

/dev/sdX steht dabei stellvertretend für das jeweilige Laufwerk, etwa /dev/sda oder /dev/nvme0n1 für NVMe-SSDs. Die Option -a sorgt dafür, dass alle verfügbaren Informationen ausgegeben werden.

Wichtig: sdX ist ein Platzhalter und muss durch die tatsächliche Bezeichnung des zu prüfenden Laufwerks ersetzt werden.

Was die Ausgabe verrät

Die Ausgabe von smartctl ist recht umfangreich und auf den ersten Blick etwas unübersichtlich. Neben allgemeinen Informationen wie Modell, Firmware-Version und Seriennummer finden sich dort auch die sogenannten S.M.A.R.T.-Attribute. Diese zeigen unter anderem wichtige Messwerte wie:

• den allgemeinen Gesundheitszustand (SMART overall-health self-assessment test result)
• die Temperatur des Laufwerks (Temperature)
• die Verfügbare Reserve (Available Spare)
• den Reserve-Schwellenwert (Available Spare Threshold)
• die verbrauchte Lebensdauer (Percentage Used)
• die gelesenen Dateneinheiten (Data Units Read)
• die geschriebenen Dateneinheiten (Data Units Written)

Ein Beispiel:

sudo smartctl -a /dev/nvme0n1

...
SMART overall-health self-assessment test result: PASSED
Temperature: 45 Celsius
Available Spare: 100%
Available Spare Threshold: 50%
Percentage Used: 4%
Data Units Read: 37.885.790 [19,3 TB]
Data Units Written: 28.019.142 [14,3 TB]
...

Für eine kurze Abfrage des Gesundheitszustands reicht hingegen:

sudo smartctl -H /dev/sdX

Ein Beispiel:

sudo smartctl -H /dev/nvme0

...
SMART overall-health self-assessment test result: PASSED
...

Fazit

Mit smartctl hat man unter Linux ein mächtiges Werkzeug zur Hand, um die Gesundheit von Laufwerken zu prüfen. Gerade bei älteren Festplatten lohnt sich ein regelmäßiger Blick auf die S.M.A.R.T.-Werte. Im Ernstfall können sie vor Datenverlust warnen – und geben den entscheidenden Anstoß, ein Backup nicht weiter aufzuschieben.

Der Beitrag Gesundheit der Festplatte überprüfen erschien zuerst auf intux.de.

Im Bundestag wächst der Wunsch nach mehr digitaler Eigenständigkeit. Eine neue Kommission untersucht derzeit, wie sich das Parlament unabhängiger von ausländischen Technologiekonzernen machen kann, wie der Blog Dr. Windows berichtet. Ziel ist ein stabiles digitales Umfeld, das sensible Abläufe schützt und zugleich den täglichen Betrieb sicherstellt. Die Arbeitsgruppe prüft das gesamte technische Fundament des Parlaments. […]

Der Beitrag Bundestag prüft tiefgreifenden Umbau seiner digitalen Infrastruktur erschien zuerst auf fosstopia.

Das Event FOSDEM 2026 bringt die Open Source Szene an einem Wochenende zusammen. Das FOSDEM 26 Event findet dieses Jahr vom 31. Januar bis 1. Februar in Brüssel statt. Über 1.100 Sprecher füllen zahlreiche Devrooms mit mehr als 1.000 Veranstaltungen. Die Bandbreite reicht von tiefen technischen Vorträgen bis zu kurzen Lightning Talks und lebhaften Diskussionsrunden. […]

Der Beitrag FOSDEM 2026: Volles Haus für Open Source erschien zuerst auf fosstopia.

Der freie Windows Nachbau ReactOS erreicht einen besonderen Meileinstein seiner Geschichte. Das Projekt blickt auf dreißig Jahre Entwicklung zurück und bleibt sowas wie ein Geheimtipp neben den großen Namen der Open Source Welt. Dabei verfolgt es ein Ziel das bis heute einzigartig wirkt. Das System möchte die Windows NT Architektur frei nachbauen. Anwendungen und Treiber […]

Der Beitrag 30 Jahre ReactOS: Ein ungewöhnliches Betriebssystem feiert Geburtstag erschien zuerst auf fosstopia.

Hinter Open Source steckt freiwillige Arbeit ohne Bezahlung und ohne offizielle Anerkennung. Eine Petition fordert Anerkennung von Open-Source-Arbeit als Ehrenamt.

Festplatten unterliegen einem natürlichen Verschleiß. Mit der Zeit können sogenannte Bad Sektoren entstehen – fehlerhafte Speicherbereiche, die nicht mehr zuverlässig gelesen oder beschrieben werden können. Eine regelmäßige Überprüfung kann helfen, Datenverlust frühzeitig zu erkennen und entsprechende Maßnahmen einzuleiten.

Was sind Bad Sektoren?

Bad Sektoren sind physisch oder logisch beschädigte Bereiche auf einem Datenträger. Physische Defekte entstehen durch Abnutzung, mechanische Schäden oder Produktionsfehler. Logische Bad Sektoren hingegen resultieren meist aus Softwareproblemen oder Stromausfällen und lassen sich mitunter korrigieren.

Analysewerkzeuge unter Linux

Linux bietet verschiedene Werkzeuge zur Analyse und Erkennung defekter Sektoren. Eines der bekanntesten Tools ist badblocks.

Ein einfacher Check lässt sich wie folgt durchführen:

sudo badblocks -vsn /dev/sdX

Ersetzt man dabei /dev/sdX durch das entsprechende Gerät, erhält man einen Überblick über den Zustand der Sektoren. Hierbei sucht badblocks gezielt nach defekten Blöcken der Festplatte.

Dabei sollte beachtet werden, dass dieser Vorgang – je nach Größe des Datenträgers – einige Zeit in Anspruch nehmen kann.

Fazit

Die regelmäßige Analyse auf Bad Sektoren ist ein wichtiger Bestandteil der Systempflege. Frühzeitig erkannte Fehler ermöglichen rechtzeitige Backups und gegebenenfalls den Austausch der betroffenen Hardware. Open-Source-Werkzeuge wie badblocks bieten unter Linux zuverlässige Möglichkeiten zur Diagnose – ganz ohne proprietäre Software.

Der Beitrag Überprüfung auf fehlerhafte Sektoren erschien zuerst auf intux.de.

Manch ein Leser kennt das vielleicht: Das CMS WordPress, mit dem man sich eigentlich gut auskennt, verhält sich plötzlich ganz anders als gewohnt. Meist hat das natürlich einen Grund.

Neulich bin ich auf ein solches Verhalten gestoßen, als ich Bilder, die mir von einem Fotografen übergeben wurden, in WordPress zur Weiterverarbeitung hochladen wollte. Zuvor hatte ich die Größen der Dateien in einer Stapelverarbeitung über das Terminal angepasst. Danach habe ich die Dateinamen nach bestimmten Vorgaben umbenannt.

Nachdem das erledigt war, habe ich das Bildmaterial in die Mediathek der Webseite hochgeladen. Dabei fiel mir auf, dass die Bezeichnungen der Bilder nicht den neuen Dateinamen entsprachen. Stattdessen trugen sie die Bezeichnung der Veranstaltung, bei der sie aufgenommen wurden. Ein Löschen und erneutes Hochladen der Fotos konnte das Problem nicht beheben.

Schnell lag der Verdacht nahe, dass in den Bilddateien selbst noch Informationen gespeichert waren, die von WordPress beim Hochladen automatisch übernommen wurden. Im konkreten Fall handelte es sich um Metadaten in der IPTC-Kopfzeile. Bei knapp 100 Bildern wäre es sehr aufwendig gewesen, diese Angaben manuell zu entfernen. Eine Lösung über eine Stapelverarbeitung war daher naheliegend, am besten direkt über das Terminal unter Ubuntu.

Glücklicherweise gibt es eine einfache Möglichkeit, solche eingebetteten Informationen automatisch aus den Dateien zu entfernen.

Zuvor muss allerdings das Paket libimage-exiftool-perl installiert werden.

sudo apt install libimage-exiftool-perl

Danach wird folgender Befehl im Verzeichnis, in dem die zu bearbeitenden Bilder liegen, ausgeführt:

exiftool -all= *.jpg

Dieser sorgt dafür, dass die Dateiendungen der Originalbilder in .jpg_original geändert und die Metadaten aus den eigentlichen Bilddateien entfernt werden.

Beim anschließenden Upload in WordPress wurden die Bildbezeichnungen wie gewünscht angezeigt – also die neuen Dateinamen mit passender Nummerierung.

Der Beitrag Metadaten aus Fotos entfernen erschien zuerst auf intux.de.