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.

Erster Testlauf

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.

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.

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

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

• https://www.debian.org
• https://www.debian.org/releases/trixie/release-notes
• https://www.linux-magazin.de/ausgaben/2025/06/deb822/
• https://repolib.readthedocs.io/en/latest/deb822-format.html
• https://manpages.debian.org/unstable/apt/sources.list.5.en.html
• https://doc.dovecot.org/main/installation/upgrade/2.3-to-2.4.html
• https://en.wikipedia.org/wiki/Debian

Andere Tests/Kurzberichte

• https://www.heise.de/news/Linux-Debian-13-kommt-als-Trixie-10515203.html
• https://distrowatch.com/table.php?distribution=debian
• https://www.golem.de/news/debian-13-im-test-architektur-entruempelt-optionen-erweitert-pakete-moderner-2508-198886.html (Paywall)

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.

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

Vorbereitung in Thunderbird

In Thunderbird wählt man Neues Adressbuch anlegen und im Anschluss 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.

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

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

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

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

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.

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.

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

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.

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.

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.

Viel Spaß!

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

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.

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.

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

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.

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.

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

• Leseprobe
• Zusatzmaterialien

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.

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)

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

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

• https://de.wikipedia.org/wiki/Google_Authenticator
• https://de.wikipedia.org/wiki/HMAC-based_one-time_password
• https://www.authy.com/
• https://wiki.archlinux.org/title/Google_Authenticator
• https://9to5mac.com/2024/07/04/authy-hack/
• https://security.googleblog.com/2023/04/google-authenticator-now-supports.html
• https://futurezone.at/apps/google-authenticator-update-2-factor-authentification-cloud-synchronisierung-google-konto/402425360

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.

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

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.

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

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

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

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

sudo mdadm --detail /dev/md0

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

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.

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.

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.

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.

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

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.

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.

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

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

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.

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

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

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

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.

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.

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

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.

Da auf meinem Server einige Container laufen, wurde durch mein Rollout des Containers Tubearchivist der Platz langsam eng. Hier habe ich mich entschlossen, den Standardspeicherplatz von Docker auf eine der 6 TB Datenpools zu verschieben. Das Umschreiben des Servicekonfigurationsdatei innerhalb von SystemD wäre hier der falsche Weg. Der richtige Weg ist hier JSON-Konfigurationsdatei des Daemon von ... Weiterlesen

Der Beitrag Docker Verschieben von /var/lib/docker erschien zuerst auf Got tty.

Wer meiner Artikelreihe „Nextcloud auf dem RasPi“ gefolgt ist und alle Schritte nacheinander umgesetzt hat, sollte erfolgreich eine Nextcloud 29 auf dem Raspberry Pi installiert haben, die über ein SSL-Zertifikat von Let’s Encrypt aus dem Internet erreichbar ist. Obwohl inzwischen Version 30 am 14.09.2024 veröffentlicht wurde, wird diese noch nicht im Stable-Zweig bereitgestellt. Daher werde ich nun auf die Behebung der verbleibenden Fehler in Nextcloud 29 eingehen.

Es fällt sicherlich auf, dass im installierten System in den Verwaltungseinstellungen zahlreiche Fehlermeldungen aufgelaufen sind. Diese müssen nun behoben und beseitigt werden.

Ihr Datenverzeichnis und Ihre Dateien sind wahrscheinlich vom Internet aus erreichbar. Die .htaccess-Datei funktioniert nicht. Es wird dringend empfohlen, Ihren Webserver dahingehend zu konfigurieren, dass das Datenverzeichnis nicht mehr vom Internet aus erreichbar ist oder dass Sie es aus dem Document-Root-Verzeichnis des Webservers herausverschieben.

Das PHP-Speicherlimit liegt unterhalb des empfohlenen Wertes von 512 MB.

Die PHP-Konfigurationsoption „output_buffering“ muss deaktiviert sein

