antiX ist eine kleine, aber feine Distribution auf der Basis von Debian Stable, die seit 2007 konsequent entwickelt wird. Gerade erschien antiX 23.2.

Quelle

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.

Das bereits tot geglaubte PineNote von Pine64 mit E-Ink-Display scheint nun doch noch auf den Markt zu kommen, nachdem ein Debian-basiertes Betriebssystem einsatzbereit ist.

Quelle

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.

Das Debian-Projekt hat die Veröffentlichung von Debian 12.7 “Bookworm” bekannt gegeben. Das aktualisierte ISO Installationsmedium für das aktuelle Debian GNU/Linux 12 „Bookworm“ Betriebssystem steht zum Download zur Verfügbung. Debian 12.7 wurde nur zwei Monate nach Debian 12.6 veröffentlicht und stellt seltsamerweise das sechste Point-Release von Debian Bookworm dar. Dabei handelt es sich um das sechste, […]

Der Beitrag Debian 12.7 „Bookworm“ veröffentlicht erschien zuerst auf fosstopia.

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.

Um später alle Vorzüge, wie Nextcloud Office, von Nextcloud Hub nutzen zu können, empfehle ich den Document Server Collabora Online – Built-in CODE Server (ARM64) auf dem Raspberry Pi via Terminal beizeiten zu installieren, da es über die grafische Oberfläche i.d.R. zu einem Timeout kommt. Wie das Ganze funktioniert erläutere ich in diesem Artikel.

Nextcloud Office

Nextcloud Office ist eine in Nextcloud integrierte Office-Lösung, die es ermöglicht, Dokumente, Tabellen und Präsentationen direkt im Browser zu erstellen und gemeinsam zu bearbeiten. Basierend auf Open-Source-Technologien wie Collabora Online unterstützt es gängige Dateiformate wie DOCX und ODT. Die Echtzeit-Zusammenarbeit und vollständige Integration in die Nextcloud-Plattform ermöglicht eine sichere und effiziente Teamarbeit, bei der alle Daten unter eigener Kontrolle bleiben. Ideal für Unternehmen, die Wert auf Datenschutz und Datensouveränität legen.

Installation

cd /var/www/html/nextcloud
sudo -u www-data php -d memory_limit=512M ./occ app:install richdocumentscode_arm64

Aktivierung

Abschließend wird die Nextcloud Office-App in den Nextcloud Hub-Paketen für die spätere Nutzung
aktiviert.

Anmerkung

Dies funktioniert nur auf 64-Bit-Systemen!

Vorschau

Im nächsten Teil zeige ich, wie man dem Raspberry PI eine feste interne IP-Adresse im heimischen Netzwerk zuweist.

Das Debian-Archiv enthält aufgrund seiner Größe zu jedem Zeitpunkt Pakete, die veraltet oder schon länger unbetreut sind. Eine neue Initiative will hier Abhilfe schaffen.

Quelle

Mit Debian 12.7 haben die Entwickler das letzte stable Release für Debian 12 alias Bookworm veröffentlicht.

Am Wochenende hat Debian seine stabile Veröffentlichung auf Version 12.7 angehoben. Gleichzeitig erhielt der Vorgänger eine letzte Aktualisierung auf Version 11.11.

Quelle

Das Debian-Projekt hat die Veröffentlichung von Debian 12.7 “Bookworm” bekannt gegeben. Das aktualisierte ISO Installationsmedium für das aktuelle Debian GNU/Linux 12 „Bookworm“ Betriebssystem steht zum Download zur Verfügbung. Debian 12.7 wurde nur zwei Monate nach Debian 12.6 veröffentlicht und stellt seltsamerweise das sechste Point-Release von Debian Bookworm dar. Dabei handelt es sich um das sechste, […]

Der Beitrag Debian 12.7 „Bookworm“ veröffentlicht erschien zuerst auf fosstopia.

Der Dienst FAI.me erlaubt das Erstellen von Debian-Images zur Installation in verschiedenen Umgebungen. Neu hinzugekommen ist die Möglichkeit, auch Live-Medien zu erstellen.

Quelle

Debian, eine der angesehensten und am weitesten verbreiteten Linux-Distributionen, hat Version 11, mit dem Codenamen “Bullseye”, ab dem 15. August 2024 in die Langzeitunterstützungsphase (LTS) überführt. Dieser Übergang erfolgt genau drei Jahre nach der ursprünglichen Veröffentlichung von Bullseye. Die Pflege der verschiedenen Debian-Versionen folgt einem strukturierten Ansatz um Stabilität und Sicherheit für alle Nutzer zu […]

Der Beitrag Debian 11 Bullseye ab sofort in der LTS Support Phase erschien zuerst auf fosstopia.

Vor einiger Zeit habe ich beschlossen eine Serie von Artikeln zum Thema Nextcloud auf dem RasPi auf meinem Blog intux.de zu veröffentlichen. Ziel ist es, eine eigene Cloud zu erstellen, die produktiv nutzbar ist. Diese soll später über das Internet erreichbar sein.

Was benötigt man dafür?

Um langfristig sicherzustellen, dass alles funktioniert, empfehle ich, die neueste Hardware zu verwenden, wie den Raspberry Pi 5. Allerdings würde hier auch ein Einplatinencomputer der vorherigen Generation mit 4GB RAM ausreichen.

Vorbereitung

Diese kleine Anleitung soll helfen, das Projekt Nextcloud auf dem Raspberry Pi nicht nur umzusetzen, sondern auch besser zu verstehen. Der Schwerpunkt liegt dabei auf der Software und der Konfiguration. So können später auftretende Fehler besser lokalisiert und abgestellt werden.

Der Raspberry Pi wird als LAMP-Server (Linux, Apache, MariaDB, PHP) dienen, die Nextcloud zu betreiben. Wie man diese vier Bausteine aufsetzt, zeige ich im folgenden Abschnitt.

Installation

Der erste Baustein der installiert wird, ist Linux. Hierbei handelt es sich um das Betriebssystem Raspberry Pi OS. Dieses spielt man ganz einfach mit dem Raspberry Pi Imager auf die MicroSD.

Hier wählt man (siehe Screenshot) das zu installierende Betriebssystem aus. In diesem Fall ist es das Raspberry Pi OS (64-bit). Im Imager können vorab einige Einstellungen vorgenommen werden. Ich werde in dieser Anleitung einfache Bezeichnungen und Passwörter verwenden. Diese können während der Installation entsprechend frei angepasst werden!

Über das Zahnrad des Imagers lässt sich das Raspberry Pi OS vorkonfigurieren. Hier trägt man für den Anfang die entsprechenden Daten ein:

Danach wählt man am PC/Notebook die MicroSD aus, auf die geschrieben werden soll.

Zum Schluss werden die Daten auf die MicroSD geflasht. Ist dies erledigt, kann die Karte ausgeworfen und in den vorbereiteten Raspbberry Pi (Kühlkörper, Gehäuse, Lüfter) geschoben werden. Dieser wird dann via LAN-Kabel mit dem heimischen Router verbunden und über das Netzteil mit Strom versorgt.

Natürlich könnte der RasPi auch via WLAN mit dem Router kommunizieren. Hiervon rate ich jedoch ab, da über die Funkverbindung oft nicht die volle Geschwindigkeit einer Ethernet-Verbindung genutzt werden kann. Weiterhin kann es zu Verbindungsabbrüchen bzw. -lücken kommen.

Nachdem der Raspberry Pi mit Strom versorgt wird, startet dieser. Ist der Raspberry Pi hochgefahren, kann dieser via arp-scan vom PC/Notebook im Netzwerk lokalisiert werden. In meinem Fall hat er die IP-Adresse 192.168.178.136.

sudo apt install arp-scan
sudo arp-scan -l

Zugriff auf den Pi erhalte ich nun via zuvor im Imager aktiviertem SSH-Zugang.

ssh Benutzer@IP-Adresse

Ist man eingeloggt, empfiehlt es sich die Lokalisierung über raspi-config auf deutsch (siehe Screenshots) umzustellen. Damit wird Datum und Uhrzeit des Servers an die europäische Zeitzone (Berlin) angepasst.

sudo raspi-config

Nun wählt man de_DE.UTF-8 UTF-8 aus und deaktiviert en_GB.UTF-8 UTF-8. Die deutsche Lokalisierung wird abschließend noch bestätigt.

