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.

Die letzten Wochen habe ich mich ziemlich intensiv mit Home Assistant auseinandergesetzt. Dabei handelt es sich um eine Open-Source-Software zur Smart-Home-Steuerung. Home Assistant (HA) ist eine spezielle Linux-Distribution, die häufig auf einem Raspberry Pi ausgeführt wird. Dieser Artikel zeigt die nicht ganz unkomplizierte Integration meines Fronius Wechselrichters in das Home-Assistant-Setup. (Die Basisinstallation von HA setze ich voraus.)

Die Abbildung ist wie folgt zu interpretieren: Heute bis 19:00 wurden im Haushalt 8,2 kWh elektrische Energie verbraucht, aber 13,6 kWh el. Energie produziert (siehe die Kreise rechts). 3,7 kWh wurden in das Netz eingespeist, 0,4 kWh von dort bezogen.

Das Diagramm »Energieverbrauch« (also das Balkendiagramm oben): In den Morgen- und Abendstunden hat der Haushalt Strom aus der Batterie bezogen (grün); am Vormittag wurde der Speicher wieder komplett aufgeladen (rot). Am Nachmittag wurde Strom in das Netz eingespeist (violett). PV-Strom, der direkt verbraucht wird, ist gelb gekennzeichnet.

Fronius-Integration

Bevor Sie mit der Integration des Fronius-Wechselrichters in das HA-Setup beginnen, sollten Sie sicherstellen, dass der Wechselrichter, eine fixe IP-Adresse im lokalen Netzwerk hat. Die erforderliche Einstellung nehmen Sie in der Weboberfläche Ihres WLAN-Routers vor.

Außerdem müssen Sie beim Wechselrichter die sogenannte Solar API aktivieren. Über diese REST-API können diverse Daten des Wechselrichters gelesen werden. Zur Aktivierung müssen Sie sich im lokalen Netzwerk in der Weboberfläche des Wechselrichters anmelden. Die relevante Option finden Sie unter Kommunikation / Solar API. Der Dialog warnt vor der Aktivierung, weil die Schnittstelle nicht durch ein Passwort abgesichert ist. Allzugroß sollte die Gefahr nicht sein, weil der Zugang ohnedies nur im lokalen Netzwerk möglich ist und weil die Schnittstelle ausschließlich Lesezugriffe vorsieht. Sie können den Wechselrichter über die Solar API also nicht steuern.

Als nächstes öffnen Sie in der HA-Weboberfläche die Seite Einstellungen / Geräte & Dienste und suchen dort nach der Integration Fronius (siehe auch hier). Im ersten Setup-Dialog müssen Sie lediglich die IP-Adresse des Wechselrichters angeben. Im zweiten Dialog werden alle erkannten Komponenten aufgelistet und Sie können diese einem Bereich zuordnen.

Bei meinen Tests standen anschließend über 60 neue Entitäten (Sensoren) für alle erdenklichen Betriebswerte des Wechselrichters, des damit verbundenen Smartmeters sowie des Stromspeichers zur Auswahl. Viele davon werden automatisch im Default-Dashboard angezeigt und machen dieses vollkommen unübersichtlich.

Energieansicht

Der Zweck der Fronius-Integration ist weniger die Anzeige diverser einzelner Betriebswerte. Vielmehr sollen die Energieflüssen in einer eigenen Energieansicht dargestellt werden. Diese Ansicht wertet die Wechselrichterdaten aus und fasst zusammen, welche Energiemengen im Verlauf eines Tags, einer Woche oder eines Monats wohin fließen. Die Ansicht differenziert zwischen dem Energiebezug aus dem Netz bzw. aus den PV-Modulen und berücksichtigt bei richtiger Konfiguration auch den Stromfluss in den bzw. aus dem integrierten Stromspeicher. Sofern Sie eine Gasheizung mit Mengenmessung verfügen, können Sie auch diese in die Energieansicht integrieren.

Die Konfiguration der Energieansicht hat sich aber als ausgesprochen schwierig erwiesen. Auf Anhieb gelang nur das Setup des Moduls Stromnetz. Damit zeigt die Energieansicht nur an, wie viel Strom Sie aus dem Netz beziehen bzw. welche Mengen Sie dort einspeisen. Die Fronius-Integration stellt die dafür Daten in Form zweier Sensoren direkt zur Verfügung:

• Aus dem Netz bezogene Energie: sensor.smart_meter_ts_65a_3_bezogene_wirkenergie

• In das Netz eingespeiste Energie: sensor.smart_meter_ts_65a_3_eingespeiste_wirkenergie

Je nachdem, welchen Wechselrichter und welche dazu passende Integration Sie verwenden, werden die Sensoren bei Ihnen andere Namen haben. In den Auswahllisten zur Stromnetz-Konfiguration können Sie nur Sensoren
auswählen, die Energie ausdrücken. Zulässige Einheiten für derartige Sensoren sind unter anderem Wh (Wattstunden), kWh oder MWh.

Code zur Bildung von drei Riemann-Integralen

Eine ebenso einfache Konfiguration der Module Sonnenkollektoren und Batteriespeicher zu Hause scheitert daran, dass die Fronius-Integration zwar aktuelle Leistungswerte für die Produktion durch die PV-Module und den Stromfluss in den bzw. aus dem Wechselrichter zur Verfügung stellt (Einheit jeweils Watt), dass es aber keine kumulierten Werte gibt, welche Energiemengen seit dem Einschalten der Anlage geflossen sind (Einheit Wattstunden oder Kilowattstunden). Im Internet gibt es eine Anleitung, wie dieses Problem behoben werden kann:

https://community.home-assistant.io/t/376329
https://www.home-assistant.io/integrations/integration

Die Grundidee besteht darin, dass Sie eigenen Code in eine YAML-Konfigurationsdatei von Home Assistant einbauen. Gemäß dieser Anweisungen werden mit einem sogenannten Riemann-Integral die Leistungsdaten in Energiemengen umrechnet. Dabei wird regelmäßig die gerade aktuelle Leistung mit der zuletzt vergangenen Zeitspanne multipliziert. Diese Produkte (Energiemengen) werden summiert (method: left). Das Ergebnis sind drei neue Sensoren (Entitäten), deren Name sich aus den title-Attributen im zweiten Teil des Listings ergeben:

• Batterieladung: sensor.total_battery_energy_charged
• Batterieentladung: sensor.total_battery_energy_discharged
• PV-Produktion: sensor.total_photovoltaics_energy

Die Umsetzung der Anleitung hat sich insofern schwierig erwiesen, als die in der ersten Hälfte des Listungs verwendeten Sensoren aus der Fronius-Integration bei meiner Anlage ganz andere Namen hatten als in der Anleitung. Unter den ca. 60 Sensoren war es nicht ganz leicht, die richtigen Namen herauszufinden. Wichtig ist auch die Einstellung device_class: power! Die in einigen Internet-Anleitungen enthaltene Zeile device_class: energy ist falsch.

Der template-Teil des Listings ist notwendig, weil der Sensor solarnet_leistung_von_der_batterie je nach Vorzeichen die Lade- bzw. Entladeleistung enthält und daher getrennt summiert werden muss. Außerdem kommt es vor, dass die Fronius-Integration einzelne Werte gar nicht übermittelt, wenn sie gerade 0 sind (daher die Angabe eines Default-Werts).

Der zweite Teil des Listungs führt die Summenberechnung durch (method: left) und skaliert die Ergebnisse um den Faktor 1000. Aus 1000 Wh wird mit unit_prefix: k also 1 kWh.

Bevor Sie den Code in configuration.yaml einbauen können, müssen Sie einen Editor als Add-on installieren (Einstellungen / Add-ons, Add-on-Store öffnen, dort den File editor auswählen).

# in die Datei /homeassistant/configuration.yaml einbauen
...
template:
  - sensor:
      - name: "Battery Power Charging"
        unit_of_measurement: W
        device_class: power
        state: "{{ max(0, 0 -  states('sensor.solarnet_leistung_von_der_batterie') | float(default=0)) }}"
      - name: "Battery Power Discharging"
        unit_of_measurement: W
        device_class: power
        state: "{{ max(0, states('sensor.solarnet_leistung_von_der_batterie') | float(default=0)) }}"
      - name: "Power Photovoltaics"
        unit_of_measurement: W
        device_class: power
        state: "{{ states('sensor.solarnet_pv_leistung') | float(default=0) }}"

sensor:
    - platform: integration
      source: sensor.battery_power_charging
      name: "Total Battery Energy Charged"
      unique_id: 'myuuid_1234'
      unit_prefix: k
      method: left
    - platform: integration
      source: sensor.battery_power_discharging
      name: "Total Battery Energy Discharged"
      unique_id: 'myuuid_1235'
      unit_prefix: k
      method: left
    - platform: integration
      source: sensor.power_photovoltaics
      name: "Total Photovoltaics Energy"
      unique_id: 'myuuid_1236'
      unit_prefix: k
      method: left

Damit die neuen Einstellungen wirksam werden, starten Sie den Home Assistant im Dialogblatt Einstellungen / System neu. Anschließend sollte es möglich sein, auch die Module Sonnenkollektoren und Batteriespeicher zu Hause richtig zu konfigurieren. (Bei meinen Experimenten hat es einen ganzen Tag gedauert hat, bis endlich alles zufriedenstellend funktionierte. Zwischenzeitlich habe ich zur Fehlersuche Einstellungen / System / Protokolle genutzt und musste unter Entwicklerwerkzeuge / Statistik zuvor aufgezeichnete Daten von falsch konfigurierten Sensoren wieder löschen.) Der Lohn dieser Art zeigt sich im Bild aus der Artikeleinleitung.

Quellen/Links

• https://www.home-assistant.io
• https://www.fronius.com/de-at/austria/solarenergie/installateure-partner/technische-daten/alle-produkte/anlagen-monitoring/offene-schnittstellen/fronius-solar-api-json-
• https://kofler.info/bedienung-fronius-symo-gen24
• https://www.home-assistant.io/integrations/fronius
• https://community.home-assistant.io/t/376329
• https://www.home-assistant.io/integrations/integration

Es gibt unzählige Möglichkeiten, die Web-Werbung zu minimieren. Die c’t hat kürzlich ausführlich zum Thema berichtet, aber die entsprechenden Artikel befinden sich auf heise.de hinter einer Paywall. Und heise.de ist ja mittlerweile auch eine Seite, die gefühlt mindestens so viel Werbung in ihre Texte einbaut wie spiegel.de. Das ist schon eine Leistung … Entsprechend lahm ist der Seitenaufbau im Webbrowser.

Egal, alles, was Sie wissen müssen, um zuhause einigermaßen werbefrei zu surfen, erfahren Sie auch hier — kostenlos und werbefrei :-)

Konzept

Die Idee ist simpel: Parallel zum lokalen Netzwerk zuhause richten Sie mit einem Raspberry Pi ein zweites WLAN ein. Das zweite Netz verwendet nicht nur einen anderen IP-Adressbereich, sondern hat auch einen eigenen Domain Name Server, der alle bekannten Ad-Ausliefer-Sites blockiert. Jeder Zugriff auf eine derartige Seite liefert sofort eine Null-Antwort. Sie glauben gar nicht, wie schnell die Startseite von heise.de, spiegel.de etc. dann lädt!

Alle Geräte im Haushalt haben jetzt die Wahl: sie können im vorhandenen WLAN des Internet-Routers bleiben, oder in das WLAN des Raspberry Pis wechseln. (Bei mir zuhause hat dieses WLAN den eindeutigen Namen/SSID wlan-without-ads.)

Zur Realisierung dieser Idee brauchen Sie einen Raspberry Pi — am besten nicht das neueste Modell: dessen Rechenleistung und Stromverbrauch sind zu höher als notwendig! Ich habe einen Raspberry Pi 3B+ aus dem Keller geholt. Auf dem Pi installieren Sie zuerst Raspbian OS Lite und dann RaspAP. Sie schließen den Pi mit einem Kabel an das lokale Netzwerk an. Der WLAN-Adapter des Raspberry Pis realisiert den Hotspot und spannt das werbefreie lokale Zweit-Netzwerk auf. Die Installation dauert ca. 15 Minuten.

Raspberry Pi OS Lite installieren

Zur Installation der Lite-Version von Raspberry Pi OS laden Sie sich das Programm Raspberry Pi Imager von https://www.raspberrypi.com/software/ herunter und führen es aus. Damit übertragen Sie Raspberry Pi OS Lite auf eine SD-Karte. (Eine SD-Karte mit 8 GiB reicht.) Am besten führen Sie gleich im Imager eine Vorweg-Konfiguration durch und stellen einen Login-Namen, das Passwort und einen Hostnamen ein. Sie können auch gleich den SSH-Server aktivieren — dann können Sie alle weiteren Arbeiten ohne Tastatur und Monitor durchführen. Führen Sie aber keine WLAN-Konfiguration durch!

