Normale Ansicht

PHP 8.4 FPM für Nextcloud 33

02. April 2026 um 04:00

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.

Diagramm der momentan unterstützten PHP-Versionen
Quelle: https://www.php.net/supported-versions.php

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.

Raspberry Pi OS Bookworm -> Trixie

28. März 2026 um 05:23

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.

Gesundheit der Festplatte überprüfen

09. Februar 2026 um 05:00

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.

Überprüfung auf fehlerhafte Sektoren

15. Januar 2026 um 08:45

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.

Trixie ohne SSH

04. Januar 2026 um 15:11

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.

Der Beitrag Trixie ohne SSH erschien zuerst auf intux.de.

Hacking & Security: Das umfassende Handbuch

15. Dezember 2025 um 05:00

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

Man-in-the-Middle-Angriff

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 umfasst insgesamt 24 Kapitel.

  • Einführung
  • Kali Linux
  • Hacking-Tools
  • Hacking lernen
  • Bug-Bounty-Programme
  • Offline Hacking
  • Passwörter
  • IT-Forensik
  • WLAN, Bluetooth und SDR
  • Angriffsvektor USB-Schnittstelle
  • Externe Sicherheitsüberprüfungen
  • Penetration-Testing
  • Windows Server absichern
  • Active Directory
  • Linux absichern
  • Sicherheit bei Samba-Fileservern
  • Sicherheit von Webanwendungen
  • Intrusion-Detection-Systeme
  • Software-Exploitation
  • Sichere KI-Anwendungen
  • Sicherheit in der Cloud
  • Microsoft 365 sicher betreiben
  • Mobile Security
  • IoT-Sicherheit

Leseprobe

Fazit

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.

Der Beitrag Hacking & Security: Das umfassende Handbuch erschien zuerst auf intux.de.

Kiosk-Anzeigesystem auf dem Raspberry Pi

25. September 2025 um 04:00

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.

Als Grundlage für das aktuelle Projekt diente mir die Anleitung „Fullscreen-Browser nach Boot auf Raspberry Pi – Kiosk-Mode“ von Easy Tec. Ich setze voraus, dass auf dem Raspberry Pi bereits Raspberry Pi OS installiert ist und ein SSH-Zugang besteht.

Benötigte Pakete installieren

sudo apt install xdotool unclutter

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:

sudo nano /lib/systemd/system/kiosk.service

Inhalt von kiosk.service:

[Unit]
Description=Chromium Kiosk
Wants=graphical.target
After=graphical.target

[Service]
Environment=DISPLAY=:0.0
Environment=XAUTHORITY=/home/intux/.Xauthority
Type=simple
ExecStart=/bin/bash /home/intux/kiosk.sh
Restart=on-abort
User=intux
Group=intux

[Install]
WantedBy=graphical.target

Anschließend wird der Dienst aktiviert und gestartet:

sudo systemctl enable kiosk.service
sudo systemctl start kiosk.service

Ein Neustart schließt die Einrichtung ab:

sudo reboot

Auflösung anpassen

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ösung
Raspberry Pi – Auflösung
Raspberry Pi – Auflösung 1920 x 1080
Raspberry Pi – Auflösung 1920 x 1080
Raspberry Pi – Auflösung 1280 x 720
Raspberry Pi – Auflösung 1280 x 720

Erster Testlauf

Raspberry Pi – Kiosk-Webseitendarstellung
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.

Der Beitrag Kiosk-Anzeigesystem auf dem Raspberry Pi erschien zuerst auf intux.de.

Bilder unter Linux effizient per Kommandozeile skalieren

22. September 2025 um 04:00

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.

Der Beitrag Bilder unter Linux effizient per Kommandozeile skalieren erschien zuerst auf intux.de.

Debian 13 veröffentlicht

31. August 2025 um 10:10

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.

Die vollständigen Hinweise zum neuen Release sind in den Debian 13 Release Notes zu finden.

Debian 13 »Trixie«

12. August 2025 um 08:42

Debian 13 »Trixie« ist fertig. Mehrere RC-Releases sind bei mir schon ein paar Monate im Einsatz — bislang ohne jedes Problem. Insofern sieht es so aus, als würde Debian seinem Ruf für stabile, ausgereifte Releases einmal mehr gerecht. Dieser Artikel fasst in kompakter Form die wichtigsten Neuerungen zusammen.

Debian mit Gnome-Desktop

Plattformen und Versionsnummern

Debian steht für sieben CPU-Plattformen zur Verfügung:

  • Standard-PCs (x86): nur noch amd64 (i386 nur einzelne Pakete, nicht mehr als vollständige Plattform)
  • ARM: arm64, armhf, armel
  • PowerPC: ppc64el
  • RISC-V: risvc64 (neu!)
  • IBM System z: s390x

MIPS wird nicht mehr unterstützt, armel mit diesem Release zum letzten Mal.

Die folgende Tabelle fasst die Versionen der Kernkomponenten von Debian 13 zusammen:

Basis               Programmierung     Server
---------------     --------------     ---------------
Kernel     6.12     bash       5.2     Apache      2.4
glibc      2.41     gcc       14.2     CUPS        2.4
Wayland    1.23     git       2.47     MariaDB    11.8
Gnome        48     Java     21/25     OpenSSH    10.0
Mesa       25.0     PHP        8.4     PostgreSQL   17
Systemd     257     Podman     5.4     Postfix    3.10
NetworkMan 1.52     Python    3.13     qemu/KVM   10.0
GRUB       2.12     Node.js     20     Samba      4.22

Wenn Sie sich bei der Installation für KDE entscheiden, kommen QT 6.8, das KDE-Framework 6.13, Plasma 6.3.6, sowie KDE Gear 25.04 bzw. 24.12 (für die PIM Suite) zur Anwendung.

Bei Dovecot warnen die Release Notes von Debian, dass sich die Syntax von Version 2.3 zu 2.4 inkompatibel geändert hat, was zu Problemen führen wird, wenn eine vorhandene Konfiguration bei einem Update übernommen werden soll. Hier ist der Link in die Dovecot-Dokumentation zu diesem Thema.

Installation

Am Installationsablauf hat sich — zumindest optisch — nichts verändert. Die teilweise seit Jahrzehnten (!) bewährten Dialoge führen durch die Installation. Das ist nicht so elegant und intuitiv wie bei anderen Systemen, dafür können bei der Partitionierung wirklich alle erdenklichen Sonderwünsche realisiert werden. Im Wildwuchs anderer Systeme betrachte ich das Installationssystem zunehmend als Pluspunkt.

Technische Neuerungen

last-Kommando neu implementiert: Unter Linux können Sie mit last die Liste der zuletzt eingeloggten Personen ermitteln. last reboot verrät, wann der Rechner zuletzt neugestartet wurde.

Das alles funktioniert in Debian auch, aber die Implementierung ist neu. last ist jetzt ein symbolischer Link auf wtmpdb. Diese Neuimplementierung der last-Datenbank verwendet SQLite und wird über das Jahr 2038 hinaus funktionieren (was beim herkömmlichen last-Kommando nicht der Fall ist).

Analog wurde lastlog durch lastlog2 ersetzt. Mehr Details geben die Release Notes.

APT-Repository-Format deb822: Debian unterstützt die neuen *.sources-Dateien zur Beschreibung von Paketquellen. Anstelle von einzeiligen Paketbeschreibungen wie

deb     http://deb.debian.org/debian/ trixie main
deb-src http://deb.debian.org/debian/ trixie main

können die Paketquellen in einem besser lesbaren, mehrzeiligen Format dargestellt werden:

# Datei /etc/apt/sources.list.d/debian.sources
Types:      deb deb-src
URIs:       http://deb.debian.org/debian/
Suites:     trixie
Components: main
Signed-By:  /usr/share/keyrings/debian-archive-keyring.gpg

Anders als ab Ubuntu 24.04 ist das neue Format in Debian 13 nicht per Default aktiv. Alle vorhandenen Paketquellen können aber mit apt modernize-sources umgestellt werden, was bei meinen Tests gut funktioniert hat. Die neuen Repo-Dateien haben die Kennung *.sources anstelle *.list. Wenn gleichnamige Dateien existieren, haben die *.sources-Dateien Vorrang. In die Dateien können auch Signatur-Keys eingebettet werden, was den lästigen Key-Import erspart. Mehr Details liefert man sources.list.

/tmp im RAM: Das /tmp-Verzeichnis wird nun mit dem tmpfs-Dateisystem im RAM abgebildet. Das verspricht höhere Geschwindigkeit beim Umgang mit temporären Dateien, kann aber bei sehr großen Dateien zum Speicherproblemen führen. /tmp darf bis zu 50% des RAMs nutzen. Das Dateisytem wird durch systemd eingerichtet. Der Grenzwert kann mit systemctl edit tmp.mount verändert werden. Dazu bauen Sie im dafür vorgesehen Bereich die folgenden zwei Zeilen ein und verändern die Werte:

[Mount]
Options=mode=1777,strictatime,nosuid,nodev,size=50%%,nr_inodes=1m

