Skip to content

Bitwarden_RS auf einem Debian Buster 10 Server installieren!

Pinned Linux
  • Die Version 1.25.0 ist ab sofort im Repository verfügbar!

    Wurde die Migration von Bitwarden_rs zu Vaultwarden noch nicht mit Version 1.24 durchgeführt, kann es passieren, dass Vaultwarden 1.25 nicht startet.
    Dieser Fehler kann durch Löschen der Datei "/etc/vaultwarden/Rocket.toml" behoben werden:

    rm /etc/vaultwarden/Rocket.toml
    

    Die Rocket.toml wird nicht länger benötigt und kann gefahrlos entfernt werden.

    Schönes Wochenende!

  • @Nico ,
    Update erfolgreich durchgeführt 👍

    Vielen Dank für das Update!
    Andreas

  • 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!?

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

  • @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?

  • 0 Votes
    1 Posts
    33 Views
    No one has replied
  • 0 Votes
    1 Posts
    158 Views
    No one has replied
  • 0 Votes
    3 Posts
    2k Views
    FrankMF

    Das mit den Namen der btrfs Subvolumes ist bekannt bei Timeshift. Im Readme steht dazu folgendes.

    BTRFS volumes

    BTRFS volumes must have an Ubuntu-type layout with @ and @home subvolumes. Other layouts are not supported. Systems having the @ subvolume and having /home on a non-BTRFS partition are also supported.

    Text file busy / btrfs returned an error: 256 / Failed to create snapshot can occur if you have a Linux swapfile mounted within the @ or @home subvolumes which prevents snapshot from succeeding. Relocate the swapfile out of @ or *@home, for example into it's own subvolume like @swap.

  • 0 Votes
    4 Posts
    298 Views
    FrankMF

    Es geht weiter, der erste ☕ und ich bin mit der Lösung nicht so richtig zufrieden, also suchen.

    Als erstes habe ich heute Morgen ein frisches SD-Karten Image mit Docker von FreindlyWrt genommen und auf meinem Test NanoPi R5S installiert. Dort mal die Config angeschaut um zu sehen, ob der Eintrag standardmäßig gesetzt ist. Doch dort taucht dann einmal eine ganz ander Config auf 🙄

    # The following settings require a restart of docker to take full effect, A reload will only have partial or no effect: # bip # blocked_interfaces # extra_iptables_args # device config globals 'globals' # option alt_config_file '/etc/docker/daemon.json' option enable '1' option data_root '/mnt/nvme_part2/docker' option log_level 'warn' option iptables '1' #list hosts 'unix:///var/run/docker.sock' # option bip '172.18.0.1/24' # option fixed_cidr '172.17.0.0/16' # option fixed_cidr_v6 'fc00:1::/80' # option ipv6 '1' # option ip '::ffff:0.0.0.0' # list dns '172.17.0.1' # list registry_mirrors 'https://<my-docker-mirror-host>' list registry_mirrors 'https://hub.docker.com' option remote_endpoint '0' # option bridge 'br-container' # Docker ignores fw3 rules and by default all external source IPs are allowed to connect to the Docker host. # See https://docs.docker.com/network/iptables/ for more details. # firewall config changes are only additive i.e firewall will need to be restarted first to clear old changes, # then docker restarted to load in new changes. config firewall 'firewall' option device 'docker0' list blocked_interfaces 'wan' option extra_iptables_args '--match conntrack ! --ctstate RELATED,ESTABLISHED' # allow outbound connections

    Das interessiert uns jetzt

    list blocked_interfaces 'wan' option extra_iptables_args '--match conntrack ! --ctstate RELATED,ESTABLISHED' # allow outbound connections

    Wenn ich das jetzt alles richtig verstehe, muss WAN geblockt sein, weil sonst der Docker Host offen im Netz steht (Hierbei bin ich mir nicht 100% sicher)
    Die zweite Zeile ist eine iptables Regel, die es den Containern dann ermöglicht das Internet zu erreichen.

    Das habe ich jetzt so eingestellt und getestet.

    root@b9ffae24913a:/# ping 1.1.1.1 PING 1.1.1.1 (1.1.1.1): 56 data bytes 64 bytes from 1.1.1.1: icmp_seq=0 ttl=57 time=17.151 ms 64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=16.553 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=20.630 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=13.948 ms ^C--- 1.1.1.1 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 13.948/17.071/20.630/2.382 ms root@b9ffae24913a:/# ping google.de PING google.de (142.250.185.195): 56 data bytes 64 bytes from 142.250.185.195: icmp_seq=0 ttl=58 time=23.797 ms 64 bytes from 142.250.185.195: icmp_seq=1 ttl=58 time=16.953 ms 64 bytes from 142.250.185.195: icmp_seq=2 ttl=58 time=19.441 ms ^C--- google.de ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 16.953/20.064/23.797/2.829 ms

    Ich hoffe mal das ich diese Thema jetzt zu den Akten legen kann.

    Wenn was falsch ist, bitte hier kommentieren, damit ich das ändern kann.

  • 0 Votes
    1 Posts
    361 Views
    No one has replied
  • Debian 10 Buster 10.5 released

    Linux
    1
    0 Votes
    1 Posts
    196 Views
    No one has replied
  • Kopia - HTTP/S Server

    Moved Kopia
    3
    0 Votes
    3 Posts
    1k Views
    FrankMF

    Ich hatte ein paar Probleme, die ich mir teilweise nicht erklären kann 🤔

    Ich möchte den Kopia Server gerne über systemd steuern.

    SystemD [Unit] Description=Kopia Server After=syslog.target After=network.target [Service] Type=simple User=kopia Group=kopia ExecStart=/usr/bin/kopia server --tls-cert-file /home/kopia-server/fullchain.pem --tls-key-file /home/kopia-server/privkey.pem --htpasswd-file /home/kopia-server/.htpasswd --address <IPv4>:51515 Restart=always RestartSec=5 [Install] WantedBy=multi-user.target

    Danach

    systemctl daemon-reload systemctl start kopia-server

    Mit

    systemctl status kopia-server

    kann man sich den Status anzeigen lassen.

    Client Rechner

    Auf dem Client, der das Backup zum Server schicken soll, machen wir dann folgendes.

    USER@HOSTNAME:~$ kopia repo connect server --url=https://<DOMAIN>:51515 --override-username=USER --override-hostname=HOSTNAME Enter password to open repository: Connected to repository API Server. NOTICE: Kopia will check for updates on GitHub every 7 days, starting 24 hours after first use. To disable this behavior, set environment variable KOPIA_CHECK_FOR_UPDATES=false Alternatively you can remove the file "/home/frank/.config/kopia/repository.config.update-info.json".

    Danach steht die Verbindung und wir können Backups hochschieben.

    kopia snapshot create $HOME

    Damit wird das Homeverzeichnis gesichert. Das initiale Backup, hat 30 Minuten gebraucht.

    created snapshot with root kb9e50ff5xxxxxxxxxx265d40a5d0861 and ID cda5c0ffxxxxxxxxxxxxxxa4cb4a367b in 30m28s

    Ein späteres Backup, sieht so aus.

    USER@HOSTNAME:~$ kopia snapshot create $HOME Snapshotting USER@HOSTNAME:/home/frank ... * 0 hashing, 51 hashed (324.8 MB), 8524 cached (6.6 GB), 0 uploaded (0 B), 0 errors 100.0% Created snapshot with root kc20a4xxxxxxxxxxxx745c6c7b37c and ID d7a96eaxxxxxxxxxxx0961018eacffa in 3m12s

    Nach 3 Minuten durch. Zu diesem Zeitpunkt hat sich aber auch nicht wirklich was geändert!

    Fazit

    Das Tool macht immer noch einen sehr guten Eindruck. Die Geschwindigkeit ist sehr gut. Die Anleitung ist leider unzureichend. Da gibt es so viele Möglichkeiten, da braucht es sehr lange, bis man da mal durchsteigt. Zum Glück, ist das was man normalerweise braucht, recht überschaubar. Bis zum produktiven Einsatz braucht das aber bei mir noch eine Menge mehr Tests.

    Was ich noch testen möchte

    Verzeichnis mounten Backup testweise wieder herstellen (zumindestens teilweise)

    Der Test läuft mit Standard Einstellungen, also z.B. ohne Kompression. Das sollte man dann auch mal testen..

    Bitte achtet auf gleiche Versionen auf dem Clienten, wie auf dem Server. Ich meine da ein paar Probleme festgestellt zu haben...

  • 0 Votes
    3 Posts
    483 Views
    FrankMF

    Ich kann dir nicht ganz folgen. Mein Wireguard Server ist eine VM im Netz. Mein Smartphone baut zu diesem eine Verbindung auf und ich habe mal eben nachgeschaut, was da so geht. Mein Smartphone ist aktuell im meinem WLan angemeldet.

    6e0016dc-7e11-41e1-bba2-e52a3f1348df-image.png

    iperf3 -s -B 10.10.1.1 ----------------------------------------------------------- Server listening on 5201 ----------------------------------------------------------- Accepted connection from 10.10.1.10, port 44246 [ 5] local 10.10.1.1 port 5201 connected to 10.10.1.10 port 44248 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 4.98 MBytes 41.7 Mbits/sec [ 5] 1.00-2.00 sec 5.52 MBytes 46.3 Mbits/sec [ 5] 2.00-3.00 sec 4.80 MBytes 40.3 Mbits/sec [ 5] 3.00-4.00 sec 4.17 MBytes 35.0 Mbits/sec [ 5] 4.00-5.00 sec 5.04 MBytes 42.3 Mbits/sec [ 5] 5.00-6.00 sec 5.43 MBytes 45.6 Mbits/sec [ 5] 6.00-7.00 sec 5.75 MBytes 48.3 Mbits/sec [ 5] 7.00-8.00 sec 5.70 MBytes 47.8 Mbits/sec [ 5] 8.00-9.00 sec 5.73 MBytes 48.1 Mbits/sec [ 5] 9.00-10.00 sec 5.65 MBytes 47.4 Mbits/sec [ 5] 10.00-10.04 sec 206 KBytes 46.5 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.04 sec 53.0 MBytes 44.3 Mbits/sec receiver ----------------------------------------------------------- Server listening on 5201 ----------------------------------------------------------- Accepted connection from 10.10.1.10, port 44250 [ 5] local 10.10.1.1 port 5201 connected to 10.10.1.10 port 44252 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 4.80 MBytes 40.2 Mbits/sec 0 253 KBytes [ 5] 1.00-2.00 sec 14.7 MBytes 123 Mbits/sec 181 379 KBytes [ 5] 2.00-3.00 sec 9.68 MBytes 81.2 Mbits/sec 58 294 KBytes [ 5] 3.00-4.00 sec 8.88 MBytes 74.5 Mbits/sec 1 227 KBytes [ 5] 4.00-5.00 sec 7.76 MBytes 65.1 Mbits/sec 0 245 KBytes [ 5] 5.00-6.00 sec 8.88 MBytes 74.5 Mbits/sec 0 266 KBytes [ 5] 6.00-7.00 sec 9.81 MBytes 82.3 Mbits/sec 0 289 KBytes [ 5] 7.00-8.00 sec 7.82 MBytes 65.6 Mbits/sec 35 235 KBytes [ 5] 8.00-9.00 sec 5.59 MBytes 46.9 Mbits/sec 4 186 KBytes [ 5] 9.00-10.00 sec 6.64 MBytes 55.7 Mbits/sec 0 207 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.04 sec 84.6 MBytes 70.6 Mbits/sec 279 sender ----------------------------------------------------------- Server listening on 5201 ----------------------------------------------------------- ^Ciperf3: interrupt - the server has terminated

    Im zweiten Teil ist der Wireguard Server der Sender.

    Bis jetzt hatte ich eigentlich nie Probleme, auch nicht unterwegs. Aber, ich gehe davon aus, das ich dich nicht 100% verstanden habe 😉