Synology [Tuto] Installer Vaultwarden avec une sauvegarde automatique de la base de données

Statut
N'est pas ouverte pour d'autres réponses.

MilesTEG

Administreur
Membre du personnel
6 Septembre 2020
3 019
735
213
( > TUTO mis à jour - v4.4 < )
  • 3.1 : ajout d'une capture d'écran de la configuration du reverse-proxy de DSM + ajout d'une mention concernant ce qui est à remplacer dans le docker-compose.yml
  • 4.0 : changement d'image pour le backup, donc le docker-compose est modifié.`
  • 4.1 : actualisation de certaines captures d'écrans
  • 4.2 : correction de quelques coquilles, et mise à jour de la ligne de commande de création des dossiers en ligne de commande.
  • 4.3 : Ajout d'un avertissement + explications pour la variable SIGNUPS_ALLOWED=false dans mon tuto
  • 4.4 : Ajout d'un script pour DSM 7
  • 4.5 : Ajout d'une partie sur le hash argon2 du token d'admin

Bonjour à toutes et à tous,



Sommaire :
0. Fichiers joints
1. Note à lire
1.1- Mise à jour v3.0 (changement de nom de l'image)
1.2- Mise à jour v4.4 (DSM7)
1.3- Mise à jour v4.5 (hash argon2)( > Mise à jour v4.5 < )

2. Préambule & Prérequis
3- Mise en place et création des conteneurs ( > Mise à jour v4.0 < )

3.1- Petites explications sur ce qui suivra
3.2- Création du docker-compose.yml ( > Mise à jour v4.5 < )

3.3- Configuration de rclone pour le backup ( > Mise à jour v4.0 < )
3.4- Création des dossiers et du réseau
3.5- Création de s conteneurs (2 méthodes)
4- 1er lancement et sécurisation 2FA
5- Ajout d'un script pour les notifications Websocket ( > Ajout v3.0 < )

5.1- Explications : Pourquoi ? Comment ? ( > Ajout v3.0 < )
5.2- Comment lancer le script ? ( > Ajout v3.0 < )
5.3- Enfin le script lui même ! ( > Mise à jour v4.4 < )
...



0. Fichiers joints


1. Note à lire :
1.1- Mise à jour v3.0 (changement de nom de l'image)

L'auteur de Bitwarden_RS, dani-garcia, a renommé son image en Vaultwarden.
1f4e2.png
Note: This project was known as Bitwarden_RS and has been renamed to separate itself from the official Bitwarden server in the hopes of avoiding confusion and trademark/branding issues. Please see #1642 for more explanation.
Je viens de mettre à jour l'intégralité du tuto pour que tout soit cohérent avec ce nouveau nom. Les noms des dossiers, fichier log, nom du conteneur, du réseau etc, sont donc renommé pour tenir compte du nouveau nom.
Pour ceux qui veulent aller vite :
  1. Arrêter le conteneur Bitwarden_RS
  2. Faire une copie de sauvegarde du dossier complet .../docker/bitwarden_rs
  3. Renommer les trois dossiers en remplaçant bitwarden (ou bitwarden_rs) par vaultwarden : bitwarden_rs/bitwarden-data/
    • bitwarden_rs/bitwarden-data/ ---> vaultwarden/vaultwarden-data/
    • bitwarden_rs/bitwarden-backup ---> vaultwarden/vaultwarden-backup/
  4. Supprimer la stack dans Portainer, ou supprimer le conteneur via la ligne de commande.
  5. Créer une nouvelle stack dans Portainer avec le fichier docker compose v3.0 (pensez à modifier les valeurs perso).
  6. Vous reconnecter.
  7. Annexe : si vous souhaitez changer de nom de domaine, créer le nouveau, et mettez le dans le docker-compose à la place de l'ancien.


1.2- Mise à jour v4.4 (DSM7)
Si vous voulez installer DSM7 RC, il faut savoir que le script pour activer les notifications websocket ne fonctionne plus en tant que tel.
Il faut le mettre à jour lui aussi :D.
Le chemin d'accès au fichier du reverse proxy a changé, la commande pour ajouter une ligne dans le fichier du reverse proxy ne fonctionne plus non plus, et la commande pour recharger nginx non plus. (Je ne modifie pas les explications du tuto car changer les chemins d'accès dans cette partie n'est pas utile...)

Dans la nouvelle version du script, j'en ai profité pour simplifier la modification de l'adresse IP qui n'est à modifier qu'en un seul endroit : voir les commentaires du script.
le script se trouve dans le §5.3.

1.2- Mise à jour v4.5 (hash argon2 pour ADMIN_TOKEN)
Depuis la mise à jour 1.28.0 de Vaultwarden, il est plus que conseillé de sécuriser le token d'admin : Secure the ADMIN_TOKEN.
Pour cela, il y a deux méthode : utilsier argon2 pour hasher le token, ou bien utiliser le binaire vaultwarden.
Je choisi ici d'utiliser argon2.
Concrètement, il faut générer un hash, et le mettre au format du docker-compose car les symboles [lCODE]$[/lCODE] présents dans le hash sont interpétés par docker-compose. Il faut donc les "échapper" avec un autre [lCODE]$[/lCODE].
Aussi, pour éviter des manipulation de chaine de caractères, et pour éviter des erreurs, je vous propose un script qui va faire tout ça à votre place.
Et si vous être sur un mac, il va vous proposer d'installer argon2 via homebrew, voir homebrew aussi si ça n'est pas installé. Vous pourrez toujours refuser et installer argon2 par vous même : voir sur ce lien..


2- Préambule & Prérequis
Tout d'abord, pourquoi je fais un nouveau tuto d'installation de vaultwarden... En fait je n'ai pas vu de tuto vraiment à mon goût sur l'installation de vaultwarden, soit il manque des explications, soit c'est fait via l'interface DSM de docker... Donc je me décide à en faire un moi-même.
Je précise qu'il n'y aura pas beaucoup de différences avec ceux trouvés sur le NET, si ce n'est ceci :
  • L'utilisation de Portainer ou de la ligne de commande (=CLI) avec docker-compose
  • Des commentaires expliquants la plupart des options utilisées tout le long du docker-compose.yml
  • Une utilisation combinée avec un conteneur faisant automatiquement des sauvegardes de la base de données, là aussi avec des commentaires dans le docker-compose.yml : https://gitlab.com/1O/vaultwarden-backup


Pour mettre en oeuvre ce tuto, il faudra au préalable :
  • que vous ayez mis en place Portainer (voir le tuto d'EVOTk) ;
  • que vous sachiez vous connecter en SSH au NAS et lancer docker-compose up -d si vous optez pour la création des conteneurs en ligne de commande (vous trouverez ici un tuto explicatif : [Tuto] Acceder à son NAS en lignes de commande) ;
  • savoir identifier les PUID et PGID d'un utilisateur avec une ligne de commande en SSH sur le NAS.


3- Mise en place et création des conteneurs ( > Mise à jour < )

3.1- Petites explications sur ce qui suivra

Le but de ce tuto est de tout préparer sur l'ordinateur avant de placer les fichiers/dossiers au bon endroit, tout en comprenant bien ce qui est fait et les implications de certaines options.
On va tout d'abord commencer par créer un fichier docker-compose.yml qui pourra servir pour les deux méthodes d'installation (Portainer, ou CLI).
J'opte pour combiner la création des deux conteneurs (vaultwarden et vaultwarden Backup) en un seul fichier docker-compose.yml. J'ai également choisi de placer ces deux conteneurs dans un même réseau (network) que je nomme vaultwarden_network.
Ensuite il faudra créer ce réseau et les dossiers utilisés avant de créer les conteneurs.
Pour les dossiers, je pars sur cette organisation : (sur le volume1)

(Note : j'ai conservé pour quelques semaines encore, l'ancien dossier de backup : vaultwarden_backup, il n'est pas nécessaire pour vous de le créer...)

Note : Tout ce qui sera XXxxXX sera à remplacer par vos valeurs. J'indiquerais comment les obtenir si ce n'est pas évident.

3.2- Création du docker-compose.yml ( > Mise à jour < )
Voir le fichier ci-joint dans le §0.
( Dans la mise à jour du tuto (v2.0), j'ai ajouté pas mal de commentaires dans le fichier docker-compose.yml. Lisez-les attentivement )

Ce fichier est composé de trois parties : une partie dédiée à vaultwarden et à sa configuration, et une autre partie dédiée à vaultwarden backup et à sa configuration, et enfin une pour le réseau.

Explications sur la partie configuration (partie 1) de vaultwarden (1ère partie du docker-compose.yml) :

Ce qui suit met en place la version de docker-compose à utiliser : pour plus de compatibilité (et par simplicité car je ne maitrise pas la v3...) on part sur une v2.

Il y a dans l'extrait ci-dessous des commentaires qui permettent de comprendre ce qui est fait.
Il faudra remplacer les XXxxXX par vos valeurs à vous.



Avertissement concernant la variable SIGNUPS_ALLOWED
Dans la partie du docker-compose concernant Vaultwarden, il y a une variable d'environnement particulière qui bloque l'inscription de nouveaux comptes si elle a comme valeur false :
Code:
- SIGNUPS_ALLOWED=false
Ce faisant, il vous sera impossible de créer votre premier compte via l'interface web de Vaultwarden si vous la laissez sur false.
Mais... Il y a deux possibilités pour quand même avoir un compte (sinon ce n'est pas très utile comme outils...).

  • La première est peut-être la plus pratique : il suffit d'aller dans l'interface admin ( https://votre-nom-de-domaine.tld/admin ) en utilisant le ADMIN_TOKEN, et de remplir le champ email dans "Invite User" avec votre email pour vous "auto-inviter". Il faut bien entendu que l'envoi d'email soit fonctionnel, ce qui sera obligatoire pour le 2FA.
    wquYyII.png
  • La deuxième méthode c'est de mettre la variable SIGNUPS_ALLOWED sur true :

  • [lcode]- SIGNUPS_ALLOWED=true[/lcode]
    Et là aussi, deux possibilités :
    • Soit vous créer de base le conteneur cette variable sur true, et alors au premier lancement vous pourrez créer votre compte. Mais il faudra ensuite soit passer par l'interface admin pour passer le paramètre "Allow new signups" à false en décochant la case à cocher (chez moi c'est par défaut à false à cause de la variable SIGNUPS_ALLOWED).

    • Soit vous modifiez (après le premier lancement et la création du compte) le docker-compose en repassant la variable SIGNUPS_ALLOWED à false, et vous recréez le conteneur.


Quoique vous fassiez, je vous conseil vivement de désactiver l'inscription via la variable SIGNUPS_ALLOWED, et d'inviter chaque utilisateur avec la console admin, puis de désactiver la console admin en commentant la variable ADMIN_TOKEN (donc en recréant le conteneur). (ce n'est qu'un conseil).





Code:
##==============================================================================================
##                                                                                            ##
##         Fichier docker-compose.yml pour Vaultwarden avec ttionya/vaultwarden-backup        ##
##                                 Révision du fichier : v4.0                                 ##
##                                                                                            ##
##==============================================================================================
##                                                                                            ##
## Attention, avec ce fichier, il faut avoir créer le réseau "vaultwarden_network" avant de   ##
## créer les conteneurs.                                                                      ##
##                                                                                            ##
##             La mise en place de fail2ban se fera avec un docker-compose dédié.             ##
##                                                                                            ##
##==============================================================================================
##                                                                                            ##
##                                       NOTE IMPORTANTE                                      ##
##                                      -----------------                                     ##
##                                                                                            ##
##  Lors de l'importation d'un fichier contenant beaucoup d'entrées, j'ai eu une erreur       ##
##  405 Not Allowed - Nginx                                                                   ##
##  Après quelques recherches, et un certains nombre de minutes, il s'est avéré que les       ##
##  expiration du délai ... (les timeout) dans le reverse proxy par défaut de 60s étaient     ##
##  trop faible.                                                                              ##
##  En passant les 3 valeurs à 300s (5min), ça a réglé mon problème.                          ##
##  (Pensez à relancer le script vaultwarden__Enable_Websocket.sh après ces modifications)    ##
##                                                                                            ##
##==============================================================================================
##                                                                                            ##
##                              Ajout des Notifications Websocket                             ##
##                                                                                            ##
## Pour qu'elles'fonctionnent, il faut configurer le reverse-proxy correctement.              ##
## Pour celui de DSM, il n'est malheureusement pas possible de configurer les                 ##
## redirections /notifications/hub vers le serveur WebSocket ni celles vers le port normal    ##
## /notifications/hub/negotiate                                                               ##
## Voir cet article pour tout ce qui n'est pas possible via l'interface de DSM :              ##
## https://github.com/dani-garcia/vaultwarden/wiki/Enabling-WebSocket-notifications           ##
##                                                                                            ##
## Dès lors, il faut ruser et passer par l'exécution d'un petit script qui va créer un        ##
## fchier ws.locations contenant les modifications précédentes, et qui va écrire une          ##
## ligne dans le fichier /etc/nginx/app.d/server.ReverseProxy.conf pour inclure le            ##
## fichier ws.locations au niveau de la section concernant le nom de domaine pour             ##
## vaultwarden.                                                                               ##
## Comme cela, il n'est pas nécessaire de passer par le changement de reverse-proxy, assez    ##
## complexe à mettre en oeuvre...                                                             ##
##                                                                                            ##
## Le script est : vaultwarden__Enable_Websocket.sh                                           ##
##                                                                                            ##
## Il faudra la lancer régulièrement et à chaque redémarrage du NAS, via deux tâches          ##
## plannifiées dédiées, en donnant 3 paramètres au fichier :                                  ##
## - le nom de domaine de vaultwarden                                                         ##
## - le port HTTP exposé (donc pas l'interne du conteneur) pour l'interface graphique         ##
## - le port websocket exposé (donc pas l'interne du conteneur)                               ##
## Voir les commentaires de ce fichier vaultwarden__Enable_Websocket.sh pour plus             ##
## d'explications.                                                                            ##
##                                                                                            ##
##==============================================================================================

---
version: "2.4"

services:
  vaultwarden:
    image: vaultwarden/server:latest    # https://github.com/dani-garcia/vaultwarden
                                        # https://github.com/dani-garcia/vaultwarden/wiki
    container_name: vaultwarden
    networks:
      - vaultwarden_network
    environment:
      # Utiliser la commande (en SSH) : id NOM_UTILISATEUR
      - PUID=1000
      - PGID=100
      - TZ=Europe/Paris
   
      # Pour l'envoi d'emails
      - SMTP_HOST=XXxxXX
      - SMTP_FROM=XXxxXX
      - SMTP_FROM_NAME=BlaBla
      - SMTP_PORT=XXxxXX
      - SMTP_SSL=true
      - SMTP_USERNAME=XXxxXX
      - SMTP_PASSWORD=XXxxXX

      - INVITATION_ORG_NAME=Vaultwarden [Votre Nom, pseudo...]   # Permet de spécifier un nom d'application pour les invitations d'organisation

      # Nécessaire pour activer le 2FA pour la connexion à notre serveur Vaultwarden
      # Il est possible de spécifier un port de connexion dans l'URL. Le https:// est obligatoire.
      # Pour cette option, il est donc OBLIGATOIRE d'avoir fait le nécessaire pour avoir du HTTPS (certificats, reverse-proxy, ...)
      - DOMAIN=XXxxXX

      # Pour enregistrer les log avec un niveau particulier
      - LOG_FILE=/data/vaultwarden.log
      - LOG_LEVEL=warn
      - EXTENDED_LOGGING=true

      # je n'aime pas les indices pour les mots de passe...
      - SHOW_PASSWORD_HINT=false

      # Pour activer la console d'administation, accessible via : https://mon.domaine.tld/admin/
      # Voir détails ici : https://github.com/dani-garcia/vaultwarden/wiki/Enabling-admin-page
      # /!\
      # /!\ N'importe qui pourra accéder à la page de connexion, alors blinder le token d'amdin ci-dessous (64 caractères pour moi) !
      # /!\ Il est de plus TRÈS important d'avoir ACTIVÉ le HTTPS avant l'activation de cette option.
      # /!\
      # Je conseille de ne l'activer qu'en cas de nécessité, et de la désactiver après.
      # L'utilisation d'Argon2 est recommandée, voir ici : https://github.com/dani-garcia/vaultwarden/wiki/Enabling-admin-page#secure-the-admin_token
      # Pour désactiver, il suffit de commenter la ligne ci-dessous.
      - ADMIN_TOKEN=XXxxXX
      # À noter :
      #   La première fois que vous enregistrez un paramètre dans la page d'administration, 'config.json' sera généré
      #   dans votre 'DATA_FOLDER'. Les valeurs de ce fichier auront priorité sur les valeurs 'environnement'.
   
      - SIGNUPS_ALLOWED=false   # Fait en sorte que les inscriptions soient bloquées, seul l'admin pourra inviter
                                # des utilisateurs avec un envoi d'email depuis la console d'administation
                             
      - WEBSOCKET_ENABLED=true  # Active les WebSocket notifications (Nécessite la configuration du reverse-proxy)
                                # Durant le nombre importants d'essais, j'en suis venu à laisser le port par défaut
                                # pour le WEBSOCKET_PORT. Il est possible que ça fonctionne avec un port différent.
                                # Il faudra alors décommenter la ligne suivante, et changer le port exposé plus bas.
      #- WEBSOCKET_PORT=3012    # Par défaut = 3012
   
      # Pour activer la récupération des icones des IP LAN, il faut mettre sur false la variable ICON_BLACKLIST_NON_GLOBAL_IPS
      - ICON_BLACKLIST_NON_GLOBAL_IPS=false      # Par défaut = true
   
      # On défini ici quelques chemins de dossiers qu'il faudra créer (pas sur que le conteneur les crées lui-même...)
      - ICON_CACHE_FOLDER=data/icon_cache
      - ATTACHMENTS_FOLDER=data/attachments
      - SENDS_FOLDER=data/sends

    labels:
      - "com.centurylinklabs.watchtower.enable=true"

    volumes:
      - "/volume1/docker/vaultwarden/vaultwarden-data/:/data/"
    ports:
      - XXxxXX:3012   # Choisir un port libre pour le websocket
      - XXxxXX:80     # Choisir un port libre pour l'interface WEB
    restart: unless-stopped


( > Mise à jour v4.5 < )[/B]
Depuis la mise à jour 1.28.0 de Vaultwarden, il est plus que conseillé de sécuriser le token d'admin : Secure the ADMIN_TOKEN.
Pour cela, il y a deux méthode : utilsier argon2 pour hasher le token, ou bien utiliser le binaire vaultwarden.
Je choisi ici d'utiliser argon2.
Concrètement, il faut générer un hash, et le mettre au format du docker-compose car les symboles [lCODE]$[/lCODE] présents dans le hash sont interpétés par docker-compose. Il faut donc les "échapper" avec un autre [lCODE]$[/lCODE].
Aussi, pour éviter des manipulation de chaine de caractères, et pour éviter des erreurs, je vous propose un script qui va faire tout ça à votre place.
Et si vous être sur un mac, il va vous proposer d'installer argon2 via homebrew, voir homebrew aussi si ça n'est pas installé. Vous pourrez toujours refuser et installer argon2 par vous même : voir sur ce lien..
Voir le script en fin de post.
Voilà un exemple de sortie de ce script :
1684420325276.png
Il donne, après avoir taper ou coller le ADMIN_TOKEN, le hash argon2 de ce token :
  • avec les paramètres conseillés par Bitwarden : une version utilisable avec la ligne de commande docker (CLI), et une version utilisable dans le fichier docker-compose.yml.
  • Même chose avec les paramètres QWASP minimum.
Dans l'exemple c-dessus, il faudra copier/coller $$argon2id$$v=19$$m=65540,t=3,p=4$$dXR1cmVGUnZqUm0rWnFScS9FTUhQV0dyOW1zZ3JlSEJGU1YyK0RDU3Yyaz0$$dvWbQwCnPVb6a0kHkqYFeRayEb9glOphDPH728Shdi8


Maintenant la deuxième partie (partie 2) qui peut ne pas être utilisée si vous ne souhaitez pas sauvegarder automatiquement la BDD : ( > Mise à jour v4.0 < )

( > Mise à jour v4.0 < )

Je change la méthode de sauvegarde pour une nouvelle image qui permet davantage de choses, dont la sauvegarde des dossiers attachements, et sends en plus de la base de données.

2T2U5QL.png

Il est possible de faire un backup local (méthode utilisée ici) mais il est également possible de faire une sauvegarde dans un cloud parmis une liste assez grande (voir plus bas).
Le fichier 7z obtenu est protégé par un mot de passe, celui présent dans le docker-compose dans la variable ZIP_PASSWORD.
La méthode de compression peut être changée pour zip, moins compressé, mais moins demandeur de ressources...


Comme précédemment, les indications sont en commentaires)
Code:
  vaultwarden_backup_ttionya:     # Voir : https://github.com/ttionya/vaultwarden-backup
    image: ttionya/vaultwarden-backup:latest
    container_name: vaultwarden_backup_ttionya
    networks:
      - vaultwarden_network
 
    restart: always
 
    depends_on:
      vaultwarden:
        condition: service_healthy
 
    labels:
      - "com.centurylinklabs.watchtower.enable=true"
 
    volumes:
      - /volume1/docker/vaultwarden/vaultwarden-data:/data
      # Chemin d'accès pour stocker le backup et la configuration rclone, voir https://github.com/ttionya/vaultwarden-backup
      - /volume1/docker/vaultwarden/vaultwarden-backup_ttionya/config:/config
      - /volume1/docker/vaultwarden/vaultwarden-backup_ttionya/rclone_backup:/rclone_backup

    environment:
      - DATA_DIR=/data                    # Dossier de données de Vaultwarden monté avec les volumes
      - RCLONE_REMOTE_NAME=Backup_Syno    # Nom de la config rclone utilisée (voir note plus bas)
      - RCLONE_REMOTE_DIR=/rclone_backup/ # Dossier qui doit monté avec les volumes
   
      # Utiliser soit SCHEDULE soit INTERVAL (ce dernier en sec)
      # Pour SCHEDULE : https://crontab.guru/#0_22_*_*_*
      # Dans la ligne suivante, on programme l'exécution tous les jours à 22h
      - CRON=0 22 * * *
      - ZIP_ENABLE=TRUE
      - ZIP_PASSWORD=WHEREISMYPASSWORD?
      - ZIP_TYPE=7z
      - BACKUP_FILE_DATE_SUFFIX=--%Hh%Mm%Ss
      - BACKUP_KEEP_DAYS=7
      # - MAIL_SMTP_ENABLE=FALSE
      # - MAIL_SMTP_VARIABLES=''
      # - MAIL_TO=''
      # - MAIL_WHEN_SUCCESS='TRUE'
      # - MAIL_WHEN_FAILURE='TRUE'
      - TIMEZONE=Europe/Paris
   
      #############################################
      # Note à propos de la configuration de rclone
      #############################################
      # Si vous voulez faire une sauvegarde locale, il faut juste placer le fichier rclone.conf dans le dossier ../config/rclone/
      # Dans ce fichier vous trouverez ceci :
      #          [Backup_Syno]
      #          type = local
      #
      # Il faudra remplacer Backup_Syno par un autre nom au besoin.
      # Ce fichier est donc prévu pour une sauvegarde locale.
      # Pour configurer d'autres types de sauvegarde, il faut lancer la configuration de rclone avec cette commande :
      # docker run --rm -it -v /volume1/docker/vaultwarden/vaultwarden-backup_ttionya/config:/config ttionya/vaultwarden-backup:latest rclone config


Et enfin une dernière partie (partie 3) qui est obligatoire, celle qui concerne le réseau :
Code:
networks:                                         # On indique ici de quel réseau on parlait précédement
  vaultwarden_network:
    external:                                     # C'est un réseau créé en dehors du docker-compose.
      name: vaultwarden_network                   # Je précise toujours un nom, car sinon ça va prendre un nom à rallonge avec
                                                  # le nom du conteneur et du réseau voulu...

Il est à préciser que ces trois parties sont à fusionner en un seul et même fichier. Je les ai séparer pour les explications.
Voir le fichier docker-compose.yml joint précédement.

3.3- Configuration de rclone pour le backup ( > Mise à jour v4.0 < )
Pour que la sauvegarde se fasse sans erreur, il faut configurer un fichier rclone.conf qui devra se trouver dans /volume1/docker/vaultwarden/vaultwarden-backup_ttionya/config/rclone/

Deux possiblités en fonction de ce que vous voudrez faire.
  • La première si vous faites comme moi, une sauvegarde locale (dans un dossier du NAS, monté dans les volumes, voir paragraphe précédent).
    Pour cette méthode, il suffit de créer un fichier rclone.conf dans /volume1/docker/vaultwarden/vaultwarden-backup_ttionya/config/rclone/ (ou de copier le fichier joint) contenant :
    Code:
    [Backup_Syno]
    type = local
    Vous remarquerez que Backup_Syno est le nom donné dans le docker compore à la variable RCLONE_REMOTE_NAME.
    Il faudra donc bien configurer la variable RCLONE_REMOTE_DIR avec le chemin d'accès à l'intérieur du conteneur.

    Je tiens à préciser que ce mode de sauvegarde doit être complété par une tâche de backup planifiée (Hyperbackup) du dossier docker contenant le dossier Vaultwarden dans un cloud ou ailleurs.
  • La seconde si vous voulez ajouter des options, ou bien faire une sauvegarde dans un cloud.
    Pour cela, il faut lancer une commande en ligne de commande SSH (donc se connecter en SSH au NAS) :
    Code:
    docker run --rm -it \
      -v /volume1/docker/vaultwarden/vaultwarden-backup_ttionya/config:/config \
      ttionya/vaultwarden-backup:latest \
      rclone config

    NOTE : Attention, pour ceux qui utilise Portainer, il se pourrait que cette commande, lancée avant la création du conteneur, fasse que la stack ne soit pas gérable par Portainer... Créer d'abord le conteneur, puis stopper le, avant de lancer cette commande.

    Cette commande ne crée pas le conteneur, elle va juste lancer le processus de configuration de rclone :


    Vous pourrez éditer la configuration précédemment enregistrée (dans mon exemple, celle utilisée pour le backup local), en créer une nouvelle, etc...
    Pour la création, il faut donc taper n (new remote).
    Une fois donné un nom, vous aurez le choix entre toutes ces possibilités de cloud (sauf n°22 qui est la sauvegarde locale) :

    Je n'ai pas poursuivi une de ces méthodes de cloud, à vous d'essayer ;) (si vous le faites, n'hésiter pas à revenir faire un petit retour ;) ).

    À l'issue de l'exécution de cette configuration, vous aurez automatiquement le fichier rclone.conf écrit dans le dossier .../config/rclone/ (ou bien celui déjà existant sera modifié).



3.4- Création des dossiers et du réseau

La partie explications des options à placer dans le fichier docker-compose.yml étant faite, passons à la création des dossiers sur le NAS.
Vous pouvez soit passer par DSM, soit par la ligne de commande.
Si vous optez pour la CLI, voilà les commandes à taper :
Code:
sudo -i
cd /volume1/docker
mkdir -p vaultwarden vaultwarden/vaultwarden-data vaultwarden/vaultwarden-backup_ttionya/config/rclone vaultwarden/vaultwarden-backup_ttionya/rclone_backup
Une fois ces dossiers créés, copier votre docker-compose.yml dans le dossier /volume1/docker/vaultwarden.

Il faut maintenant créer le réseau. Plusieurs possibilités existent.
Soit vous passez par DSM (non expliquée ici), soit vous passez par Portainer, soit enfin via la CLI.
  • Utilisation de Portainer :
    Dans Portainer, il faut aller dans la section Networks, et ensuite cliquer sur le bouton Add Network :

    Ensuite, il suffit juste de rentrer le nom du réseau à créer (ici : ) et de bien choisir Bridge comme Driver :

    Il n'y a pas besoin de toucher au reste. Portainer choisir les IP en fonction de ce qui est déjà créé chez vous.
    ________________
  • Utilisation de la CLI :
    Pour créer le réseau vaultwarden_network :
    Code:
    sudo docker network create vaultwarden_network
    Si vous voulez supprimer le réseau ainsi créé, il faut taper :
    Code:
    sudo docker network rm vaultwarden_network
    Au besoin, si vous voulez lister les réseeaux :
    Code:
    sudo docker network ls
    Note : Si vous avez plusieurs commandes à taper en mode root, il faut faire : sudo -i
    Et ensuite taper vos commande sans le sudo devant.



3.5- Création des conteneurs (2 méthodes)
Maintenant tout est prêt pour qu'on se lance dans la création des conteneurs.
Deux possibilités : passer par Portainer, ou bien la CLI.
  • Par Portainer :
    Il faut aller dans la section "Stacks", puis cliquer sur le bouton "+ Add stack" :

    Ensuite, on donne un nom à la stack que l'on va créer et on copie/colle le contenu du fichier docker-compose.yml créé précédemment :

    Il est également possible d'uploader ce dit fichier en utilisant le bouton "Upload" : (je n'ai personnellement jamais utiliser cette option, mais il n'y a pas de raison pour qu'elle ne fonctionne pas)


    Il ne reste plus qu'à cliquer sur le bouton "Deploy the stack" tout en bas à gauche de la page :


    Si une erreur apparait, ce sera dans le coin supérieur droit dans un rectangle rouge, essayer d'en faire une capture avant sa disparition.
    Si non, un message en vert apparait et les conteneurs seront créés :


    Vous noterez dans cette stack, il est possible de l'éditer pour la modifier avec l'onglet Editor :

    __________
  • Par la CLI :
    Avec la ligne de commande, il faut être en root (voir remarque faite précédemment à ce propos...).
    Il faut aussi être dans le dossier contenant le fichier docker-compose.yml (attention au nom, il doit être exactement docker-compose.yml), sinon il faut spécifier avec un argument supplémentaire le fichier et son chemin. Je choisi la facilité : on se place dans le bon dossier :
    Code:
    cd /volume1/docker/Vaultwarden
    sudo docker-compose up -d
    La création des deux conteneurs se fait et ils démarrent.



4- 1er lancement et sécurisation 2FA
Une fois les étapes précédentes accomplies, il faut accéder au serveur avec l'url que vous avez indiqué dans la configuration.
Si vous essayer d'accéder via l'IP LAN en http ça ne fonctionnera pas, car le HTTPS est activé, vous aurez l'erreur suivante :

Et si vous essayer toujours avec l'IP mais en HTTPS, vous aurez cette erreur :


( > Mise à jour - v3.1 < )
Bref, il faut y accéder avec votre nom de domaine. Mais pour cela il faut paramétrer le reverse-proxy de DSM.

Une fois cette entrée créé, vous pouvez accéder en HTTPS avec votre nom de domain à Vaultwarden :



( > Mise à jour - v3.0 < )
Vous devriez voir ici "© 2021, Bitwarden Inc. (Powered by Vaultwarden)", ceci marque le changement de nom de l'image, voir §1)



Il faut ensuite créer votre compte et vous pourrez alors créer vos mots de passe, importer depuis un autre logiciel de mot de passe...

Voilà voilà.
Reste plus qu'à sécuriser le compte avec le 2FA. Pour cela, il faut aller dans le compte :


Puis il faut choisir votre méthode. J'ai choisi de passer par une application d'authentification comme MS Authenticator, ou Authy, ou même une autre application de mot de passe comme EnPass que j'utilise aussi.
Cliquer sur le bouton Gérer de la méthode choisie :
Entre votre mot de passe maitre (celui du compte BW) :

À l'aide de l'application d'authentification, après y avoir entrer les infos (QR-Code ou Code alphanumérique), entrer le code à usage unique générer pour valider le 2FA :


Voilà, le compte est protégé :)

PS : si vous n'avez plus besoin de compte sur votre serveur, il est possible de désactiver la création des comptes.
Dans la section :
Code:
    environment:
Il faut ajouter ceci :
Code:
      - SIGNUPS_ALLOWED=false



5- Ajout d'un script pour les notifications Websocket
Alors, après pas mal de temps de recherche, j'ai finalement trouvé comment activer les notifications Websocket et j'ai aussi compris leur utilité.
J'ai trouvé la méthode sur le forum officiel de Vaultwarden, où ce lien a été posté : https://gist.github.com/nstanke/3949ae1c4706854d8f166d1fb3dadc81
J'ai pris ce script, et je l'ai amélioré selon mes goûts de sureté, et d'explications (vous verrez plus bas de quoi je parle).

5.1- Explications : Pourquoi ? Comment ?

Ces notifications servent à mettre à jour automatiquement les extensions navigateurs et les clients non mobiles, donc les applications windows, macos, etc, mais pas android et iOS. Pour ces derniers OS, ce n'est juste pas possible avec Vaultwarden, car il faudrait passer par les serveurs de Bitwarden pour les notifications push. Et Vaultwarden ne peut pas le faire.

Pour activer ces notifications Websocket, il faut faire plusieurs choses. Seul ce qui suit est faisable directement depuis DSM, dans le reverse-proxy :

Lors de la création de la règle pour Vaultwarden, il faut ajouter les entêtes personnalisés suivants : (pensez à utiliser le bouton pour créer automatiquement les deux premières lignes)


Pour le reste, malheureusement il n'est pas possible de le faire depuis DSM... car bien le moteur du reverse-proxy est nginx, il n'y a pas d'interface graphique pour le faire.
Il faut faire passer /notifications/hub avec les mêmes entêtes et /notifications/hub/negotiate au conteneur. Et ça, pas moyen de le faire depuis DSM.
Il faut passer par un script qui va créer un fichier ws.locations contenant ces propriétés, et modifier le fichier de configuration /etc/nginx/app.d/server.ReverseProxy.conf afin d'inclure le fichier créé ws.locations au bon endroit, c'est-à-dire dans la section du nom de domaine pour bitwardenRS.
C'est donc un prérequis (voir les captures précédentes).
Le fichier qui sera créé ressemblera à ceci :

Il faudra adapter le script suivant pour tenir compte de votre adresse IP de l'hôte du conteneur vaultwarden. C'est-à-dire remplacer 192.168.2.200 par l'IP de votre NAS.

Il est à noter que le fichier /etc/nginx/app.d/server.ReverseProxy.conf est réinitialisé à chaque démarrage du NAS, mais aussi à chaque changement dans l'interface graphique du reverse-proxy dans DSM. Il faut donc le lancer périodiquement.
Il faudra créer une tâche planifiée en conséquence.
En ce qui me concerne j'ai créé une tâche déclenchée à chaque démarrage du NAS, et une programmée toutes les 6h. Vous pouvez mettre une fréquence plus grande (toutes les 1h) ou moins, c'est selon votre utilisation du NAS et des modifications dans le reverse-proxy.
La modification du fichier ressemblera à ceci :


5.2- Comment lancer le script ?

Le script (présent dans le § suivant) doit être lancé avec 3 arguments, sinon vous aurez un beau message indiquant que vous avez fait n'importe quoi... (mais sans rien casser, j'ai bien fait les choses).
Si le script n'est pas lancé avec le bon nombre d'arguments, vous aurez ce message :


Attention, s'il y a bien 3 arguments, je n'ai pas fait de vérification, à vous de savoir ce que vous faites !
Voici quelques explications sur les arguments à placer.
  • Le premier est votre nom de domaine pour Vaultwarden.
  • Le second est le port déclaré dans le reverse proxy pour accéder à l'interface web : par défaut c'est 80. Il sera probablement modifié dans votre installation (voir fichier docker-compose).
  • Le troisième est le port websocket qui par défaut est le 3012. Il sera probablement modifié dans votre installation (voir fichier docker-compose).

Exemple de commande à placer dans le planificateur de tâches :
Code:
bash /volume1/docker/_Scripts-DOCKER/vaultwarden_RS__Enable_Websocket.sh mon-ndd-a-moi.tld 8001 3012

Voilà voilà pour les explications.
Il faudra le lancer une fois après avoir paramétré les tâches.

5.3- Enfin le script lui même !

Voir §0 pour télécharger le fichier.
Attention, j'ai mis pas mal de commentaires dans le script, et que j'ai mis des lignes echo permettant d'avoir un retour d'exécution pour le log qu'on obtient.
Lisez bien les commentaire ;)

Le script pour DSM 6.x :

Code:
#!/bin/bash
##==============================================================================================
##                                                                                            ##
##                      Script vaultwarden__Enable_Websocket_DSM-6.x.sh                       ##
##                                                                                            ##
##          Source : https://gist.github.com/nstanke/3949ae1c4706854d8f166d1fb3dadc81         ##
##                                                                                            ##
##==============================================================================================
##                                                                                            ##
##   Ce script pemet de router ce qui ne peut pas être fait avec le reverse-proxy             ##
##   de DSM (Synology) pour faire fonctionner les notifications Websocket                     ##
##   Doc. vaultwarden :                                                                       ##
##        Route the /notifications/hub endpoint to the WebSocket server, by default           ##
##        at port 3012, making sure to pass the Connection and Upgrade headers.               ##
##        (Note the port can be changed with WEBSOCKET_PORT variable)                         ##
##        https://github.com/dani-garcia/vaultwarden/wiki/Enabling-WebSocket-notifications    ##
##                                                                                            ##
##==============================================================================================
##                                                                                            ##
##                             Principe de Tâche planifier à créer                            ##
##                                                                                            ##
## Il faut lancer régulièrement le script car toutes modifications faites dans l'interface    ##
## graphique du Reverse-Proxy de DSM va modifier le fichier de configuration. Il en va de     ##
## même lorsque le NAS redémarre.                                                             ##
##                                                                                            ##
##==============================================================================================
##                                                                                            ##
##        /!\    Il faut modifier l'adresse IP en ligne 79 et 85 par l'IP du NAS    /!\       ##
##                                                                                            ##
##==============================================================================================
##                                                                                            ##
## Paramètres de lancement du script :                                                        ##
## bash /volume1/docker/vaultwarden/enable_ws.sh vault.example.com 5555 5556                  ##
##                                                                                            ##
## -- vault.example.com = Nom de domaine de vaultwarden (celui du Reverse Proxy de DSM)       ##
## -- 5555 = Port exposé ROCKET_PORT par Docker (Identique à celui du Reverse Proxy de DSM)   ##
## -- 5556 = Port exposé WEBSOCKET_PORT par Docker                                            ##
##                                                                                            ##
##==============================================================================================

LOC_DIR="/etc/nginx"
part1=0
part2=0

echo -e "\n$(date "+%R:%S - ") Script vaultwarden__Enable_Websocket.sh pour activer les Notifications Websockets"

f_affiche_parametre() {
    echo "          bash /volume1/docker/_Scripts-DOCKER/vaultwarden__Enable_Websocket.sh vault.example.com 5555 5556 "
    echo "                           -- vault.example.com = Nom de domaine de vaultwarden (celui du Reverse Proxy de DSM) "
    echo "                           -- 5555 = Port exposé ROCKET_PORT par Docker (Identique à celui du Reverse Proxy de DSM)"
    echo "                           -- 5556 = Port exposé WEBSOCKET_PORT par Docker"
}

if [ ! $# -eq 3 ]; then
    if [ $# -eq 0 ]; then
        # Aucun paramètre n'a été fourni. On va afficher la liste de ce qui peut être utilisé.
        echo "$(date "+%R:%S - ") Aucun paramètre fourni ! Revoir l'appel du script :"
        f_affiche_parametre
    else
        echo "$(date "+%R:%S - ") Le nombre de paramètres fournis n'est pas correct ! Revoir l'appel du script :"
        f_affiche_parametre
    fi
    echo -e "$(date "+%R:%S - ") ECHEC de lancement du script !!!!!!!!!\n"
    exit 1
fi

echo "$(date "+%R:%S - ") Exécution des commandes..."


#############################################################################################################
## Début de la partie de création/modification de fichiers
##
if [ -f $LOC_DIR/ws.locations ]; then
  rm /etc/nginx/ws.locations
  part1=1
fi
echo """
location /notifications/hub {
    proxy_pass http://192.168.2.200:$3;
    proxy_set_header Upgrade \$http_upgrade;
    proxy_set_header Connection \"upgrade\";
}

location /notifications/hub/negotiate {
    proxy_pass http://192.168.2.200:$2;
}
""" >> $LOC_DIR/ws.locations


if ! grep -q "ws.locations" /etc/nginx/app.d/server.ReverseProxy.conf; then
    sed -i "/$1;/ a\ include $LOC_DIR/ws.locations;" /etc/nginx/app.d/server.ReverseProxy.conf
    if nginx -t 2>/dev/null; then synoservicecfg --reload nginx; else exit 1; fi

    part2=1     # Variable pour indiquer que cette partie a été exécutée
fi
##
## Fin de la partie de création/modification de fichiers
#############################################################################################################

if [ $part1 -eq 1 ]; then
  echo "$(date "+%R:%S - ")    -- Le fichier $LOC_DIR/ws.locations existait déjà, il a été supprimé puis recréé."
else
  echo "$(date "+%R:%S - ")    -- Le fichier $LOC_DIR/ws.locations n'existait pas, il a été créé."
fi
if [ $part2 -eq 1 ]; then
  echo "$(date "+%R:%S - ")    -- !!!!!! --->  La modification dans le fichier /etc/nginx/app.d/server.ReverseProxy.conf n'existait pas. Elle a été écrite."
  echo "$(date "+%R:%S - ")    -- !!!!!! --->  Le fichier /etc/nginx/app.d/server.ReverseProxy.conf a du être réinitialisé après un reboot ou lors d'une modification du reverse-proxy dans DSM."
else
  echo "$(date "+%R:%S - ")    -- La modification du fichier /etc/nginx/app.d/server.ReverseProxy.conf a déjà été effectuée lors d'une précédente exécution. Aucune modification n'est donc nécessaire."
fi

echo "$(date "+%R:%S - ") Script vaultwarden__Enable_Websocket.sh terminé"

exit


MAJ v4.4 - Le script pour DSM 7 :

Code:
#!/bin/bash
##==============================================================================================
##                                                                                            ##
##                        Script vaultwarden__Enable_Websocket_DSM-7.sh                       ##
##                                                                                            ##
##          Source : https://gist.github.com/nstanke/3949ae1c4706854d8f166d1fb3dadc81         ##
##                                                                                            ##
##==============================================================================================
##                                                                                            ##
##   Ce script pemet de router ce qui ne peut pas être fait avec le reverse-proxy             ##
##   de DSM (Synology) pour faire fonctionner les notifications Websocket                     ##
##   Doc. vaultwarden :                                                                       ##
##        Route the /notifications/hub endpoint to the WebSocket server, by default           ##
##        at port 3012, making sure to pass the Connection and Upgrade headers.               ##
##        (Note the port can be changed with WEBSOCKET_PORT variable)                         ##
##        https://github.com/dani-garcia/vaultwarden/wiki/Enabling-WebSocket-notifications    ##
##                                                                                            ##
##==============================================================================================
##                                                                                            ##
##                             Principe de Tâche planifier à créer                            ##
##                                                                                            ##
## Il faut lancer régulièrement le script car toutes modifications faites dans l'interface    ##
## graphique du Reverse-Proxy de DSM va modifier le fichier de configuration. Il en va de     ##
## même lorsque le NAS redémarre.                                                             ##
##                                                                                            ##
##==============================================================================================
##                                                                                            ##
##        /!\    Il faut modifier l'adresse IP en ligne 47 par l'IP du NAS    /!\             ##
##                                                                                            ##
##==============================================================================================
##                                                                                            ##
## Paramètres de lancement du script :                                                        ##
## bash /volume1/docker/bitwarden/enable_ws.sh vault.example.com 5555 5556                    ##
##                                                                                            ##
## -- vault.example.com = Nom de domaine de vaultwarden (celui du Reverse Proxy de DSM)       ##
## -- 5555 = Port exposé ROCKET_PORT par Docker (Identique à celui du Reverse Proxy de DSM)   ##
## -- 5556 = Port exposé WEBSOCKET_PORT par Docker                                            ##
##                                                                                            ##
##==============================================================================================

LOC_DIR="/etc/nginx"
part1=0
part2=0
MY_DOMAIN=$1
PORT_ACCES=$2
PORT_CONT=$3
IP_NAS="192.168.2.200"

echo -e "\n$(date "+%R:%S - ") Script vaultwarden__Enable_Websocket.sh pour activer les Notifications Websockets"

f_affiche_parametre() {
  echo "          bash /volume1/docker/_Scripts-DOCKER/vaultwarden__Enable_Websocket.sh vault.example.com 5555 5556 "
  echo "                           -- vault.example.com = Nom de domaine de vaultwarden (celui du Reverse Proxy de DSM) "
  echo "                           -- 5555 = Port exposé ROCKET_PORT par Docker (Identique à celui du Reverse Proxy de DSM)"
  echo "                           -- 5556 = Port exposé WEBSOCKET_PORT par Docker"
}

if [ ! $# -eq 3 ]; then
  if [ $# -eq 0 ]; then
    # Aucun paramètre n'a été fourni. On va afficher la liste de ce qui peut être utilisé.
    echo "$(date "+%R:%S - ") Aucun paramètre fourni ! Revoir l'appel du script :"
    f_affiche_parametre
  else
    echo "$(date "+%R:%S - ") Le nombre de paramètres fournis n'est pas correct ! Revoir l'appel du script :"
    f_affiche_parametre
  fi
  echo -e "$(date "+%R:%S - ") ECHEC de lancement du script !!!!!!!!!\n"
  exit 1
fi

echo "$(date "+%R:%S - ") Exécution des commandes..."


#############################################################################################################
## Début de la partie de création/modification de fichiers
##
if [ -f $LOC_DIR/websocket.locations.vaultwarden ]; then
  rm $LOC_DIR/websocket.locations.vaultwarden
  part1=1
fi
echo """
location /notifications/hub {
    proxy_pass http://192.168.2.200:$PORT_CONT;
    proxy_set_header Upgrade \$http_upgrade;
    proxy_set_header Connection \"upgrade\";
}

location /notifications/hub/negotiate {
    proxy_pass http://192.168.2.200:$PORT_ACCES;
}
""" >>$LOC_DIR/websocket.locations.vaultwarden

# Note : avec DSM7, le chemin d'accès du fichier server.ReverseProxy.conf a changé
#         DSM6.2  = /etc/nginx/app.d/server.ReverseProxy.conf
#         DSM7    = /etc/nginx/sites-enabled/server.ReverseProxy.conf
if ! grep -q "websocket.locations.vaultwarden" /etc/nginx/sites-enabled/server.ReverseProxy.conf; then

  # Commandes fonctionnelles avec DSM6.2.x, mais plus avec DSM 7.0 (RC)
  #sed -i "/$1;/ a\ include $LOC_DIR/websocket.locations.vaultwarden;" /etc/nginx/app.d/server.ReverseProxy.conf
  #if nginx -t 2>/dev/null; then synoservicecfg --reload nginx; else exit 1; fi

  # Commande fonctionnelles avec DSM 7 (RC)
  sed -r "s#^([[:blank:]]*server_name[[:blank:]]*${MY_DOMAIN}[[:blank:]]*;[[:blank:]]*)\$#\1\n\n\tinclude ${LOC_DIR}/websocket.locations.vaultwarden;#" /etc/nginx/sites-enabled/server.ReverseProxy.conf > /etc/nginx/sites-enabled/server.ReverseProxy.conf.new
  mv /etc/nginx/sites-enabled/server.ReverseProxy.conf.new /etc/nginx/sites-enabled/server.ReverseProxy.conf

  if nginx -t 2>/dev/null; then synosystemctl reload nginx; else exit 1; fi

  part2=1 # Variable pour indiquer que cette partie a été exécutée

fi
##
## Fin de la partie de création/modification de fichiers
#############################################################################################################

if [ $part1 -eq 1 ]; then
  echo "$(date "+%R:%S - ")    -- Le fichier $LOC_DIR/websocket.locations.vaultwarden existait déjà, il a été supprimé puis recréé."
else
  echo "$(date "+%R:%S - ")    -- Le fichier $LOC_DIR/websocket.locations.vaultwarden n'existait pas, il a été créé."
fi
if [ $part2 -eq 1 ]; then
  echo "$(date "+%R:%S - ")    -- !!!!!! --->  La modification dans le fichier /etc/nginx/sites-enabled/server.ReverseProxy.conf n'existait pas. Elle a été écrite."
  echo "$(date "+%R:%S - ")    -- !!!!!! --->  Le fichier /etc/nginx/sites-enabled/server.ReverseProxy.conf a du être réinitialisé après un reboot ou lors d'une modification du reverse-proxy dans DSM."
else
  echo "$(date "+%R:%S - ")    -- La modification du fichier /etc/nginx/sites-enabled/server.ReverseProxy.conf a déjà été effectuée lors d'une précédente exécution. Aucune modification n'est donc nécessaire."
fi

echo "$(date "+%R:%S - ") Script vaultwarden__Enable_Websocket.sh terminé"

exit


Plus tard viendra la partie fail2ban.











________________


À venir : intégration de fail2ban pour sécuriser un poil plus, même si avec le HTTPS et la 2FA c'est déjà bien :)
 
Dernière édition:
Je voudrais modifier le docker-compose avec une nouveauté de la dernière version de l'image bitwarden_rs Backup, mais je peux plus éditer mon message.
Est-ce qu'un modérateur peut m'autoriser à modifier mon post initial ?
Merci :giggle:
 
Salut,
Je peu le modifier pour toi si tu le souhaite.
Répond avec les modif que tu souhaite apporter, et je le ferait :)
 
Ok, mais ce serait plus pratique que je puisse le faire moi-même...

Sinon pour les modifs :
Dans le fichier docker-compose et dans le code coller, remplacer ceci :
Code:
      # Delete old backups after X many days
      - DELETE_AFTER=14
par celà :
Code:
      # Delete old backups after X many days
      - DELETE_AFTER=14
      
      # If you need timestamps in your local timezone you should mount /etc/timezone:/etc/timezone:ro and
      # /etc/localtime:/etc/localtime:ro like it's done in the docker-compose.yml.
      # An other possible solution is to set the environment variable accordingly (like TZ=Europe/Berlin)
      # (see https://en.wikipedia.org/wiki/List_of_tz_database_time_zones for more information).
      - TZ=Europe/Paris


Et dans le même fichier, remplacer ça :
Code:
      - /etc/localtime:/etc/localtime:ro

par ça :
Code:
      #- /etc/localtime:/etc/localtime:ro  # Devenu inutile sur nos Syno avec la variable d'env. TZ (voir plus bas)
 
Au fait, c'est pour l'image/service :
Code:
  bitwarden_backup:     # Voir : https://gitlab.com/1O/bitwarden_rs-backup
    image: bruceforce/bw_backup:latest
 
MilesTEG1 a dit:
Ok, mais ce serait plus pratique que je puisse le faire moi-même...

Malheureusement a cause du SPAM ( et autre ), nous sommes obligé d'avoir des regles plutot stricte.
Je avis voir avec FX ce qu'on peu faire :)
 
merci pour le tuto, je suis admiratif du travail effectué,
si un autre génie a déjà effectué un tuto sur l’installation Dolibarr MariaDB(10), Phpmyadmin (NAS Synology).
Je suis preneur :giggle: :giggle: :giggle:
 
Merci :)
Et pour les autres applications, là par contre, je ne sais pas. Je n'ai jamais utilisé...
 
Bonjour,

J'ai un souci avec la 1er stack, j'ai une première erreur avec la création du network j'ai du rajouter la valeur suivante :
frontend-network:
external: true

Et maintenant je bloque sur l'erreur suivant :
Vous savez d'ou peux venir cette erreur ?
 

Pièces jointes

  • Capture d’écran 2021-03-30 à 16.19.30.png
    Capture d’écran 2021-03-30 à 16.19.30.png
    59.2 KB · Affichages: 578
synorun a dit:
Bonjour,

J'ai un souci avec la 1er stack, j'ai une première erreur avec la création du network j'ai du rajouter la valeur suivante :
frontend-network:
external: true

Et maintenant je bloque sur l'erreur suivant :
Vous savez d'ou peux venir cette erreur ?
Bonjour,
Je pense que c'est ce que vous avez ajouté qui pose problème :
Code:
frontend-network:
    external: true
Ce n'est pas reconnu par Portainer et son docker-compose (peut-être limité) pour un docker-compoe en version 2.
Il faut laisser tel que c'est mis dans le tuto et bien penser à créer le réseau avant de lancer la création de la stack avec portainer (ou de la commande docker-compose en CLI).

Autre chose, il n'y a pas de 1er stack et de 2nde Stack, ni de 3ème... Tout doit être mis ensemble. (il peut éventuellement possible de ne pas mettre la deuxième partie qui concerne le backup si ce n'est pas désiré). J'ai juste décomposé pour le bien du tuto et des explications.
Je ferais prochainement un ajout du compose complet.
Bonne journée.
 
Ha et bien en fait, j'avais bien fait le tuto, le fichier complet est disponible, voir le début de ce paragraphe :
 
( > TUTO mis à jour < )


Bonjour à toutes et à tous,

Préambule
Tout d'abord, pourquoi je fais un nouveau tuto d'installation de Bitwarden_rs... En fait je n'ai pas vu de tuto vraiment à mon goût sur l'installation de Bitwarden_rs, soit il manque des explications, soit c'est fait via l'interface DSM de docker... Donc je me décide à en faire un moi-même.
Je précise qu'il n'y aura pas beaucoup de différences avec ceux trouvés sur le NET, si ce n'est ceci :
  • L'utilisation de Portainer ou de la ligne de commande (=CLI) avec docker-compose
  • Des commentaires expliquants la plupart des options utilisées tout le long du docker-compose.yml
  • Une utilisation combinée avec un conteneur faisant automatiquement des sauvegardes de la base de données, là aussi avec des commentaires dans le docker-compose.yml : https://gitlab.com/1O/bitwarden_rs-backup


Sommaire :
1. Prérequis
2- Mise en place et création des conteneurs ( > Mise à jour < )
2.1- Petites explications sur ce qui suivra
2.2- Création du docker-compose.yml ( > Mise à jour < )
2.3- Création des dossiers et du réseau
2.4- Création des conteneurs (2 méthodes)
3- 1er lancement et sécurisation 2FA
4- Ajout d'un script pour les notifications Websocket ( > Ajout < )
4.1- Explications : Pourquoi ? Comment ? ( > Ajout < )
4.2- Comment lancer le script ? ( > Ajout < )
4.3- Enfin le script lui même ! ( > Ajout < )
...


1- Prérequis

Pour mettre en oeuvre ce tuto, il faudra au préalable :
  • que vous ayez mis en place Portainer (voir le tuto d'EVOTk) ;
  • que vous sachiez vous connecter en SSH au NAS et lancer docker-compose up -d si vous optez pour la création des conteneurs en ligne de commande (vous trouverez ici un tuto explicatif : [Tuto] Acceder à son NAS en lignes de commande) ;
  • savoir identifier les PUID et PGID d'un utilisateur avec une ligne de commande en SSH sur le NAS.


2- Mise en place et création des conteneurs ( > Mise à jour < )

2.1- Petites explications sur ce qui suivra

Le but de ce tuto est de tout préparer sur l'ordinateur avant de placer les fichiers/dossiers au bon endroit, tout en comprenant bien ce qui est fait et les implications de certaines options.
On va tout d'abord commencer par créer un fichier docker-compose.yml qui pourra servir pour les deux méthodes d'installation (Portainer, ou CLI).
J'opte pour combiner la création des deux conteneurs (bitwarden_rs et Bitwarden_rs Backup) en un seul fichier docker-compose.yml. J'ai également choisi de placer ces deux conteneurs dans un même réseau (network) que je nomme bitwarden_network.
Ensuite il faudra créer ce réseau et les dossiers utilisés avant de créer les conteneurs.
Pour les dossiers, je pars sur cette organisation : (sur le volume1)



Note : Tout ce qui sera XXxxXX sera à remplacer par vos valeurs. J'indiquerais comment les obtenir si ce n'est pas évident.

2.2- Création du docker-compose.yml ( > Mise à jour < )
Vous pouvez télécharger le fichier ci-joint :
( Dans la mise à jour du tuto, j'ai ajouté pas mal de commentaires dans le fichier docker-compose.yml. Lisez-les attentivement )

Ce fichier est composé de trois parties : une partie dédiée à bitwarden_rs et à sa configuration, et une autre partie dédiée à bitwarden_rs backup et à sa configuration, et enfin une pour le réseau.

Explications sur la partie configuration (partie 1) de bitwarden_rs (1ère partie du docker-compose.yml) :

Ce qui suit met en place la version de docker-compose à utiliser : pour plus de compatibilité (et par simplicité car je ne maitrise pas la v3...) on part sur une v2.
Je place dans l'extrait ci-dessous des commentaires supplémentaires (non présents dans le fichier joint) pour expliquer les choix faits.
Code:
##==============================================================================================
##                                                                                            ##
##             Fichier docker-compose.yml pour Bitwarden_RS avec Bitwarden-Backup             ##
##                                                                                            ##
##==============================================================================================
##                                                                                            ##
## Attention, avec ce fichier, il faut avoir créer le réseau "bitwarden_network" avant de     ##
## créer les conteneurs.                                                                      ##
##                                                                                            ##
##             La mise en place de fail2ban se fera avec un docker-compose dédié.             ##
##                                                                                            ##
##==============================================================================================
##                                                                                            ##
##                              Ajout des Notifications Websocket                             ##
##                                                                                            ##
## Pour qu'elles'fonctionnent, il faut configurer le reverse-proxy correctement.              ##
## Pour celui de DSM, il n'est malheureusement pas possible de configurer les                 ##
## redirections /notifications/hub vers le serveur WebSocket ni celles vers le port normal    ##
## /notifications/hub/negotiate                                                               ##
## Voir cet article pour tout ce qui n'est pas possible via l'interface de DSM :              ##
## https://github.com/dani-garcia/bitwarden_rs/wiki/Enabling-WebSocket-notifications          ##
##                                                                                            ##
## Dès lors, il faut ruser et passer par l'exécution d'un petit script qui va créer un        ##
## fchier ws.locations contenant les modifications précédentes, et qui va écrire une          ##
## ligne dans le fichier /etc/nginx/app.d/server.ReverseProxy.conf pour inclure le            ##
## fichier ws.locations au niveau de la section concernant le nom de domaine pour             ##
## bitwarden_RS.                                                                              ##
## Comme cela, il n'est pas nécessaire de passer par le changement de reverse-proxy, assez    ##
## complexe à mettre en oeuvre...                                                             ##
##                                                                                            ##
## Le script est : Bitwarden_RS__Enable_Websocket.sh                                          ##
##                                                                                            ##
## Il faudra la lancer régulièrement et à chaque redémarrage du NAS, via deux tâches          ##
## plannifiées dédiées, en donnant 3 paramètres au fichier :                                  ##
## - le nom de domaine de bitwarden                                                           ##
## - le port HTTP exposé (donc pas l'interne du conteneur) pour l'interface graphique         ##
## - le port websocket exposé (donc pas l'interne du conteneur)                               ##
## Voir les commentaires de ce fichier Bitwarden_RS__Enable_Websocket.sh pour plus            ##
## d'explications.                                                                            ##
##                                                                                            ##
##==============================================================================================

---
version: "2"

services:
  bitwardenrs:  # Voir : https://github.com/dani-garcia/bitwarden_rs
    image: bitwardenrs/server:latest
    container_name: bitwardenrs
    networks:
      - bitwarden_network
    environment:
      # Utiliser la commande (en SSH) : id NOM_UTILISATEUR
      - PUID=XXxxXX
      - PGID=XXxxXX
      - TZ=Europe/Paris

      # Pour l'envoi d'emails
      - SMTP_HOST=XXxxXX
      - SMTP_FROM=XXxxXX
      - SMTP_FROM_NAME=BlaBla
      - SMTP_PORT=XXxxXX
      - SMTP_SSL=true
      - SMTP_USERNAME=XXxxXX
      - SMTP_PASSWORD=XXxxXX

      - INVITATION_ORG_NAME=Bitwarden_RS [Votre Nom, pseudo...]   # Permet de spécifier un nom d'application pour les invitations d'organisation

      # Nécessaire pour activer le 2FA pour la connexion à notre serveur bitwarden_rs
      # Il est possible de spécifier un port de connexion dans l'URL. Le https:// est obligatoire.
      # Pour cette option, il est donc OBLIGATOIRE d'avoir fait le nécessaire pour avoir du HTTPS (certificats, reverse-proxy, ...)
      - DOMAIN=XXxxXX

      # Pour enregistrer les log avec un niveau particulier
      - LOG_FILE=/data/bitwarden.log
      - LOG_LEVEL=warn
      - EXTENDED_LOGGING=true

      # je n'aime pas les indices pour les mots de passe...
      - SHOW_PASSWORD_HINT=false

      # Pour activer la console d'administation, accessible via : https://mon.domaine.tld/admin/
      # Voir détails ici : https://github.com/dani-garcia/bitwarden_rs/wiki/Enabling-admin-page
      # /!\
      # /!\ N'importe qui pourra accéder à la page de connexion, alors blinder le token d'amdin ci-dessous (64 caractères pour moi) !
      # /!\ Il est de plus TRÈS important d'avoir ACTIVÉ le HTTPS avant l'activation de cette option.
      # /!\
      # Je conseille de ne l'activer qu'en cas de nécessité, et de la désactiver après.
      # Pour désactiver, il suffit de commenter la ligne ci-dessous.
      - ADMIN_TOKEN=XXxxXX
      # À noter :
      #   La première fois que vous enregistrez un paramètre dans la page d'administration, 'config.json' sera généré 
      #   dans votre 'DATA_FOLDER'. Les valeurs de ce fichier auront priorité sur les valeurs 'environnement'.
      
      - SIGNUPS_ALLOWED=false   # Fait en sorte que les inscriptions soient bloquées, seul l'admin pourra inviter
                                # des utilisateurs avec un envoi d'email depuis la console d'administation
                                
      - WEBSOCKET_ENABLED=true  # Active les WebSocket notifications (Nécessite la configuration du reverse-proxy)
                                # Durant le nombre importants d'essais, j'en suis venu à laisser le port par défaut
                                # pour le WEBSOCKET_PORT. Il est possible que ça fonctionne avec un port différent.
                                # Il faudra alors décommenter la ligne suivante, et changer le port exposé plus bas.
      #- WEBSOCKET_PORT=3012    # Par défaut = 3012
      
      # Pour activer la récupération des icones des IP LAN, il faut mettre sur false la variable ICON_BLACKLIST_NON_GLOBAL_IPS
      - ICON_BLACKLIST_NON_GLOBAL_IPS=false      # Par défaut = true

    labels:
      - "com.centurylinklabs.watchtower.enable=true"

    volumes:
      - "/volume1/docker/bitwarden_rs/bitwarden-data/:/data/"
    ports:
      - XXxxXX:3012   # Choisir un port libre pour le websocket
      - XXxxXX:80     # Choisir un port libre pour l'interface WEB
    restart: unless-stopped


Maintenant la deuxième partie (partie 2) qui peut ne pas être utilisée si vous ne souhaitez pas sauvegarder automatiquement la BDD : ( > Mise à jour < )

Comme précédemment, les indications sont en commentaires)
Code:
  # Sauvegarde automatique de la base de données, au-cas-où !
  bitwarden_backup:     # Voir : https://gitlab.com/1O/bitwarden_rs-backup
    image: bruceforce/bw_backup:latest
    container_name: bitwarden_backup
    networks:
      - bitwarden_network
    restart: always
    depends_on:
      bitwardenrs:
        condition: service_healthy
    labels:
      - "com.centurylinklabs.watchtower.enable=true"
    volumes:
      #- /etc/localtime:/etc/localtime:ro  # Devenu inutile sur nos Syno avec la variable d'env. TZ (voir plus bas)
      - /volume1/docker/bitwarden_rs/bitwarden-data/:/data/
      # Chemin d'accès pour stocker le backup, voir https://gitlab.com/1O/bitwarden_rs-backup#wrong-permissions
      - /volume1/docker/bitwarden_rs/bitwarden-backup:/backup_folder/

    environment:
      # Path to the Bitwarden sqlite3 database inside the container
      - DB_FILE=/data/db.sqlite3

      # Path to the desired backup location inside the container
      # - BACKUP_FILE=/data/db_backup/backup.sqlite3
      - BACKUP_FILE=/backup_folder/backup.sqlite3

      # Sets the permissions of the backup file
      # The permissions should at least be 700 since the backup folder itself gets the same permissions
      # and with 600 it would not be accessible.
      - BACKUP_FILE_PERMISSIONS=700

      # Cronjob format "Minute Hour Day_of_month Month_of_year Day_of_week Year"
      # https://crontab.guru/#0_9_*_*_*
      # minutes | heures | jour du mois | mois | jour de la semaine
      - CRON_TIME=0 18 * * *

      # Set to true to append timestamp to the BACKUP_FILE
      - TIMESTAMP=true

      # User ID to run the cron job with
      - UID=1038    # J'ai créé un utilisateur dédié à Bitwarden, utiliser la commande 'id nom_user'

      # Group ID to run the cron job with
      - GID=100

      # Path to the logfile inside the container
      #- LOGFILE

      # Path to the cron file inside the container
      #- CRONFILE

      # Delete old backups after X many days
      - DELETE_AFTER=14
      
      # If you need timestamps in your local timezone you should mount /etc/timezone:/etc/timezone:ro and
      # /etc/localtime:/etc/localtime:ro like it's done in the docker-compose.yml.
      # An other possible solution is to set the environment variable accordingly (like TZ=Europe/Berlin)
      # (see https://en.wikipedia.org/wiki/List_of_tz_database_time_zones for more information).
      - TZ=Europe/Paris


Et enfin une dernière partie (partie 3) qui est obligatoire, celle qui concerne le réseau :
Code:
networks:                                         # On indique ici de quel réseau on parlait précédement
  bitwarden_network:
    external:                                     # C'est un réseau créé en dehors du docker-compose.
      name: bitwarden_network                     # Je précise toujours un nom, car sinon ça va prendre un nom à rallonge avec
                                                  # le nom du conteneur et du réseau voulu...

Il est à préciser que ces trois parties sont à fusionner en un seul et même fichier. Je les ai séparer pour les explications.
Voir le fichier docker-compose.yml joint précédement.

2.3- Création des dossiers et du réseau

La partie explications des options à placer dans le fichier docker-compose.yml étant faite, passons à la création des dossiers sur le NAS.
Vous pouvez soit passer par DSM, soit par la ligne de commande.
Si vous optez pour la CLI, voilà les commandes à taper :
Code:
sudo -i
cd /volume1/docker
mkdir -p bitwarden_rs bitwarden_rs/bitwarden-data bitwarden_rs/bitwarden-backup
Une fois ces dossiers créés, copier votre docker-compose.yml dans le dossier /volume1/docker/bitwarden_rs.

Il faut maintenant créer le réseau. Plusieurs possibilités existent.
Soit vous passez par DSM (non expliquée ici), soit vous passez par Portainer, soit enfin via la CLI.
  • Utilisation de Portainer :
    Dans Portainer, il faut aller dans la section Networks, et ensuite cliquer sur le bouton Add Network :

    Ensuite, il suffit juste de rentrer le nom du réseau à créer (ici : ) et de bien choisir Bridge comme Driver :

    Il n'y a pas besoin de toucher au reste. Portainer choisir les IP en fonction de ce qui est déjà créé chez vous.
    ________________
  • Utilisation de la CLI :
    Pour créer le réseau bitwarden_network :
    Code:
    sudo docker network create bitwarden_network
    Si vous voulez supprimer le réseau ainsi créé, il faut taper :
    Code:
    sudo docker network rm bitwarden_network
    Au besoin, si vous voulez lister les réseeaux :
    Code:
    sudo docker network ls
    Note : Si vous avez plusieurs commandes à taper en mode root, il faut faire : sudo -i
    Et ensuite taper vos commande sans le sudo devant.



2.4- Création des conteneurs (2 méthodes)
Maintenant tout est prêt pour qu'on se lance dans la création des conteneurs.
Deux possibilités : passer par Portainer, ou bien la CLI.
  • Par Portainer :
    Il faut aller dans la section "Stacks", puis cliquer sur le bouton "+ Add stack" :

    Ensuite, on donne un nom à la stack que l'on va créer et on copie/colle le contenu du fichier docker-compose.yml créé précédemment :

    Il est également possible d'uploader ce dit fichier en utilisant le bouton "Upload" : (je n'ai personnellement jamais utiliser cette option, mais il n'y a pas de raison pour qu'elle ne fonctionne pas)


    Il ne reste plus qu'à cliquer sur le bouton "Deploy the stack" tout en bas à gauche de la page :


    Si une erreur apparait, ce sera dans le coin supérieur droit dans un rectangle rouge, essayer d'en faire une capture avant sa disparition.
    Si non, un message en vert apparait et les conteneurs seront créés :


    Vous noterez dans cette stack, il est possible de l'éditer pour la modifier avec l'onglet Editor :

    __________
  • Par la CLI :
    Avec la ligne de commande, il faut être en root (voir remarque faite précédemment à ce propos...).
    Il faut aussi être dans le dossier contenant le fichier docker-compose, sinon il faut spécifier avec un argument supplémentaire le fichier et son chemin. Je choisi la facilité : on se place dans le bon dossier :
    Code:
    cd /volume1/docker/bitwarden_rs
    sudo docker-compose up -d
    La création des deux conteneurs se fait et ils démarrent.



3- 1er lancement et sécurisation 2FA
Une fois les étapes précédentes accomplies, il faut accéder au serveur avec l'url que vous avez indiqué dans la configuration.
Si vous essayer d'accéder via l'IP LAN en http ça ne fonctionnera pas, car le HTTPS est activé, vous aurez l'erreur suivante :

Et si vous essayer toujours avec l'IP mais en HTTPS, vous aurez cette erreur :

Bref, il faut y accéder avec votre nom de domaine :

Il faut ensuite créer votre compte et vous pourrez alors créer vos mots de passe, importer depuis un autre logiciel de mot de passe...


Voilà voilà.
Reste plus qu'à sécuriser le compte avec le 2FA. Pour cela, il faut aller dans le compte :


Puis il faut choisir votre méthode. J'ai choisi de passer par une application d'authentification comme MS Authenticator, ou Authy, ou même une autre application de mot de passe comme EnPass que j'utilise aussi.
Cliquer sur le bouton Gérer de la méthode choisie :
Entre votre mot de passe maitre (celui du compte BW) :

À l'aide de l'application d'authentification, après y avoir entrer les infos (QR-Code ou Code alphanumérique), entrer le code à usage unique générer pour valider le 2FA :


Voilà, le compte est protégé :)

PS : si vous n'avez plus besoin de compte sur votre serveur, il est possible de désactiver la création des comptes.
Dans la section :
Code:
    environment:
Il faut ajouter ceci :
Code:
      - SIGNUPS_ALLOWED=false




( > Mise à jour : AJOUT < )


4- Ajout d'un script pour les notifications Websocket
Alors, après pas mal de temps de recherche, j'ai finalement trouvé comment activer les notifications Websocket et j'ai aussi compris leur utilité.
J'ai trouvé la méthode sur le forum officiel de Bitwarden_RS, où ce lien a été posté : https://gist.github.com/nstanke/3949ae1c4706854d8f166d1fb3dadc81
J'ai pris ce script, et je l'ai amélioré selon mes goûts de sureté, et d'explications (vous verrez plus bas de quoi je parle).

4.1- Explications : Pourquoi ? Comment ?

Ces notifications servent à mettre à jour automatiquement les extensions navigateurs et les clients non mobiles, donc les applications windows, macos, etc, mais pas android et iOS. Pour ces derniers OS, ce n'est juste pas possible avec Bitwarden_RS, car il faudrait passer par les serveurs de Bitwarden pour les notifications push. Et Bitwarden_RS ne peut pas le faire.

Pour activer ces notifications Websocket, il faut faire plusieurs choses. Seul ce qui suit est faisable directement depuis DSM, dans le reverse-proxy :

Lors de la création de la règle pour BitwardenRS, il faut ajouter les entêtes personnalisés suivants : (pensez à utiliser le bouton pour créer automatiquement les deux premières lignes)


Pour le reste, malheureusement il n'est pas possible de le faire depuis DSM... car bien le moteur du reverse-proxy est nginx, il n'y a pas d'interface graphique pour le faire.
Il faut faire passer /notifications/hub avec les mêmes entêtes et /notifications/hub/negotiate au conteneur. Et ça, pas moyen de le faire depuis DSM.
Il faut passer par un script qui va créer un fichier ws.locations contenant ces propriétés, et modifier le fichier de configuration /etc/nginx/app.d/server.ReverseProxy.conf afin d'inclure le fichier créé ws.locations au bon endroit, c'est-à-dire dans la section du nom de domaine pour bitwardenRS.
C'est donc un prérequis (voir les captures précédentes).
Le fichier qui sera créé ressemblera à ceci :

Il faudra adapter le script suivant pour tenir compte de votre adresse IP de l'hôte du conteneur bitwarden. C'est-à-dire remplacer 192.168.2.200 par l'IP de votre NAS.

Il est à noter que le fichier /etc/nginx/app.d/server.ReverseProxy.conf est réinitialisé à chaque démarrage du NAS, mais aussi à chaque changement dans l'interface graphique du reverse-proxy dans DSM. Il faut donc le lancer périodiquement.
Il faudra créer une tâche planifiée en conséquence.
En ce qui me concerne j'ai créé une tâche déclenchée à chaque démarrage du NAS, et une programmée toutes les 6h. Vous pouvez mettre une fréquence plus grande (toutes les 1h) ou moins, c'est selon votre utilisation du NAS et des modifications dans le reverse-proxy.
La modification du fichier ressemblera à ceci :


4.2- Comment lancer le script ?

Le script (présent dans le § suivant) doit être lancé avec 3 arguments, sinon vous aurez un beau message indiquant que vous avez fait n'importe quoi... (mais sans rien casser, j'ai bien fait les choses).
Si le script n'est pas lancé avec le bon nombre d'arguments, vous aurez ce message :


