Die Cloud ist umgezogen

Kategorien: Internet, Raspberry Pi

Nachdem der Bilderrahmen läuft, habe ich nun auch meine Cloud, genauergesagt die Nextcloud, auf den neuen Raspberry Pi 4 umgezogen. Das hat relativ gut funktioniert, gab aber „fast erwartet“ ein paar kleinere Hürden zu bewältigen…

Die Cloud in Bewegung
Die Cloud in Bewegung

Ausgangsbasis

Auf einem Raspberry Pi 3b hatte ich eine Nextcloudpi-Instanz laufen. Auf dem Gerät lief sonst nichts anderes und mit meinem neuen Raspberry Pi 4 und dem digitalen Bilderrahmen, wollte ich die Cloud zukünftig auf dem neuen Pi laufen lassen. Den 3er-Raspi kann ich dann für etwas anderes benutzen.

Da jetzt auf dem neuen Raspberry Pi schon eine aktuelles System läuft, musste ich mich hier für eine Installation der einzelnen Nextcloud-Komponenten entschließen und konnte nicht auf einen vorgefertigten Nextcloudpi zurückgreifen.

So sollte die Cloud aussehen

Der Raspberry Pi 4 stand als digitaler Bilderrahmen in meinem Buchregal und hatte lediglich einen Stromanschluss. Alles weitere habe ich dann über mein heimisches Netzwerk im WLAN-Modus konfiguriert.

Die neue Cloud wollte ich hier jetzt auch erstmal per WLAN laufen lassen und sehen, wie so die Performance ist.

Das ich eventuell ein Problem mit der Temperatur bekommen könnte, das habe ich bereits gesehen und einkalkuliert. Die Zeitschaltuhr hat mittlerweile ihren Betrieb aufgenommen.

Wenn Bilderrahmen und Nextcloud erstmal harmonieren sollten, dann könnte ich den Pi noch weiter ausbauen.

Der Weg und das (Zwischen-)Ergebnis

Die Installation der Nextcloud-Komponenten via Script, wie hier beschrieben, funktionierte soweit ohne Probleme.

Leider hatte ich dann aber beim Aufruf der lokalen IP-Adresse zur Ersteinrichtung der Nextcloud gleich einmal eine Fehlermeldung. Ich hatte vorher die alte Cloud bereits vom Netzwerk getrennt, aber vielleicht war der Router trotzdem irgendwie irritiert. Über http://nextcloud.local bin ich dann erstmal reingekommen.

Alle Konfigurations-Einstellungen hatte ich dann erstmal von der alten Cloud übernommen. Die System-Info der Nextcloud hat mir dann gleich mal ein paar Baustellen aufgezeigt: HTTPD Service closed, HPB Service closed, Port check 80 closed, Port check 443 closed, Dnsmasq, Let’s encrypt…

HTTPD-Service

Die Fehlermeldungen bin ich dann erstmal von oben herunter angegangen. Die Cloud ist mir partout nicht in den https-Mode gesprungen. Das hing mit dem HTTPD-Service und Let’s encrypt zusammen. Zwar hat die Nextcloud-Konfiguration des Zertifikats einwandfrei funktioniert, dennoch hat mir

systemctl status apache2.service

die Fehlermeldung ausgeworfen „Let’s encrypt Zertifikat nicht vorhanden“. Der Fehler war dann verhältnismäßig schnell gefunden, denn der gesuchte Ordner mit den Schlüsseln unter /etc/letsencrypt/live/ hatte einfach einen anderen Namen, als er von Apache gesucht wurde. Eine Anpassung der dementsprechend conf-Datei verhalf da Abhilfe. Dann funktionierte der Apache2-Service und die Fehlermeldung in der System-Info verschwand.

HPD-Service

Ähnliches war dann beim HPB-Service (High Performance Back-End). Dieser hing dann irgendwie mit dem dnsmasq-Problem und dem Loopback der Fritzbox zusammen. Die Cloud ließ sich direkt aus dem Netzwerk nicht stetig aufrufen. Zwar sollte hier meine Fritzbox (eine 7490) eigentlich keine Probleme bereiten, tat es aber trotzdem. Hier brach die Verbindung ständig ab oder kam garnicht zustande. Von außerhalb des lokalen Netzwerks lief alles ohne Probleme.

Anders als bei der alten Cloud wollte ich bei den dnsmasq-Einstellungen in der Nextcloud eigentlich auf den Google-Nameserver 8.8.8.8 verzichten, aber die vorgegebenen Vodafone-Server, die ich von der Fritzbox als verfügbar angezeigt bekommen habe, wollten einfach keine Reaktion zeigen. Auch mit dem Google-Server hatte ich komischerweise weiterhin Probleme.

Das löste sich dann aber tatsächlich, als ich von meinem WLAN-Versuch wieder zurück in die LAN-Lösung gegangen bin

systemctl status dnsmasq.service

zeigte mir tatsächlich nach einem Neustart immer wieder „wlan-schnittstelle nicht gefunden“. Nach einem Restart des Service war das dann zwar weg, allerdings funktionierte der Service dann auch nicht durchgängig.

Erst ein kompletter Wechsel auf einen Anschluss mit Kabel und ein Einstellen des 8.8.8.8-Service brachte die Cloud dann zum ordnungsgemäßen Laufen.

Zwar wird nun weiterhin noch angezeigt, dass die 80er- und 443er-Ports geschlossenwären, aber der Router sagt mir etwas anderes und funktionieren tut anscheinend trotz der Closed-Meldung alles einwandfrei.

Und weiter…

Den Inhalt der Cloud habe ich dann „relativ zügig“ übertragen bekommen und habe direkt wieder Zugriff mit allen Accounts bekommen. Lediglich die Windows-Clients wollten sich „aus Gründen“ neu synchronisieren. Okay, lief halt einfach über Nacht.

Das Thema „Google-Nameserver“ hat mich weiterhin gewurmt… konnte ich aber mittlerweile mit einem Pi-hole auf dem freigewordenen Raspberry Pi 3b lösen. Das gibt aber einen separaten Blog-Beitrag… 😉

«
»

    Schreibe einen Kommentar

    Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.