Portal zur Registrierung eines Kontos mit Domainauswahl
Jede Domain hat seinen eigenen mailcow-Server
mailcow Stable-Version (Docker)
Als mailcow-Storage wird ein 3-fach redundanter RustFS S3 Storage eingesetzt.
RustFS hat 3x Storage Box von Hetzner mit jeweils (zu Beginn) 1 TB Speicher. Das macht netto 2 TB.
Als Dateisystem wird JuiceFS eingesetzt, dies spricht direkt RustFS an und ermöglicht den Erhalt der mailcow-Verzeichnisstruktur.
Serverseitige Mail-Verschlüsselung durch mailcow-Cryptmodul.
Tägliche snapshot-basierte Sicherung der Storage Boxen.
Tägliche Sicherung der mailcow Mails, Datenbank und Konfiguration.
Features:
Privatsphäre & Sicherheit: Keine Analyse deiner Mails, kein Tracking. Deine Daten gehören dir. Alle E-Mails werden auf der Festplatte verschlüsselt abgelegt.
Kalender & Kontakte: Verwaltung deiner Termine und Adressbücher via CalDAV, CardDAV und Exchange ActiveSync (EAS) auf allen Geräten.
100% Werbefrei: Genieße ein sauberes Postfach mit 1 GB Speicher und ohne lästige Werbebanner. Voller Fokus auf deine Korrespondenz.
Standort Deutschland: Serverstandorte ausschließlich in Deutschland bei Hetzner Online. DSGVO-konform und sicher.
Das Betreiben der Dienste, Webseite und Server machen wir gerne, kostet aber leider auch Geld.
Unterstütze unsere Arbeit mit einer Spende und diskutiere in unserem Chat mit.
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.“
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?
Per Mail und im Forum kamen immer mehr Hinweise auf verzögerte Push-Benachrichtigungen rein. Ich selbst habe es ebenfalls bemerkt und wollte nun einmal handeln.
Um eine IP-Sperre auszuschließen habe ich den MollySocket Dienst erstmal umgezogen auf einen anderen Server, es brachte keine Besserung.
Nach ein paar Anpassungen im NGINX sind die Warnungen im Log nicht verschwunden: WARN mollysocket::ws::websocket_connection] Did not receive the last keepalive: aborting.
Ein bisschen Recherche und KI-Chat brachten mir die Idee die MollySocket eigene Datenbank zu leeren und quasi bei Null anzufangen.
Ein Test wie im Forum beschrieben unter neuer Subdomain mit den gleichen Einstellungen brachte gute Ergebnisse, Push-Benachrichtigungen kamen wieder direkt an.
Was muss ich machen?
Die MollySocket-Datenbank habe ich jetzt resettet.
Es sollte automatisch gehen, aber zur Sicherheit scannt bitte den QR-Code neu ein: https://molly.adminforge.de
Was ist Molly und MollySocket?
Molly ist ein unabhängiger Signal-Fork für Android mit verbesserten Features.
Das Betreiben der Dienste, Webseite und Server machen wir gerne, kostet aber leider auch Geld.
Unterstütze unsere Arbeit mit einer Spende und diskutiere in unserem Chat mit.
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.
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:
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:
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.
Das Betreiben der Dienste, Webseite und Server machen wir gerne, kostet aber leider auch Geld.
Unterstütze unsere Arbeit mit einer Spende und diskutiere in unserem Chat mit.
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!
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:
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-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.
Architektur: Modernes Android mit WorkManager, Coroutines und Material Design.
Push: UnifiedPush Integration.
Privacy: Kein Tracking, keine Werbung, keine Google Play Services Abhängigkeit.
Warum ist die App nicht im Google Play Store?
Uns ist Open Source wichtig und wir möchten dies nicht unterstützen! Mehr unter Keep Android Open.
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.
Feedback
Wünsche und Änderungsvorschläge kannst du im Chat hinterlassen.
Das Betreiben der Dienste, Webseite und Server machen wir gerne, kostet aber leider auch Geld.
Unterstütze unsere Arbeit mit einer Spende und diskutiere in unserem Chat mit.
Die Lösung ist die Eigenschaften der Virtuellen Maschine aufzurufen, hier die Volle Auflösung des Retina Display verwenden zu aktivieren und nach dem Anmelden im Kali Linux Desktop Kali HiDPI Mode zu wählen. Nach einem Restart sollte alles beim alten sein. Nach dem aus sicherheitsupdategründen erzwungenen Upgrade auf macOS 26.3 mit einem anschließenden Update auf VMware ... Weiterlesen
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.
Hier haben wir wieder ein „Henne und Ei“-Problem.Zwar sind die Cookies richtig kopiert worden und auch die Dateien sind zugänglich, sie lassen sich ja via Browser aufrufen, aber leider ist ytdlp veraltet. Bis ein neues Image für Tube Archivist erscheint, muss man sich mit der Variable TA_AUTO_UPDATE_YTDLP helfen. Mit dieser Variable in der Compose-Datei und ... Weiterlesen
Mit KitchenOwl kannst du deine selbst kreierten Rezepte abspeichern, damit du sie nicht mehr vergisst. Teile die Rezepte mit anderen oder erstelle eine Einkaufsliste für dein nächstes Dinner. Außerdem kannst du deine Einkaufskosten hinterlegen, um eine monatliche Bilanz zu erhalten.
Das Betreiben der Dienste, Webseite und Server machen wir gerne, kostet aber leider auch Geld.
Unterstütze unsere Arbeit mit einer Spende und diskutiere in unserem Chat mit.
Das Betreiben der Dienste, Webseite und Server machen wir gerne, kostet aber leider auch Geld.
Unterstütze unsere Arbeit mit einer Spende und diskutiere in unserem Chat mit.
Das Betreiben der Dienste, Webseite und Server machen wir gerne, kostet aber leider auch Geld.
Unterstütze unsere Arbeit mit einer Spende und diskutiere in unserem Chat mit.
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.
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.
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.
Die im Oktober 2025 erschienene Neuauflage des Raspberry Pi OS, basierend auf Debian 13 „Trixie“, dürfte einige Nutzer überrascht haben. In den Medien wurde darüber nur wenig berichtet – auch an mir war die Veröffentlichung zunächst vorbeigegangen.
Trotzdem habe ich nicht gezögert, das neue System mithilfe des Raspberry Pi Imager auf eine microSD-Karte zu schreiben. Ziel war es wie gewohnt, eine sogenannte headless-Installation vorzubereiten – also ohne Monitor und Tastatur. Die weitere Einrichtung sollte anschließend bequem per SSH (Secure Shell) erfolgen.
Der Vorgang wurde auf einem Notebook mit Ubuntu 24.04 LTS und dem über die Paketverwaltung installierten Raspberry Pi Imager (Version 1.8.5) durchgeführt. Nach dem Flashen wurden die Karte in den Raspberry Pi eingesetzt und das System gestartet. Doch eine Verbindung per SSH war danach nicht möglich.
Ursache und Lösung
Die Ursache für dieses Verhalten war schnell gefunden: Raspberry Pi OS 13 erfordert für die korrekte Vorkonfiguration den Raspberry Pi Imager in Version 2.0 oder höher. Und genau hier beginnt das Problem – zumindest für Linux-Nutzer.
Während Windows-Nutzer den neuen Imager bereits komfortabel nutzen können, hinkt die Linux-Unterstützung deutlich hinterher. Bislang steht weder ein aktuelles .deb-Paket noch eine Snap-Version zur Verfügung. Das sorgt in der Linux-Community verständlicherweise für Kopfschütteln – gerade bei einem Projekt wie dem Raspberry Pi, das tief in der Open-Source-Welt verwurzelt ist.
AppImage als Ausweg
Glücklicherweise bietet der Entwickler ein AppImage des neuen Imagers an. Dieses lässt sich unter Ubuntu und anderen Distributionen unkompliziert starten – ganz ohne Installation. Damit ist es wie gewohnt möglich, WLAN-Zugangsdaten und SSH vor dem ersten Start zu konfigurieren.
Fazit
Wer Raspberry Pi OS 13 „Trixie“ headless nutzen möchte, sollte sicherstellen, dass der Imager in Version 2.0 oder neuer verwendet wird. Für Linux-Nutzer führt der Weg aktuell nur über das bereitgestellte AppImage. Es bleibt zu hoffen, dass die offizielle Paketunterstützung für Linux bald nachgereicht wird.
Das Betreiben der Dienste, Webseite und Server machen wir gerne, kostet aber leider auch Geld.
Unterstütze unsere Arbeit mit einer Spende und diskutiere in unserem Chat mit.
„Hacking & Security: Das umfassende Handbuch“ von Michael Kofler, Roland Aigner, Klaus Gebeshuber, Thomas Hackner, Stefan Kania, Frank Neugebauer, Peter Kloep, Tobias Scheible, Aaron Siller, Matthias Wübbeling, Paul Zenker und André Zingsheim ist 2025 in der 4., aktualisierten und erweiterten Auflage im Rheinwerk Verlag erschienen und umfasst 1271 Seiten.
Ein Buchtitel, der bereits im Namen zwei gegensätzliche Extreme vereint: Hacking und Security. Dieser Lesestoff richtet sich nicht an ein breites Publikum, wohl aber an all jene, die Wert auf digitale Sicherheit legen – sei es im Internet, auf Servern, PCs, Notebooks oder mobilen Endgeräten. Gleichzeitig kann dieses umfassende Nachschlagewerk auch als Einstieg in eine Karriere im Bereich Ethical Hacking dienen.
Das Buch ist in drei inhaltlich spannende und klar strukturierte Teile gegliedert.
TEIL I – Einführung und Tools erläutert, warum es unerlässlich ist, sich sowohl mit Hacking als auch mit Security auseinanderzusetzen. Nur wer versteht, wie Angreifer vorgehen, kann seine Systeme gezielt absichern und Sicherheitsmaßnahmen umsetzen, die potenzielle Angriffe wirksam abwehren.
Behandelt werden unter anderem praxisnahe Übungsmöglichkeiten sowie Penetrationstests auf speziell dafür eingerichteten Testsystemen. Ziel ist es, typische Angriffsabläufe nachzuvollziehen und daraus wirksame Schutzkonzepte abzuleiten. Einen zentralen Stellenwert nimmt dabei das speziell für Sicherheitsanalysen entwickelte Betriebssystem Kali Linux ein, das in diesem Zusammenhang ausführlich vorgestellt wird.
Kali Linux – Simulation eines erfolgreichen Angriffs auf SSH
TEIL II – Hacking und Absicherung widmet sich intensiv den beiden zentralen Themenbereichen Hacking und Security. Es werden unterschiedliche Angriffsszenarien analysiert und typische Schwachstellen aufgezeigt. Besonders hervorgehoben wird dabei die Bedeutung der Festplattenverschlüsselung, um den unbefugten Zugriff auf sensible Daten zu verhindern.
Auch der Einsatz starker Passwörter in Kombination mit Zwei-Faktor-Authentifizierung (2FA) gehört heute zum Sicherheitsstandard. Dennoch lauern Gefahren im Alltag: Wird ein Rechner unbeaufsichtigt gelassen oder eine Sitzung nicht ordnungsgemäß beendet, kann etwa ein präparierter USB-Stick mit Schadsoftware gravierende Schäden verursachen.
Server-Betreiber stehen zudem unter permanentem Druck durch neue Bedrohungen aus dem Internet. Das Buch bietet praxisnahe Anleitungen zur Härtung von Windows- und Linux-Servern – beispielsweise durch den Einsatz von Tools wie Fail2Ban, das automatisiert Brute-Force-Angriffe erkennt und unterbindet.
Ein weiteres Kernthema ist die Verschlüsselung von Webverbindungen. Moderne Browser weisen inzwischen deutlich auf unsichere HTTP-Verbindungen hin. Die Übertragung sensibler Daten ohne HTTPS birgt erhebliche Risiken – etwa durch Man-in-the-Middle-Angriffe, bei denen Informationen abgefangen oder manipuliert werden können.
Abgerundet wird das Kapitel durch eine ausführliche Betrachtung von Angriffsmöglichkeiten auf weit verbreitete Content-Management-Systeme (CMS) wie WordPress, inklusive praxisnaher Hinweise zur Absicherung.
TEIL III – Cloud, Smartphones, IoT widmet sich der Sicherheit von Cloud-Systemen, mobilen Endgeräten und dem Internet of Things (IoT). Unter dem Leitsatz „Die Cloud ist der Computer eines anderen“ wird aufgezeigt, wie stark Nutzerinnen und Nutzer bei der Verwendung externer Dienste tatsächlich abhängig sind. Besonders bei Cloud-Angeboten amerikanischer Anbieter werden bestehende geopolitische Risiken oft unterschätzt – obwohl sie spätestens seit den Enthüllungen von Edward Snowden nicht mehr zu ignorieren sind.
Selbst wenn Rechenzentren innerhalb Europas genutzt werden, ist das kein Garant für Datenschutz. Der Zugriff durch Dritte – etwa durch Geheimdienste – bleibt unter bestimmten Umständen möglich. Als datenschutzfreundliche Alternative wird in diesem Kapitel Nextcloud vorgestellt: ein in Deutschland entwickeltes Cloud-System, das sich auf eigenen Servern betreiben lässt. Hinweise zur Installation und Konfiguration unterstützen den Einstieg in die selbstbestimmte Datenverwaltung.
Wer sich für mehr digitale Souveränität entscheidet, übernimmt zugleich Verantwortung – ein Aspekt, dem im Buch besondere Aufmerksamkeit gewidmet wird. Ergänzend werden praxisnahe Empfehlungen zur Absicherung durch Zwei- oder Multi-Faktor-Authentifizierung (2FA/MFA) gegeben.
Ein weiteres Thema sind Sicherheitsrisiken bei mobilen Geräten und IoT-Anwendungen. Besonders kritisch: schlecht gewartete IoT-Server, die oft im Ausland betrieben werden und ein hohes Angriffspotenzial aufweisen. Auch hier werden konkrete Gefahren und Schutzmaßnahmen anschaulich dargestellt.
Das Buch bietet einen fundierten und praxisnahen Einstieg in die Welt von IT-Sicherheit und Hacking. Es richtet sich gleichermaßen an interessierte Einsteiger als auch an fortgeschrittene Anwender, die ihre Kenntnisse vertiefen möchten. Besonders gelungen ist die Verbindung technischer Grundlagen mit konkreten Anwendungsszenarien – vom Einsatz sicherer Tools über das Absichern von Servern bis hin zur datenschutzfreundlichen Cloud-Lösung.
Wer sich ernsthaft mit Sicherheitsaspekten in der digitalen Welt auseinandersetzen möchte, findet in diesem Werk einen gut strukturierten Leitfaden, der nicht nur Wissen vermittelt, sondern auch zum eigenständigen Handeln motiviert. Ein empfehlenswertes Nachschlagewerk für alle, die digitale Souveränität nicht dem Zufall überlassen wollen.
Seit einiger Zeit treten unter Ubuntu 24.04 LTS Probleme beim Ausführen von VirtualBox auf. Diese lassen sich zwar temporär durch das Entladen eines KVM-Moduls beheben, tauchen jedoch nach einem Neustart wieder auf.
KVM steht für Kernel-based Virtual Machine und ist eine Virtualisierungstechnologie für Linux auf x86-Hardware.
Temporäre Lösung
Abhängig vom verwendeten Prozessor kann das jeweilige KVM-Modul aus dem laufenden Kernel mit folgendem Befehl entfernt werden:
sudo modprobe -r kvm_intel
bei AMD-Systemen:
sudo modprobe -r kvm_amd
Diese Methode ist jedoch nicht dauerhaft, da das Modul nach einem Neustart wieder geladen wird.
Bei der Recherche zu diesem Thema bin ich auf zwei Lösungsansätze gestoßen, die das Problem dauerhaft beheben sollten. Zum einen geht es um das Hinzufügen einer Boot-Option in GRUB, zum anderen um die Erstellung einer Blacklist der entsprechenden KVM-Module für VirtualBox.
1. Ansatz – Eingriff in den Bootloader (GRUB)
In der Datei /etc/default/grub wird der Eintrag
GRUB_CMDLINE_LINUX=
um folgenden Parameter (siehe Screenshot) ergänzt:
"kvm.enable_virt_at_load=0"
Anschließend muss die GRUB-Konfiguration aktualisiert werden:
sudo update-grub
Wichtiger Hinweis: Ein fehlerhafter Eintrag in der GRUB-Konfiguration kann dazu führen, dass das System nicht mehr startet. Unerfahrene Nutzer könnten in eine schwierige Situation geraten. Daher ist ein vollständiges System-Backup vor dem Eingriff unbedingt empfehlenswert.
GRUB-Konfiguration
2. Ansatz – Blacklisting des KVM-Moduls
Ein sichererer und eleganterer Weg ist das Blacklisting des Moduls. Dazu wird eine neue Konfigurationsdatei angelegt:
sudo nano /etc/modprobe.d/blacklist-kvm.conf
Dort fügt man folgende Zeilen hinzu:
blacklist kvm
blacklist kvm_intel
Nach einem Neustart des Systems wird das jeweilige KVM-Modul nicht mehr geladen und VirtualBox sollte wie gewohnt funktionieren.
Fazit
Die zweite Methode ist risikoärmer und benutzerfreundlicher. Dennoch empfiehlt es sich, vor jeder Änderung am System ein Backup anzulegen.
Solche Aufgaben können notwendig werden, wenn die Dateien aus unterschiedlichen Quellen stammen – so wie im folgenden Beispiel: Ich hatte vier verschiedene Zuarbeiten mit jeweils eigenen Benennungsregeln erhalten. Um die insgesamt 95 Dateien einheitlich in eine bestehende Webseite einzubinden, mussten sie alle nach einem gemeinsamen Schema umbenannt werden.
Umsetzung
Auf einem Ubuntu-System erfolgt die Mehrfachumbenennung ganz einfach: Zunächst wird das Verzeichnis geöffnet, in dem sich alle zu verarbeitenden Bilder befinden.
Dateien – Ansicht Bilder (ungeordnet)
Im Dateimanager „Dateien“ (früher „Nautilus“) werden mit Strg + A alle Dateien markiert.
Dateien – Ansicht Bilder (alle ausgewählt)
Mit einem Rechtsklick lässt sich nun die Option „Umbenennen“ auswählen. Hier wird „[Ursprünglicher Dateiname]“ durch den endgültigen Dateinamen ersetzt und über „+ Hinzufügen“ der neue Suffix ausgewählt.
Die Mehrfachumbenennung unter GNOME ist ein einfaches, aber äußerst praktisches Werkzeug – besonders in Kombination mit einer automatischen Skalierung, wie im zuvor genannten Artikel beschrieben. So lässt sich die Verarbeitung großer Bildmengen deutlich effizienter gestalten und viel Zeit sparen.
Auf Anfrage einer Bildungseinrichtung, die ein Anzeigesystem für aktuell laufende Kurse auf ihrer Webseite realisieren möchte, habe ich nach einer Möglichkeit gesucht, ein stabiles, kostengünstiges und quelloffenes System umzusetzen.
Hardware-Auswahl
Bei der Hardware fiel die Entscheidung nicht schwer: Ein Raspberry Pi ist für diesen Einsatzzweck bestens geeignet. Als Gehäuse empfiehlt sich ein passiv gekühltes Modell aus Aluminium, um einen lautlosen und langlebigen Betrieb zu gewährleisten.
Installation
Bereits vor einigen Jahren habe ich ein ähnliches System für eine Fahrschule realisiert, das seit nunmehr fast fünf Jahren zuverlässig als „Schaufensterwerbung“ im Dauerbetrieb läuft.
Mit xdotool kann der Chromium-Browser automatisiert gesteuert werden. unclutter blendet den Mauszeiger nach kurzer Inaktivität aus.
Kiosk-Skript erstellen
Nun wird das Skript kiosk.sh erstellt. Wichtig: Den Benutzernamen intux ggf. durch den tatsächlich verwendeten Benutzer ersetzen. Für einen ersten Testlauf greife ich meine eigene Website intux.de ab.
sudo nano /home/intux/kiosk.sh
Inhalt von kiosk.sh:
#!/bin/bash
xset s noblank
xset s off
xset -dpms
unclutter -idle 0.5 -root &
sed -i 's/"exited_cleanly":false/"exited_cleanly":true/' /home/intux/.config/chromium/Default/Preferences
sed -i 's/"exit_type":"Crashed"/"exit_type":"Normal"/' /home/intux/.config/chromium/Default/Preferences
/usr/bin/chromium-browser --noerrdialogs --disable-infobars --kiosk https://intux.de
while true; do
xdotool keydown ctrl+Tab; xdotool keyup ctrl+Tab;
sleep 10
done
Systemd-Dienst einrichten
Um sicherzustellen, dass Chromium nach jedem Neustart automatisch im Kiosk-Modus gestartet wird, wird ein systemd-Dienst eingerichtet:
Ich habe mich für eine Bildschirmauflösung von 1280 × 720 Pixel (16:9) entschieden. Diese lässt sich bequem über die grafische Oberfläche des Raspberry Pi OS einstellen.
Raspberry Pi – AuflösungRaspberry Pi – Auflösung 1920 x 1080Raspberry Pi – Auflösung 1280 x 720
Erster Testlauf
Raspberry Pi – Kiosk-Webseitendarstellung
System duplizieren
Da das System nun wie gewünscht funktioniert, habe ich es auf weitere Geräte dupliziert – eines für jede Etage des Gebäudes. Um die einzelnen Systeme im Netzwerk unterscheiden zu können, erhielten sie unterschiedliche Hostnamen:
Uranus
Venus
Mars
Pluto
Der Hostname lässt sich über raspi-config anpassen:
sudo raspi-config
Nach dem Klonen stellte ich jedoch fest, dass der Kiosk-Dienst auf den neuen Systemen nicht wie erwartet startete. Die Ursache war die Datei SingletonLock von Chromium. Diese muss gelöscht werden:
rm -rf /home/intux/.config/chromium/SingletonLock
Fazit
Mit überschaubarem Aufwand und etwas Recherche ließ sich ein praktikables Open-Source-Projekt umsetzen, das nun im Realbetrieb zeigen kann, wie zuverlässig es funktioniert.
Wer regelmäßig Webprojekte betreut, kennt das Problem: Große Bilddateien können die Ladezeiten einer Website deutlich beeinträchtigen und wirken sich negativ auf die Suchmaschinenoptimierung (SEO) aus. Besonders dann, wenn eine größere Anzahl von Fotos verarbeitet werden muss, ist eine manuelle Bearbeitung mit grafischen Programmen nicht nur zeitraubend, sondern auch ineffizient.
In einem aktuellen Fall erhielt ich rund 120 Fotos eines Fotografen, die für eine Galerie auf einer Webseite vorgesehen waren. Die Bilddateien lagen jedoch in einer Größe vor, die weder performant für das Web war noch den SEO-Richtlinien entsprach.
Da ich für meine Projekte eine maximale Bildbreite von 1024 Pixeln definiert habe, griff ich – wie bereits im Artikel „Bilder per Batch skalieren“ beschrieben – auf ein bewährtes Werkzeug aus dem Open-Source-Bereich zurück: ImageMagick.
Mit einem einfachen Befehl ließ sich die gesamte Bildersammlung direkt über das Terminal verarbeiten:
mogrify -resize 1024x1024 *.jpg
Dieser Befehl skaliert alle .jpg-Dateien im aktuellen Verzeichnis auf eine maximale Kantenlänge von 1024 Pixeln – unter Beibehaltung des Seitenverhältnisses. Innerhalb weniger Sekunden war der gesamte Stapel an Bildern webgerecht optimiert.
Solche kleinen, aber wirkungsvollen Tools aus der Open-Source-Welt sind nicht nur ressourcenschonend, sondern tragen auch dazu bei, Arbeitsabläufe deutlich zu beschleunigen – ganz ohne aufwendige GUI-Programme oder proprietäre Softwarelösungen.
Vor ziemlich genau drei Wochen wurde Debian 13 mit dem Codenamen "trixie" veröffentlicht. Da Debian einen wichtigen Architekturzweig unter Linux bildet, von dem viele Derivate wie z. B. Ubuntu abzweigen, werfen wir heute einen kleinen Blick auf die Veränderungen.
Zahlen, Daten, Fakten
Schaut man in die Veröffentlichungsmeldung, bekommt man einen Überblick, was sich in diesem Release getan hat:
Das Release umfasst nach gut zwei Jahren Entwicklung 69.830 Pakete, wobei 14.100 Zugänge, 8.840 Abgänge und 44.326 Aktualisierungen zu verzeichnen sind. Als Kernel kommt Linux 6.12 LTS zum Einsatz. Gebaut wird mit GCC 14.2 und LLVM 19. Systemd wird in Version 257 genutzt. Bei den Desktopumgebungen sind wir bei GNOME 48, KDE Plasma 6.3, LXDE 13, LXQt 2.1.0 und Xfce 4.20 angekommen. Python wird in Version 3.13, Rust in Version 1.85, OpenSSL in Version 3.5 und PHP in Version 8.4 ausgeliefert. Das gesamte Paketarchiv umfasst 403 GB, wovon auf den meisten Systemen nur ein Bruchteil installiert sein sollte.
Zu den Architekturen:
Die offizielle 32-Bit-Unterstützung (i386) entfällt ab diesem Release. Verbleibende i386-Pakete für Anwendungen sind nur zur Nutzung auf einem 64-Bit-System mit entsprechendem 64-Bit-Kernel vorgesehen, Stichwort multiarch.
Für ARM-Nutzer alter Architekturen vor Arm v7, die auf die armel (ARM EABI) zurückgegriffen haben, ist Debian 13 das letztmögliche Release. Installationsabbilder werden schon jetzt nicht mehr bereitgestellt.
Die Unterstützung für mipsel und mips64el entfällt mit diesem Release komplett.
Besonderheiten
Aus Entwicklersicht wurden erste Vorkehrungen für Lösungen gegen das Jahr-2038-Problem unternommen. Im Jahr 2038 wird der für Linux-Systeme integrale Unix-Timestamp (Sekunden ab 01.01.1970) nicht mehr allein durch 32-Bit darstellbar sein. time_t wurde auf 64-Bit umgestellt und in mühevoller Arbeit auf die verschiedenen Pakete ausgerollt. Gleichzeitig werden auch Anwendungen wie lastlog aus Debian 13 entfernt, da der 32-Bit-Timestamp so tief verankert ist, dass eine Umstellung neue Programme erfordert. Ersatz in Form von lslogins, lastlog2 oder wtmpdb steht bereit, falls benötigt.
Aus administrativer Sicht ist das /tmp-Verzeichnis in diesem Release spannend, da es nicht mehr auf dem Dateisystem liegt, sondern über tmpfs gemounted wird. Die Daten liegen somit im RAM. Dadurch teilen sich die Daten im temporären Verzeichnis einerseits mit den Anwendungen und dem Cache nun den Arbeitsspeicher, andererseits sind nach Neustart die Daten auch gelöscht. Bei einem Upgrade auf Version 13 sei zu bedenken, dass das neue tmpfs das alte /tmp-Verzeichnis im Dateisystem, sofern vorhanden, überdeckt. Wer nach dem Upgrade auf alte Daten noch zurückgreifen möchte, muss das Dateisystem per bind-mount in z. B. das Verzeichnis /mnt einhängen (mount --bind / /mnt) und kann anschließend die alten Daten aus dem Verzeichnis retten.
OpenSSH ist nun in Version 10 verfügbar und fährt weiter den Support alter Cipher zurück. Diesmal sind die veralteten DSA-Schlüssel an der Reihe. Wer sich noch auf alte Geräte wie Router oder Switches verbinden muss, benötigt nun das Zusatzpaket openssh-client-ssh1, da sich DSA auch über Konfigurationsoptionen nicht mehr aktivieren lässt.
Aus Security-Sicht ist eine Neuerung bei ping ganz interessant. Da dieses Programm ICMP-Pakete senden muss, die bisher nicht über reguläre Sockets abbildbar waren, lief es bisher nur unter erhöhten Rechten, da ein Zugriff auf Raw Sockets erforderlich war. Das wird bislang mit File Capabilities umgesetzt, ganz früher kam sogar noch setuid zum Einsatz. Da potentielle Sicherheitslücken in der Ping-Binary damit unnötig viel Angriffsfläche auf einem System eröffnen würden und der Ping nicht das volle Potential von Raw Sockets benötigt, können Anwendungen nun die Datagramme über ICMP_PROTO-Sockets versenden. Ping nutzt unter Debian 13 nun diese Variante. Durch die Umstellung entfällt das Erfordernis der erweiterten Rechte. Die ICMP_PROTO-Sockets können wiederum durch z. B. net.ipv4.ping_group_range eingeschränkt werden.
Auch für Security interessant: das neue Paket debian-security-support ermöglicht es, den Supportstatus der installierten Pakete zu überprüfen.
Hinweise für das Upgrade
Wer Debian 13 per SSH aktualisiert, sollte aufpassen: OpenSSH sollte erst mindestens auf Version 1:9.2p1-2+deb12u7 (Debian 12) aktualisiert werden, da sonst Unterbrechungen während des Upgrades auftreten können.
Auch Administratoren, die viel virtualisieren, sollten auf libvirt achten: Das bisher monolithische Paket wurde umfangreich aufgespalten und es sollte vorab untersucht werden, welche weiteren Pakete nun benötigt werden, damit nach dem Update keine Funktionalität verloren geht.
Unterstützung und EoL
Stand August 2025 gibt es nun drei unterstützte Debian-Versionen:
Debian 13 (stable, trixie) bis August 2028, verlängert per LTS bis Juni 2030
Debian 12 (oldstable, bookworm) bis Juni 2026, verlängert per LTS bis Juni 2028
Debian 11 (oldoldstable, bullseye) nur noch als LTS bis August 2026
Administratoren sollten nun beginnen, ihre Migration von Debian 11 anzugehen. LTS-Versionen werden nicht mehr vom regulären Security- und Release-Team, sondern durch das LTS-Team gepflegt, um einen fünfjährigen Support sicherzustellen. Der Übergang ist fließend, aber durch den immensen Aufwand können nicht alle Pakete mit der gleichen Aufmerksamkeit betreut werden.
Im Artikel „Nextcloud-Kalender in Thunderbird einbinden“ habe ich erklärt, wie man seine Nextcloud-Termine im Mail-Client über die CalDAV-Schnittstelle integrieren kann. Das Gleiche funktioniert auch problemlos via CardDAV mit den Kontakten. Wie das geht, beschreibe ich in diesem Artikel.
Vorbereitung in der Nextcloud
Zuerst meldet man sich über die Weboberfläche der Nexcloud an. Dort navigiert man zu den Kontakten und weiter unten links zu den Kontakte-Einstellungen.
Nextcloud – Kontakte-Einstellungen
Von hier wählt man das entsprechende Adressbuch und kopiert den Link.
Im sich öffnenden Fenster Neues CardDAV-Adressbuch gibt man nun den Benutzernamen des Nextcloud-Accounts und den zuvor kopierten Link der CardDAV-Adresse ein.
Thunderbird – Neues CardDAV-Adressbuch
Diesen Vorgang bestätigt man nun mit dem Passwort des Nextcloud-Accounts und OK
Thunderbird – Authentifizierung
und schließt die Einrichtung nach der Auswahl der Verfügbaren Adressbücher mit Weiter ab.
Anmelden
Das Betreiben der Dienste, Webseite und Server machen wir gerne, kostet aber leider auch Geld.
Wichtiger Hinweis:
