bruno78
-
Compteur de contenus
706 -
Inscription
-
Dernière visite
-
Jours gagnés
14
Tout ce qui a été posté par bruno78
-
@.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 ?
-
[TUTO] Certificat Let's Encrypt avec acme.sh & api Ovh en Docker (DSM6/7) (Update 07/09/22)
bruno78 a répondu à un(e) sujet de Einsteinium dans Tutoriels
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 -
@.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
-
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
-
@.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
-
[TUTO] Certificat Let's Encrypt avec acme.sh & api Ovh en Docker (DSM6/7) (Update 07/09/22)
bruno78 a répondu à un(e) sujet de Einsteinium dans Tutoriels
@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. -
@oracle7, oui et oui 🙂 Montage docker-compose.yaml vérifié et [[ bien en place . Cdt Bruno78
-
@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
-
@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
-
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
-
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 !
-
@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
-
@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.
-
@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
-
@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 ....
-
@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
-
@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
-
@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
-
@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
-
@oracle7, @TuringFan, valeur d'origine dans account.conf : LOG_FILE='/usr/local/share/acme.sh/acme.sh.log'
-
@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
-
avec le bon numéro de port, ça marche tout de suite mieux !! Merci
-
Bonjour @DaffY, il s'est passé un truc curieux . Voulant profiter du module imagik, j'active le profile php7.3 sur une installation WordPress (virtual host) auparavant en php7.2. Et la patatra : login wordpress refusé, pas moyen de récupérer un nouveau mot de passe. Je reviens en php7.2, est je récupère mon accès login/password habituel .... Ais-je raté une étape pour le passge de php7.2 à php 7.3 ? Merci Bruno78
-
@hieronimus, @oracle7 effectivement ma procédure "checkndd" ne prenait pas ce cas de figure en compte. J'ai fait une correction. Je vous la livre à tous les 2 en MP uniquement le temps qu'elle soit validée. Cdt Bruno78
-
Bonjour @hieronimus, c'est bizarre ! et que contient /volume1/Certs/Acme_renew/acmelog stp ? il faudrait avoir à la fois ta console (putty ou autre), acme_renew_python.log.1 et acmelog; as-tu passé cette étape qui vient juste après le lancement , la vérification du ndd, et recapitule les arguments ? -- acme_renew release : Version 1.44 Released -- 21-aout-2020 -- version Python system : Python 3.5.1 -- SYNOCERT : /usr/syno/etc/certificate -- LOCALCERT : /usr/local/etc/certificate -- ACMECERTS : /volume1/Certs -- ndd.tld : xxxxxxx.ovh -- certtype : RSA -- scriptdir : /volume1/Certs/Acme_renew -- log [-l] : True -- clean [-c] : False -- force [-f] : False -- test [-t] : False Il faut que je vérifie ma routine de vérification du ndd.tld, c'est peut-être elle qui n'apprécie pas tous les sous domaines. Je n'avais pas envisagé ce cas de figure. Je n'avais envisagé uniquement le cas de figure : Le_Domain='ndd.tld' Le_Alt='*.ndd.tld' Je regarde ce qu'il en est ... Cdt Bruno78