BLOG

Hey, ich möchte euch darauf hinweisen, warum ich davon abrate, ausschließlich auf Cloud-Dienste (Cloud-Zwang) zu setzen. Es geht nicht nur darum, dass eure Daten auf fremden Servern liegen, sondern auch darum, dass bei einer Abschaltung des Anbieters plötzlich alles ins Dunkle stürzen kann.

Ein aktuelles Beispiel liefert Gigaset (Link):

ZitatDie Cloud-Dienste der Smart Home/Care Produkte müssen daher zum 29. März 2024 eingestellt werden. Eine Aufrechterhaltung ist insolvenzrechtlich nicht möglich. Dadurch werden die Apps für die Smart Home/Care Produkte und die vernetzten Sensoren und Geräte nicht mehr nutzbar sein. Sollten Sie Kamera Service Pakete gebucht haben, enden diese ebenfalls spätestens zum 29. März 2024. Hinsichtlich sämtlicher ggf. bestehender Vertragsverhältnisse wird Nichterfüllung gewählt.

Wir bedauern die Unannehmlichkeiten, bla bla bla ... Eine Rücksendung der Geräte ist leider nicht möglich, bla bla bla ...

Oder wie Golem schreibt: Gigasets Smart-Home-System wird zu Elektroschrott

Seriöse Anbieter bieten Geräte an, die auch ohne Cloud-Dienste funktionieren. Falls eine sichere Cloud-Lösung auf einem deutschen Server optional angeboten wird, ist das eine Option, die genutzt werden kann, aber nicht muss.

Bei Smart Home Geräten, die einen sogenannten "Cloud-Zwang" haben, handelt es sich um Geräte, die für ihre Funktionen eine dauerhafte Verbindung zu den Servern des Herstellers benötigen. Das bedeutet, dass viele ihrer Funktionen nicht oder nur eingeschränkt verfügbar sind, wenn keine Internetverbindung besteht oder wenn die Server des Herstellers ausfallen. Hier sind einige Beispiele von Smart Home Geräteherstellern oder spezifischen Geräten, die für den Betrieb eine Cloud-Anbindung erfordern:

• Gigaset - Gigaset nutz für viele seiner Smart Home Lösungen eine Cloud-Verbindung. Dies ermöglicht die Fernsteuerung und -überwachung der Geräte, macht sie aber auch abhängig von der Verfügbarkeit der Cloud-Dienste. Ein Umstand, den viele Nutzer nun leidvoll erfahren müssen.
• Netatmo - Netatmo bietet verschiedene Smart Home Produkte an, darunter Wetterstationen, Kameras und Thermostate, die ebenfalls für Funktionen wie Fernzugriff und Datenanalyse auf Cloud-Dienste angewiesen sind.
• Google Nest - Die Produkte von Google Nest, einschließlich Thermostate, Rauchmelder und Kameras, verwenden Cloud-Dienste für die Fernsteuerung, Software-Updates und zum Teil für die Verarbeitung von Nutzerdaten.
• Ring - Rings Video-Türklingeln und Sicherheitskameras laden aufgenommene Videos in die Cloud hoch, um sie für die Benutzer zugänglich zu machen. Ohne Cloud-Anbindung wären viele ihrer Kernfunktionen nicht nutzbar.
• Philips Hue - Obwohl Philips Hue-Lampen und -Zubehör auch lokal über das Zigbee-Protokoll gesteuert werden können, wird für den Fernzugriff und die Nutzung von Automatisierungen eine Cloud-Verbindung benötigt. Mit Zigbee2MQTT könnt ihr jedoch diese Geräte, zum Beispiel über ioBroker, direkt mittels MQTT ansteuern und so den Cloud-Zwang umgehen.
• Amazon Echo - Die Echo-Geräte von Amazon sind stark auf die Cloud-Dienste von Amazon angewiesen, um Sprachbefehle zu verarbeiten und auf Anfragen zu reagieren.
• TP-Link Kasa - TP-Links Kasa-Smart-Home-Geräte benötigen eine Cloud-Verbindung für Fernzugriff und Steuerung über die Kasa-App.

Es ist wichtig zu beachten, dass sich die Abhängigkeit von der Cloud und die Funktionsweise von Smart Home Geräten mit Software-Updates ändern kann und auch abhängig von den spezifischen Anforderungen der Nutzer unterschiedlich bewertet wird. Einige Nutzer bevorzugen Geräte mit Cloud-Anbindung für erweiterte Funktionen und Komfort, während andere aus Datenschutz- und Sicherheitsgründen Geräte bevorzugen, die lokal ohne Internetverbindung funktionieren können.

OK, und was ist mit diesem angebissenen Apfel? Apple bietet mit HomeKit eine Plattform für Smart Home Geräte an, die sowohl Cloud-Dienste als auch lokale Steuerung unterstützt. Im Gegensatz zu vielen anderen Systemen, die stark auf Cloud-Anbindung angewiesen sind, legt Apple einen großen Wert auf Datenschutz und ermöglicht es, dass viele HomeKit-kompatible Geräte auch lokal, ohne Internetverbindung, gesteuert werden können. So bietet zum Beispiel Eve ein spezielles und sicheres Smart Home Portfolio für Apple ohne Cloud an. Oder ihr bindet Shelly-Geräte in HomeKit ein (Link smartapfel.de).

Am sichersten ist es, einen eigenen HomeServer, wie zum Beispiel ioBroker, zu nutzen (optional mit Cloud-Anbindung), und sicherzustellen, dass alle eingebundenen Geräte keinen Cloud-Zwang besitzen. Auf diese Weise behältst du die volle Kontrolle über deine Daten und minimierst das Risiko unerwünschter Zugriffe.

2024-01-09, Neuer Standard: dbus-broker-units

Arch Linux hat offiziell bekannt gegeben, dass 'dbus-broker-units' nun die bevorzugte Implementierung für den D-Bus Daemon ist:

ZitatFor the foreseeable future we will still support the use of 'dbus-daemon', the previous implementation. Pacman will ask you whether to install 'dbus-broker-units' or 'dbus-daemon-units'. We recommend picking the default.

Link: archlinux.org/news/making-dbus-broker-our-default-d-bus-daemon

Dieser Schritt wird mit einer Reihe von Vorteilen begründet, darunter verbesserte Leistung, Zuverlässigkeit und eine bessere Integration mit systemd, dem weit verbreiteten System- und Service-Manager für Linux.

Was bedeutet das für die Benutzer?
Für bestehende und neue Benutzer von Arch Linux und Manjaro stellt sich die Frage: Was bedeutet diese Änderung? Die gute Nachricht ist, dass 'dbus-daemon', die vorherige Implementierung, weiterhin unterstützt wird. Dies gibt den Benutzern Flexibilität und die Möglichkeit, bei Bedarf auf die ältere Version zurückzugreifen.

Empfehlung: Warum 'dbus-broker-units' bevorzugen?
Die Empfehlung von Arch Linux, 'dbus-broker-units' als Standardauswahl zu wählen, ist nicht leichtfertig. Diese moderne Implementierung verspricht nicht nur eine bessere Leistung, sondern auch eine höhere Zuverlässigkeit. Für Benutzer, die auf der Suche nach einem reibungslosen und effizienten Systemerlebnis sind, scheint 'dbus-broker-units' die richtige Wahl zu sein.

Schlussfolgerung:
Die Entscheidung von Arch Linux, 'dbus-broker-units' als Standard-D-Bus-Implementierung zu wählen, ist ein weiteres Beispiel für die ständige Evolution und Verbesserung im Linux-Ökosystem. Für Anwender von Arch Linux und Manjaro bedeutet dies, Zugang zu modernster Technologie zu haben, die darauf ausgerichtet ist, Systemleistung und -zuverlässigkeit zu verbessern. Indem man der Empfehlung folgt und 'dbus-broker-units' installiert, kann man von diesen Verbesserungen profitieren und gleichzeitig sicher sein, dass man eine von der Community unterstützte und zukunftsorientierte Lösung verwendet.


Systemaktualisierung:

Vorbereitung...
Synchronisiere Paketdatenbanken...
Aktualisierung von core.db...
Aktualisierung von extra.db...
Aktualisierung von community.db...
Aktualisierung von multilib.db...
Wähle einen Anbieter für dbus-units:
1:  dbus-broker-units  35-2       core
2:  dbus-daemon-units  1.14.10-2  core

Nummer eingeben (Standard=1): 1


Hallo Linux-Fans! In der vielfältigen und sich stetig entwickelnden Welt von Linux-Distributionen wie Arch Linux oder Manjaro stoßen wir manchmal auf spannende Entscheidungen bezüglich der Auswahl unserer Systempakete. Von essentiellen Kernkomponenten bis hin zu spannender Anwendungssoftware – diese Pakete sind das A und O unseres Systems. Nicht bei jedem Update, aber doch ab und zu, stehen wir vor der Frage: Welches Paket passt am besten? Welche Software-Version bietet die meisten Vorteile?

In den nächsten Blogposts gehen wir einige dieser wichtigen Entscheidungen durch. Wir schauen hinter die Kulissen und beleuchten die Überlegungen und Empfehlungen, die zu diesen Entscheidungen führen – wie zum Beispiel der Wechsel von 'dbus-daemon-units' zu 'dbus-broker-units' bei Arch Linux. Diese Entscheidungen haben nicht nur Einfluss auf die Leistung und Sicherheit unseres Systems, sondern auch darauf, wie gut wir damit arbeiten können. Immer in Bewegung, erfordert die Welt der Linux-Pakete unser Wissen, unsere Erfahrung und manchmal auch ein bisschen Mut, Neues auszuprobieren.

Hinweis: Dieser Artikel gibt einen allgemeinen Überblick und ist für alle gedacht, die mehr über die Linux-Welt erfahren möchten. Für tiefere Einblicke empfehle ich, einen Blick in die offiziellen Dokumentationen und Ankündigungen der jeweiligen Linux-Distributionen zu werfen, z.B.: forum.manjaro.org/c/announcements/11

Vorbemerkung: Ursprünglich betrieb ich Pi-hole 5.x unter Manjaro-arm mit Nginx, jedoch traten zahlreiche PHP-Fehler und Warnungen auf, insbesondere unter PHP 8.2. Seltsamerweise traten sogar Apache2-Warnungen auf, obwohl dieser nicht genutzt wurde! Aufgrund dieser Probleme habe ich mich entschieden, zu Lighttpd zurückzukehren, um Pi-hole zu betreiben. Es scheint, dass die Integration von Pi-hole mit Lighttpd besser funktioniert.

Gleiche Warnung wie mein Thread ioBroker mit Pi 4 und Manjaro : Ich möchte betonen, dass Debian als LTS ein äußerst solides und stabiles System ist. Bitte nehmt meinen Thread daher nicht falsch auf. Manjaro-ARM ist ebenfalls ein sehr solides und stabiles System, jedoch muss dieses in der Regel nur einmal installiert werden. Es ist wichtig zu beachten, dass Pi-hole Manjaro nicht unterstützt. Wenn dies ein Problem darstellt, sollte man auf jeden Fall bei Debian bleiben.

Abgesehen von Unbound war die Installation relativ einfach. Wer Pi-hole in Kombination mit Unbound nutzen möchte, sollte dafür allerdings etwas mehr Zeit einplanen. Möglicherweise findet ihr nützliche Unterstützung und Anleitungen in diesem Blog, die euch bei der Einrichtung helfen können.

Pi-hole ist eine freie Open Source Software, die als DNS-basierter Tracking- und Werbeblocker für das gesamte Heimnetzwerk fungiert. Es lädt unerwünschte Inhalte wie Werbebanner, bösartige Webseiten oder Telemetriedaten von IoT-Geräten und Smart TVs nicht, da es diese schon auf DNS-Ebene blockiert. Im Gegensatz zu herkömmlichen Blockern, die auf spezifische Programme oder Geräte beschränkt sind, wirkt Pi-hole netzwerkweit.

Die Einrichtung und Anpassung von Pi-hole auf einem Raspberry Pi und in einer FritzBox sowie die Konfiguration von Whitelist oder Blacklist, auch mit regulären Ausdrücken, sind einfach. Pi-hole funktioniert als DNS-Server, kann jedoch keine Werbung oder Cookie-Meldungen von der gleichen Domain blockieren, wofür weiterhin uBlock verwendet werden kann.

Mit der Kombination aus Pi-hole und Unbound, einem alternativen DNS-Resolver mit DNSSEC, wird das Netzwerk sicherer und schneller. Unbound sendet Anfragen direkt an Root DNS-Server, was initial etwas langsamer sein kann, aber durch den Cache bei nachfolgenden Anfragen beschleunigt wird. Diese Kombination gewährleistet auch, dass Anfragen von außen nicht mitgelesen werden können. Unbound übernimmt zudem die DNSSEC-Funktion, sodass eine separate Aktivierung in Pi-hole nicht nötig ist.

Wer bereits Erfahrungen mit einer solchen Umsetzung hat oder ebenfalls Interesse an diesem Vorhaben zeigt, ist herzlich eingeladen, sich hier zu melden und seine Gedanken oder Tipps zu teilen. Ich freue mich auf einen regen Austausch via Matrix: #RPI-Manjaro-arm:tchncs.de



INHALT

• Pi-hole auf Manjaro ARM installieren
• Optimierung für SSD-Laufwerke und Anpassung der EDNS-Paketgröße
• Unbound installieren und testen
• FritzBox mit Pi-Hole
• IPv4/IPv6-Adressen statisch zuweisen
• Automatisierung der Aktualisierung von root.hints
• Aktualisieren, Überprüfen und Diagnose