Attention, s'il y a bien 3 arguments, je n'ai pas fait de vérification, à vous de savoir ce que vous faites !
Voici quelques explications sur les arguments à placer.
  • Le premier est votre nom de domaine pour Bitwarden-RS.
  • Le second est le port déclaré dans le reverse proxy pour accéder à l'interface web : par défaut c'est 80. Il sera probablement modifié dans votre installation (voir fichier docker-compose).
  • Le troisième est le port websocket qui par défaut est le 3012. Il sera probablement modifié dans votre installation (voir fichier docker-compose).

Exemple de commande à placer dans le planificateur de tâches :
Code:
bash /volume1/docker/_Scripts-DOCKER/Bitwarden_RS__Enable_Websocket.sh mon-ndd-a-moi.tld 8001 3012

Voilà voilà pour les explications.
Il faudra le lancer une fois après avoir paramétré les tâches.

4.3- Enfin le script lui même !

Voilà le script. Attention, j'ai mis pas mal de commentaires dans le script, et que j'ai mis des lignes echo permettant d'avoir un retour d'exécution pour le log qu'on obtient.
Lisez bien les commentaire ;) (pièce jointe : Voir la pièce jointe Bitwarden_RS__Enable_Websocket.7z

Code:
#!/bin/bash
##==============================================================================================
##                                                                                            ##
##                          Script Bitwarden_RS__Enable_Websocket.sh                          ##
##                                                                                            ##
##          Source : https://gist.github.com/nstanke/3949ae1c4706854d8f166d1fb3dadc81         ##
##                                                                                            ##
##==============================================================================================
##                                                                                            ##
##   Ce script pemet de router ce qui ne peut pas être fait avec le reverse-proxy             ##
##   de DSM (Synology) pour faire fonctionner les notifications Websocket                     ##
##   Doc. Bitwarden_RS :                                                                      ##
##        Route the /notifications/hub endpoint to the WebSocket server, by default           ##
##        at port 3012, making sure to pass the Connection and Upgrade headers.               ##
##        (Note the port can be changed with WEBSOCKET_PORT variable)                         ##
##        https://github.com/dani-garcia/bitwarden_rs/wiki/Enabling-WebSocket-notifications   ##
##                                                                                            ##
##==============================================================================================
##                                                                                            ##
##                             Principe de Tâche planifier à créer                            ##
##                                                                                            ##
## Il faut lancer régulièrement le script car toutes modifications faites dans l'interface    ##
## graphique du Reverse-Proxy de DSM va modifier le fichier de configuration. Il en va de     ##
## même lorsque le NAS redémarre.                                                             ##
##                                                                                            ##
##==============================================================================================
##                                                                                            ##
##        /!\    Il faut modifier l'adresse IP en ligne 89 et 95 par l'IP du NAS    /!\       ##
##                                                                                            ##
##==============================================================================================
##                                                                                            ##
## Paramètres de lancement du script :                                                        ##
## bash /volume1/docker/bitwarden/enable_ws.sh vault.example.com 5555 5556                    ##
##                                                                                            ##
## -- vault.example.com = Nom de domaine de Bitwarden_rs (celui du Reverse Proxy de DSM)      ##
## -- 5555 = Port exposé ROCKET_PORT par Docker (Identique à celui du Reverse Proxy de DSM)   ##
## -- 5556 = Port exposé WEBSOCKET_PORT par Docker                                            ##
##                                                                                            ##
##==============================================================================================

##===========================================================================================================
##                                                                                                         ##
## Ma commande à lancer :                                                                                  ##
## bash /volume1//docker/_Scripts-DOCKER/Bitwarden_RS__Enable_Websocket.sh mon-ndd-a-moi.tld 8001 30120    ##
##                                                                                                         ##
##===========================================================================================================

LOC_DIR="/etc/nginx"
part1=0
part2=0

echo -e "\n$(date "+%R:%S - ") Script Bitwarden_RS__Enable_Websocket.sh pour activer les Notifications Websockets"

f_affiche_parametre() {
    echo "          bash /volume1//docker/_Scripts-DOCKER/Bitwarden_RS__Enable_Websocket.sh vault.example.com 5555 5556 "
    echo "                           -- vault.example.com = Nom de domaine de Bitwarden_rs (celui du Reverse Proxy de DSM) "
    echo "                           -- 5555 = Port exposé ROCKET_PORT par Docker (Identique à celui du Reverse Proxy de DSM)"
    echo "                           -- 5556 = Port exposé WEBSOCKET_PORT par Docker"
}

if [ ! $# -eq 3 ]; then
    if [ $# -eq 0 ]; then
        # Aucun paramètre n'a été fourni. On va afficher la liste de ce qui peut être utilisé.
        echo "$(date "+%R:%S - ") Aucun paramètre fourni ! Revoir l'appel du script :"
        f_affiche_parametre
    else
        echo "$(date "+%R:%S - ") Le nombre de paramètres fournis n'est pas correct ! Revoir l'appel du script :"
        f_affiche_parametre
    fi
    echo -e "$(date "+%R:%S - ") ECHEC de lancement du script !!!!!!!!!\n"
    exit 1
fi

echo "$(date "+%R:%S - ") Exécution des commandes..."


#############################################################################################################
## Début de la partie de création/modification de fichiers
##
if [ -f $LOC_DIR/ws.locations ]; then
  rm /etc/nginx/ws.locations
  part1=1
fi
echo """
location /notifications/hub {
    proxy_pass http://192.168.2.200:$3;
    proxy_set_header Upgrade \$http_upgrade;
    proxy_set_header Connection \"upgrade\";
}

location /notifications/hub/negotiate {
    proxy_pass http://192.168.2.200:$2;
}
""" >> $LOC_DIR/ws.locations


if ! grep -q "ws.locations" /etc/nginx/app.d/server.ReverseProxy.conf; then
    sed -i "/$1;/ a\ include $LOC_DIR/ws.locations;" /etc/nginx/app.d/server.ReverseProxy.conf
    if nginx -t 2>/dev/null; then synoservicecfg --reload nginx; else exit 1; fi

    part2=1     # Variable pour indiquer que cette partie a été exécutée
fi
##
## Fin de la partie de création/modification de fichiers
#############################################################################################################

if [ $part1 -eq 1 ]; then
  echo "$(date "+%R:%S - ")    -- Le fichier $LOC_DIR/ws.locations existait déjà, il a été supprimé puis recréé."
else
  echo "$(date "+%R:%S - ")    -- Le fichier $LOC_DIR/ws.locations n'existait pas, il a été créé."
fi
if [ $part2 -eq 1 ]; then
  echo "$(date "+%R:%S - ")    -- !!!!!! --->  La modification dans le fichier /etc/nginx/app.d/server.ReverseProxy.conf n'existait pas. Elle a été écrite."
  echo "$(date "+%R:%S - ")    -- !!!!!! --->  Le fichier /etc/nginx/app.d/server.ReverseProxy.conf a du être réinitialisé après un reboot ou lors d'une modification du reverse-proxy dans DSM."
else
  echo "$(date "+%R:%S - ")    -- La modification du fichier /etc/nginx/app.d/server.ReverseProxy.conf a déjà été effectuée lors d'une précédente exécution. Aucune modification n'est donc nécessaire."
fi

echo "$(date "+%R:%S - ") Script Bitwarden_RS__Enable_Websocket.sh terminé"

exit



Plus tard viendra la partie fail2ban.











________________

À venir : intégration de fail2ban pour sécuriser un poil plus, même si avec le HTTPS et la 2FA c'est déjà bien :)
 
Une mise à jour viendra d'ici quelques jours pour correspondre au changement de nom de Bitwarden_RS qui devient Vaultwarden.
@bientôt :)
 
Statut
N'est pas ouverte pour d'autres réponses.