Bitwarden stürzt ab, wenn neuer Ordner angelegt werden soll

[iPaul]

Hallo

Ich habe Bitwarden im Docker auf meiner 1513+ erfolgreich am Laufen. Mir ist jedoch aufgefallen, dass BW abstürzt, wenn ich im Web-Client einen neuen Ordner in meinem Tresor anlegen will. Die Fehlermeldung (Anhang) ist für mich unverständlich. Da darin jedoch Chrome erwähnt wird, habe ich es auch mit Firefox probiert. Das Problem bleibt jedoch bestehen.

Es passiert folgendes:
Ich versuche einen neuen Ordner anzulegen, dann erscheint längere Zeit der Am-Arbeiten-Kreis und dann Fehlermeldung. Danach geht nichts mehr und ich muss BW im Docker neu starten.

Eine Idee, wo ich ansetzen kann?

 

[THDev]

container log währenddessen sagt was?

 

[haydibe]

Status Code 405 steht bei http generell für "Method Not Allowed". Es deutet darauf hin, dass der Client versucht mit dem Server in einer nicht unterstützen Art und Weise versucht zu kommunizieren. Aktualisiere den Bitwarden-Container(-Zoo falls es das "echte" Bitwarden ist) und die Clients bzw. Browser plugins auf die jeweils neuste Version und schau, ob sich das Problem dann erledigt hat. Das Problem kann es eigentlich nur geben wenn Client und Server nicht "sauber" zusammenpassen.

Kann aber auch sein, dass die Fehlermeldung und der zurückgegebene Status Code einfach nur murks sind.

 

[iPaul]

Danke für die Antworten.

Erstaunlicherweise konnte ich nun zwei Ordner anlegen und einen wieder löschen. Der Fehler trat erst beim Löschen des zweiten Ordners auf. Dann jedoch gleiches Verhalten und gleiche Fehlermeldung.

Im Log steht in dieser Zeit nichts. Weder beim Anlegen der Ordner, noch beim Löschen. Habe sowohl das Protokoll via Docker angeschaut, als auch das im Portainer.

Aktualisiert hab ich den Container gestern. Neuere Version gibt es nicht. Ich verwende jedoch bitwardenrs-server. Ist das nicht das richtige Bitwarden?

 

[haydibe]

Ich verwende jedoch bitwardenrs-server

Das ist eine Schlüsselinformation. Bitwardenrs ist eine eigenständige Lösung, die api-kompatibel ist mit dem orginal Bitwarden und damit auch kompatibel mit dessen Clients. Während das orginal Bitwarden alles andere als schonen mit Systemressourcen umgeht (CPU/RAM/Storage), ist Bitwardenrs das extreme Gegenteil.

Es ist nicht auszuschließen, dass es vorkommt, dass das original Bitwarden Änderungen einführt, die dann in die Clients fließen, die dann noch nicht in Bitwardenrs verfügbar sind.

Leg doch ein Issue im Github Projekt von bitwardenrs an: https://github.com/dani-garcia/bitwarden_rs/issues

Update:
Ich habe gerade mit dem Chrome-Plugin 3 neue Ordner hintereinander angelegt und auch weider gelöscht. Lief ohne Probleme. Allerdings ist mein bitwardenrs/server Container auch schon 2 Monate alt (demnach das Image dahinter auch mindestens so alt)

 

[iPaul]

OK. Werde ich machen.

Das Update von bitwardenrs habe ich jedoch gemacht, weil das Problem schon vorher bestand. Ich hoffte, das Update löst das Problem...Tat es leider nicht.

Ich hab schon davon gelesen, dass Installationen über Docker nicht so zuverlässig laufen, wie Installationen über die Commandozeile. Hab jedoch keine Ahnung, ob das wirklich relevant ist...

 

[DrDeath]

Ich habe das mal versucht nachzustellen, konnte es aber nicht.