Ihr Webserver ist nicht ordnungsgemäß für die Auflösung von „/ocm-provider/“ eingerichtet. Dies hängt höchstwahrscheinlich mit einer Webserver-Konfiguration zusammen, die nicht dahingehend aktualisiert wurde, diesen Ordner direkt zu auszuliefern. Bitte vergleichen Sie Ihre Konfiguration mit den mitgelieferten Rewrite-Regeln in „.htaccess“ für Apache oder den in der Nginx-Dokumentation mitgelieferten. Auf Nginx sind das typischerweise die Zeilen, die mit „location ~“ beginnen und ein Update benötigen. Weitere Informationen finden Sie in der Dokumentation .

Ihr Webserver ist nicht ordnungsgemäß für die Auflösung von .well-known-URLs eingerichtet. Fehler bei: /.well-known/webfinger Weitere Informationen finden Sie in der Dokumentation .

4 Fehler in den Protokollen seit 20. September 2024, 10:15:53

Der Server hat keine konfigurierte Startzeit für das Wartungsfenster. Das bedeutet, dass ressourcenintensive tägliche Hintergrundaufgaben auch während Ihrer Hauptnutzungszeit ausgeführt werden. Wir empfehlen, das Wartungsfenster auf eine Zeit mit geringer Nutzung festzulegen, damit Benutzer weniger von der Belastung durch diese umfangreichen Aufgaben beeinträchtigt werden. Weitere Informationen finden Sie in der Dokumentation .

Einige Header sind in Ihrer Instanz nicht richtig eingestellt – Der Strict-Transport-Security-HTTP-Header ist nicht gesetzt (er sollte mindestens 15552000 Sekunden betragen). Für erhöhte Sicherheit wird empfohlen, HSTS zu aktivieren. Weitere Informationen finden Sie in der Dokumentation .

In der Datenbank fehlen einige Indizes. Auf Grund der Tatsache, dass das Hinzufügen von Indizes in großen Tabellen einige Zeit in Anspruch nehmen kann, wurden diese nicht automatisch erzeugt. Durch das Ausführen von „occ db:add-missing-indices“ können die fehlenden Indizes manuell hinzugefügt werden, während die Instanz weiter läuft. Nachdem die Indizes hinzugefügt wurden, sind Anfragen auf die Tabellen normalerweise schneller. Fehlende optionaler Index „mail_messages_strucanalyz_idx“ in der Tabelle „mail_messages“. Fehlende optionaler Index „mail_class_creat_idx“ in der Tabelle „mail_classifiers“. Fehlende optionaler Index „mail_acc_prov_idx“ in der Tabelle „mail_accounts“. Fehlende optionaler Index „mail_alias_accid_idx“ in der Tabelle „mail_aliases“. Fehlende optionaler Index „systag_by_objectid“ in der Tabelle „systemtag_object_mapping“. Fehlende optionaler Index „mail_messages_mb_id_uid_uidx“ in der Tabelle „mail_messages“. Fehlende optionaler Index „mail_smime_certs_uid_email_idx“ in der Tabelle „mail_smime_certificates“. Fehlende optionaler Index „mail_trusted_senders_idx“ in der Tabelle „mail_trusted_senders“. Fehlende optionaler Index „mail_coll_idx“ in der Tabelle „mail_coll_addresses“.

Das PHP OPcache-Modul ist nicht ordnungsgemäß konfiguriert. Der „OPcache interned strings“-Puffer ist fast voll. Um sicherzustellen, dass sich wiederholende Strings effektiv zwischengespeichert werden können, wird empfohlen, „opcache.interned_strings_buffer“ mit einem Wert größer als „8“ in der PHP-Konfiguration zu setzen.. Weitere Informationen finden Sie in der Dokumentation .

Die Datenbank wird für transaktionale Dateisperren verwendet. Um die Leistung zu verbessern, konfigurieren Sie bitte Memcache, falls verfügbar. Weitere Informationen finden Sie in der Dokumentation .

Es wurde kein Speichercache konfiguriert. Um die Leistung zu verbessern, konfigurieren Sie bitte Memcache, sofern verfügbar. Weitere Informationen finden Sie in der Dokumentation .