Mit der SD-Karten nehmen Sie den Raspberry Pi in Betrieb. Der Pi muss per Netzwerkkabel mit dem lokalen Netzwerk verbunden sein. Melden Sie sich an (wahlweise mit Monitor + Tastatur oder per SSH) und führen Sie ein Update durch (sudo apt update und sudo apt full-upgrade).

RaspAP installieren

RaspAP steht für Raspberry Pi Access Point. Sein Setup-Programm installiert eine Weboberfläche, in der Sie unzählige Details und Funktionen Ihres WLAN-Routers einstellen können. Dazu zählen:

• Verwendung als WLAN-Router oder -Repeater
• freie Auswahl des WLAN-Adapters
• frei konfigurierbarer DHCP-Server
• Ad-Blocking-Funktion
• VPN-Server (OpenVPN, WireGuard)
• VPN-Client (ExpressVPN, Mullvad VPN, NordVPN)

An dieser Stelle geht es nur um die Ad-Blocking-Funktionen, die standardmäßig aktiv sind. Zur Installation laden Sie das Setup-Script herunter, kontrollieren kurz mit less, dass das Script wirklich so aussieht, als würde es wie versprochen RaspAP installieren, und führen es schließlich aus.

Die Rückfragen, welche Features installiert werden sollen, können Sie grundsätzlich alle mit [Return] beantworten. Das VPN-Client-Feature ist nur zweckmäßig, wenn Sie über Zugangsdaten zu einem kommerziellen VPN-Dienst verfügen und Ihr Raspberry Pi diesen VPN-Service im WLAN weitergeben soll. (Das ist ein großartiger Weg, z.B. ein TV-Gerät via VPN zu nutzen.)

Welche Funktionen Sie wirklich verwenden, können Sie immer noch später entscheiden. Das folgende Listing ist stark gekürzt. Die Ausführung des Setup-Scripts dauert mehrere Minuten, weil eine Menge Pakete installiert werden.

wget https://install.raspap.com -O raspap-setup.sh
less raspap-setup.sh
bash raspap-setup.sh

The Quick Installer will guide you through a few easy steps
Using GitHub repository: RaspAP/raspap-webgui 3.0.7 branch
Configuration directory: /etc/raspap
lighttpd root: /var/www/html? [Y/n]:
Installing lighttpd directory: /var/www/html
Complete installation with these values? [Y/n]:
Enable HttpOnly for session cookies? [Y/n]:
Enable RaspAP control service (Recommended)? [Y/n]:
Install ad blocking and enable list management? [Y/n]:
Install OpenVPN and enable client configuration? [Y/n]:
Install WireGuard and enable VPN tunnel configuration? [Y/n]:
Enable VPN provider client configuration? [Y/n]: n
The system needs to be rebooted as a final step. Reboot now? [Y/n]

Wenn alles gut geht, gibt es nach dem Neustart des Raspberry Pi ein neues WLAN mit dem Namen raspi-webgui. Das Passwort lautet ChangeMe.

Sobald Sie Ihr Notebook (oder ein anderes Gerät) mit diesem WLAN verbunden haben, öffnen Sie in einem Webbrowser die Seite http://10.3.141.1 (mit http, nicht https!) und melden sich mit den folgenden Daten an:

Username: admin
Passwort: secret

In der Weboberfläche sollten Sie als Erstes zwei Dinge ändern: das Admin-Passwort und das WLAN-Passwort:

• Zur Veränderung des Admin-Passworts klicken Sie auf das User-Icon rechts oben in der Weboberfläche, geben einmal das voreingestellte Passwort secret und dann zweimal Ihr eigenes Passwort an.

• Die Eckdaten des WLANs finden Sie im Dialogblatt Hotspot. Das Passwort können Sie im Dialogblatt Security verändern.

RaspAP verwendet automatisch den WLAN-Namen (den Service Set Identifier) raspi-webgui. Auf der Einstellungsseite Hotspot können Sie einen anderen Namen einstellen. Ich habe wie gesagt wlan-without-ads verwendet. Danach müssen sich alle Clients neu anmelden. Fertig!

USB-WLAN-Adapter

Leider hat der lokale WLAN-Adapter des Raspberry Pis keine großartige Reichweite. Für’s Wohnzimmer oder eine kleine Wohnung reicht es, für größere Wohnungen oder gar ein Einfamilienhaus aber nicht. Abhilfe schafft ein USB-WLAN-Antenne. Das Problem: Es ist nicht einfach, ein Modell zu finden, das vom Linux-Kernel auf Anhieb unterstützt wird. Ich habe zuhause drei USB-WLAN-Adapter. Zwei haben sich als zu alt erwiesen (kein WPA, inkompatibel mit manchen Client-Geräten etc.); der dritte Adapter (BrosTrend AC650) wird auf Amazon als Raspberry-Pi-kompatibel beworben, womit ich auch schon in die Falle getappt bin. Ja, es gibt einen Treiber, der ist aber nicht im Linux-Kernel inkludiert, sondern muss manuell installiert werden:

https://github.com/ElectricRCAircraftGuy/BrosTrendWifiAdapterSoftware

Immerhin gelang die Installation unter Raspberry Pi OS Lite auf Anhieb mit dem folgenden, auf GitHub dokumentierten Kommando:

sh -c 'busybox wget deb.trendtechcn.com/install \
       -O /tmp/install && sh /tmp/install'

Mit dem nächsten Neustart erkennt Linux den WLAN-Adapter und kann ihn nutzen. Das ändert aber nichts daran, dass mich die Installation von Treibern von dubiosen Seiten unglücklich macht, dass die Treiberinstallation nach jedem Kernel-Update wiederholt werden muss und dass die manuelle Treiberinstallationen bei manchen Linux-Distributionen gar nicht möglich ist (LibreELEC, Home Assistant etc.).

Wenn Sie gute Erfahrungen mit einem USB-WLAN-Adapter gemacht haben, hinterlassen Sie bitte einen kurzen Kommentar!

Sobald RaspAP den WLAN-Adapter kennt, bedarf es nur weniger Mausklicks in der RaspAP-Weboberfläche, um diesen Adapter für den Hotspot zu verwenden.

Alternativ können Sie den internen WLAN-Adapter auch ganz deaktivieren. Dazu bauen Sie in config.txt die folgende Zeile ein und starten den Raspberry Pi dann neu.

# Datei /boot/firmware/config.txt
...
dtoverlay=disable-wifi

Danach kennt Raspberry Pi OS nur noch den USB-WLAN-Adapter, eine Verwechslung ist ausgeschlossen.

Vorteile

Der größte Vorteil von RaspAP als Ad-Blocker ist aus meiner Sicht seine Einfachheit: Der Werbeblocker kann mit minimalem Konfigurationsaufwand von jedem Gerät im Haushalt genutzt werden (Opt-In-Modell). Sollte RaspAP für eine Website zu restriktiv sein, dauert es nur wenige Sekunden, um zurück in das normale WLAN zu wechseln. Bei mir zuhause waren alle Familienmitglieder schnell überzeugt.

Nachteile

• Der Raspberry Pi muss per Ethernet-Kabel mit dem lokalen Netzwerk verbunden werden.

• Manche Seiten sind so schlau, dass sie das Fehlen der Werbung bemerken und dann nicht funktionieren. Es ist prinzipbedingt unmöglich, für solche Seiten eine Ausnahmeregel zu definieren. Sie müssen in das normale WLAN wechseln, damit die Seite funktioniert.

• youtube-Werbung kann nicht geblockt werden, weil Google so schlau ist, die Werbefilme vom eigenen Server und nicht von einem anderen Server zuzuspielen. youtube.com selbst zu blocken würde natürlich helfen und außerdem eine Menge Zeit sparen, schießt aber vielleicht doch über das Ziel hinaus.

• Mit RaspAP sind Sie in einem eigenen privaten Netz, NICHT im lokalen Netz Ihres Internet-Routers. Sie können daher mit Geräten, die sich im wlan-without-ads befinden, nicht auf andere Geräte zugreifen, die mit Ihrem lokalen Router (FritzBox etc.) verbunden sind. Das betrifft NAS-Geräte, Raspberry Pis mit Home Assistant oder anderen Anwendungen etc.

Keine Werbeeinnahmen mehr für Seitenbetreiber?

Mir ist klar, dass sich viele Seiten zumindest teilweise über Werbung finanzieren. Das wäre aus meiner Sicht voll OK. Aber das Ausmaß ist unerträglich geworden: Mittlerweile blinkt beinahe zwischen jedem Absatz irgendein sinnloses Inserat. Werbefilme vervielfachen das Download-Volumen der Seiten, der Lüfter heult, ich kann mich nicht mehr auf den Text konzentrieren, den ich lese. Es geht einfach nicht mehr.

Viele Seiten bieten mir Pur-Abos an (also Werbeverzicht gegen Bezahlung). Diesbezüglich war https://derstandard.at ein Pionier, und tatsächlich habe ich genau dort schon vor vielen Jahren mein einziges Pur-Abo abgeschlossen. In diesem Fall ist es auch ein Ausdruck meiner Dankbarkeit für gute Berichterstattung. Früher habe ich für die gedruckte Zeitung bezahlt, jetzt eben für die Online-Nutzung.

Mein Budget reicht aber nicht aus, dass ich solche Abos für alle Seiten abschließen kann, die ich gelegentlich besuche: heise.de, golem.de, phoronix, zeit.de, theguardian.com usw. Ganz abgesehen davon, dass das nicht nur teuer wäre, sondern auch administrativ mühsam. Ich verwende diverse Geräte, alle paar Wochen muss ich mich neu anmelden, damit die Seiten wissen, dass ich zahlender Kunde bin. Das ist bei derstandard.at schon mühsam genug. Wenn ich zehn derartige Abos hätte, würde ich alleine an dieser Stelle schon verzweifeln.

Wenn sich Zeitungs- und Online-News-Herausgeber aber zu einem Site-übergreifenden Abrechnungsmodell zusammenschließen könnten (Aufteilung der monatlichen Abo-Gebühr nach Seitenzugriffen), würde ich mir das vielleicht überlegen. Das ist aber sowieso nur ein Wunschtraum.

Aber so, wie es aktuell aussieht, funktioniert nur alles oder nichts. Mit RaspAP kann ich die Werbung nicht für manche Seiten freischalten. Eine Reduktion des Werbeaufkommens auf ein vernünftiges Maß funktioniert auch nicht. Gut, dann schalte ich die Werbung — soweit technisch möglich — eben ganz ab.

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ß!

Der neue Raspberry Pi 5 verfügt erstmals über eine PCIe-Schnittstelle. Leider hat man sich bei der Raspberry Pi Foundation nicht dazu aufraffen können, gleich auch einen Slot für eine PCIe-SSD vorzusehen. Gut möglich, dass es auch einfach an Platzgründen gescheitert ist. Oder wird dieser Slot das Kaufargument für den Raspberry Pi 6 sein? Egal.

Mittlerweile gibt es diverse Aufsteckplatinen für den Raspberry Pi, die den Anschluss einer PCIe-SSD ermöglichen. Sie unterscheiden sich darin, ob sie über oder unter der Hauptplatine des Raspberry Pis montiert werden, ob sie kompatibel zum Lüfter sind und in welchen Größen sie SSDs aufnehmen können. (Kleinere Aufsteckplatinen sind mit den langen 2280-er SSDs überfordert.)

Update: Im Mai 2024 stellte auch die Raspberry Pi Foundation einen SSD-Adapter vor. Vorteil: billig. Nachteil: nur für kleine SSDs geeignet (2230/2242). Siehe https://www.raspberrypi.com/news/m-2-hat-on-sale-now-for-12/

NVMe Base von Pimoroni

Für diesen Artikel habe ich die NVMe Base der britischen Firma Pimoroni ausprobiert (Link). Inklusive Versand kostet das Teil ca. 24 €, der Zoll kommt gegebenenfalls hinzu. Die Platine wird mit einem winzigen Kabel und einer Menge Schrauben geliefert.

Der Zusammenbau ist fummelig, aber nicht besonders schwierig. Auf YouTube gibt es eine ausgezeichnete Anleitung. Achten Sie darauf, dass Sie wirklich eine PCIe-SSD verwenden und nicht eine alte M2-SATA-SSD, die Sie vielleicht noch im Keller liegen haben!