Versuchsaufbau: Raspberry Pi 4, der mit Manjaro-ARM (headless) installiert ist und zusätzlich Pi-hole mit Unbound, sowie ioBroker mit einem Z-Wave-Modul betreibt, angeschlossen an einer 12-Volt USV.


Die angezeigte Auslastung und Temperatur entsprechen einem normalen Betrieb mit ioBroker und Pi-Hole. Beachte, dass ich die Netzwerktabelle zurückgesetzt habe. Der Raspberry Pi 4 ist mit einem groß dimensionierten passiven Kühlkörper ausgestattet.


Hier ist eine mögliche Methode zur Umsetzung. Ich verwende eine FritzBox als Router, falls du einen anderen Router verwendest, musst du diese Einstellungen entsprechend anpassen. Ich gehe davon aus, dass Manjaro ARM installiert ist und du die IP-Adresse deines Pi 4 mit Manjaro-arm kennst, und dich per SSH verbindest, z.B.:
ssh pi4m@192.168.1.42
Aktualisiere deine Paketlisten und installiere die erforderliche Pakete:
sudo pacman -Syu
sudo pacman -Sy --needed yay base-devel git php-fpm php-sqlite inetutils curl lighttpd php-cgi gnu-netcat xxd-standalone unbound(für netcat wähle ich "gnu-netcat" und für xxd "xxd-standalone")

Kontrolliere die installierte PHP-Version:
php -v(zu dem Zeitpunkt war das PHP 8.2.12)

PHP-Leseberechtigungen festlegen. Bei der Verwendung von PHP v7.0 oder neuer ist die PHP-Direktive open_basedir standardmäßig leer. Das bedeutet, dass PHP auf alle Verzeichnisse und Dateien zugreifen kann, die von der Benutzerkennung des Webservers gelesen werden können. Aus Gründen der Sicherheit wird die open_basedir-Direktive absichtlich für die administrative Pi-hole-Weboberfläche gesetzt.
sudo nano /etc/php/php.ini

Zitatopen_basedir = /srv/http/pihole:/run/pihole-ftl/pihole-FTL.port:/run/log/pihole/pihole.log:/run/log/pihole-ftl/pihole-FTL.log:/etc/pihole:/etc/hosts:/etc/hostname:/etc/dnsmasq.d/02-pihole-dhcp.conf:/etc/dnsmasq.d/03-pihole-wildcard.conf:/etc/dnsmasq.d/04-pihole-static-dhcp.conf:/var/log/lighttpd/error-pihole.log:/proc/loadavg:/proc/meminfo:/proc/cpuinfo:/sys/class/thermal/thermal_zone0/temp:/tmp

yay -S pi-hole-serverDer AUR-Helfer-Prompt (ohne sudo!) zeigt dann Optionen zum installieren an, hier wähle ich [A]lle. Dadurch werden sowohl die expliziten AUR-Pakete (wie pi-hole-server und pi-hole-ftl) als auch alle notwendigen Abhängigkeiten (sowohl aus dem AUR als auch aus den offiziellen Repositories) installiert.
Die Wahl von "I" ist nur dann sinnvoll, wenn du sicher bist, dass alle benötigten Pakete bereits auf deinem System installiert sind und keine neuen Installationen oder Updates erforderlich sind. Im nächsten Schritt wird gefragt, ob du die Unterschiede (Diffs) zwischen den aktuellen Build-Dateien und den neuen Versionen der Pakete, die du installieren möchtest, anzeigen lassen möchtest, hier wähle ich [N] Keine.

Lege das Administrator-Passwort für die Pi-hole-Webinterface fest:
pihole -a -p(du kannst das auch leer lassen)

Erforderliche PHP-Erweiterungen aktivieren:
sudo nano /etc/php/php.iniPrüfe und aktiviere diese Einstellungen:

Zitatextension=curl
extension=pdo_sqlite
extension=sockets
extension=sqlite3

Kopieren die im Paket enthaltene Standardkonfiguration für Pi-hole:
sudo cp /usr/share/pihole/configs/lighttpd.example.conf /etc/lighttpd/lighttpd.conf
Aktiviere den lighttpd.service und starte es:
sudo systemctl enable lighttpd.service
sudo systemctl start lighttpd.serviceStelle sicher, dass Lighttpd auf deinem Raspberry Pi läuft. Du kannst dies mit dem folgenden Befehl überprüfen:
sudo systemctl status lighttpd
Richte die System-Hosts-Datei korrekt ein:
sudo nano /etc/hosts

Zitat127.0.0.1    localhost
192.168.1.42    pi.hole manjaro-arm
192.168.1.1    fritz.box

Ersetze 192.168.1.42 mit der IP-Adresse deines Pi-hole-Servers und manjaro-arm mit dem tatsächlichen Hostnamen dieses Servers. Diese Einstellung sorgt dafür, dass Anfragen an "pi.hole" und "manjaro-arm" korrekt an deinen Pi-hole-Server weitergeleitet werden.

Wenn du in deinen Netzwerk-Logs "_gateway" als Client siehst, ist das normal und zeigt an, dass dein Netzwerk wie erwartet funktioniert. Dies kannst du im Terminal mit dem Befehl route überprüfen. Um stattdessen den Namen deines Routers anzuzeigen, füge die tatsächliche IP-Adresse deines Routers, zum Beispiel 192.168.1.1, zusammen mit dem gewünschten Hostnamen, wie "fritz.box", hinzu (Zeile 3).

Netzwerk neu starten:
sudo systemctl restart systemd-networkDNS-Resolver von Pi-hole neu starten:
pihole restartdns
Aktualisiere die Blockierliste von Pi-hole:
pihole -g
Das Pi-hole Webinterface sollte nun erreichbar sein: http://192.168.1.42/admin/login.php

Die Nutzung der Standard Pi-hole Sperrliste (Adlists) "StevenBlack/hosts" ist in der Regel ausreichend:
https://raw.githubusercontent.com/StevenBlack/hosts/master/hostsund evtl. eine Sperrliste die Malware verbreiten:
https://urlhaus.abuse.ch/downloads/hostfile
Während es möglich ist, weitere Sperrlisten hinzuzufügen, bevorzuge ich die Verwendung einer eigenen Blacklist mit regulären Ausdrücken, um potenzielle Probleme zu vermeiden. Für Nutzer, die beispielsweise eine YT-History benötigen oder die obersten gesponserten Links in einer bekannten Suchmaschinen verwenden möchten, bietet sich die Erstellung einer Whitelist an. Eine solche Whitelist und Blacklist, auch mit regulären Ausdrücken, könnte dann folgendermaßen aussehen (Domains):

• EU Cookie Meldung (blacklist): (^|\.)usercentrics\.eu$
• google-Tracking (whitelist): (\.|^)googleadservices\.com$
• Adobe trackingServer (blacklist):  (^|\.)omtrdc\.net$
• youtube video history (whitelist): s.youtube.com
• Domains der TLD .zip (blacklist): \.zip$
• Apple icloud (whitelist): (\.|^)icloud\.com$
• need for add card in wallet app (whitelist): supportmetrics.apple.com
• Brave Server, um Nutzern Feldversuche für neue Funktionen zu liefern (blacklist): variations.brave.com

---

Optimierung für SSD-Laufwerke
sudo nano /etc/pihole/pihole-FTL.conf

Zitat### This file contains parameters for FTL behavior.
### At install, all parameters are commented out. The user can select desired options.
### Options shown are the default configuration. No modification is needed for most
### installations.
### Visit https://docs.pi-hole.net/ftldns/configfile/ for more detailed parameter explanations

## Max Database Days
## How long should queries be stored in the database -days-?
## Setting this to 0 disables the database
## See: https://docs.pi-hole.net/ftldns/database/
## Options: number of days
MAXDBDAYS=90

## Database Interval
## How often do we store queries in FTL's database -minutes-?
## See: https://docs.pi-hole.net/ftldns/database/
## Options: number of minutes
DBINTERVAL=60.0

## Privacy Level
## Which privacy level is used?
## See: https://docs.pi-hole.net/ftldns/privacylevels/
## Options: 0, 1, 2, 3
PRIVACYLEVEL=0

# This setting limits the number of requests that Pi-hole accepts from a single IP address per minute
RATE_LIMIT=2000/60

Wenn gewünscht kann die Abfrageprotokollierung mit "PRIVACYLEVEL=3" deaktiviert werden. Die Einstellung RATE_LIMIT=2000/60 in der pihole-FTL.conf begrenzt die Anzahl der Anfragen, die Pi-hole von einer einzelnen IP-Adresse akzeptiert, auf maximal 2000 Anfragen pro Minute.

Pi-hole-FTL neu starten:
sudo systemctl restart pihole-FTL.service
Verbesserung der DNS-Stabilität durch Anpassung der EDNS-Paketgröße und die maximale Anzahl gleichzeitiger DNS-Anfragen in Pi-hole
Überprüfe, ob das Verzeichnis '/etc/dnsmasq.d' existiert, indem du 'ls /etc/dnsmasq.d' eingibst. Falls das Verzeichnis nicht vorhanden ist, erstelle es mit 'sudo mkdir /etc/dnsmasq.d'. In meinem Fall war dies jedoch nicht erforderlich, da das Verzeichnis bereits existierte.

Erstelle eine neue Konfigurationsdatei (Quelle):
sudo nano /etc/dnsmasq.d/99-edns.confFüge die folgende Zeile in die Datei ein:

Zitatedns-packet-max=1232
dns-forward-max=300

DNS-Dienst neu starten:
pihole restartdns
Für die Zeitserver-Synchronisation verwende ich NTP und stelle den Zeitserver auf den meiner FritzBox ein. Hier ist ein Beispiel, wie du dies in deiner Konfiguration vornehmen kannst. Öffne die Konfigurationsdatei mit dem Befehl:
sudo nano /etc/systemd/timesyncd.confSetze den NTP-Server auf die IP-Adresse deiner FritzBox. Zum Beispiel: NTP=192.168.1.1
Ich habe bereits diese Anpassung in meiner ioBroker-Installation vorgenommen, die auf demselben Raspberry Pi läuft.

Ebenso habe ich meine /etc/fstab für die SSD angepasst, siehe ioBroker mit Pi 4 und Manjaro.

---

---

Bevor du Unbound einrichtest, überprüfe, ob alles funktioniert, indem du in den Einstellungen -> DNS zum Beispiel die Checkboxen 'Quad9 (gefiltert, DNSSEC)' als Upstream DNS Server und 'Use DNSSEC' aktivierst. Beachte jedoch: Sobald du Unbound aktiviert hast, solltest du DNSSEC in den Pi-Hole-Einstellungen deaktivieren, da es in den Unbound-Einstellungen aktiviert wird.

Unbound kann wie folgt installiert werden, sobald Pi-hole einwandfrei funktioniert:

sudo pacman -Sy --needed unbound
Lege ein Unbound Log-Verzeichniss an und setze die korrekten Berechtigungen:
sudo mkdir -p /var/log/unbound/
sudo chown -R unbound:unbound /var/log/unbound/
Es wird empfohlen, die Hauptkonfigurationsdatei von Unbound nicht direkt zu bearbeiten. Stattdessen solltest du eine separate Konfigurationsdatei, beispielsweise pi-hole.conf, im Verzeichnis /etc/unbound/unbound.conf.d/ anlegen, um dort deine spezifischen Einstellungen vorzunehmen. Dies bietet auch den Vorteil, dass mehrere Konfigurationsdateien in diesem Verzeichnis erstellt werden können. Falls das Verzeichnis unbound.conf.d noch nicht existiert, erstelle es mit dem erforderlichen Befehl:
sudo mkdir -p /etc/unbound/unbound.conf.d/
Erstelle eine neue Unbound-Konfigurationdatei:
sudo nano /etc/unbound/unbound.conf.d/pi-hole.confFüge diese Daten ein und passe evtl. die "forward-zone" an:

Zitatserver:
    # If no logfile is specified, syslog is used
    # (e.g.: 'journalctl -u unbound' or 'journalctl -u unbound -p err')
    # logfile: "/var/log/unbound/unbound.log"
    verbosity: 0

    directory: "/etc/unbound"
    username: unbound  # root ->only for testing!

    interface: 127.0.0.1
    port: 5335
    do-ip4: yes
    do-udp: yes
    do-tcp: yes

    # May be set to yes if you have IPv6 connectivity
    do-ip6: yes

    # You want to leave this to no unless you have *native* IPv6. With 6to4 and
    # Terredo tunnels your web browser should favor IPv4 for the same reasons
    prefer-ip6: yes

    # Use this only when you downloaded the list of primary root servers!
    # If you use the default dns-root-data package, unbound will find it automatically
    root-hints: "/etc/unbound/root.hints"

    # The following line will configure unbound to perform cryptographic
    # DNSSEC validation using the root trust anchor
    auto-trust-anchor-file: "/etc/unbound/trusted-key.key"

    # Trust glue only if it is within the server's authority
    harden-glue: yes

    # Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes BOGUS
    harden-dnssec-stripped: yes

    # Don't use Capitalization randomization as it known to cause DNSSEC issues sometimes
    # see https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378 for further details
    use-caps-for-id: no

    # Reduce EDNS reassembly buffer size.
    # IP fragmentation is unreliable on the Internet today, and can cause
    # transmission failures when large DNS messages are sent via UDP. Even
    # when fragmentation does work, it may not be secure; it is theoretically
    # possible to spoof parts of a fragmented DNS message, without easy
    # detection at the receiving end. Recently, there was an excellent study
    # >>> Defragmenting DNS - Determining the optimal maximum UDP response size for DNS <<<
    # by Axel Koolhaas, and Tjeerd Slokker (https://indico.dns-oarc.net/event/36/contributions/776/)
    # in collaboration with NLnet Labs explored DNS using real world data from the
    # the RIPE Atlas probes and the researchers suggested different values for
    # IPv4 and IPv6 and in different scenarios. They advise that servers should
    # be configured to limit DNS messages sent over UDP to a size that will not
    # trigger fragmentation on typical network links. DNS servers can switch
    # from UDP to TCP when a DNS response is too big to fit in this limited
    # buffer size. This value has also been suggested in DNS Flag Day 2020.
    edns-buffer-size: 1232

    # Perform prefetching of close to expired message cache entries
    # This only applies to domains that have been frequently queried
    prefetch: yes

    # One thread should be sufficient, can be increased on beefy machines. In reality for most users running on small networks or on a single machine, it should be>
    num-threads: 1

    # Ensure kernel buffer is large enough to not lose messages in traffic spikes
    so-rcvbuf: 1m

    # Ensure privacy of local IP ranges
    private-address: 192.168.0.0/16
    private-address: 169.254.0.0/16
    private-address: 172.16.0.0/12
    private-address: 10.0.0.0/8
    private-address: fd00::/8
    private-address: fe80::/10

    # ADD
    # maximum number of simultaneous DNS requests (default: 150)
    num-queries-per-thread: 300
    #
    # "forward-zone" directs specific domain queries to designated upstream DNS servers
    # Adjust your IP addresses!
    forward-zone:
      name: "fritz.box"
      forward-addr: 192.168.1.1@53