Danach wird der Raspberry Pi mit

sudo reboot

neu gestartet. Ist dies geschehen, empfiehlt es sich, das OS zu aktualisieren.

sudo apt update && sudo apt upgrade -y

Danach werden die noch fehlenden 3 Bausteine (Apache 2, MariaDB und PHP) nachinstalliert.

sudo apt install apache2 mariadb-server php php-mysql php-zip php-gd php-json php-curl php-mbstring php-intl php-imagick php-xml php-dom php-bcmath -y

Nachdem die Installation durchgelaufen ist, kann man zum Testen den Webserver Apache via Browser über die Web-Adresse http://ip erreichen.

Anschließend wird die von der Nextcloud benötigte Datenbank installiert. Zuerst wird jedoch die mysql_secure_installation durchgeführt. Ich empfehle hier das Ganze gemäß meinen Empfehlungen (Enter, n, n, y, y, y, y) zu durchlaufen. Hierbei wird für den MariaDB-Server kein separates Root-Passwort vergeben, der anonyme User wird gelöscht, die Remote-Root-Anmeldung wird verboten, die Test-DB wird gelöscht und die Änderungen ausgeführt.

sudo mysql_secure_installation

Nachdem dieser Schritt durchgeführt wurde, kann über folgenden Befehl die Datenbank erstellt werden.

sudo mysql -u root -p

In meinem Fall heißen die Datenbank und der Benutzer „nextcloud“. Die Datenbank liegt dann auf dem „localhost“.

> CREATE DATABASE nextcloud;
> CREATE USER 'nextcloud'@'localhost' IDENTIFIED BY 'geheim';
> GRANT ALL ON nextcloud.* TO 'nextcloud'@'localhost';
> FLUSH PRIVILEGES;
> \q

Im Nachgang wechselt man in das Verzeichnis /var/www/html, wo die Nextcloud installiert wird. Die letzte Version wird vom Entwickler herunter geladen und entpackt. Danach wird die nicht mehr benötigte Zip-Datei wieder gelöscht und die Rechte der Dateien an den Benutzer www-data übertragen.

cd /var/www/html
sudo wget https://download.nextcloud.com/server/releases/latest.zip
sudo unzip *.zip
sudo rm *.zip
sudo chown -R www-data:www-data /var/www/html/nextcloud

Nun ist die Nextcloud über http://ip/nextcloud (http://102.168.178.136/nextcloud) erreichbar. Man legt den Admin fest und trägt die Daten der zuvor erstellten MariaDB-Datenbank in die Eingabemaske ein. Hat das alles geklappt, dann dauert die Einrichtung ein paar Minuten und die Nextcloud steht bereit zum ersten Login des neuen Administrators.

Vorschau

Im nächsten Teil zeige ich, wie man die App Collabora Online – Built-in CODE Server (ARM64) in der Nextcloud via Terminal installiert.

Viel Spaß!

Wayland 1.23.0-1 verhindert den Start einer Wayland-Sitzung mit Plasma 5. Die Version wird derzeit in Debian Unstable und siduction verteilt. Auch Ubuntu könnte bald betroffen sein.

Quelle

cURL wird oft unbedacht eingesetzt, indem darauf basierende Befehle auf GitHub und anderswo kopiert und ausgeführt werden. Um dieses Sicherheitsrisiko abzuschwächen, liefert Debian cURL jetzt mit HTTP/3 aus.

Quelle

Kurz notiert: Debian 10 mit dem Codenamen "buster" erreicht heute das End of Life. Die Unterstützung wurde bis 2022 vom Debian-Team bereitgestellt und dann bis zum heutigen Tage durch das LTS-Team sichergestellt. Damit wurde Debian 10 knapp fünf Jahre durchgängig unterstützt.

Debian 10 wurde am 6. Juli 2019 und somit vor knapp fünf Jahren veröffentlicht. Ausgeliefert wurde das Betriebssystem mit dem Linux-Kernel 4.19. Der letzte Point-Release erfolgte am 10. September 2022, damit endete auch der klassische Security-Support.

Anschließend hat das LTS-Team die Unterstützung am 1. August 2022 mit einer Teilmenge von Architekturen (amd64, i386, amd64, armhf) übernommen, damit Nutzer wichtige Sicherheitsupdates noch erhalten und die Gelegenheit haben, auf den Folge-Release umzustellen. Diese Unterstützung läuft am heutigen Tage aus.

Es ist somit an der Zeit, auf Debian 11 mit dem Codenamen "bullseye" umzustellen. Die Migrationsanleitung ist in den Release Notes für Debian 11 zu finden. Hier wird auch erläutert, mit welchen Breaking Changes zu rechnen ist. Wie üblich, lässt sich der Release über die APT-Konfiguration anheben, gefolgt von einem Upgrade über APT. Die wichtigste Änderung dabei ist, dass das Security-Archiv ein neues Layout hat. Ich habe einige Systeme schon aktualisiert, dabei gab es bei mir keine Probleme. Das sollte auch bei anderen Systemen keine Schwierigkeiten bereiten, wenn sich an den offiziellen Debian-Paketquellen orientiert wird. Die Backports sollte man aber kontrollieren, wenn z. B. ein Backports-Kernel genutzt wurde, um WireGuard schon mit Debian 10 nutzen zu können (erst Debian 11 hat eine Kernelversion, in der WireGuard integriert ist).

Aktuell werden vom Debian-Team die Versionen 11 (bullseye) und 12 (bookworm) als Hauptversionen gepflegt. Das LTS-Team ist eine Gruppe von Freiwilligen, die sich zum Ziel gesetzt hat, eine fünfjährige Unterstützung für Debian-Versionen sicherzustellen. Wer eine zehnjährige Unterstützung benötigt, kann auf entgeltliche ELTS-Angebote wie z. B. von Freexian zurückgreifen.

Am Wochenende wurden Debian GNU/Linux 12.6 und Debian GNU/Linux 11.10 freigegeben. Wegen der xz Backdoor erschien Debian 12.6 fast drei Monate später als geplant..

Quelle

Vor über vier Jahren hatte ich mich schon einmal mit dieser Thematik im Artikel „TURN-Server für Nextcloud Talk“ auseinandergesetzt. Über die Jahre hinweg hat sich jedoch einiges geändert und ich konnte mein Wissen ausbauen. Aus diesem Grund möchte ich nun meine aktuellsten Erkenntnisse noch einmal zusammenhängend präsentieren.

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

Bei meinen ersten Versuchen auf dem Raspberry Pi fiel auf, dass der Service des TURN-Servers schneller startet als das gesamte System, was einen Betrieb unmöglich machte. Diese Problematik konnte ich wie im Artikel „coTurn zeitverzögert auf Raspberry Pi starten“ beschrieben, lösen. Leider überstand aber dieser Eingriff kein Systemupgrade. Durch einen sehr hilfreichen Kommentar von Matthias, kann ich nun eine bessere Lösung aufzeigen.

Es wird mit

sudo systemctl edit coturn.service

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.

Seit Nextcloud Hub 8 (29.0.0) ist ChatGPT nicht mehr über den Picker der Nextcloud zu erreichen. Dieser Umstand kann Nerven kosten, wenn OpenAI’s KI-Dienst hin und wieder genutzt wird und man plötzlich feststellt, dass dieser nicht mehr funktioniert. So ging es mir, als ich den in die Nextcloud integrierten KI-Assistenten einem kleinen Publikum vorstellen wollte. Da das neueste Release 29.0.0 noch recht frisch ist, findet man derzeit wenig Hinweise, wie man ChatGPT weiter nutzen kann.

Einrichtung

Dies hat mich nun dazu bewogen einen kleinen Artikel hierzu zu schreiben. Grundvoraussetzung ist jedoch ein Account beim US-amerikanischen Softwareunternehmen OpenAI bei dem ein API-Key erstellt wird.

Des weiteren müssen in der Nextcloud die Apps OpenAI and LocalAI integration und Nextcloud Assistant hinzugefügt und aktiviert werden.

Im Anschluss wird der API-Key, wie im Screenshot zu sehen ist, in der App OpenAI and LocalAI integration hinterlegt.

Nun kann man über den neuen Nextcloud-Assistent das KI-Tool nutzen.