Nachdem Sie alles zusammengeschraubt haben, starten Sie Ihren Raspberry Pi neu (immer noch von der SD-Karte). Vergewissern Sie sich mit lsblk im Terminal, dass die SSD erkannt wurde! Entscheidend ist, dass die Ausgabe eine oder mehrere Zeilen mit dem Devicenamen nmve0n1* enthält.

lsblk

NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
mmcblk0     179:0    0  29,7G  0 disk 
├─mmcblk0p1 179:1    0   512M  0 part /boot/firmware
└─mmcblk0p2 179:2    0  29,2G  0 part 
nvme0n1     259:0    0 476,9G  0 disk 

Raspberry-Pi-OS klonen und von der SSD booten

Jetzt müssen Sie Ihre Raspberry-Pi-OS-Installation von der SD-Karte auf die SSD übertragen. Dazu starten Sie das Programm Zubehör/SD Card Copier, wählen als Datenquelle die SD-Karte und als Ziel die SSD aus.

SD Card Copier kopiert das Dateisystem im laufenden Betrieb, was ein wenig heikel ist und im ungünstigen Fall zu Fehlern führen kann. Der Prozess dauert ein paar Minuten. Während dieser Zeit sollten Sie auf dem Raspberry Pi nicht arbeiten! Das Kopier-Tool passt die Größe der Partitionen und Dateisysteme automatisch an die Größe der SSD an.

Als letzten Schritt müssen Sie nun noch den Boot-Modus ändern, damit Ihr Raspberry Pi in Zukunft die SSD als Bootmedium verwendet, nicht mehr die SD-Karte. Dazu führen Sie im Terminal sudo raspi-config aus und wählen Advanced Options -> Boot Order -> NVMe/USB Boot.

Selbst wenn alles klappt, verläuft der nächste Boot-Vorgang enttäuschend. Der Raspberry Pi lässt sich mit der Erkennung der SSD so viel Zeit, dass die Zeit bis zum Erscheinen des Desktops sich nicht verkürzt, sondern im Gegenteil ein paar Sekunden verlängert (bei meinen Tests ca. 26 Sekunden, mit SD-Karte nur 20 Sekunden). Falls Sie sich unsicher sind, ob die SSD überhaupt verwendet wird, führen Sie noch einmal lsblk aus. Der Mountpoint / muss jetzt bei einem nvme-Device stehen:

lsblk

NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
nvme0n1     259:0    0 476,9G  0 disk 
├─nvme0n1p1 259:1    0   512M  0 part /boot/firmware
└─nvme0n1p2 259:2    0 476,4G  0 part /

Wie viel die SSD an Geschwindigkeit bringt, merken Sie am ehesten beim Start großer Programme (Firefox, Chromium, Gimp, Mathematica usw.), der jetzt spürbar schneller erfolgt. Auch größere Update (sudo apt full-upgrade) gehen viel schneller vonstatten.

Benchmark-Tests

Ist die höhere Geschwindigkeit nur Einbildung, oder läuft der Raspberry Pi wirklich schneller? Diese Frage beantworten I/O-Benchmarktests. (I/O steht für Input/Output und bezeichnet den Transfer von Daten zu/von einem Datenträger.)

Ich habe den Pi Benchmark verwendet. Werfen Sie immer einen Blick in heruntergeladene Scripts, bevor Sie sie mit sudo ausführen!

wget https://raw.githubusercontent.com/TheRemote/ \
       PiBenchmarks/master/Storage.sh
less Storage.sh       
sudo bash Storage.sh

Ich habe den Test viermal ausgeführt:

• Mit einer gewöhnlichen SD-Karte.
• Mit einer SATA-SSD (Samsung 840) via USB3.
• Mit einer PCIe-SSD (Hynix 512 GB PCIe Gen 3 HFS512GD9TNG-62A0A)
• Mit einer PCIe-SSD (wie oben) plus PCIe Gen 3 (Details folgen gleich).

Die Unterschiede sind wirklich dramatisch:

Modell                 Pi 5 + SD     Pi 5 + USB    Pi 5 + PCIe     Pi 5 + PCIe 3
-----------------    -----------  -------------  -------------   ---------------
Disk Read                73 MB/s       184 MB/s       348 MB/s          378 MB/s
Cached Disk Read         85 MB/s       186 MB/s       358 MB/s          556 MB/s
Disk Write               14 MB/s       121 MB/s       146 MB/s          135 MB/s
4k random read         3550 IOPS     32926 IOPS    96.150 IOPS      173.559 IOPS
4k random write         918 IOPS     27270 IOPS    81.920 IOPS       83.934 IOPS
4k read               15112 KB/s     28559 KB/s   175.220 KB/s      227.388 KB/s
4k write               4070 KB/s     28032 KB/s   140.384 KB/s      172.500 KB/s   
4k random read        13213 KB/s     17153 KB/s    50.767 KB/s       54.682 KB/s
4k random write        2862 KB/s     27507 KB/s   160.041 KB/s      203.630 KB/s        
Score                       1385           9285         34.723            43.266

Beachten Sie aber, dass das synthetische Tests sind! Im realen Betrieb fühlt sich Ihr Raspberry Pi natürlich schneller an, aber keineswegs in dem Ausmaß, den die obigen Tests vermuten lassen.

PCIe Gen 3

Standardmäßig verwendet der Raspberry Pi PCI Gen 2. Mit dem Einbau von zwei Zeilen Code in /boot/firmware/config.txt können Sie den erheblich schnelleren Modus PCI Gen 3 aktivieren. (Der Tipp stammt vom PCIe-Experten Jeff Geerling.)

# in /boot/firmware/config.txt
dtparam=pciex1
dtparam=pciex1_gen=3

Die obigen Benchmarktests beweisen, dass die Einstellung tatsächlich einiges an Zusatz-Performance bringt. Ehrlicherweise muss ich sagen, dass Sie davon im normalen Betrieb aber wenig spüren.

Bleibt noch die Frage, ob die Einstellung gefährlich ist. Die Raspberry Pi Foundation muss ja einen Grund gehabt haben, warum sie PCI Gen 3 nicht standardmäßig aktiviert hat. Zumindest bei meinen Tests sind keine Probleme aufgetreten. Auch dmesg hat keine beunruhigenden Kernel-Messages geliefert.

Fazit

Es ist natürlich cool, den Raspberry Pi mit einer schnellen SSD zu verwenden. Für Bastelprojekte ist dies nicht notwendig, aber wenn Sie vor haben, Ihren Pi als Server, NAS etc. einzusetzen, beschleunigt die SSD I/O-Vorgänge enorm.

Schön wäre, wenn der Raspberry Pi in Zukunft einen PCIe-Slot erhält, um (zumindest kurze) SSDs ohne Zusatzplatine zu nutzen. Bis dahin sind die Erweiterungsplatinen eine Übergangslösung.

In der Community ist zuletzt die Frage aufgetaucht, ob der Raspberry Pi überhaupt noch preiswert ist. Diese Frage ist nicht unberechtigt: Die Kosten für einen neuen Pi 5 + Netzteil + Lüfter + SSD-Platine + SSD + Gehäuse gehen in Richtung 150 €. Sofern Sie ein Gehäuse finden, in dem der Pi samt SSD-Platine Platz findet … Um dieses Geld bekommen Sie auch schon komplette Mini-PCs (z.B. die Chuwi Larkbox X). Je nach Anwendung muss man fairerweise zugeben, dass ein derartiger Mini-PC tatsächlich ein besserer Deal ist.

Quellen/Links

• Pimoroni NVMe Base: https://shop.pimoroni.com/products/nvme-base, https://www.youtube.com/watch?v=odG7FbptgWQ
• Pineberry (2 Modelle): https://pineberrypi.com
• Geekworm (diverse Modelle): https://geekworm.com/search?type=product&q=pcie
• PCIe Gen 3: https://www.jeffgeerling.com/blog/2023/forcing-pci-express-gen-30-speeds-on-pi-5
• Chuwi Larkbox X: https://www.derstandard.at/story/3000000204570
• When did the Raspberry Pi get so expensive? https://www.jeffgeerling.com/blog/2024/when-did-raspberry-pi-get-so-expensive
• SSD-Adapter der Raspberry Pi Foundation https://www.raspberrypi.com/news/m-2-hat-on-sale-now-for-12/

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.

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!

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

Wer meinem Blog folgt und, wie im Artikel „PHP 7.4 FPM auf PHP 8.1 FPM für Nextcloud“, die externe PHP-Quelle von https://deb.sury.org/ eingebaut hat und später der Anleitung „PHP 8.2 FPM für Nextcloud 28“ gefolgt ist, könnte noch auf PHP 8.2 FPM hängen geblieben sein. Da sich diese Version im Status Security fixes only befindet, ist ein Wechsel auf eine höhere Version absolut empfehlenswert. Diese PHP-Version lässt sich recht einfach auf PHP 8.4 FPM umstellen. Unter dem Raspberry Pi OS ist das mit wenigen Befehlen erledigt. In diesem Beitrag zeige ich kurz, wie man PHP 8.2 deaktiviert, PHP 8.4 installiert und Nextcloud anschließend mit der neuen Version betreibt.

Vor der Umstellung empfiehlt es sich, ein Backup der Installation und der Datenbank anzulegen. Außerdem sollte geprüft werden, ob die eingesetzten Apps bereits mit Nextcloud 33 und PHP 8.4 kompatibel sind.

Installierte PHP-Version prüfen

Das System sollte zunächst auf den aktuellen Stand gebracht werden:

sudo apt update && sudo apt upgrade

Jetzt prüfen, welche PHP-Version aktuell aktiv ist:

php -v

Falls Apache mit PHP-FPM genutzt wird, lohnt sich auch ein Blick auf die aktiven Module und Konfigurationen.

PHP 8.4 und benötigte Module installieren

Wer von PHP 8.2 auf PHP 8.4 wechselt, installiert zunächst die neue Version samt der für Nextcloud üblichen Erweiterungen:

sudo apt update

sudo apt install php8.4 php8.4-mbstring php8.4-gd php8.4-curl php8.4-imagick php8.4-intl php8.4-bcmath php8.4-gmp php8.4-mysql php8.4-zip php8.4-xml php8.4-apcu libapache2-mod-php8.4 php8.4-bz2 php8.4-redis

PHP 8.2 deaktivieren und PHP 8.4 aktivieren

Nun wird PHP 8.2 deaktiviert und PHP 8.4 aktiviert:

sudo update-alternatives --config php

sudo update-alternatives --config php
Es gibt 7 Auswahlmöglichkeiten für die Alternative php (welche /usr/bin/php bereitstellen).

  Auswahl      Pfad                  Priorität Status
------------------------------------------------------------
  0            /usr/bin/php.default   100       automatischer Modus
  1            /usr/bin/php.default   100       manueller Modus
  2            /usr/bin/php7.4        74        manueller Modus
  3            /usr/bin/php8.1        81        manueller Modus
* 4            /usr/bin/php8.2        82        manueller Modus
  5            /usr/bin/php8.3        83        manueller Modus
  6            /usr/bin/php8.4        84        manueller Modus
  7            /usr/bin/php8.5        85        manueller Modus

Hier die entsprechende Nummer eingeben – in diesem Fall die 6 für PHP 8.4:

sudo update-alternatives --config php
Es gibt 7 Auswahlmöglichkeiten für die Alternative php (welche /usr/bin/php bereitstellen).

  Auswahl      Pfad                  Priorität Status
------------------------------------------------------------
  0            /usr/bin/php.default   100       automatischer Modus
  1            /usr/bin/php.default   100       manueller Modus
  2            /usr/bin/php7.4        74        manueller Modus
  3            /usr/bin/php8.1        81        manueller Modus
  4            /usr/bin/php8.2        82        manueller Modus
  5            /usr/bin/php8.3        83        manueller Modus
* 6            /usr/bin/php8.4        84        manueller Modus
  7            /usr/bin/php8.5        85        manueller Modus

Die Abfrage der Version zeigt, ob die Umstellung auf PHP 8.4 angenommen wurde.

php -v

PHP 8.4 FPM starten und Apache neu laden

Anschließend wird der neue FPM-Dienst aktiviert und gestartet:

sudo a2disconf php8.2-fpm
sudo apt install php8.4-fpm
sudo a2enconf php8.4-fpm

Der Neustart des Webservers aktiviert nun die aktuelle PHP-Version:

sudo service apache2 restart

Nextcloud-Konfiguration

Sollten in Nextcloud anschließend wieder die bekannten Fehlermeldungen erscheinen, sind diese am besten Schritt für Schritt abzuarbeiten. Dazu werden zunächst die neue php.ini geöffnet:

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