Nach dem Speichern sollten die Berechtigungen angepasst werden (optional, aber empfohlen):
sudo chmod 644 /etc/unbound/unbound.conf.d/pi-hole.conf
Dieser Befehl lädt und aktualisiert die Root-Trust-Anchors für DNSSEC, die Unbound zur Validierung der Authentizität von DNS-Antworten benötigt, und speichert sie in der angegebenen Datei:
sudo unbound-anchor -a /etc/unbound/trusted-key.keyTesten:
sudo unbound-anchor -vErgebnis:

Zitat/etc/trusted-key.key has content
success: the anchor is ok

WICHTIG: Berechtigungen für den Ordner sowie alle Dateien und Unterverzeichnisse (rekursiv) für den Unbound-Benutzer festlegen:
sudo chown -R unbound:unbound /etc/unbound
Öffne die Unbound-Hauptkonfigurationsdatei:
sudo nano /etc/unbound/unbound.confErsetze den Inhalt der Hauptkonfigurationsdatei von Unbound mit den folgenden Zeilen, um sicherzustellen, dass alle zusätzlichen Konfigurationsdateien aus dem Verzeichnis "/etc/unbound/unbound.conf.d/" automatisch eingebunden werden:

Zitat# Unbound configuration file
#
# The following line includes additional configuration files from the
# /etc/unbound/unbound.conf.d directory.
include-toplevel: "/etc/unbound/unbound.conf.d/*.conf"

Die Konfiguration pi-hole.conf unterstützt sowohl IPv4 als auch IPv6. Unbound wird IPv6 bevorzugen (prefer-ip6: yes), aber auch IPv4 verwenden, falls notwendig. Einige der anderen Optionen in der Konfigurationsdatei stellen sicher, dass Unbound sicher und effizient arbeitet. Zum Beispiel werden private Adressbereiche aus Datenschutzgründen blockiert. Die Option 'control-enable: yes' in der Unbound-Konfiguration, wie im unten angegebenen Link zur Unbound-Dokumentation näher erläutert, ist für die grundlegende Einrichtung von Unbound als rekursiven DNS-Server in Verbindung mit Pi-hole nicht notwendig. Sie ist vielmehr für erweiterte Verwaltungsaufgaben gedacht, die über die typischen Anforderungen einer Pi-hole-Installation hinausgehen.

Gut zu wissen: 127.0.0.1 ist derselbe Localhost wie ::1. AAAA-Datensätze funktionieren über IPv4 genauso gut wie über IPv6. Der Client kann Pi-hole nach wie vor über IPv6 befragen. Ob Pi-hole die Anfrage über IPv4 oder IPv6 weiterleitet, ist unerheblich und ein "interface: ::1" nicht notwendig.