Für Ihre Installation ist keine Standard-Telefonregion festgelegt. Dies ist erforderlich, um Telefonnummern in den Profileinstellungen ohne Ländervorwahl zu überprüfen. Um Nummern ohne Ländervorwahl zuzulassen, fügen Sie bitte „default_phone_region“ mit dem entsprechenden ISO 3166-1-Code der Region zu Ihrer Konfigurationsdatei hinzu. Weitere Informationen finden Sie in der Dokumentation .

Sie haben Ihre E-Mail-Serverkonfiguration noch nicht festgelegt oder überprüft. Gehen Sie bitte zu den „Grundeinstellungen“, um diese festzulegen. Benutzen Sie anschließend den Button „E-Mail senden“ unterhalb des Formulars, um Ihre Einstellungen zu überprüfen. Weitere Informationen finden Sie in der Dokumentation .

Dieser Instanz fehlen einige empfohlene PHP-Module. Für eine verbesserte Leistung und bessere Kompatibilität wird dringend empfohlen, diese zu installieren: – gmp für WebAuthn passwortlose Anmeldung und SFTP-Speicher Weitere Informationen finden Sie in der Dokumentation .

Fehlerbeseitigung

Der erste Fehler in der Liste (… Datenverzeichnis und Ihre Dateien sind wahrscheinlich vom Internet aus erreichbar …) wird behoben, indem man die Konfigurationsdatei des Webservers mit

sudo nano /etc/apache2/apache2.conf

öffnet und den folgenden Eintrag

<Directory /var/www/>
        Options Indexes FollowSymLinks
        AllowOverride None
        Require all granted
</Directory>

sucht. Hier wird „None“ durch „All“ ersetzt. Anschließend wird der Webserver neu gestartet und überprüft, ob die Fehlermeldung tatsächlich verschwunden ist. Diese Vorgehensweise wird nun bei jedem der zu beseitigenden Fehler wiederholt. Auf diese Weise lässt sich gut nachvollziehen, wie die Liste nach und nach abgebaut wird.

sudo service apache2 restart

Beim zweiten Fehler gilt es, das Memory Limit in der php.ini von 128MB auf 512MB anzuheben. Hierzu öffnet man diese mit

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

und ändert den Wert von

memory_limit = 128M

auf.

memory_limit = 512M

Anschließend wird der Webserver erneut gestartet.

sudo service apache2 restart

Eine weitere Fehlermeldung (… Einige Header sind in Ihrer Instanz nicht richtig eingestellt …) wird behoben, indem wir den Header HSTS aktivieren.

sudo a2enmod headers

Im Anschluss geht man in den VirtualHost, wie im Artikel „Nextcloud auf dem RasPi – Teil 5“ beschrieben,

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

und entfernt das Rautezeichen vor der Zeile. Die Zeile wird also auskommentiert

Header always set Strict-Transport-Security "max-age=31536000"

und der Webserver neu gestartet.

sudo service apache2 restart

Danach wird ein weiterer Fehler (… E-Mail-Serverkonfiguration noch nicht festgelegt …) wie folgt behoben: Hierzu navigiert man in die Verwaltungseinstellungen → Verwaltung → Grundeinstellungen und ermöglicht Nextcloud, eMails zu senden. Dies ist wichtig, damit man bei einem vergessenen Passwort als Nutzer dieses zurücksetzen kann.

Diese Daten sind natürlich an die eigene E-Mail-Adresse anzupassen. Die meisten E-Mail-Anbieter geben hier entsprechende Anleitungen.

Die nächste Fehlermeldung (… keine Standard-Telefonregion festgelegt …) verschwindet, indem die Konfigurationsdatei der Nextcloud mit

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

um folgende Zeile am Ende der Auflistung erweitert wird.

'default_phone_region' => 'DE',

