Skip to content

Bitwarden_RS auf einem Debian Buster 10 Server installieren!

Angeheftet Linux
  • @hase567 Ich glaube Du verwechselst da was. Die Bitwarden_RS (vaultwarden) Version 1.24.0 ist aktuell und dani-garcia hat noch keine neue Version veröffentlicht. https://github.com/dani-garcia/vaultwarden/releases

    Du meinst mit Version 2.28.0 das Original. Das wird dann vermutlich die Vorlage für das nächste Release vom dani-garcia.

    Ich denke, da müssen wir uns noch etwas in Geduld üben.

  • @FrankM
    ich meinte "Update web vault to 2.28.0"
    Habe mich falsch ausgedrückt 🙄

  • Es gibt mal wieder ein Update - aber keine neue Version!
    Was hat es damit auf sich?

    Das Paket "bitwarden-rs" ist jetzt nur noch ein Metapaket mit einer Abhängigkeit auf das neue Paket "vaultwarden". Beim nächsten Update ("apt update && apt upgrade") wird also Bitwarden_rs durch Vaultwarden ersetzt.

    Die Konfiguration und das Datenverzeichnis werden dabei vollständig migriert.
    Übrig bleiben lediglich die Verzeichnisse /etc/bitwarden_rs und /var/lib/bitwarden_rs, die nach erfolgreichem Test manuell gelöscht werden können.

    Neue Installationen (auch über das Paket "bitwarden-rs") installieren ab sofort immer Vaultwarden.

    Die Ubuntu 22.04 Kompatibilität ist nicht gelöst und damit meine nächste Baustelle...

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

    Es gibt mal wieder ein Update - aber keine neue Version!
    Was hat es damit auf sich?

    Das Paket "bitwarden-rs" ist jetzt nur noch ein Metapaket mit einer Abhängigkeit auf das neue Paket "vaultwarden". Beim nächsten Update ("apt update && apt upgrade") wird also Bitwarden_rs durch Vaultwarden ersetzt.

    Die Konfiguration und das Datenverzeichnis werden dabei vollständig migriert.
    Übrig bleiben lediglich die Verzeichnisse /etc/bitwarden_rs und /var/lib/bitwarden_rs, die nach erfolgreichem Test manuell gelöscht werden können.

    Neue Installationen (auch über das Paket "bitwarden-rs") installieren ab sofort immer Vaultwarden.

    Die Ubuntu 22.04 Kompatibilität ist nicht gelöst und damit meine nächste Baustelle...

    Ich habe es dann eben mal ausprobiert und es lief einwandfrei. Danke dafür. Außerdem habe ich den Eingangsthread an Vaultwarden angepasst. Den Titel lass ich mal so, evt. bau ich da am WE was zu.

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

  • PyWebIO vs. Flask

    Python3
    2
    0 Stimmen
    2 Beiträge
    118 Aufrufe
    FrankMF

    Mist, jetzt habe ich auch noch Streamlit gefunden. Jetzt geht mir langsam die Zeit aus...

  • 0 Stimmen
    25 Beiträge
    3k Aufrufe
    FrankMF

    Hallo @wooshell , erst mal sehr schade das Du so einen Stress mit dem Board hast. Ich habe das jetzt schon Monate laufen, übrigens ohne einen Kühler. Ok, wird ordentlich warm aber ich hasse Lüfter 😉

    Ich kann leider nicht so richtig erkennen, wo dein Problem liegt. Wie groß ist dein Speicher? Ist der in der Liste der unterstützen RAM Riegel?

    Das habe ich verbaut.

    RAM: Corsair Vengeance SODIMM 32GB (2x16GB) DDR4 2400MHz CL16 https://www.corsair.com/de/de/Kategorien/Produkte/Arbeitsspeicher/VENGEANCE-DDR4-SODIMM/p/CMSX32GX4M2A2400C16

    Aus dem Bauch heraus, würde ich auf RAM tippen.

  • 0 Stimmen
    3 Beiträge
    1k Aufrufe
    M

    @frankm

    Habe neulich auch einen meiner rockpro64 neu mit Debian 11 installiert, und dabei auch die festplatte (NVMe eigentlich) verschlüsselt.

    War mir erst unsicher das ich dann immer eine serielle Console brauch bei reboot. Man kann aber auch dropbear (SSH server) in die initram integrieren und dann während das booten den Server erreichen und die Passphrase für das Laufwerk eingeben.

    Diese 2 links waren hilfreich.

    https://salsa.debian.org/debian/dropbear/blob/debian/2018.76-5/debian/README.initramfs
    https://unix.stackexchange.com/questions/411945/luks-ssh-unlock-strange-behaviour-invalid-authorized-keys-file

    M

  • Debian 11 Bullseye released!

    Linux
    4
    0 Stimmen
    4 Beiträge
    283 Aufrufe
    FrankMF

    Mein Systemadmin auf der Arbeit meinte heute, angesprochen auf das Problem, läuft der Network-Manager? Ok, gute Frage...... Schauen wir mal.

    Ich bin mir leider nicht 100% sicher, ob er vor meinem Eingreifen lief, ich denke aber schon. Warum ich unsicher bin?

    root@debian:~# systemctl enable systemd-networkd.service Created symlink /etc/systemd/system/dbus-org.freedesktop.network1.service → /lib/systemd/system/systemd-networkd.service. Created symlink /etc/systemd/system/multi-user.target.wants/systemd-networkd.service → /lib/systemd/system/systemd-networkd.service. Created symlink /etc/systemd/system/sockets.target.wants/systemd-networkd.socket → /lib/systemd/system/systemd-networkd.socket. Created symlink /etc/systemd/system/network-online.target.wants/systemd-networkd-wait-online.service → /lib/systemd/system/systemd-networkd-wait-online.service.

    Ok, danach

    root@debian:~# systemctl start systemd-networkd.service root@debian:~# systemctl status systemd-networkd.service ● systemd-networkd.service - Network Service Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; ven> Active: active (running) since Tue 2021-08-17 17:36:38 CEST; 6s ago TriggeredBy: ● systemd-networkd.socket Docs: man:systemd-networkd.service(8) Main PID: 1288 (systemd-network) Status: "Processing requests..." Tasks: 1 (limit: 19087) Memory: 3.9M CPU: 39ms CGroup: /system.slice/systemd-networkd.service └─1288 /lib/systemd/systemd-networkd Aug 17 17:36:38 debian systemd[1]: Starting Network Service... Aug 17 17:36:38 debian systemd-networkd[1288]: enp25s0: Gained IPv6LL Aug 17 17:36:38 debian systemd-networkd[1288]: Enumeration completed Aug 17 17:36:38 debian systemd[1]: Started Network Service.

    Danach ging immer noch nix.

    root@debian:/etc/network# ^C root@debian:/etc/network# nmcli device show GENERAL.DEVICE: wlx7cdd907cbec2 GENERAL.TYPE: wifi GENERAL.HWADDR: BA:59:C0:76:C7:F5 GENERAL.MTU: 1500 GENERAL.STATE: 20 (nicht verfügbar) GENERAL.CONNECTION: -- GENERAL.CON-PATH: -- GENERAL.DEVICE: enp25s0 GENERAL.TYPE: ethernet GENERAL.HWADDR: 30:9C:23:60:C6:8E GENERAL.MTU: 1500 GENERAL.STATE: 10 (nicht verwaltet) GENERAL.CONNECTION: -- GENERAL.CON-PATH: -- WIRED-PROPERTIES.CARRIER: an IP4.ADDRESS[1]: 192.168.3.169/24 IP4.GATEWAY: 192.168.3.1 IP4.ROUTE[1]: dst = 192.168.3.0/24, nh = 0.0.0.0, mt = 0 IP4.ROUTE[2]: dst = 0.0.0.0/0, nh = 192.168.3.1, mt = 0 IP6.ADDRESS[1]: 2a02:908:1260:13bc:329c:23ff:xxxx:xxxx/64 IP6.ADDRESS[2]: fd8a:6ff:2880:0:329c:23ff:fe60:c68e/64 IP6.ADDRESS[3]: fe80::329c:23ff:fe60:c68e/64 IP6.GATEWAY: fe80::e4d3:f0ff:fe8f:2354 IP6.ROUTE[1]: dst = fe80::/64, nh = ::, mt = 256 IP6.ROUTE[2]: dst = ::/0, nh = fe80::e4d3:f0ff:fe8f:2354, mt = 1024 IP6.ROUTE[3]: dst = 2a02:908:xxxx:xxxx::/64, nh = ::, mt = 256 IP6.ROUTE[4]: dst = fd8a:6ff:2880::/64, nh = ::, mt = 256

    Jetzt hatte ich das erste Mal einen Ansatz, wonach ich suchen musste.

    GENERAL.STATE: 10 (nicht verwaltet)

    Etwas Suche im Netz und dann das

    nano /etc/NetworkManager/NetworkManager.conf

    Inhalt der Datei

    [main] plugins=ifupdown,keyfile [ifupdown] managed=false

    Das false in true geändert. Danach ein

    systemctl restart NetworkManager

    und ich konnte den Network-Manager auf dem Desktop benutzen!?!?!?

    Bildschirmfoto vom 2021-08-17 18-07-25.png

    Irgendwas ist da durcheinander im Bullseye 😳

  • ClusterSSH

    Angeheftet Linux
    4
    0 Stimmen
    4 Beiträge
    728 Aufrufe
    FrankMF

    Mal wieder lange dran rumgefummelt, bis es passte.

    I have figured out how to use any font in xterm. So for the case of the mentioned Inconsolata font size 14, the following works:

    Add these 2 lines into ~/.Xresources (create it if it does not exist)

    XTermfaceName: Inconsolata
    XTermfaceSize: 14

    Then, tell xterm to use this file:

    export XENVIRONMENT="${HOME}/.Xresources"

    Preferably add this export into .bashrc, so that it is persistent.

    comment out the font settings in ~/.clusterssh/config, if it exists: # terminal_font=6x13

    Quelle: https://unix.stackexchange.com/questions/230106/cluster-ssh-specify-terminal-font

  • 0 Stimmen
    1 Beiträge
    236 Aufrufe
    Niemand hat geantwortet
  • Wenn dir der Redis-Server flöten geht....

    Verschoben Redis
    3
    0 Stimmen
    3 Beiträge
    523 Aufrufe
    FrankMF

    So, nach einer kleinen Pause und ein wenig nachdenken ist mir doch noch was eingefallen 😉

    Backports! Man so einfach!

    nano /etc/apt/sources.list

    Das folgende eintragen.

    # backports deb http://deb.debian.org/debian stretch-backports main

    Danach ein

    apt update

    Und dann schauen wir uns mal die Version an....

    apt -t stretch-backports search redis-server Sorting... Done Full Text Search... Done golang-github-stvp-tempredis-dev/stretch-backports 0.0~git20160122.0.83f7aae-1~bpo9+1 all Go package to start and stop temporary redis-server processes libtest-redisserver-perl/oldstable,oldstable 0.20-1 all redis-server runner for tests python-hiredis/oldstable,oldstable 0.2.0-1+b2 amd64 redis protocol reader for Python 2.X using hiredis python3-hiredis/oldstable,oldstable 0.2.0-1+b2 amd64 redis protocol reader for Python using hiredis redis/stretch-backports 5:5.0.3-3~bpo9+2 all Persistent key-value database with network interface (metapackage) redis-server/stretch-backports 5:5.0.3-3~bpo9+2 amd64 [residual-config] Persistent key-value database with network interface

    Und die habe ich gestern Abend gebaut.

    127.0.0.1:6379> INFO # Server redis_version:5.0.5

    Ok, das schmerzt jetzt 😛

  • MariaDB installieren

    Verschoben MariaDB
    1
    0 Stimmen
    1 Beiträge
    599 Aufrufe
    Niemand hat geantwortet