Daher wird nur die IPv4-Adresse mit Port des Unbound-DNS-Servers (127.0.0.1#5335) in das Feld "Custom 1 (IPv4)" in den Einstellungen von Pi-hole eingetragen.

"do-ip6: yes" in unbound's Konfiguration steuert, ob unbound IPv6 für das Stellen von DNS- Anfragen an seine Upstream-Servern verwenden soll, und ob unbound über IPv6 eingehende DNS-Anfragen beantwortet.

Verwende den Befehl curl, um die Root-Hints-Datei von der IANA-Website herunterzuladen und in das Unbound-Konfigurationsverzeichnis zu speichern:
sudo curl --output /etc/unbound/root.hints https://www.internic.net/domain/named.cache
Es gibt zwei Dateien, named.root und named.cache, die Informationen über die Stamm-DNS-Server bereitstellen, wobei named.root direkt von IANA stammt und weniger häufig aktualisiert wird, während named.cache von ICANN bereitgestellt wird und häufiger aktualisiert werden kann.
Am Ende beschreibe ich, wie du den Download mithilfe von systemd und einem Timer automatisieren kannst.

Überprüfe die spezifische Pi-hole-Konfiguration auf Syntaxfehler:
sudo unbound-checkconf /etc/unbound/unbound.conf.d/pi-hole.confDas Ergebnis sollte "no errors in /etc/unbound/unbound.conf.d/pi-hole.conf" sein.

Unbound aktivieren und starten:
sudo systemctl enable unbound
sudo systemctl start unboundUnbound Status prüfen:
sudo systemctl status unbound
Nachdem du diese Schritte ausgeführt hast, sollte der Unbound-Dienst auf Port 5335 verfügbar sein, und du kannst versuchen, die DNS-Auflösung zu testen:
dig pi-hole.net @127.0.0.1 -p 5335
Überprüfe ob DNSSEC funktioniert:
dig fail01.dnssec.works @127.0.0.1 -p 5335
dig dnssec.works @127.0.0.1 -p 5335Der erste Befehl sollte einen Statusbericht von SERVFAIL und keine IP-Adresse liefern. Der zweite sollte NOERROR plus eine IP-Adresse liefern.

Außerdem könnt Ihr den Resolver mit Drill wie folgt testen:
drill badsig.go.dnscheck.tools
drill go.dnscheck.toolsDer erste Befehl sollte einen rcode von SERVFAIL liefern. Der zweite Befehl sollte einen rcode von NOERROR liefern.

Obwohl DANE (DNS-based Authentication of Named Entities) eine wertvolle Sicherheitstechnologie darstellt, ist sie derzeit nicht so weit verbreitet oder unterstützt wie andere Sicherheitsmechanismen. So testest du DNSSEC-Validierung für eine bestimmte Domain:
dig @127.0.0.1 -p 5335 +dnssec +cd internet.nlHierbei fordert +dnssec die Authentifizierung von DNS-Daten unter Verwendung von DNSSEC an. +cd (Checking Disabled) deaktiviert die DNSSEC-Validierung und gibt jede Antwort zurück, auch wenn sie nicht authentifiziert wurde. Das erwartete Ergebnis ist eine DNS-Antwort, die zeigt, dass die Domain internet.nl erfolgreich mit DNSSEC signiert wurde. Achte besonders auf den "ad" (Authenticated Data) Flag in den Flags der Antwort:

Zitat...
;; flags: qr rd ra ad cd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
...

Ich habe einen Test auf meinem Hauptrechner durchgeführt, um die DNSSEC-Konfiguration des Mail-Providers Posteo.de zu überprüfen. Hierfür habe ich den folgenden Befehl verwendet:
dig posteo.de SOA +dnssecDieser Befehl fragt den SOA (Start of Authority)-Eintrag für posteo.de ab und fordert DNSSEC-Informationen an. Die Ausgabe des Befehls zeigt folgende wichtige Informationen:
...
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
...Das Vorhandensein des "ad"-Flags in der Antwort zeigt an, dass die DNS-Antwort für die SOA-Abfrage von posteo.de von DNSSEC validiert wurde und als sicher und authentisch gilt. Dies ist ein gutes Zeichen dafür, dass die Domain korrekt mit DNSSEC konfiguriert ist.

Um TLS-Verbindungen (HTTPS) zu verifizieren, nutze das Tool ldns:
ldns-dane -d verify posteo.de 443Das Ergebnis zeigt, ob die TLS-Verbindung zu posteo.de über Port 443 erfolgreich mit DANE validiert wurde:

Zitat185.67.36.168 dane-validated successfully
185.67.36.169 dane-validated successfully
2a05:bc0:1000::168:1 dane-validated successfully
2a05:bc0:1000::169:1 dane-validated successfully
2a05:bc0:1000:80::168:1 dane-validated successfully
2a05:bc0:1000:80::169:1 dane-validated successfully

Zusätzlich bietet die Webseite internet.nl eine einfache Möglichkeit, eine 'Domain signature validation' (DNSSEC) für eine beliebige Domain zu testen.

Fazit: Obwohl DANE eine zusätzliche Sicherheitsebene bieten kann, indem es TLS-Zertifikate direkt im DNS validiert, bleibt es eine weniger genutzte Technologie im Vergleich zu etablierten PKI-basierten Ansätzen. Dennoch ist es ein wichtiges Werkzeug im Arsenal zur Verbesserung der Internet-Sicherheit, insbesondere in Bereichen, wo ein hohes Maß an Kontrolle und Authentizität erforderlich ist.

Schließlich konfigurierst du Pi-hole so, dass es deinen rekursiven DNS-Server verwendet, indem du 127.0.0.1#5335 als Custom DNS (IPv4) angibst und alle anderen Upstream DNS Server deaktivierst.

Im Tab "DNS" der Pi-hole-Einstellungen aktiviere alle Kontrollkästchen außer DNSSEC:

• Never forward non-FQDN A and AAAA queries -> an
• Never forward reverse lookups for private IP ranges -> an
• Use DNSSEC -> aus, Unbound übernimmt die DNSSEC-Funktion!
• Verwende "Use Conditional Forwarding" nur, wenn Unbound nicht verwendet wird (siehe pi-hole.conf), z.B.:

• Local network in CIDR notation: 192.168.1.0/24
• IP address of your DHCP server (router): 192.168.1.1
• Local domain name (optional): fritz.box

Überprüfe ob die Namensauflösung für "fritz.box" korrekt funktioniert:
ping fritz.box

---

FritzBox mit Pi-Hole

Dieser Befehl auf deinem Manjaro-arm zeigt die IP-Adressen aller Netzwerkschnittstellen auf deinem System an:
ip addr show | grep inet | awk '{print $2}'Dieser Befehl zeigt nur die IP-Adresse der spezifischen Netzwerkschnittstelle "end0" von manjaro-arm an (kann auch in der FritzBox geprüft werden):
ip addr show dev end0 | grep inet | awk '{print $2}'Es scheint, dass die Bezeichnung "end0" anstatt "eth0" unter Manjaro-ARM für die Netzwerkschnittstelle verwendet wird. Dieser Befehl listet alle Netzwerkschnittstellen auf und zeigt ihre aktuellen Bezeichnungen an:
ip link show
Teste die IPv4- und IPv6-ULA-Adresse, indem du von einem anderen Rechner im selben Netzwerk aus einen Ping durchführst, z.B. so:
ping 192.168.1.42
ping -6 fd00::1111:5555:9cba:def1
Diese IPs trage ich in der FritzBox ein "Internet ->Zugangsdaten -> DNS-Server":
DNSv4-Server: 192.168.1.42
DNSv6-Server: fd00::1111:5555:9cba:def1
Bei DNS-Störungen auf öffentliche DNS-Server zurückgreifen: An



Vorteil: Funktioniert mit VPN Clients und Clients im Gastnetz und als Fallback. Kleiner Nachteil: Im Pi-hole Log seht ihr nur die FritzBox und nicht, welche Clients welche Anfragen stellen.

Überprüfe den genutzten DNS-Server im Fritz Online-Monitor (IP's habe ich entfernt):


Wer Clients sehen möchte, kann das unter "Heimnetz -> Netzwerk -> Netzwerkeinstellungen - IPv4-Einstellungen und IPv6-Einstellungen" einstellen.
Vorteil: Clients im Log anstatt der FritzBox. Nachteil: Damit ist leider nur ein DNS-Server möglich, also kein Fallback. Wenn der dann weg fällt, haben die Clients keinen DNS-Server mehr. VPN Clients und Clients im Gastnetz fragen die FritzBox als DNS und nicht das Pi-hole.

Unter Netzwerk lege ich die IP vom Raspberry Pi (z.B. 192.168.1.42) fest -> Diesem Netzwerkgerät immer die gleiche IPv4-Adresse zuweisen. Daher muss ich keine feste IP-Adresse über systemd-networkd einrichten. Das ist eine gängige Praxis und wird oft als "DHCP-Reservierung" oder "Statische DHCP-Zuweisung" bezeichnet. Dabei wird im Router für die MAC-Adresse des Raspberry Pi eine feste IP-Adresse hinterlegt. Jedes Mal, wenn der Pi eine DHCP-Anfrage sendet, antwortet der Router mit derselben IP-Adresse.

Nachtrag: Da die FritzBox nur IPv4-Adressen statisch zuweisen kann und keine integrierte Möglichkeit bietet, DHCP-Reservierungen für IPv6-Adressen, einschließlich ULAs, vorzunehmen, habe ich eine feste IPv4-Adresse und eine IPv6-Adresse als Unique Local Address (ULA) speziell für das lokale Netzwerk konfiguriert. ULAs sind innerhalb des Netzwerks eindeutig und werden nicht im Internet geroutet. In meiner FritzBox habe ich das ULA-Präfix für IPv6-Adressen manuell auf 'fd00::/64' festgelegt.

sudo nano /etc/systemd/network/10-static.network

Zitat[Match]
Name=end0

[Network]
Address=192.168.1.42/24  # Ersetze mit deiner festen IPv4-Adresse
Gateway=192.168.1.1      # Ersetze mit dem IPv4-Gateway, normalerweise die IP-Adresse deines Routers
DNS=192.168.1.1          # Ersetze mit der IP-Adresse deines bevorzugten DNS-Servers

Address=fd00::1111:5555:9cba:def1/64    # Ersetze mit deiner festen ULA-Adresse
DHCP=no
IPv6AcceptRA=no

Hierbei ist es wichtig zu beachten:

• Eine ULA ist spezifisch für IPv6. IPv4 verwendet stattdessen private Adressbereiche (wie 192.168.x.x).
• Das festgelegte ULA-Präfix in deiner FritzBox (fd00::/64) definiert den Bereich, aus dem du deine lokalen IPv6-Adressen auswählen kannst.
• Stelle sicher, dass deine Endgeräte IPv6-Adressen innerhalb dieses Präfixes verwenden, um im lokalen Netzwerk korrekt zu funktionieren.
• Die letzten beiden Zeilen sind nicht unbedingt erforderlich, aber sie sorgen dafür, dass keine automatische Konfiguration für IPv6 auf der Netzwerkschnittstelle stattfindet, wenn du bereits statische IPv6-Adressen manuell konfiguriert hast.

Starte dann systemd-networkd neu:
sudo systemctl restart systemd-networkdÜberprüfe nach dem Neustart des Dienstes, ob die IP-Adressen korrekt zugewiesen wurden:
ip addr show end0Teste die IPv4- und IPv6-ULA-Adresse, indem du von einem anderen Rechner im selben Netzwerk aus einen Ping durchführst, z.B. so:
ping 192.168.1.42
ping -6 fd00::1111:5555:9cba:def1

---

Konfiguration von sudoers und Erstellung von systemd-Services zur Automatisierung der Aktualisierung von root.hints in Unbound

Durch die Verwendung von systemd für die Aufgabenplanung wird der veraltete Cron-Job ersetzt. Stattdessen wird eine systemd "service" Einheit erstellt, die den Download der root.hints-Datei und die Aktualisierung im Verzeichnis /etc/unbound gemäß einem festgelegten Zeitplan durchführt. Wenn der Download erfolgreich ist, wird die alte root.hints-Datei durch die neue ersetzt. Wenn der Download fehlschlägt, bleibt die alte Datei unverändert.

Erstelle eine neue Datei im /etc/sudoers.d/ Verzeichnis:
sudo nano /etc/sudoers.d/unboundIn der neuen Datei fügst du die Regel ein, die dem unbound-Benutzer erlaubt, den reload-unbound.service ohne Passwort zu starten:

Zitatunbound ALL=(ALL) NOPASSWD: /bin/systemctl start reload-unbound.service

Es ist wichtig, dass die Pfade in der sudoers-Konfiguration genau mit den tatsächlichen Installationspfaden der Befehle auf deinem System übereinstimmen. Diese Datei sollte mit chmod 440 gesichert werden:
sudo chmod 0440 /etc/sudoers.d/unbound
Erstelle eine 'reload-unbound.service' Datei als separate systemd-Einheit, indem diese speziell für das Neuladen des Unbound-Dienstes verantwortlich ist. Für diese Aktion sind root-Berechtigungen erforderlich. Dies ermöglicht eine saubere Trennung und verbessert die Wartbarkeit deines Systems:
sudo nano /etc/systemd/system/reload-unbound.serviceFüge den folgenden Inhalt in die Datei ein:

Zitat[Unit]
Description=Reload Unbound service (need sudo)

[Service]
Type=oneshot
ExecStart=/bin/systemctl reload unbound.service

[Install]
WantedBy=multi-user.target

Erstelle ein 'update-root-hints.service' (ausgeführt als Benutzer unbound), der die root.hints Datei herunterlädt und aktualisiert, und dann den 'reload-unbound.service' startet:
sudo nano /etc/systemd/system/update-root-hints.serviceFüge den folgenden Inhalt in die Datei ein:

Zitat[Unit]
Description=Update root hints file and reload Unbound
After=network.target

[Service]
User=unbound
Group=unbound
ExecStart=/bin/sh -c 'rm -f /etc/unbound/root.hints.new; /usr/bin/curl --output /etc/unbound/root.hints.new https://www.internic.net/domain/named.cache && mv /etc/unbound/root.hints.new /etc/unbound/root.hints'
ExecStartPost=/bin/sudo /bin/systemctl start reload-unbound.service

[Install]
WantedBy=multi-user.target

In systemd wird standardmäßig davon ausgegangen, dass ein .timer-File den zugehörigen .service mit dem gleichen Namen startet. Erstelle eine .timer-Datei, die den Zeitplan für die Ausführung der Aufgabe festlegt:
sudo nano /etc/systemd/system/update-root-hints.timerFüge den folgenden Inhalt in die Datei ein:

Zitat[Unit]
Description=Run the update-root-hints.service monthly

[Timer]
OnCalendar=monthly
Persistent=true

[Install]
WantedBy=timers.target

Es wird allgemein empfohlen, die Root-Hints-Datei alle 3 bis 6 Monate zu aktualisieren. Der 'update-root-hints.service', der monatlich durch diesen Timer ausgelöst wird – eine konservative und sichere Herangehensweise –, führt nach erfolgreichem Update der root.hints Datei automatisch den 'reload-unbound.service' aus, um den Unbound-Dienst neu zu laden.

Aktiviere den systemd Timer, damit er bei jedem Systemstart automatisch ausgeführt wird:
sudo systemctl enable update-root-hints.timerStarte den Timer und den Service:
sudo systemctl start update-root-hints.timer
sudo systemctl start update-root-hints.service
Überprüfe den Status des "timer": Du kannst den Status des "timer" überprüfen, um sicherzustellen, dass er aktiv ist und ordnungsgemäß funktioniert:
sudo systemctl status update-root-hints.timer
Oder die Liste aller aktiven Timer-Einheiten von Systemd anzeigen:
sudo systemctl list-timers
Jetzt sollte der Timer den Service entsprechend dem definierten Zeitplan ausführen, und die Aufgabe zur Aktualisierung der root.hints-Datei wird von systemd verwaltet.

Bei einem Problem lässt sich 'update-root-hints.service' manuell so testen:
sudo systemctl start update-root-hints.serviceÜberprüfen auf mögliche Fehler:
journalctl -u update-root-hints.service
Wenn du Änderungen an systemd-Konfigurationsdateien vornimmst, solltest du die systemd-Konfiguration neu laden. Dies erreichst du mit dem Befehl 'sudo systemctl daemon-reload'. Anschließend solltest du den betroffenen Timer mit 'sudo systemctl restart update-root-hints.timer' neu starten.

---

Aktualisiere regelmäßig deine Paketlisten

Mindestens alle 6 Monate, idealerweise jedoch monatlich, solltest du deine Paketlisten aktualisieren. Verwende dazu die folgenden Befehle:

Für die Grundaktualisierung
sudo pacman -Syu
yay -Syu  # Achtung: 'sudo' wird hier nicht benötigt!

Optional: Aktualisiere die Blockierliste von Pi-hole:
pihole -g
Entferne nicht benötigte Pakete:
sudo pacman -Rsn $(pacman -Qdtq)
Optional: Leere den Cache:
sudo pacman -Scc
Überprüfe trusted-key.key
Diese Datei enthält einen Zeitstempel, wann sie zuletzt aktualisiert wurde:
cat /etc/unbound/trusted-key.keyDie Ausgabe der Datei enthält Einträge wie last_queried und last_success, die anzeigen, wann die Datei zuletzt abgefragt und erfolgreich aktualisiert wurde. Diese Informationen helfen zu bestimmen, wie aktuell die Trust-Anchor-Informationen in deinem Unbound-DNS-Resolver sind.

Überprüfe die Root Hints
Aktuellen Status überprüfen:
ls -l /etc/unbound/root.hintsManuelles Update, falls erforderlich:
sudo curl --output /etc/unbound/root.hints https://www.internic.net/domain/named.cache
Hinweis: Dies sollte nicht notwendig sein, wenn du eine .timer-Datei dafür eingerichtet hast.

Überprüfe Liste aller aktiven Timer-Einheiten von Systemd
sudo systemctl list-timers
Um die Berechtigungen für den Ordner /etc/unbound, einschließlich aller darin enthaltenen Dateien und Unterverzeichnisse, rekursiv auf den Benutzer und die Gruppe unbound zu setzen (falls die Berechtigungen geändert wurden), verwende den folgenden Befehl:
sudo chown -R unbound:unbound /etc/unbound
Systemdiagnose
Überprüfe den verfügbaren Speicherplatz:
df -hÜberwache die Systemressourcen:
htopDieses Tool zeigt eine kontinuierliche Liste der Netzwerkverbindungen und deren Bandbreitennutzung auf "end0" an:
sudo iftop -i end0Neustart deines Systems, z.B. nach einem Kernel-Update mit:
reboot
Oder schalte es aus, um beispielsweise die SSD durch ein Backup zu ersetzen. Falls du zwei SSDs verwendest:
shutdown -h 0

---

Testseiten:

• Pi-hole Testseite
• internet.nl/connection/
• rootcanary.org/test.html

Quellen:

• wiki.archlinux.org/title/Pi-hole
• aur.archlinux.org/packages/pi-hole-server
• wiki.archlinux.org/title/Unbound
• Pi-hole mit FritzBox
• CC2.tv: Weg mit dem Dreck!
• Dennis Schröder: Pi-hole Unbound
• Wiki: Domain Name System
• Mike Kuketz: Pi-hole: Einrichtung und Konfiguration mit Fritz!Box – AdBlocker Teil1
• Mike Kuketz: Pi-hole: Einrichtung und Konfiguration mit unbound – AdBlocker Teil2

Achtung: Die Links sind teilweise auf Linux Debian fixiert, dennoch können diese hilfreich sein.

Linux Pi-System Monitor

Da für RPi-Monitor (rpi2) bereits seit geraumer Zeit keine Updates mehr verfügbar sind und es ausschließlich für Debian entwickelt wurde, verwende ich ein kleines JavaScript. Dieses überwacht die CPU-Temperatur und die Betriebszeit eines Raspberry Pi-Systems und speichert diese Informationen regelmäßig in ioBroker-Datenpunkten. Wer mehr Informationen benötigt, kann das gerne als Vorlage nutzen und erweitern.

// V23.12.002
// Linux Pi-System Monitor
//
// Das Skript überwacht die CPU-Temperatur und die Uptime eines Raspberry Pi-Systems,
// und speichert diese Informationen regelmäßig in ioBroker-Datenpunkten,
// wobei die Temperatur auf eine Stelle und die Uptime auf zwei Stellen hinter dem Komma begrenzt wird.

var exec = require("child_process").exec;

// Pfad für die Datenpunkte
var dataPath = "javascript.0.linux-pi-system";

// Funktion zur Aktualisierung eines Zustands, falls vorhanden, oder zur Erstellung eines neuen Zustands
function updateOrCreateState(path, value, callback) {
    getObject(path, function (err, obj) {
        if (!err && obj) {
            // Der Zustand existiert bereits, aktualisiere ihn
            setState(path, value, true, callback);
        } else {
            // Zustand erstellen
            createState(path, value, true, callback);
        }
    });
}

// Funktion zur Speicherung der CPU-Temperatur
function saveCPUTemperature() {
    exec("cat /sys/class/thermal/thermal_zone0/temp", function (error, stdout, stderr) {
        if (!error) {
            // Umrechnung in Grad Celsius mit einer Stelle hinter dem Komma begrenzt
            var millikelvin = parseFloat(stdout.trim());
            var celsius = (millikelvin / 1000).toFixed(1);

            // Speichern des Wertes in ioBroker
            updateOrCreateState(dataPath + ".temperature", celsius, function () {});
        } else {
            log("Fehler beim Abrufen der CPU-Temperatur: " + error);
        }
    });
}

// Funktion zur Umrechnung der Uptime in Stunden und Speicherung
function saveUptime() {
    exec("cat /proc/uptime", function (error, stdout, stderr) {
        if (!error) {
            // Zerlegen des stdout-Strings und Umwandlung der ersten Zahl in Stunden
            var uptimeInSeconds = parseFloat(stdout.split(' ')[0]);
            var uptimeInHours = (uptimeInSeconds / 3600).toFixed(2);

            // Speichern des umgerechneten Wertes in ioBroker
            updateOrCreateState(dataPath + ".uptime", uptimeInHours, function () {});
        } else {
            log("Fehler beim Abrufen der Uptime: " + error);
        }
    });
}

// Initialer Aufruf der Funktionen
saveCPUTemperature();
saveUptime();

// Zeitplan für die regelmäßige Ausführung
schedule("*/5 * * * *", saveCPUTemperature); // Alle 5 Minuten die CPU-Temperatur abrufen und speichern
schedule("*/10 * * * *", saveUptime); // Alle 10 Minuten die Uptime abrufen und speichern


PS: Inzwischen ist der Adapter ioBroker.info DEPRECATED und ich nutze diesen nicht mehr.

Für mein Projekt nutze ich das Z-Wave Modul RaZberry 7 (ZME_RAZBERRY7)


Standardmäßig wird der UART des Raspberry Pi 4 vom integrierten Bluetooth-Modul belegt. Um den UART für die serielle Kommunikation über die GPIO-Pins – zum Beispiel für das Z-Wave Modul – freizugeben, sind spezifische Anpassungen in der Datei /boot/config.txt erforderlich. Durch diese Anpassungen wird das Bluetooth-Modul deaktiviert und der UART aktiviert:

sudo nano /boot/config.txt

Zitatdtoverlay=disable-bt
enable_uart=1

Zusätzlich sind Änderungen in der Datei /boot/cmdline.txt notwendig, um die serielle Kommunikation für das Z-Wave Modul zu konfigurieren:
sudo nano /boot/cmdline.txtEntferne den Eintrag "console=serial0,115200". Diese Änderung verhindert, dass der Serial Port für Konsolenausgaben genutzt wird, was für die Verwendung des Z-Wave Moduls entscheidend ist.

Nach diesen Anpassungen aktualisiere die Systembibliotheken und füge den Benutzer iobroker zur Gruppe uucp hinzu, um Zugriff auf den Serial Port zu gewähren:
sudo ldconfig
sudo usermod -a -G uucp iobroker
sudo rebootNach dem Neustart sind die Änderungen aktiv und der Serial Port ist für die Nutzung mit dem Z-Wave Modul bereit.

Die Gruppenmitgliedschaft des Benutzers iobroker kannst du mit dem folgenden Befehl überprüfen:
groups iobroker
Den Serial Port des RaZberry 7 Moduls findest du mit diesem Befehl:
ls -l /dev/ttyA*In meinem Fall ist es /dev/ttyAMA0, den ich im zwave2 Adapter von ioBroker als "Serielle Schnittstelle auswählen" eingetragen habe.

---

Achtung! Im ioBroker Backup sind keine Z-Wave Geräte enthalten. Nur mit Z-Way kann ein Backup vom Gateway der inkludierten Z-Wave Geräte erstellt werden.

Da Z-Way nicht über das AUR (Arch User Repository) für Manjaro verfügbar ist, habe ich das Razberry-System auf einer SD-Karte unter Debian 11 (Bullseye) installiert. Für die Erstinstallation auf einem neuen Raspberry Pi habe ich die Anleitung von Z-Wave.Me genutzt.

Die SD-Karte nutze ich ausschließlich für spezielle Aufgaben wie Firmware-Updates (Stand April 2023: Version 7.38), Backups und Wiederherstellungsprozesse des Razberry-Moduls. Um sie zu verwenden, stecke ich einfach die SD-Karte ein und trenne die USB-SSD, damit das System von der SD-Karte bootet. Dieses Verfahren erlaubt es mir, gezielte Wartungs- und Update-Aktionen durchzuführen, ohne dabei meine primäre Installation auf Manjaro zu beeinflussen.

Ich habe erfolgreich eine Migration von meinem alten RaZberry2 Z-Wave-Modul zum neuen RaZberry7 durchgeführt, indem ich die Backup- und Restore-Funktionen genutzt habe.

ioBroker manuell installieren, anstelle des Original-Installationsskripts

Falls du unter Manjaro-ARM unerwarteterweise Probleme mit dem Original-Installationsskript haben solltest (Punkt 4), kannst du alternativ diesen Installationsweg wählen.

a) Benutzer "iobroker" erstellen
Überprüfe, ob der Benutzer iobroker existiert und erstelle ihn, falls nicht:
id iobroker &>/dev/null || sudo useradd -m -s /usr/sbin/nologin iobrokerHinweis: Dieser Befehl erstellt einen Benutzer namens `iobroker` mit einem Home-Verzeichnis, aber ohne eine Login-Shell, was bedeutet, dass er sich nicht direkt anmelden kann. Prüfen mit:
id iobroker
Optional, die Zugriffsrechte anpassen:
sudo chmod -v 755 /home/iobroker(von 0700 in 0755)

Benutzer zur "iobroker"-Gruppe hinzufügen,um auf die ioBroker-Verzeichnisse zugreifen zu können:
sudo usermod -a -G iobroker $USERPrüfen mit:
id $USER
b) Installiere ioBroker

