Skip to content

Bitwarden_RS auf einem Debian Buster 10 Server installieren!

Angeheftet Linux
  • @hase567 Willkommen!

    Ich habe ja in der Anleitung die Konfiguration für Apache2 drin, ich würde das gerne um die Nginx Konfiguration erweitern. Kannst Du die hier zur Verfügung stellen?

    Der Nico hat mir damals erzählt, das er zeitnah ein neues Debian Paket baut. Ich habe mal bei ihm angefragt..

  • Antwort vom Nico

    Aber du verwendest schon mein Repository? Dort bin ich aktuell eine Version hinter der neuesten. Warum? Die haben den Namen des Projektes geändert und ich weiß noch nicht wie ich das handlen soll. Und da es dort keine Sicherheitslücken gab, habe ich das vorerst nicht priorisiert.

    Kurzfassung: Updates kommen über das Repository. Sicherheitsupdates schnell, bei anderen kann es mal ein paar Tage bis Wochen dauern

  • Hi,
    danke für dein Feedback bzgl. der Updates...
    Also ich habe mich fast an Deiner apache Anleitung gehalten, bis auf die Apache conf-Anpassungen. Da ich nginx nutze, habe ich etwas gefunden.
    Auf der Website https://pieterhollander.nl/post/bitwarden/ findest du die Einträge für die Bitwarden nginx vault.conf. Diese habe ich fast 1:1 übernommen.
    Bisher läuft es auf einem Testserver bei mir ohne Probleme...

  • Hi Frank,
    konntest du damit etwas anfangen bzw. hast du es bereits getestet?

  • @hase567 Danke, der Link war informativ und ich denke ich bekomme das auch damit hin, wenn da nicht die Zeit wäre. So was mache ich selten, mal eben nebenbei. Somit brauche ich da mal eine ruhige Stunde für. Ausprobieren möchte ich das auf alle Fälle, da alle meine anderen Server NGINX benutzen.

  • @hase567 Ok, hast mich überredet 🙂 Kurzer Test.

    service apache2 stop
    

    Danach NGINX installiert

    apt install nginx
    

    Konfiguration unter

    /etc/nginx/sites-enabled/default
    

    eingetragen. Folgt noch, muss noch was anpassen.

    service nginx restart
    

    Und, läuft so weit ich das auf die Schnelle sehen kann, wie unter Apache2.

    Ich werde das in der Anleitung s.o. später hinzufügen. Dann können sich Interessierte aussuchen, was sie nutzen möchten.

    Und jetzt habe ich zusätzlich ein + 😊

    26011942-5d37-40fc-ae25-8daa4073f3d3-image.png

  • Hi,
    das ist doch Super. Hatte mich auch gewundert das es doch recht Simpel ist.
    Bei mir läuft es aktuell noch auf einem Testserver, ohne irgendwelche Fehler weder seitens nginx noch von Bitwarden.
    Werde wohl komplett auf ein Livesystem umstellen. 😊

  • @hase567 Darf ich hier eigentlich nicht so schreiben, aber ich teste sehr viel direkt auf meinen Servern. Für Fälle wo es mal richtig schief geht, habe ich bei Hetzner ja noch etliche Backups der letzten paar Tage. Und Datensicherung usw. ist sowieso vorhanden.

    Und mal eben NGINX neben dem Apache2 zu testen ist ja auch nicht wirklich Hexerei. Wobei ich den Apachen wesentlich anstrengender finde. Aber, das könnte eine sehr subjektive Meinung sein. Darum freut es mich, wenn wir oben im Thread beide Varianten drin haben. Ich baue das morgen ein.

  • Hallo,

    ich habe es nun auch geschafft das Repository auf die aktuelle Version von (nun) Vaultwarden zu aktualisieren. Das Paket und die Binary heißen aber noch "bitwarden_rs". Die Transition auf den neuen Namen habe ich (zumindest für dieses Release) verschoben.

    Zusätzlich habe ich die Installationsanleitung von @FrankM im Repository verlinkt. Danke für den schönen Beitrag.
    Ebenfalls Danke für die nginx Snippets. Ich bin ein Apache-Kind, aber werde bei Gelegenheit die ordnungsgemäße Funktion verifizieren und die nginx Konfiguration dann auch ergänzen.

    Beste Grüße
    Nico

  • @nico Danke für die Infos!

    Ich hab mal getestet 🙂

    root@:~# service bitwarden_rs restart
    Warning: The unit file, source configuration file or drop-ins of bitwarden_rs.service changed on disk. Run 'systemctl daemon-reload' to reload units.
    root@:~# systemctl daemon-reload
    root@:~# service bitwarden_rs restart
    

    7bba03e1-ea0a-4ea2-aa98-eaf3d65e835d-grafik.png

    Passt

  • Hi,
    bitte achtet darauf, das die neue .env Datei weitere/neue Zeilen enthält bzgl. der Purge Cronjobs des "Send" Systems. Die Einträge dazu sind auch im Adminbereich einsehbar.

    Andi

  • @hase567 Danke für den Hinweis.

    Da ich gestern vom Nico gefragt wurde, ob die Websockets unter NGINX gehen, habe ich das gestern ausprobiert. Ging nicht. Heute dann mal auf die Suche gegangen und festgestellt, das die in der Konfigurationsdatei nicht aktiv waren.

    Also eingeschaltet und ausprobiert. Einen neuen Eintrag erstellt und geschaut, ob der ohne Neuladen, sofort angezeigt wird. Das passiert bei mir jetzt so.

    Ich hoffe das stimmt jetzt so alles...

    ## Enables websocket notifications
    WEBSOCKET_ENABLED=true
    
    ## Controls the WebSocket server address and port
    WEBSOCKET_ADDRESS=0.0.0.0
    WEBSOCKET_PORT=3012
    
  • @frankm Setz die "WEBSOCKET_ADDRESS" auf 127.0.0.1. Der Port muss/sollte nicht ohne Reverse Proxy erreichbar sein.

  • @nico Done.

    Ging erst nicht, was man so alles vergisst, der Port muss ja auch mal zugänglich sein. 🤓

    Also, das was ich heute dann noch optimiert habe. Für Websocket die Config entsprechend anpassen. Den Port in der Firewall freigeben.

    Das Logging wollte ich noch umbiegen, es hat lange gedauert, bis ich den Grund gefunden hatte warum es nicht geht.

    /lib/systemd/system/bitwarden_rs.service
    

    Der Dienst muss leicht angepasst werden

    ReadWriteDirectories=/var/lib/bitwarden_rs /var/log/bitwarden
    

    Dann geht es auch mit dem Logging in diese Datei.

  • @FrankM, @Nico
    Toller Service hier von euch bzgl. Bitwarden_rs! Läuft jetzt bei mir auch alles so wie es sein soll!

    Happy Weekend
    Andy

  • @hase567 Ich habe zu danken. Durch deinen sehr nützlichen Link

    konnte ich jetzt die Fail2Ban Erkennung noch mit einbauen, das Logging läuft jetzt auch separat. Tolle Seite vom Pieter. Hab mich da mal bedankt.

  • FrankMF FrankM hat dieses Thema am angepinnt
  • Hi zusammen,
    ich wollte nun mal auf einen Debian Server die Installation auf einem Apache durchführen.
    Bei der Einrichtung mit:
    apt-key adv --keyserver keys.gnupg.net --recv-keys 24BFF712
    erscheint folgende Fehlermeldung:
    Executing: /tmp/apt-key-gpghome.adhmhBrwoR/gpg.1.sh --keyserver keys.gnupg.net --recv-keys 24BFF712
    gpg: Empfangen vom Schlüsselserver fehlgeschlagen: Kein Name

    Habt Ihr eine Idee?

  • @hase567 Da ich ja gerade einige Server von Debian Buster nach Debian Bullseye migriere, ist mir das auch schon aufgefallen 😉
    @Nico ist über das Problem informiert und arbeitet an einer Lösung.

  • @frankm sagte in Bitwarden_RS auf einem Debian Buster 10 Server installieren!:

    @Nico ist über das Problem informiert und arbeitet an einer Lösung.

    Das hört sich gut an 👍 🤓

  • @hase567 Ich habe die Anleitung auf https://bitwarden-deb.tech-network.de/ überarbeitet.
    Jetzt funktioniert es auch mit Debian 11 und neueren Ubuntu Versionen.

    Konkret hat sich Schritt 1 geändert. Das Hinzufügen des Keys erfolgt jetzt über:

    wget -O /etc/apt/trusted.gpg.d/bananian-keyring.gpg https://bitwarden-deb.tech-network.de/bananian-keyring.gpg
    

  • Update 1.32.3 released

    Vaultwarden
    1
    0 Stimmen
    1 Beiträge
    65 Aufrufe
    Niemand hat geantwortet
  • MongoDB - Erste Erfahrungen

    Linux
    2
    0 Stimmen
    2 Beiträge
    141 Aufrufe
    FrankMF

    So frisch von der MongoDB Front und wieder viel gelernt, weil beim Üben macht man Fehler 🙂

    Oben war ja mongodump & mongorestore von der KI empfohlen. Hier das wie ich es gemacht habe.

    mongodump frank@redis-stack:~$ mongodump -u frank -p '<password>' --host 192.168.3.9 --authenticationDatabase admin -d portfolio -o mongodump/ 2024-04-06T09:29:25.174+0200 writing portfolio.stockList to mongodump/portfolio/stockList.bson 2024-04-06T09:29:25.175+0200 writing portfolio.users to mongodump/portfolio/users.bson 2024-04-06T09:29:25.175+0200 done dumping portfolio.stockList (8 documents) 2024-04-06T09:29:25.176+0200 writing portfolio.total_sum to mongodump/portfolio/total_sum.bson 2024-04-06T09:29:25.177+0200 done dumping portfolio.total_sum (1 document) 2024-04-06T09:29:25.177+0200 writing portfolio.old_total_sum to mongodump/portfolio/old_total_sum.bson 2024-04-06T09:29:25.177+0200 writing portfolio.stocks to mongodump/portfolio/stocks.bson 2024-04-06T09:29:25.177+0200 done dumping portfolio.users (4 documents) 2024-04-06T09:29:25.178+0200 writing portfolio.settings to mongodump/portfolio/settings.bson 2024-04-06T09:29:25.178+0200 done dumping portfolio.settings (1 document) 2024-04-06T09:29:25.179+0200 done dumping portfolio.old_total_sum (1 document) 2024-04-06T09:29:25.179+0200 done dumping portfolio.stocks (34 documents) mongorestore mongorestore -u frank -p '<password>' --host 192.168.3.9 --authenticationDatabase admin -d portfolio mongodump/meineDatenbank/

    Hier wird die Datensicherung mongodump/meineDatenbank/ in die neue Datenbank portfolio transferiert.

    Grund für das Ganze? Mich hatte der Datenbank Name meineDatenbank gestört.

    Benutzerrechte

    Jetzt der Teil wo man schnell was falsch machen kann 🙂 Ich hatte also die neue Datenbank, konnte sie aber nicht lesen. Fehlten halt die Rechte. Ich hatte dann so was hier gemacht.

    db.updateUser("frank", { roles: [ { role: "readWrite", db: "meineDatenbank" }, { role: "readWrite", db: "portfolio" }]})

    Ging auch prima, kam ein ok zurück. Nun das Problem, ich hatte beim Einrichten, den User frank als admin benutzt. Durch den oben abgesetzten Befehl (frank ist ja admin), wurden die neuen Rechte gesetzt und die Rechte als Admin entzogen!! Das war jetzt nicht wirklich das was ich gebrauchen konnte. LOL

    Ich hatte jetzt keine Kontrolle mehr über die DB. Das war aber nicht so wirklich kompliziert, das wieder zu ändern. Die Authentication temporär abstellen. Also /etc/mongod.conf editieren und

    #security: security.authorization: enabled

    eben mal auskommentieren. Den Daemon neustarten und anmelden an der DB.

    mongosh --host 192.168.3.9

    Danach neuen User anlegen

    db.createUser({ user: "<name>", pwd: "<password>", roles: [ { role: "userAdminAnyDatabase", db: "admin" } ] })

    mongod.conf wieder ändern und neustarten. Danach hat man wieder eine DB mit Authentifizierung und einen neuen Admin. Ich bin diesmal, man lernt ja, anders vorgegangen. Es gibt nun einen Admin für die DB und einen User zum Benutzen der Datenbanken! So wie man es auch auf einem produktiven System auch machen würde. Wenn ich jetzt mal was an den Benutzerrechten des Users ändere, kann mir das mit dem Admin nicht mehr passieren. Hoffe ich 🙂

  • Nextcloud - extrem lange Ladezeiten

    Nextcloud
    1
    0 Stimmen
    1 Beiträge
    133 Aufrufe
    Niemand hat geantwortet
  • Happy Birthday Debian

    Allgemeine Diskussionen
    1
    0 Stimmen
    1 Beiträge
    77 Aufrufe
    Niemand hat geantwortet
  • Debian 13 - Trixie

    Linux
    1
    0 Stimmen
    1 Beiträge
    133 Aufrufe
    Niemand hat geantwortet
  • Kopia - HTTP/S Server aufsetzen

    Angeheftet Kopia
    1
    0 Stimmen
    1 Beiträge
    401 Aufrufe
    Niemand hat geantwortet
  • Linux Befehle - ls & tail

    Linux
    1
    0 Stimmen
    1 Beiträge
    379 Aufrufe
    Niemand hat geantwortet
  • Let's Encrypt installieren

    Verschoben Let's Encrypt
    3
    0 Stimmen
    3 Beiträge
    1k Aufrufe
    FrankMF

    Wenn ihr alles richtig gemacht habt, dann könnt ihr Euer Zertifikat überprüfen lassen. Sollte dann so aussehen.

    0_1538314120455_index.jpeg