Wenn Sie /tmp wie bisher als reguläres Verzeichnis auf der SSD/Festplatte wünschen, führen Sie systemctl mask tmp.mount aus und starten Ihr System neu.

Sicherheit: Debian-Pakete sind gegen ROP- und COP/JOP-Angriffe gehärtet (betrifft die amd64– und arm64-Architektur). Die Pakete sind speziell kompiliert, um Exploits durch Return-Oriented Programming (ROP) bzw. Call/Jump-Oriented Programming (COP/JOP) zu erschweren. Weitere Details und Links finden Sie in den Release Notes.

Geschwindigkeit: Laut einem Test von Phoronix ist Debian 13 rund 13 Prozent schneller als die Vorgängerversion.

Tipps und Tricks

Wenn Sie Debian in einer virtuellen Maschine verwenden und Text und Bilder über die Zwischenablage mit dem Host austauschen wollen, führen Sie apt install spice-vdagent aus und starten die VM neu.

Fazit

Das Debian-Projekt ist 32 Jahre alt (Projektgründung im August 1993, 0.9-Releases 1994 und 1995, Version 1.1 1996). Debian zählt damit zu den ältesten Linux-Distributionen überhaupt — und ist bis heute mehr als nur relevant: Überlegen Sie nur für eine Minute, wie die Linux-Landschaft ohne Debian aussähe! Nicht nur Millionen Debian-Anwender stünden im Regen, auch Ubuntu, Linux Mint, Raspberry Pi OS etc. würde die Basis entzogen.

Für Version 13 gilt: Debian bleibt Debian. Große technische Innovationen finden anderswo statt. Stattdessen gibt es Unterstützung für viele CPU-Plattformen und ein solides, stabiles Fundament für die tägliche Arbeit, sei es am Desktop oder in Server-Anwendungen. Und das alles frei von finanziellen Interessen. Dafür sollte jeder Linux-Fan der Debian-Community unendlich dankbar sein.

Quellen/Links

Andere Tests/Kurzberichte

Nextcloud-Kontakte in Thunderbird einbinden

18. Juli 2025 um 04:00

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
Nextcloud – Kontakte-Einstellungen

Von hier wählt man das entsprechende Adressbuch und kopiert den Link.

Nextcloud – Adressbücher
Nextcloud – Adressbücher
Nextcloud – CardDAV-Adresse kopieren
Nextcloud – CardDAV-Adresse kopieren

Vorbereitung in Thunderbird

In Thunderbird wählt man Neues Adressbuch anlegen und im Anschluss CardDAV-Adressbuch hinzufügen.

Thunderbird – Neues Adressbuch anlegen
Thunderbird – Neues Adressbuch anlegen
Thunderbird – CardDAV-Adressbuch hinzufügen
Thunderbird – CardDAV-Adressbuch hinzufügen

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
Thunderbird – Neues CardDAV-Adressbuch

Diesen Vorgang bestätigt man nun mit dem Passwort des Nextcloud-Accounts und OK

Thunderbird – Authentifizierung
Thunderbird – Authentifizierung

und schließt die Einrichtung nach der Auswahl der Verfügbaren Adressbücher mit Weiter ab.

Thunderbird – Neues CardDAV-Adressbuch
Thunderbird – Neues CardDAV-Adressbuch
Thunderbird – Kontakte
Thunderbird – Kontakte

Die Kontakte werden nun wie gewünscht in Thunderbird angezeigt (siehe Screenshot).

Der Beitrag Nextcloud-Kontakte in Thunderbird einbinden erschien zuerst auf intux.de.

Thinkpad T450s ACPI Error unter Debian GNU/Linux

10. Juli 2025 um 13:08

Was bei mir so vor der Eingabe des LUKs Passwortes und dem Starten von Debian vorbeihuschte, hatte mich dann doch einmal interessiert: Kurz und knapp, es ist ein Fehler im BIOS, welcher schon seit 2013 besteht und vom T440 bis an den T460 weitergereicht wurde.Lenovo behebt den Fehler, welcher bekannt ist nicht.Jemand hat den zugehörigen ... Weiterlesen

Der Beitrag Thinkpad T450s ACPI Error unter Debian GNU/Linux erschien zuerst auf Got tty.

Nextcloud-Kalender in Thunderbird einbinden

02. Juli 2025 um 04:00

Einen Nextcloud-Kalender in Thunderbird einzubinden, ist nicht sehr schwer. Wie das Ganze funktioniert, zeige ich in diesem Artikel.

Vorbereitung in der Nextcloud

Zuerst meldet man sich über die Weboberfläche der Nextcloud an. Dort navigiert man zum Kalender und weiter unten links auf die Kalender-Einstellungen.

Nextcloud – Kalender-Einstellungen
Nextcloud – Kalender-Einstellungen

Dort wird dann die Primäre CalDAV-Adresse, wie im Screenshot zu sehen, kopiert.

Nextcloud –- CalDAV-Adresse
Nextcloud – CalDAV-Adresse

Vorbereitung in Thunderbird

In Thunderbird wählt man den Kalender aus, klickt auf Neuer Kalender, wählt Im Netzwerk und fügt den Benutzernamen des Nextcloud-Accounts sowie die zuvor kopierte CalDAV-Adresse ein.

Thunderbird – Neuen Kalender erstellen
Thunderbird – Neuen Kalender erstellen
Thunderbird – Netzwerk-Kalender
Thunderbird – Netzwerk-Kalender
Thunderbird – Netzwerk-Kalender -> Adresse eingeben
Thunderbird – Netzwerk-Kalender -> Adresse eingeben

Nun bestätigt man den Vorgang mit dem Passwort des Nextcloud-Accounts.

Anschließend werden die Kalender der Nextcloud angezeigt und man wählt den zu integrierenden CalDAV-Kalender aus.

Thunderbird – Netzwerk-Kalender -> Kalender auswählen
Thunderbird – Netzwerk-Kalender -> Kalender auswählen

Ist dies erledigt, wird der Kalender in Thunderbird angezeigt. Nach der automatischen Synchronisation, die eine Weile dauern kann, sind auch die ersten Einträge – wie im Screenshot zu sehen – sichtbar.

Thunderbird – Kalender
Thunderbird – Kalender

Viel Spaß!

Der Beitrag Nextcloud-Kalender in Thunderbird einbinden erschien zuerst auf intux.de.

dnsHome bevorzugt IPv6

27. Juni 2025 um 04:00

Wenn es um den Raspberry Pi und DynDNS geht, empfehle ich gerne, wie im Artikel „Nextcloud auf dem RasPi – Teil 4“ beschrieben, als DynDNS-Anbieter den Dienst dnsHome.de. Privatanwender kommen hier in den Genuss, eine kostenlose DynDNS für kleinere Projekte nutzen zu können. Dieser Dienst arbeitet einwandfrei und sorgt dafür, dass u. a. eigene Cloud-Server nach der Zwangstrennung des Internetanbieters stets erreichbar bleiben. Durch den ständigen Abruf der öffentlichen IP und der Übermittlung bei Änderung dieser an den DynDNS-Anbieter wird sichergestellt, dass der Server über eine Subdomain immer erreichbar bleibt.

Darstellung DynDNS
Darstellung DynDNS. Quelle: Wikipedia

Nun kam es aber bei einer von mir aufgesetzten Installation in einem Telekom-Netz vor, dass die von dnsHome empfohlene Konfiguration

# Configuration file for ddclient generated by debconf
#
# /etc/ddclient.conf
 
protocol=dyndns2
ssl=yes # Erst ab ddclient Version 3.7 möglich, bitte prüfen
daemon=3600
use=web, web=ip.dnshome.de
server=www.dnshome.de
login=SUBDOMAIN.DOMAIN.TLD
password=PASSWORT
SUBDOMAIN.DOMAIN.TLD

des ddclients nicht funktionierte. Wo lag das Problem? Der Eintrag

web=ip.dnshome.de

ermittelt in diesem Netz nicht wie gewünscht die IPv4-, sondern die IPv6-Adresse und leitet diese an dnsHome weiter. Somit wurde die Verbindung der Subdomain zum Server gestört. Natürlich gibt es auch hierfür eine einfache Lösung. Durch den Austausch des zuvor erwähnten Eintrags durch

web=ip4.dnshome.de

wird das Problem behoben.

Der Beitrag dnsHome bevorzugt IPv6 erschien zuerst auf intux.de.

Open Source baut Brücken

23. Mai 2025 um 04:00

Seit über zwölf Jahren beschäftige ich mich intensiv mit Linux-Servern. Der Einstieg gelang mir über den Einplatinencomputer Raspberry Pi. Erste Erfahrungen sammelte ich damals mit XBMC – heute besser bekannt als Kodi. Dabei handelt es sich um eine freie, plattformübergreifende Mediaplayer-Software, die dank ihrer Flexibilität und Erweiterbarkeit schnell mein Interesse an quelloffener Software weckte.