und anschließend die Werte für memory_limit sowie session.gc_maxlifetime gemäß den Empfehlungen angepasst:

memory_limit = 512M
session.gc_maxlifetime = 3600

Am Ende der php.ini werden außerdem noch die Einstellungen für den Zwischenspeicher OPcache ergänzt:

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

Zur Optimierung von PHP 8.4 FPM können speziell auf einem Raspberry Pi 5 mit 8 GB RAM in der Datei www.conf

sudo nano /etc/php/8.4/fpm/pool.d/www.conf

die folgenden Werte angepasst werden. Standardmäßig stehen dort in der Regel:

pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3

Diese werden dann auf folgende Werte geändert:

pm = dynamic
pm.max_children = 200
pm.start_servers = 20
pm.min_spare_servers = 10
pm.max_spare_servers = 30

Anschließend wird der Dienst neu gestartet:

sudo service php8.4-fpm restart

Danach muss in der apcu.ini noch das Command Line Interface (CLI) des PHP-Caches aktiviert werden. Dazu die Datei öffnen:

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

und am Ende folgende Zeile ergänzen:

apc.enable_cli=1

Ist dies geschehen, wird der Webserver ein letztes Mal neu gestartet:

sudo service apache2 restart

Nextcloud prüfen

Danach sollte die Nextcloud-Instanz im Browser aufgerufen werden. Unter Administrationseinstellungen / System lässt sich kontrollieren, ob die neue PHP-Version erkannt wurde.

Zur Sicherheit zusätzlich die Logdateien von Apache, PHP-FPM und Nextcloud prüfen.

Fazit

Die Umstellung von PHP 8.2 auf PHP 8.4-fpm für Nextcloud 32 ist unter Raspberry Pi OS schnell erledigt. Wichtig ist vor allem, die benötigten PHP-Module zu installieren und anschließend die alte FPM-Konfiguration sauber durch die neue zu ersetzen.

Der Beitrag PHP 8.4 FPM für Nextcloud 33 erschien zuerst auf intux.de.

Dieser Beitrag baut auf dem Artikel „PHP7.4-fpm auf PHP8.1-fpm für Nextcloud“ auf.

Im Januar 2023 hatte ich erklärt, wie ich mein Raspberry Pi OS 11 (basierend auf Debian 11 Bullseye), durch Einbinden einer Fremdquelle, von PHP7.4-fpm auf PHP8.1-fpm aktualisiert habe. Warum ich zu diesem Zeitpunkt die Version 8.1 installiert habe, ist recht einfach zu beantworten. Die aktuelle Version Nextcloud 25 war noch nicht kompatibel zu PHP 8.2. Erst mit Nextcloud 26 war ein Upgrade möglich.

Nun habe ich mich nach der Aktualisierung auf Nextcloud 28 entschieden auf PHP 8.2 zu wechseln. Da ich den FastCGI-Prozessmanager FPM bevorzuge, unterscheidet sich das Upgrade etwas von einer herkömmlichen PHP-Installation.

Installation

Zuerst wird das System auf den aktuellen Stand gebracht.

sudo apt update && sudo apt upgrade -y

Ein Check zeigt, welche PHP-Version momentan aktiv ist.

php -v

Hier die Ausgabe:

PHP 8.1.27 (cli) (built: Dec 21 2023 20:17:59) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.27, Copyright (c) Zend Technologies
with Zend OPcache v8.1.27, Copyright (c), by Zend Technologies

Jetzt werden alle benötigten Pakete nachinstalliert (auch das von Nextcloud 28 verlangte bz2 und der von mir eingesetzte Redis-Server).

sudo apt install php8.2 php8.2-mbstring php8.2-gd php8.2-curl php8.2-imagick php8.2-intl php8.2-bcmath php8.2-gmp php8.2-mysql php8.2-zip php8.2-xml php8.2-apcu libapache2-mod-php8.2 php8.2-bz2 php8.2-redis

Nun wird via CLI die PHP-Version von 8.1 auf 8.2 mit

sudo update-alternatives --config php

umgestellt.

sudo update-alternatives --config php
Es gibt 5 Auswahlmöglichkeiten für die Alternative php (welche /usr/bin/php bereitstellen).

  Auswahl      Pfad                  Priorität Status
------------------------------------------------------------
  0            /usr/bin/php.default   100       automatischer Modus
  1            /usr/bin/php.default   100       manueller Modus
  2            /usr/bin/php7.4        74        manueller Modus
* 3            /usr/bin/php8.1        81        manueller Modus
  4            /usr/bin/php8.2        82        manueller Modus
  5            /usr/bin/php8.3        83        manueller Modus

sudo update-alternatives --config php
Es gibt 5 Auswahlmöglichkeiten für die Alternative php (welche /usr/bin/php bereitstellen).

  Auswahl      Pfad                  Priorität Status
------------------------------------------------------------
  0            /usr/bin/php.default   100       automatischer Modus
  1            /usr/bin/php.default   100       manueller Modus
  2            /usr/bin/php7.4        74        manueller Modus
  3            /usr/bin/php8.1        81        manueller Modus
* 4            /usr/bin/php8.2        82        manueller Modus
  5            /usr/bin/php8.3        83        manueller Modus

Ein abschließender Check zeigt die aktuelle Version.

php -v

PHP 8.2.14 (cli) (built: Dec 21 2023 20:18:00) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.2.14, Copyright (c) Zend Technologies
with Zend OPcache v8.2.14, Copyright (c), by Zend Technologies

Ist die Ausgabe korrekt, kann PHP8.1-fpm deaktiviert, PHP8.2-fpm installiert und aktiviert werden.

sudo a2disconf php8.1-fpm
sudo apt install php8.2-fpm
sudo a2enconf php8.2-fpm

Der Restart des Webservers führt nun die Änderungen aus.

sudo service apache2 restart

Nextcloud-Konfiguration

Da in der Nextcloud nun wieder die bekannten Fehlermeldungen auftauchen, heißt es, diese schrittweise abzuarbeiten. Dazu wird die neue php.ini geöffnet

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

und die Werte für memory_limit sowie session_lifetime wie empfohlen angepasst.

memory_limit = 512M
session.gc_maxlifetime = 3600

Der Block

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

für den Zwischenspeicher OPchache wird ans Ende der php.ini gesetzt.

Zur Optimierung von PHP8.2-fpm werden speziell für das Modell Raspberry Pi 4 mit 4GB RAM in der Datei www.conf mit

sudo nano /etc/php/8.2/fpm/pool.d/www.conf

folgende Werte von

pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3

auf

pm = dynamic
pm.max_children = 120
pm.start_servers = 12
pm.min_spare_servers = 6
pm.max_spare_servers = 18

angepasst und der Dienst neu gestartet.

sudo service php8.2-fpm restart

Danach muss in der apcu.ini das Command Line Interface des PHP Cache noch aktiviert werden, indem

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

folgende Zeile am Ende eingetragen wird.

apc.enable_cli=1

Ist dies geschehen, wird der Webserver ein letztes Mal neu gestartet.

sudo service apache2 restart

Fazit

Die Umstellung bringt zwar im Moment keine erkennbaren Vorteile, jedoch verschafft es wieder ein wenig Zeit und senkt den Druck das eigentliche Raspberry Pi OS 11 Bullseye durch die aktuelle Version 12 Bookworm zu ersetzen.

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.

Screen Sharing mit dem Raspberry Pi war schon immer ein fehleranfälliges Vergnügen. In der Vergangenheit hat die Raspberry Pi Foundation auf die proprietäre RealVNC-Software gesetzt. Zuletzt war RealVNC aber nicht Wayland-kompatibel. Die Alternative ist wayvnc, ein Wayland-kompatible VNC-Variante: Wie ich unter Remote Desktop und Raspberry Pi OS Bookworm schon berichtet habe, ist wayvnc aber nicht mit allen Remote-Clients kompatibel, insbesondere nicht mit Remotedesktopverbindung von Microsoft.

Anfang Mai 2024 hat die Raspberry Pi Foundation mit Raspberry Pi Connect eine eigene Lösung präsentiert. Ich habe das System ausprobiert. Um das Ergebnis gleich vorwegzunehmen: Bei meinen Tests hat alles bestens funktioniert, selbst dann, wenn auf beiden Seiten private Netzwerke mit Network Address Translation (NAT) im Spiel sind. Das Setup ist sehr einfach, als Client reicht ein Webbrowser. Geschwindigkeitswunder sind aber nicht zu erwarten, selbst im lokalen Netzwerk treten spürbare Verzögerungen auf.

Voraussetzungen

Raspberry Pi Connect setzt voraus, dass Sie die aktuelle Raspberry-Pi-Version »Bookworm« verwenden und dass der PIXEL Desktop in einer Wayland-Session läuft. Das schränkt die Modellauswahl auf 4B, 400 und 5 ein. Ob Ihr Desktop Wayland nutzt, überprüfen Sie am einfachsten im Terminal:

echo $XDG_SESSION_TYPE 

  wayland

Gegebenenfalls können Sie mit raspi-config zwischen Xorg und Wayland umschalten (Menüpunkt Advanced Options / Wayland).

Installation

Die Software-Installation verläuft denkbar einfach:

sudo apt update
sudo apt upgrade
sudo apt install rpi-connect

Nach der Installation erscheint ein neues Icon im Panel des PIXEL Desktops. Über dessen Menüeintrag Sign in gelangen Sie auf die Website https://connect.raspberrypi.com/sign-in. Dort müssen Sie eine Raspberry-Pi-ID einrichten. Die Eingabefelder sind auf ein Minimum beschränkt: E-Mail-Adresse, Passwort (2x) und Name. Fertig!

Fernzugriff

Um nun von einem anderen Rechner auf den PIXEL Desktop Ihres Raspberry Pis zuzugreifen, melden Sie sich dort ebenfalls auf der Website https://connect.raspberrypi.com/sign-in an. Dort werden alle registrierten Geräte aufgelistet. (Mit einer Raspberry-Pi-ID können als mehrere Raspberry Pis verknüpft werden.)

Praktische Erfahrungen

Bei meinen Tests hat Raspberry Pi Connect ausgezeichnet funktioniert. Der Verbindungsaufbau war problemlos. Der Desktop-Inhalt erscheint in einem neuen Browser-Fenster. Der Desktop-Inhalt wird automatisch auf die Fenstergröße skaliert. Die Bedienung ist denkbar simpel. Über zwei Buttons können Texte über die Zwischenablage kopiert bzw. eingefügt werden.

Raspberry Pi Connect testet beim Verbindungsaufbau, ob sich der Raspberry Pi und Ihr Client-Rechner (z.B. Ihr Notebook) im gleichen Netzwerk befinden. Wenn das der Fall ist, stellt der Client eine direkte Peer-to-Peer-Verbindung zum Raspberry Pi her. Nach dem Verbindungsaufbau fließen keine Daten mehr über den Raspberry-Pi-Connect-Server. Die Verbindungsgeschwindigkeit ist dann spürbar höher. Dennoch ist es empfehlenswert, die Bildschirmauflösung auf dem Raspberry Pi nicht höher einzustellen als notwendig.

Wenn sich Ihr Pi und Ihr Client-Rechner dagegen in unterschiedlichen (privaten) Netzwerken befinden, agiert ein Server der Raspberry Pi Foundation als Relay. Sowohl der Bildschirminhalt als auch alle Eingaben werden verschlüsselt nach Großbritannien und wieder zurück übertragen. Selbst wenn alle Geräte eine gute Internetverbindung haben, ist ein gewisser Lag unvermeidlich.

Details über die Art der Verbindung erfahren Sie, wenn Sie den Mauszeiger auf das Schloss-Icon im Screen-Sharing-Fenster bewegen.

Technische Details

Laut https://www.raspberrypi.com/news/raspberry-pi-connect/ verwendet Raspberry Pi Connect das Verfahren WebRTC. Dieser Standard kommt auch bei Programmen wie Microsoft Teams oder Zoom zum Einsatz.

Wenn die Remote-Desktop-Verbindung nicht im lokalen Netzwerk stattfindet, fließt der ganze Netzwerkverkehr über einen Relay-Server in Großbritannien. Dabei kommt das Protokoll Traversal Using Relays around NAT (kurz TURN) zum Einsatz. Die Daten werden TLS-verschlüsselt.

Der entscheidende Schwachpunkt des Systems besteht darin, dass es aktuell nur einen einzigen TURN-Server gibt. Je mehr gleichzeitige Remote-Desktop-Verbindungen aktiv sind, desto langsamer wird das Vergnügen … (Und besonders schnell ist es schon im Idealfall nicht.)