Bei mir läuft der "latest" Docker Container von Bitwarden RS (bitwardenrs/server:latest)

Hast Du es schon einmal mit einem anderen Browser versucht, oder mit einem Smartphone Client.... passiert das dort auch ?

 

[haydibe]

Ich hab schon davon gelesen, dass Installationen über Docker nicht so zuverlässig laufen, wie Installationen über die Commandozeile. Hab jedoch keine Ahnung, ob das wirklich relevant ist...

Für Anwender die Container mit ach und krach nach dubiosen Blog-Posts aufsetzen mag das stimmen
Ich arbeite nun seit knapp 6-7 Jahren mit Container und kann das nicht bestätigen.

Am Ende ist ein Docker Container nur ein isolierter Prozess auf dem Host der durch Isoliation nur den ihm erlaubten Teil des Hosts sehen und auch nur soviel Ressourcen nutzen darf, das ganze garniert mit Netzwerk und Storagemagie... Es hat so rein garnichts mit Server Virtualisierung zu tun, wie man es von VM's gewohnt ist

 

[iPaul]

Ich habe das mal versucht nachzustellen, konnte es aber nicht.

Bei mir läuft der "latest" Docker Container von Bitwarden RS (bitwardenrs/server:latest)

Hast Du es schon einmal mit einem anderen Browser versucht, oder mit einem Smartphone Client.... passiert das dort auch ?

Anderen Browser auch versucht. Gleiches Problem. Auch die Android App führt zum gleichen Resultat.

 

[iPaul]

Danke für eure Inputs.

Habe den Issue wie weiter oben empfohlen bei Github gepostet und folgende Antwort erhalten:

It looks like your reverse proxy is blocking PUT or DELETE requests (Since it returns 405).
Bitwarden_RS needs GET, POST, PUT, DELETE, without those HTTP Methods the application will not work.

Nun ist mir jedoch nicht bekannt, wie man das am Reverse Proxy auf der DS einstellen kann. Geblockt hab ich von mir aus gesehen nichts und irgendwie erscheint es mir dann nicht logisch, dass es doch manchmal funktioniert. Wenn geblockt, dann würde es doch nie klappen...

 

[DrDeath]

Zeig doch mal deine Reverse Proxy Einstellung.

Da die Einstellung über die Synology Web Oberfläche nicht den gewünschten Anforderungen entspricht, habe ich mir folgende nginx Reverse Proxy Einstellung per "root" user erstellt ( Nach diesem Vorbild: https://www.blackvoid.club/bitwarden-livesync-feature/ ) :

Mein bitwardenrs Container läuft auf der internen IP 192.168.2.10 und exposed die Ports 15080:80 und 15012:3012 , die müsstest du in der u.g. Konfiguration adaptieren.

Meine "/etc/nginx/sites-enabled/bitwarden_reverse_proxy.conf" sieht so aus:

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name                meine.domain.de;

    ssl_certificate            /usr/syno/etc/certificate/system/FQDN/fullchain.pem;
    ssl_certificate_key        /usr/syno/etc/certificate/system/FQDN/privkey.pem;

    location / {
        proxy_connect_timeout  60;
        proxy_read_timeout     60;
        proxy_send_timeout     60;
        proxy_intercept_errors off;
        proxy_http_version     1.1;
        proxy_set_header       Host                      $http_host;
        proxy_set_header       X-Real-IP                 $remote_addr;
        proxy_set_header       X-Forwarded-For           $proxy_add_x_forwarded_for;
        proxy_set_header       X-Forwarded-Proto         $scheme;
        proxy_pass             http://192.168.2.10:15080;

    }

    location /notifications/hub {
        proxy_pass             http://192.168.2.10:15012;
        proxy_set_header       Upgrade                   $http_upgrade;
        proxy_set_header       Connection                "upgrade";
    }

    location /notifications/hub/negotiate {
        proxy_pass             http://192.168.2.10:15080;
    }

    error_page 403 404 500 502 503 504 @error_page;

    location @error_page {
        root /usr/syno/share/nginx;
        rewrite (.*) /error.html break;
        allow all;
    }

}

 