Die Fehlermeldung zum OPcache-Modul (… PHP OPcache-Modul ist nicht ordnungsgemäß konfiguriert …) lässt sich beseitigen, indem das Paket php-apcu installiert und die Erweiterung entsprechend konfiguriert wird.

sudo apt install php-apcu -y

Danach wird die Konfiguration der Nextcloud mit

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

erneut aufgerufen und

'memcache.local' => '\\OC\\Memcache\\APCu',

vor ’trusted_domains … eingefügt. Um das Ganze wirksam umzusetzen, öffnet man noch einmal die php.ini mit

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

und fügt diesen Block am Ende der Datei ein.

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

Abschließend wird der Apache2 wieder neu gestartet.

sudo service apache2 restart

Die Problematik zum Thema (… konfigurieren Sie bitte Memcache …) lässt sich lösen, indem man einen Redis-Server installiert, konfiguriert und diesen einbindet. Dazu werden die Pakete redis-server und php-redis installiert.

sudo apt install redis-server php-redis -y

In der redis.conf werden danach mit

sudo nano /etc/redis/redis.conf

die Zeilen

unixsocket /run/redis/redis-server.sock
        unixsocketperm 770

gesucht, auskommentiert und der Redis-Server gestartet.

sudo service redis start

Nun muss der Benutzer www-data noch zur Gruppe redis hinzugefügt werden.

sudo usermod -aG redis www-data

Um das Ganze nun abschließend umzusetzen, wird erneut die Konfiguration der Nextcloud geöffnet,

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

um folgenden Block unter der Zeile ’memcache.local … einzufügen.

'filelocking.enabled' => true,
  'memcache.locking' => '\OC\Memcache\Redis',
  'redis' => array(
     'host' => 'localhost',
     'port' => 6379,
     'timeout' => 0.0,
      ),

Nach einem erneuten Neustart des Webservers sollte nun auch diese Fehlermeldung verschwunden sein.

sudo service apache2 restart

Nun wird noch dafür gesorgt, dass HTTPS bei einer Webserveranfrage erzwungen wird. Dazu wird das Apache2-Modul rewrite installiert

sudo a2enmod rewrite

und via

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

ein weiteres Mal der VirtualHost aufgerufen und dieser Block unter der Zeile <VirtualHost *:80> eingefügt.

RewriteEngine On
        RewriteCond %{HTTPS} !=on
        RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Wieder wird der Webserver gestartet.

sudo service apache2 restart

Die Fehlermeldung zu fehlenden Modulen (… fehlen einige empfohlene PHP-Module …) wird durch die Installation des Pakets php-gmp beseitigt.

sudo apt install php-gmp -y

Nach der Installation wird der Apache2 ein weiteres Mal neu gestartet.

sudo service apache2 restart

Ein anderer Fehler (… Server hat keine konfigurierte Startzeit für das Wartungsfenster …) lässt sich beheben, indem man die Nextcloud-Konfiguration mit

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

um diese zwei Zeilen

'maintenance' => false,
  'maintenance_window_start' => 1,

unter dem letzten Block erweitert.

Um OCC-Befehle auszuführen, ist es notwendig, den Alternative PHP Cache (APC) für das Command Line Interface (CLI) zu aktivieren. Dies ist wichtig, um den nächsten Fehler zu beheben. Dazu wird die entsprechende Konfigurationsdatei geöffnet

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

und folgender Eintrag

apc.enable_cli=1

ans Ende gesetzt und der Webserver neu gestartet.

sudo service apache2 restart

Jetzt kann die Fehlermeldung (… In der Datenbank fehlen einige Indizes …) behoben werden, nachdem das Verzeichnis /var/www/html/nextcloud/ zuvor betreten wurde.

cd /var/www/html/nextcloud/

Hier führt man den entsprechenden OCC-Befehl aus, der fehlende Indizes der Nextcloud-Datenbank hinzufügt.

sudo -u www-data php occ db:add-missing-indices

Abschließend wird die Log-Datei der Nextcloud gelöscht. Danach sollte sich ein grünes Häkchen mit dem Hinweis „Alle Überprüfungen bestanden“ zeigen.

