Heute möchte ich über ein sinnvolles und relativ schnell nachzurüstendes Feature zur Nextcloud berichten. Der zeitliche Aufwand beträgt nur wenige Minuten, ist aber zum Schutz der eigenen Daten eine gut investierte Zeit.
Ab und zu kam es vor, dass ich mich aus meiner Cloud nicht richtig abgemeldet, sondern nur den Browser geschlossen hatte. Beim nächsten Aufruf meiner Nextcloud stellte ich fest, dass ich plötzlich im Datenbereich bin, ohne mich vorher eingeloggt zu haben.
Mein Gedanke: Was würde passieren, wenn ein Unberechtigter so Zugriff auf alle in einer Cloud abgelegten Daten bekommt? Nicht auszudenken, der Schaden wäre wohl immens.
Damit dies nicht vorkommt, ist es sinnvoll ein Auto Logout einzurichten. Hierzu öffnet man als Erstes die config.php der Nextcloud
Eine Session wird auf 30 Minuten sowie die Lebensdauer des Login-Cookies auf 15 Tage begrenzt. Diese Werte können natürlich den eigenen Wünschen und Gegebenheiten angepasst werden.
Dabei gilt zu beachten, dass die session.gc_maxlifetime in der php.ini >= der eingestellten session_lifetime sein muss. Dazu öffne ich die php.ini von PHP 8.1 FPM
sudo nano /etc/php/8.1/fpm/php.ini
und setze den Wert auf 3600.
session.gc_maxlifetime = 3600
Nun muss PHP bzw. der Webserver neu gestartet werden, um die Änderungen wirksam umzusetzen.
sudo service php8.1-fpm restart
Ein geschlossener Browser führt nun, wie gewünscht, zu einem Auto Logout.
Die aktuelle Raspberry-Pi-Version verwendet auf den Raspberry-Pi-Modellen 4B, 400 sowie 5 Wayland als Default-Grafiksystem. Aus diesem Grund funktionieren viele Programme zur Fernwartung bzw. für Remote-Desktop-Funktionen nicht mehr wie gewohnt. Betroffen ist unter anderem RealVNC, bisher die Default-Lösung der Raspberry Pi Foundation. RealVNC verspricht etwas vage, im Verlauf des Jahres 2024 eine Wayland-kompatible Version ihrer Software zu veröffentlichen. An dieser Stelle erkläre ich Ihnen, was Sie tun können, wenn Sie nicht solange warten möchten.
Xorg versus Wayland
Das X Window System und der Xorg-Server bilden das traditionelle Grafiksystem von Linux. Es basiert auf einem Client/Server-Modell und hat sich jahrzehntelang bewährt. Allerdings ist der Xorg-Server mit vielen Altlasten und Sicherheitsproblemen verbunden. Die Software wird schon seit mehrere Jahren nicht mehr weiterentwickelt und kaum noch aktiv gewartet. Seine Zeit läuft ab.
Der Nachfolger von Xorg heißt Wayland ist dagegen »nur« ein neues Protokoll für die Kommunikation zwischen dem Wayland Compositor (einem Display-Server) und den Anwendungsprogrammen (Clients). Wayland bricht mit dem X Window System und verspricht ein System, das schlanker, sicherer und effizienter ist. Wayland gehört die Zukunft.
Zwar sind mittlerweile viele Programme Wayland-kompatibel, aber leider nicht alle. Besonders große Probleme gibt es bei Programmen, die den Bildschirminhalt auslesen wollen, also Tools für Screenshots, Screencasts, Screen Sharing und Remote Desktop. Derartige Funktionen sind auch unter Wayland möglich, müssen aber vollständig neu implementiert werden.
Aktuelles Grafiksystem ermitteln
Ob Ihr Raspberry Pi Wayland oder Xorg als Grafiksystem verwendet, stellen Sie am einfachsten mit einem Kommando im Terminal fest:
echo $XDG_SESSION_TYPE
wayland
Im Desktop-Betrieb lauten die möglichen Antworten wayland oder x11. In einer SSH-Session im Textmodus lautet das Ergebnis dagegen tty.
Lösung 1: Xorg statt Wayland verwenden
Die bei weitem einfachste Lösung besteht darin, das Grafiksystem von Wayland zurück auf Xorg umzustellen. Dazu führen Sie in einem Terminal-Fenster sudo raspi-config aus und wählen zuerst den Menüpunkt Advanced Options, dann Wayland. Jetzt können Sie sich zwischen dem X11 Backend und dem Wayland Backend entscheiden. Gleichzeitig ändert sich auch der Window Manager (Openbox versus Wayfire). Optisch ergeben sich daraus aber nur geringe Unterschiede.
Die Einstellung wird in der Datei /etc/lightdm/lightdm.conf gespeichert:
# in der Datei /etc/lightdm/lightdm.conf
...
# für Wayland:
user-session=LXDE-pi-wayfire
# oder für X:
user-session=LXDE-pi-x
Die Umstellung des Grafiksystems wird erst nach einem Neustart wirksam. Die meisten Remote-Desktop-Tools inklusive RealVNC sollte nun wieder wie gewohnt funktionieren. Der RealVNC-Server ist standardmäßig installiert. Die Aktivierung kann aber nicht über das Raspberry-Pi-Konfigurationsprogramm erfolgen. Dessen VNC-Option gilt nur für wayvnc und muss deaktiviert (!) sein, sonst kommt es zu einem Port-Konflikt. Den RealVNC-Dienst aktivieren Sie anschließend wie folgt:
Ein VNC-Icon im Panel zeigt an, dass der Start funktioniert hat, und gibt Aufschluss darüber, ob gerade eine Verbindung aktiv ist.
Allerdings gibt es auch hier eine Einschränkung: Der RealVNC-Server funktioniert nur in der 64-Bit-Version von Raspberry Pi OS Bookworm, nicht aber mit der 32-Bit-Version. Dieses Problem soll aber in naher Zukunft behoben werden.
Lösung 2: wayvnc
Wenn Sie bei Wayland bleiben, steht das neue Programm wayvnc zur Verfügung. Sie aktivieren es am einfachsten mit dem Programm Raspberry Pi-Konfiguration im Dialogblatt Schnittstellen, Option VNC.
Aktivierung des VNC-Servers im »Raspberry Pi-Konfigurationsprogramm«
Daraus resultiert die folgende Konfigurationsdatei /etc/xdg/autostart/wayvnc.desktop:
Jetzt brauchen Sie auf Ihrem Client-Rechner (auf dem Rechner, mit dem Sie Ihren Raspberry Pi steuern möchten), einen zu wayvnc kompatiblen VNC-Client. Der Raspberry-Pi-Blog empfiehlt das Programm vncviewer des Projekts TigerVNC. Die meisten Linux-Distributionen stellen ein entsprechendes Paket zur Verfügung. Für Windows und macOS (Intel) finden Sie hier Downloads.
Bei meinen Tests unter Windows ist der Verbindungsaufbau mit dem Programm Remotedesktopverbindung gescheitert. Mit dem vncviewer von TigerVNC hat es dann aber funktioniert.
Sofern der Raspberry Pi mit einem eigenen Monitor verbunden ist, gilt für den Remote Desktop dieselbe Bildschirmauflösung. Wenn der Raspberry Pi dagegen »headless« läuft, können Sie die gewünschte Auflösung mit sudo raspi-config, Display Options, VNC Resolution einstellen (maximal 1920×1080, erfordert einen Reboot).
Smart Homes sind in aller Munde. Bei Neubauten sowieso, aber auch bestehende Immobilien werden gerne zu so genannten Smart Homes umgerüstet. Den großen Markt teilen sich natürlich kommerzielle Anbieter, aber gerade auf der Softwareseite konkurrieren auch freie und open source Software um die Kunden. Die bekanntesten Teilnehmer im open source Bereich sind FHEM, OpenHAB und Home Assistant (früher bekannt als hass.io).
Diese Software soll verschiedene smarte Geräte vereinen, so dass sie alle unter einer Haube stecken. Anstatt jeweils eine Anwendung für die Heizung, das Licht und die Energieversorgung zu verwenden, soll die Software übergeordnet sein. Sie bildet damit die Schnittstelle zwischen den Geräten und mir.
Ich möchte mein Haus mit dem Home Assistant smart machen, bzw. einige der vorhandenen Komponenten dort einbinden. In diesem Artikel möchte ich zunächst auf die Installation von Home Assistant Container eingehen.
Unterschied zwischen Home Assistant und Home Assistant Container
Der mächtige Home Assistant wird gerne auf einem Raspberry Pi installiert. In der Regel verwendet man dafür gleich ein ganzes Image für das Betriebssystem. Das bedeutet, dass man statt des üblichen Raspbian das „Home Assistant Operating System“ installiert.
Der Vorteil liegt darin, dass man den Home Assistant in vollem Umfang nutzen kann. Der Nachteil ist, dass man über ein stark angepasstes OS verfügt. Möchte man noch weitere Software darauf laufen lassen, könnte das zu Konflikten führen.
In meinem Fall laufen noch andere Prozesse auf dem Raspberry. Somit kommt für mich das OS nicht infrage. Stattdessen möchte ich auf Home Assistant Container setzen. Hier läuft die Software über Docker.
Benutzt man den Home Assistant Container, muss man mit Einschränkungen leben. Es ist beispielsweise nicht möglich, Add-ons zu installieren. Der Grund liegt meines Wissens darin, dass Add-ons als (Docker-)Container installiert werden. Und das geht nicht, wenn bereits die Hauptanwendung in einem (Docker-) Container läuft. [Falls das jemand genauer weiß, gerne einen Kommentar hinterlassen!]
Installation von Home Assistant Container
Was man als Vorbereitung braucht, ist ein installiertes Linux-System. In meinem Beispiel ist es Raspbian auf einem Raspberry Pi 4. Dort meldet man sich via SSH an.
Schritt 1: Docker installieren. Gegebenenfalls hat man eine alte Version bereits installiert. Diese muss man entfernen und die aktuelle Version installieren. Dazu wird das Docker-Repository hinzugefügt und die Software daraus installiert. Am Ende wird eine Benutzergruppe „docker“ erstellt (ggf. geschieht das automatisch). Der aktuelle Benutzer – hier nennt er sich pi – wird der Gruppe hinzugefügt.
Schritt 2: Home Assistant Container installieren. Der folgende Befehl holt sich das entsprechende Image aus dem Dockerhub, lädt es herunter und installiert es. Es ist wichtig, dass der Ordnerpfad für die Konfigurationsdatei korrekt angegeben wird. Wie oben bereits beschrieben, fehlt die Add-on-Funktion. Um die configuration.yaml bearbeiten zu können, muss man an diese Datei herankommen. Mit der Flag -v mountet man einen existierenden Ordner in den Docker-Container und kann damit die Datei weiterhin bearbeiten.
Schritt 3: Docker-Image verwalten. Die gesamte Home Assistant Installation kann man über den Container starten und stoppen. Ein Update führt man ebenfalls über das Docker-Image aus. Die Befehle hierfür lauten folgendermaßen.
Schritt 4: Auf Home Assistant zugreifen. Ab jetzt erfolgt die Verwaltung des Home Assistant über die Weboberfläche. Mit http://<IP-Adresse des Raspberrys>:8123 kann man von einem PC des gleichen Netzwerks auf die Installation zugreifen. Änderungen an der configuration.yaml müssen weiterhin über die Systemoberfläche, also z.B. mit nano oder vim über SSH erfolgen.
Der Raspberry Pi 4 kann 4K@60Hz ausgeben. Unter LibreELEC muss dies über die config.txt aktiviert werden. Leider funktioniert die Methode (noch) nicht mit LibreELEC 10. Über den Texteditor: Steckt die SD-Karte in euren PC,...
Im vorherigen Beitrag habe ich euch gezeigt wie ihr den Hauppauge WinTV-soloHD oder Hauppauge WinTV-dualHD unter Linux einrichtet. Hinweis: Für Raspberry Pi OS 10 „Buster“ gibt es derzeit (Stand: Januar 2021) keine eigenen Tvheadend...
Ein NAS zu verwenden ist in vielen Situationen sinnvoll. Wenn man beispielsweise mehrere netzwerkfähige Geräte verwendet, seien es PCs, Tablets oder Fernseher, können alle Geräte auf den gleichen Speicher zugreifen. Dort gespeicherte Dateien, beispielsweise Urlaubsfotos, können dann auf allen diesen Geräten angezeigt werden.
Meine Motivation ist allerdings vor allem der redundante Festplattenspeicher. Ich verwende ein NAS mit zwei Festplatten. Ich werde sie so konfigurieren, dass beide Festplatten sich gegenseitig spiegeln, also exakt die gleichen Daten speichern. Das nennt sich RAID 1 (Redundant Array of independent disks). Fällt eine der beiden Festplatten aus, kann sie ersetzt werden und die Daten sind noch auf der zweiten Festplatte gespeichert.
NAS kaufen vs. Raspberry Pi Eigenbau
Das aktuelle Einstiegsmodell von Synology, DS218j, genügt für mich allemal. Ich werde einen relativ geringen Traffic darauf laufen lassen und brauche dort keine übermäßige Rechenleistung (momentan habe ich keinen Bedarf an Videocodierung oder anderen aufwendigen Berechnungen). Ich kann von meinen Geräten im Heimnetzwerk darauf zugreifen und haben die besagte Ausfallsicherheit durch das RAID 1.
Andere Hersteller kommen natürlich auch in Frage. Für meine Bedürfnisse ist es schon beinahe egal, wer das NAS herstellt. Ich habe mich für den Hersteller entschieden, der in meinem Bekanntenkreis bereits verwendet wird.
Prinzipiell gibt es sogar die Möglichkeit, das NAS über ein Raspberry Pi selbst zu bauen. Das Betriebssystem OpenMediaVault kann man das sogar recht komfortabel umsetzen. Ein halbwegs neuer Raspberry Pi und externe Festplatten genügen, schon kann man die Low Budget Variante selber bauen. Die Einrichtung funktioniert anschließend über den Browser, so wie es auch in den kommerziellen Varianten der Fall ist.
Ich entschied mich für die kommerzielle Variante. Das ist – zugegeben – eher untypisch für mich und das Blog. Normalerweise bin ich eher der Bastler, der gerne solche Systeme selber baut. In diesem speziellen Fall war mir die Kaufvariante allerdings lieber.
NAS-Festplatten vs. Deskop-Festplatten
Die zweite Frage, nachdem die Entscheidung auf die Diskstation DS218j gefallen ist, lautet: welche Festplatten werde ich verwenden?Die sogenannten NAS-Festplatten sind robuster ausgestattet als die typischen Desktop-Festplatten. Die wesentlichen Unterschiede zwischen den Typen sind die folgenden:
Drehzahl: NAS-HDD laufen langsamer als Desktop-HDD. Sie sind dadurch ruhiger, verbrauchen weniger Energie und erwärmen sich nicht so stark.
Montagebohrungen: Nicht jede HDD hat die passenden Befestigungsmöglichkeiten für die Rahmen in einem NAS.
Firmware: NAS-HDD können mit dem RAID-Controller über ausgefallene Sektoren kommunizieren.
Vibrationen: NAS-HDD haben manchmal einen Virbationssensor, der bei zu starken Vibrationen im Gehäuse die HDD herunterfährt. Außerdem sind die „besseren“ NAS-HDD zusätzlich mit Vibrationsdämpfern ausgestattet.
Ich habe mal letztendlich für die NAS-Version von Western Digital entschieden (WD Red). Aus meiner Sicht sind alle HDD-Hersteller gleichbedeutend, es hätte genauso gut Seagate oder Sandisk oder etwas anderes werden können. Die NAS-Festplatten kosten nur unwesentlich mehr als die Desktop-Version.
Anmelden