Fazit

Raspberry Pi Connect punktet vor allem durch seine Einfachheit.

• Am Raspberry Pi reicht es aus, rpi-connect zu installieren.
• Die Raspberry-Pi-ID kann rasch und unkompliziert eingerichtet werden.
• Die Anwendung im Webbrowser funktioniert plattformübergreifend und einfach.

Allzu hohe Performance-Anforderungen sollten Sie nicht haben. Die Nachlaufzeiten bei Mausbewegungen und gar beim Verschieben eines Fensters sind beachtlich. Für administrative Arbeiten reicht die Geschwindigkeit aber absolut aus.

Schließlich bleibt abzuwarten, wie gut die Software skaliert. Aktuell befindet sich Raspberry Pi Connect noch in einem Probebetrieb. Soweit sich der Raspberry Pi und der Client-Rechner nicht im gleichen lokalen Netzwerk befinden, werden die Bildschirmdaten über einen Relay in Großbritannien geleitet. Aktuell gibt es genau einen derartigen Relay. Je mehr Anwender Raspberry Pi Connect gleichzeitig nutzen, desto langsamer wird es. Die Raspberry Pi Foundation lässt sich aktuell überhaupt offen, ob es den Relay-Betrieb dauerhaft kostenlos anbieten kann.

Quellen/Links

• https://connect.raspberrypi.com
• https://www.raspberrypi.com/news/raspberry-pi-connect/
• https://de.wikipedia.org/wiki/WebRTC
• https://en.wikipedia.org/wiki/Traversal_Using_Relays_around_NAT
• https://kofler.info/remote-desktop-und-raspberry-pi-os-bookworm

Anfang Oktober 2025 hat das Raspberry Pi OS ein Upgrade auf Version 13 mit dem Codenamen Trixie erhalten. Dies setzt die Serverbetreiber wieder einmal mächtig unter Druck, obwohl Bookworm noch weitere Jahre unterstützt wird. Die Entwickler empfehlen eine Neuinstallation. Es ist immer von Vorteil, ein Betriebssystem wie im Falle von Trixie neu und somit sauber aufzusetzen. Da ich aber seit Jahren eine gut funktionierende Nextcloud-Instanz auf meinem Raspberry Pi pflege, die ich in meinem Alltag produktiv einsetze, wäre es zu schade, noch einmal ganz von vorn anfangen zu müssen. Aus diesem Grund war ich auf der Suche nach einem funktionierenden Tutorial für das anstehende OS-Upgrade. Schon beim Umstieg auf Bookworm war der Blog von Sascha Syring sehr hilfreich. Also hoffte ich auch dieses Mal, wieder hier fündig zu werden. Der Artikel „Raspberry Pi OS – Update von Bookworm (12) auf Trixie (13)“ von Sascha beschreibt einmal mehr die genaue Vorgehensweise.

Ich konnte somit alles 1:1 mit meinem System umsetzen. Hier nun alle Schritte mit den entsprechenden Erläuterungen.

Bevor es jedoch losgeht, noch ein wichtiger Hinweis:

Denkt bitte daran, vorher ein Backup zu erstellen! Das Upgrade birgt nicht zu unterschätzende Gefahren.

Upgrade auf Trixie

Zuerst sollte man dafür sorgen, das System inklusive Kernel und aller Abhängigkeiten auf den neuesten Stand zu bringen. Hierzu führt man folgenden Befehl aus:

sudo apt update && sudo apt full-upgrade

Vorbereitend wurde in meinem Fall die alte PHP-Fremd-Quelle deaktiviert.

Hierzu setzt man eine Raute (#) vor den Eintrag, öffnet dazu die php.list mit einem Editor

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

und kommentiert die Zeile entsprechend aus:

#deb https://packages.sury.org/php/ bullseye main

Danach werden die hauseigenen Quellen des Raspberry Pi OS auf Trixie umgestellt:

sudo nano /etc/apt/sources.list

Hierzu wird in allen Quellen wie folgt bookworm durch trixie ersetzt:

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

Das Gleiche führt man analog hier durch:

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

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

Da beim ersten Versuch des Upgrades noch einiges schieflief, möchte ich an dieser Stelle darauf hinweisen, dass das Entfernen folgender Pakete für das Gelingen extrem wichtig ist!

sudo apt purge -y raspberrypi-ui-mods
sudo apt purge -y lxplug-batt
sudo apt purge -y lxplug-cpu

Ist dies erledigt, startet man via

sudo apt update && sudo apt full-upgrade

das eigentliche Upgrade. Hierzu ist noch zu erwähnen, dass bei den Abfragen zu alten Konfigurationen diese erhalten bleiben sollen. An diesen Stellen also bitte immer die Vorgabe (N) während der Installation wählen.

Die Pakete rpd-wayland-all und rpd-x-all werden noch nachinstalliert:

sudo apt install rpd-wayland-all rpd-x-all

Aufgeräumt wird mit:

sudo apt autoremove
sudo apt clean

und das System wird neu gestartet:

sudo reboot now

Überprüfung

Nach dem Neustart sollte der Befehl

sudo cat /etc/os-release

nun Folgendes ausgeben:

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

Feintuning

Da der NetworkManager nach dem Neustart noch nicht arbeitet, sollte er mit

sudo systemctl enable NetworkManager && sudo systemctl start NetworkManager

aktiviert und gestartet werden.

PHP-Quelle wieder einbinden

Am Anfang der Anleitung hatte ich die PHP-Quelle auskommentiert. Das machen wir nun wieder rückgängig. Erscheint nun nach einem Update der Hinweis, dass der zugehörige Schlüssel abgelaufen ist, löscht man diesen, lädt den aktuellen herunter und liest ihn neu ein.

sudo rm -f /usr/share/keyrings/deb.sury.org-php.gpg
sudo curl -sSLo /etc/apt/trusted.gpg.d/sury-php.gpg https://packages.sury.org/php/apt.gpg

Die Paketquellen werden nun abermals eingelesen und das System aktualisiert:

sudo apt update && sudo apt upgrade

Da die PHP-Quelle allerdings noch nicht für Trixie optimiert ist, ersetzt man auch hier bookworm bzw. bullseye durch trixie:

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

#deb https://packages.sury.org/php/ bullseye main

Ein weiteres Mal werden die Paketquellen eingelesen und das System aktualisiert:

sudo apt update && sudo apt upgrade

Ist dies geschehen, ist das Upgrade von Raspberry Pi OS Version 12 auf 13 abgeschlossen.

Viel Erfolg bei der Umsetzung!

Der Beitrag Raspberry Pi OS Bookworm -> Trixie erschien zuerst auf intux.de.

Die Raspberry Pi Foundation hat vor einigen Tagen eine komplett reorganisierte Implementierung Ihres Raspberry Pi OS Imager vorgestellt. Das Programm hilft dabei, Raspberry Pi OS oder andere Distributionen auf SD-Karten für den Raspberry Pi zu schreiben. Mit der vorigen Version hatte ich zuletzt Ärger. Aufgrund einer Unachtsamkeit habe ich Raspberry Pi OS über die Windows-Installation auf der zweite SSD meines Mini-PCs geschrieben. Führt Version 2.0 ebenso leicht in die Irre?

Installation unter Linux

Der Raspberry Pi Imager steht für Windows als EXE-Datei und für macOS als DMG-Image zur Verfügung. Installation und Ausführung gelingen problemlos.

Unter Linux ist die Sache nicht so einfach. Die Raspberry Pi Foundation stellt den Imager als AppImage zur Verfügung. AppImages sind ein ziemlich geniales Format zur Weitergabe von Programmen. Selbst Linux Torvalds war begeistert (und das will was sagen!): »This is just very cool.« Leider setzt Ubuntu auf Snap-Pakete und die Red-Hat-Welt auf Flatpaks. Dementsprechend mau ist die Unterstützung für das AppImage-Format.

Ich habe meine Tests unter Fedora 43 durchgeführt. Der Versuch, den heruntergeladenen Imager einfach zu starten, führt sowohl aus dem Webbrowser als auch im Gnome Dateimanager in das Programm Gnome Disks. Fedora erkennt nicht, dass es sich um eine App handelt und bietet stattdessen Hilfe an, in die Image-Datei hineinzusehen. Abhilfe: Sie müssen zuerst das Execute-Bit setzen:

chmod +x Downloads/imager_2.2.0.amd64.AppImage

Aber auch der nächste Startversuch scheitert. Das Programm verlangt sudo-Rechte.

Mit sudo funktioniert es schließlich:

sudo Downloads/imager_2.2.0.amd64.AppImage

Tipp: Beim Start mit sudo müssen Sie imager_n.n.AppImage unbedingt einen Pfad voranstellen! Wenn Sie zuerst mit cd Downloads in das Downloads-Verzeichnis wechseln und dann sudo imager_n.n.AppImage ausführen, lautet die Fehlermeldung Befehl nicht gefunden. Hingegen funktioniert sudo ./imager_n.n.AppImage.

Bedienung

Ist der Start einmal geglückt, lässt sich das Programm einfach bedienen: Sie wählen zuerst Ihr Raspberry-Pi-Modell aus, dann die gewünschte, dazu passende Distribution und schließlich das Device der SD-Karte aus. Vorsicht!! Wie schon bei der alten Version des Programms sind die Icons irreführend. In meinem Fall (PC mit zwei zwei SSDs und einer SD-Karte) wird das SD-Karten-Icon für die zweite SSD verwendet, das USB-Icon dagegen für die SD-Karte. Passen Sie auf, dass Sie nicht das falsche Laufwerk auswählen!! Ich habe ein entsprechendes GitHub-Issue verfasst.

In den weiteren Schritten können Sie eine Vorabkonfiguration von Raspberry Pi OS vornehmen, was vor allem dann hilfreich ist, wenn Sie den Raspberry Pi ohne Tastatur und Monitor (»headless«) in Betrieb nehmen und sich direkt per SSH einloggen möchten.

Bei den Zusammenfassungen wäre die Angabe des Device-Namens der SD-Karte eine große Hilfe.

Fazit

Die Oberfläche des Raspberry Pi Imager wurde überarbeitet und ist ein wenig übersichtlicher geworden. An der Funktionalität hat sich nichts geändert. Leider kann es weiterhin recht leicht passieren, das falsche Device auszuwählen. Bedienen Sie das Programm also mit Vorsicht!

Quellen/Links

• https://www.raspberrypi.com/software/
• https://www.raspberrypi.com/news/a-new-raspberry-pi-imager/
• https://kofler.info/raspberry-pi-os-trixie/
• https://appimage.org/
• https://github.com/raspberrypi/rpi-imager/issues/1327

Einige Wochen nach dem Release von Debian 13 »Trixie« hat die Raspberry Pi Foundation auch Raspberry Pi OS aktualisiert. Abseits der Versionsnummern hat sich wenig geändert.

Raspberry Pi Imager

Die »Installation« von Raspberry Pi OS funktioniert wie eh und je: Sie laden die für Ihr Betriebssystem passende Version des Raspberry Pi Imagers herunter und wählen in drei Schritten Ihr Raspberry-Pi-Modell, die gewünschte Distribution und schließlich das Device Ihrer SD-Karte aus. Einfacher kann es nicht sein, würde man denken. Dennoch habe ich es geschafft, auf einem Rechner mit zwei SSDs (einmal Linux, diese SSD war aktiv in Verwendung, einmal Windows) die Installationsdaten auf die Windows-SSD statt auf die SD-Karte zu schreiben. Schuld war ich natürlich selbst, weil ich nur auf das Pictogram gesehen und nicht den nebenstehenden Text gelesen habe. Der Imager hat die SSD mit dem SD-Karten-Icon garniert.

Wenn Sie möchten, können Sie im Imager eine Vorweg-Konfiguration durchführen. Das ist vor allem für den Headless-Betrieb praktisch, erspart aber auch erste Konfigurationsschritte im Assistenten, der beim ersten Start erscheint.

Versionsnummern

Raspberry Pi OS Trixie profitiert mit dem Versionssprung vom neueren Software-Angebot in Debian Trixie. Die aktuelleren Versionsnummern sind gleichzeitig das Hauptargument, auf Raspberry Pi OS Trixie umzusteigen.

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
NetworkMan 1.52     Java     21/25     OpenSSH    10.0
Mesa       25.0     PHP        8.4     PostgreSQL   17
Systemd     257     Python    3.13     Postfix    3.10
                                       Samba      4.22

Einheitliche Konfiguration

Die größte Änderung am Desktop »PIXEL« (vom Hintergrundbild abgesehen) betrifft die Konfiguration: Das Control Center umfasst nun auch Desktop-Einstellungen, die Bildschirm-Konfiguration und die Drucker-Konfiguration. Das ist definitiv ein Fortschritt im Vergleich zur bisher recht willkürlichen Aufteilung der Konfiguration über diverse Programme mit recht uneinheitlichem Erscheinungsbild.

gpioset

Die Syntax von gpioset hat sich geändert (vermutlich schon vor einiger Zeit, aber mir ist es erst im Rahmen meiner Tests mit Raspberry Pi OS Trixie aufgefallen):

• Der gewünschte Chip (Nummer oder Device) muss mit der Option -c angegeben werden.

• Das Kommando läuft per Default endlos, weil es nur so den eingestellten Status der GPIOs garantieren kann. Wenn Sie wie bisher ein sofortiges Ende wünschen, übergeben Sie die Option -t 0. Beachten Sie, dass -t nicht die Zeit einstellt, sondern für ein regelmäßiges Ein- und Ausschalten gedacht ist (toggle). Ich habe die Logik nicht verstanden, aber -t 0 führt auf jeden Fall dazu, dass das Kommando sofort beendet wird.

• Alternativ kann das Kommando mit -z im Hintergrund fortgesetzt werden.

Das folgende Kommando gilt für Chip 0 (/dev/gpiochip0) und somit für die »gewöhnlichen« GPIOs. Dank -t 0 wird das Kommando sofort beendet.

gpioset -c 0 -t 0  7=1   # GPIO 7 (Pin 26) auf "high" stellen
sleep 3
gpioset -c 0 -t 0  7=0   # GPIO 7 (Pin 26) auf "low" stellen

Verwenden Sie besser das Kommando pinctrl, wenn Sie GPIOs im Terminal oder in bash-Scripts verändern wollen!

Sonstiges

Raspberry Pi OS verwendet nun per Default Swap on ZRAM. Nicht benötigte Speicherblöcke werden also komprimiert und in einer RAM-Disk gespeichert. Besonders gut funktioniert das bei Raspberry-Pi-Modellen mit viel RAM.

Raspberry Pi OS wird keine Probleme mit dem Jahr 2038 haben. Die zugrundeliegenden Änderungen stammen von Debian und wurden einfach übernommen.

Dank neuer Meta-Pakete ist es einfacher, von Raspberry Pi OS Lite auf die Vollversion umzusteigen. Das ist aus Entwicklersicht sicher erfreulich, der praktische Nutzen hält sich aber in Grenzen.

Mathematica steht aktuell noch nicht zur Verfügung, die Pakete sollen aber bald nachgeliefert werden.

Auch die Software für einige HATs (KI- und TV-Funktionen) müssen erst nachgereicht werden.

Fazit

Alles in allem ist das Raspberry-Pi-OS-Release unspektakulär. Das hat aber auch damit zu tun, dass Raspberry Pi OS bereits in den letztes Releases umfassend modernisiert wurde. Zur Erinnerung: Raspberry Pi OS verwendet Wayland, PipeWire, den NetworkManager etc., verhält sich also mittlerweile ganz ähnlich wie »normale« Linux-Distributionen. Diesmal gab es einfach weniger zu tun :-)