sudo -u www-data truncate /var/www/html/nextcloud/data/nextcloud.log --size 0

Fazit

Selbstverständlich ist es von entscheidender Bedeutung, dass die Nextcloud optimal funktioniert. Dieser Artikel soll dazu beitragen. Anfangs mag man durch die Vielzahl der Fehlermeldungen etwas überwältigt sein. Doch wenn alle Schritte nach und nach abgearbeitet werden, wird man am Ende mit dem grünen Häkchen belohnt. Ein regelmäßiger Blick in die Verwaltungseinstellungen gibt Aufschluss über den Fortschritt und erleichtert das Verständnis der durchgeführten Maßnahmen.

Tipp

Nach der Veröffentlichung des ersten Point Releases von Nextcloud 30 wird automatisch ein Upgrade auf diese Version vorgeschlagen. Es wird empfohlen, über den grafischen Updater auf die neuere Version umzusteigen.

Vorschau

Der nächste Artikel dieser Reihe wird sich damit befassen, das System mit „PHP-FPM“ weiter zu optimieren und die Ladezeiten zu verkürzen.

Im vorherigen Artikel habe ich beschrieben, wie man den Raspberry Pi und den Router konfiguriert, um auf die Nextcloud aus dem Internet zuzugreifen. Da die Verbindung derzeit unverschlüsselt ist, werde ich nun erläutern, wie man eine SSL-Verschlüsselung implementieren und erzwingen kann.

Installation

Zu Beginn installieren wir Certbot, um ein Let’s-Encrypt-Zertifikat zu erstellen.

sudo apt install python3-certbot-apache -y

Der Vorgang wird wie folgt gestartet. Dabei ist es wichtig, die korrekte DynDNS-Adresse (dnsHome.de) anzugeben. Zudem muss eine eMail-Adresse hinterlegt werden.

sudo certbot --apache

Nachdem das Zertifikat ausgestellt wurde, folgt die Konfiguration des VirtualHost. Diesen erstellt man mit dem folgenden Befehl und fügt den unten aufgeführten Block in die Datei /etc/apache2/sites-available/raspi.conf ein.

Dabei müssen die Pfade für das Zertifikat und der Servername an die eigene DynDNS angepasst werden.

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

<VirtualHost *:80>
        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html/nextcloud
        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
<IfModule mod_ssl.c>
<VirtualHost *:443>
        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html/nextcloud
#        Header always set Strict-Transport-Security "max-age=31536000"
#        Header append X-FRAME-OPTIONS "SAMEORIGIN"
        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
SSLCertificateFile /etc/letsencrypt/live/meinecloud.dnshome.de/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/meinecloud.dnshome.de/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
ServerName meinecloud.dnshome.de
</VirtualHost>
</IfModule>

Nun werden die nicht mehr benötigten Vorgaben der VirtualHosts deaktiviert, der neue VirtualHost aktiviert und das SSL-Modul des Apache2 eingeschaltet.

sudo a2dissite 000-default.conf
sudo a2dissite 000-default-le-ssl.conf
sudo a2ensite raspi.conf
sudo a2enmod ssl

Danach wird der Webserver neu gestartet.

sudo service apache2 restart

HTTPS erzwingen

Um Verbindungen über HTTPS zu erzwingen, muss das Apache2-Modul „rewrite“ aktiviert werden.

sudo a2enmod rewrite

Danach öffnen wir den VirtualHost erneut

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

und fügen die folgenden drei Rewrite-Zeilen hinzu.

<VirtualHost *:80>
    RewriteEngine On
    RewriteCond %{HTTPS} !=on
    RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
...

Anschließend wird der Webserver erneut neu gestartet.

sudo service apache2 restart

Regelmäßige Erneuerung des SSL-Zertifikats

