Jeff777

groupe : docker propriétaire : root C'est ça ? EDIT : mais je viens de voir que les droits étaient repassés à 0660 après le redémarrage du nas !

J'ai redémarrer le nas pour être certain de l'état des containers et là plus rien ne fonctionne. J'ai mis les droits à 0666 tout en gardant docker:root. En redémarrant le nas tous les dashboards fonctionnent à nouveau (sauf Freebox bien sûr). Par contre il est toujours impossible de ce connecter au container telegraf

oui la même. A l'instant j'ai trouvé cette piste : I have come across the information that this message is displayed when the current user's uid and gid from docker host is not mapped inside the container's /etc/passwd Edit : mais cela ne m'aide pas beaucoup🙄

J'ai fait cela, mais pour éviter une erreur dans les log de telegraf j'ai changé le groupe de dock.sock suite à la remarque d' @oracle7. J'ai mis groupe:docker et gardé propriétaire : root. Et avec cela plus d'erreur et les dashboards sont à nouveau complets. Sauf le dashboard Freebox.🙄 Je tente de refaire le tuto de @bruno78 mais là impossible de me connecter au container telegraf : Que faut-il faire ?

@molinadiaz J'ai une config avec deux nas sur le même réseau et je n'ai qu'un seul nom de domaine pour lequel je suis ns et soa. Si j'avais la possibilité de mettre l'un d'eux sur le même réseau je pense que je ferai comme toi avec un deuxième domaine. Si tu perds un nas les domaines ne sont pas affectés dans l'immédiat mais si cette situation s'éternise tes domaines vont finir par tomber à mon avis. Mon routeur ne me demande pas de DNS pour l'accès internet j'ai uniquement ceux du DHCP qui sont les adresses locales de mes nas (depuis que j'ai intégré pihole je l' ai remplacé par l'adresse du raspberry avec les adresses locales des nas en dns). Dans ton cas tu as les adresses de tes nas dans la config DHCP ce sont tes deux nas, ça c'est pour résoudre les requêtes internes. Comme dis @oracle7 les requêtes externes ne font que transiter par le routeur car elles concernent ton domaine (dans ce cas ce sont tes zones qui font autorité). Dans la config du routeur je mettrai les même redirecteurs que tu as mis dans DNS serveur FDN Clouflare etc... sinon cela risque de faire yoyo si tu mets à nouveau tes IP des nas.

@molinadiaz Quelque chose qui demeure flou. Tu utilises un nom de domaine ou deux noms de domaine. Je suppose que c'est 2 puisque tu as une zone principale sur chaque nas et une zone secondaire qui est l'esclave de la zone principale du second. C'est bien cela ? En résumé : nas1 IP1 héberge zone principale ndd1(avec ndd1 A IP1) et zone slave ndd2 nas2 IP2 héberge zone principale ndd2(avec ndd2 A IP2) et zone slave ndd1 Peux-tu nous mettre l'image de tes zones principales (en remplaçant IP et domaines par ce qui précède) ?

J'ai mis en place HSTS sur mes deux nas (dsm7, dsm6) et ça fonctionne sur les deux 😉

Bonjour@kankan

Bienvenue @graal

J'ai retrouvé le fil : C'est mieux de tout lire mais en résumé : il faut ajouter la ligne suivante au fichier .htaccess : Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" env=HTTPS , cocher les cases hsts des entrées des proxy inverses et attendre que les navigateurs soient en preloading

Je ne vois pas ce que tu veux dire. Normalement la vue WAN est paramétrée sans limite de service IP source afin de couvrir toutes les requêtes non locales et de renvoyer sur les redirecteurs en cas de non résolution par DNS serveur. Attention si tu utilises le HSTS il y a des choses à faire ! Il y a un fil récent sur le sujet. Si tu ne trouves pas je vais regarder mais là je dois m'absenter. Bonne recherche

J'avoue ne pas connaître les IP semi-fixes. Quel est ton FAI, si ce n'est pas indiscret 😉

Tu n'as pas une IP fixe. Si c'est le cas tu vas te heurter à une impossibilité au mieux ça va être instable jusqu'à bugger complètement.

Je ne connais pas le routeur TP-LINK. Mais oui je pense qu'il faut mettre les adresses publiques de tes DNS. Tu ne risques rien d'essayer en tout cas.

Bonjour @molinadiaz Tes zones publiques ne vont résoudre que les adresses sur lesquelles tu as autorité c'est à dire celles de ton domaine. Sinon ce sont les résolveurs qui vont prendre la relève. Si les sites qui ne fonctionnent pas sont extérieurs à ton domaine essaie de changer ou d'ajouter un autre résolveur. Peut-être également en IPV6. Par exemple pour FDN: Si ce sont les sites de ton domaine il faut vérifier les paramétrages des nas (zones, proxy inversés...)

Comme prévu la MàJ s'est faite cette nuit. J'ai perdu deux panneaux sur la freebox et deux panneaux sur docker. Comme ces panneaux me servent pas beaucoup je crois que je vais rester comme cela. Edit : c'est pire que cela si je ne prend que la période après la MàJ ! Finalement je vais revenir en arrière sur telegraf

Ah bon. J'ai toujours InfluxDB en 1.8 mais Telegraf en latest. Watchtower a tourné il y a 6 jours et c'est cette nuit la prochaine MàJ ! Je reste comme ça pour voir et merci pour la solution.

Bienvenue @fe9177

J'ai essayé le .p12 et le .pfx et viens d'essayer de changer l'extension .p12 en .pfx ça fait un peu cuisine mais la sauce ne prend toujours pas. Heureusement si je fais "continue" j'arrive toujours à me connecter ! Je laisse tomber.....mais j'y reviendrai .

Bon j'ai réussi à supprimer le certificat que me proposait OpenVPN (sur ma tablette : paramètres/sécurité/Effacer info d'identification.) J'ai suivi tes conseils mais il m'est toujours impossible d'installer le certificat .p12 obtenu avec openssl. J'ai lu qu'il fallait utiliser le mot de passe créé lors de la conversion en .p12. J'ai recréé le P12 plusieurs fois avec des mots de passe différents. Mais je suis à chaque fois en échec sans majuscule, sans chiffre, avec 12 caractères etc...