Bei meinen bisherigen Tests sind mir keine Probleme aufgefallen. Umgekehrt gibt es aber auch so wenig Neuerungen, dass ich bei einem vorhandenen Projekt dazu rate, die Vorgängerversion Raspberry Pi OS »Bookworm« einfach weiterlaufen zu lassen. Die Raspberry Pi Foundation rät von Distributions-Updates ab, und der Nutzen einer Neuinstallation steht in keinem Verhältnis zum Aufwand. Und es nicht auszuschließen, dass mit den vielen Versions-Updates doch die eine oder andere Inkompatibilität verbunden ist.

Quellen und Links

• https://www.raspberrypi.com/software
• https://www.raspberrypi.com/news/trixie-the-new-version-of-raspberry-pi-os
• https://github.com/raspberrypi-ui/rpd-metas
• https://www.heise.de/news/Raspberry-Pi-OS-wechselt-auf-Debian-Trixie-Basis-10722458.html
• https://kofler.info/debian-13-trixie
• https://stackoverflow.com/questions/77441261/is-it-possible-for-gpioset-version-2-0-2-to-exit-immediately

„Hacking & Security: Das umfassende Handbuch“ von Michael Kofler, Roland Aigner, Klaus Gebeshuber, Thomas Hackner, Stefan Kania, Frank Neugebauer, Peter Kloep, Tobias Scheible, Aaron Siller, Matthias Wübbeling, Paul Zenker und André Zingsheim ist 2025 in der 4., aktualisierten und erweiterten Auflage im Rheinwerk Verlag erschienen und umfasst 1271 Seiten.

Ein Buchtitel, der bereits im Namen zwei gegensätzliche Extreme vereint: Hacking und Security. Dieser Lesestoff richtet sich nicht an ein breites Publikum, wohl aber an all jene, die Wert auf digitale Sicherheit legen – sei es im Internet, auf Servern, PCs, Notebooks oder mobilen Endgeräten. Gleichzeitig kann dieses umfassende Nachschlagewerk auch als Einstieg in eine Karriere im Bereich Ethical Hacking dienen.

Das Buch ist in drei inhaltlich spannende und klar strukturierte Teile gegliedert.

TEIL I – Einführung und Tools erläutert, warum es unerlässlich ist, sich sowohl mit Hacking als auch mit Security auseinanderzusetzen. Nur wer versteht, wie Angreifer vorgehen, kann seine Systeme gezielt absichern und Sicherheitsmaßnahmen umsetzen, die potenzielle Angriffe wirksam abwehren.

Behandelt werden unter anderem praxisnahe Übungsmöglichkeiten sowie Penetrationstests auf speziell dafür eingerichteten Testsystemen. Ziel ist es, typische Angriffsabläufe nachzuvollziehen und daraus wirksame Schutzkonzepte abzuleiten. Einen zentralen Stellenwert nimmt dabei das speziell für Sicherheitsanalysen entwickelte Betriebssystem Kali Linux ein, das in diesem Zusammenhang ausführlich vorgestellt wird.

TEIL II – Hacking und Absicherung widmet sich intensiv den beiden zentralen Themenbereichen Hacking und Security. Es werden unterschiedliche Angriffsszenarien analysiert und typische Schwachstellen aufgezeigt. Besonders hervorgehoben wird dabei die Bedeutung der Festplattenverschlüsselung, um den unbefugten Zugriff auf sensible Daten zu verhindern.

Auch der Einsatz starker Passwörter in Kombination mit Zwei-Faktor-Authentifizierung (2FA) gehört heute zum Sicherheitsstandard. Dennoch lauern Gefahren im Alltag: Wird ein Rechner unbeaufsichtigt gelassen oder eine Sitzung nicht ordnungsgemäß beendet, kann etwa ein präparierter USB-Stick mit Schadsoftware gravierende Schäden verursachen.

Server-Betreiber stehen zudem unter permanentem Druck durch neue Bedrohungen aus dem Internet. Das Buch bietet praxisnahe Anleitungen zur Härtung von Windows- und Linux-Servern – beispielsweise durch den Einsatz von Tools wie Fail2Ban, das automatisiert Brute-Force-Angriffe erkennt und unterbindet.

Ein weiteres Kernthema ist die Verschlüsselung von Webverbindungen. Moderne Browser weisen inzwischen deutlich auf unsichere HTTP-Verbindungen hin. Die Übertragung sensibler Daten ohne HTTPS birgt erhebliche Risiken – etwa durch Man-in-the-Middle-Angriffe, bei denen Informationen abgefangen oder manipuliert werden können.

Abgerundet wird das Kapitel durch eine ausführliche Betrachtung von Angriffsmöglichkeiten auf weit verbreitete Content-Management-Systeme (CMS) wie WordPress, inklusive praxisnaher Hinweise zur Absicherung.

TEIL III – Cloud, Smartphones, IoT widmet sich der Sicherheit von Cloud-Systemen, mobilen Endgeräten und dem Internet of Things (IoT). Unter dem Leitsatz „Die Cloud ist der Computer eines anderen“ wird aufgezeigt, wie stark Nutzerinnen und Nutzer bei der Verwendung externer Dienste tatsächlich abhängig sind. Besonders bei Cloud-Angeboten amerikanischer Anbieter werden bestehende geopolitische Risiken oft unterschätzt – obwohl sie spätestens seit den Enthüllungen von Edward Snowden nicht mehr zu ignorieren sind.

Selbst wenn Rechenzentren innerhalb Europas genutzt werden, ist das kein Garant für Datenschutz. Der Zugriff durch Dritte – etwa durch Geheimdienste – bleibt unter bestimmten Umständen möglich. Als datenschutzfreundliche Alternative wird in diesem Kapitel Nextcloud vorgestellt: ein in Deutschland entwickeltes Cloud-System, das sich auf eigenen Servern betreiben lässt. Hinweise zur Installation und Konfiguration unterstützen den Einstieg in die selbstbestimmte Datenverwaltung.

Wer sich für mehr digitale Souveränität entscheidet, übernimmt zugleich Verantwortung – ein Aspekt, dem im Buch besondere Aufmerksamkeit gewidmet wird. Ergänzend werden praxisnahe Empfehlungen zur Absicherung durch Zwei- oder Multi-Faktor-Authentifizierung (2FA/MFA) gegeben.

Ein weiteres Thema sind Sicherheitsrisiken bei mobilen Geräten und IoT-Anwendungen. Besonders kritisch: schlecht gewartete IoT-Server, die oft im Ausland betrieben werden und ein hohes Angriffspotenzial aufweisen. Auch hier werden konkrete Gefahren und Schutzmaßnahmen anschaulich dargestellt.

Das Buch umfasst insgesamt 24 Kapitel.

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

Leseprobe

• Leseprobe

Fazit

Das Buch bietet einen fundierten und praxisnahen Einstieg in die Welt von IT-Sicherheit und Hacking. Es richtet sich gleichermaßen an interessierte Einsteiger als auch an fortgeschrittene Anwender, die ihre Kenntnisse vertiefen möchten. Besonders gelungen ist die Verbindung technischer Grundlagen mit konkreten Anwendungsszenarien – vom Einsatz sicherer Tools über das Absichern von Servern bis hin zur datenschutzfreundlichen Cloud-Lösung.

Wer sich ernsthaft mit Sicherheitsaspekten in der digitalen Welt auseinandersetzen möchte, findet in diesem Werk einen gut strukturierten Leitfaden, der nicht nur Wissen vermittelt, sondern auch zum eigenständigen Handeln motiviert. Ein empfehlenswertes Nachschlagewerk für alle, die digitale Souveränität nicht dem Zufall überlassen wollen.

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

Ein MQTT-Broker ist die Schnittstelle zwischen vielen IoT-Sensoren und Geräten, die Sensordaten auswerten oder Aktoren steuern. Das MQTT-Protokoll ist offen und sehr weit verbreitet. Es findet in der Industrie Anwendungen, ist aber auch in Smart Homes ist MQTT weit verbreitet.
MQTT ist ein sehr schlankes und schnelles Protokoll. Es wird in Anwendungen mit niedriger Bandbreite gerne angewendet.

MQTT funktioniert, grob gesagt, folgendermaßen: IoT-Geräte können Nachrichten versenden, die von anderen IoT-Geräten empfangen werden. Die Vermittlungsstelle ist ein sogenannter MQTT-Broker. Dieser empfängt die Nachrichten von den Clients. Gleichzeitig können diese Nachrichten von anderen Clients abonniert werden. Die Nachrichten werden in sog. Topics eingestuft, die hierarchisch angeordnet sind, z.B. Wohnzimmer/Klima/Luftfeuchtigkeit.

Home Assistant, oder ein anderer Client, kann diesen Topic abonnieren und den Nachrichteninhalt („Payload„) auswerten (z.B. 65%).

Home Assistant OS vs. Home Assistant Container

In Home Assistant OS und Supervisor gibt es ein Addon, das einen MQTT-Broker installiert. Das ist sehr einfach, komfortabel und funktioniert wohl recht zurverlässig. In den Installationsarten Home Assistant Container und Core gibt es diese Möglichkeit nicht. Hier muss man manuell einen MQTT-Broker aufsetzen.

In diesem Artikel beschäftige ich mich damit, wie man den MQTT-Brocker Mosquitto über Docker installiert. Anschließend zeige ich, wie man die Konfigurationsdatei gestaltet und eine Verbindung zu Home Assistant herstellt. Das Ergebnis ist dann ungefähr so, als hätte man das Addon installiert. Los gehts!

