bruno78

@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$

@.Shad., @oracle7, @Jeff777, j'ai mis à jour la procédure pour installer Python dans le docker telegraf:latest avec une version actuelle 1.15.2. Voir en première page. @.Shad., merci pour le cadeau empoisonné du docker Python partageant ses librairies avec le docker telegraf 😁.... c'était, et c'est toujours, une belle idée ..... ça fait une semaine que je suis dessus et je n'y suis pas arrivé. Je ne pense pas être très loin, mais telegraf refuse d'exécuter python alors qu'il voit bien la librairie partagée. Faire un 'cat' sur un fichier partagé, pas de problème, mais dés que je veux exécuter python (qu'il voit bien), invariablement la réponse est :'this file does not exists' .... 😡 Je vais laisser reposer un peu la chose ... Cdt Bruno78

Bonjour, j'ai l'habitude de créer un répertoire pour le docker-compose, puis des dossiers individuels pour les fichiers persistants de chaque container. Mais chacun peut s'organiser comme il le souhaite, tant que les noms de volumes sont corrects dans le docker-compose. Cdt Envoyé de mon STF-L09 en utilisant Tapatalk

Bonjour @oracle7, en fait j'utilise un fichier docker-compose.yaml global pour tous les services de monitoring. Et j'y définis le réseau à utiliser ainsi que les adresses (IP et MAC (arbitraires)) de chacun des containers Docker. Le fichier ressemble à ceci : version: "2" networks: monitoring: driver: bridge ipam: driver: default config: - subnet: 172.20.0.0/29 # gateway: 172.20.0.1 # ip_range: 172.20.0.0/29 # Network .0; gateway .1 ; grafana .2; influxdb .3 ; nas_telegraf .4; fbx_telegraf .5; N/A .6 ; Broadcast .7 services: grafana: image: grafana/grafana:latest container_name: grafana hostname: grafana mac_address: d2:ca:ab:cd:00:02 networks: monitoring: ipv4_address: 172.20.0.2 ... influxdb: image: influxdb:latest container_name: influxdb hostname: influxdb mac_address: d2:ca:ab:cd:00:03 networks: monitoring: ipv4_address: 172.20.0.3 ... nas_telegraf: image: telegraf:latest container_name: nas_telegraf hostname: nas_telegraf mac_address: d2:ca:ab:cd:00:04 networks: monitoring: ipv4_address: 172.20.0.4 ... fbx_telegraf: image: telegraf:1.14.5 container_name: fbx_telegraf hostname: fbx_telegraf mac_address: d2:ca:ab:cd:00:05 networks: monitoring: ipv4_address: 172.20.0.5 ... Ça a l'avantage de fixer toutes les adresses .... Je ne me souviens pas de ce qui se passe quand on ne spécifie pas les addr MAC, mais en tout cas elles changent me semblent' ils d'une création de container à la suivante. C'est quand même assez pratique ... Cdt Bruno78

Hello, @oracle7, assez peu de place dans un 918+ pour des dissipateurs. Je peux mesurer, mais ce sera au 1/4 de mm .... Sans dissipateur et mode ventilo "calme", mes 2 SSD (Samsung SSD 970 EVO Plus 250GB) sont à 31°c au repos, et ne dépassent jamais 38/40. Pendant que les DD sont à 32°c. Bruno78

@Jeff777, non, je ne pense pas que cela change quoi que ce soit pour ton problème, malheureusement.

@MilesTEG1, oui c'est la version latest. Pas de problème pour gérer le NAS avec.

Bonjour, suite à opérations de mise à jour de mes images docker, je me suis aperçu que la dernière branche de developpement docker telegraf (la branche 1.15.x) pose problème au niveau de l'installation de Python. La procédure doit être différente, je n'ai pas encore corrigé ce point. (Par contre, il n'y a pas de contrainte à utiliser la version 1.15.2 (latest) pour le docker telegraf gérant le NAS) Pour le moment, la version max du docker telegraf pour doit donc être limitée à 1.14.5 pour y installer python pour le script Freebox. J'ai modifié le Tuto en ce sens. La modification concerne le fichier docker-compose.yaml, dans lequel on précise donc la version souhaitée au lieu de laisser "latest". services: fbx_telegraf: image: telegraf:1.14.5 container_name: fbx_telegraf hostname: fbx_telegraf Au lieu de services: fbx_telegraf: image: telegraf:latest container_name: fbx_telegraf hostname: fbx_telegraf

@MilesTEG1, Et donc je confirme qu'avec la dernière version de la branche 1.14, càd telegraf:1.14.5, pas de problème pour installer Python pour le docker telegraf gérant la Freebox. Par contre ça plante si on passe sur la branche 1.15.x Bruno78

@.Shad., oui tu as entierement raison. Même si pour le moment je ne sais pas trop comment faire cela, .... mais ce sera une bonne occasion d'apprendre Pour le moment je me concentre pour restorer un docker fbx_telegraf opérationnel. Je suis en train de le regenerer avec une version telegraf 1.14.5, la ":latest" étant une 1.15.2

@.Shad., bonjour, à propos du problème de terminal docker fermé "socket fermé", j'avais ce problème sur tous mes container Docker. Après quelques recherches, il semble que ce pourrait être dû à l'accès au DSM via ReverseProxy. Si j'accède au DSM simplement en local via son adresse IP, alors plus de problème, tous les terminaux sont fonctionnels. De toute façon, il reste toujours la solution via connexion ssh, mais sans expliquer le pourquoi, au moins le passage en connexion directe permet de contourner le problème. Techniquement parlant, je ne sais pas analyser la cause profonde .... PS : pour tenter de résoudre ce problème, j'ai procédé à la mise à jour de tous mes Docker. Tout c'est bien passé, sauf pour le Docker Telegraf pour monitoring Freebox. En fait la mise à jour est ok vers un telegraf 1.5.2, mais ensuite l'installation de Python3 pose problème. Donc si vous faites du monitoring de votre Freebox via docker telegraf, ne mettez pas à jour votre docker Telegraf pour le moment. Restez dans votre version actuelle. Il faut que je regarde le problème plus en détail. Il semble y avoir eu des évolutions dans la (les ?) dernières versions du docker telegraf.

@.Shad., c'est un peu plus problématique chez moi. A priori tous les dockers refusent cette connexion console, y compris Pihole qui lui est à jour (ce qui n'est pas forcement le cas des autres). Même pb avec Portainer (mais les container n'ont pas été installés avec Portainer, donc c'est peut-être normal ?) .... Je pense que je vais commencer par mettre tous les containers à jour. Ensuite on verra. Pour le moment, le me contente de passer par un #docker exec -it <xxxxx> /bin/bash ....