oracle7

@cotp Bonjour, Tu as là un exemple typique de la différence entre un réseau filaire Ethernet de bout en bout et un réseau hétérogène (si je puis dire) mélangeant Filaire Ethernet et CPL. Autant j'aurais compris la chute de débit entre ton PC et les NAS à cause des CPL qui doivent très largement bridé ton réseau à mon avis. Autant c'est d'autant plus bizarre pour tes NAS qui eux si j'ai bien compris sont connectés en filaire Ethernet à un même switch. Donc si tu utilises des lecteurs réseaux montés depuis le PC alors là, c'est sûr ce sont tes CPL qui te brident le débit du réseau dans sa globalité. Du coup et si tu essayait via File Station de faire le transfert direct entre NAS ? Ahhreeee 😩 . @Kramlech m'a encore grillé ! j'écris pas assez vite 🤪 Au final, je ne peux que t'inviter à réfléchir sérieusement à tirer des câbles Ethernet dans ton logement pour monter un réseau digne de ce nom et de bannir tes CPL. C'est que j'ai fait personnellement, pas sans mal certes, mais maintenant c'est le jour et la nuit et surtout depuis que j'ai fait cela, plus de problèmes de stabilité du réseau induits par les CPL et pourtant c'était du haut gamme. Cordialement oracle😉

@kroumi Bonjour, Bon eh bien je vois que tu avances, c'est bien ! Cliques sur le popup "catégories" pour afficher en petites icônes et là tu auras le détails de tous les panneaux. Peut-être un problème de droits sur ces répertoires pour ton utilisateur ? A vérifier dans DSM. Je ne comprends pas. J'ai créé sur mon PC un lecteur réseau sur un dossier quelconque dans un répertoire partagé de mon NAS. J'ai navigué dans de lecteur réseau. Ensuite j'ai déconnecté ce lecteur. Il a disparu de l'explorateur Windows tout simplement. Rien à faire de plus. Je ne t'en dis pas plus car je vois que @Kramlech viens de te répondre dans le même sens. Cordialement oracle7😉

@.Shad. Bonjour, SUPER çà marche 😄, watchtower installé (j'ai juste viré dans "volumes:" la ligne " : - ./config.json:/root/.docker/config.json qui était inutile vu que je n'utilise pas de fichier config.json. On verra à l'usage si les notifications se font bien par Mail. Merci encore pour ton aimable support. Cordialement oracle7😉

@.Shad. Bonsoir, OK merci pour ces précisions, je fais comme cela alors. Cordialment oracle7😉

@cotp Bonjour, A titre d'exemple quand je transfert du PC vers le NAS un film d'1 Go j'ai un taux de transfert moyen qui oscille entre 100 et 120 Mo/s et cela prend environ 5 à 6 sec (avec pas d'autre charge sur le réseau). Je te laisses en tirer les conclusions. Cordialement oracle7😉

@.Shad. Bonjour, Merci d'avoir pris le temps de me répondre. Donc pour faire simple si je laisse dans le fichier docker-compose.yml les options WATCHTOWER_NOTIFICATION_EMAIL_SERVER_USER et WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PASSWORD renseignées avec mon login/MdP en clair et que je restreint les droits en L/E/X (equiv chmod 0700) sur ce fichier, à mon utilisateur administrateur, cela est suffisant ? Et si Oui, du coup est-ce qu'il faut préciser " user: "UID:GID" " dans le fichier docker-compose.yml ? Cordialement oracle7😉

@cotp Bonjour, Avec le temps la sagesse fini par venir 😎 Cordialement oracle7😉

@Matt Lapatte Bonjour, Je crois que ton problème est là. Ton dynDNS n'est pas défini correctement. Il doit pointer sur "exemple.ch" et non pas "ip.exemple.ch". Dans l'état, lorsque tu tapes "fichier.exemple.ch" cela ne marche pas car ton domaine "exemple.ch" ne pointe pas sur ton dynDNS. C'est le domaine "ip.exemple.ch" qui pointe sur ton @IP externe. Dans ces conditions, il faudrait pour que cela marche, taper "fichier.ip.exemple.ch" (en voyant plus large : "xxxxx.ip.exemple.ch" pour tous tes autres sous-domaines). Tu me suis ? Cette notation "à rallonge" devient à l'usage très "lourde" et contraignante car plus de caractères à saisir avec tous les risques d'erreurs que cela engendre. Aussi il te faut reprendre ta zone DNS pour simplifier tes connexions. Je m'explique : Ton dynDNS doit être "exemple.ch" pointant sur ton @IP externe dynamique du moment (mettre en corrélation cela dans DSM pour le DDNS). Attention lors de la création du DynHOST (aux étapes 2 et 3) dans les champs "sous-domaine" veiller à bien saisir une étoile " * " et rien d'autre (voir ce TUTO) pour ne pas retomber dans le piège et bien obtenir un dynHOST du type "exemple.ch" ! Dans ta zone DNS il faut des enregistrements tels que : Aucun enregistrement "A" car tu as une @IP dynamique. (souvent OVH en rajoute un par défaut pointant sur une @IP OVH). Un enregistrement CNAME pour chaque sous-domaine que tu utilises du type "xxxxx.exemple.ch" pointant vers "exemple.ch". Tu peux aussi mettre en place un wilcard du type "*.exemple.ch" pointant vers "exemple.ch". De cette façon, alors seulement tes redirections telles quelles sont définies dans ton proxy inversé pourront fonctionner correctement. Voilà c'est pas plus compliqué. Cordialement oracle7😉

