Die Cloud ist umgezogen
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…
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… 😉
2 Kommentare
Hallo Ralf,
nach langen Recherchen habe ich diese Seite von Dir gefunden. Ich habe mit meinen RASPI 4B und der Nextcloud PI das gleiche Problem der Erreichbarkeit aus dem lokalen LAN. Manchmal gehts, meistens gehts nicht. Extern ist alles ok. Der HPB Service ist auch down.
Anfänglich vermutete ich das Problem in Verbindung mit Let’s encrypt und den zwei Einträgen in der config.php trusted_domain und trusted_proxies. Da es auch ab und zu geht, ist es auch schwer nachzuvollziehen. Meine IT Umgebung ist relativ überschaubar. Am DSL ist eine Fritz!Box 7390 und setzt die Ports 80 und 443 auf den direkt mit Kabel angeschlossenen Raspi um.
Als DNS habe ich meine FB eingetragen und über das WebUI auch mal den google DNS. Half aber nichts.
Hast Du eine Idee was ich noch machen kann? In den NC Form komme ich auch nicht weiter.
Thomas
Hallo Thomas,
danke für deine Nachricht. Hm, also mal sehen… wie übertragbar meine Einstellung auf deinen Raspi sind, sei jetzt einfach mal dahingestellt.
Also im ncp-config habe ich beispielsweise eine static-IP gesetzt, bei den trusted-domains habe ich gar nichts eingetragen.
Die dnsmasq ist aktiv und als DNS server ist mein PiHole eingetragen. Zwar wird mir über nc-info immer noch gesagt, ich solle dnsmasq enablen, aber irgendwie funktioniert das auch so.
Die Services sind alle up. HTTPD, PHP, MariaDB, Redis und auch HPD.
Am HPD service hatte ich ja auch leicht zu knabbern, der “Umweg” über den PiHole hat mir dann ermöglicht auf das Google-DNS zu verzichten.
Ich glaube die FB als DNS einzutragen könnte Probleme verursachen, vielleicht würde ich da mal ansetzen…