Viel Spaß!

Da ich einiges an Zeit in meine auf dem Raspberry Pi 4 laufende Nextcloud investiert habe, wäre es schade, für das aktuelle Raspberry Pi OS 12, alles noch einmal aufsetzen und konfigurieren zu müssen. Obwohl die Entwickler des Betriebssystems von einem Upgrade generell abraten, habe ich mich auf die Suche nach einer guten und funktionierenden Anleitung gemacht und bin auf den vielversprechenden Artikel „Raspberry Pi OS – Update von Bullseye (11) auf Bookworm (12)“ von Sascha Syring gestoßen.

Um das Ganze ausgiebig zu testen, habe ich das Upgrade zuerst auf einem Raspberry Pi 4 durchgeführt, auf dem ein Mumble-Server läuft, den unsere Community produktiv zum Erfahrungsaustausch nutzt. Nachdem dies alles problemlos funktioniert hat, habe ich mich an meinen Nextcloud-RasPi gewagt. Was es weiter zu beachten gab, darauf gehe ich am Ende des Artikels noch ein.

Systemupgrade

Bevor es los geht muss das System auf den aktuellsten Stand unter Raspberry Pi OS 11 Bullseye gebracht werden. Hierzu führt man Folgendes aus:

sudo apt update && sudo apt upgrade && sudo apt dist-upgrade

Paketquellen

Danach werden die Paketquellen auf das neue System Bookworm angepasst. Hierzu öffnet man die /etc/apt/sources.list

sudo nano /etc/apt/sources.list

und kommentiert alle aktiven Quellen, indem man vor jede aktive Zeile eine Raute „#“ setzt. Danach fügt man die drei Zeilen

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

am Anfang ein und speichert die Datei mit Ctr + o ab und verlässt dann den Editor mit Ctr + x.

Das Gleiche Spiel wiederholt man mit den zusätzlichen Paketquellen.

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

Hier wird nun folgende Zeile an den Anfang gesetzt:

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

Die Datei wird mit Ctr + o gespeichert und der Editor mit Ctr + x verlassen. Ist dies geschehen, können die Paketquellen neu eingelesen werden.

sudo apt update

Bootpartition

Nun kommt der kniffligste Teil. Die Bootpartition muss an die neuen Gegebenheiten angepasst werden. Dazu wird die alte Boot-Partition ausgehängt.

sudo umount /boot

Dann wird das neue Verzeichnis /boot/firmware erstellt.

sudo mkdir /boot/firmware

Jetzt bearbeitet man die Partitionstabelle:

sudo nano /etc/fstab

Hier wird der Eintrag der Bootpartition entsprechend eingetragen. Bei mir sieht das so aus:

Die Datei wird wieder mit Ctr + o gespeichert und der Editor mit Ctr + x verlassen. Damit die Änderungen wirksam werden, wird systemd neu geladen

sudo systemctl daemon-reload

und die neue Boot-Partition gemountet.

sudo mount /boot/firmware

Bootloader und Kernel

Im Nachgang werden die aktuelle Firmware und der aktuelle Kernel für das Raspberry Pi OS 12 (Bookworm) installiert

sudo apt install raspi-firmware linux-image-rpi-v8

und der alte Bootloader und Linux-Kernel entfernt.

sudo apt remove raspberrypi-kernel raspberrypi-bootloader

Ist dies geschehen, müssen die Paketquellen nochmalig mit

sudo apt update

eingelesen werden.

Upgrade

Nun kann das eigentlich Upgrade durchgeführt werden. Hierbei stoppt der Vorgang bei den wichtigsten Konfigurationsdateien. Diese werden in der Regel alle beibehalten.

sudo apt full-upgrade

System aufräumen

Nun wird das System noch aufgeräumt.

sudo apt autoremove
sudo apt clean

Neustart

Nach dem Neustart

sudo reboot now

sollte nun das aktuelle Raspberry Pi OS 12 laufen. Das installierte Betriebssystem lässt man sich mit

cat /etc/os-release

anzeigen.

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

Mit

uname -a

kann man nun den aktuellen Kernel checken. Meine Ausgabe sieht wie folgt aus:

Linux nextcloud 6.6.20+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.6.20-1+rpt1 (2024-03-07) aarch64 GNU/Linux

(„nextcloud“ in dieser Zeile ist der Hostname)

Abschließend sei darauf hingewiesen, dass das Upgrade einige Gefahren in sich birgt. Bitte vorher unbedingt an ein Backup denken, was im Bedarfsfall wieder eingespielt werden kann!

Noch zu erwähnen

Eingangs des Artikels hatte ich erwähnt, dass es Weiteres zu beachten gibt. Durch das Upgrade wurden die Einstellungen des Dienstes zu meinem Turn-Server zurück gesetzt. Ein funktionierender Turn-Server ist wichtig, um reibungslosen Verlauf in Videokonferenzen zu ermöglichen.

Wer also wie ich eine Nextcloud auf dem Raspberry Pi installiert hat und bisher meinen Anleitungen gefolgt ist, muss den zeitverzögerten Start des Turnservers, wie im Artikel „coTurn zeitverzögert auf Raspberry Pi starten“ beschrieben, wieder neu konfigurieren. Dazu editiert man die Datei /lib/systemd/system/coturn.service:

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

Nun fügt man den folgenden Eintrag unter [Service] ein und speichert die Änderung mit Ctlr + o.

ExecStartPre=/bin/sleep 30

Den Editor verlässt man dann wieder mit Ctrl + x. Durch den Eintrag wird nun eine Verzögerung von 30 Sekunden erzwungen. Mit 

sudo service coturn restart

wird der Turnserver zeitverzögert neu gestartet. jetzt arbeitet coTURN nach dem nächsten Reboot des Raspberry Pi wie gewünscht.

Viel Erfolg!

Bei Technik-affinen Leuten wie die Leser dieses Blogs dürfte sich bereits wie ein Lauffeuer verbreitet habe, dass das weit verbreitete Paket xz-utils (Datenkompressions-Tools), beginnend mit den Versionen 5.6.0 bis 5.6.1, eine Backdoor hat (CVE-2024-3094). Diese Hintertür könnte es einem böswilligen Akteur ermöglichen, die sshd-Authentifizierung zu kompromittieren. Damit könnte sie oder er unbefugten Fernzugriff auf das gesamte System erhalten. Die gute Nachricht ist, dass aktuelle LTS-Versionen von Ubuntu nicht betroffen sind. Das gilt auch für Linux Mint und die stabile Version […]

Der Beitrag Kali von xz-utils Backdoor betroffen, Debian / Ubuntu nicht ist von bitblokes.de.

Die weitverbreiteten Datenkompressionswerkzeuge XZ Utils (früher LZMA Utils) enthalten in Version 5.6 eine Backdoor. Ziel der Backdoor ist nach aktuellem Kenntnisstand eine Kompromittierung von SSH-Servern. Dies wurde gestern auf der oss-security-Mailingliste von Andres Freund nebst einer umfangreichen Analyse des Sachverhalts bekannt gegeben. Durch den Einsatz der Werkzeuge in Linux-Distributionen haben wir hier einen Fall einer Supply-Chain-Attacke. Red Hat hat dem Vorfall die CVE-Nummer CVE-2024-3094 vergeben.

Vorab eine Liste mit weiteren Links:

• Stellungsnahmen von verschiedenen Distributoren
  • Arch Linux
  • Debian
  • Red Hat
  • SUSE
• FAQ
• Hacker-News-Diskussion
• Zeitleiste

Wirkungsweise

Dabei wird die Backdoor nur unter bestimmten Bedingungen ausgeführt, wie das FAQ beschreibt. Im Wesentlichen muss argv[0] auf /usr/sbin/sshd gesetzt sein und eine Reihe an Umgebungsvariablen entweder gesetzt oder nicht gesetzt sein. Normalerweise hängt OpenSSH nicht von liblzma ab. Einige Distributoren patchen OpenSSH allerdings so, dass systemd-Notifcations funktioniert, welches wiederum auf liblzma setzt und die Backdoor möglich macht. Technisch werden einige Checks durchgeführt und anschließend mittels IFUNC Bibliotheksaufrufe umgeleitet. Dies betrifft nach aktuellem Stand auch Aufrufe während der Kryptoroutinen bei der SSH-Authentifizierung.