Ein Let’s Encrypt-Zertifikat sollte monatlich erneuert werden, um sicherzustellen, dass die verschlüsselte Kommunikation auf Ihrer Website
kontinuierlich geschützt ist. Die regelmäßige Erneuerung gewährleistet, dass das Zertifikat gültig bleibt und Ihre Websitebesucher vor potenziellen Sicherheitsrisiken wie Man-in-the-Middle-Angriffen geschützt werden.

Dafür navigieren wir zum Home-Verzeichnis

cd ~/

und erstellen die Datei zertifikat.sh.

nano zertifikat.sh

Dort wird der folgende Inhalt eingetragen.

#!/bin/bash
certbot certonly --renew-by-default --apache --rsa-key-size 4096 -d meinecloud.dnshome.de
/etc/init.d/apache2 restart

Auch hier ist der Servername an die eigene DynDNS anzupassen.

Nun wird das erstellte Skript ausführbar gemacht

sudo chmod +x zertifikat.sh

und ein Cronjob erstellt,

sudo nano /etc/crontab

der das Script jeweils am 1. jeden Monats um 2:30 Uhr ausführt. Dabei ist folgende Zeile am Ende hinzuzufügen

30 2 1 * *      root    /home/radiouser/zertifikat.sh >/home/radiouser/zertifikat.log 2>&1

und der Cronjob neu zu starten.

sudo /etc/init.d/cron restart

Vorschau

Im nächsten Teil zeige ich, wie man die aufgelaufenen Fehler nach der Erstinstallation der Nextcloud beheben kann.

Möchte man den Hashwert eines Ubuntu-Images mit Hilfe der Prüfsumme überprüfen, geht man wie folgt vor.

Zuerst wird das Ubuntu-Image und die dazugehörige SHA256SUMS-Datei herunter geladen. Beide Dateien sollten sich im gleichen Verzeichnis befinden.

Prüfsummencheck

Danach führt man folgenden Befehl in diesem Verzeichnis aus, um die Prüfziffern zu checken.

sha256sum -c SHA256SUMS 2>&1 | grep OK

Wenn alles in Ordnung ist wird dies mit „OK“ bestätigt.

Wozu das Ganze?

Diese Art von Integritätsprüfung stellt sicher, dass das ISO-Image korrekt heruntergeladen wurde und dass die lokale Datei eine genaue Kopie der auf den Download-Servern gespeicherten Datei ist. Ein Fehler beim Download könnte zu einer beschädigten Datei führen, die bei der Installation unerwartete Probleme verursachen kann.

Weitere Beispiele

Das Ganze lässt sich natürlich auch auf andere Betriebssystem-Images anwenden.

Um die auf dem Raspberry Pi installierte Nextcloud nun von außen über das Internet zu erreichen, ist es nötig, eine Webadresse über die öffentliche IP-Adresse mit der, wie im Artikel „Nextcloud auf dem RasPi – Teil 3“ beschriebenen, internen festen IP-Adresse des Raspberry Pi zu verknüpfen. Hierbei greife ich auf einen DynDNS-Dienst zurück. Ich zeige im folgenden Beitrag die Vorgehensweise mit einem bestehenden Account von dnsHome.de.

Das alles realisiert man über ein sogenanntes Portforwarding (Portfreigabe). Hierzu weist man den Router an, Anfragen über alle benötigten Ports zur internen IP des Raspberry Pi durchzustellen. In meinem Fall sind das die Ports 443, 80, 5900, 5349 und 43434. Wie man das Ganze umsetzt, zeigt der Screenshot meiner FRITZ!Box. Diese Einstellungen sind die Grundvoraussetzungen für die Erreichbarkeit der Nextcloud aus dem Internet.

Portfreigabe

Ermittlung der öffentlichen IP-Adresse

Über den Befehl

curl ifconfig.me

erhält man die öffentliche IP-Adresse, über die der Raspberry Pi nun aus dem Internet erreichbar ist. Ein anschließender Test sollte ungefähr so aussehen.