Das Original-Debian-Installationsskript von ioBroker setzt aktiv die Eigentümerschaft des ioBroker-Installationsverzeichnisses (/opt/iobroker) auf den Benutzer iobroker. Dies wird typischerweise mit dem Befehl "chown -R iobroker:iobroker /opt/iobroker" erreicht, um sicherzustellen, dass alle Dateien und Verzeichnisse korrekt dem iobroker-Benutzer zugewiesen sind.

In meinem alternativen Installationsansatz verwende ich eine temporäre Bash-Shell-Sitzung, die unter dem Benutzer iobroker läuft, um die Installationsbefehle auszuführen. Dadurch werden die Dateien von Beginn an unter dem korrekten Benutzer erstellt, was die nachträgliche Anpassung der Eigentümerschaft überflüssig macht. Installiere die Adapter nacheinander, um mögliche Probleme während der Installation leichter zu bewerkstelligen.

Wichtig: Nach erfolgreicher Installation von ioBroker sollten Befehle wie "npm install iobroker.zwave2", "iob stop", "iob fix" oder "reboot" ohne die Verwendung von sudo ausgeführt werden.

Installiere den ioBroker.js-Controller:
sudo su -s /bin/bash -c "cd /opt/iobroker && npm install iobroker.js-controller@stable --unsafe-perm --no-audit" iobroker

Admin-Adapter installieren:
sudo -u iobroker bash -c "cd /opt/iobroker && npm install iobroker.admin@stable --unsafe-perm --no-audit"(ja, diese kürzere Syntax funktioniert auch)

Web-Adapter installieren:
sudo -u iobroker bash -c "cd /opt/iobroker && npm install iobroker.web@stable --unsafe-perm --no-audit"
Backitup-Adapter installieren:
sudo -u iobroker bash -c "cd /opt/iobroker && npm install iobroker.backitup@stable --unsafe-perm --no-audit"
Discovery-Adapter installieren (nutze ich nicht):
sudo -u iobroker bash -c "cd /opt/iobroker && npm install iobroker.discovery@stable --unsafe-perm --no-audit"
Um ioBroker zu starten, kannst du den folgenden Befehl verwenden:
sudo -u iobroker /opt/iobroker/iobroker startErsteinrichtung von ioBroker durchzuführen:
sudo -u iobroker /opt/iobroker/iobroker setup first
Status des ioBroker-Controllers:
sudo -u iobroker /opt/iobroker/iobroker status
ioBroker Upgrade:
sudo -u iobroker /opt/iobroker/iobroker stop
sudo -u iobroker /opt/iobroker/iobroker update
sudo -u iobroker /opt/iobroker/iobroker upgrade self
sudo -u iobroker /opt/iobroker/iobroker upgrade
sudo -u iobroker /opt/iobroker/iobroker start
c) Systemstart ioBroker
Um ioBroker auf Manjaro so zu konfigurieren, dass es beim Systemstart automatisch startet, musst du einen systemd-Service manuell einrichten.

Service-Datei erstellen:
sudo nano /usr/lib/systemd/system/iobroker.serviceInhalt der Service-Datei:

Zitat[Unit]
Description=ioBroker Server
Documentation=http://iobroker.net
After=network.target redis.service influxdb.service mysql-server.service mariadb-server.service
Wants=redis.service influxdb.service mysql-server.service mariadb-server.service

[Service]
Type=simple
User=iobroker
Environment="NODE=$(which node)"
ExecStart=/usr/bin/bash -c '${NODE} /opt/iobroker/node_modules/iobroker.js-controller/controller.js'
Restart=on-failure
RestartSec=3s

[Install]
WantedBy=multi-user.target

Wichtig: Passe den 'ExecStart'-Pfad an deine Node.js-Installation an.

Berechtigungen setzen und Service aktivieren:
sudo chmod 644 /usr/lib/systemd/system/iobroker.service
sudo systemctl daemon-reload
sudo systemctl enable iobroker.service

Hinweis: Wenn du Änderungen an der Konfiguration vornehmen musst, kannst du die Service-Datei bearbeiten und danach "sudo systemctl daemon-reload" und "sudo systemctl restart iobroker.service" ausführen, um die Änderungen anzuwenden.

Erstelle den symbolischen Link:
sudo ln -s /usr/lib/systemd/system/iobroker.service /etc/systemd/system/multi-user.target.wants/iobroker.service
Überprüfe den Link:
ls -l /etc/systemd/system/multi-user.target.wants/iobroker.service

Starte den ioBroker-Dienst:
sudo systemctl start iobroker.service
Service-Status überprüfen:
sudo systemctl status iobroker.service(Beenden mit "Q")

Nachdem du diese Schritte abgeschlossen hast, sollte ioBroker automatisch starten, wenn dein System hochfährt. Wenn du Änderungen an der Konfiguration vornehmen musst, kannst du die Service-Datei bearbeiten und danach "sudo systemctl daemon-reload" und "sudo systemctl restart iobroker.service" ausführen, um die Änderungen anzuwenden.

d) Überprüfe oder passe die Sudo-Berechtigungen des ioBroker-Benutzers an:
sudo nano /etc/sudoers.d/iobrokerDiese sieht bei mir so aus:

Zitatiobroker ALL=(ALL) ALL
iobroker ALL=(ALL) NOPASSWD: /usr/sbin/shutdown
iobroker ALL=(ALL) NOPASSWD: /usr/sbin/halt
iobroker ALL=(ALL) NOPASSWD: /usr/sbin/poweroff
iobroker ALL=(ALL) NOPASSWD: /usr/sbin/reboot
iobroker ALL=(ALL) NOPASSWD: /usr/sbin/systemctl start
iobroker ALL=(ALL) NOPASSWD: /usr/sbin/systemctl stop
iobroker ALL=(ALL) NOPASSWD: /usr/sbin/mount
iobroker ALL=(ALL) NOPASSWD: /usr/sbin/umount
iobroker ALL=(ALL) NOPASSWD: /usr/sbin/systemd-run
iobroker ALL=(ALL) NOPASSWD: /usr/sbin/make
iobroker ALL=(ALL) NOPASSWD: /usr/sbin/ping
iobroker ALL=(ALL) NOPASSWD: /usr/sbin/setcap
iobroker ALL=(ALL) NOPASSWD: /usr/sbin/vcgencmd
iobroker ALL=(ALL) NOPASSWD: /usr/sbin/cat
iobroker ALL=(ALL) NOPASSWD: /usr/sbin/df
iobroker ALL=(ALL) NOPASSWD: /usr/sbin/ldconfig
ALL ALL=NOPASSWD: /usr/sbin/systemctl start iobroker
ALL ALL=NOPASSWD: /usr/sbin/systemctl stop iobroker
ALL ALL=NOPASSWD: /usr/sbin/systemctl restart iobroker
ALL ALL=(iobroker) NOPASSWD: /usr/sbin/node /opt/iobroker/node_modules/iobroker.js-controller/iobroker.js *

Der iobroker-Benutzer hat ohne Passworteingabe weitreichende Berechtigungen, darunter das Herunterfahren, Neustarten, Starten von Diensten und Ausführen von Befehlen auf dem System sowie spezielle Berechtigungen für den iobroker-Dienst. Es ist wichtig, dass die Pfade in der sudoers-Konfiguration genau mit den tatsächlichen Installationspfaden der Befehle auf deinem System übereinstimmen. Diese Datei sollte mit chmod 440 gesichert werden.
sudo chmod 444 /etc/sudoers.d/iobrokerWenn du die Datei bearbeiten möchtest, kannst du die Berechtigungen kurz auf chmod 644 setzen:
sudo chmod 644 /etc/sudoers.d/iobrokerNachdem du die erforderlichen Bearbeitungen vorgenommen hast, solltest du die Berechtigungen jedoch erneut auf chmod 444 setzen, um die Sicherheit der Datei zu gewährleisten.

Du kannst den ioBroker-Fixer ausführen, falls auf deinem System irgendwo noch Berechtigungen oder Einstellungen nicht korrekt gesetzt sind. Die Meldungen wie 'sudo: apt-get: Befehl nicht gefunden' im Abschnitt 'Installing prerequisites (1/5)' kannst du ignorieren, da sie nur unter Debian funktionieren und in diesem Fall nicht relevant sind. Falls benötigte Pakete fehlen, können sie mit 'pacman' installiert werden:
iob stop
curl -fsSL https://iobroker.net/fix.sh | bash -
iob start

Hier mein Ergebnis am Ende, nachdem durch den ioBroker-Fixer die Autostart-Funktion für den ioBroker-Dienst aktiviert wurde - hatte ich vergessen (Created symlink /etc/systemd/system/multi-user.target.wants/iobroker.service → /usr/lib/systemd/system/iobroker.service):

ZitatYour installation was fixed successfully
Run iobroker start to start ioBroker again!

ioBroker kann nun über die IP im Webbrowser aufgerufen werden http://<IP-Adresse>:8081 und eingerichtet werden.

Prolog

Derzeit hört man viel über ioBroker im Vergleich zu Home Assistant. Bezüglich Home Assistant kann ich nicht viel sagen, außer dass ioBroker dank seiner Blockly-Steuerungen in Kombination mit VIS und den Datenpunkten mit Abstand meine Top-Features sind. Der Nachfolger von VIS, VIS2 (derzeit in der Beta-Phase), soll außerdem Responsive Design ermöglichen. Dieses Feature würde ich in Home Assistant sehr vermissen, aber das ist natürlich rein meine persönliche Meinung.