Betroffenheit

Der Wirkungsweise der Payload ist noch nicht abschließend geklärt. Besonders auch aus diesem Grund wird ein unverzügliches Update angeraten. Im Folgenden einige unverbindliche Faktoren, die eine Verwundbarkeit wahrscheinlich machen. Auf diese Weise kann man priorisieren, welche Systeme zuerst aktualisiert werden sollten.

Versionierte Distros wie z. B. Debian oder RHEL sind nach aktuellem Kenntnisstand mit ihren stabilen Versionen nicht direkt betroffen, da die Versionen 5.6 noch keinen Einzug in das System gefunden haben. Die Testing-Versionen dieser Distros wie z. B. Debian Sid wurden allerdings aktualisiert und sind betroffen.

Rolling-Release-Distros sind naturgemäß auch betroffen, wenn sie schon Version 5.6 in ihre Pakete aufgenommen haben. Dies betrifft zum Beispiel Arch Linux oder Gentoo. Da allerdings einige Distributionen wie Arch Linux OpenSSH nicht gegen liblzma linken, wird die Bibliothek nicht direkt in die Ausführung der Komponenten eingebunden.

Nach aktuellem Stand wird eine Verwundbarkeit besonders kritisch, wenn auf dem betroffenen Host ein öffentlich erreichbarer SSH-Server läuft, da die oben beschriebenen Faktoren ein Laden der Payload auslösen können.

Wie kam es?

Aufgefallen ist die Backdoor nur durch Zufall durch das Debugging von Performanceproblemen, die durch die Backdoor verursacht wurden. Die Backdoor wurde obfuskiert im Rahmen von Buildskripten untergebracht, sodass aufgrund der Komplexität die Lücken noch nicht direkt aufgefallen sind.

Das Repository hinter xz kann als kompromittiert gesehen werden und ist auch auf GitHub schon gesperrt worden. Auffällig ist, dass die Backdoor in den Tarballs der Releases enthalten war, nicht jedoch im Repository-Dump selber. Auch personell gab es einige Auffälligkeiten, da es vor kurzem einen Maintainerwechsel beim Projekt gab und die Lücken vom neuen Maintainer, der seit 2 Jahren am Projekt mitarbeitet, zumindest begünstigt wurden. Die Art und Weise lässt auch auf ein koordiniertes, von langer Hand geplantes Vorgehen schließen.

Einfluss und Folgen

Das große Ganze ist ein Paradebeispiel von xkcd 2347 "Dependency". Wir sehen hier Live ein Beispiel einer Supply-Chain-Attacke. Ein kleines, scheinbar unbedeutendendes Projekt wird übernommen, nur um strategisch Commits zu platzieren, die automatisch "flussabwärts" ihren Weg in größere Distributionen finden, die allesamt auf das Projekt setzen. Alles passiert trotz Open Source. Besonders pikant: der Maintainer hat aktiv versucht, die Backdoor-begünstigenden Umgebungsfaktoren, konkret das Umbiegen von Bibliotheksaufrufen mittels ifunc, in Fuzzing-Projekten wie oss-fuzz, die aktiv nach sowas suchen, zu deaktivieren.

Software wird immer bedeutender und benötigt Vertrauen. Dabei ist jetzt schon klar, dass niemand selber solch komplexe Systeme von alleine bauen kann. Aber auch die Kontrolle der Quellen ist eine große Herausforderung. Neue Gesetzgebung wie der geplante Cyber Resilience Act in der EU versuchen in der Industrie Anreize zu schaffen, die Softwarequalität zu erhöhen.

Diese Attacke konnte einigermaßen abgewendet werden, sollte die umfassende Analyse der Payload keine belastenden Neuigkeiten hervorbringen. Eines ist aber auch klar: Die Angreifer studieren das Verhalten der Verteidiger und werden in Zukunft ihre Vorgehensweise dahingehend optimieren, nicht so einfach mehr gefunden zu werden. Es ist also möglich, Backdoors in so ein Ökosystem hineinzuschummeln. Umso besser müssen aber die Identifikations- und Abwehrmöglichkeiten werden, damit solche Angriffe wirksam verhindert werden können.