Das Update auf Nextcloud 21 bringt einige Neuerungen mit sich. Das interessanteste Feature ist dabei das High Performance Backend für Dateien. Dies ist eine in Rust entwickelte Komponente, die eine direkte Verbindung von Desktop-/Mobil-/ oder Web-Apps zur Cloud sicher stellen kann. Hierbei wird viel Last vom Server genommen, da die Client-Anwendungen nicht mehr pollen müssen, um Änderungen an Dateien mit zu bekommen. Stattdessen werden die Anwendungen durch Notifications aktiv über Dateiänderungen informiert.
Laut Nextcloud-Blog kann die Anzahl der Server-Client-Verbindungen um 90% reduziert werden. In großen Nextcloud-Umgebungen kann dies zu einer Performance-Verbesserung um den Faktor 10 führen.
Der folgende Artikel beschreibt die Installation und Konfiguration des High Performance Backends für Dateien. Als Basis dient wie immer eine Installation nach folgendem Tutorial: Nextcloud auf Ubuntu Server 20.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban
Hinweis: In kleineren Umgebungen wird hier der Performance-Schub schätzungsweise deutlich geringer ausfallen. In kleineren „Familien-Clouds“ wird die Installation eines solchen High Performance Backends vermutlich gar nicht spürbar sein.
Update-Historie (letztes Update: 25.02.2021)- 25.02.2021:
- Hinweise zum Update der App hinzugefügt
Inhalt
Voraussetzungen
Grundvoraussetzung ist natürlich eine bestehende Nextcloud-Instanz, die bereits mit Version 21 läuft. Zur Kommunikation zwischen den Komponenten wird hier Redis genutzt, daher muss die Nextcloud bereits mit einer bestehenden Redis-Instanz zusammen arbeiten.
Als Webserver nutze ich hier nginx. Allerdings funktioniert das High Performance Backend auch mit anderen Webservern/Proxy-Servern. Genaue Anweisungen dazu findet man dazu im GitHub-Repository des Projekts.
Einrichtung des High Performance Backends für Dateien
Der erste Schritt führt hierbei in den Nextcloud App Store. Unter der Kategorie Werkzeuge findet man hier die App Client Push.
Nach der Installation und Aktivierung über den App Store sind die Tätigkeiten in der Nextcloud-Oberfläche bereits abgeschlossen.
Weiter geht es hier auf der Kommandozeile des Servers.
Als erstes braucht der virtuelle Host für Nextcloud eine kleine Erweiterung:
nano /etc/nginx/conf.d/nextcloud.meinedomain.de.conf
Hier fügen wir folgenden location-Block im Server-Block für HTTPS (am besten ganz unten) ein:
location /push/ {
proxy_pass http://localhost:7867/;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}Anschließend muss zur Übernahme der Änderungen der Webserver einmal neu geladen werden:
service nginx reload
Anschließend muss das Setup des High Performance Backends über OCC aufgerufen werden:
cd /var/www/nextcloud sudo -u www-data php occ notify_push:setup
Hier kann nun u.U. eine Fehlermeldung ausgegeben werden, dass die IP des Servers als sog. „Trusted Proxy“ hinterlegt werden muss. Die genaue IP wird dabei vom Setup-Assistenten angezeigt (hier: 192.168.178.10).
Wenn dies der Fall ist, dann öffnen wir zunächst einmal die Konfiguration von Nextcloud:
nano /var/www/nextcloud/config/config.php
Hier wird nun folgende Einstellung hinterlegt:
'trusted_proxies' =>
array (
0 => '192.168.178.10',
),Wichtig: Hier ist darauf zu achten, dass trusted_proxies nicht doppelt definiert wird. Auch wenn diese Variable vorher noch nicht manuell angelegt war, kann dies durch den ersten Aufruf des Setups passiert sein.
Nach dieser Änderung kann das Setup nochmals per OCC aufgerufen werden:
sudo -u www-data php occ notify_push:setup
Wenn die Konfiguration in Ordnung ist, werden nun Anweisungen angezeigt, um eine systemd Unit für das Backend anzulegen.
Wichtig: Hier nun nicht einfach Enter drücken, dies würde das Setup mit einer Fehlermeldung beenden. Stattdessen öffnet man am besten eine weitere SSH-Session, um die Konfiguration der Unit hierüber abzuschließen.
Die genauen Schritte werden ja im Setup-Assistenten angezeigt, daher hier nur exemplarisch im Schnelldurchgang:
/etc/systemd/system/notify_push.service
Folgender Inhalt ist hier einzufügen:
[Unit] Description = Push daemon for Nextcloud clients [Service] Environment=PORT=7867 Environment=NEXTCLOUD_URL=https://nextcloud.meinedomain.de ExecStart=/var/www/nextcloud/apps/notify_push/bin/x86_64/notify_push /var/www/nextcloud/config/config.php User=www-data [Install] WantedBy = multi-user.target
Nun wird der Service einfach nur noch aktiviert und gestartet:
systemctl enable --now notify_push
Nun kann man wieder auf die ursprüngliche SSH-Session wechseln, wo das Setup noch auf eine Eingabe wartet. Hier einfach Enter drücken und es sollte eine Erfolgsmeldung angezeigt werden.
Die Einrichtung des High Performance Backends für Dateien ist damit auch schon abgeschlossen.
Update der App „Client Push“
In regelmäßigen Abständen erscheint ein Update der App „Client Push“. Das Update wird dabei als einfaches App-Update in der Nextcloud selbst durchgeführt.
Wichtig: Mit dem App-Update kommt meist auch eine neue Version des Binaries (notify_push), welches in der App enthalten ist und von der systemd Unit als Service genutzt wird. Hier gilt: Nach jedem Update der App „Client Push“ ist der Service neu zu starten:
service notify_push restart
Fazit
Die Einrichtung des High Performance Backends erfordert zwar ein paar mehr Schritte als das einfache Aktivieren der entsprechenden App, trotzdem hält sich hier der Aufwand für die Installation in Grenzen.
Das Feature ist gerade mit Nextcloud 21 eingeführt worden und ist deshalb noch brandneu. Leider fehlen hier noch konkrete Erfahrungswerte, wie sich die Performance in der Praxis dadurch verbessert.
Habt ihr das High Performance Backend für Dateien bereits für eure Nextcloud aktiviert? Wie sind eure Erfahrungen bzgl. Performance und Stabilität? Hinterlasst mir dazu doch einfach einen Kommentar.
Weiterführende Artikel
Links
- Nextcloud Hub 21 out with up to 10x better performance, whiteboard and more collaboration features (Nextcloud-Blog)
- Nextcloud/notify_push (GitHub)
Ähnliche Artikel:
Nextcloud auf Ubuntu Server 20.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban
Nextcloud auf Ubuntu Server mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban
Nextcloud auf Ubuntu Server 18.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban
Nextcloud Talk mit eigenem Signaling-Server (High Performance Backend)
Vielen, vielen Dank! Ich lese Ihre Anleitungen unglaublich gerne und konnte bereits viel lernen. Riesig freuen würde ich mich noch über eine Anleitung für Nextcloud 21 mit PHP 8.
Beste Grüße aus dem Rhein Main Gebiet.
Hi,
ich bin ja kein Fan von PPAs, daher wird es vermutlich erst ein Update des Artikels geben, wenn PHP 8 in den offiziellen Paketquellen von Ubuntu enthalten ist. Ansonsten sollte sich die Konfiguration nicht all zu sehr von PHP 7.4 unterscheiden.
Gruß,
Jan
Moin Jan,
würdest Du auch eine Anleitung schreiben, wie man PHP 7.4 auf PHP 8 updatet oder aktualisierst Du nur deinen Komplettartikel zur Installation von „Nextcloud auf Ubuntu Server 20.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban“?
Viele Grüße
Thomas
Hi Thomas,
da PHP 8 wohl nicht mehr für Ubuntu 20.04 kommen wird, werde ich dazu in Zukunft wohl mal einen neuen Artikel verfassen.
Das kann aber durchaus noch eine Weile dauern.
Gruß,
Jan
Wie sieht es denn aus, wenn man mehr als nur eine Nextcloud Installation auf einem Server betreibt?
Hi,
hier würde ich die Backends einfach auf unterschiedlichen Ports laufen lassen. Ebenso wird dann natürlich eine zweite systemd Unit benötigt. Sollte aber funktionieren.
Gruß,
Jan
Super, vielen Dank.
Kann testen, ob es richtig funktioniert?
Gruss,
Jakob
Hi,
wenn das Setup am Ende die Erfolgsmeldung ausgibt, sollte alles funktionieren.
Ansonsten solltest du auch im Access-Log des Webservers Zugriffe auf
/push/sehen können.Gruß,
Jan
Hallo!
Vielen Dank für die Anleitung!
Ich hab meine Cloud damals nach der alten Anleitung unter Ubuntu 18.04 aufgesetzt. Ich hab inzwischen ein Update auf Ubuntu 20.04 und auch auf Nextcloud 21 gemacht.
Jetzt möchte ich gern das High Performance Backup einrichten bekoote abder folgenden Fehler:
Allowing self-signed certificates in the push config.
🗴 failed to run self-test with auto-generated config.
test output: [2021-02-25 15:15:43.412806 +01:00] INFO [notify_push] src/main.rs:58: Running with certificate validation disabled
[2021-02-25 15:15:43.417983 +01:00] WARN [notify_push] src/lib.rs:131: failed to detect app version app: Response was of incompatible type: „Response type not string compatible.“ (response was nil)
[2021-02-25 15:15:43.522927 +01:00] INFO [notify_push] src/main.rs:89: shutdown signal received, shutting down
✓ redis is configured
🗴 using unencrypted https for push server is strongly discouraged
🗴 push server url is set to localhost, the push server will not be reachable from other machines
✓ push server is receiving redis messages
✓ push server can load mount info from database
🗴 push server can’t connect to the Nextcloud server
Wo muss ich in der Konfiguration den location-block einfügen?
Ich hab schon verschiedene Stellen ausprobiert, aber leider kommt immer der gleiche Fehler :-(
Viele Dank für Deine Hilfe :-)
Hi,
den Block für das HPB musst du einfahch nur im vHost für NC ganz unten (aber vor der letzten schließenden Klammer, die ist vom Server-Block) einfügen.
Hast du in der Nextcloud config.php die lokale IP des Servers als „trusted-Proxy“ eingetragen?
Gruß,
Jan
Hi!
Sorry, ich steh gerade total auf dem Schlauch…
Ich hab den Block in der Datei cloud.xxx.de_nextcloud.conf am Ende vor der letzten schließenden Klammer eingefügt.
Ist das richtig?
Es kommt immer noch die gleiche Fehlermeldung.
Hi,
ja, das ist soweit korrekt.
Gruß,
Jan
trusted-proxy hab ich eingetragen.
Ich nutze ocloud.de, da die Updates automatisch eingespielt werden und es somit immer auf dem neusten Stand ist. Und die Daten werden im deutschen Rechenzentren gespeichert und insbesondere die Kalenderfunktion wird von mir intensiv genutzt.
Hallo Jan,
nach dem Ausführen sudo -u www-data php occ notify_push:setup wird ein externe IP ausgegeben.
Habe die Config mehrmals überprüft.
Gruß Hans
Hi Hans,
was heißt „externe IP ausgegeben“? Wie lauten die Meldungen konkret, wenn du das Setup ausführst?
Gruß,
Jan
Hallo Jan,
ist die gleiche Meldung wie über „ Meldung bzgl. fehlendem Eintrag bei trusted_proxies“ von deiner Anleitung, nur wird hier eine externe IP 88.xx und keine interne IP 192.169.x ausgegeben. In der NC wird die Meldung, „ Sie verwenden eine externe IP für den Push-Service“ (so ähnlich) ausgegeben.
Gruß Hans
Hi Hans,
was passiert, wenn die die externe IP in die „trusted_proxies“ einträgst?
Gruß,
Jan
Hallo Jan,
dann kommt genau diese Meldung in der NC.
„ Sie verwenden eine externe IP für den Push-Service“ (so ähnlich)“
Gruß Hans
Hi Hans,
wie löst der Server selbst mit einem „ping“ die Domain der Cloud selbst auf? Stimmt die IP?
Ist die Meldung vielleicht nur ein Hinweis und keine Fehlermeldung?
Gruß,
Jan
Bei mir dasselbe. Hier die Meldung:
– – push server is not a trusted proxy, please add ’79.XXX.XX.XX‘ to the list of trusted proxies or configure any existing
reverse proxy to forward the ‚x-forwarded-for‘ send by the push server.
See https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/reverse_proxy_configuration.html#definin
g-trusted-proxies for how to set trusted proxies.
If you’re having issues getting the trusted proxy setup working, you can try bypassing any existing reverse proxy
in your setup by setting the `NEXTCLOUD_URL` environment variable to point directly to the internal Nextcloud webserver
url
(You will still need the ip address of the push server added as trusted proxy)
Hi Georg,
wenn das immer nicht nicht funktioniert, obwohl die entsprechende IP in „trusted_proxies“ eingetragen ist und der Webserver X-Forwarded-For richtig setzt: Versuch mal, in die /etc/hosts die Domain deiner Cloud auf die 127.0.0.1 „umzubiegen“. Dann sollte localhost als Trusted Proxy ja ausreichen.
Gruß,
Jan
Hi Jan,
danke für den Tipp! Der Eintrag in der /etc/hosts Datei hat geholfen!
Grüße
Georg
Hallo Jan,
ja, ist nur ein Hinweis, jedoch für mich nicht ganz nachvollziehbar.
Gruß Hans
Hi Hans,
naja, man kann sich das denke ich so vorstellen, dass ein Request gegen /push/ noch mal eine „zweite Runde“ durch den Webserver macht. Daher kann man diese Meldung denke ich ignorieren.
Ansonsten würde es sich evtl. anbieten, in der /etc/hosts (auf dem Server selbst) mal die Cloud-Domain auf die lokale LAN-IP zu setzen. Dann sollten solche Requests auch immer „Netzwerk-intern“ bleiben.
Gruß,
Jan
Hi,
sind ja schon ältere Posts, aber ich habe die ANleitung nocheinmal neu umgesetzt und bei mir kam der push auch von der öffentlichen WAN IP des Routers. Der Verweis in /etc/hosts von Netzwerk interner Server IP auf die Domain hat das Problem gelöst.
Vielen Dank :)
Danke für die Anleitung, wie müsste man das denn bei Apache machen?
Hi,
wie im Artikel erwähnt, sind im GitHub-Repository Erläuterungen enthalten, wie man dies mit anderen Web- oder Proxy-Servern aufsetzen kann. Hier ist auch die Anleitung für Apache zu finden.
Gruß,
Jan
Hallo,
mal eine Frage kann es sein das die Version Nextcloud 21 noch nicht für alle im Stabilen Kanal angeboten wurde. Denn ich habe heute auch wieder geschaut und leider ist die Version 21 immer noch für mich sichtbar.
Vielen Dank
Thomas
Hi Thomas,
ja, das kann gut sein, hier wird gerne mal gewartet, bis das erste Minor-Rrelease draußen ist. Um das Update zu erzwingen, kannst du mal probieren, auf den Beta-Update-Kanal umzustellen. Kann sein, dass es dir dann angeboten wird.
Gruß,
Jan
Hallo, brauche Hilfe.
ich finde es sehr gut wie Du das alles super erklärst. Folge hier ständig deinen Lernanweisungen…
Ich wollte jetzt auch „Einrichtung des High Performance Backends für Dateien“ einrichten. da mein Nextcloud auf einen Raspberry PI4 mit 4 GB Ram läuft. Nun bekomme ich bei ausführen des Befehls
sudo -u www-data php occ notify_push:setup
die folgende Antwort in ROT
In RedisQueue.php line 37: Redis server went away
Wo ist die Datei?, eigentlich im Ordner /var/www/html aber da ist nichts!
Kann mir jemand helfen
Hi Jens,
mit Redis meint er keine Datei, sondern die In-Memory-DB Redis. Diese muss vorher installiert sein, da das High Performance Backend darauf angewiesen ist. Hast du Redis bei dir schon installiert? Wenn nicht, dann schau mal hier vorbei.
Gruß,
Jan
Danke Jan,
so habe jetzt nochmals alles nach der Anleitung sorgfältig gemacht.
Komme jetzt bis fast zum Abschluss, der Dienst läuft (eingerichtet mit dem zweiten SSH Fenster) Wenn ich dann im ersten Fenster auf Enter drücke kommt dann folgende rote Meldung „push binary doesn’t seem to be running, did you follow the above instructions?“ das wars!!! liegt es an der PHP Version 8 oder was läuft noch falsch?
danke im vorraus
Jens
Hi Jens,
nein, die Binary-Datei basiert nicht auf PHP, daher wird das keine Rolle spielen.
Läuft denn die systemd Unit bei dir richtig? Sieht nämlich so aus, als wenn der Dienst gar nicht laufen würde…
Gruß,
Jan
Hi Jens,
auf der Github Seite stand für mich die Lösung:
„If you’re using nginx, add the following location block to the existing server block of the nextcloud server.“
Hast du die config vor dem server block rein kopiert, oder „ganz unten“ mit angestellt.?
Ersteres brachte bei mir deinen Fehler, letzeres schaffte es den zu beheben…
Hi Stefan,
ja, der location-Block muss im Server-Block aufgeführt werden, nicht irgendwo darunter oder so.
Gruß,
Jan
Hallo Jan,
das sagt der Befehl: sudo service notify_push status.
● notify_push.service – Push daemon for Nextcloud clients
Loaded: loaded (/etc/systemd/system/notify_push.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Mon 2021-03-22 20:21:17 GMT; 23h ago
Process: 32422 ExecStart=/var/www/nextcloud/apps/notify_push/bin/x86_64/notify_push /var/www/nextcloud/config/config.php (code=exited, status=203/EXEC)
Main PID: 32422 (code=exited, status=203/EXEC)
Mär 22 20:21:17 nextcloud systemd[1]: Started Push daemon for Nextcloud clients.
Mär 22 20:21:17 nextcloud systemd[32422]: notify_push.service: Failed to execute command: Permission denied
Mär 22 20:21:17 nextcloud systemd[32422]: notify_push.service: Failed at step EXEC spawning /var/www/nextcloud/apps/notify_push/bin/x86_64/notify_push: Permission denied
Mär 22 20:21:17 nextcloud systemd[1]: notify_push.service: Main process exited, code=exited, status=203/EXEC
Mär 22 20:21:17 nextcloud systemd[1]: notify_push.service: Failed with result ‚exit-code‘.
das heißt ein Berechtigungsproblem!
Was muss ich ändern?
Hi,
gut, da kommen wir der Lösung denke ich mal einen Schritt näher. Alles im apps-Verzeichnis der NC sollte ja dem User www-data gehören. Die systemd Unit wird auch unter dem User www-data aufgerufen.
Daher prüfe mal, ob dein Webserver-User wirklich www-data ist und ob die Berechtigungen korrekt gesetzt sind.
Ansonsten könntest du die Binary auch mal im Kontext des entsprechenden Users direkt auf der Kommandozeile aufrufen und nach irgendwelchen sonstigen Meldungen schauen.
Gruß,
Jan
Hallo Jan,
habe die Berechtigung nochmals mit dem Befehl;
„chown -R www-data:www-data /var/www/nextcloud“
angepasst.
leider bekomme ich immer noch das Berechtigunsproblem!!!
● notify_push.service – Push daemon for Nextcloud clients
Loaded: loaded (/etc/systemd/system/notify_push.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Fri 2021-03-26 18:16:28 GMT; 8s ago
Process: 1903 ExecStart=/var/www/nextcloud/apps/notify_push/bin/x86_64/notify_push /var/www/nextcloud/config/config.php (code=exited, status=203/EXEC)
Main PID: 1903 (code=exited, status=203/EXEC)
Mär 26 18:16:28 nextcloud systemd[1]: Started Push daemon for Nextcloud clients.
Mär 26 18:16:28 nextcloud systemd[1903]: notify_push.service: Failed to execute command: Permission denied
Mär 26 18:16:28 nextcloud systemd[1903]: notify_push.service: Failed at step EXEC spawning /var/www/nextcloud/apps/notify_push/bin/x86_64/notify_push: Permission denied
Mär 26 18:16:28 nextcloud systemd[1]: notify_push.service: Main process exited, code=exited, status=203/EXEC
Mär 26 18:16:28 nextcloud systemd[1]: notify_push.service: Failed with result ‚exit-code‘.
Was mache ich falsch??
und danke das Du soviel Geduld hast
Jens
sorry muss nochmal kurz schreiben;
bekomme jetzt im NC Fehlerprotokol folgenden Eintrag
„Error PHP Error: fsockopen(): Unable to connect to localhost:7867 (Connection refused) at /var/www/nextcloud/apps/notify_push/lib/SetupWizard.php#90
<>
OC\Log\ErrorHandler::onError()
/var/www/nextcloud/apps/notify_push/lib/SetupWizard.php – line 90:
fsockopen()
/var/www/nextcloud/apps/notify_push/lib/Command/Setup.php – line 137:
OCA\NotifyPush\SetupWizard->isPortFree()
/var/www/nextcloud/3rdparty/symfony/console/Command/Command.php – line 255:
OCA\NotifyPush\Command\Setup->execute()
/var/www/nextcloud/3rdparty/symfony/console/Application.php – line 1009:
Symfony\Component\Console\Command\Command->run()
/var/www/nextcloud/3rdparty/symfony/console/Application.php – line 273:
Symfony\Component\Console\Application->doRunCommand()
/var/www/nextcloud/3rdparty/symfony/console/Application.php – line 149:
Symfony\Component\Console\Application->doRun()
/var/www/nextcloud/lib/private/Console/Application.php – line 215:
Symfony\Component\Console\Application->run()
/var/www/nextcloud/console.php – line 100:
OC\Console\Application->run()
/var/www/nextcloud/occ – line 11:
require_once(„/var/www/ne … p“)“
Kannst Du damit was anfangen??
Jens
Hi Jens,
das könnte genau der Hinweis sein: Port 7867 scheint belegt zu sein.
Prüfe mal, was auf diesem Port läuft.
Oder einfach in der systemd Unit und im proxy_pass im nginx einen anderen Port nutzen.
Gruß,
Jan
So fange jetzt noch einmal von vorne an. Welche PHP Version würdest Du jetzt installieren 7.3, 7.4 oder gleich 8.0 wobei es da noch keine PHP 8.0 JSON für raspberry gibt!!!
Danke für die Tipps.
Jens
Hi Jens,
ich empfehle immer, die PHP-Version zu nehmen, die in den Paketquellen deiner Distribution enthalten sind.
Beim Raspi müsste das (basierend auf Debian Buster) noch Version 7.3 sein.
Von der 8er Version würde ich momentan noch die Finger lassen.
Gruß,
Jan
Hallo Jan,
hatte ja neulich schon geschrieben daß es mit Ubuntu für Raspberry funktioniert. Nun habe ich ein neues Problem… und zwar die Performance. Wenn ich mit Samba Daten auf die Ganze RAID 8 Bay
(USB3.0) übertrage habe ich Geschwindigkeiten von bis zu 20 Mbits. Wenn ich jetzt über Nextcloud die WebDav Freigabe nutze und Daten in die Cloud schreiben möchte sind es max. 860 kbits!! Also riesen Unterschiede. Den PHP RAM habe ich schon erhöht auf 2047 MB. Was kann ich noch machen damit ich die Cloud schneller mit Daten füllen kann?
Raspberry Pi 4 mit 4 GB RAM
Danke im voraus…..
Jens
Hi Jens,
also erst einmal würde ich PHP keine 2 GB RAM geben, wenn der Raspi nur 4 GB hat. Im schlimmsten Fall fängt der nämlich das Swappen an und dann geht die Performance richtig in den Keller. Also max. 512 MB, nicht mehr.
Zum anderen sind 20MBit/s (also nur ca. 2,5MB/s) für die USB-Platte entschieden zu wenig. Ich bin nun nicht der Raspi-Experte, aber wenn man sich hier mal umhört, gibt es wohl häufiger Performance-Probleme mit USB 3.0 Platten am Raspi.
Der Sache würde ich erst einmal nachgehen und zwar ohne Samba, etc. Also erst einmal den Datendurchsatz bei direkten Schreiben/Lesen messen (hdparm). Wenn das schon zu langsam ist, wäre dieses Problem erst einmal zu lösen.
Des weiteren: Warum nutzt du Samba für die ext. Platte, wenn diese direkt an den Raspi angeschlossen ist? Du kannst doch die Platte dann einfach per /etc/fstab in den Raspi mounten und so direkt schreiben, oder?
Wenn alle anderen Sachen von der Performance her gut funktionieren, dann kann man sich daran machen, den Flaschenhals beim Zugriff über Nextcloud zu suchen. Das wird dann allerdings etwas aufwändiger, da hier sehr viele Faktoren eine Rolle spielen und es hier leider kein „Schema F“ gibt.
Gruß,
Jan
so nun bin ich am Gerät, sorry
hdparm -tT /dev/sdb1(NAS.Raid.Stationj)
Timing cached reads: 1638 MB in 2.00 seconds = 820.05 MB/sec
Timing buffered disk reads: 526 MB in 3.00 seconds = 175.19 MB/sec
root@NAS:~# hdparm -tT /dev/sdb1
/dev/sdb1:
Timing cached reads: 1674 MB in 2.00 seconds = 837.75 MB/sec
Timing buffered disk reads: 606 MB in 3.01 seconds = 201.58 MB/sec
root@NAS:~#
wäre also mehr als ausreichend
Was mir allerdings aufgefallen istdie SD Karte (Sandisk Ultra 64 GB) macht statt 80 MB/s nur um die 43 MB/s
/dev/mmcblk0p1:
Timing cached reads: 1752 MB in 2.00 seconds = 877.12 MB/sec
HDIO_DRIVE_CMD(identify) failed: Invalid argument
Timing buffered disk reads: 132 MB in 3.05 seconds = 43.34 MB/sec
root@NAS:~# hdparm -tT /dev/mmcblk0p1
/dev/mmcblk0p1:
Timing cached reads: 1812 MB in 2.00 seconds = 907.06 MB/sec
HDIO_DRIVE_CMD(identify) failed: Invalid argument
Timing buffered disk reads: 130 MB in 3.00 seconds = 43.33 MB/sec
die Raid Station hängt direkt über fstab mit USB 3.0 Anschluss im System drin. Brauch den Samba Server nur um auch als Fesplattenspeicher für meinen Festplattenreceiver. Da habe ich die schnellen Übertragungszeit. Verbunden ist alles mit Lan Kabel 1000/1000 (Mbps)
Kann es sein das die Datenbank sehr viel Speicher braucht….lieber auslagern!!! Hätte noch einen PI3 zur Verfügung!!!
Danke für dein Kopfzerbrechen……
Hi Jens,
OK, die Übertragungsdaten über USB 3.0 sehen gar nicht schlecht aus. Nun wird es allerdings schwer, den Flaschenhals für Samba/Nextcloud zu finden. Hier müsste man wirklich das System und alle einzelnen Prozesse genau analysieren.
Du könntest versuchen, die DB auch auf die ext. HDD zu packen. Dann würde dies nicht durch die SD-Karte ausgebremst. Ein Auslagern auf einen Raspi 3 macht da denke ich weniger Sinn, denn dieser schreibt ja auch wieder über HDD und dann kommt noch der Netzwerk-Overhead dazu.
Es wäre vielleicht eine Überlegung wert, den Raspi durch z.B. einen Intel NUC zu ersetzen. Schon der kleinste NUC hat schätzungsweise die 10-fache Leistung eines Raspis. Damit sollten sich die Performance-Probleme dann in Luft auflösen.
Gruß,
Jan
Moin Jan,
ich erhalte nach erfolgreicher Umsetzung folgende Meldung:
The reverse proxy header configuration is incorrect, or you are accessing Nextcloud from a trusted proxy. If not, this is a security issue and can allow an attacker to spoof their IP address as visible to the Nextcloud. Further information can be found in the documentation.
Ich habe es so eingerichtet, wie hier vorgeschlagen. Besteht meinerseits Bedarf zu handeln oder ist das nur eine Warnung?
Herzliche Grüße
Michael
Hi Michael,
ich sehe dies eher als Warnung, wenn hier wirklich ein Proxy zum Einsatz kommt.
Nur ohne Proxy wäre dies so zu verstehen, dass hier Handlungsbedarf besteht.
Gruß,
Jan
Bei mir wird die App nirgends angezeigt, muss ich da etwas besonderes machen? Ich habe zwei Instanzen : NC 20.0.10 und NC 19.0.10, auf beiden ist es aber nicht zu finden
Hi,
das High Peformance Backend for Files gibt es erst ab der Nextcloud Version 21. bei NC 19 bzw. 20 ist die App noch nicht im App Store zu finden.
Gruß,
Jan
Hi Jan,
ich habe alles gemäß Anleitung hinterlegt/eingerichtet.
Ich bekomme nach allem folgende Fehlermeldung:
root@nextcloud:/var/www/nextcloud# sudo -u www-data php occ notify_push:setup
This setup wizard is intended for use on single server instances
where the nextcloud server, web server/reverse proxy and push daemon all run on the same machine.
If your setup is more complex or involves any kind of load balancing
you should follow the manual setup instruction on the README instead
https://github.com/nextcloud/notify_push
Press enter to continue or ESC to cancel…
Push binary seems to be running already
🗴 failed to run self-test.
test output: ✓ redis is configured
🗴 using unencrypted https for push server is strongly discouraged
🗴 push server url is set to localhost, the push server will not be reachable from other machines
✓ push server is receiving redis messages
✓ push server can load mount info from database
✓ push server can connect to the Nextcloud server
🗴 push server is not a trusted proxy, please add ‚192.168.1.28‘ to the list of trusted proxies or configure any existing reverse proxy to forward the ‚x-forwarded-for‘ send by the push server.
See https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/reverse_proxy_configuration.html#defining-trusted-proxies for how to set trusted proxies.
The following trusted proxies are currently configured: „192.168.1.28“, „127.0.0.1“, „::1“
The following x-forwarded-for header was received by Nextcloud: 192.168.1.1
from the following remote: 192.168.1.28
If you’re having issues getting the trusted proxy setup working, you can try bypassing any existing reverse proxy
in your setup by setting the `NEXTCLOUD_URL` environment variable to point directly to the internal Nextcloud webserver url
(You will still need the ip address of the push server added as trusted proxy)
See the steps in the README for manual setup instructions: https://github.com/nextcloud/notify_push
unter trustet proxy waren bereits zwei Einträge vorhanden. Hängt es damit zusammen?
Hi,
trag doch mal in die /etc/hosts ein, dass er deine Domain auf 192.168.1.28 auflösen soll. Danach das „Setup“ nochmal ausprobieren.
Gruß,
Jan
Hi Jan,
habe ich eingetragen, jedoch leider ohne Erfolg.
Noch eine andere Idee?
Grüße
Timo
Hi Jan,
bekomme jetzt folgendes:
test output: ✓ redis is configured
🗴 using unencrypted https for push server is strongly discouraged
🗴 push server url is set to localhost, the push server will not be reachable from other machines
✓ push server is receiving redis messages
✓ push server can load mount info from database
🗴 push server can’t connect to the Nextcloud server
error sending request for url (https://cloud.meinedomain.de/index.php/apps/notify_push/test/cookie): error trying to connect: invalid certificate: CertExpired: error trying to connect: invalid certificate: CertExpired: invalid certificate: CertExpired
See the steps in the README for manual setup instructions: https://github.com/nextcloud/notify_push
Hi,
hier sagt er nun, dass das Zertifikat abgelaufen ist. Stimmt die Meldung, oder „lügt“ er hier?
Die /etc/hosts hast du noch so angepasst, dass die Domain auf localhost verweist?
Gruß,
Jan
Hi Timo,
der nächste Schritt wäre vermutlich, das Setup mal explizit mit der genutzten Domain aufzurufen:
occ notify_push:setup https://meinedomain.deGruß,
Jan
„Mit dem App-Update kommt meist auch eine neue Version des Binaries (notify_push), welches in der App enthalten ist und von der systemd Unit als Service genutzt wird. Hier gilt: Nach jedem Update der App „Client Push“ ist der Service neu zu starten:“
EINMAL im Leben hat systemd einen Vorteil und dann merkt es keiner 8-)))
(und schon fehlt die Hälfte).
Man kann systemd-Units durch Events auslösen lassen — und einer davon ist die Änderung einer Datei.
Man schreibt eine Datei xxx.path
::::::::::::::
apache2-restart.path
::::::::::::::
[Unit]
Description=Watch files to restart blah
Wants=apache2.service
[Path]
PathChanged=/etc/apache2/irgendeine-datei
[Install]
WantedBy=multi-user.target
und dann dazu
eine Datei xxxxx.service
apache2-restart.service
[Unit]
Description=Restart apache
After=network.target
[Service]
Type=oneshot
WorkingDirectory=/var/tmp
User=root
Group=root
ExecStart=/bin/systemctl restart apache2.service
[Install]
WantedBy=multi-user.target
Hi,
danke für den Hinweis, das werde ich mir mal näher ansehen.
Gruß,
Jan
Ich hab das ganze gerade mal ausprobiert und es läuft bei mir. Getestet hab ich das ganze einfach mit einem „touch /srv/www/nextcloud/apps/notify_push/bin/x86_64/notify_push“. Wenn das nächste mal ein update in der Nextcloud App ansteht, werde ich mir das mal genauer anschauen.
Vielen Dank an noses für den Hinweis!
Hallo,
ich habe auch noch eine Frage dazu. Die Anleitung ist sehr gut.
Allerdings erhalte ich folgende Fehlermeldung beim Ausführen bei notify_push:setup
Ich erhalte folgende Fehlermeldung:
push binary doesn’t seem to be running, did you follow the above instructions?
Process: 4692 ExecStart=/var/www/nextcloud/apps/notify_push/bin/x86_64/notify_push /var/www/nextcloud/config/config.php (code=exited, status=203/EXEC)
Woran kann das liegen?
Ich freu mich auf eure Hilfe.
Vielen Dank
Hi Luca,
was sagt denn
service notify_push statusoder das syslog?Gruß,
Jan
Hallo Jan,
vielen Dank für deine schnelle Rückmeldung :)
Wenn ich notify_push status abrufe, erhalte ich folgende Fehlermeldung:
notify_push.service – Push daemon for Nextcloud clients
Loaded: loaded (/etc/systemd/system/notify_push.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Fri 2022-02-25 19:00:47 CET; 19h ago
Main PID: 4692 (code=exited, status=203/EXEC)
Feb 25 19:00:47 XXX systemd[1]: Started Push daemon for Nextcloud clients.
Feb 25 19:00:47 XXX systemd[4692]: notify_push.service: Failed to execute command: Permi>
Feb 25 19:00:47 XXX systemd[4692]: notify_push.service: Failed at step EXEC spawning /va>
Feb 25 19:00:47 XXX systemd[1]: notify_push.service: Main process exited, code=exited, s>
Feb 25 19:00:47 XXX systemd[1]: notify_push.service: Failed with result ‚exit-code‘.
Hilft dir das weiter?
Worauf muss ich achten, wenn ich syslog auslese?
Ich danke dir schon einmal vielmals :)
Hi Luca,
der interessante Teil der Ausgabe scheint hier nicht mit gekommen zu sein. Interessant wird es in der Zeile, die mit
Failed to execute command: Permi>endet.Daher tippe ich mal, dass es sich um Dateiberechtigungen o.ä. handelt, die noch falsch gesetzt sind.
Gruß,
Jan
Hi Jan,
da habe ich scheinbar die Ausgabe nicht korrekt kopiert.
Ich habe nun das nocheinmal durchgeführt.
Nun erhalte ich auch die Ausgabe:
„systemd[373435]: notify_push.service: Failed at step EXEC spawning /var/www/nextcloud/apps/notify_push/bin/x86_64/notify_push: Permissi>“
Die komplette Meldung:
Feb 28 14:44:24 systemd[1]: Started Push daemon for Nextcloud clients.
Feb 28 14:44:24 systemd[373435]: notify_push.service: Failed to execute command: Permission denied
Feb 28 14:44:24 systemd[373435]: notify_push.service: Failed at step EXEC spawning /var/www/nextcloud/apps/notify_push/bin/x86_64/notify_push: Permissi>
Feb 28 14:44:24 systemd[1]: notify_push.service: Main process exited, code=exited, status=203/EXEC
Feb 28 14:44:24 systemd[1]: notify_push.service: Failed with result ‚exit-code‘.
Das heißt, die App notify_push hat keine notwendigen Berechtigungen, Richtig?
Wenn ja, wie vergebe ich diese Berechtigung?
Ich danke dir :)
Hi Luca,
leider ist die Meldung schon wieder abgeschnitten. ;-)
Daraus geht leider nicht hervor, welche Berechtigungen ihm fehlen.
Gruß,
Jan
Hi Jan,
das ist mir unangenehm. So nun der dritte Versuch :) Aber nun habe ich alles kopiert. Was meinst du, woran es liegt?:)
notify_push.service – Push daemon for Nextcloud clients
Loaded: loaded (/etc/systemd/system/notify_push.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Mon 2022-02-28 14:44:24 CET; 2h 14min ago
Process: 373435 ExecStart=/var/www/nextcloud/apps/notify_push/bin/x86_64/notify_push /var/www/nextcloud/config/config.php (code=exited, status=203/EXEC)
Main PID: 373435 (code=exited, status=203/EXEC)
Feb 28 14:44:24 XXX systemd[1]: Started Push daemon for Nextcloud clients.
Feb 28 14:44:24 XXX systemd[373435]: notify_push.service: Failed to execute command: Permission denied
Feb 28 14:44:24 XXX systemd[373435]: notify_push.service: Failed at step EXEC spawning /var/www/nextcloud/apps/notify_push/bin/x86_64/notify_push: Permission denied
Feb 28 14:44:24 XXX systemd[1]: notify_push.service: Main process exited, code=exited, status=203/EXEC
Feb 28 14:44:24 XXX systemd[1]: notify_push.service: Failed with result ‚exit-code‘.
Ich freu mich auf deine Rückmeldung.
Hi Luca,
OK, er sagt auch lediglich „Permission denied“ ohne weitere Angaben.
Das kann aber z.B. daran liegen, dass das Binary-File nicht am angegebenen Ort (systemd-Unit) zu finden ist.
Was sagt bei dir ein
ls -la /var/www/nextcloud/apps/notify_push/bin/x86_64/notify_push?Gruß,
Jan
Erst einmal wieder vielen Dank für deine schnelle Rückmeldung.
Wie kann es passieren, dass die Binary-Datei nicht am richtigen Ort ist?
Ich habe den Befehl ausgeführt und erhalte folgenden Hinweis:
root@xxx:/var/www/nextcloud# ls -la /var/www/nextcloud/apps/notify_push/bin/x86_64/notify_push
-rw-r—– 1 www-data www-data 22144304 Feb 13 21:49 /var/www/nextcloud/apps/notify_push/bin/x86_64/notify_push
Was genau bedeutet das?
Vielen Dank im Voraus
Hi Luca,
das bedeutet, dass die Datei an angegebenen Pfad existiert.
Probiere als nächstes mal, den Befehl manuell auszuführen, der in der systemd-Unit unter „ExecStart“ angegeben ist.
Gruß,
Jan
Hi Jan,
mal wieder vielen Dank für deine fixe Rückmeldung. Starte ich den Befehl manuell mit system enable?
da bin ich mir gerade nicht sicher.
Dankeschön.
Viele Grüße
Luca
Hi Luca,
einfach den Befehl hinter dem ‚=‘ in die Kommandozeile eingeben. Hoffentlich kommt da dann eine aussagekräftigere Fehlermeldung.
Gruß,
Jan
Hallo Jan,
ich habe denb Befehl angewandt. Anbei die Meldung, die ich erhalten habe.
root@XXX:/var/www/nextcloud# /var/www/nextcloud/apps/notify_push/bin/x86_64/notify_push /var/www/nextcloud/config/config.php
bash: /var/www/nextcloud/apps/notify_push/bin/x86_64/notify_push: Permission denied
You have new mail in /var/mail/root
Hilft uns das weiter?
Da bekommen wir leider keine weiteren Infos raus.
Hast du noch weitere Ideen?
Hi Luca,
da ist nur das
You have new mail in /var/mail/rootetwas komisch. Hast du so etwas wie msmtp o.ä. installiert? Schau nach der Ausführung des Befehls doch mal ins Syslog (auf die Zeitstempel achten, da hier u.U. „viel los ist“).Gruß,
Jan
Hi Jan,
genau, ich habe postfix installiert. Nun habe ich den Befehl erneut ausgeführt.
Dieses Mal kam diese Meldung nicht.
Zum Test habe ich folgenden Push service erneut gestartet. Der Befehl lautet:
„systemctl enable –now notify_push“
Danach habe ich mir mit dem Befehl „tail /var/log/syslog“ die lezten Einträge anzeigen lassen.
Ich habe folgendes Ergebnis erhalten:
Mar 7 23:02:04 XXX systemd[1]: Reloading.
Mar 7 23:02:05 XXX systemd[1]: Started Push daemon for Nextcloud clients.
Mar 7 23:02:05 XXX systemd[40300]: notify_push.service: Failed to execute command: Permission denied
Mar 7 23:02:05 XXX systemd[40300]: notify_push.service: Failed at step EXEC spawning /var/www/nextcloud/apps/notify_push/bin/x86_64/notify_push: Permission denied
Mar 7 23:02:05 XXX systemd[1]: notify_push.service: Main process exited, code=exited, status=203/EXEC
Mar 7 23:02:05 XXX systemd[1]: notify_push.service: Failed with result ‚exit-code‘.
Mar 7 23:02:06 XXX postfix/postqueue[40302]: warning: /etc/postfix/main.cf,line 52: overriding earlier entry: smtp_tls_security_level=may
Kann man sich das aufrufen /var/mail/root?
Das bringt jetzt auch nicht so viel Aufschluss, oder?
Hi Luca,
nein, leider gibt das auch keine weiteren Hinweise. Das letzte, was mir noch einfällt: Versuch mal, die Binary als ausführbar zu markieren:
chmod +x /var/www/nextcloud/apps/notify_push/bin/x86_64/notify_pushDamit gab es mal vor einiger Zeit Probleme, sollte aber mit der Version 0.13 behoben worden sein.
Ansonsten würde ich empfehlen, mal einen Issue bei GitHub wegen des Problems auf zu machen.
Gruß,
Jan
Hi Jan,
ich wollte dir die Rückmeldung geben, dass nun alles geklappt hat. ich danke dir wirklich vielmals für deine schnelle Hilfe :)
Viele Grüße
Luca
Hi Luca,
erst einmal danke für die positive Rückmeldung.
Woran hat es nun eigentlich gelegen? Interessiert mich, da ich ein solches Problem noch nie beobachten konnte…
Gruß,
Jan
Hallo Jan,
Sorry für die späte Rückmeldung.
Es war ein ganz einfacher und blöder Fehler. Ich habe in die notify_push.service folgenden Befehl eingefügt:
ExecStart=/var/www/nextcloud/apps/notify_push/bin/x86_64/….
Habe mich ja an deine Anleitung gehalten. Dabei ist mir die ganze Zeit nicht aufgefallen, dass ich kein x86_64 System habe, sondern ein arch64. Den Pfad habe ich dementsprechend abgeändert und schon hat es funktioniert :)
Also ein ganz unnötiger Fehler von mir. Aber ohne deine Hilfe hätte ich den nicht gefunden.
Deswegen danke ich dir noch einmal vielmals :)
Hi Luca,
ok, dann konnte es ja nicht funktionieren. Auf diese Ursache wäre ich allerdings nie gekommen.
Aber super, dass es bei dir nun klappt und danke für die Rückmeldung.
Gruß,
Jan
Hallo Jan,
nun muss ich mich doch noch einmal zu diesem Thema melden :) Ich habe mir auf den nginx das Geo-Blocking installiert (super Anleitung übringens) :) – Nun erhalte ich wieder folgende Fehlermeldung, wenn ich den push service abfrage:
notify_push[3553]: [2022-04-01 15:46:57.753844 +00:00] ERROR [notify_push] src/main.rs:60: Self test failed: Failed to request app verson: error sending request for url (https://XXX/index.php/apps/notify_push/test/version): http2 error: stream error received: unspecific protocol error detected: stream error received: unspecific protocol error detected
Hast du eine Idee, woran das liegt? :)
Ich danke dir schon einmal vielmals
Hi Luca,
der Fehler ist mir bisher noch nicht unter gekommen. Kannst du mal ausprobieren, den Push-Dienst komplett neu aufzusetzen?
Gruß,
Jan
Hi Jan,
dann werde ich das mal machen. Wie kann ich denn alles nochmal zurücksetzen? gibt es einen befehl mit dem man gleich alle Datei, Verzeichnisse, etc löscht?
Danke dir
Hi Luca,
naja, die App einfach nochmal löschen, neu herunter laden und das „Setup“ nochmal neu durchgehen. Hier auf evtl. erscheinende Fehlermeldungen achten.
Gruß,
Jan
Hi Jan,
ich habe den Fehler gefunden. Es lag an meinen Einstellungen für das Geoblocking des nginx.
Jetzt läuft alles super.
Ich danke dir vielmals für deine Hilfe und deinen super Anleitungen
Hallo Jan,
ersteinmal auch von mir ganz herzlichen Dank für deine super Anleitungen. Mir, als absoluten Newbie auf dem Gebiet, hast du damit schon mehrfach aus der Patsche geholfen! Besten Dank!
Vielleicht kannst du mir bei meinem neuesten Problem auch weiterhelfen:
Vermutlich ist es das gleiche, wie bei Luca:
Ich habe das High-Performance Backend nach deiner Anleitung eingerichtet, aber es scheint irgendwie mit dem Geo-ip blocking zu kollidieren:
Wenn ich in der nginx.conf default=no setze, gibt der notify_push.service folgenden Error aus:
`May 01 21:07:53 cloud notify_push[10266]: [2022-05-01 21:07:53.214580 +02:00] ERROR [notify_push] src/main.rs:77: Self test failed: Error while communicating with nextcloud instance`
Bei default=yes hingegen scheint er sauber zu laufen.
Der Geo-ip block part in der nginx.conf sieht bei mir grade so aus:
`geoip2 /usr/share/GeoIP/GeoLite2-Country.mmdb {
$geoip2_data_country_iso_code country iso_code;
}
map geo $LAN-ip {
default no;
127.0.0.1 yes;
::1 yes;
192.168.178.0/24 yes;
}
map $geoip2_data_country_iso_code $allowed_country {
default no;
DE yes;`
Ausserdem ist in der nextcloud.conf
`if ($LAN-ip = yes) {
set $allowed_country yes;
}
if ($allowed_country = no) {
return 444;
}`
eingefügt.
Hast du vielleicht noch eine idee, wo es da hängen könnte? Bin für jeden tipp dankbar.
@LUCA wie hast du das bei dir gelöst?
Beste Grüße.
Hi,
dein Konzept sieht erst einmal gut aus. Allerdings musst du darauf achten, dass du in deinem Netzwerk wirklich mit der LAN-IP an die Cloud kommst. Das geht eigentlich nur, wenn die Domain bei dir lokal auf die LAN-IP auflöst. Ansonsten werden diese Requests auch „über das Internet“ gesendet.
Was passiert, wenn du folgende URL aufrufst (mit deiner richtigen Domain): https://meine.cloud.de/push/test/version
Gruß,
Jan
Danke für die schnelle Antwort!
Jetzt bin ich unsicher, was du mit „im Netzwerk WIRKLICH mit der LAN-IP an die Cloud kommen“ meinst. Wenn ich die lokale ip im browser eintragen, kommt die nextcloud-Anmeldung. Das müsste es doch sein, oder? Sorry, dass ich nachfrage ;-)
Wenn ich https://meine.cloud.de/push/test/version eingebe kommt:
„HTTP method not allowed“
Hilft das irgendwie weiter?
Hi,
ok, du gehst über die IP-Adresse und nicht über die Domain. Kann man auch so machen, aber dann meckert ja jeder Browser, dass das Zertifikat nicht passt.
Dieses „HTTP method not allowed“ passt auch so weit. Wenn hier kein HTTP 444 kommt, dann greift hier der Geoblock nicht. Dann kann das eigentlich mit dem Geoblock nix zu tun haben.
Kannst du mal versuchen, beim Setup des HPB mal die Domain explizit mitzugeben?
Gruß,
Jan
Doch, sorry für das Missverständnis. Eigentlich gehe ich immer über die Domain. ich hatte nur beim geoblocking auch mal die ip eingetragen, um das sicher auszuschließen.
Mit deinem Verdacht, das es nicht das Geoblocking ist, liegst du übrigens richtig. mittlerweile kommt die Fehlermeldung auch mit default=yes. hatte wohl ein bisschen verzögerung und ich hab mich zu früh gefreut. Schade.
Meinst du die domain im HPB setup in /etc/systemd/system/notify_push.service?
`
…
Environment=NEXTCLOUD_URL=https://meine.domain.de
…
`
Das hatte ich schon immer so gemacht. nicht mit der ip.
Genauso bei der client-push app installation.
Oder gibts beim setup noch ne andere stelle, wo die Domain rein muss, die ich übersehen habe?
Hi,
ok, dann passt das ja und es liegt wohl nicht am Geoblocking.
Trag doch mal in der /etc/hosts die NC-Domain mit 127.0.0.1 auf dem Server ein.
Bzgl. der Domain gibt es sonst keine Einstellungen beim Setup mehr, das ist die einzige Option.
Gruß,
Jan
Hi Jan,
hab jetzt nochmal rumprobiert, aber leider noch keine Lösung für die Geo-ip-allowlist gefunden:
Geo ip blocking ist komplett auskommentiert und „service notify_push status“ läuft nach dem 1. start ohne fehler bis zum reboot.
Danach erscheint dann: „ERROR [notify_push] src/main.rs:77: Self test failed: Error while communicating with nextcloud instance“
geo ip blocking ist es hier also wohl nicht.
Wenn ich `sudo -u www-data php occ notify_push:setup https://meine.domain.de/push` , oder das setup normal, oder den selbsttest danach ausführe, sieht alles gut aus:
✓ redis is configured
✓ push server is receiving redis messages
✓ push server can load mount info from database
✓ push server can connect to the Nextcloud server
✓ push server is a trusted proxy
✓ push server is running the same version as the app
configuration saved
Kann ich sonst irgendwie checken, ob HPB sauber läuft?
Wenn ich dann allerdings geo ip blocking mit allowlist wieder reinmache, läuft HPB nicht mehr:
`🗴 can’t connect to push server: cURL error 56: OpenSSL SSL_read: Connection reset by peer, errno 104 (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://cloud.meinedomain.de/push/test/cookie`
Auch das setup läuft dann nicht mehr durch, egal was ich mache.
Denke, ich werde als plan B die Blockliste reinmachen. Muss ich halt die Schurkenstaaten selber eintragen, aber besser als nix ;-)
Ich vermute, es liegt irgendwie an meiner dilettantisch eingerichteten IP/Domain konstellation.
Ist wahrscheinlich noch ne wichtige info, die ich vergessen habe:
die cloud läuft als LXS-container auf Proxmox.
Deinen vorherigen kommentar hab ich falsch verstanden: Ich scheine also über die IP und nicht über die Domain zu gehen. Das erklärt dann auch, warum der browser meckert trotz zertifikat.
Ist das dann nur der Eintrag in `/etc/hosts`?
Sähe dann so aus:
127.0.0.1 meine.domain.de
Macht aber für den HPB Fehler keinen unterschied.
Hast du vielleicht einen Tip für eine gute Anleitung, wo ich mir die Domain/IP geschichte nochmal angucken kann. Und wie man das einrichtet. Das wäre super hilfreich.
Bestend Dank auf jeden Fall, für deine Mühe und Geduld.
Beste Grüße,
Iring
Hi,
also ich würde da erst einmal möglichst viele Variablen aus der Gleichung nehmen. Wenn Geoblocking komplett deaktiviert ist, funktioniert das HPB ja anscheinend erst einmal. Erst nach einem Reboot tut es das dann nicht mehr. Hier würde ich erst einmal ansetzen. Leider fällt mir dazu spontan auch nichts mehr ein. Am besten mal bei GitHub ein Issue eröffnen.
Zum Eintrag in der /etc/hosts (auf dem Server): Dies bewirkt nur, dass er „seine eigene Domain“ einfach nur lokal auflöst.
Damit das bei dir im gesamten Netzwerk auf die LAN-IP aufgelöst wird (also auch für jeden Client), dazu brauchst du einen eigenen DNS-Server. Dazu kann aber auch Pi-hole verwendet werden.
Mal was ganz anderes, bevor du da nun viel Energie reinsteckst: Wie viele Clients sind denn dauerhaft mit deiner NC verbunden? Einen positiven Effekt durch das HPB wirst du erst merken, wenn dies hunderte Clients sind, ansonsten wirst du da absolut keinen Unterschied merken. Das nur mal so nebenbei erwähnt – und ja, ich weiß: Egal, was es bringt, man möchte es mindestens einmal ans Laufen gebracht haben. ;-)
Gruß,
Jan
Hi Jan,
an hunderten von Clients bin ich nicht mal annähernd dran. Währe mit meinem Setup auch grob fahrlässig ;-)
Du triffst es aber ganz genau: “Egal, was es bringt, man möchte es mindestens einmal ans Laufen gebracht haben.” X-D
Ich denke aber, das kann man jetzt mal so als „laufen“ gelten lassen und widme mich lieber dem Thema dns-server.
Vielen Dank auf jeden Fall für deinen Input. Hast mich beim Einstieg in die Thematik einen Riesen Schritt weiter gebracht. Also besten Dank nochmal und weiter so.
Viele Grüße,
Iring
Hallo Jan,
ich habe mal wieder einen Fehler den ich nicht ganz nachvollziehen kann.
Failed to connect to database
error returned from database: 1130: Host ‚127.0.0.1‘ is not allowed to
connect to this MariaDB server
1130: Host ‚127.0.0.1‘ is not allowed to connect to this MariaDB server
????
Gruß Hans
Hi Hans,
wo genau kommt dieser Fehler?
Versuch es mal mit ‚localhost‘ und nicht mit ‚127.0.0.1‘.
Gruß,
Jan
Hallo Jan,
der Fehler wird dann ausgegeben wenn ich den Push-Service starte ( service notify_push restart). Ich versuche mal localhost.
Vielen Dank
Gruß Hans
Hallo Jan,
hat nichts gebracht, ich schaue weiter.
Danke!
Gruß Hans
Hi Hans,
welche NC Version hast du genau? Und wie schaut der OCC-Befehl für das Setup konkret aus? Kann nämlich sein, dass du da noch deine NC-Domain mit angeben musst.
Gruß,
Jan
Hallo Jan,
wie von dir beschrieben habe ich auch die NC-Domain mit angegeben. NC 24.07.
Ich google mal weiter und installiere ggf. den Service neu.
So einen Fehler hatte ich noch nie.
Wenn ich den Service (manuell) starte kommt kein Fehler, dieser wird erst ausgegeben wenn ich den Server neu gestartet habe und den Service im Anschluss prüfe, wird der Fehler ausgegeben.
Vielen Dank
Gruß Hans
Hi Hans,
also wenn du den Server neu startest und im Anschluss den Dienst selbst, dann funktioniert es? Dann probier mal aus, per Cron den Dienst nach Reboot und z.B. 15 Sekunden Wartezeit neu zu starten. Kann sein, dass dies ein Problem mit der Reihenfolge ist.
Gruß,
Jan
Hallo Jan.
Danke für die Anleitung!
Ich bekomme bei der Einrichtung immer eine Zertifikatsfehlermeldung.
Das Zertifikat ist ein gekauftes AlphaSSL Wildcard und macht weder beim Nginx noch auf zahllosen anderen Systemen Probleme. Ich bin nicht ganz so firm in Webservern und SSL und vielleicht habe ich da irgendwas falsch konfiguriert. Hast Du vielleicht eine Idee zur Folgenden Fehlermeldung („adresse-meines-webservers“ ist natürlich nur für diesen Kommentar geändert und eigentlich die richtige FQ-Adresse)
🗴 failed to run self-test.
test output: ✓ redis is configured
🗴 using unencrypted http for push server is strongly discouraged
🗴 push server url is set to localhost, the push server will not be reachable from other machines
✓ push server is receiving redis messages
✓ push server can load mount info from database
🗴 push server can’t connect to the Nextcloud server
error sending request for url (https://„adresse-meins-servers“/index.php/apps/notify_push/test/cookie): error trying to connect: invalid peer certificate contents: invalid peer certificate: UnknownIssuer
Hi Basti,
also aus der Fehlermeldung kann ich nur heraus lesen, dass irgend etwas mit dem Zertifikat nicht stimmt. Wie schaut das Testergebnis von Qualys SSL Labs aus?
Ich kenne es ansonsten nur, dass manche gekauften Zertifikate erst einmal „zusammen gebaut“ werden müssen, d.h. die Chain aus den Dateien erstellt werden muss, die du vom Zertifikats-Anbieter bekommst. Das unterscheidet sich aber wohl von Anbieter zu Anbieter, daher kann ich dir hier leider keine konkreten Tipps geben.
Gruß,
Jan
Hi Jan. Danke für die Antwort.
Ich nutze die Webserver-Protection einer Sophos UTM vor der Nextcloud. Ich vermute das daher die Qualys SSL Tests das Zertifikat auf der UTM Abfragen. Hier sitzt allerdings eigentlich das gleiche Zertifikat (ist ein Alpha SSL Wildcard).
Hier gibts ein paar „Orange“ Meldungen, mit denen ich als Zertifikats-Laie allerdings nur bedingt etwas anfangen kann unten ein paar der Meldungen.
Ich habe erstmal auf LetsEnrypt umgestellt und damit klappte es sofort, war also eindeutig ein Zertifikats-Thema.
Eine weitere Frage zur Performance generell, ich hoffe das ist ok wenn ich das hier Platziere:
Ich nutze Nextcloud für ausgiebiges Daten-Synchronisieren, viele kleine und auch große Dateien. Ich habe von 4 auf 8 GB RAM erweitert, kannst Du mir einen Tipp geben wo ich die RAM Erweiterung dem System mitteilen muss (PHP-FPM?, NGINX?, PostgrSQL?)
Danke!!!
VG Basti
Qualys SSL Meldungen orange:
DNS CAA No (more info)
TLS 1.0 und 1.1
und diverse Ciphers.
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH secp256r1 (eq. 3072 bits RSA) FS WEAK 256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH secp256r1 (eq. 3072 bits RSA) FS WEAK 256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b) DH 2048 bits FS WEAK 256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) DH 2048 bits FS WEAK 256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH secp256r1 (eq. 3072 bits RSA) FS WEAK 128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH secp256r1 (eq. 3072 bits RSA) FS WEAK 128
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x67) DH 2048 bits FS WEAK 128
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) DH 2048 bits FS WEAK 128
TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d) WEAK 256
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c) WEAK 128
TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d) WEAK 256
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) WEAK 256
TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c) WEAK 128
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) WEAK 128
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) ECDH secp256r1 (eq. 3072 bits RSA) FS WEAK 112
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16) DH 2048 bits FS WEAK 112
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) WEAK 112
Hi Basti,
das einzige „No-Go“, was ich bei den Alpha SSL Zertifikaten/Sophos sehe, ist dass TLSv1.0 und TLSv1.1 zugelassen sind. Das sollte man heutzutage nicht mehr machen (TLSv1.2 ist das absolute Minimum).
Das ist dann leider ein Problem mit diesen Zertifikaten bzw. der Sophos. Hier habe ich leider keinerlei Erfahrungen, daher kann ich dazu nichts sagen.
Wenn du den RAM erweiterst, dann sind hier lediglich die PHP-Einstellungen rund um „pm.max_children“ anzupassen, falls du hier etwas verändert hast und diese auf das tatsächlich vorhandene RAM optimiert wurden. Andere Stellen sind hier eigentlich nicht anzupassen.
Gruß,
Jan
Hi Jan.
Danke Dir!
TLS1.0 und 1.1 habe ich inzwischen deaktiviert. Jetzt bekomme ich immerhin ein A-Rating.
Das mit dem RAM schaue ich mir dann mal an.
Besten Dank für die Infos.
VG Basti