Nextcloud 21: High Performance Backend für Dateien

Nextcloud Logo

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

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.

Die App "Client Push" im Nextcloud App Store
Die App „Client Push“ im Nextcloud App Store

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).

Meldung bzgl. fehlendem Eintrag bei trusted_proxies
Meldung bzgl. fehlendem Eintrag bei trusted_proxies

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.

Instruktionen zum anlegen der systemd Unit
Instruktionen zum anlegen der systemd Unit

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 war erfolgreich
Die Einrichtung des High Performance Backends war erfolgreich

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

94 Kommentare zu „Nextcloud 21: High Performance Backend für Dateien“

  1. 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.

    1. 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

      1. 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

        1. 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

    1. 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

    1. 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

  2. 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 :-)

    1. 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

      1. 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.

    2. 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.

  3. 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

      1. 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

          1. Hallo Jan,

            dann kommt genau diese Meldung in der NC.
            „ Sie verwenden eine externe IP für den Push-Service“ (so ähnlich)“

            Gruß Hans

          2. 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

          3. 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)

          4. 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

    1. 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

  4. 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

    1. 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

  5. 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

    1. 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

      1. 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

        1. 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

        2. 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…

          1. Hi Stefan,

            ja, der location-Block muss im Server-Block aufgeführt werden, nicht irgendwo darunter oder so.

            Gruß,
            Jan

  6. 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?

    1. 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

      1. 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

      2. 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

        1. 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

  7. 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

    1. 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

      1. 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

        1. 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

          1. 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……

          2. 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

  8. 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

    1. 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

  9. nickvergessen

    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

    1. 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

  10. 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?

    1. 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

        1. 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

          1. 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

        2. Hi Timo,

          der nächste Schritt wäre vermutlich, das Setup mal explizit mit der genutzten Domain aufzurufen: occ notify_push:setup https://meinedomain.de

          Gruß,
          Jan

  11. „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-)))

    1. (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

        1. 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!

  12. 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

      1. 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 :)

        1. 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

          1. 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 :)

          2. Hi Luca,

            leider ist die Meldung schon wieder abgeschnitten. ;-)
            Daraus geht leider nicht hervor, welche Berechtigungen ihm fehlen.

            Gruß,
            Jan

          3. 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.

          4. 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

          5. 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

          6. 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

          7. 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

          8. Hi Luca,

            einfach den Befehl hinter dem ‚=‘ in die Kommandozeile eingeben. Hoffentlich kommt da dann eine aussagekräftigere Fehlermeldung.

            Gruß,
            Jan

          9. 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?

          10. Hi Luca,

            da ist nur das You have new mail in /var/mail/root etwas 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

          11. 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?

          12. 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_push
            Damit 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

          13. 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

          14. 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

          15. 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 :)

          16. 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

        2. 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

          1. Hi Luca,

            der Fehler ist mir bisher noch nicht unter gekommen. Kannst du mal ausprobieren, den Push-Dienst komplett neu aufzusetzen?

            Gruß,
            Jan

          2. 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

          3. 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

          4. 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

          5. 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.

          6. 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

          7. 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?

          8. 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

          9. 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?

          10. 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

          11. 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

          12. 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

          13. 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

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht.