bruno78

Bonjour @Jeff777, ca y est, les dashboards basés sur l'API V8 sont en place depuis hier. Je vais laisser tourner un peu et voir si il y a des ajustements à faire. Par contre, pourrais-tu stp , depuis une console ssh sur le docker telegraf qui gère ta box, lancer la commande " python3 freebox_058.py -S ". ? => je voudrais savoir quelle est la valeur donnée par la POP pour le champ "mode" du port #1 (celui qui est 1G/2.5G). Sur la Revo, on a : 0=> auto, 1=> 10Base-T, 2=> 100Base-T, 3=> 1000Base-T. Et accessoirement, comment est décrit ce port sur le FreeboxOS ? Merci.

@kerod@oracle7, Parfait. On attend donc l'analyse du fichier log par @oracle7 Je reste à l'écoute .... PS : @kerod : si je peux me permettre, stp, lorsque tu anonymises, plutôt que de laisser un blanc à l'emplacement des valeurs masquées, mets plutôt quelque chose du genre "ndd.tld", ou "xxxx.yyy", ... . Cela permet de savoir qu'il y avait bien un paramètre et qu'il a été masqué, plutôt que de croire que le paramètre est manquant. Dans l'exemple de ton début de log, la ligne "--ndd.tld : " => ma première réaction a été de dire "tiens il manque un paramètre, curieux !" Puis je me suis dit "non c'est ok, il a simplement été masqué". Merci

@oracle7, @kerod, bonjour, chemins en "dur" : dans le script Python, et depuis le début, sont en "dur" les 2 variables SYNOCERTS = "/usr/syno/etc/certificate" & LOCALCERT = "/usr/local/etc/certificate". Aucune raison de les changer. Ceci dit si vous avez fait une installation "exotique" de acme.sh, il faudra mettre à jour dans le fichier Python. Mais ce cas ne devrait pas arriver (ou alors pour de bonnes raisons qu'il faudra m'expliquer) troisième chemin : ACMECERT. On va chercher sa valeur dans le fichier géré par acme.sh (variable CERT_HOME dans le fichier) : /usr/local/share/acme.sh/account.conf. Typiquement, ACMECERT vaut /volume1/Certs). Si tu lances un test à blanc, tu dois voir en début de log les lignes suivantes: -- SYNOCERT : /usr/syno/etc/certificate -- LOCALCERT : /usr/local/etc/certificate -- ACMECERTS : /volume1/Certs sauf erreur de ma part, il n'y a pas eu d'évolution sur ces chemins dans les différentes versions du script (dans les toutes premières versions, ACMECERTS était codé en dur me semble t'il, mais à cette même valeur. Lancement de la commande acme.sh ... pour renouveler le certificat : avant de lancer la commande de renouvellement, on exporte systématiquement les 4 variables d'environnement suivantes : os.environ["SYNO_Create"] = "1", os.environ["SYNO_Username"] = SAVED_SYNO_Username, os.environ["SYNO_Password"] = SAVED_SYNO_Password, os.environ["SYNO_DID"] = SAVED_SYNO_DID Ces variables sont récupérées dans le fichier de configuration du domaine, soit ACMECERTS/ndd.tld/ndd.tld.conf, càd en clair : /volume1/Certs/ndd.tld/ndd.tld.conf le corolaire qui en découle : à aucun moment la clé CK n'est traité par le script Python. => seul acme.sh traite cette clé (comme bon lui semble) Dans le log du script Python, effectivement on indique "nouveau certificat par défaut: xxxx" même si il n'a pas été renouvelé, et dans ce cas on ajoute comme tu l'as vu la précision "le certificat n'a pas été renouvelé". Je vais modifier la formulation pour être plus clair. Mais ça veut dire clairement que le certificat par défaut est toujours le même après qu'avant, que acme.sh ne l'a pas renouvelé pour quelque raison que ce soit. l’échec que tu constate est dû à acme.sh, pour une raison qu'il reste à déterminer. Et pour cela un log complet acmelog serait très utile. Enfin expérience personnelle avec acme.sh et la clé CK : il m'est déjà arrivé que l'authentification soit refusée pour de multiples raisons : a) clé mal recopiée (ça arrive, mais si cela a fonctionné une première fois, elle doit être bonne), b) durée de validité expirée auprès d'ovh. Dans ce cas dans le acmelog il y a un lien demandant de se re-authentifier. Il suffit de le suivre et c'est bon. c) enfin, et cela m'est arrivé aussi, sans rien changer ça ne marche pas au premier essai mais ça fonctionne au second sans n'avoir rien touché !!! frustrant mais c'est comme ça (pb chez ovh ? surcharge ? temps de réponse ? ....) Voilà ce que je peux te dire avec les éléments des posts précédents. En cas de nouvel echec, merci de nous envoyer (en MP de préférence et anonymisés si tu le souhaites) les logs complets acmelog et acme_renew_python.log.1 Cdt Bruno78

@Jeff777, merci pour l'info, c'est plutôt une bonne nouvelle, car je ne comprenais pas d’où cela pouvait venir sinon. Dans la version 059, outres les paramètres qui ont changé de place dans l'arborescence des données (températures, ventilo) , j'ai essayé d'être plus propre, et donc mieux compatible, dans le soft => par exemple pour les ports, lister les ports avant de faire une interrogation dessus, pour éviter de coder "en dur" 4 ports à examiner et de se planter avec la POP qui n'a que 3 ports ..... Idem pour les réseaux (pub, guest, ...) , les disques, les réseaux wifi, etc .... ça devrait donc permettre d'augmenter la compatibilité. Mais ça va peut-être compliquer un peu les requêtes Grafana, c'est pour cela que je veux valider un dashboard complet avant de lâcher le script. => après il faudra que tu valides sur la POP ....

🙄 je suis aussi en python 3.7.3 root@ds918blam:~# docker exec -it fbx_telegraf /bin/bash root@fbx_telegraf:/# python3 -V Python 3.7.3 root@fbx_telegraf:/# root@fbx_telegraf:/usr/local/py# python3 freebox_058.py -r Already registered, exiting root@fbx_telegraf:/usr/local/py# c'est normal ça ??? "temporary failure in name resolution" As-tu recréé le docker fbx_telegraf de zéro ? et re-installé python ? tu es toujours avec la version telegraf:latest ? je suis en telegraf:latest, ce qui me donne une version 1.15.2. Mais je vois sur DockerHub qu'il y a une 1.15.3 ... ? pas testée de mon côté.

@Jeff777, ok pardon je n'ai pas été précis. Il ne faut pas le lancer depuis le script telegraf. Il faut se connecter sur le docker freebox_telegraf, et lancer la commande à la main. depuis un terminal en ssh sur le nas root@ds918blam:~# docker exec -it fbx_telegraf /bin/bash root@fbx_telegraf:/# cd /usr/local/py root@fbx_telegraf:/usr/local/py# python3 freebox_058.py -h usage: freebox_058.py [-h] [-s] [-r] [-n app_name] [-i app_id] [-d device_name] [-f format] [-e endpoint] [-S] [-P] [-H] [-D] [-L] [-W] [-I] [-X] optional arguments: -h, --help show this help message and exit -s, --register-status Get register status -r, --register Register app with Freebox API -n app_name, --appname app_name Register with app_name -i app_id, --appid app_id Register with app_id -d device_name, --devicename device_name Register with device_name -f format, --format format Specify output format between graphite and influxdb -e endpoint, --endpoint endpoint Specify endpoint name or address -S, --status-switch Get and show switch status -P, --status-ports Get and show switch ports stats -H, --status-sys Get and show system status -D, --internal-disk-usage Get and show internal disk usage -L, --lan-config Get and show LAN config -W, --wifi-usage Get and show wifi usage -I, --lan-interfaces Get and show lan interfaces -X, --interfaces-hosts Get and show interfaces hosts root@fbx_telegraf:/usr/local/py# Ceci dit, l'erreur que tu as, montre qu'il n'y a pas de timeout, mais simplement que le résultat du "-h" n'est pas au format attendu par influxdb, ce qui est normal. Donc c'est bien la communication avec le freebox qui est cassée. Je pense donc qu'il faut vérifier l'association de l'appli avec la freebox, et le cas échéant la refaire. Cdt Bruno78

@Jeff777, pour le 059, tous les essais sont OK depuis le shell fbx_telegraf, en lançant les commandes python à la main. Il me reste à vérifier que l'intégration dans un dashboard est également OK et qu'il n'y a pas d'effet de bord. D'ici 1 jour ou 2 ce devrait être OK.

Bonjour @Jeff777, sans argument, le script va quand même chercher les paramètres "box". Si dans le même temps tu fais l'essai avec "-h" (affichage du help SANS aller chercher quoi que ce soit sur la box) et que là ça fonctionne, alors je suggère de vérifier l'authentification de l'appli sur la box. Le fichier ".credentials" est'il toujours présent dans /usr/local/py ? Pour info, j'ai presque terminé une version "059" entièrement basée sur l'api V8. En fait c'est terminé, mais je n'ai pas fini les tests .... Je pense que pour la POP tu retrouveras (presque ?) tous les paramètres manquants .... mais je ne serais pas en mesure de tester sur une POP avant de le livrer .... Je ne pourrai que guarantir que c'est bon sur une Révolution. Et effectivement, certains paramètres ont changé de localisation entre la V4 et la V8 ..... Cdt Bruno78

@Jeff777 bonjour Jeff777, ça avance ! Pour en avoir le cœur net, j'ai pris une trace entre l'application Freebox-OS sur un PC et la Freebox => c'est bien la version V8 de l'API qui est utilisée ! Donc il n'y a pas à tortiller, c'est celle là qu'il faut arriver à faire fonctionner. En modifiant le script Python, j'ai commencé à récupérer les nouvelles structures de données V8. Certaines (beaucoup) n'ont pas bougé, mais d'autres sont nouvelles ou ont évolué (comme par exemple et au hasard les capteurs de température, le disque dur, .... ) . C'est un peu long et fastidieux, mais je pense que l'on va progresser. Dés que j'ai quelque chose d'un peu abouti, je te le transmets. Bruno78

Bonjour @Jeff777, sans connaitre le nom des variables internes utilisées, ca va être compliqué. Pour le CPU par exemple, les variables remontées sur une Revolution sont "temp_cpub" et "temp_cpum". Si tu me dis que sur la POP elles s'appellent temp1 et temp2, on peut essayer un script avec les paramètres "temp_cpu1" et "temp_cpu2" .... mais c'est de la pêche à la ligne. On ne ferait que tenter de deviner. Pas top ! Idem pour le disque et le Wifi, comment connaitre le noms interne des paramètres ? Je vais regarder s' il n'y a pas moyen d'avoir une requete d'interrogation qui remonterait la liste des paramètres accessibles ... Je vais tester cela avec un script dédié. Si ca fonctionne, je te passerai la main. A suivre.

.... c'est frustrant .....

@Jeff777, je n'avais pas fait attention, mais en regardant ton résultat Grafana précédent, on voit bien que le résultat du -S donne 3 ports (link#1, link#2 et link#3) ! Donc pour le -P, je pense qu'avec la modification énoncée ci-dessus ( for i in [1, 2, 3] ), ça peut le faire. Si ok, il faudra que je change le code pour rendre cette différence de configuration physique transparente pour l'utilisateur. Bruno78

@Jeff777 , du coup j'ai un test à te proposer (mais c'est vraiment en désespoir de cause !) : à la ligne 535 du script python freebox_058.py, puisqu'il n'y a que 3 ports, faire le test de remplacer : for i in [1, 2, 3, 4]: par for i in [1, 2, 3]: Qu'en penses-tu ? Bruno78

Bonjour, l'argument "-P" va chercher les compteurs sur chacun des 4 ports du switch d'une Fbox Revolution. Pour cela, il adresses les url api_url = '%s/switch/port/%s/stats' % (ENDPOINT, port) c'est à dire http://mafreebox.free.fr/api/v4/switch/port/1/stats http://mafreebox.free.fr/api/v4/switch/port/2/stats http://mafreebox.free.fr/api/v4/switch/port/3/stats http://mafreebox.free.fr/api/v4/switch/port/4/stats Pour chaque port, on reçoit : Tx bytes Rate, Rx Byte Rate, et TX bytes. Ca c'est pour la Fbox Revolution qui a 4 ports 1G. Or si je ne me trompe, la POP possède 3 ports (1*2.5Gbps et 2*1Gbps). Il y a donc fort à parier que l'url permettant de récuperer ces stats soit différente. Mais de là à savoir laquelle est-ce ????? Je n'ai pas encore trouvé l'information ....

@Jeff777, oui, sans argument, tu obtiens un état "de base". Ensuite chaque argument ajoute des infos supplémentaires. Mais là, sans documentation précise sur la POP, ca va être coton de progresser. Je ne sais pas si il existe un moyen de "découvrir" les paramètres accessibles ? Si nouvelles idées .... Cdt

@Jeff777, finalement, avec cette url "v8", il me manque des données (temp, system fan, ...). Je reviens donc à la v4 qui doit être plus en accord avec mon matériel. Tiens nous au courant de ce que cela donne pour la POP. Cdt Bruno78

@Jeff777, là j'ai peur de ne pouvoir aller au delà. On est tributaire de ce qui est implémenté, ou pas, dans la Fbox POP, même si on est sur la même version d'API. Dans mon script Python, on utilise de base l'url suivante : ENDPOINT="http://"+args.Endpoint+"/api/v4/" Or en cherchant sur le net, je suis tombé sur ce post (https://community.jeedom.com/t/freebox-pop-appareils-connectes-ne-fonctionne-pas/34054) concernant certes Jeedom, mais l’intéressant c'est qu'ils semblent utiliser l'url de base : mafreebox.free.fr/api/v8/lan/browser/pub([]). => donc j'ai quand même l'impression qu'on ne va pas taper au même endroit. Ceci dit, les équipements connectés, je vais bien les chercher dans /lan/browser/ .... => visiblement la POP avait un problème, corrigé en V4.2.4, or je vois que tu es déjà en 4.2.5 .... .mais c'est juste pour dire que la POP est encore "un peu jeune" peut-être côté software. => si j'étais joueur et que c'était mon matériel, j'irai modifier la ligne 902 du script python pour remplacer ENDPOINT="http://"+args.Endpoint+"/api/v4/" par ENDPOINT="http://"+args.Endpoint+"/api/v8/" ..... Après, tu ne risques pas grand chose à faire le test .... . => je viens de le faire chez moi (v4=>v8) face à la Révolution, et cela semble OK (quelques tests basiques)). Je pense que ça vaut le coup d'être tenté ! Cdt Bruno78

Bonjour @Jeff777, on commence à apercevoir une petite lueur au bout du tunnel ! Mais j'ai malheureusement l'impression que l'on se trouve devant une évolution de l'API de la Freebox ! si on lance le script python sans argument, on accède aux tags "python" et "box", qui donnent entre autre la version du script, le nom du script, et les infos "box" (addr IP, debit, type xdsl/ fibre ..) l'otion -S donne l'etat du switch -H l'état global de la Freebox dans un premier temps, je conseillerai de lancer à la main le script python avec 1 seule optionà chaque fois, pour les tester toutes une à une, et voir ce qui remonte ou pas. Pour info, peux-tu également te connecter à ta Freebox avec l'url suivante : http://mafreebox.freebox.fr/api_version cela devrait donner la version d'api en service sur la Fbox POP. POur info, sur ma Révolution , j'ai ceci : Cdt Bruno78

Bonjour @Pommefrais3 en fait l'erreur doit se trouver au-dessus, dans les nombreuses lignes de log. Peux-tu nous faire parvenir le log complet (en MP si tu le souhaites à @oracle7 et à moi même ??) Merci Bruno78

Bonjour @Jeff777, je me demandais effectivement si la situation avait évoluée. Là tu as clairement un problème d'authentification entre fbx_telegraf et influxdb. Je voudrais juste récapituler car je ne suis plus certain de ta configuration: 1 seul docker telegraf pour le nas et fbx POP ? dans le telegraf.conf, tu as donc le output plugin : urls = ["http://influxdb:8086"] database = "fbx_telegraf" database_tag = "" skip_database_creation = true retention_policy = "" write_consistency = "any" timeout = "30s" username = "fbx_telegraf" password = "fbx_telegraf" Sur influxdb, cette database existe bien et avec les bons users/password ? pour le(s) NAS et routeurs dont le monitoring fonctionne, est-ce la même instance d'influxdb ? si oui est-ce la même base sur influxdb ? On est bien d'accord que si tu lances la commande Python freebox_058.py .... depuis un terminal telegraf, cela fonctionne et tu recupères bien les données de ta Fbox ? as-tu la possibilité d'avoir plus d'info sur l'erreur remontée par le script python ? Désolé si je reviens sur des points déjà abordés ... . Bruno78

