.Shad.

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.

Je te propose une solution, mais pas un premier choix, c'est de passer par un proxy inversé avec un profil de contrôle d'accès. Mais je pense que d'autres trouveront un moyen de te permettre de choisir sur quelle interface est exposée Dolibarr (peut-être via les hôtes virtuels de Webstation ?).

Merci de dégrossir le travail, je t'avoue que je n'ai pas le temps de m'y pencher pour le moment. Pour les nouveautés, elles sont surtout l'air de se situer au niveau de la visualisation directe des métriques depuis InfluxDB : https://www.influxdata.com/blog/introducing-the-next-generation-influxdb-2-0-platform/ Il faut reconnaître que ça claque quand même. 😉 Ils insistent aussi sur le fait qu'on peut créer des tâches pour travailler directement sur les métriques stockées. Je pense que ça vaudra le coup d'y passer, je pense commencer à y regarder d'ici quelques semaines.

Welcome !

Bienvenue parmi nous !