.Shad.

Plusieurs choses, premièrement ton fail2ban ne peut pas marcher en l'état, car il va lire les logs de /volume1/docker/bitwarden/bitwarden.log. N'oublie pas que ton conteneur fail2ban, celui de crazymax par exemple, n'a pas la moindre idée de l'existence de ce chemin. Pour qu'il ait accès aux logs de Bitwarden, il faut monter ces logs dans le conteneur fail2ban. Chez moi j'utilise la version officielle de Bitwarden, donc le chemin des logs n'est pas le même que pour toi, mais voici un exemple : C'est la config de ma jail Bitwarden dans jail.local, je dis au conteneur qu'il doit aller voir dans son arborescence dans /log/host_bitwarden.txt pour trouver les logs qui l'intéressent. C'est arbitraire, j'aurais pu lui dire de regarder dans /toto/tutu/tata.txt Et pour que ce fichier existe dans le conteneur, il faut que mon conteneur fail2ban ait monté ces logs en volume : C'est la dernière ligne qui t'intéresse. J'ai monté l'équivalent de ton /volume1/docker/bitwarden/bitwarden.log dans /log/host_bitwarden.txt Si tu as déjà défini des volumes sous DSM, je pense que tu vois comment faire. Pour les mails, pour l'image de crazy-max en tout cas, c'est assez limpide : https://github.com/crazy-max/docker-fail2ban#environment-variables Tu as juste à configurer quelques variables d'environnement. Par contre, je doute de la pertinence d'un envoi de mail à chaque blocage par fail2ban. Vu que j'ai plusieurs personnes qui utilisent mon instance Bitwarden, il est accessible directement par nom de domaine, et donc des intrus peuvent essayer de se logger, bon ils n'ont aucune chance d'y arriver, car fail2ban + authentification 2FA + restriction à la Belgique et à la France. Mais ça ne les empêche pas d'essayer et de se faire ban en masse, je n'imagine même pas le nombre de mails que je recevrais... 😄

Bienvenue parmi nous, puisses-tu continuer de trouver ton bonheur par ici !

Ce n'est pas la même version : 6.2.4-25556 contre 25554 avant.

Les problèmes d'horloge peuvent être liés à la pile CMOS de la carte mère, a vérifier mais je pense qu'il s'agit d'une bête CR2032 3V. Quant aux DNS tu peux les changer dans /etc/resolv.conf, ce sera sûrement écrasé par le système mais temporairement ça te permet de vérifier ta résolution DNS. De plus avec nslookup tu peux spécifier le DNS utilisé en ajoutant son IP à la suite du domaine interrogé. C'est très étrange que le bouton reset ne fonctionne pas, peut-être aussi lié à une pile HS ?

Bienvenue parmi nous !

Super présentation ! J'ai fait mon propre rack informatique aussi avec des LACK d'Ikea, en plus d'être fun et instructif ça claque bien. 😉 Welcome !

Bienvenue parmi nous 🙂

Et tu as bien compris, c'est @Jeff777 qui pensait que tu parlais d'un serveur de nom (nameserver ou NS) secondaire, qui n'est pas la même chose.

Si son NAS est éteint, il est coincé. S'il met un DNS secondaire, il peut continuer de résoudre publiquement. @StéphanH Par contre attention, parfois ton client voudra consulter le DNS secondaire au lieu du primaire, même si ce dernier est disponible, et dans ce cas-là la résolution locale ne sera pas fonctionnelle. Cela dit c'est assez rare.

Il te manque simplement un enregistrement A pour ndd.com qui pointe vers ton NAS. On évite de faire un CNAME depuis ndd.com vers ns.ndd.com vu que le domaine racine est généralement SoA (Start of Authority).