@Pinpon_112 Bonjour, Surtout prends ton temps et soit très attentif à ce que tu fait et il n'y aura aucun problème ... même si à 99% du temps les problèmes viennent de l'interface chaise/clavier 😜 Cordialement oracle7😉

@Pinpon_112 Bonjour, Il suffira juste de : Avant toutes choses, sauvegarder sur un PC/Mac : Les fichiers du certificat contenus dans "/volume1/Certs/tonDomaine.tld/" soit le répertoire "tonDomaine.tld" au complet. Les fichiers "account.conf", "acme.sh.env" et "http.header" contenus dans le répertoire "/usr/local/share/acme.sh/". Le script python "acme_renew.py" contenu dans le répertoire "volume1/Scripts". Après le changement de NAS : Réinstaller le Shell script "acme.sh" ( voir § 2 du TUTO) qui recréera notamment le répertoire "/volume1/Certs/". Restorer les fichiers du certificats donc le dossier complet "tonDomaine.tld" dans "volume1/Certs". Restorer les fichiers "account.conf", "acme.sh.env" et "http.header" dans le répertoire "/usr/local/share/acme.sh/". Restorer le fichier "acme_renew.py" dans le répertoire "volume1/Scripts". Recréer dans DSM la tâche programmée de renouvellement ( voir § 6 du TUTO). Recréer le certificat dans DSM en important les fichiers "tonDomaine.tld.key", "tonDomaine.tld.cer" et "ca.cer" issus du répertoire "/volume1/Certs/tonDomaine.tld/". (Bien penser à donner la même description qu'auparavant à ce certificat et le déclarer par défaut). Configurer le certificat pour l'appliquer à tous les services. Dans une session SSH sous root, faire un test en exécutant la commande "python|python3 /volume1/Scripts/acme_renew.py -t -l tonDomaine.tld" Analyser les fichiers log "acmelog" et "acme_renew_python.log.1" situés dans "/volume1/Certs/Acme_renew/" pour vérifier que tout est clair (ie pas d'erreurs). Voilà en espérant que je n'ai rien oublié. Cordialement oracle7😉

@kroumi Bonsoir, IL faut tout simplement le déconnecter. Pour retrouver le panneau de configuration sous WIN 10 : Là je ne sais que te dire de plus car chez moi les deux de figure marchent sans problème. Ton utilisateur a-t-il bien les droits nécessaires sur "TonDossierPartagé" ? Vérifies cela ... PS : Je viens de contrôler, cela marche aussi normalement si tu ne mets pas "volume1", donc essaies "\\NomDuNAS\TonDossierPartagé" ou "\\@IPLOcaleDuNAS\TonDossierPartagé" Cordialement oracle7😉

@.Shad. Bonsoir, OK merci pour la précision du réseau. Ok je comprend bien mais quel serait le risque de partager quand même le réseau du monitoring avec whatchtower ? Avec les options WATCHTOWER_NOTIFICATION_EMAIL_SERVER_USER et WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PASSWORD on inscrit en clair son login/MdP de messagerie. C'est pas terrible du point de vue sécurité ! N'y-a-t-il pas moyen de masquer ces derniers ? Je vois que dans la partie "volumes:" on monte un fichier config.json. Est-ce que avec ce fichier config.json (renseigné manuellement comme décrit dans la doc watchtower au chapitre "Private registries") cela peux le faire ? Si oui dans ce cas je ne vois pas bien où il faut placer ce fichier config.json ? Directement dans "/volume1/watchtower/" ? Du coup comment on renseigne les dites options suscitées ? Edit : Pour faire suite à mes questions précédentes, après avoir fouillé un peu plus la doc, est-ce que l'on renseigne les options comme ci-dessous (je suis pas du tout sûr de la syntaxe pour les variables REPO_xxxx) ? : Cordialement oracle7😉

@Octopuss45 Bonjour, A mon humble avis ton utilisateur "Octopuss45" n'a pas les droits "administrateur" suffisants. J'ai exécuté cette commande chez moi en tant que root et là aucun problèmes, j'ai le détail de la place occupée par tous mes répertoires. Cordialement oracle7😉

@.Shad. Bonjour, Merci de ta réponse. Je ne comprend pas : dans ton fichier docker-compose.yml ci-dessus, le service s'appelle "ouroboros" et le hostename "watchtower" ? le service ne devrait-il pas aussi s'appeler "watchtower" ? Sinon tu n'as pas répondu à ma question vis à vis du réseau à utiliser (point 2). Cordialement oracle7😉

@stee Bienvenue à toi sur ce forum 😀

@.Shad. Bonjour, Avant d'installer le conteneur ouroboros, pour ma compréhension j'aurais deux questions : Soit : dans le fichier docker-compose.yml d'ouroboros, on ajoute dans la partie "environnement:" une ligne du type " - MONITOR="grafana influxdb telegraf" " avec " - LABEL_ENABLE=false " (ou non définie), OU bien Soit dans le fichier docker-compose.yml de chaque conteneur que j'utilise (ex : influxdb, graphana, telegraf), on ajoute dans la partie "labels:" une ligne du type " - "com.ouroboros.enable=true" " . Ces ajouts de lignes sont exclusif l'un de l'autre. J'ai bon ? Pour le réseau à utiliser avec ouroboros, est-ce que je peux utiliser le même que celui défini pour mon monitoring global, ce qui me permettrait d'affecter une @IP spécifique au conteneur "ouroboros" ? Ce qui donnerait pour le fichier docker-compose/yml de outoboros : version: "2.1" services: ouroboros: image: pyouroboros/ouroboros:latest container_name: ouroboros network_mode: bridge environment: - CLEANUP=true - SELF_UPDATE=true - LOG_LEVEL=debug - CRON="30 1 * * *" - TZ=Europe/Paris - MONITOR="influxdb grafana telegraf" labels: - "com.ouroboros.enable=true" volumes: - "/var/run/docker.sock:/var/run/docker.sock" mac_address: d2:ca:ab:cd:00:05 networks: monitoring: ipv4_address: 172.20.0.5 restart: unless-stopped Cordialement oracle7😉

@Octopuss45 Bonjour, Non, cette solution est un dernier recours ! Changes l'@IP du PC qui te sert à te connecter au NAS et provisoirement fixes dans l'adaptateur réseau de ton PC cette nouvelle @IP (évidemment différente de celle qui subit le blocage par le NAS !!!). Attention aussi qu'elle ne soit pas déjà attribuée à un autre périphérique ... Plus tard tu pourras revenir à une @IP définie par le DHCP automatique. C'est juste le temps de te reconnecter au NAS, de supprimer les blocages sur ton @IP originelle. Cordialement oracle7😉

@Dut Surleweb Bonjour, Tu le dis toi même, aussi je crains à mon humble avis que les manipulations suivantes que tu as faites à propos du répertoire ".well-known" aient été inutiles, voire même qu'elles risquent maintenant de perturber le système du NAS. Mais c'est toi qui maîtrise ton NAS ... J'ai recherché (peut-être mal) ce répertoire dans toute ma configuration mais je n'ai rien trouvé (la chaine "well-known" n'existe nul part sur mon NAS) d'où je reste assez dubitatif sur le bien fondé de cette solution. Tu as dis précédemment que dans ta zone DNS chez ton fournisseur de domaine que le seul enregistrement présent était : " nas A 14400 @IP_de_mon_nas ". Aussi comme "nas" n'est pas un nom de domaine au format FQDN (Full Qualified Domain Name), peux-tu STP alors m'expliquer comment tu accèdes à DSM. Que tapes-tu exactement comme URL dans ton navigateur ? Je souhaiterai simplement comprendre ... Cela n'engage que moi, mais je crois que telle quel cela ne peut marcher (configuration DNS à mon sens anormale et non standard) d'où ma précédente préconisation de correction. Tu n'as pas non plus répondu à ma question du point 2 ni d'ailleurs aux dernières. Libre à toi, mais alors tu comprendras aisément qu'il soit difficile de t'aider plus avant ... Cordialement oracle7😉

@Octopuss45 Bonjour, Vu la taille de l'@IP que tu saisis (reprise dans le dernier message de non existence de l'hôte), j'ai comme l'impression quelle n'a pas le bon format ! Tu ne lui rajoutes rien en suffixe par hasard ? Elle doit être dans ton cas du style : "192.168.0.xxx" avec "xxx" valant de 1 à 254. Le port pour SSH est normalement le port 22 sauf si tu l'as modifié dans DSM à "Panneau de configuration / Terminal et SNMP / Terminal / SSH". D'ailleurs à cet endroit as-tu bien activer le service SSH ? Ton Mot de passe "root" ne doit pas comporter de caractères "exotiques" sinon cela ne marchera pas ! Que des lettres minuscules, majuscules, non accentuées et ou des chiffres le tout d'une longueur d'au moins 12 caractères (ce sont les bonnes pratiques !). Tous les autres caractères sauf le underscore "_" sont à bannir , le système Unix/linux qui est derrière DSM ne les apprécie pas du tout. Saches que tu n'attaques ici pas un système Windows qui lui est assez permissif sur ce point (quoi que). Avec DSM sur ton NAS, tu attaques un système d'exploitation Unix/linux, il n'y a pas de comparaison à faire avec Windows. Maintenant, tu peux toujours ouvrir un ticket au près du support Synology pour leur suggérer ce type d'évolution. Je serai curieux de connaître leur réponse ... Je crains que tu ne mélanges les notions. Il n'y a aucun rapport entre les groupes de stockage (qui correspondent à un disque "logique" qui lui-même regroupe un ou plusieurs disques physiques) et le fait de ne pouvoir supprimés définitivement des fichiers supprimés. Au passage, ne pas confondre non plus les groupes de stockage et les volumes. Ce n'est pas du tout la même chose. Ces derniers peuvent êtres assimilés à des partitions du disque logique suscité. Enfin comme nous te l'avons déjà expliqué précédemment @Kramlech et moi même, tout comme sous Windows, les fichiers ne sont jamais vraiment supprimés du disque. Leur référencement dans la table des matières ou table d'allocation du disque est simplement supprimé. Ils ne sont plus pris en compte. L'espace physique qu'ils occupent est rajouté à l'espace libre et ils seront ainsi écrasés en partie ou complétement lors de l'écriture d'un nouveau fichier selon la taille de ce dernier. Je t'invite à regarder en particulier le § "Principe de stockage" ainsi que tout ce Wiki pour t'en convaincre. Bonne lecture. Cordialement oracle7😉

@kerod Bonjour, Ce message est normal dans la mesure où la commande de renouvellement exécutée par le script acme.sh en interne du script Python, n'a pas aboutie. Les raisons en sont multiples. Dans ce cas, tu as dû avoir d'autres messages d'erreurs, il ne peut en être autrement. Envoies moi ton fichier acmelog complet pour analyse car là ce n'est qu'un extrait pas forcément révélateur du problème. Que dit aussi le fichier "acme_renew_python.log.1" ?, Envoies le moi STP. De plus, précédemment tu as parlé (message à l'appui) d'un problème de "consumer key". Est-il toujours d'actualité ou pas car tu n'en parles plus maintenant ? Cordialement oracle7😉

@cotp Bonjour, Les recommandations formulées par @Kramlech et @Mic13710 répondaient simplement à ta question et ils avaient tous les deux raison et leurs solutions et avis étaient bonnes. Ne vas surtout pas croire le contraire. Pour ma part, la solution que je t'avais initialement proposée, te faisait certes faire quelques manipulations en plus (dont le formatage), mais avec l'avantage de se trouver dans les mêmes conditions que si on partait avec des disques neufs (contrôlés) et un NAS Vierge. C'est tout, pas plus ... Mais attention, dans tous les cas tu aurais eu droit au contrôle de parité et à sa "lenteur" mais sûrement pas aussi long que maintenant. Cordialement oracle7😉

@kerod Bonjour, OK mais que dit précisément le log acmelog ? La raison du non renouvellement y figure certainement ... Cordialement oracle7😉

@kerod Bonjour, Ah bon ! Et quels éléments précis te permettent d'alimenter cette assertion ? Je serais curieux de les connaître. Pour ma part, il semble que le message que tu as reçu est on ne peut plus clair : Il est donc parfaitement clair que la clé CK que tu as saisie dans la variable d'environnement OVH_CK n'est pas la bonne. Et en conséquence, elle n'est pas vue valide lorsque le script "acme.sh" (exécuté en interne du script Python de renouvellement) lance les contrôles de sécurité chez OVH avant d'insérer dans la zone DNS de ton domaine les enregistrements "TXT" de challenge qui seront ensuite relus par les serveurs de Let'sEncrypt pour valider le renouvellement du certificat. Ce n'est pas plus compliqué que cela. Compares cette valeur de clé CK avec la sauvegarde de celle-ci que tu as dû sûrement faire selon les recommandations du TUTO pour t'en convaincre. Cordialement oracle7😉

@cotp Bonjour, Je vois que tu te rends compte que c'est exactement mes recommandations à faire après le contrôle, formulées lors de nos premiers échanges. Cordialement oracle7😉

@PiwiLAbruti Bonjour, OK bien vu, mes doigts ont fourchés ... 🤪 Cordialement oracle7😉