Was den Matter und Thread Hype betrifft, es klingt vielversprechend, aber für mich scheint es noch in der Beta-Phase zu sein. Einige Hersteller bieten Matter bereits mit Bridges dafür an, obwohl sie eigentlich nicht notwendig wären. Daher werde ich bei WLAN-Geräten und Z-Wave-Geräten bleiben, insbesondere bei batteriebetriebenen Geräten. Dies entspricht im Prinzip Thread, allerdings verwendet Z-Wave für den Heimbereich die vorteilhaftere Frequenz von 868 MHz (EU) und zeichnet sich durch eine besonders hohe Energieeffizienz aus, die sogar geringeren Stromverbrauch als ZigBee-Geräte aufweist, was es besonders für batteriebetriebene Geräte geeignet macht.

Ich verstehe nicht, warum manche ioBroker auf Windows PCs oder Macs installieren möchten. Für einen stabilen Dauerbetrieb (24/7) ist ein headless Server unerlässlich. Er garantiert höhere Stabilität und Effizienz, da keine grafische Oberfläche Systemressourcen beansprucht. Deshalb sollte für optimalen Betrieb von ioBroker auf spezialisierte Serverlösungen zurückgegriffen werden.

Für ein stets aktuelles und sicheres SmartHome-System ist es wichtig, das Betriebssystem regelmäßig zu aktualisieren. Bei Diensten wie ioBroker, die auf Debian basieren, empfiehlt es sich, alle 2-4 Jahre ein Update des LTS Debian-Systems durchzuführen. Dies kann entweder durch eine komplette Neuinstallation oder durch den Wechsel zu einem Rolling-Release-Betriebssystem wie Manjaro, welches ich derzeit teste, erfolgen. Die regelmäßige Aktualisierung ist nicht nur für die Sicherheit essenziell, sondern auch für die Funktionsfähigkeit der SmartHome-Geräte.

SmartHome-Gadgets können zwar Spaß machen und potenziell zur Energieeinsparung beitragen, wie zum Beispiel durch Funk Heizkörperregler, aber sie können konventionelle Technik, die jahrzehntelang ohne Batteriewechsel und Updates funktioniert, nicht vollständig ersetzen. Zudem besteht das Risiko, dass Produkte minderer Qualität nach einigen Jahren ausfallen und durch inkompatible Nachfolgemodelle ersetzt werden müssen. Daher sollte stets die Frage nach der Sicherheit und der Zuverlässigkeit ohne SmartHome-Funktionen gestellt werden.

Unabhängig vom verwendeten SmartHome-System sind regelmäßige Updates, idealerweise monatlich oder mindestens nach 6 Monaten, unerlässlich. Bei Debian ist spätestens nach fünf Jahren ein Wechsel des LTS-Release erforderlich. Wer diese Aktualisierungen vernachlässigt, handelt grob fahrlässig. Der Grundsatz 'Never change a running system' ist in diesem Kontext nicht anwendbar.

Debian veröffentlicht seine Stable-Releases regelmäßig und bietet nach der Veröffentlichung drei Jahre vollständige Unterstützung, gefolgt von zwei weiteren Jahren LTS-Unterstützung. Derzeit ist das Debian 12 Bookworm (Oktober 2023) und ich nutze Debian 11 Bullseye mit ioBroker, was noch ca. 2 Jahre mit Sicherheitsupdates versorgt werden soll. Ehrlich gesagt, habe ich wenig Lust, zum dritten Mal ein Betriebssystem-Upgrade durchzuführen. Aus diesem Grund betreibe ich ioBroker auf einem zweiten Raspberry Pi 4 (Architektur: ARMv8 Cortex-A72) mit 8 GB RAM. Die Installation erfolgt unter Linux Manjaro in der ARM-Minimal-Version 64bit für Raspberry, speziell in der Headless-Variante ohne grafische Benutzeroberfläche (GUI). Als Speichermedium verwende ich eine externe SSD. Dieses Setup ermöglicht es mir, vom Rolling-Release-Prinzip zu profitieren, wodurch ich kontinuierlich volle Unterstützung sowie aktuelle Kernel und Pakete erhalte.

Ich möchte betonen, dass Debian als LTS ein äußerst solides und stabiles System ist. Bitte nehmt meinen Thread daher nicht falsch auf. Manjaro-ARM ist ebenfalls ein sehr solides und stabiles System, jedoch muss dieses in der Regel nur einmal installiert werden. Es ist wichtig zu beachten, dass ioBroker Manjaro nicht unterstützt. Wenn dies ein Problem darstellt, sollte man auf jeden Fall bei Debian bleiben.

Warum den Raspberry Pi 4 anstelle des Pi 5 wählen? Der Raspberry Pi 4 ist für einen "normalen" ioBroker Betrieb völlig ausreichend, selbst wenn du zusätzlich Pi-hole installierst und ihn als Fileserver nutzt. Du kannst ihn auch ohne Lüfter mit einem großem passiven Kühlkörper betreiben und dennoch eine gute Leistung bei unter 40 Grad Celsius CPU-Temperatur im Normalbetrieb erzielen. ioBroker mit einem Z-Wave Modul RaZberry7 und externer SDD T5 benötigt im normalen Betrieb bei mir unter 1 Ampere, und kurz 1,5 - 2,0 Ampere bei Schreibvorgängen oder höher CPU Last. Der Pi 5 hingegen verbraucht mehr Strom und sollte mit einem Lüfter betrieben werden. Ein leistungsstärkerer PC als der Pi 4 würde nur Sinn machen, wenn du mehr als nur ioBroker installieren möchtest, wie zum Beispiel NextCloud, Livestreaming oder kleinen Matrix Server.

Wer bereits Erfahrungen mit einer solchen Umsetzung hat oder ebenfalls Interesse an diesem Vorhaben zeigt, ist herzlich eingeladen, sich hier zu melden und seine Gedanken oder Tipps zu teilen. Ich freue mich auf einen regen Austausch via Matrix: #RPI-Manjaro-arm:tchncs.de



Leider existiert kein Installations-Skript von ioBroker für Linux Manjaro. Daher veröffentliche ich meine "experimentelle" Anleitung hier in meinem Blog, in der ich beschreibe, wie ich ioBroker mit dem Debian Installations-Skript installiert habe. Bitte beachte, dass diese Methode nicht für den produktiven Einsatz empfohlen wird. Ich selbst habe Manjaro erst eingesetzt, nachdem ich ausführliche Tests durchgeführt hatte.


Versuchsaufbau: Raspberry Pi 4, der mit Manjaro-ARM (headless) installiert ist und zusätzlich Pi-hole mit Unbound, sowie ioBroker mit einem Z-Wave-Modul betreibt, angeschlossen an einer 12-Volt USV.

---

INHALT

• Manjaro ARM auf Raspberry Pi 4 installieren
• Manjaro ARM optimieren
• Node.js installieren
• ioBroker installieren
• Problemlösungen
• System Updates

1. Manjaro ARM auf einem Raspberry Pi 4 installieren

Hier beschreibe ich meine Methode, Manjaro ARM auf einem Raspberry Pi 4 mit einer SSD unter Verwendung eines Linux Manjaro-Systems zu installieren. Lade zuerst die Manjaro-ARM-minimal-rpi4-Datei von manjaro.org/download herunter. Im September 2023 war das die Version 23.02:

Choose Architecture: ARM -> DEVICE OPTIONS: "RASPBERRY PI 4B ..." -> Minimal -> Manjaro-ARM-minimal-rpi4-23.02.img.xz (ca. 430 MB)

Nach dem Herunterladen entpacke die Datei. Du erhältst dann die Datei "Manjaro-ARM-minimal-rpi4-23.02.img" (ungefähr 3 GB). Anschließend musst du dieses Image auf eine SD-Karte flashen. Dieser Prozess ist vergleichbar mit dem Flashen anderer Systeme, beispielsweise unter Verwendung von Tools wie Unetbootin oder SUSE Studio Imagewriter.

Ich habe das Image "Manjaro-ARM-minimal-rpi4-23.02.img" auf eine Samsung SSD T5 geschrieben, indem ich den SUSE Studio Imagewriter verwendet habe. Die Ethernet-Verbindung (LAN) in einem DHCP-Netzwerk funktioniert direkt und ist der beste Weg, um einen Internetzugang zu erhalten. Starte den Raspberry Pi mit dem angeschlossenen LAN-Kabel. Nach einigen Sekunden ist der Systemstart abgeschlossen.

Um die IP-Adresse deines Raspberry Pi in deinem lokalen Netzwerk zu finden, kannst du entweder in deinem Router nachsehen oder den Befehl
arp-scan --localauf einem Linux-Computer ausführen. Im Router habe ich diesem Netzwerkgerät immer die gleiche IPv4-Adresse zugewiesen.

Sobald du das Gerät gefunden hast, verwende SSH im Terminal, um eine Verbindung zum Raspberry Pi herzustellen:
ssh root@192.168.x.yBeim ersten Login wird ein neuer SHA256 Fingerprint erstellt, dann erscheint ein Assistent um die Manjaro ARM Installation abzuschließen, Beispiel:

Finish Manjaro ARM Install

• Choose your keyboard layout: de
• Enter disired username: pi4m
• Enter additionale groups: keine weiteren (default ist vorerst ausreichend)
• Enter disired Full Name: Manjaro
• Enter new Password: xxxxxxxxxxxx
• Enter new Root Password: xxxxxxxxxxxxxxxxxxx  -> ja, es ist ein Root-Benutzer vorhanden (su)
• Choose you timezone: Europe/Berlin
• Choose your locale: de_DE.UTF-8
• Choose desired hostname: manjaro-arm

Versucht, keinen Punkt auszulasssen, denn jedes Mal, wenn die Angabe falsch ist, beginnt der Assistent wieder von vorne, was möglicherweise frustrierend sein kann.

Schließlich gibt der Assistent eine Bestätigungsliste aus. Überprüft, ob alles korrekt ist. Die Grundkonfiguration dauert nur wenige Sekunden. Danach wird das System die Größe der SSD anpassen und einen Neustart durchführen. Nach dem Neustart ist das System bereit und mit den von dir vorgenommenen Einstellungen einsatzbereit.

Mit dem von dir gewählten Benutzernamen und SSH kannst du dich nun anmelden und das System aktualisieren.
ssh pi4m@192.168.x.yBeim ersten Aktualisieren kannst du die Spiegelserver (Mirrors) für Pacman auf Server in Deutschland, Frankreich und Österreich beschränken, alles aktualisieren und nur die zwei neuesten Versionen jedes Pakets im Cache behalten. Hier ist der Befehl:
sudo pacman-mirrors --country Germany,France,Austria && sudo pacman -Syyuu && sudo paccache -rk2Wenn du aufgefordert wirst, "rpi-eeprom durch extra/rpi4-eeprom ersetzen? [J/n]" und du ein Raspberry Pi 4 verwendest, dann ist es in der Regel eine gute Idee, diese Frage mit "J" (default) für Ja zu beantworten und das rpi-eeprom-Paket durch das rpi4-eeprom-Paket zu ersetzen.

Bei "raspberrypi-utils und raspberrypi-userland-aarch64-git stehen miteinander in Konflikt (raspberrypi-firmware). raspberrypi-userland-aarch64-git entfernen? [j/N]" habe ich mit "J" beantwortet.

Für zukünftige Aktualisierungen:
sudo pacman -Syyuu && sudo paccache -rk2Der Befehl aktualisiert auch das linux-rpi4-Paket auf deinem Manjaro ARM-System und kann damit den Kernel auf eine neuere Version anheben, wenn eine solche in den Repositories verfügbar ist. Die Version eines Kernel-Pakets kann mit 'pacman -Si linux-rpi4' überprüft werden.

Diese Befehle aktualisieren dein System und behalten nur die zwei neuesten Versionen jedes Pakets im Cache, um Speicherplatz zu sparen. Verwaiste Pakete entfernen:
sudo pacman -Rsn $(pacman -Qdtq)Optional alle Pakete im Pacman Cache vollständig entfernen:
sudo pacman -Scc
Installiere die folgenden Pakete, falls sie auf deinem System noch nicht vorhanden sind, z.B.um das Build-Umfeld und zusätzliche Tools bereitzustellen:
sudo pacman -S --needed acl avahi base-devel cairo cmake curl gcc giflib git htop iftop libcap libjpeg-turbo librsvg lm_sensors make neofetch net-tools pam pango pkgconf systemd-libs unzip sqlite cifs-utils nfs-utils
Version prüfen:
lsb_release -a

ZitatLSB Version:    n/a
Distributor ID: Manjaro-ARM
Description:    Manjaro ARM Linux
Release:        23.02
Codename:      n/a

oder:
neofetch

htop

Den Raspberry Pi neu starten:
sudo rebootoder ausschalten:
sudo shutdown -h 0

2. Manjaro ARM optimieren

Headless, prüfen, ob dein Manjaro-System im Headless-Modus (ohne grafische Benutzeroberfläche) betrieben wird:
systemctl get-defaultWenn das Ergebnis "graphical.target" liefert, bedeutet das, dass dein System standardmäßig in einer grafischen Umgebung (GUI) startet. Mit dem Befehl
sudo systemctl set-default multi-user.targetstellst du das System so ein, dass es im Headless-Modus startet, also ohne grafische Benutzeroberfläche (GUI). Dieser Modus eignet sich besonders für Server, da er weniger Ressourcen beansprucht, die sonst für die GUI benötigt würden. Ein weiterer Vorteil ist die erhöhte Stabilität, da weniger Komponenten vorhanden sind, die potenziell abstürzen oder Probleme verursachen könnten (zurück zur GUI: 'sudo systemctl set-default graphical.target').