Schnell wurde mir klar, dass der Raspberry Pi weit mehr kann. So folgten bald weitere spannende Projekte, darunter auch die ownCloud. Das von Frank Karlitschek gegründete Unternehmen entwickelte eine Cloud-Software, die nicht nur quelloffen war, sondern sich auch problemlos auf Systemen wie Debian oder Ubuntu installieren ließ. Die Möglichkeit, eigene Dateien auf einem selbst betriebenen Server zu speichern und zu synchronisieren, war ein überzeugender Schritt in Richtung digitaler Eigenverantwortung.

Im Jahr 2016 verließ Karlitschek ownCloud, forkte das Projekt und gründete die Firma Nextcloud. Diese erfreut sich bis heute großer Beliebtheit in der Open-Source-Community. Nextcloud bietet neben der klassischen Dateisynchronisation auch zahlreiche Erweiterungen wie Kalender, Kontakte, Videokonferenzen und Aufgabenverwaltung. Damit positioniert sich die Lösung als vollwertige Alternative zu kommerziellen Diensten wie Google Workspace oder Microsoft 365 – mit dem entscheidenden Unterschied, dass die Datenhoheit beim Nutzer selbst bleibt.

Debian vs. Ubuntu

Nextcloud lässt sich auf Debian- und Ubuntu-Systemen relativ unkompliziert auf einem klassischen LAMP-Stack installieren. Doch welches System die bessere Wahl ist, lässt sich pauschal nicht sagen – beide bringen ihre jeweiligen Stärken und Schwächen mit. Debian gilt als besonders stabil und konservativ, was es ideal für Serverumgebungen macht. Ubuntu hingegen punktet mit einem häufig aktuelleren Softwareangebot und einem umfangreicheren Hardware-Support.

Da das Betriebssystem des Raspberry Pi stark an Debian angelehnt ist, läuft die Cloud-Software auch auf dieser Plattform nach wie vor sehr stabil – inzwischen sogar in einer 64-Bit-Variante. Häufiger Flaschenhals ist hier jedoch nicht die Software selbst, sondern die Internetanbindung. Insbesondere der Upstream kann bei vielen DSL-Verbindungen zur Herausforderung werden, wenn größere Datenmengen übertragen werden sollen. Ein Blick in Richtung Virtual Private Server kann sich lohnen.

Virtual Private Server

Wer eine Nextcloud im eigenen Zuhause betreiben möchte, ist mit einem Raspberry Pi gut beraten. Doch Mini-PCs mit Debian oder Ubuntu bieten aufgrund ihrer Bauform – etwa durch die Möglichkeit, mehrere SSDs aufzunehmen – oft eine noch bessere Alternative. Hinzu kommt der Vorteil, dass auch Dienste wie automatische Backups oder RAID-Systeme einfacher umzusetzen sind.

Will man jedoch weitere Dienste auf dem Server betreiben, wie etwa WordPress für die eigene Webseite oder einen Mailserver für den E-Mail-Verkehr, stößt man mit einem Mini-Computer schnell an Grenzen. In solchen Fällen ist ein Virtual Private Server, kurz VPS, die bessere Wahl. Leistungsfähige Angebote wie ein passendes VPS von IONOS, Hetzner oder Netcup machen ein solches Vorhaben inzwischen auch für Privatnutzer bezahlbar. VPS bieten dabei nicht nur mehr Leistung, sondern auch eine höhere Verfügbarkeit, da die Anbindung an das Internet in der Regel professionell realisiert ist.

Fazit

Wer eigene Dienste wie Cloud, Website oder E-Mail in Selbstverwaltung hosten möchte, kann dies mit überschaubarem Aufwand zu Hause mit Open-Source-Software umsetzen. Reicht die Leistung nicht aus, ist ein Virtual Private Server (VPS) eine sinnvolle Alternative.

Der administrative Aufwand sollte dabei nicht unterschätzt werden. Regelmäßige Updates, Backups und Sicherheitskonfigurationen gehören ebenso zum Betrieb wie ein grundlegendes Verständnis für die eingesetzten Komponenten. Doch der entscheidende Vorteil bleibt: Die Kontrolle über die eigenen Daten liegt vollständig in der eigenen Hand – ein wichtiger Schritt hin zur digitalen Souveränität. Open Source baut hier nicht nur funktionale, sondern auch ideelle Brücken.

Der Beitrag Open Source baut Brücken erschien zuerst auf intux.de.

GIMP 3: Das umfassende Handbuch

22. Mai 2025 um 04:00

GIMP 3: Das umfassende Handbuch“ von Jürgen Wolf ist 2025 in der 4., aktualisierten und überarbeiteten Auflage im Rheinwerk Verlag erschienen und umfasst 782 Seiten.

Viele Anwender haben lange darauf gewartet – GIMP ist nach fast sechs Jahren Entwicklungszeit in Version 3 erschienen. Dieses Release bringt einen komplett überarbeiteten Kern mit sich und setzt nun auf das GTK3-Toolkit. Das Buch „GIMP 3: Das umfassende Handbuch“ bietet – wie der Name schon verrät – ein umfassendes Nachschlagewerk zum GNU Image Manipulation Program, kurz: GIMP.

Das Buch ist in sieben Teile gegliedert.

Teil I – Grundlagen widmet sich, wie der Titel schon sagt, den grundlegenden Funktionen von GIMP. Der Autor erläutert die Oberfläche des Grafikprogramms und stellt dabei heraus, dass sich Nutzer auch in der neuen Version schnell zurechtfinden – ein Hinweis, der mögliche Bedenken beim Umstieg zerstreuen dürfte. Die Aussage „GIMP ist nicht Photoshop“ von Jürgen Wolf ist prägnant und unterstreicht, dass es sich bei GIMP um ein eigenständiges, leistungsfähiges Programm handelt, das keinen direkten Vergleich mit kommerzieller Software scheuen muss – oder sollte. Zahlreiche Workshops mit umfangreichem Zusatzmaterial begleiten die einzelnen Kapitel. Neben der Benutzeroberfläche werden in Teil I auch Werkzeuge und Dialoge ausführlich erklärt. Darüber hinaus wird beschrieben, wie RAW-Aufnahmen in GIMP importiert und weiterverarbeitet werden können. Ebenso finden sich Anleitungen zum Speichern und Exportieren fertiger Ergebnisse sowie Erläuterungen zu den Unterschieden zwischen Pixel- und Vektorgrafiken (siehe Grafik). Auch Themen wie Farben, Farbmodelle und Farbräume werden behandelt – Letzteres wird im dritten Teil des Buches noch einmal vertieft.

Eine Gegenüberstellung von einer Vektorgrafik und einer Pixelgrafik
Vektorgrafik vs. Pixelgrafik

Teil II – Die Bildkorrektur behandelt schwerpunktmäßig die Anpassung von Helligkeit, Kontrast und anderen grundlegenden Bildeigenschaften. Ein wesentlicher Abschnitt widmet sich der Verarbeitung von RAW-Aufnahmen, wobei das Zusammenspiel von GIMP mit Darktable im Mittelpunkt steht. Zahlreiche Beispiele und praxisnahe Bearbeitungshinweise unterstützen den Leser bei der Umsetzung am eigenen Bildmaterial.

Teil III – Rund um Farbe und Schwarzweiß beschreibt den Umgang mit Farben und erläutert grundlegende Konzepte dieses Themenbereichs. Dabei wird auch der Einsatz von Werkzeugen wie Pinsel, Stift und Sprühpistole behandelt. Darüber hinaus zeigt das Kapitel, wie Farben verfremdet und Schwarzweißbilder erstellt werden können.

Teil IV – Auswahlen und Ebenen führt den Leser in die Arbeit mit Auswahlen und Ebenen ein. Besonders faszinierend ist dabei das Freistellen von Objekten und die anschließende Bildmanipulation – eine Disziplin, die GIMP hervorragend beherrscht. Auch hierzu bietet das Buch eine Schritt-für-Schritt-Anleitung in Form eines Workshops.

Teil V – Kreative Bildgestaltung und Retusche erklärt, was sich hinter Bildgröße und Auflösung verbirgt und wie sich diese gezielt anpassen lassen. Techniken wie der „Goldene Schnitt“ werden vorgestellt und angewendet, um Motive wirkungsvoll in Szene zu setzen. Außerdem zeigt das Kapitel, wie sich Objektivfehler – etwa tonnen- oder kissenförmige Verzeichnungen – sowie schräg aufgenommene Horizonte korrigieren lassen. Die Bildverbesserung und Retusche werden ausführlich behandelt. Vorgestellte Techniken wie die Warptransformation sind unter anderem in der Nachbearbeitung von Werbefotografie unverzichtbar.

Warptransformation mit GIMP
Retusche – Warptransformation

Teil VI – Pfade, Text, Filter und Effekte beschäftigt sich mit den vielfältigen Möglichkeiten, die GIMP für die Arbeit mit Pixel- und Vektorgrafiken bietet. So lassen sich beispielsweise Pixelgrafiken nachzeichnen, um daraus Vektoren bzw. Pfade für die weitere Bearbeitung zu erzeugen. Eine weitere Übung, die sich mit der im Handbuch beschriebenen Methode leicht umsetzen lässt, ist der sogenannte Andy-Warhol-Effekt.