Nun wäre es einfach, diese IP-Adresse mit einer Domain zu verknüpfen. Die wenigsten Nutzer verfügen jedoch über eine feste öffentliche IP-Adresse. Aus diesem Grund greift man hier auf einen DynDNS-Anbieter zurück, da sich aufgrund von Zwangstrennungen durch den Provider die öffentliche IP-Adresse bis zu einmal am Tag ändern kann.

Damit ein DynDNS-Anbieter eine Webadresse dauerhaft mit dem Router verknüpfen kann, muss dieser regelmäßig Informationen über die aktuelle öffentliche IP-Adresse erhalten. Dies kann über eine FRITZ!Box realisiert werden oder durch die Verwendung des ddclient, der auf dem Raspberry Pi installiert wird und so den Kontakt zum DynDNS-Anbieter aufrechterhält. Bei einer Änderung der IP wird diese wieder der DynDNS-Adresse zugewiesen.

Als DynDNS-Anbieter empfehle ich den Dienst dnsHome.de (ein Account ist vorher einzurichten).

Installation ddclient

Zuerst wird ddclient auf dem Raspberry Pi installiert.

sudo apt install ddclient -y

Während der Installation möchte der Client einen DynDNS-Anbieter einrichten. Da dnsHome.de dem ddclient nicht bekannt ist, empfehle ich die Einrichtung einfach durchzuklicken. Im Anschluss öffnet man die Konfigurationsdatei von ddclient

sudo nano /etc/ddclient.conf

und ersetzt den gesamten Inhalt mit folgendem Inhalt.

# Configuration file for ddclient generated by debconf
#
# /etc/ddclient.conf
protocol=dyndns2
ssl=yes
daemon=3600
use=web, web=ip.dnshome.de
server=www.dnshome.de
login=meinecloud.dnshome.de
password=geheim
datenboxx.dnshome.de

Bei „login“ und „password“ sollten natürlich die eigenen Zugangsdaten eingetragen werden, die zuvor bei dnsHome.de vergeben wurden.

Start ddclient

Sobald alles konfiguriert ist, kann der Client gestartet werden.

sudo ddclient start

Um sicherzustellen, dass die Nextcloud einen Login-Bildschirm über die DynDNS-Adresse bereitstellt, ist folgender Eintrag in der Datei /var/www/html/nextcloud/config/config.php erforderlich.

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

Die DynDNS-Adresse muss nun als vertrauenswürdige Domain eingetragen werden.

'trusted_domains' => 
  array (
    0 => '192.168.88.159',
    1 => 'meinecloud.dnshome.de',

Sobald dies erledigt ist, kann die Nextcloud im Browser über http://meinecloud.dnshome.de erreicht werden.

Vorschau

Im nächsten Teil zeige ich, wie man ein SSL-Zertifikat erstellt und dauerhaft eine verschlüsselte Verbindung zur Nextcloud sicherstellt.

Das Zuweisen einer statischen IP-Adresse an einen Raspberry Pi ist sinnvoll, um sicherzustellen, dass das Gerät immer unter derselben Adresse im Netzwerk erreichbar ist. Dies ist besonders nützlich für bestimmte Anwendungen wie z.B. Nextcloud, für die eine konstante IP-Adresse wichtig ist.

Festlegen einer statischen internen IP-Adresse

Eine statische lokale IP setzt man wie folgt. Zuerst installiert man dhcpcd.

sudo apt install dhcpcd -y

und trägt dann folgenden Block mit

sudo nano /etc/dhcpcd.conf

am Ende der /etc/dhcpcd.conf ein. Hierbei habe ich mich für die interne IP 192.168.178.136. Dies ist natürlich abhängig vom Adressbereich des eigenen Netzwerks. Auch die IP des Routers ist entsprechend anzupassen.

profile static_eth0
static ip_address=192.168.178.23/24
static routers=192.168.178.1
static domain_name_servers=192.168.178.1

Zum Schluss wird der Dienst dhcpcd neu gestartet.

sudo service dhcpcd restart

Vorschau

Im nächsten Teil zeige ich, was nötig ist, die Nextcloud über das Internet erreichbar zu machen.