Schritt für Schritt: MQTT-Broker Mosquitto mit Docker installieren

Als MQTT-Broker verwende ich die weit verbreitete Software Mosquitto von Eclipse. Dieser wird auch von Home Assistant bevorzugt und ist derjenige Broker, den das Addon installieren würde.
Für diese Anleitung wird vorausgesetzt, dass Docker bereits installiert ist und eine SSH-Verbindung zum Server hergestellt werden kann.

Schritt 1: Zunächst erstellen wir ein paar Ordner, die wir später benötigen. Mosquitto wird später so konfiguriert, dass in diese Ordner alle wichtigen Dateien abgelegt werden. Dadurch kann man auf dem Filesystem des Servers Mosquitto konfigurieren und beobachten.

$ mkdir mosquitto
$ mkdir mosquitto/config 
$ mkdir mosquitto/data 
$ mkdir mosquitto/log

Schritt 2: Nun wird die Konfigurationsdatei für Mosquitto erstellt. Über diese Datei kann man das Verhalten von Mosquitto steuern.

$ nano config/mosquitto.conf

persistence true
persistence_location /mosquitto/data/
log_dest file /mosquitto/log/mosquitto.log
log_dest stdout
password_file /mosquitto/config/mosquitto.passwd
allow_anonymous false
listener 1883

Schritt 3: Mit dem folgenden Befehl lädt man sich das aktuelle Image von Eclipse Mosquitto auf den Server.

$ docker pull eclipse-mosquitto

Schritt 4: Mit dem folgenden Befehl wird der Docker-Container gestartet. Das ist der Schlüsselmoment, jetzt muss alles klappen.

$ docker run -it -p 1883:1883 -p 9001:9001 --name mosquitto -v /home/pi/mosquitto/config:/mosquitto/config -v /home/pi/mosquitto/data:/mosquitto/data -v /home/pi/mosquitto/log:/mosquitto/log eclipse-mosquitt

Die Flags bedeuten hierbei folgendes:

• -p 1883:1883 Der genannte Port ist die Standardeinstellung für MQTT. Alles was auf diesen Port am Server ankommt, wird in den Mosquitto-Container geleitet.
• -p 9001:9001 Über diesen Port laufen die Websocket-Anwendungen. Falls das nicht benötigt wird, kann man das weg lassen
• name mosquitto Über diesen kurzen Namen können wir den Docker-Container steuern
• -v <filesystem-Pfad>:<Container-Pfad> Die in Schritt 1 erstellten Ordner werden in den Container eingebunden

Wer lieber Docker Compose verwendet, trägt diesen Eintrag in seine *.yaml ein:

services:
    eclipse-mosquitto:
        stdin_open: true
        tty: true
        ports:
            - 1883:1883
            - 9001:9001
        restart: unless-stopped
        container_name: mosquitto
        volumes:
            - /home/pi/mosquitto/config:/mosquitto/config
            - /home/pi/mosquitto/data:/mosquitto/data
            - /home/pi/mosquitto/log:/mosquitto/log
        image: eclipse-mosquitto

Schritt 5: Checken, ob der Container ordnungsgemäß läuft. In der folgenden Liste sollte eine Zeile mit dem Mosquitto-Docker auftauchen. Dieser sollte außerdem „up“ sein. Falls nicht, nochmal versuchen den Container zu starten und kontrollieren, ob er läuft.

$ docker container ls -a
CONTAINER ID   IMAGE          COMMAND   CREATED        STATUS        PORTS    NAMES
xxxxxxxxx   eclipse-mosquitto "/init"   3 minutes ago   Up 2 minutes  [...]   mosquitto

Schritt 6: Sehr gut, der Container läuft. Es wird dringend empfohlen, den MQTT-Broker so abzusichern, dass nur angemeldete User darauf zugreifen können. Das ist ja schon in Schritt 2 in die Konfigurationsdatei geschrieben worden. Mit dem folgenden Befehl melden wir uns in der Shell innerhalb des Containers an und erstellen einen Benutzer. In diesem Beispiel mosquitto. Im Anschluss an diesen Befehl wird man zweimal gebeten, das Passwort für den User festzulegen. Ist das geschafft, läuft der MQTT-Broker auf dem Server. Herzlichen Glückwunsch!

$ docker exec -it mosquitto sh // öffnet die Shell innerhalb des Dockers
mosquitto_passwd -c /mosquitto/config/mosquitto.passwd mosquitto

Optional Schritt 7: Den MQTT-Broker bindet man in Home Assistant ein, indem man auf Einstellungen → Geräte und Dienste → + Integration hinzufügen klickt. Im Suchfenster nach „MQTT“ suchen und die Zugangsdaten eingeben.
Die Server-Adresse findet man übrigens am schnellsten über ifconfig heraus.

The post MQTT-Broker Mosquitto als Docker Container installieren first appeared on bejonet - Linux | Smart Home | Technik.

(Aktualisiert 13.9.2024) Mit der Auslieferung des Raspberry Pi 5 im Herbst 2024 hat sich bei einigen Low-Level-Tools der GPIO-Zugriff geändert: Für die Modelle bis einschließlich Raspberry Pi 4 erfolgt der GPIO-Zugriff über chip0 bzw. /dev/gpiochip0. Beim Raspberry Pi musste dagegen chip4 bzw. /dev/gpiochip4 verwendet werden. Scripts, die universell auf alten und neuen Geräten laufen sollten, brauchten eine entsprechende Fallunterscheidung.

Mit Kernel 6.6.47, der mittlerweile standardmäßig als Update unter Raspberry Pi OS installiert wird, ändert sich wieder alles! Auch beim Raspberry Pi 5 muss nun /dev/gpiochip0 verwendet werden. Eine Referenz aller internen GPIO-Nummern gibt cat /sys/kernel/debug/gpio.

Die Änderung betrifft unter anderem:

• Python: gpiozero, lgpio, gpiod
• Bash: gpioset, gpioget
• C: lgpio, libgpiod, wiringpi

Scripts, die mit diesen Modulen bzw. Bibliotheken verfasst wurden, müssen geändert werden (Umstellung von GPIO-Chip 4 auf GPIO-Chip 0). Im Folgenden habe ich diesbezüglich Anleitungen für diverse Fälle zusammengefasst.

13.9.2024: Mit dem neuesten Update von Raspberry Pi OS wird ein Link von /dev/gpiochip4 auf /dev/gpiochip0 eingerichtet, wodurch die Auswirkungen des veränderten Kernels in den meisten Fällen nicht mehr spürbar sind.

ls -l /dev/gpiochip*

crw-rw---- 1 root gpio 254,  0 13. Sep 08:39 /dev/gpiochip0
crw-rw---- 1 root gpio 254, 10 13. Sep 08:39 /dev/gpiochip10
crw-rw---- 1 root gpio 254, 11 13. Sep 08:39 /dev/gpiochip11
crw-rw---- 1 root gpio 254, 12 13. Sep 08:39 /dev/gpiochip12
crw-rw---- 1 root gpio 254, 13 13. Sep 08:39 /dev/gpiochip13
lrwxrwxrwx 1 root root       9 13. Sep 08:39 /dev/gpiochip4 -> gpiochip0

Von gpiozero gibt es mittlerweile eine aktualisierte Version, die das richtige Chip-Device erkennt.

Python-Scripts mit gpiozero

Beim Start derartiger Scripts auf dem Raspberry Pi 5 mit dem aktuellen Kernel (>= 6.6.47) tritt die Fehlermeldung can not open gpiochip auf. Das Script bricht ab. Der Fehler ist bekannt, es wird demnächst eine neue Version des Python-Modules geben. Bis dahin ist es am einfachsten, das Script wie folgt zu starten:

RPI_LGPIO_CHIP=0 ./gpiozero-led.py

Alternativ führen Sie export RPI_LGPIO_CHIP=0 aus und fügen diese Anweisung auch in /home/your-account/.bashrc ein. Eine weitere Möglichkeit ohne die externe Definition von Umgebungsvariablen besteht darin, am Beginn Ihres Python-Scripts die folgende Zeile einzubauen:

import os 
os.environ['RPI_LGPIO_CHIP']='0'

Im gpiozero-Issue ist auch von PWM-Problemen zu lesen, die sich selbst mit RPI_LGPIO_CHIP=0 nicht lösen lassen. Das kann ich nicht bestätigen. Mein PWM-Test-Script gibt zwar eine Warnung aus, funktioniert aber.

Python-Scripts mit lgpio

Wenn Sie in Ihrem Python-Script das lgpio-Modul verwenden, müssen Sie den Handle nun IMMER mit gpiochip_open(0) öffnen, also:

# alle Raspberry-Pi-Modelle mit aktuellen Kernel >= 6.6.45
handle = lgpio.gpiochip_open(0)

# Raspberry Pi 5 mit Kernel < 6.6.45
# handle = lgpio.gpiochip_open(4)

Python-Scripts mit gpiod

Wenn Sie in Ihrem Python-Script das gpiod-Modul verwenden, müssen Sie die Initialisierung nun IMMER mit 'gpiochip0' durchführen, also:

chip = gpiod.Chip('gpiochip0')     # alle Modelle mit Kernel >= 6.6.45
# chip = gpiod.Chip('gpiochip4')   # Raspberry Pi 5 mit Kernel < 6.6.45

pinout-Kommando

Auch das Kommando pinout liefert zur Zeit Fehlermeldungen (can’t connect to pigpio at localhost sowie Unable to initialize GPIO Zero). Hinter den Kulissen handelt es sich bei dem Kommando um ein Python-Script, das gpiozero verwendet. Bis dieses Modul aktualisiert wird, hilft der oben schon erwähnte Trick mit RPI_LGPIO_CHIP=0 weiter, also:

RPI_LGPIO_CHIP=0 pinout

bash-Scripts mit gpioset, gpioget und gpiomon

Bei den genannten Kommandos übergeben Sie als ersten Parameter die Chip-Nummer. Ab Kernel 6.6.45 lautet diese IMMER 0, also z.B.:

chip=0
gpioset $chip 7=1   # GPIO 7 (Pin 26) auf "high" stellen
gpioset $chip 7=0   # GPIO 7 (Pin 26) auf "low" stellen

bash-Scripts mit pinctrl

Hier ändert sich nichts. pinctrl war schon in der Vergangenheit in der Lage, die richtige Chip-Nummer selbst zu erkennen, und das funktioniert weiterhin. Großartig!

pinctrl set 7 op dh   # LED an Pin 26 ein
pinctrl set 7 op dl   # LED an Pin 26 aus

C-Programme mit lgpio

Ab Kernel 6.6.45 müssen Sie IMMER die Chip-Nummer 0 verwenden, also:

#define CHIP 0
...
h = lgGpiochipOpen(CHIP);  // open connection to I/O chip

C-Programme mit gpiod

Ab Kernel 6.6.45 müssen Sie IMMER "gpiochip0" verwenden, also:

char *chipname = "gpiochip0";
chip = gpiod_chip_open_by_name(chipname);
...

wiringpi

Die von Gordon Drogon entwickelte wiringpi-Bibliothek ist seit vielen Jahren veraltet (gilt bis Version 2.5).

2024 hat der Grazer Computer Club die Wartung der Bibliothek übernommen. Damit ist diese Bibliothek (jetzt in Version 3.0) wieder verwendbar! Weitere Informationen sowie Installationshinweise gibt es auf der GitHub-Projektseite:

https://github.com/WiringPi/WiringPi

Persönliche Anmerkung

Diese ganze Angelegenheit ist ein einziges Trauerspiel. Dass beim Raspberry Pi 5 anfänglich /dev/gpiochip4 als interne GPIO-Schnittstelle verwendet wurde (und nicht von Anfang an /dev/gpiochip0 wie bei früheren Raspberry-Pi-Modellen), war schon eine äußerst fragwürdige Entscheidung. Aber die Schnittstelle jetzt, fast ein Jahr nach dem Release des Raspberry Pi 5 und Raspberry Pi OS Bookworm, zu ändern, ist einfach irrsinnig.

Mit dem Kernel-Update funktionieren unzählige GPIO-Scripts von einen Tag auf den anderen nicht mehr. So etwas muss von vorne herein vermieden werden, und, wenn es denn gar nicht anders geht, viel viel besser kommuniziert werden. Die Maintainer der GPIO-Bibliotheken waren offenbar allesamt überrascht von der Änderung. Unprofessioneller geht’s nicht.

Hintergründe / Links

