Skip to content

Bitwarden_RS auf einem Debian Buster 10 Server installieren!

Angeheftet Linux
85 5 7.4k 2
  • Hallo,

    ich hatte eben einmal auf die neueste Version geupdatet und erhalte von meinem Reverseproxy den Fehler 500 und vom Vaultwarden Debian Server einen Server ist nicht erreichbar zurück.

    Mein derzeitiges System ist ein Debian 11.3 mit Vaultwarden 1.24.0.

    Wie gesagt nach dem Update bekomme ich keinen Seitenaufbau hin. Hat sich irgendetwas hinsichtlich des Webservers geändert? Ich habe auf dem Vaultwardenserver kein Nginx oder Apache laufen. Bisher hatte dies auch gut funktioniert.

    Weiß langsam nicht mehr wo ich suchen soll. Vielleicht kann mir ja jemand helfen...

    Grüße
    jascha

  • Hallo,

    ich hatte eben einmal auf die neueste Version geupdatet und erhalte von meinem Reverseproxy den Fehler 500 und vom Vaultwarden Debian Server einen Server ist nicht erreichbar zurück.

    Mein derzeitiges System ist ein Debian 11.3 mit Vaultwarden 1.24.0.

    Wie gesagt nach dem Update bekomme ich keinen Seitenaufbau hin. Hat sich irgendetwas hinsichtlich des Webservers geändert? Ich habe auf dem Vaultwardenserver kein Nginx oder Apache laufen. Bisher hatte dies auch gut funktioniert.

    Weiß langsam nicht mehr wo ich suchen soll. Vielleicht kann mir ja jemand helfen...

    Grüße
    jascha

    @skyacer Moin Jascha,
    sorry für die späte Rückmeldung. Existiert das Problem noch?

    Wenn ja, poste doch bitte einmal den Output der folgenden Befehle:

    ls -lha /etc/vaultwarden
    ps aux | grep warden
    netstat -tulpen | grep warden
    systemctl status vaultwarden.service
    
    

    Danke und beste Grüße!

  • Vaultwarden ist auf Version 1.25.2 aktualisiert. Danke @Nico

    vaultwarden -v
    vaultwarden 1.25.2
    

  • Moin,
    seit dem letzten Update hatte ich enorm viele Fehlermeldungen in den Logs. Nach etwas Recherche habe einen Hinweis gefunden.

    In der Nginx Vhost habe ich einen Eintrag hinzugefügt und somit waren die Fehlermeldungen verschwunden.

    proxy_http_version 1.1;

    Leider bin ich nicht der große Profi, vielleicht kann Nico oder jemand anderes das ganze mal anpassen!?

  • Moin,
    seit dem letzten Update hatte ich enorm viele Fehlermeldungen in den Logs. Nach etwas Recherche habe einen Hinweis gefunden.

    In der Nginx Vhost habe ich einen Eintrag hinzugefügt und somit waren die Fehlermeldungen verschwunden.

    proxy_http_version 1.1;

    Leider bin ich nicht der große Profi, vielleicht kann Nico oder jemand anderes das ganze mal anpassen!?

    @hase567 Moin,

    wie lautete denn die Fehlermeldung? Kannst du die bitte mal posten?

    Gab es dadurch auch funktionelle Einschränkungen oder bist du lediglich über das Log darauf gestoßen?

    Beste Grüße und ein schönes Wochenende!
    Nico

  • @hase567 Moin,

    wie lautete denn die Fehlermeldung? Kannst du die bitte mal posten?

    Gab es dadurch auch funktionelle Einschränkungen oder bist du lediglich über das Log darauf gestoßen?

    Beste Grüße und ein schönes Wochenende!
    Nico

    @Nico
    es gab keine funktionellen Einschränkungen, bin nur über die Logfiles drauf gestoßen.
    Leider ist das Logfile nicht mehr vorhanden 😞
    Kann mich nur dran erinnern, das fast bei jedem Zugriff der Fehler aufgeführt wurde...

  • @Nico
    es gab keine funktionellen Einschränkungen, bin nur über die Logfiles drauf gestoßen.
    Leider ist das Logfile nicht mehr vorhanden 😞
    Kann mich nur dran erinnern, das fast bei jedem Zugriff der Fehler aufgeführt wurde...

    @hase567 Moin,

    ich verwende "leider" Apache und kann den Fehler daher nach reproduzieren. Vielleicht kannst du die genannte Option einmal auskommentieren, den Fehler reproduzieren und hier posten? Dann schaue ich mir das gerne mal an.

    Beste Grüße!

  • Die letzten Wochen etwas viel mit Python & PyWebIO beschäftigt, fast vergessen das hier zu erwähnen.

    Vaultwarden ist auf Version 1.26.0 aktualisiert. Danke @Nico

    :~# vaultwarden -v
    vaultwarden 1.26.0
    
  • Moin,
    danke fürs Update, werde es morgen einmal Updaten!

  • @Nico fleißig 😊 👍

    root@:~# vaultwarden -v
    vaultwarden 1.27.0
    
  • Moin!
    Update verlief ohne Probleme... Danke!

  • Danke @Nico

    root :~# vaultwarden -v
    vaultwarden 1.28.0
    
  • Ich hatte heute im Admininterface mal reingeschaut. Da stand die Version noch auf 1.27 und nicht auf 1.28. Ok, kein Problem, einmal neustarten und gut.

    systemctl restart vaultwarden
    

    Ok, danach startete er nicht mehr! Gar nicht! 🤔

    Der Fehler

    Mar 31 22:31:35 bitwarden vaultwarden[1614]: Error loading config:
    Mar 31 22:31:35 bitwarden vaultwarden[1614]: Unable to write to log file. /var/log/vaultwarden/vaultwarden.log
    

    Es hat erst etwas gedauert, bis mich @Nico auf die Idee brachte das Logging, welches ich umgebogen hatte, wieder auf syslog zu stellen.

    Ich nutze normalerweise folgendes

    LOG_FILE=/var/log/vaultwarden/vaultwarden.log
    USE_SYSLOG=false
    

    Ok, dann mal geändert. Danach startete Vaultwarden wieder. Das sieht nach einem Bug aus, weil egal was man an Benutzerrechten einstellt er schreibt nicht in das Logfile. Aktuell denke ich, es ist ein 🐛

    Update: Lösung -> https://linux-nerds.org/topic/1373/vaultwarden-systemd

  • Es haben sich ein paar Dinge geändert.

    Admin Login

    Das steht normalerweise in der config.env und aktiviert den Admin-Zugang.

    ADMIN_TOKEN=PASSWORD
    

    Er meckert jetzt, das PW wäre als Plaintext gespeichert. Das kann man ändern . Dazu in der Konsole folgendes eingeben

    vaultwarden hash
    

    Ausgabe

    root@:~# vaultwarden hash
    Generate an Argon2id PHC string using the 'bitwarden' preset:
    
    Password: 
    Confirm Password: 
    
    ADMIN_TOKEN='$argon2id$v....................................'
    

    Die Zeile mit ADMIN_TOKEN kopieren und in die config.env einfügen. Danach meckerte er immer noch.

    In der config.json muss der Admin Token entfernt werden! Danach funktionierte es, wie erwartet.

  • Unter Account Settings / Security / Keys findet man folgendes.

    adea18a8-9f88-49c4-b1cf-fcfca89d0c94-grafik.png

    Setzt mal bitte den PW Hash von PBKDF2 auf Argon2id um. Das soll den Brute Force des Passwortes extrem erschweren.

    Links zum Thema

    Danke @Nico für die Tipps.

  • @Nico war schnell heute 😊

  • Vielen Dank für das Update!!

  • Hi,
    ich wollte auf einem neuen Server Vaultwarden installieren, leider erhalte ich folgende Fehlermeldung:
    Das Laden der konfigurierten Datei »main/binary-arm64/Packages« wird übersprungen, da das Depot »http://bitwarden-deb.tech-network.de buster InRelease« die Architektur »arm64« nicht unterstützt.

    Gibt es dafür eine Lösung?

  • Hallo @hase567

    du hast einen Server auf ARM Basis (eine der neuen Hetzner Ampere Altra Instanzen?) und das Paket ist aktuell ausschließlich für x86/amd64 gebaut.
    Aktuell gibt es dafür keine Lösung. Ich kann mir bei Gelegenheit gerne mal anschauen, was es an Aufwand bedeutet, ein arm64 Paket zu bauen. Ich bitte dafür allerdings noch um etwas Geduld.

  • Hallo @hase567

    du hast einen Server auf ARM Basis (eine der neuen Hetzner Ampere Altra Instanzen?) und das Paket ist aktuell ausschließlich für x86/amd64 gebaut.
    Aktuell gibt es dafür keine Lösung. Ich kann mir bei Gelegenheit gerne mal anschauen, was es an Aufwand bedeutet, ein arm64 Paket zu bauen. Ich bitte dafür allerdings noch um etwas Geduld.

    @Nico
    ja genau so ist es. Es ist der neue Hetzner Ampere Server.

    Dachte mir schon das es daran liegt 🙄
    So ein mist...

  • OpenCloud - Docker Compose local

    Verschoben OpenCloud opencloud linux
    3
    1
    0 Stimmen
    3 Beiträge
    484 Aufrufe
    FrankMF
    Noch was Wichtiges. Die Docker Installation nutzt folgende config. In meinem Beispiel findet man sie unter /home/frank/opencloud/deployments/examples/opencloud_full Darin liegt ein .env ## Basic Settings ## # Define the docker compose log driver used. # Defaults to local LOG_DRIVER= # If you're on an internet facing server, comment out following line. # It skips certificate validation for various parts of OpenCloud and is # needed when self signed certificates are used. INSECURE=true ## Traefik Settings ## # Note: Traefik is always enabled and can't be disabled. # Serve Traefik dashboard. # Defaults to "false". TRAEFIK_DASHBOARD= # Domain of Traefik, where you can find the dashboard. # Defaults to "traefik.opencloud.test" TRAEFIK_DOMAIN= # Basic authentication for the traefik dashboard. # Defaults to user "admin" and password "admin" (written as: "admin:$2y$05$KDHu3xq92SPaO3G8Ybkc7edd51pPLJcG1nWk3lmlrIdANQ/B6r5pq"). # To create user:password pair, it's possible to use this command: # echo $(htpasswd -nB user) | sed -e s/\\$/\\$\\$/g TRAEFIK_BASIC_AUTH_USERS= # Email address for obtaining LetsEncrypt certificates. # Needs only be changed if this is a public facing server. TRAEFIK_ACME_MAIL= # Set to the following for testing to check the certificate process: # "https://acme-staging-v02.api.letsencrypt.org/directory" # With staging configured, there will be an SSL error in the browser. # When certificates are displayed and are emitted by # "Fake LE Intermediate X1", # the process went well and the envvar can be reset to empty to get valid certificates. TRAEFIK_ACME_CASERVER= [....gekürzt....] Man kann dort etwas ändern und mittels docker compose up -d alles aktualisieren. Radicale OpenCloud nutzt im Moment folgendes https://radicale.org/v3.html als Backend Server für Kalender & Kontakte. Jemand hat mir dann erklärt, wie das so funktioniert. Danach hatte es dann klick gemacht. https://fosstodon.org/@h4kamp/114562514701351170 In der config findet man zum Beispiel die Konfiguration für radicale (Kalender- und Kontakte-App) Das ist nur eine rudimentäre Ablage, wird gesteuert über Clienten, z.B. die Thunderbird Kalender Funktion. ### Radicale Setting ### # Radicale is a small open-source CalDAV (calendars, to-do lists) and CardDAV (contacts) server. # When enabled OpenCloud is configured as a reverse proxy for Radicale, providing all authenticated # OpenCloud users access to a Personal Calendar and Addressbook RADICALE=:radicale.yml # Docker image to use for the Radicale Container #RADICALE_DOCKER_IMAGE=opencloudeu/radicale # Docker tag to pull for the Radicale Container #RADICALE_DOCKER_TAG=latest # Define the storage location for the Radicale data. Set the path to a local path. # Ensure that the configuration and data directories are owned by the user and group with ID 1000:1000. # This matches the default user inside the container and avoids permission issues when accessing files. # Leaving it default stores data in docker internal volumes. #RADICALE_DATA_DIR=/your/local/radicale/data In einer Standard Installation ist das auskommentiert. RADICALE=:radicale.yml Danach ein docker compose up -d und Eure Kalendereinträge (extern auf einem Clienten verwaltet) werden in der OpenCloud gesichert.
  • Debian Bookworm 12.10 released

    Linux debian linux bookworm
    3
    0 Stimmen
    3 Beiträge
    356 Aufrufe
    FrankMF
    @MikDD Ich kann das Verhalten von Die bei mir nicht erkennen. Habe ein NAS, welches ich mit einem SystemD Dienst einfach einbinde. [Unit] Description=Mount NFS Share from 192.168.3.19:/NAS After=network-online.target Wants=network-online.target [Mount] What=192.168.3.19:/NAS Where=/mnt/NAS Type=nfs Options=defaults,timeo=900 [Install] WantedBy=multi-user.target Dann habe ich das in meinem Dateibrowser drin, suche meinen Videoordner und starte das Video. Einen kleinen Moment später startet das Video. Die Verzögerung wird die Zeitspanne sein, die benötigt wird einen Cache zu füllen. Wäre ja auch blöd, wenn man erst den ganzen Film runter laden muss. Hier, in meinem Forum, sollte man genug Informationen dazu finden. Wenn es irgendwo hakt oder klappt, stelle bitte eine Frage. Achso, Willkommen im Forum
  • 0 Stimmen
    1 Beiträge
    3k Aufrufe
    Niemand hat geantwortet
  • Nextcloud 23.0.3

    Nextcloud nextcloud linux
    1
    0 Stimmen
    1 Beiträge
    177 Aufrufe
    Niemand hat geantwortet
  • Ubiquiti ER-X - DMZ

    Verschoben OpenWRT & Ubiquiti ER-X openwrt linux er-x
    1
    2
    0 Stimmen
    1 Beiträge
    301 Aufrufe
    Niemand hat geantwortet
  • Cockpit

    Linux linux
    1
    1
    0 Stimmen
    1 Beiträge
    268 Aufrufe
    Niemand hat geantwortet
  • Redis installieren

    Angeheftet Verschoben Redis linux redis
    1
    0 Stimmen
    1 Beiträge
    424 Aufrufe
    Niemand hat geantwortet
  • Installation von Grav & NGinx & PHP7.2

    Angeheftet Verschoben Grav grav linux
    2
    1
    0 Stimmen
    2 Beiträge
    1k Aufrufe
    FrankMF
    Nachdem ich den ROCKPro64 jetzt auf den Mainline umgestellt habe, lief meine Testinstallation von Grav nicht mehr. Hilfreiche Sache um das Problem zu lösen -> https://gist.github.com/GhazanfarMir/03bd1f1f770a3834d47274586d46ea62 Ich bekam immer 502 Bad Gateway, Grund war ein nicht korrekt gestarteter php-pfm Service. rock64@rockpro64v2_0:/usr/local/bin$ sudo service php7.2-fpm start rock64@rockpro64v2_0:/usr/local/bin$ sudo service php7.2-fpm status ● php7.2-fpm.service - The PHP 7.2 FastCGI Process Manager Loaded: loaded (/lib/systemd/system/php7.2-fpm.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2018-08-16 20:15:20 CEST; 21s ago Docs: man:php-fpm7.2(8) Main PID: 3206 (php-fpm7.2) Status: "Processes active: 0, idle: 2, Requests: 3, slow: 0, Traffic: 0.2req/sec" Tasks: 3 (limit: 4622) CGroup: /system.slice/php7.2-fpm.service ├─3206 php-fpm: master process (/etc/php/7.2/fpm/php-fpm.conf) ├─3207 php-fpm: pool www └─3208 php-fpm: pool www Aug 16 20:15:19 rockpro64v2_0 systemd[1]: Starting The PHP 7.2 FastCGI Process Manager... Aug 16 20:15:20 rockpro64v2_0 systemd[1]: Started The PHP 7.2 FastCGI Process Manager.