Attention, tu ne peux pas avoir le même sous-domaine HomeBridge pour le proxy et pour sa cible. Mais je pense que c'est une coquille, tu as effectivement saisi le principe. Prenons un exemple simple : nas.local A 192.168.0.100 rp.local A 192.168.0.100 raspberry.local A 192.168.0.101 moments.local CNAME rp.local homebridge.local CNAME rp.local Je dis que nas.local renvoie vers l'IP locale de mon NAS. Je dis que le proxy inversé rp.local peut-être joint sur l'IP 192.168.0.100, qui se trouve être celle de mon NAS. Mon proxy inversé pourrait être sur n'importe quel autre périphérique du réseau. J'ai aussi un Raspberry Pi que j'ai ajouté dans mon serveur DNS. Vu que je compte faire passer Moments et HomeBridge par le proxy inversé, je vais les faire pointer vers le proxy inversé. Pour que le proxy inversé fonctionne, il faut donc que lorsque je tape moments.local, c'est vers lui que ça aille, c'est bien le cas ici. Donc il attend gentiment sur son port 443 (par commodité, pour ne pas taper de port derrière le nom de domaine, rien n'empêche de mettre autre chose), et HO ! https://moments.local:443 => C'est pour moi ça ! Pourquoi ? parce qu'il a une entrée du type : Dans source on a bien ce à quoi il doit réagir. Dans destination, ce vers quoi il va rediriger en backend. HTTP car on a pas besoin de chiffrer entre le NAS et le NAS, le chiffrement se fait avant d'arriver au proxy inversé. Localhost car le hasard fait que le proxy inversé est sur le NAS, et que Moments, je voudrais atteindre un service du Raspberry Pi, je mettrais son IP ou raspberry.local 10004 car c'est le port personnalisé par défaut pour Moments dans le portail des applications. Pour revenir au serveur DNS, il faut bien différencier les noms qu'on lie à des périphériques (nas.local et raspberry.local) et les noms qu'on lie à des services (moments.local et homebridge.local) quand on passe par un proxy inversé... Sans proxy il n'y a pas besoin, car on se contente de mettre le nom du périphérique, suivi du port de l'application. Ici forcément ça ne suffit plus, vu qu'on interroge tout sur le même port, on différencie donc par le nom de domaine qu'on donne, et cela doit donc être inscrit dans la zone DNS.

C'est le proxy inversé qui se charge de ça. 😉

Si tu ne veux pas d'ennuis, tu retires virgules, ponctuation, espaces, majuscules, etc... Tu gardes lettres, chiffres, underscore et tiret. Linux ne te causera jamais le moindre souci avec ce formatage-là.

Je disais ça dans le sens que c'était une conséquence de modifier les enregistrements de ta zone. 😉

Si c'est effectivement une zone esclave, il n'a rien à faire, lorsque tu mets à jour ta zone, tu incrémentes le serial et si tu as coché l'option "activer la notification des zones esclaves", ça va automatiquement les mettre à jour. Enfin, sous réserve qu'il ait fait une transmission du port 53535, qui est le port utilisé par DNS Server justement pour la notification des zones. Et que tu aies autorisé son IP publique dans les paramètres de "Limiter le transfert de zone".

Hello, tu as tout à fait le droit, mais tu ne trouveras pas beaucoup d'aide concernant ton NAS en particulier. Il y a des sujets qui peuvent tout de même t'intéresser, comme la partie Docker. Tu auras sûrement un bien meilleur support sur https://www.forum-nas.fr

Sur mon DS118, ça marche bien : Pour l'unité, tu as loupé quelques échanges, il faut supprimer le 0.954, c'est en fait le coefficient de conversion de kibibytes à kilobytes, voir mon explication il y a quelques pages. Pour moi le measurement "memTotalReal" ne prend pas en compte la mémoire réservée que tu vois dans ton moniteur de ressources.

C'est typiquement le genre de chose que je préfère avoir sur un VPS ou directement hébergé par un tiers compétent. Pour l'uptime, pour la latence des requêtes extérieures vers ton serveur aussi, pour DNSSEC et principalement le fait que DNS Server est juste BIND avec une interface qui limite dans certaines possibilités de configuration (même si c'est quand même assez complet). PS : Ce n'est pas une question de sécurité, mais juste de préférence personnelle. 😉

Pas grand monde je pense, et perso j'irais jamais héberger ma zone DNS localement, même avec une IP fixe. 😛 Le tutoriel est là pour aider, les commentaires du script se suffisent selon moi.

Oh bah tu fais ce que tu veux, c'est pour m'internationaliser quand j'aurai conquis le monde !! (ou au moins une deuxième personne que toi 😄 😄)

Sur Windows, je dois définir un utilisateur pour faire cette tâche, j'imagine que sur VMWare c'est similaire. Est-ce qu'il dispose de privilèges suffisants ? C'est la piste vers laquelle ton message d'erreur oriente. Vérifie que ton utilisateur : - peut utiliser Active Backup, que ce soit via les permissions utilisateur ou de groupe. - a des privilèges suffisamment élevés pour écrire dans le dossier partagé ActiveBackupforBusiness.

Script mis à jour, notamment au niveau des entêtes et des commentaires, plus verbeux.

Interpelant en effet. Pas moyen d'échanger deux CPL (qui ne soient pas sur le même circuit) ?

En allant voir dans le centre de paquets suite à ta remarque, je viens de voir ceci dans le patch notes d'ABB (beta) : Ca avait été annoncé quelque part ? En tout cas c'est cool 😎 Actuellement j'utilise Borg Backup en lignes de commande qui est très bien fait, mais si je peux passer par ABB pour mon serveur Debian, ce serait top !

Passer par un proxy inversé permet d'avoir un seul point d'entrée, et suivant le domaine demandé (disons https://domaine1.exemple.fr) ça va te rediriger vers Dolibarr, alors que https://domaine2.exemple.fr te redirigera vers un autre site. Ca donne l'énorme avantage de pouvoir tout atteindre depuis un seul et même port, 443 par exemple par commodité. DSM intègre un proxy inversé, et il y a la fonction profil de contrôle d'accès (ACL en anglais - Access Control List) qui permet de dire si suivant l'origine, tu autorises ou pas d'accéder à cette ressource. Il suffit d'autoriser les IP privées (192.168.x.x, 10.x.x.x, etc...) et de refuser le reste, ainsi toutes les IP publiques n'y auront pas accès. Le réseau de ton serveur VPN étant également dans une plage privée, ça ne posera aucun souci. Mais je n'y connais rien à Webstation, qui permet peut-être de faire ce que tu veux, j'attire l'attention de @DaffY qui s'y connaît beaucoup plus à ce sujet.