Bonjour à tous, J'ai trouvé une partie du problème. L'échec des tests provient de la localisation des serveurs utilisés. En effet dans les pare-feu je limite l'accès aux ports 80/443 à certains pays. Si j'autorise tous les pays tous les tests sont bons sauf le ping IPV4 qui fait du timeout. Par contre il faut toujours que j'ignore le certificat proposé qui pourtant est valide. Résolu en supprimant les certificats de mon nom de domaine du registre des certificats (executer : certmgr.msc). Le certificat n'est plus proposé. Reste le ping IPV4

Bonjour @tonejay Je viens de rentrer et je viens de me rendre compte que je t'ai mal informé. En fait, sous DSM6 j'avais deux virtual hosts qui fonctionnaient : un site wordpress et un autre assez ancien que j'avais fait avec un logiciel éditeur de site. Lors de la mise à jour vers DSM7 je n'ai pas remarqué que si ce dernier était toujours en virtual host le site wordpress ne l'était plus mais avait été transformé en "portail de serveur de paquet" : Ce qui ramène à ta question : Donc oui il faut créer ce portail.😉 Pour les droits j'ai la même chose que toi. Edit :Je précise aussi que je n'ai pas créé une entrée wordpress.ndd.ovh de reverse proxy. Cet hôte est uniquement mentionné dans le portail de serveur de paquet. Par ailleurs, je n'ai pas eu à créer de certificat pour cet hôte car j'ai une wildcard. La case HSTS ci-dessus n'est pas à cocher si tu n'as pas opté pour le preloading. Désolé de cette réaction tardive

Dans les dossiers partagés il faut l'activer 😉 Édit : je crois mais n'en suis pas certain. A moins que ce soit dans la console d'administration de Drive

Bonjour, Peux-tu confirmer que ton site WordPress est à la racine du dossier partagé web_packages ? Si c'est le cas tu peux tenter de faire un virtual host. Dans Webstation :portail de service/créer portail de service/virtual host Nom d'hôte : mon site. ndd / racine du document : web_packages/wordpress

Bienvenue @xav107