Aller au contenu

bruno78

Membres
  • Compteur de contenus

    706
  • Inscription

  • Dernière visite

  • Jours gagnés

    14

Tout ce qui a été posté par bruno78

  1. @Einsteinium, bonjour, je viens de faire le premier domaine selon cette méthode .... c'est presque déconcertant de facilité ! Top. RDV dans 2 mois pour voir le renouvellement 🙂. Ca ma pris en gros 30min parce qu'en plus je prends note de ce que je fais ainsi que des screenshots. Sinon en 15 min c'est fait. Par contre, je n'ai pas compris comment gérer plusieurs domaines : si je demande de nouvelles clés pour un domaine suivant, il faudra mettre à jour account.conf ? Mais du coup ce ne sera plus cohérent avec le premier ? me fais-je des nœuds au cerveau ? Ou alors faut'il d'un coup créer un seul jeu de clé OVH pour tous les domaines concernés ? Merci en tout cas pour ce tuto ! Bruno78
  2. @.Shad. alors si je mets dans le resolv.conf l'adresse de mon NAS qui est serveur de nom, encore une fois tout semble normal : il ne connait pas "influxdb" il connait "google.fr" alors que si il y a 172.0.0.11, alors il sait resoudre "influxdb" et "google.fr" ... root@nas_telegraf:/etc# nslookup > influxdb Server: 127.0.0.11 Address: 127.0.0.11#53 Non-authoritative answer: Name: influxdb Address: 172.20.0.3 > google.fr Server: 127.0.0.11 Address: 127.0.0.11#53 Non-authoritative answer: Name: google.fr Address: 216.58.206.227 Name: google.fr Address: 2a00:1450:4007:80f::2003 > exit root@nas_telegraf:/etc# echo nameserver 192.168.1.171 > resolv.conf root@nas_telegraf:/etc# echo options ndots:0 >> resolv.conf root@nas_telegraf:/etc# cat resolv.conf nameserver 192.168.1.171 options ndots:0 root@nas_telegraf:/etc# nslookup > influxdb Server: 192.168.1.171 Address: 192.168.1.171#53 ** server can't find influxdb: NXDOMAIN > google.fr Server: 192.168.1.171 Address: 192.168.1.171#53 Non-authoritative answer: Name: google.fr Address: 216.58.206.227 Name: google.fr Address: 2a00:1450:4007:80f::2003 Le telegraf qui vient poller le NAS est bien sur la même machine. Si je remplace dans l'agent l'adresse du NAS par l'adresse de la passerelle (172.20.0.1), alors avec resolv.conf pointant vers 127.0.0.11, ca fonctionne bien en bridge (à condition de ne pas oublier dans le graf grafana, si on a une condition "where agent_host = ..." de mettre "where agent_host = 172.20.0.1" au lieu de "where agent_host = 192.168.1.171" si on a ce genre de conditions. => il semble donc que la solution soit bien de donner à l'agent SNMP la passerelle de reseau bridge. @MilesTEG1 oui, j'ai upgradé de DSM6 vers DSM7, ca marchait avait avec tous les dockers en mode bridge, et la ca ne veut plus. J'ai été obligé sur conseil de Shad de passer le docket telegraf en mode réseau "host"
  3. Merci, je te réponds dans la journée. Bruno78 Envoyé de mon STF-L09 en utilisant Tapatalk
  4. @.Shad., effectivement, on est moins seul ! Mon resolv.conf sur le docker telegraf (1.15.3) en mode bridge : root@nas_telegraf:/etc# cat resolv.conf nameserver 127.0.0.11 options ndots:0 root@nas_telegraf:/etc# peut-être tenter de revenir legèrement en arrière sur la version telegraf ?
  5. Bonjour @Einsteinium, avant de me lancer, j'aurai une petite question : ayant déjà 3 certificats LE acme.sh valides, je me pose la question de savoir comment les intégrer dans ce process ? Le plus simple est peut-être de les effacer/supprimer, puis de les recréer en suivant ce Tuto depuis le début ? Merci, Bruno78
  6. @.Shad. résultat du nslookup sur le telegraf mode bridge : tout a l'air normal pourtant. root@nas_telegraf:/# nslookup > influxdb Server: 127.0.0.11 Address: 127.0.0.11#53 Non-authoritative answer: Name: influxdb Address: 172.20.0.3 > grafana Server: 127.0.0.11 Address: 127.0.0.11#53 Non-authoritative answer: Name: grafana Address: 172.20.0.2 > > google.fr Server: 127.0.0.11 Address: 127.0.0.11#53 Non-authoritative answer: Name: google.fr Address: 216.58.209.227 Name: google.fr Address: 2a00:1450:4007:817::2003 > Cdt, Bruno78
  7. bonjour @.Shad., je vais faire le test de nslookup dans la journée j'espère. Pour joindre le NAS, depuis Telegraf, j'utilise l'adresse IP du NAS [[inputs.snmp]] # List of agents to poll agents = [ "192.168.1.171" ] # addr IP du NAS Bruno78
  8. @.Shad. brillantissime ! oui, avec Telegraf en "host", ca passe !! Mais du coup, qu'est ce qui a changé ? je suis passé de DSM6 à DSM7 sans toucher aux config des dockers. Tout était à l'identique. Donc ? Merci de cette piste Bruno78
  9. @Einsteinium bonjour, je dois faire partie de ceux qui ont téléchargé .... et n'ont pas encore fait de retour . Désolé, ça va venir. Tout simplement, ma migration dsm6 => dsm7 a été un peu plus douloureuse que prévue (faut d'ailleurs que je mette une synthèse à ce propos dans le fil dsm7). Je vais m'y remettre, aucun doute.
  10. @oracle7, oui et oui 🙂 Montage docker-compose.yaml vérifié et [[ bien en place . Cdt Bruno78
  11. @oracle7, malheureusement, fichier telegraf.conf remis au propre, vérifie l'absence de tabulation, vérifié l'indentation (au cas ou ...). est rien à faire .... Toujours aucune remontée d'info snmp du NAS par telegraf. Cdt Bruno78
  12. @oracle7 , Je n'ai plus le temps de regarder ce soir, mais c'est vrai que mon fichier telegraf.conf n'est pas très "propre" côté indentations. J'espère que ce n'est que cela. Je regarde ça demain. Merci. Bruno78 Envoyé de mon STF-L09 en utilisant Tapatalk
  13. Bonjour @.Shad., @Einsteinium, je ne savais pas trop où placer cette question (ici ou côté DSM7 ? ) : depuis mon passage en DSM7, il n'y a plus de remontée de données via telegraf pour tout ce qui relève du plugin [inputs.snmp]. Invariablement le même message : 2020-10-17T16:42:00Z D! [inputs.snmp] Previous collection has not completed; scheduled collection skipped 2020-10-17T16:42:00Z W! [inputs.snmp] Collection took longer than expected; not complete after interval of 1m0s Et au final rien ne remonte vers influxdb, et donc rien non plus sur grafana ! Et pourtant, toutes les commandes snmpwalk ou snmpbulkwalk, qui sont à la base du fonctionnement de telegraf, fonctionnent parfaitement lorsque lancées à la main. Ce qui ne vient pas de [inputs.snmp] fonctionne parfaitement (par exple : [[inputs.system]], [[inputs.swap]], [[inputs.mem]], ....). J'ai l'impression d'avoir tout vérifié et regardé tous les logs et toutes les traces, ... rien vu de probant ! Je sèche ... Cdt Bruno78 @oracle7, as-tu essayé de mettre directement les valeurs numériques des OID dans le telegraf.conf ? De mémoire lorsque l'on avait inclus le monitoring des UPS dans le dashboard du NAS, j'avais eu ce genre de problème ... Ce n'est qu'une piste .... Cdt Bruno78
  14. Bonjour @Jeff777, peux-tu préciser stp ce que tu entends par "je démonte et remonte" le container ? Tant qu'on ne le supprime pas et donc qu'on ne le reconstruit pas, le python est persistant dans le container telegraf. Par contre si tu as effacé ton container, pas le choix, il faut re-installer python. Par ailleurs, cela n'a rien à voir avec le Python sur le NAS (rem : en version DSM7, python 3 est intégré de base dans DSM 🙂 ) Je n'ai enregistré ma Freebox qu'une seule fois, lorsque j'ai dû la changer. D’ailleurs, si tu conserves et sauvegarde le fichier ".credentials" qui se trouve dans ton répertoire docker/fbx_telegraf/py (là où tu as le script), il te suffit de le replacer à cet endroit pour ne pas avoir à refaire l'authentification (question sécurité on repassera ....) la fois suivante .... Je ne sais pas si j'ai répondu ? Cdt Bruno78 PS : quant à installer python en dehors du Docker mais utilisable par le docker, ..... on a essayé, on s'est cassé les dents .... rien à faire !
  15. @Pinpon_112 bonjour, mais es-tu arrivé à l'écran API d'OVH ? (https://eu.api.ovh.com/createToken/), puis à te logger et entrer tes paramètres pour générer les clés ? Bruno78
  16. @Pinpon_112, on va attendre qu' @oracle7 passe par là. Je ne vois rien d'évident par rapports aux traces que je peux avoir par ailleurs.
  17. @Pinpon_112, est-ce le premier renouvellement que tu tentes ? ou en as-tu déjà fait un qui a marché ? Tu as bien utilisé le Account ID : identifiant principal de connexion chez OVH (de la forme XXXXX-ovh) et non pas l'adresse mail de ton compte ? As-tu fait plusieurs tentatives de créations de clés au départ ? Cdt Bruno78
  18. @Pinpon_112, @oracle7, je vois potentiellement ceci : [Mon Oct 5 00:00:23 CEST 2020] Please open this link to do authentication: https://eu.api.ovh.com/auth/? credentialTokenXXXXXXXXXXXXXXXXXXXXXXX [Mon Oct 5 00:00:23 CEST 2020] Here is a guide for you: https://github.com/acmesh-official/acme.sh/wiki/How-to-use-OVHdomain- api [Mon Oct 5 00:00:23 CEST 2020] Please retry after the authentication is done. Donc je conseille de suivre le lien pour (re-)faire l'authentification et retenter ....
  19. @Pinpon_112, @oracle7, si possible mets nous un lien de téléchargement en MP,ce sera le plus simple. Et anonymise le log (mais on le traitera avec soins .... :-) Bruno78
  20. @TuringFan, .... là je sèche ..... mais on est bien d'accord, tu es en véritable accès root (pas en sudo -i) (voir tout début du Tuto d' @oracle7) ?? @oracle7 .... help 🙂 Cdt Bruno78
  21. @hieronimus merci, c'est toujours bien d'avoir un retour, et encore mieux quand c'est positif. Ce correctif va donc être maintenu puisque validé. Cdt Bruno78
  22. @TuringFan bonjour, de ce que je comprends, tu avais bien hier soir recréé ton certificat, tout neuf. Pour t'en convaincre, il faut aller vérifier les dates dans /volume1/Certs/ndd.tld/ndd.tld.conf.... Mais il ne restait "plus qu'à" le déployer. Normal qu'il apparaisse qu'expiré dans DSM, puisque tu ne vois que l'ancien, mais pas le nouveau qui n'a pas été déployé. Le message est clair à l'échec du déployement : enable to authenticate / check user passowrd. Puis-je suggérer que pour la durée du test, quelques minutes, tu définisses un mot de passe simple ? genre "leschemisesdelarchiduchesse", tu le mets dans un fichier texte, puis tu ne t'en sers que par copie/coller. D'où pas de risque d'erreur. Il faut tordre le coup à ce problème d'authentification. Et ne pas oublier ensuite de revenir à un mot de passe FORT. Cdt Bruno78
  23. @oracle7, @TuringFan, valeur d'origine dans account.conf : LOG_FILE='/usr/local/share/acme.sh/acme.sh.log'
  24. @TuringFan, @oracle7, je vais peut-être enfoncer des portes ouvertes, désolé, mais ne suivant ce pb que de loin ... est-ce que le répertoire ./Acme_renew existe ? est-ce que le fichier ./Acme_renew/acmelog existe ? quelle est la valeur de la variable LOG_FILE dans le fichier /usr/local/share/acme.sh/account.conf Merci
  25. avec le bon numéro de port, ça marche tout de suite mieux !! Merci
×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.