Überprüfe, ob die Änderung erfolgreich war, indem du den folgenden Befehl ausführst:
systemctl get-defaultDieser Befehl sollte jetzt "multi-user.target" als Antwort geben. Starte das System neu:
sudo reboot
Im Headless-Modus, lassen sich spezifische Funktionen, die vorrangig für grafische Ausgaben oder Audio relevant sind, deaktivieren, um Systemressourcen zu schonen. Entsprechend habe ich solche Funktionen sowie WiFi und BT, was ich nicht benötige, in den Einstellungen deaktiviert:
sudo nano /boot/config.txt

Zitat# gpu_mem=64
auto_initramfs=1
arm_64bit=1
disable_overscan=1
# dtparam=krnbt=on

# disable sound
dtparam=audio=off
# hdmi_drive=2

# disable vc4
# dtoverlay=vc4-kms-v3d
# max_framebuffers=2
disable_splash=1

[all]
dtoverlay=disable-wifi
dtoverlay=disable-bt

NTP, als Zeitserver nutze ich den von der FritzBox, z.B.:
sudo nano /etc/systemd/timesyncd.conf

ZitatNTP=192.168.1.1

SSD, um die Lebensdauer deiner SSD zu verlängern, kannst du bei EXT4-Dateisystemen die Option "noatime" in die fstab-Datei einfügen. Ein Beispiel hierfür wäre:
sudo nano /etc/fstab

Zitat# <file system> <dir> <type> <options> <dump> <pass>
PARTUUID=d42a0555-01  /boot  vfat    defaults,noexec,nodev,showexec    0  0
PARTUUID=d42ba555-02  /  ext4    defaults,noatime    0  1

Dieser Eintrag verhindert, dass das System bei jedem Lesezugriff die Zugriffszeit (atime) aktualisiert, was die Anzahl der Schreibvorgänge auf der SSD reduziert. Starte das System neu:
sudo reboot
TMPFS, da Manjaro ARM auf systemd basiert und tmpfs zur Konfiguration von /tmp verwendet, entfällt die manuelle Einrichtung in der /etc/fstab-Datei. Du kannst dies kurz überprüfen, indem du
df -hausführst (tmpfs schont die SSD und erhöht die Geschwindigkeit).

TRIM, die Ausgabe des Befehls
sudo systemctl status fstrim.timerzeigt an, dass der TRIM-Timer aktiviert und eingerichtet ist. Der Timer ist so konfiguriert, dass er einmal pro Woche (standardmäßig) ausgeführt wird, um nicht mehr benötigte Blöcke auf der SSD freizugeben. Befehl um die SSD manuell zu trimmen:
sudo fstrim -a -v
LED (optional deaktivieren), auf einem Manjaro Arch-System mit systemd kannst du einen systemd-Service erstellen, um die rote LED (Power-LED = PWR) bei jedem Systemstart auszuschalten. Mit Root-Rechten (su) lässt sich die LED zwar mit dem Befehl "echo 0 > /sys/class/leds/PWR/brightness" ausschalten, jedoch wird sie nach einem Neustart des Systems wieder aktiviert. Um sicherzustellen, dass die rote LED bei jedem Systemstart deaktiviert wird, erstelle eine systemd-Service-Datei:
sudo nano /etc/systemd/system/disable-pwr-led.serviceFüge den Inhalt für den Service hinzu:

Zitat[Unit]
Description=Disable the PWR LED on Raspberry Pi

[Service]
Type=oneshot
ExecStart=/bin/sh -c "echo 0 > /sys/class/leds/PWR/brightness"

[Install]
WantedBy=multi-user.target

Speichere und schließe den Editor und aktiviere den Service:
sudo systemctl enable disable-pwr-led.serviceStarte den Service oder das System neu um zu testen, ob der Service funktioniert, kannst du ihn manuell starten oder einfach dein System neu starten. Um den Service zu starten, verwende:
sudo systemctl start disable-pwr-led.serviceOder starte dein System neu, um zu sehen, ob der Service beim Booten korrekt ausgeführt wird. Durch diesen systemd-Service wird sichergestellt, dass der Befehl zum Ausschalten der LED bei jedem Systemstart ausgeführt wird.

Bitte beachte, dass sich der Name für die LED in einem früheren Update geändert hat. Falls sich der Name in Zukunft wieder ändert, stell sicher, dass du den aktuellen Namen verwendest. Um die im System verfügbaren LEDs aufzulisten, verwende folgenden Befehl:
ls /sys/class/leds/

ZitatACT  default-on  mmc0  mmc0::  PWR

Update des Raspberry Pi EEPROM
sudo rpi-eeprom-update -aEs ist wichtig zu beachten, dass das Aktualisieren des EEPROMs ein kritisches Verfahren ist, da es die Firmware und Konfigurationseinstellungen ändern kann. Durch Hinzufügen der "-a" oder "--stable" Option wird sichergestellt, dass nur die stabile Version des EEPROMs heruntergeladen und aktualisiert wird, wenn eine solche verfügbar ist.

Protokolldaten von Pacman auslesen
sudo cat /var/log/pacman.logARL (Arch Rollback Machine) Fehlerprotokoll auslesen
sudo cat /var/log/pacman.log | grep "ARL"

Prüfen ob systemd-Dienste fehlgeschlagen sind
systemctl --failed
Fehler Protokoll seit gestern
journalctl -p err --since yesterday
Journal Protokoll von - bis
journalctl --since "20:30:00" --until "20:42:00"
Löschen aller Protokolldaten
sudo journalctl --rotate
sudo journalctl --vacuum-time=1sDer erste Befehl dreht die Protokoll-Dateien und erstellt neue. Der zweite Befehl löscht alle Protokolldaten, die älter als eine Sekunde sind. Du kannst die Zeitspanne nach Bedarf anpassen.


3. Node.js installieren

Die Installation von ioBroker erfolgt in zwei Schritten, zuerst wird Node.js installiert, anschließend folgt die Installation von ioBroker selbst. Um auf einem Manjaro ARM-System eine bestimmte Version von Node.js, wie beispielsweise Version 18.x, zu installieren, wäre der Node Version Manager (NVM) eine praktische Wahl. Allerdings unterstützt ioBroker offiziell keine Verwendung von NVM.

Deswegen installieren wir eine LTS-Version von Node.js aus den Manjaro-Paketquellen. Seit April 2023 empfiehlt ioBroker die LTS-Version von Node.js 18.x, die unter Manjaro als nodejs-lts-hydrogen bekannt ist. Zum Zeitpunkt dieses Beitrags war 18 die aktuelle Version. Um diese Version zu installieren, kannst du den folgenden Befehl verwenden:

sudo pacman -S nodejs-lts-hydrogen npm(V20: nodejs-lts-iron, V18: nodejs-lts-hydrogen, V16: nodejs-lts-gallium, V14: nodejs-lts-fermium, V12: nodejs-lts-erbium)

Hinweis: Sobald ioBroker die LTS-Version von Node.js 20.x empfiehlt, werde ich diese testen. Zuerst werde ich die V18 deinstallieren und dann die V20 wie folgt installieren:
iob stop && iob update && iob upgrade self && iob upgrade
sudo pacman -Syyuu
sudo pacman -Rns nodejs-lts-hydrogen npm
sudo pacman -S nodejs-lts-iron npm
sudo paccache -rk2
reboot

Um ioBroker erfolgreich auszuführen, musste ich npm (Node Package Manager) explizit installieren. Andernfalls erhielt ich Fehlermeldungen im Webinterface des ioBroker-Admins, wie "Cannot check node.js/npm version", und in der Terminalabfrage von "sudo systemctl status iobroker.service" wurde der Fehler "Cannot get NPM version: Command failed: npm -v" angezeigt, obwohl "npm -v" in der Konsole eine Rückmeldung gab.

Bei Bedarf, verwende diesen Befehl um Informationen über das installierte Paket zu erhalten.
pacman -Qi nodejs-lts-hydrogen
Wenn du bereits Node.js (lts-hydrogen) auf deinem System installiert hast und dann npm hinzufügst, sollte npm automatisch die richtige Version installieren (zumindest war das bei mir der Fall). Es ist jedoch nicht klar, wie Arch/Manjaro mit dieser Konfiguration umgeht, da sie nach Node.js Previous Releases nicht immer kompatibel sind, insbesondere wenn eine LTS-Version verwendet wird.
Nachtrag: Gemäß dem Github-Eintrag arbeitet das npm-Team an der Integration von npm 10 in Node.js 20 und 18. Die Veröffentlichung von npm 10 in Node.js 18.20 ist voraussichtlich für Oktober 2023 geplant. Manjaro-ARM ist in Bezug auf die npm-Version wahrscheinlich etwas schneller. Ich hoffe, dass ioBroker damit keine Probleme hat, deshalb ist für mich alles noch "experimentell".

Überprüfe die Node.js-Version:
node -vAusgabe: v18.18.0
npm -vAusgabe: v10.2.4

OPTIONAL: Wenn du beim Ausführen von "npm -v" die Meldung "Kommando nicht gefunden" erhältst, musst du wahrscheinlich npm zum PATH hinzufügen. Finde zuerst den Pfad zu npm heraus, indem du den folgenden Befehl ausführst:
sudo find / -name npm
Bearbeite deine Shell-Konfigurationsdatei (die Datei hängt von der verwendeten Shell ab, z.B. ~/.bashrc, ~/.bash_profile, ~/.zshrc, je nachdem, welche Shell du benutzt). Du kannst einen Texteditor verwenden, um die Datei zu öffnen, z.B.:
nano ~/.bashrc
Am Ende der Datei füge die folgende Zeile ein, die du aus dem vorherigen Schritt gefunden hast und passe den 'export PATH' an:

Zitat# Setze den PATH für npm
export PATH=/usr/lib/node_modules/corepack/shims:$PATH

Aktualisiere deine aktuelle Shell-Sitzung:
source ~/.bashrc
Überprüfe nun die Installation von npm, um sicherzustellen, dass sie korrekt konfiguriert ist:
npm -v

4. ioBroker installieren

Die Empfehlung, ioBroker nicht als root-Benutzer zu installieren, ist sehr wichtig, um Sicherheitsprobleme zu vermeiden! Das Ausführen der Installation muss als ein normaler User durchgeführt werden, durch diesen User wird auch das System zukünftig administriert. Der normale User sollte, nicht iobroker heißen, es sollte der bei der Basisinstallation, angelegte User sein. Der Hauptgrund für die Verwendung eines separaten Benutzers für ioBroker ist, dass dieser Benutzer eingeschränkte Rechte hat im Vergleich zum root-Benutzer oder deinem Hauptbenutzer. Dies verringert das Sicherheitsrisiko, falls es zu einem Einbruch in das System über ioBroker kommt.

Das Original-Installationsskript von ioBroker, setzt aktiv die Eigentümerschaft des ioBroker-Installationsverzeichnisses (/opt/iobroker) auf den Benutzer iobroker. Dies wird typischerweise mit dem Befehl "chown -R iobroker:iobroker /opt/iobroker" erreicht, um sicherzustellen, dass alle Dateien und Verzeichnisse korrekt dem iobroker-Benutzer zugewiesen sind.

Der effizienteste und schnellste Weg besteht darin, das Original-Installationsskript (Einzeiler) zur Installation von ioBroker zu verwenden. Sollte es unter Manjaro Probleme damit geben, kannst du ioBroker manuell installieren, wie ich im nächsten Thread (ioBroker manuell installieren, anstelle des Original-Installationsskripts) erläutern werde.
curl -sL https://iobroker.net/install.sh | bash -
Die Meldungen wie 'sudo: apt-get: Befehl nicht gefunden' im ersten Abschnitt kannst du ignorieren (Installing prerequisites 1/4), da sie nur unter Debian funktionieren und in diesem Fall nicht relevant sind. Falls benötigte Pakete fehlen, können sie stattdessen mit 'pacman' installiert werden. Wir haben bereits alle wichtigen Pakete im ersten Abschnitt installiert.

Am Ende kannst den Service-Status überprüfen:
sudo systemctl status iobroker.service(Beenden mit "Q")

Sollte dieser wider Erwarten nicht gestartet sein, starte den ioBroker-Service mit folgendem Befehl:
sudo systemctl start iobroker.service
ioBroker kann nun über die IP im Webbrowser aufgerufen werden http://<IP-Adresse>:8081 und eingerichtet werden:


Optional, die Zugriffsrechte anpassen:
sudo chmod -v 755 /home/iobroker(von 0700 in 0755)

 


5. Solltest du Probleme mit ioBroker haben, könnte es hilfreich sein, diese Tools zu nutzen oder die Parameter zu überprüfen

Diese beiden ioBroker-Tools funktionieren in den meisten Fällen auch unter Linux Manjaro-ARM, mit Ausnahme weniger Prüfungen, die spezifisch für Debian-Systeme entwickelt wurden (z.B. dpkg).

Das Diagnoseskript von Thomas Braun für ioBroker dient dazu, benötigte Informationen in Threads im ioBroker-Forum strukturiert und kompakt zusammenzufassen. Das Skript liest nur Informationen und verändert nichts.
iob diag
Der ioBroker-Fixer überprüft und korrigiert Systemrechte sowie führt andere Aufgaben aus.
iob stop && iob fixAlternativ kannst du den ioBroker-Fixer auch aus dem Internet herunterladen und ausführen:
iob stop && curl -fsSL https://iobroker.net/fix.sh | bash -
############