Bonjour @TuringFan, je pense effectivement qu'il sera plus simple de repartir du début sur de bonnes bases, et de valider chaque étape. Là j'avoue que je ne sais plus très bien ce qui est validé ou pas dans ton installation. Donc difficile de voir ce qui ne colle pas .... Surtout bien faire attention aux problèmes de droits (=> connection root), aux clés générées chez OVH, ..... Bon courage Bruno78

Bonsoir, @oracle7 @TuringFan, 1) comme nul n'est à l'abri d'un bug, j'ai revérifié le script Pyhton. Le seul endroit où on traite le fichier account.conf, c'est entre les lignes 27 à 34. On ouvre le fichier en lecture seule ('r'), on le lit et on le referme immédiatement : on en extrait la valeur du CERT_HOME # ACMECERTS a aller chercher dans /usr/local/share/acme.sh/account.conf CERT_HOME='/volume1/Certs' fichier = "/usr/local/share/acme.sh/account.conf" f = open(fichier, "r") account = f.readlines() f.close() for ligne in account: if "CERT_HOME" in ligne : ACMECERTS = re.findall('\'(.*?)\'', ligne)[0] Je ne vois pas comment le script pourrait altérer ce fichier. 2) pour le problème de date, @oracle7 a je pense raison. Le certificat a dû être créé, mais non déployé ??? Il va falloir utiliser le -f pour forcer le renouvellement. Mais attention à la limite des 5 demandes / semaine ! Il faut vraiment vérifier que tout est d'équerre avant de relancer une tentative. Cdt Bruno78

Bonjour @oracle7, @TuringFan, le lancement avec "-l" indique le log du script acme.sh. dans /volume1/Certs/Acme_renew/acmelog . Le script Python genère lui, de toute façon, un log /volume1/Certs/Acme_renew/acme_renew_python.log.x [x de 1 a 9]. effectivement, pour lancer avec python3, il faut executer python3 .... . La commande python pointe toujours sur Python2 enfin, d’après les extraits que tu donnes, la demande de renouvellement a bien été faire, et l'erreur se tropuve donc dans le log du script acme.sh, donc dans le fichier /volume1/Certs/Acme_renew/acmelog c'est ce fichier qu'il faut examiner de plus pret pour savoir pourquoi il a planté. il faudrait le log acmelog complet. Cdt Bruno78

@oracle7, ça me parait bien pour grafana, si ton user est bien "1030" .

Bonjour, @oracle7, ayant mis à jour tous mes dockers récemment, le renouvellement de Grafana n'a posé aucun problème. Comme l'a dit @.Shad. commencer par vérifier le user => uid. volumes: - "/volume1/docker/monitoring/grafana/data:/var/lib/grafana" user: "1026" "1026" étant l'Id du user qui va utiliser grafana, pour moi mon user admin personalisé. Pour obtenir cette référence => # id <utilisateur> Bruno78 PS pour compléter les droits sur /var/lib dans grafana : bash-5.0$ ls -lisa total 0 738 0 drwxr-xr-x 1 root root 40 Aug 25 09:01 . 733 0 drwxr-xr-x 1 root root 86 Aug 25 09:01 .. 739 0 drwxr-xr-x 1 root root 0 May 29 14:20 apk 706381 0 drwxr-xr-x 1 1026 users 40 Sep 9 06:10 grafana 740 0 drwxr-xr-x 1 root root 0 May 29 14:20 misc 741 0 drwxr-xr-x 1 root root 0 May 29 14:20 udhcpd bash-5.0$ cd grafana bash-5.0$ pwd /var/lib/grafana bash-5.0$ ls -lisa total 2512 706381 0 drwxr-xr-x 1 1026 users 40 Sep 9 06:10 . 738 0 drwxr-xr-x 1 root root 40 Aug 25 09:01 .. 706933 2512 -rwxr-xr-x 1 1026 root 2572288 Sep 9 06:10 grafana.db 706932 0 drwxr-xr-x 1 1026 root 88 May 27 06:12 plugins 707168 0 drwxr-xr-x 1 1026 root 0 Mar 13 14:33 png bash-5.0$