• https://forums.raspberrypi.com/viewtopic.php?t=359302
• https://forums.raspberrypi.com/viewtopic.php?t=361116
• https://github.com/domoticz/domoticz/issues/6040
• https://github.com/WiringPi/WiringPi/issues/280
• https://stackoverflow.com/questions/78452048/not-able-to-access-gpio-pins-on-my-raspberry-pi-5
• https://github.com/raspberrypi/linux/pull/6144
• https://github.com/gpiozero/gpiozero/issues/1166

Dieser Blog-Beitrag ist ursprünglich unter https://pi-buch.info/low-level-gpio-zugriff-geaendert-mit-kernel-6-6/ erschienen. Danke an Hr. Strohmayer, der mich als erster auf dieses Problem aufmerksam gemacht hat.

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.

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.

Mein Raspberry Pi 5 ist mit einem SSD-Hat ausgestattet (Pimoroni, siehe Blog). Auf der SSD ist Raspberry Pi OS Bookworm installiert. Jetzt möchte ich aber Raspberry Pi OS Trixie ausprobieren. Das System habe ich mit dem Raspberry Pi Imager auf eine SD-Card geschrieben. Sowohl SSD als auch SD-Karte sind angeschlossen, die Boot-Reihenfolge ist auf SD-Card first eingestellt.

raspi-config verändert die Variable BOOT_ORDER, die im EEPROM gespeichert wird. Die Variable kann mit `rpi-eeprom-config´ gelesen werden:

rpi-eeprom-config

  [all]
  BOOT_UART=0
  WAKE_ON_GPIO=0
  POWER_OFF_ON_HALT=1
  BOOT_ORDER=0xf461

0xf461 bedeutet (die Auswertung erfolgt mit den niedrigsten Bits zuerst, also von rechts nach links):

1 - Try SD card
6 - Try NVMe
4 - Try USB mass storage
f - RESTART (loop back to the beginning)

Die Einstellung ist also korrekt, trotzdem bootet der Pi hartnäckig von der SSD und ignoriert die SD-Card. Warum?

Analyse

Schuld sind die Partition-UUIDs! Die SSD habe ich vor eineinhalb Jahren mit dem SD Card Copier geklont. Die Option New Partition UUIDs habe ich nicht verwendet, ich sah keinen Grund dazu. Jetzt liegt folgendes Problem vor: Die SSD und die vom Rasbperry Pi Imager erzeugte SD-Card haben die gleichen Partition-UUIDs!

lsblk -o NAME,PARTUUID,UUID,MOUNTPOINT

  NAME          PARTUUID     UUID                                   MOUNTPOINT
  mmcblk0                                                            
  ├─mmcblk0p1   8a676486-01  1E1E-DAB6                              /boot/firmware
  └─mmcblk0p2   8a676486-02  b8316dab-786b-45e8-815c-3d4bbf198d98    

  nvme0n1                                                            
  ├─nvme0n1p1   8a676486-01  1E1E-DAB6                               
  ├─nvme0n1p2   8a676486-02  b8316dab-786b-45e8-815c-3d4bbf198d98   /
  └─nvme0n1p3   8a676486-03  293896b6-33ee-43de-87d4-56944456cec6 

Deswegen sind die UUIDs in /etc/fstab und in /boot/firmware/cmdline.txt nicht eindeutig:

cat /etc/fstab

  proc                  /proc           proc    defaults          0       0
  PARTUUID=8a676486-01  /boot/firmware  vfat    defaults          0       2
  PARTUUID=8a676486-02  /               ext4    defaults,noatime  0       1


cat /boot/firmware/cmdline.txt

  console=serial0,115200 console=tty1 root=PARTUUID=8a676486-02 rootfstype=ext4 \
    fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles cfg80211.ieee80211_regdom=AT

Solange beide Datenträger verbunden sind, ist nicht vorhersehbar, welche Partitionen tatsächlich genutzt werden. Am einfachsten wäre es natürlich, das Kabel zur SSD vorübergehend zu trennen; das ist aber nicht empfehlenswert, weil es hierfür keinen richtigen Stecker gibt, sondern nur eine sehr filigrane Kabelpressverbindungen, die möglichst nicht anrührt werden sollte.

Lösung

Ich habe den Pi ohne SD-Karte neu gebootet und dann

• die Filesystem-UUIDs geändert,
• /etc/fstab angepasst und
• /boot/firmware/cmdline.txt ebenfalls angepasst.

Im Detail: Da die ursprüngliche Partitionierung der SSD von der SD-Karte übernommen wurde, liegt eine MBR-Partitionstabelle vor. In diesem Fall ergeben sich die Partition-UUIDs aus der Disk-ID plus Partitionsnummer. Die Disk-ID (Hex-Code mit 8 Stellen) kann mit fdisk geändert werden:

fdisk /dev/nvme0n1

  Welcome to fdisk (util-linux 2.38.1).
  Command (m for help): x.                   <-- aktiviert den Expertenmodus
  Expert command (m for help): i             <-- ID ändern
  Enter the new disk identifier: 0x1234fedc. <-- neue ID als Hex-Code
  Disk identifier changed from 0x8a676486 to 0x1234fedc.
  Expert command (m for help): r             <-- zurück ins Hauptmenü (return)
  Command (m for help): w                    <-- Änderungen speichern (write)

  The partition table has been altered.
  Syncing disks.

Mit fdisk -l vergewissern Sie sich, dass die Änderung wirklich funktioniert hat:

fdisk -l /dev/nvme0n1

  ...
  Disk identifier: 0x1234fedc

Weil der Datenträger in Verwendung ist, zeigt fdisk -l /dev/nvme0n1 weiter die alte UUID an. Sie müssen glauben, dass es funktioniert hat :-(

Bevor Sie einen Reboot machen, müssen Sie nun mit einem Editor auch /etc/fstab und /boot/firmware/cmdline.txt anpassen. In meinem Fall sehen die Dateien jetzt so aus:

cat /etc/fstab

  proc                  /proc           proc    defaults          0       0
  PARTUUID=1234fedc-01  /boot/firmware  vfat    defaults          0       2
  PARTUUID=1234fedc-02  /               ext4    defaults,noatime  0       1

cat /boot/firmware/cmdline.txt

  console=serial0,115200 console=tty1 root=PARTUUID=1234fedc-02 rootfstype=ext4 \
    fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles cfg80211.ieee80211_regdom=AT

Jetzt ist ein Reboot fällig, um zu testen, ob alles funktioniert. (Bei mir hat es im ersten Versuch NICHT funktioniert, weil ich bei fdisk das write-Kommando vergessen habe. Dann muss die SSD ausgebaut, ein USB-Gehäuse mit einem Computer verbunden und der Vorgang wiederholt werden.)

Ab jetzt sind die Partitions-UUIDs von SD-Karte und SSD voneinander unterscheidbar. Die Umschaltung des Boot-Systems mit raspi-config funktioniert, wie sie soll.

Quellen/Links

• https://kofler.info/raspberry-pi-5-mit-pcie-ssd/
• https://forums.raspberrypi.com/viewtopic.php?t=364985
• https://forums.raspberrypi.com/viewtopic.php?p=2189368#p2189368
• https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#BOOT_ORDER
• https://askubuntu.com/questions/1250224/how-to-change-partuuid

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.

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.

Smart Homes sind in aller Munde. Bei Neubauten sowieso, aber auch bestehende Immobilien werden gerne zu so genannten Smart Homes umgerüstet. Den großen Markt teilen sich natürlich kommerzielle Anbieter, aber gerade auf der Softwareseite konkurrieren auch freie und open source Software um die Kunden. Die bekanntesten Teilnehmer im open source Bereich sind FHEM, OpenHAB und Home Assistant (früher bekannt als hass.io).

Diese Software soll verschiedene smarte Geräte vereinen, so dass sie alle unter einer Haube stecken. Anstatt jeweils eine Anwendung für die Heizung, das Licht und die Energieversorgung zu verwenden, soll die Software übergeordnet sein. Sie bildet damit die Schnittstelle zwischen den Geräten und mir.

Ich möchte mein Haus mit dem Home Assistant smart machen, bzw. einige der vorhandenen Komponenten dort einbinden. In diesem Artikel möchte ich zunächst auf die Installation von Home Assistant Container eingehen.

Unterschied zwischen Home Assistant und Home Assistant Container

Der mächtige Home Assistant wird gerne auf einem Raspberry Pi installiert. In der Regel verwendet man dafür gleich ein ganzes Image für das Betriebssystem. Das bedeutet, dass man statt des üblichen Raspbian das „Home Assistant Operating System“ installiert.

Der Vorteil liegt darin, dass man den Home Assistant in vollem Umfang nutzen kann. Der Nachteil ist, dass man über ein stark angepasstes OS verfügt. Möchte man noch weitere Software darauf laufen lassen, könnte das zu Konflikten führen.

In meinem Fall laufen noch andere Prozesse auf dem Raspberry. Somit kommt für mich das OS nicht infrage. Stattdessen möchte ich auf Home Assistant Container setzen. Hier läuft die Software über Docker.

Benutzt man den Home Assistant Container, muss man mit Einschränkungen leben. Es ist beispielsweise nicht möglich, Add-ons zu installieren. Der Grund liegt meines Wissens darin, dass Add-ons als (Docker-)Container installiert werden. Und das geht nicht, wenn bereits die Hauptanwendung in einem (Docker-) Container läuft. [Falls das jemand genauer weiß, gerne einen Kommentar hinterlassen!]

Installation von Home Assistant Container

Was man als Vorbereitung braucht, ist ein installiertes Linux-System. In meinem Beispiel ist es Raspbian auf einem Raspberry Pi 4. Dort meldet man sich via SSH an.

Schritt 1: Docker installieren. Gegebenenfalls hat man eine alte Version bereits installiert. Diese muss man entfernen und die aktuelle Version installieren. Dazu wird das Docker-Repository hinzugefügt und die Software daraus installiert. Am Ende wird eine Benutzergruppe „docker“ erstellt (ggf. geschieht das automatisch). Der aktuelle Benutzer – hier nennt er sich pi – wird der Gruppe hinzugefügt.

sudo apt-get remove docker docker-engine docker.io containerd runc
sudo apt-get update
sudo apt-get install ca-certificates curl gnupg lsb-release
curl -fsSL https://download.docker.com/linux/debian/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
echo   "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/debian \
 $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
 
sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io
sudo groupadd docker
sudo usermod -aG docker pi

Schritt 2: Home Assistant Container installieren. Der folgende Befehl holt sich das entsprechende Image aus dem Dockerhub, lädt es herunter und installiert es. Es ist wichtig, dass der Ordnerpfad für die Konfigurationsdatei korrekt angegeben wird. Wie oben bereits beschrieben, fehlt die Add-on-Funktion. Um die configuration.yaml bearbeiten zu können, muss man an diese Datei herankommen. Mit der Flag -v mountet man einen existierenden Ordner in den Docker-Container und kann damit die Datei weiterhin bearbeiten.

mkdir /home/pi/homeassistant/config
docker run -d \
  --name="homeassistant" \
  --privileged \
  --restart=unless-stopped \
  -e "TZ=Europe/Berlin"
  -v /home/pi/homeassistant:/config \
  --net=host \
  homeassistant/home-assistant:stable

Wer lieber Docker Compose verwendet, kann den folgenden Eintrag in die *.yaml eintragen:

name: smart_home_p10
services:
    home-assistant:
        container_name: homeassistant
        privileged: true
        restart: unless-stopped
        environment:
            - TZ=Europe/Berlin
        volumes:
            - /home/pi/homeassistant:/config
        network_mode: host
        image: ghcr.io/home-assistant/home-assistant:stable

Schritt 3: Docker-Image verwalten. Die gesamte Home Assistant Installation kann man über den Container starten und stoppen. Ein Update führt man ebenfalls über das Docker-Image aus. Die Befehle hierfür lauten folgendermaßen.

# Update installieren
docker pull homeassistant/home-assistant:stable

# Container stoppen und entfernen
docker stop homeassistant
docker rm homeassistant

Schritt 4: Auf Home Assistant zugreifen. Ab jetzt erfolgt die Verwaltung des Home Assistant über die Weboberfläche. Mit http://<IP-Adresse des Raspberrys>:8123 kann man von einem PC des gleichen Netzwerks auf die Installation zugreifen. Änderungen an der configuration.yaml müssen weiterhin über die Systemoberfläche, also z.B. mit nano oder vim über SSH erfolgen.

nano /home/pi/homeassistant/config/configuration.yaml

The post Home Assistant Container installieren first appeared on bejonet - Linux | Smart Home | Technik.

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.