Andy-Warhol-Effekt mit GIMP 3 erzeugt
Andy-Warhol-Effekt

Teil VII – Ausgabe und Organisation zeigt, wie der Leser kleine Animationen im WebP- oder GIF-Format erstellen kann. Auch worauf beim Drucken und Scannen zu achten ist, wird in diesem Kapitel ausführlich erläutert. Jürgen Wolf geht zudem noch einmal umfassend auf die verschiedenen Einstellungen in GIMP ein. Besonders hilfreich ist die Auflistung sämtlicher Tastaturkürzel, die die Arbeit mit dem Grafikprogramm spürbar erleichtern.

Das Buch umfasst insgesamt 28 Kapitel und deckt damit alle wichtigen Bereiche der Bildbearbeitung mit GIMP 3 ab.

  • Die Arbeitsoberfläche
  • Umgang mit Dateien
  • Praktische Hilfsmittel
  • Grundlagen der Bildbearbeitung
  • Grundlegendes zur Bildkorrektur
  • Tonwerte anpassen
  • Farbkorrekturen
  • Darktable: Raw-Bilder bearbeiten
  • Mit Farben malen
  • Farbverfremdung
  • Schwarzweißbilder
  • Auswahlen
  • Bildbereiche freistellen mit Auswahlen
  • Ebenen-Grundlagen
  • Ebenentechniken
  • Ebenenmasken
  • Ebenenmodus
  • Bildgröße und Auflösung ändern
  • Die Bildkomposition optimieren
  • Bildstörungen beheben (und hinzufügen)
  • Retusche-Techniken
  • Schärfen und Weichzeichnen
  • Die Arbeit mit Pfaden
  • Text und Texteffekte
  • Die Filter von GIMP
  • Ausgabe für das Internet
  • Drucken und Scannen mit GIMP
  • Die Arbeit mit GIMP organisieren

Leseproben und Downloads

Fazit

GIMP 3: Das umfassende Handbuch“ von Jürgen Wolf überzeugt durch eine klare Struktur, verständliche Erklärungen und praxisnahe Workshops. Sowohl Einsteiger als auch fortgeschrittene Anwender finden hier ein zuverlässiges Nachschlagewerk rund um die Bildbearbeitung mit GIMP. Besonders hervorzuheben sind die zahlreichen Beispiele sowie die umfassende Behandlung aller relevanten Themenbereiche. Wer ernsthaft mit GIMP arbeiten möchte, findet in diesem Buch eine uneingeschränkte Kaufempfehlung.

Der Beitrag GIMP 3: Das umfassende Handbuch erschien zuerst auf intux.de.

SSH-Server mit 2FA-Login

19. Mai 2025 um 15:10

Der SSH-Dienst ist ein natürliches Angriffsziel jedes Servers. Klassische Abwehrmaßnahmen zielen darauf aus, den root-Login zu sperren (das sollte eine Selbstverständlichkeit sein) und mit Fail2ban wiederholte Login-Versuche zu blockieren. Eine weitere Sicherheitsmaßnahme besteht darin, den Passwort-Login mit einer Zwei-Faktor-Authentifizierung (2FA) zu verbinden. Am einfachsten gelingt das server-seitig mit dem Programm google-authenticator. Zusätzlich zum Passwort muss nun ein One-time Password (OTP) angegeben werden, das mit einer entsprechenden App generiert wird. Es gibt mehrere geeignete Apps, unter anderem Google Authenticator und Authy (beide kostenlos und werbefrei).

Es gibt verschiedene Konfigurationsoptionen. Ziel dieser Anleitung ist es, parallel zwei Authentifizierungsvarianten anzubieten:

  • mit SSH-Schlüssel (ohne 2FA)
  • mit Passwort und One-time Password (also mit 2FA)
Links die App »Google Authenticator«, rechts »Authy«

Grundlagen: sshd-Konfiguration

Vorweg einige Worte zu Konfiguration des SSH-Servers. Diese erfolgt durch die folgenden Dateien:

/etc/ssh/sshd_config
/etc/ssh/sshd_config.d/*.conf
/etc/crypto-policies/back-ends/opensshserver.config  (nur RHEL)

Verwechseln Sie sshd_config nicht mit ssh_config (ohne d) für die Konfiguration des SSH-Clients, also für die Programme ssh und scp! opensshserver.config legt fest, welche Verschlüsselungsalgorithmen erlaubt sind.

Beachten Sie, dass bei Optionen, die in den sshd-Konfigurationsdateien mehrfach eingestellt sind, der erste Eintrag gilt (nicht der letzte)! Das gilt auch für Einstellungen, die am Beginn von sshd_config mit Include aus dem Unterverzeichnis /etc/ssh/sshd_config.d/ gelesen werden und die somit Vorrang gegenüber sshd_config haben.

Werfen Sie bei Konfigurationsproblemen unbedingt auch einen Blick in das oft übersehene sshd_config.d-Verzeichnis und vermeiden Sie Mehrfacheinträge für ein Schlüsselwort!

Weil die Dateien aus /etc/ssh/sshd_config.d/ Vorrang gegenüber sshd_config haben, besteht eine Konfigurationsstrategie darin, sshd_config gar nicht anzurühren und stattdessen alle eigenen Einstellungen in einer eigenen Datei (z.B. sshd_config.d/00-myown.conf) zu speichern. 00 am Beginn des Dateinamens stellt sicher, dass die Datei vor allen anderen Konfigurationsdateien gelesen wird.

Überprüfen Sie bei Konfigurationsproblemen mit sshd -T, ob die Konfiguration Fehler enthält. Wenn es keine Konflikte gibt, liefert sshd -T eine Auflistung aller aktuell gültigen Einstellungen. Die Optionen werden dabei in Kleinbuchstaben angezeigt. Mit grep -i können Sie die für Sie relevante Einstellung suchen:

sshd -T | grep -i permitro

  permitrootlogin yes

Änderungen an sshd_config werden erst wirksam, wenn der SSH-Server die Konfiguration neu einliest. Dazu führen Sie das folgende Kommando aus:

systemctl reload sshd       # RHEL
systemctl reload ssh        # Debian, Ubuntu

google-authenticator einrichten

Google Authenticator bezeichnet zwei unterschiedliche Programme: einerseits die App, die sowohl für iOS als auch für Android verfügbar ist, andererseits ein Linux-Kommando, um die 2FA auf einem Linux-Server einzurichten. Während der Code für die Smartphone-Apps nicht öffentlich ist, handelt es sich bei dem Linux-Kommando um Open-Source-Code. Das resultierende Paket steht für RHEL-Distributionen in der EPEL-Paketquelle zur Verfügung, bei Ubuntu in universe.

dnf install google-authenticator qrencode   # RHEL + EPEL
apt install libpam-google-authenticator     # Debian, Ubuntu

Nach der Installation führen Sie für den Account, als der Sie sich später via SSH anmelden möchten (also nicht für root), das Programm google-authenticator aus. Nachdem Sie den im Terminal angezeigten QR-Code gescannt haben, sollten Sie zur Kontrolle sofort das erste OTP eingeben. Sämtliche Rückfragen können Sie mit y beantworten. Die Rückfragen entfallen, wenn Sie das Kommando mit den Optionen -t -d -f -r 3 -R 30 -W ausführen. Das Programm richtet die Datei .google-authenticator im Heimatverzeichnis ein.

user$ google-authenticator
  Do you want authentication tokens to be time-based (y/n)
  Enter code from app (-1 to skip): nnnnnn
  Do you want me to update your .google_authenticator file? (y/n)
  Do you want to disallow multiple uses of the same
    authentication token? (y/n)
  ...
Zum Einrichten wird das Kommando »google-authenticator« im Terminal ausgeführt. Den QR-Code scannen Sie dann mit der OTP-App Ihrer Wahl ein. (Keine Angst, der hier sichtbare QR-Code stammt nicht von einem öffentlich zugänglichen Server. Er wurde vielmehr testweise in einer virtuellen Maschine erzeugt.)

SSH-Server-Konfiguration

Das nächste Listing zeigt die erforderlichen sshd-Einstellungen. Mit der Methode keyboard-interactive wird PAM für die Authentifizierung verwendet, wobei auch eine mehrstufige Kommunikation erlaubt ist. Die ebenfalls erforderliche Einstellung UsePAM yes gilt bei den meisten Linux-Distributionen standardmäßig. Am besten speichern Sie die folgenden Zeilen in der neuen Datei /etc/ssh/sshd_config.d/00-2fa.conf. Diese wird am Beginn der sshd-Konfiguration gelesen und hat damit Vorrang gegenüber anderen Einstellungen.

# Datei /etc/ssh/sshd_config.d/00-2fa.conf
UsePAM                           yes
PasswordAuthentication           yes
PubkeyAuthentication             yes
ChallengeResponseAuthentication  yes
# Authentifizierung wahlweise nur per SSH-Key oder
# mit Passwort + OTP
AuthenticationMethods            publickey keyboard-interactive

PAM-Konfiguration

Der zweite Teil der Konfiguration erfolgt in /etc/pam.d/sshd. Am Ende dieser Datei fügen Sie eine Zeile hinzu, die zusätzlich zu allen anderen Regeln, also zusätzlich zur korrekten Angabe des Account-Passworts, die erfolgreiche Authentifizierung durch das Google-Authenticator-Modul verlangt:

# am Ende von /etc/pam.d/sshd (Debian, Ubuntu)
...
# Authenticator-Zifferncode zwingend erforderlich
auth required pam_google_authenticator.so

Alternativ ist auch die folgende Einstellung mit dem zusätzlichen Schlüsselwort nullok denkbar. Damit akzeptieren Sie einen Login ohne 2FA für Accounts, bei denen Google Authenticator noch nicht eingerichtet wurde. Sicherheitstechnisch ist das natürlich nicht optimal — aber es vereinfacht das Einrichten neuer Accounts ganz wesentlich.

# am Ende von /etc/pam.d/sshd (Debian, Ubuntu)
...
# Authenticator-Zifferncode nur erforderlich, wenn 
# Google Authenticator für den Account eingerichtet wurde
auth required pam_google_authenticator.so nullok

Wenn Sie RHEL oder einen Klon verwenden, sieht die PAM-Konfiguration ein wenig anders aus. SELinux verbietet dem SSH-Server Zugriff auf Dateien außerhalb des .ssh-Verzeichnisses. Deswegen müssen Sie die Datei .google-authenticator vom Home-Verzeichnis in das Unterverzeichnis .ssh verschieben. restorecon stellt sicher, dass der SELinux-Kontext für alle Dateien im .ssh-Verzeichnis korrekt ist.

user$ mv .google-authenticator .ssh/    (nur unter RHEL!)
user$ restorecon .ssh

In der Zeile auth required übergeben Sie nun als zusätzliche Option den geänderten Ort von .google-authenticator. Falls Sie die nullok-Option verwenden möchten, fügen Sie dieses Schlüsselwort ganz am Ende hinzu.

# am Ende von /etc/pam.d/sshd (RHEL & Co.)
...
auth required pam_google_authenticator.so secret=/home/${USER}/.ssh/.google_authenticator

Test und Fehlersuche

Passen Sie auf, dass Sie sich nicht aus Ihrem Server aussperren! Probieren Sie das Verfahren zuerst in einer virtuellen Maschine aus, nicht auf einem realen Server!

Vergessen Sie nicht, die durchgeführten Änderungen zu aktivieren. Vor ersten Tests ist es zweckmäßig, eine SSH-Verbindung offen zu lassen, damit Sie bei Problemen die Einstellungen korrigieren können.

sshd -T                   # Syntaxtest
systemctl reload sshd     # RHEL
systemctl reload ssh      # Debian + Ubuntu

Bei meinen Tests hat sich die Google-Authenticator-Konfiguration speziell unter RHEL als ziemlich zickig erwiesen. Beim Debugging können Sie client-seitig mit ssh -v, server-seitig mit journalctl -u sshd nach Fehlermeldungen suchen.

Die Anwendung von Google Authenticator setzt voraus, dass die Uhrzeit auf dem Server korrekt eingestellt ist. Die One-Time-Passwords gelten nur in einem 90-Sekunden-Fenster! Das sollten Sie insbesondere bei Tests in virtuellen Maschinen beachten, wo diese Bedingung mitunter nicht erfüllt ist (z.B. wenn die virtuelle Maschine pausiert wurde). Stellen Sie die Zeit anschließend neu ein, oder starten Sie die virtuelle Maschine neu!

Was ist, wenn das Smartphone verlorengeht?

Für den Fall, dass das Smartphone und damit die zweite Authentifizierungsquelle verlorengeht, zeigt das Kommando google-authenticator bei der Ausführung fünf Ziffernfolgen an, die Sie einmalig für einen Login verwendet können. Diese Codes müssen Sie notieren und an einem sicheren Ort aufbewahren — dann gibt es im Notfall einen »Plan B«. (Die Codes sind auch in der Datei .google_authenticator enthalten. Auf diese Datei können Sie aber natürlich nicht mehr zugreifen, wenn Sie keine Login-Möglichkeit mehr haben.)

Die App Google Authenticator synchronisiert die 2FA-Konfiguration automatisch mit Ihrem Google-Konto. Die 2FA-Konfiguration kann daher auf einem neuen Smartphone rasch wieder hergestellt werden. Schon eher bereitet Sorge, dass nur die Kenntnis der Google-Kontodaten ausreichen, um Zugang zur 2FA-Konfiguration zu erhalten. Die Cloud-Synchronisation kann in den Einstellungen gestoppt werden.

Auch Authy kann die 2FA-Konfiguration auf einem Server der Firma Twilio speichern und mit einem weiteren Gerät synchronisieren. Anders als bei Google werden Ihre 2FA-Daten immerhin mit einem von Ihnen zu wählenden Passwort verschlüsselt. Mangels Quellcode lässt sich aber nicht kontrollieren, wie sicher das Verfahren ist und ob es den Authy-Betreibern Zugriff auf Ihre Daten gewährt oder nicht. 2024 gab es eine Sicherheitspanne bei Twilio, bei der zwar anscheinend keine 2FA-Daten kompromittiert wurden, wohl aber die Telefonnummern von 35 Millionen Authy-Benutzern.

Sicherheits- und Privacy-Bedenken

Authenticator-Apps funktionieren prinzipiell rein lokal. Weder der beim Einrichten erforderliche Schlüssel bzw. QR-Code noch die ständig generierten Einmalcodes müssen auf einen Server übertragen werden. Die Apps implementieren den öffentlich standardisierten HMAC-based One-Time Password Algorithmus (OATH-HOTP).

Allerdings bieten einige OTP-Apps die Möglichkeit, die Account-Einträge über ein Cloud-Service zu sichern (siehe oben). Diese Cloud-Speicherung ist eine mögliche Sicherheitsschwachstelle.

Davon losgelöst gilt wie bei jeder App: Sie müssen der Firma vertrauen, die die App entwickelt hat. Der Code der App Google Authenticator war ursprünglich als Open-Source verfügbar, seit 2020 ist das leider nicht mehr der Fall. Wenn Sie weder Google Authenticator noch Authy vertrauen, finden Sie im Arch Linux Wiki Links zu Apps, deren Code frei verfügbar ist.

Quellen, Links

Upgrade auf Nextcloud 31

18. April 2025 um 04:00

Heute möchte ich kurz erzählen, welche Schwierigkeiten ich beim Upgrade auf Nextcloud 31 Hub 10 zu bewältigen hatte.

Das Upgrade auf Nextcloud 31 war in meinem Fall mal wieder von einigen Hürden umstellt. Meine ersten Versuche, die Nextcloud auf Version 31.0.0 Stable zu heben, waren zwar von Erfolg gekrönt, jedoch sperrte ich damit meinen WebAuthn-Zugang zu meinen Daten. Weitere Versuche bei den Neuerscheinungen 31.0.1 und 31.0.2 liefen ebenfalls ins Leere.

Nun, mit Version 31.0.3, wurde das WebAuthn-Problem jedoch gefixt. Nach der Reparatur der Datenbank und dem Einspielen fehlender Indizes blieb noch eine zu beseitigende Fehlermeldung übrig. Es handelt sich um ein falsches Zeilenformat in der Datenbank.

Falsches Zeilenformat in deiner Datenbank gefunden. ROW_FORMAT=Dynamic bietet die beste Datenbankleistung für Nextcloud. Bitte aktualisiere das Zeilenformat in der folgenden Liste: oc_authtoken, oc_notifications_settings, oc_circles_event, oc_bookmarks_root_folders, oc_vcategory_to_object, oc_vcategory, oc_richdocuments_assets, oc_calendar_rooms, oc_calendar_invitations, oc_webauthn, oc_deck_cards, oc_circles_mountpoint, oc_users, oc_collres_accesscache, oc_talk_internalsignaling, oc_mail_attachments, oc_talk_attendees, oc_external_options, oc_oauth2_access_tokens, oc_twofactor_totp_secrets, oc_deck_assigned_users, oc_mail_trusted_senders, oc_external_config, oc_storages, oc_group_folders_manage, oc_mail_aliases, oc_activity_mq, oc_jobs, oc_bookmarks_folders, oc_deck_board_acl, oc_whats_new, oc_deck_attachment, oc_group_user, oc_twofactor_u2f_registrations, oc_share_external, oc_calendarobjects, oc_accounts_data, oc_mail_accounts, oc_calendarchanges, oc_text_sessions, oc_notifications_pushhash, oc_appconfig, oc_bookmarks_folders_public, oc_user_status, oc_mail_provisionings, oc_circles_mount, oc_bookmarks_tree, oc_richdocuments_direct, oc_calendarsubscriptions, oc_accounts, oc_external_mounts, oc_login_flow_v2, oc_mail_message_tags, oc_calendar_resources_md, oc_comments_read_markers, oc_deck_assigned_labels, oc_mail_tags, oc_mounts, oc_text_documents, oc_flow_checks, oc_mimetypes, oc_group_admin, oc_deck_boards, oc_groups, oc_bookmarks_shares, oc_group_folders_acl, oc_ratelimit_entries, oc_circles_member, oc_migrations, oc_notifications, oc_direct_edit, oc_group_folders_trash, oc_twofactor_providers, oc_files_trash, oc_collres_collections, oc_federated_reshares, oc_talk_commands, oc_addressbookchanges, oc_user_transfer_owner, oc_authorized_groups, oc_share, oc_mail_mailboxes, oc_circles_token, oc_talk_bridges, oc_directlink, oc_circles_circle, oc_twofactor_backupcodes, oc_flow_operations_scope, oc_mail_recipients, oc_calendar_appt_bookings, oc_oauth2_clients, oc_circles_remote, oc_group_folders_groups, oc_bookmarks, oc_dav_shares, oc_cards, oc_addressbooks, oc_mail_local_messages, oc_storages_credentials, oc_activity, oc_bookmarks_tags, oc_external_applicable, oc_recent_contact, oc_filecache, oc_file_locks, oc_mail_messages, oc_flow_operations, oc_known_users, oc_text_steps, oc_collres_resources, oc_richdocuments_wopi, oc_mail_coll_addresses, oc_bookmarks_shared_folders, oc_circles_membership, oc_group_folders, oc_systemtag, oc_comments, oc_systemtag_object_mapping, oc_trusted_servers, oc_privacy_admins, oc_dav_cal_proxy, oc_calendar_appt_configs, oc_talk_rooms, oc_deck_stacks, oc_calendar_rooms_md, oc_cards_properties, oc_properties, oc_calendar_resources, oc_calendar_reminders, oc_preferences, oc_circles_share_lock, oc_bruteforce_attempts, oc_filecache_extended, oc_schedulingobjects, oc_systemtag_group, oc_deck_labels, oc_talk_sessions, oc_profile_config, oc_calendars, oc_calendarobjects_props. Weitere Informationen findest du in der Dokumentation ↗.

Dieser Konflikt kann aber schnell gelöst werden, indem man ein Skript mit folgendem Inhalt erstellt und dieses im Nachgang im Home-Verzeichnis ausführt. Dazu wechselt man in dieses:

cd ~/

Dann öffnet man den Editor:

sudo nano database.sh

fügt folgenden Inhalt ein und speichert mit Ctrl + o:

#!/bin/bash

# Prompt for database credentials
read -p "Enter Database Name: " DB_NAME
read -p "Enter Username: " DB_USER
read -s -p "Enter Password: " DB_PASS
echo

# Generate ALTER TABLE statements and execute them
mysql -u "$DB_USER" -p"$DB_PASS" -e "
SELECT CONCAT('ALTER TABLE `', TABLE_NAME, '` ROW_FORMAT=DYNAMIC;') 
FROM INFORMATION_SCHEMA.TABLES 
WHERE TABLE_SCHEMA = '$DB_NAME' 
AND ENGINE = 'InnoDB';
" -B -N | while read -r sql; do
    mysql -u "$DB_USER" -p"$DB_PASS" -e "$sql" "$DB_NAME"
done

Mit Ctrl + x verlässt man den Editor wieder. Nun wird das Skript mit

sudo chmod +x database.sh

ausführbar gemacht und mit

sudo ./database.sh

gestartet. Während der Ausführung werden Datenbankname, Benutzername und Passwort abgefragt. Sind die Eingaben richtig, sind die Datenbank am Ende gefixt und die Fehlermeldung verschwunden.

Der Beitrag Upgrade auf Nextcloud 31 erschien zuerst auf intux.de.

Einspielen eines Backups mit Statusanzeige

18. März 2025 um 13:06

Beim Wiederherstellen eines Backups zurück auf eine MicroSD unter Linux ist der Befehl dd ein bewährtes Werkzeug. Jedoch fehlte in der Vergangenheit die Anzeige des Fortschritts, sodass der Benutzer nicht genau wusste, wie lange der Vorgang noch dauert. Mit der Option status=progress ändert sich das. In diesem Artikel zeige ich, wie man ein Backup komfortabel mit dd auf eine MicroSD schreibt und dabei den Fortschritt im Blick behält.

Der Befehl im Detail

Um das Image backup.img aus dem Home-Verzeichnis von intux auf die MicroSD zu schreiben, wird folgender Befehl genutzt:

sudo dd if=/home/intux/backup.img of=/dev/mmcblk0 bs=1M status=progress

Die Eingabe muss natürlich an die Gegebenheiten des eigenen Systems (Verzeichnisse) angepasst werden.

Hier eine kurze Erläuterung der Parameter:

  • sudo – Da dd direkten Zugriff auf die Speichergeräte benötigt, sind Administratorrechte erforderlich.
  • if=/home/intux/backup.img – Das if (input file) gibt das Image an, das auf die Karte geschrieben werden soll.
  • of=/dev/mmcblk0 – Das of (output file) gibt das Zielgerät an. Hier ist es die MicroSD (/dev/mmcblk0).
  • bs=1M – Die Blockgröße beträgt 1 Megabyte. Dies beschleunigt das Schreiben im Vergleich zur Standardblockgröße.
  • status=progress – Zeigt während des Kopiervorgangs den Fortschritt an.

Fortschrittsanzeige in Echtzeit

Einer der größten Nachteile von dd war lange Zeit das fehlende Feedback über den aktuellen Status. Durch die Option status=progress erhalten wir eine dynamische Anzeige, die kontinuierlich angibt, wie viele Daten bereits übertragen wurden.

Während der Kopiervorgang läuft, wird eine Zeile mit der Anzahl der geschriebenen Bytes und der aktuellen Transferrate ausgegeben. Das könnte dann so aussehen:

16280190976 bytes (16 GB, 15 GiB) copied, 1071 s, 15,2 MB/s
dd mit Fortschrittsanzeige
dd mit Fortschrittsanzeige

Diese Anzeige aktualisiert sich in regelmäßigen Abständen, sodass man jederzeit sieht, wie weit der Vorgang fortgeschritten ist.

Fazit

Dank status=progress ist dd nicht mehr die Blackbox, die es früher war. Die Live-Anzeige sorgt dafür, dass man stets über den aktuellen Fortschritt informiert bleibt. Wer regelmäßig Backups auf MicroSDs schreibt, sollte diesen praktischen Zusatz unbedingt nutzen.

Der Beitrag Einspielen eines Backups mit Statusanzeige erschien zuerst auf intux.de.

Raspberry Pi Raid

06. März 2025 um 15:38

Heute möchte ich über ein Thema schreiben, das sicher den einen oder anderen Leser meines Blogs beschäftigt. Es geht um die Frage, wie man auf einer auf einem Raspberry Pi installierten Nextcloud ein RAID-System aufbaut, um Daten redundant auf dem Massenspeicher abzulegen.

Als Vorlage diente mir hierbei eine Anleitung von Daniel von der Firma apfelcast, die ich in Teilen etwas abgeändert habe.

Installation

Zuerst wird die Software mdadm auf dem Raspberry Pi installiert.

sudo apt-get install mdadm

Um diese zu aktivieren, muss der Raspberry Pi nach der Installation von mdadm neu gestartet werden.

sudo reboot

Danach schaut man nach den angeschlossenen Datenträgern. Ich setze voraus, dass man sich zuvor ausreichend mit dieser Materie auseinandergesetzt hat. Ein RAID-Level 1 erfüllt in unserem Fall alle Voraussetzungen für dieses Unterfangen.

Wenn zwei baugleiche SSDs mit identischer Speicherkapazität (z. B. 1 TB) angeschlossen sind, können diese mit folgendem Befehl identifiziert werden:

sudo lsblk

Beide Laufwerke werden als /dev/sda und /dev/sdb ausgegeben.

RAID-System

Raid-System
Raid-System

Nun werden alle Daten und Partitionen der SSDs gelöscht. Hierzu werden beide Befehle nacheinander ausgeführt:

sudo parted /dev/sda "rm 1"
sudo parted /dev/sdb "rm 1"

Ein abschließender Check gibt Gewissheit.

sudo lsblk

Bei Festplatten < 2 TB werden nun die MSDOS-Partitionstabellen erstellt.

sudo parted /dev/sda "mklabel msdos"
sudo parted /dev/sdb "mklabel msdos"

Bei Festplatten > 2 TB verwendet man hingegen folgende Befehle für GPT-Partitionstabellen.

sudo parted /dev/sda "mklabel gpt"
sudo parted /dev/sdb "mklabel gpt"

Anschließend werden die ext4-Partitionen auf beiden Datenträgern erstellt.

sudo parted /dev/sda "mkpart primary ext4 1M -1"
sudo parted /dev/sdb "mkpart primary ext4 1M -1"

Nun wird RAID auf beiden Partitionen aktiviert.

sudo parted /dev/sda "set 1 raid on"
sudo parted /dev/sdb "set 1 raid on"

Anschließend kann der Status überprüft werden (siehe Screenshot).

sudo parted -s /dev/sda print
sudo parted -s /dev/sdb print
Check des Status nach Aktivierung der einzelnen Raid-Partitionen
Check des Status nach Aktivierung der einzelnen Raid-Partitionen

Jetzt wird ein RAID-Level 1 erstellt, sodass beide Laufwerke zu einem zusammengeführt und so die Daten redundant gespeichert werden können. Falls eine SSD ausfällt, sollten somit keine Daten verloren gehen.

sudo mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda1 /dev/sdb1

Alternativ könnte ein RAID 0 eingerichtet werden, um beide SSDs hintereinander zu verknüpfen. Dabei würde sich die Speicherkapazität verdoppeln.

Eine letzte Überprüfung zeigt nun den aktuellen Zustand.

lsblk
Eingehängte Raid-SSDs
Eingehängte Raid-SSDs

Einrichtung des Dateisystems

Nun kann das Dateisystem für das RAID eingerichtet werden.

sudo mkfs -t ext4 /dev/md0

Der Fortschritt wird mit den folgenden Befehlen überprüft (siehe Screenshots).

cat /proc/mdstat
Überprüfung des Fortschritts
Überprüfung des Fortschritts
sudo mdadm --detail /dev/md0
Details des Raid-Systems
Details des Raid-Systems

Das Mountverzeichnis wird erstellt und der Datenspeicher darauf gemountet.

sudo mkdir /media/ssd
sudo mount /dev/md0 /media/ssd

Nun wird die Datei /etc/fstab bearbeitet, damit der Datenträger nach einem Neustart weiterhin mit unserer Nextcloud verbunden bleibt.

sudo nano /etc/fstab/

Dort fügt man folgende Zeile hinzu und speichert die Datei ab:

/dev/md0 /media/raid ext4 4,nofail 0 0
Konfigurations-Datei /etc/fstab
Konfigurationsdatei /etc/fstab

Die Bearbeitung der crontab sorgt dafür, dass das RAID-System beim Neustart korrekt eingebunden wird.

sudo crontab -e

Dort wird folgender Eintrag hinzugefügt:

@reboot sleep 5; sudo mount /dev/md0 /media/raid

Datenverzeichnis verschieben

Das vorhandene Datenverzeichnis wird von der MicroSD auf das RAID-System verschoben.

sudo mv /var/www/html/nextcloud/data /media/ssd

Anschließend muss der Nextcloud noch mitgeteilt werden, wo sich das Datenverzeichnis befindet. Dazu wird die Konfigurationsdatei geöffnet.

sudo nano /var/www/html/nextcloud/config/config.php

Der folgende Eintrag wird angepasst und von

'datadirectory' => '/var/www/html/nextcloud/data',

in

'datadirectory' => '/media/ssd/data',

geändert.

Damit ist die Einrichtung des RAID-Systems für die Nextcloud auf dem Raspberry Pi abgeschlossen!

Der Beitrag Raspberry Pi Raid erschien zuerst auf intux.de.

Ubuntu beschleunigen

14. Januar 2025 um 05:00

Es gibt ein paar Stellschrauben, an denen man drehen kann, um das Betriebssystem Ubuntu zu beschleunigen. Heute stelle ich das Tool Preload vor.

Bei Preload handelt es sich um einen Hintergrunddienst, der die Systemleistung verbessert, indem er häufig genutzte Anwendungen vorab lädt. Preload basiert auf der Idee des „predictive loading“, bei dem das System analysiert, welche Programme der Benutzer häufig verwendet, und diese Programme oder Teile davon im Voraus in den Speicher lädt. Dadurch können Programme oder Teile davon, die bereits im RAM vorhanden sind, schneller starten.

Installation

sudo apt install preload

Die Konfiguration kann angepasst werden, wobei die Standardeinstellung völlig ausreicht. Wer dennoch einige Werte anpassen möchte, schaut bitte hier.

Der Beitrag Ubuntu beschleunigen erschien zuerst auf intux.de.

Software CEWE Fotowelt installieren

12. Januar 2025 um 05:00

Fotobücher lassen sich heutzutage recht leicht über Computer oder Smartphones erstellen. Hierzu gibt es einige Anbieter, die sich darauf spezialisiert haben. Ich möchte heute erklären, wie man die Software CEWE Fotowelt auf Ubuntu 24.04 LTS installiert.

Quelle: YouTube

Installation

Um CEWE Fotowelt zu installieren, wird die Seite cewe.de aufgerufen und die Software über Software & App -> CEWE Fotowelt Software -> Kostenfrei herunterladen und unter Downloads auf dem eigenen Rechner abgelegt. Anschließend wird die Datei setup_CEWE_Fotowelt.tgz im Downloads-Ordner entpackt. Nun wechselt man in das Terminal und führt folgenden Befehl aus:

sudo /home/intux/Downloads/setup_CEWE_Fotowelt/./install.pl

Hierbei muss noch der Benutzer (in meinem Fall intux) an die eigenen Gegebenheiten angepasst werden.

Man folgt nun der Anleitung durch Bestätigen mit Enter. Es öffnet sich die Endbenutzer-Lizenzvereinbarung (EULA) zu „CEWE FOTOWELT“. Diese wird durch das Drücken von q (nach dem Lesen) verlassen. Danach wird man aufgefordert, die EULA zu akzeptieren. Dies geschieht über die Eingabe von ja und der Bestätigung via Enter.

Die Frage:

Wo soll ‚CEWE Fotowelt 8.0.2‘ installiert werden? [/opt/CEWE/CEWE Fotowelt]

wird ebenfalls mit Enter akzeptiert.

Durch erneutes Bestätigen mit Enter wird das noch nicht existierende Verzeichnis angelegt. Im Anschluss werden durch die neuerliche Eingabe von Enter die Daten aus dem Internet geladen und die Software installiert.

Software CEWE Fotowelt
CEWE_Fotowelt
Erstellung Fotobuch mit Software CEWE Fotowelt
Erstellung Fotobuch

Der Beitrag Software CEWE Fotowelt installieren erschien zuerst auf intux.de.

Nextcloud auf dem RasPi – Teil 9

22. Dezember 2024 um 08:47

Mit diesem Artikel möchte ich meine Nextcloud-Serie schließen. Um die installierte Cloud nun noch mit einer Videokonferenz-Funktion zu erweitern, möchte ich heute zeigen, wie man einen TURN-Server auf das bestehende System aufsetzt. Dies hatte ich im Mai diesen Jahres im Artikel „Coturn TURN-Server für Nextcloud Talk“ zwar schon erklärt, aber es gehört aus meiner Sicht einfach in diese Artikelserie hinein.

Installation

Ein TURN-Server wird von Nextcloud Talk benötigt, um Videokonferenzen zu ermöglichen. Der TURN-Server bringt die Teilnehmer, welche sich in verschiedenen Netzwerken befinden, zusammen. Nur so ist eine reibungslose Verbindung unter den Gesprächspartnern in Nextcloud Talk möglich.

Wer bisher meinen Anleitungen zur Installation von Nextcloud auf dem Raspberry Pi gefolgt ist, kann nun die eigene Cloud für Videokonferenzen fit machen. Zu bedenken gilt aber, dass ein eigener TURN-Server nur bis maximal 6 Teilnehmer Sinn macht. Wer Konferenzen mit mehr Teilnehmern plant, muss zusätzlich einen Signaling-Server integrieren.

Nun zur Installation des TURN-Servers. Zuerst installiert man den Server mit

sudo apt install coturn

und kommentiert folgende Zeile, wie nachfolgend zu sehen in /etc/default/coturn aus.

sudo nano /etc/default/coturn

Dabei wird der Server im System aktiviert.

#
# Uncomment it if you want to have the turnserver running as
# an automatic system service daemon
#
TURNSERVER_ENABLED=1

Nun legt man die Konfigurationsdatei zum TURN-Server mit folgendem Inhalt an.

sudo nano /etc/turnserver.conf
listening-port=5349
fingerprint
lt-cred-mech
use-auth-secret
static-auth-secret=geheimespasswort
realm=cloud.domain.tld
total-quota=100
bps-capacity=0
stale-nonce
no-loopback-peers
no-multicast-peers

Hier werden u.a. der Port und das Passwort des Servers sowie die Domain der Cloud eingetragen. Natürlich muss hier noch der Port im Router freigegeben werden. Ein starkes Passwort wird nach belieben vergeben.

Hierbei kann das Terminal hilfreich sein. Der folgende Befehl generiert z.B. ein Passwort mit 24 Zeichen.

gpg --gen-random --armor 1 24

Jetzt wird der Server in den Verwaltungseinstellungen als STUN- und TURN-Server inkl. Listening-Port sowie Passwort eingetragen.

Nextcloud - Verwaltungseinstellungen - Talk
Nextcloud – Verwaltungseinstellungen – Talk
Eintrag der Domain für STUN- und TURN-Server (sowie Passwort)
Eintrag der Domain für STUN- und TURN-Server (sowie Passwort)

Damit der TURN-Server nach einem Reboot auch zuverlässig startet, müssen ein paar Einstellungen am Service vorgenommen werden. Mit

sudo systemctl edit coturn.service

wird der Service des Servers editiert. Folgender Eintrag wird zwischen die Kommentare gesetzt:

### Editing /etc/systemd/system/coturn.service.d/override.conf
### Anything between here and the comment below will become the new contents of the file

[Service]
ExecStartPre=/bin/sleep 30

### Lines below this comment will be discarded

### /lib/systemd/system/coturn.service

Dies ermöglicht den TURN-Server (auch nach einem Upgrade) mit einer Verzögerung von 30 Sekunden zu starten.

Zum Schluss wird der Service neu gestartet.

sudo service coturn restart

Ein Check zeigt, ob der TURN-Server funktioniert. Hierzu klickt man auf das Symbol neben dem Papierkorb in der Rubrik TURN-Server der Nextcloud. Wenn alles perfekt läuft ist, wird im Screenshot, ein grünes Häkchen sichtbar.

Check TURN-Server
Check TURN-Server
Check bestanden
Check bestanden

Damit endet die Artikelserie Nextcloud auf dem RasPi. Viel Spaß beim Nachbauen!

Nextcloud auf dem RasPi – Teil 8

18. November 2024 um 05:00

Als ich mit der Artikelserie zur Nextcloud auf dem Raspberry Pi begann, war mein Ziel, ein Tutorial zu erstellen, das es ermöglicht, eine Nextcloud auf dem Einplatinencomputer so zu installieren und zu konfigurieren, dass diese produktiv genutzt werden kann. Nextcloud ist mittlerweile mehr als nur eine Cloud. Nextcloud hat sich zu einem professionellen Büroprodukt entwickelt, das ich selbst täglich nutze.

In diesem Artikel zeige ich, wie man den Datenspeicher von der MicroSD auf eine SSD auslagert, um die Speicherkapazität der Nextcloud zu erweitern. Ich verwende dafür eine SanDisk Extreme mit einer Kapazität von 2TB.

Die Leser, die dieser Artikelreihe bisher gefolgt sind und alles auf dem Raspberry Pi nachgebaut haben, sollten die Version 29 installiert haben. Diejenigen, die etwas mutiger waren, haben bereits ein Upgrade auf Version 30 in den Verwaltungseinstellungen durchgeführt.

Installation

Bevor wir starten, sollte unbedingt ein Backup des gesamten Systems durchgeführt werden, um Datenverlust zu vermeiden, falls etwas schief geht.

Zuerst wird die externe SSD mit dem Raspberry Pi über den USB 3.0-Anschluss verbunden. Anschließend wird die SSD mithilfe des folgenden Befehls identifiziert.

sudo fdisk -l

Das System zeigt nun an, dass die SSD als /dev/sda1 eingehängt wurde. Durch die Eingabe von

sudo mkfs.ext4 /dev/sda1
Identifizierung der SSD im System
Identifizierung der SSD im System

kann die SSD in Ext4 formatiert werden. Auf meinem System erschien eine Fehlermeldung, dass die SSD bereits eingehängt ist und daher nicht formatiert werden kann.

Fehlermeldung – /dev/sda1 is mounted

Daher muss die SSD zuerst wieder ausgehängt werden.

sudo umount -fl /dev/sda1

Anschließend wird die SSD, gemäß der bereits erwähnten Methode im Artikel, Ext4-formatiert. Die Abfrage wird durch die Eingabe von „y“ bestätigt.

sudo mkfs.ext4 /dev/sda1
Formatierung der SSD im Ext4-Format
Formatierung der SSD (Ext4)

Nun wird das Verzeichnis /media/ssd erstellt, in dem später das Datenverzeichnis auf der externen SSD liegen wird.

sudo mkdir /media/ssd

Danach wird das Verzeichnis mit dem Inhalt der SSD gemountet.

sudo mount /dev/sda1 /media/ssd

Damit die SSD auch nach einem Neustart korrekt eingebunden wird, trägt man sie mit der richtigen UUID in die /etc/fstab ein. Die benötigte UUID findet man über den Befehl:

sudo blkid /dev/sda1
Auslesen der UUID der SSD
Auslesen der UUID der SSD

Nun kann die fstab mit der entsprechenden Zeile ergänzt werden. Dieser Eintrag erfolgt direkt unter den beiden Hauptpartitionen (siehe Screenshot).

sudo nano /etc/fstab

Die hier von mir angegebene UUID ist natürlich durch die UUID der eigenen Festplatte zu ersetzen.

UUID=4866c0d5-3ab8-4746-8aaf-c772a60444e9 /media/ssd     ext4    defaults          0       0
Inhalt der Systemdatei /etc/fstab
Systemdatei /etc/fstab

Dabei muss man mit größter Sorgfalt vorgehen, da das System bei einer falschen Eingabe möglicherweise nicht mehr starten wird. Ein vorheriges Backup bietet (wie oben schon erwähnt) Sicherheit. Nachdem alles korrekt eingegeben wurde, kann der Raspberry Pi neu gestartet werden.

sudo reboot

Wenn das System fehlerfrei neu gestartet ist, wird das Datenverzeichnis von der MicroSD-Karte auf die SSD verschoben. Dieser Vorgang kann je nach Größe einige Minuten dauern.

sudo mv /var/www/html/nextcloud/data /media/ssd

Nun muss der Nextcloud noch mitgeteilt werden, wo sich das Datenverzeichnis befindet. Dazu gehen wir in die config.php.

sudo nano /var/www/html/nextcloud/config/config.php

Hier wird nun das Datenverzeichnis an die neue Situation angepasst. Dazu sucht man den Eintrag

'datadirectory' => '/var/www/html/nextcloud/data',

und ändert diesen in:

'datadirectory' => '/media/ssd/data',

Das Data-Verzeichnis befindet sich jetzt auf der externen SSD. Falls ein Upgrade ansteht, kann dieses gleich durchgeführt werden.

Nextcloud - Upgrade auf Version 30.0.2
Nextcloud – Upgrade auf Version 30.0.2
Nextcloud - Dashboard
Nextcloud – Dashboard
Festplatte sda1
Festplatte sda1

Vorschau

Im nächsten und letzten Artikel dieser Reihe möchte ich zeigen, wie man Nextcloud mit einem TURN-Server erweitert, um Videokonferenzen mit Nextcloud Talk nutzen zu können.

Nextcloud auf dem RasPi – Teil 7

16. November 2024 um 05:00

Heute geht es um das Fein-Tuning unserer Nextcloud-Installation, genauer gesagt, um die Umstellung des Systems von PHP auf PHP-FPM. Hierzu wird der Webserver Apache2 konfiguriert und auf HTTP/2 umgestellt.

Installation

Auf dem aktuellen System, Raspberry Pi OS Bookworm, läuft derzeit standardmäßig PHP 8.2. Diese Version werden wir mit den folgenden Schritten umstellen: Zunächst installieren wir PHP-FPM 8.2. Anschließend deaktivieren wir PHP 8.2, aktivieren PHP-FPM 8.2 und HTTP/2. Die erforderlichen Befehle werden nacheinander in der angegebenen Reihenfolge ausgeführt.

sudo apt install php-fpm -y
sudo a2dismod php8.2
sudo a2enconf php8.2-fpm
sudo a2enmod proxy_fcgi
sudo a2dismod mpm_prefork
sudo a2enmod mpm_event
sudo a2enmod http2

Anschließend fügen wir im VirtualHost die folgende Zeile über den Editor Nano

sudo nano /etc/apache2/sites-available/raspi.conf

unter VirtualHost *:443>

Protocols h2 http/1.1

hinzu (siehe Screenshot).

VirtualHost
VirtualHost

Mit einem Neustart des Webservers aktivieren wir nun PHP-FPM 8.2.

sudo service apache2 restart

In der Nextcloud treten nun, nach der Umstellung, allerdings wieder einige bekannte Fehler auf. Diese beheben wir indem wir, mit

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

folgenden Eintrag

memory_limit = 128M

in

memory_limit = 512M


ändern. Am Ende der Datei wird zudem ein weiterer Block mit den spezifischen Einstellungen zu OPcache eingefügt.

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

Zum Abschluss muss dann der PHP-FPM 8.2-Dienst neu gestartet werden.

sudo service php8.2-fpm restart

Tipp

Für eine zusätzliche Optimierung können die FPM-Einstellungen angepasst werden. Dazu werden die folgenden Parameter mit dem Editor auf die spezifischen Anforderungen des Systems eingestellt:

sudo nano /etc/php/8.2/fpm/pool.d/www.conf
pm = dynamic
pm.max_children = 120
pm.start_servers = 12
pm.min_spare_servers = 6
pm.max_spare_servers = 18

Diese Werte sind auf ein System mit 4 GB RAM abgestimmt (siehe Link).

Zum Abschluss wird der Dienst ein letztes Mal gestartet, damit die Änderungen wirksam werden.

sudo service php8.2-fpm restart

Vorschau

Der nächste Artikel dieser Reihe wird sich damit befassen, das Datenverzeichnis von der MicroSD auf eine externe SSD auszulagern, um so den Speicher der Nextcloud zu erweitern.

❌