Normale Ansicht

Received before yesterday

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.

Ansible Collection tronde.opencloud

05. Mai 2025 um 07:20

In diesem Beitrag berichte ich über mein Wochenend-Projekt „Ansible Collection tronde.opencloud“, welche ihr seit dem 4. Mai 2025 in Version 1.0.0 auf Ansible Galaxy sowie bei Codeberg.org findet.

Ich habe die Collection mit den folgenden Zielen erstellt:

  • Deployment von OpenCloud mittels Ansible in einer rootless Podman-Umgebung
  • Backup der OpenCloud und Speicherung des Backups auf dem Ansible Control Node
  • Restore der OpenCloud aus einem zuvor erzeugten Backup

Aktuell läuft eine OpenCloud-Instanz auf einem meiner Server unter Debian Bookworm.

Nicht so schnell! Was sind Ansible, OpenCloud und Podman?

Derjenige, dem diese Begriffe bereits geläufig sind, kann direkt zum Abschnitt Motivation springen. Für alle anderen gibt es hier eine knappe Erklärung mit Verweisen zu weiteren Informationen, um sich mit der Materie vertraut zu machen.

Ansible

Ansible hat sich zu einem beliebten Schweizer Taschenmesser für Automation, Konfigurations-Management, Deployment und Orchestrierung entwickelt. Über folgende Links findet ihr reichlich informationen dazu:

OpenCloud

OpenCloud ist die Filesharing & Kollaborations-Lösung der Heinlein Gruppe.

Durch intelligentes Datei-Management und eine starke Open Source-Community werden Dateien zu wertvollen Ressourcen – effektiv strukturiert und langfristig nutzbar.

Quelle: https://opencloud.eu/de

Links zu weiteren Informationen:

Podman

Podman ist ein Werkzeug zur Erstellung von Linux-Containern und der Verwaltung des gesamten Container-Lebenszyklus. Links mit Informationen zu Podman:

Motivation

Ich betreibe und nutze privat eine Nextcloud, um Dateien über mehrere Geräte zu synchronisieren, mit anderen zu teilen und um Backups verschiedener Geräte und Dienste darin abzulegen. Dazu betreibe ich neben dem Reverse Proxy (NGINX) einen Container mit einer MySQL-Datenbank und einen Anwendungscontainer mit Nextcloud selbst. Nextcloud verfügt über ein reichhaltiges Plugin-Ökosystem zur Erweiterung der Funktionalität, welche ich persönlich allerdings nicht benötige.

OpenCloud ist wie Nextcloud ein Fork von OwnCloud. Siehe dazu den Bericht: Opencloud forkt Owncloud — neue Wendung bei den freien Speichercloud-Versionen im Linux-Magazin vom 22. Januar 2025.

Mir gefällt, dass OpenCloud ganz ohne Datenbank auskommt und sich auf die Synchronisation und das Teilen von Daten fokussiert. Dies entspricht genau meinem Anwendungsfall. Wenn ich dadurch einen Dienst weniger betreiben kann (MySQL), ist das umso besser.

Nur passt der gewählte Technologie-Stack nicht zu meiner persönlichen Vorliebe. Während OpenCloud auf die Verwendung von Docker Compose mit Traefik als Reverse Proxy setzt, bevorzuge ich, Container mit Podman zu betreiben und verwende (noch) NGINX als Reverse Proxy.

Um OpenCloud etwas kennenzulernen, habe ich beschlossen, analog zu meiner Ansible Collection tronde.nextcloud eine Collection tronde.opencloud zu erstellen, um OpenCloud deployen und verwalten zu können.

Ob sich der Aufwand lohnt, werde ich mit der Zeit sehen. Wenn es mir zuviel wird oder ich den Gefallen daran verliere, werde ich dieses Wochenendprojekt wieder einstellen bzw. gern in die Hände motivierter Menschen geben, die es weiterführen möchten.

Informationen zur Collection

Das Wichtigste zu dieser Collection habe ich bereits zu Beginn dieses Textes geschrieben. Neben den für Ansible Collections und Roles typischen README.md-Dateien habe ich auch ein paar Zeilen Dokumentation erstellt:

Die Collection steht unter einer freien Lizenz und ich gebe keinerlei Garantie oder Gewähr, dass euch deren Verwendung nicht direkt in den Untergang führt. ;-)

Die Collection kann (noch) nicht viel. Das Wenige scheint jedoch robust zu funktionieren. Wenn ihr neugierig seid, probiert sie gerne aus. Auch euer konstruktives Feedback ist mir stets willkommen.

Für mich ist dies ein Wochenend-Projekt, das mit etlichen anderen Themen um meine Zeit konkurriert. Erwartet daher keine schnellen Entwicklungsfortschritte. Wenn ihr gern daran mitwirken möchtet, bin ich dafür offen. Werft einen Blick in den kurzen Contribution Guide und legt los. Falls ihr Fragen habt oder euch mit mir über die Collection austauschen möchtet, könnt ihr

  • eure Frage als Issue mit dem Label „Question“ im Repository stellen oder
  • in den Matrix-Raum #My-IT-Brain posten.

Erster Eindruck von OpenCloud

Das noch recht junge Projekt macht einen aufgeräumten Eindruck. Die Benutzeroberfläche ist nicht überladen und ich finde mich schnell darin zurecht. Das Entwicklerteam antwortet bereitwillig auf Fragen und kümmert sich in angemessener Zeit um Issues. Dies ist zumindest mein subjektiver Eindruck.

Einziger Wermudstropfen ist wie so oft die Dokumentation, welche mit der Entwicklung offenbar nicht Schritt halten kann. Diese lässt leider noch viele Fragen offen, welche über GitHub Discussions oder Suche im Quelltext geklärt werden können/müssen. Ich empfinde dies etwas ermüdend und es drückt die Motivation.

Nun werde ich OpenCloud erstmal einige Zeit nutzen und ein paar Versions-Upgrades hinter mich bringen. Anschließend werde ich dann einen Meinungsartikel schreiben, wie es mir gefällt.

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.

❌