[iPaul]

Hier meine Reverse Proxy-Einstellungen. Da gibts ja nicht viel anzupassen...

Mit nginx hab ich mich noch nicht beschäftigt. Das würde dann den in der DSM eingebauten Reverse Proxy ersetzen?

 

[DrDeath]

ja, korrekt.

 

[iPaul]

und das muss man über Console/Terminal einrichten?

 

[DrDeath]

Ja, die Anleitung dazu habe ich bereits gepostet in #11

 

[iPaul]

Hab ich gesehen. Danke. Nur noch nicht studiert...

 

[iPaul]

Hab die Anleitung mal umgesetzt. Irgendwas läuft jedoch noch nicht richtig.

Bei mir liegt das LetsEncrypt-Zertifikat in "/usr/syno/etc/certificate/system/default/". So habe ich das auch in der .conf eingetragen.

Wahrscheinlich stimmt was mit den Ports nicht. Da blick ich noch nicht durch.

Bei welchem proxy_pass kommt welcher Port hin? Ich hab jetzt mal beim ersten den eingetragen, den ich im Browser mit dem Hostnamen eingebe um mein BW zu öffnen.

Beim zweiten habe ich den Port eingegeben, auf den bisher der RP umgeleitet hat.

Beim dritten wieder den für die URL vom Browser.

In der .conf steht jedoch immer nur http. Ich bin der Meinung mit dem Zertifikat sollts ja über https laufen. Zumindet extern und intern dann umgeleitet auf http. So hab ich die Funktion des RP in der DSM verstanden.

Bring ich da was durcheinander?

 

[DrDeath]

Ja, du bringst etwas durcheinander.

Der nginx Reverse Proxy macht den https offload und reicht intern nur http weiter.

Der erste Eintrag für "location /" wird auf den http Port des bitwarden Containers gelenkt ( der, der mit XXXX:80 definiert wurde)
Der zweite Eintrag "location /notifications/hub" wird auf den WebSocket Port des bitwarden Containers gelenkt ( der, der mit XXXX:3012 definiert wurde)
Der dritte Eintrag für "location /notifications/hub/negotiate" wird wiederum auf den http Port des bitwarden Containers gelenkt ( der, der mit XXXX:80 definiert wurde)


Zudem liegen die Zertifikate in meiner Synology zusätzlich unter: /usr/syno/etc/certificate/system/FQDN/ (FQDN FullQualifiedDomainName)

 

[iPaul]

Ist das mit den Zertifikaten zusätzlich notwendig? Sollte ja nicht drauf ankommen, wo die liegen, oder?

Ich denke, ich hab das nun richtig in die .conf eingetragen. Und wie greif ich nun auf BW zu? Mit https://meine.domäne:xxxx geht es nicht, egal ob ich den http-Port des Containers, den des WebSocket oder auch keinen nehme.

Vorher mit dem RP aus der DSM hatte ich noch einen weiteren Port definiert, über den ich auf BW zugegriffen habe. Das gibts/brauchts mit der nginx-Variante nicht mehr?

 

[DrDeath]

Normalerweise mit https://deine.domain.de damit der nginx reverse proxy den https port 443 und den server_name deine.domain.de erkennt.

Die Verbindung von außen läuft ja so ab:

Internet —> dein DynDNS Name —> Router mit Portweiterleitung 443 auf deine Synology —> nginx Reverse Proxy 443 —> Bitwarden Docker Container Port XXXX —> im Container Port 80

Ich selbst habe meine Konfiguration nicht auf den https Port 443 laufen, sondern habe z.B. 5253 benutzt.

Dann muss ich auch: https://deine.domain.de:5253 aufrufen.