Der Befehl systemctl status iobroker.service überprüft und zeigt den aktuellen Betriebsstatus des iobroker.service auf dem Linux-System an, das Systemd verwendet, z.B.:
sudo systemctl status iobroker.service
● iobroker.service - ioBroker Server
    Loaded: loaded (/usr/lib/systemd/system/iobroker.service; enabled; preset: disabled)
    Active: active (running) since Sun 2023-12-12 14:42:11 CET; 7h ago
      Docs: http://iobroker.net
  Main PID: 476 (iobroker.js-con)
      Tasks: 185 (limit: 9279)
        CPU: 2h 25min 24.513s
    CGroup: /system.slice/iobroker.service
            ├─ 476 iobroker.js-controller
            ├─ 560 io.admin.0
            ├─ 648 io.javascript.0
            ├─ 733 io.email.0
            ├─ 849 io.ping.0
            ├─ 878 io.shelly.0
            ├─ 896 io.tr-064.0
            ├─ 927 io.info.0
            ├─ 998 io.zwave2.0
            ├─1097 io.fullybrowser.0
            ├─1252 io.simple-api.0
            ├─1580 io.web.0
            ├─1591 io.yahka.0
            └─3790 io.backitup.0
(Beenden mit "Q")

############

Überprüfe nicht nur die Shell-Konfigurationsdatei des Hauptbenutzers (siehe Punkt 3), sondern auch die vom "iobroker", um sicherzustellen, dass der Pfad korrekt eingestellt ist. Die genaue Datei hängt von der verwendeten Shell des Benutzers ab, z.B. ~/.bashrc, ~/.bash_profile, oder ~/.zshrc, abhängig von der gewählten Shell. Du kannst einen Texteditor verwenden, um die Datei zu öffnen. Zum Beispiel:
sudo nano /home/iobroker/.bashrcÜberprüfe dann die folgenden Zeilen in der .bashrc-Datei:

Zitat# Setze den PATH für npm
export PATH=/usr/lib/node_modules/corepack/shims:$PATH

Wenn du die Änderungen in der Konfigurationsdatei vorgenommen hast, ist ein Neustart erforderlich.

############

Einige alte Skripte rufen nodejs anstelle von node auf. Da Node.js standardmäßig unter dem Namen node installiert wird, kannst du einen symbolischen Link (Symlink) erstellen, um diese Kompatibilitätsprobleme zu lösen.

a) Überprüfen, ob /usr/bin/nodejs existiert:
ls -l /usr/bin/nodejsb) Erstellen eines Symlinks (falls /usr/bin/nodejs nicht existiert):
sudo ln -s /usr/bin/node /usr/bin/nodejsDieser Befehl erstellt einen Symlink nodejs, der auf die node-Anwendung verweist. Damit wird jeder Aufruf von nodejs an node weitergeleitet. Test:
nodejs -v

---

6. System Updates

Um sowohl das gesamte System (Manjaro) als auch ioBroker in einer einzigen Zeile zu aktualisieren und deinen Raspberry Pi anschließend neu zu starten, führe diesen Befehl aus. Stelle sicher, dass du über vorhandene Backups verfügst. Nach Abschluss der Aktualisierung erfolgt der Neustart des Raspberry Pi automatisch:
iob stop && iob update && iob upgrade self && iob upgrade && sudo pacman -Syyuu && sudo paccache -rk2 && reboot

Darüber hinaus kannst du dein Manjaro-System aufräumen, um nicht mehr benötigte Pakete zu entfernen, indem du die folgenden Befehle ausführst:
sudo pacman -Rsn $(pacman -Qdtq)
sudo pacman -Scc
Linux-Systemverwaltung: Prüfe mit df -h die Festplattenbelegung, den LAN-Datentransfer in Echtzeit mit sudo iftop und mit htop (Systemmonitoring-Tool) die Informationen zur Systemauslastung, zur Prozessverwaltung und zur Ressourcennutzung auf einem Linux-System.

---

Quellen:

• www.iobroker.net/#de/documentation
• github.com/ioBroker

Biete hier ein Paar Bowers & Wilkins DM604 S3 Lautsprecher in sehr gutem Zustand an. Der Preis ist verhandelbar und günstig.

Die Lautsprecher sind ausschließlich für Abholung erhältlich. Optional kann ich auch einen Onkyo A-9110 HiFi Verstärker in silber anbieten, der gut zu den Lautsprechern passt und eine hervorragende Klangqualität bietet. Der Verstärker ist zwar schwächer als die Lautsprecher, reicht aber absolut aus und sorgt bereits für einen beeindruckenden Sound.







Kontakt

Matrix ist ein Chat-Protokoll und dezentrale Alternative zu Jabber/XMPP mit Ende-zu-Ende-Verschlüsselung. Die Serverkomponenten von Matrix sind Open Source, und der Aufbau einer föderalen Infrastruktur ist möglich und gilt als sehr sicher. Jeder kann einen eigenen Server betreiben, der mit allen anderen Servern im Netzwerk kommunizieren kann, aber nicht muss. Eine der Hauptfunktionen von Matrix ist die Möglichkeit, durch Bridging andere Kommunikationsdienste wie WhatsApp, Signal oder Telegram einzubinden. Und das Beste daran? Um die Matrix zu nutzen, braucht man keine rote Pille zu schlucken – und das ganz ohne in einen Kaninchenbau zu fallen!



Es gibt zahlreiche Client-Apps für Matrix, die für nahezu alle Betriebssysteme – einschließlich Smartphones – verfügbar sind. Zudem ist es möglich, Matrix über Webclients direkt im Webbrowser zu nutzen, was den Dienst noch zugänglicher macht. Persönlich nutze ich derzeit Element auf meinem Smartphone und auf meinem Linux Manjaro-System.

Um die Beziehung zwischen Matrix und Element zu verdeutlichen, kann man Matrix als das gesamte E-Mail-System betrachten, während Element einer spezifischen E-Mail-Anwendung entspricht.

Bei Matrix handelt es sich um ein offenes, dezentralisiertes Protokoll. Die meisten Matrix-Nutzer nutzen den Homeserver von matrix.org, der aufgrund der hohen Nutzerzahl zeitweise überlastet ist. Zudem ist dies ist für eine dezentrale Hierarchie suboptimal. Idealerweise wird empfohlen einen eigenen Homeserver zu hosten, aber nicht jeder hat die Mittel dazu... wie auch immer, ihr solltet einen anderen Homeserver als den Standard matrix.org nutzen, es gibt gute Alternativen, z.B.:

• tchncs.de (ein Technikkollektiv)
• nope.chat (ein Dienst von adminforge.de)
• freiburg.social (ein Dienst von freiburg.social e. V.)
• app.nitro.chat (von der Nitrokey GmbH)
• Liste der öffentlichen Matrix Homeserver

Es gibt mehrere Client-Apps für Matrix, wobei Element die größte Verbreitung hat. Nach der Installation einer Client-App kann man einen Account auf einem beliebigen Server entsprechend den eigenen Präferenzen frei wählen, unabhängig von der Telefonnummer. Diesen Server nennt man im Matrix-Jargon den 'Homeserver'.

Leider ist es oft schwierig, z.B. vollständig auf WhatsApp (im weiteren Text als WA bezeichnet) zu verzichten, gerade weil die App so weit verbreitet ist. Für viele Menschen ist WA ein unverzichtbarer Bestandteil des täglichen Lebens – und das, obwohl die Nutzung der App erhebliche Datenschutzprobleme mit sich bringt. Sobald Alternativen zur Sprache kommen, wird sogleich das Killerargument vorgebracht: "Aber fast alle meine Freunde und Bekannten sind bei WA."

Um dieses Dilemma zu lösen, habe ich eine Bridge für WA eingerichtet. Dadurch kann ich nahtlos mit meinen Client-Apps kommunizieren. Ein zusätzlicher Vorteil ist, dass es mir erlaubt, WA simultan auf mehreren Geräten zu verwenden. Es ist jedoch zu beachten, dass nicht alle Server diese Bridges unterstützen und WA mindestens alle 14 Tage einmal gestartet werden muss, ansonsten ist ein neuer WA Bridge Login notwendig.

Persönlich ziehe ich immer die Matrix vor – ja, ich lebe gerne in der Matrix.

---

TIPPS:

Als Matrix-Server verwende ich tchncs.de, zusammen mit einem Bridge-Bot für WA. Dies ist besonders nützlich für diejenigen, die sich gegen die Nutzung von Matrix sträuben und lieber bei WA bleiben.

Schritte zur Einrichtung:
1. **Einladen des Bots**:
  - Beginne eine Unterhaltung mit (Plus-Symbol neben Personen) `@whatsappbot:tchncs.de`.
  - In der Regel ist die Syntax whatsappbot:servername.tld, falls du einen anderen Server nutzt.

2. **Anmeldung**:
  - Sende die Nachricht `login`.
  - Die Einrichtung erfolgt ähnlich wie bei WA Web mittels QR-Code.

3. **Hilfe erhalten**:
  - Sende `help`, um zur Hilfeseite zu gelangen.

4. **Kontakte und Gruppen synchronisieren**:
  - Sende `sync contacts`, um die Kontakte zu synchronisieren (bei mir funktioniert das nicht), oder
  - Sende `sync groups`, um Gruppen zu synchronisieren (ebenfalls bei mir ohne Funktion).

5. **Kontakte und Gruppen auflisten**:
  - Sende `list contacts`, um eine Liste deiner Kontakte zu erhalten, oder
  - Sende `list groups`, um eine Liste deiner Gruppen zu sehen.

6. **Gruppe hinzufügen**:
  - Sende `open idNR`, um einer Gruppe beizutreten (z.B.: `open 1234567-1234567`).

7. **Neuen Kontakt anlegen**:
  - Wenn der Kontakt nicht in der Liste steht, sende z.B. `pm +49123456789`, um einen neuen Kontakt anzulegen.

Bitte beachte, dass diese Tipps basierend auf meiner persönlichen Erfahrung erstellt wurde und einige Befehle bei dir eventuell nicht funktionieren könnten.

Mein Link mit der Matrix Adresse @jolichter:tchncs.de ist https://matrix.to/#/@jolichter:tchncs.de. Diese universelle URL dient dazu, eine einfache und benutzerfreundliche Möglichkeit zu bieten, auf eine Matrix-ID zu verweisen. Sie stellt einen praktischen Link zu Matrix-Räumen, Benutzern oder Nachrichten bereit, ohne dass man an eine spezifische Anwendung gebunden ist. Die Syntax setzt sich aus dem festen Teil https://matrix.to/#/ und der spezifischen Matrix-ID (MXID) des Benutzers, in diesem Fall @jolichter:tchncs.de, zusammen. Wenn jemand diesem Link folgt, wird er zu einer Seite weitergeleitet, die es ihm ermöglicht, über einen Matrix-Client mit dieser MXID in Kontakt zu treten. Es ist vergleichbar mit einem 'mailto'-Link für E-Mail-Adressen, nur dass es für Matrix-Kommunikation gedacht ist (The matrix.to URL scheme).

---

Metadaten
Nicht unerwähnt bleiben sollte, dass bei Matrix – wie bei XMPP – die größte Stärke gleichzeitig die größte Schwäche ist: die Föderalität. Wenn ein Matrix-Server föderiert wird, gehört er zu einem größeren Netzwerk. Doch diese Vernetzung führt auch zu Kontrollverlust, da alle beteiligten Server standardmäßig Kopien der Kommunikation dauerhaft speichern. Auf dem eigenen Matrix-Server (Homeserver) kann eine Nachricht gelöscht werden, aber die Umsetzung auf anderen Servern ist ungewiss. Vertrauen in den eigenen Administrator und die anderen beteiligten Server ist im Matrix-Universum essenziell.

Während die Nachrichten zwar Ende-zu-Ende-verschlüsselt sind, gilt das nicht für die Metadaten. Dies muss nicht zwingend als Nachteil betrachtet werden. Dennoch sollte man sich darüber im Klaren sein, dass die Vermeidung von Metadaten, z.B. der Kommunikationsverlauf, bei Matrix nicht im Fokus steht. Diese Metadaten können Einblicke in die Kommunikationsmuster und -gewohnheiten der Benutzer geben, auch wenn der Inhalt der Nachrichten selbst verschlüsselt ist. Es ist wichtig, sich bewusst zu sein, dass Ende-zu-Ende-Verschlüsselung nicht notwendigerweise alle Aspekte der Privatsphäre abdeckt, insbesondere wenn es um Metadaten geht – es sei denn, man verwendet einen eigenen Matrix-Server ohne die Föderalität.

Hier eine Analyse der gängigen Messenger-Dienste (ohne Gewähr):

Auch wenn manche es behaupten, der Produktiv genutzte Server-Quellcode von Telegram, Threema und Signal ist nicht öffentlich zugänglich. Wenn überhaupt, ist nur die Client-Software dieser Messenger-Dienste Open Source.

Erklärung: Ein "Walled Garden" (zu Deutsch: "eingezäunter Garten") bezieht sich auf eine geschlossene Plattform oder ein Ökosystem, das darauf abzielt, Benutzer innerhalb seiner eigenen Dienste und Anwendungen zu halten, während der Zugang oder die Interaktion mit externen Diensten oder Ressourcen eingeschränkt wird. FOSS steht für "Free and Open Source Software", was auf Deutsch "Freie und Open-Source-Software" bedeutet. Es handelt sich um Software, deren Quellcode öffentlich zugänglich ist und die unter einer Lizenz veröffentlicht wird, die es Benutzern erlaubt, die Software frei zu verwenden, zu modifizieren und zu verbreiten.

Links:

• Die verrückte Welt der Messenger (Mike Kuketz - Es kann nie den »einen« Messenger geben)
• Empfehlenswert: Element für Matrix (digitalcourage.de)
• Dokumentation - Matrix am KIT (gute Starthilfe auch für andere Homeserver)
• whatsapp-telegram-signal-in-einer-app-nutzen-mit-matrix-anleitung
• whatsapp-account-zwei-geraete-anleitung
• WhatsApp Bridge in Matrix einrichten (YT)
• Matrix-Analyse - Warum nicht Threema?