bruno78

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

@Jeff777, content de voir en tout cas que les modifications effectuées semblent bien compatibles avec la Freebox POP. Tu sembles avoir récupéré toues les infos manquantes : disques, capteurs température et ventilo, disque, ports switch sans blocage ... Désolé pour les alias qui étaient présent dans les exemples de requetes, effectivement ils correspondent à ma Revolution. A adapter donc. Au niveau de la liste des stations, si tu le souhaites, tu peux aussi te servir du tag2 => group by tag(tag2), il te diras si tes stations sur sur le réseau "pub" (cas classique) ou sur "wifiguest" si tu l'as configuré. Si pas de "wifiguest", inutile de s'en occuper. (tu a la liste des interfaces avec "-I") A noter en particulier sur le Wifi, d'autres champs seraient disponibles : ssid, signal level, .... et tous les paramètres de réglages du Wifi, mais est-ce bien nécessaire de les remonter ici ? pour le moment je ne les ai pas intégrés. Si il y a de la demande .... Enfin toujours au niveau du wifi , pour info en décortiquant les messages de retour brut, j'ai repéré 3 types de wifi capabilities : le "2d4g" (ok notre wifi N), le '"5g" (ok notre wifi AC), .... et une 3éme catégories : le "60g" => serait-ce du futur Wifi 6 ? je ne crois pas que des box actuelles Free supportent le Wifi6 ? si ? Cdt Bruno78

@stee, @Jeff777, je vous livre enfin la version 059 du script python, basée sur l'APi V8 de FreeboxOs, qui je l'espère aura une meilleure compatibilité avec la POP (c'est fait pour). Cette version tourne depuis une petite semaine sur ma Revolution sans problème, donc je vous la livre en l'état. Des évolutions ont été faites entre autre : sur le listage des disques et partitions sur le listage des températures et ventilateur sur le listage des ports du switch A noter : que je ne saurai que trop recommander de partir d'une nouvelle base de données influxdb dédiée pour éviter des conflits de variables. j'ai observé un peu trop de timeout sur les requêtes; J'ai donc passé le time out dans le fichier de conf telegraf de 5 à 8 secondes (sachant que le polling est fait toutes les 10 secondes) Enfin et c'est une première pour moi, je tente la livraison GitHub. Ça en fera surement sourire certains, mais moi ça m'a plutôt fait souffrir pour le moment ! Merci de votre indulgence ! La livraison se trouve là : https://github.com/bruno78310/Freebox-Revolution-Monitoring.git Vous y trouverez le fichier python, le fichier telegraf.conf, ainsi que les screenshot et requêtes associées qui ont évolué, ainsi qu'un recueil de l'ensemble des paramètres (pdf) Cdt Bruno78

@stee merci stee, excellente initiative. Je vais aller chercher des tuto et explications de bases sur les principes de fonctionnement , du genre "GitHub pour les nuls", ou "Github le guide du débutant" ....

Ok. Par ailleurs, je me permets d'attirer ton attention sur les questions de sécurité, primordiales de nos jours. Il y a sur ce forum quelques incontournables Tuto. A lire sans modération [emoji16] Envoyé de mon STF-L09 en utilisant Tapatalk

Lets encrypt demande un accès au port 80, donc tu dois diriger le 80 vers le 80 .... Envoyé de mon STF-L09 en utilisant Tapatalk

Bonjour @Geoff1330, indépendemment du problème d'accessibilité (ports 80/443 ouverts et forwardés vers le NAS et acceptés par le FW, cf msg de Kramlech ci-dessus), tu as une limite de 5 demandes par semaine pour chaque domaine. Si tu as épuisé les 5 demandes, il te faudra attendre 1 semaine avant de pouvoir renouveler la demande. Cdt Bruno78

Bonjour @stee, je ne sais pas pourquoi il n'est plus disponible .... Je te rejoins donc le fichier ed058, qui est celui en cours. Nota : le fichier ed058 utilise l'api V4 de FreeboxOS. Or aujourd'hui nous sommes sur un api V8, y compris pour d'autres Freebox que la Révolution. Le script python compatible api V8 est en cours de finalisation, il devrait arriver d'ici fin de semaine (j'espère !) Donc attends toi à une mise à jour sous peu. PS : un petit passage par la case présentation sera apprécié pour connaitre tes attentes et ton matériel et tes centres d'intêrets. PS2 : un repository GitHub est en cours de reflexion .... Merci freebox_058.py

ok merci. Et ton routeur, sur le port #3, il est synchronisé à 1Gbps, ou à 2.5Gbps ?? Parce que là il dit 1Gbps, pas 2.5.

heu oui, j'aimerai bien voir le port #1 up ..... et synchronisé en 2.5G 🙂 et à ce moment là voir comment il est vu par FreeboxOS, et quel est le mode remonté par le script ?

merci @Jeff777, mais du coup le port 1 étant inactif, il est en mode 0 (10Base-T) et du coup je ne vois pas ce que cela donnerai si il y avait un équipement dessus synchronisé à 2.5G. Je ne sais pas si tu en as un à disposition ? Sinon tant pis. Merci quand même. Je pense pouvoir te transférer le script d'ici fin de semaine max. Petite info : pour reconstruire le dashboard (plus facile de reconstruire à partir de zéro), j'ai préféré utiliser une nouvelle base influxdb pour ne pas mélanger avec les anciennes mesures .... et pouvoir revenir en arrière facilement en cas de besoin. Il faut que je fasse un peu de documentation avec.

@.Shad. bonjour, oui il faudrait que je le fasse .... dés que j'aurai appris et compris comment fonctionne GitHub 🙂. Je suis total débutant sur ce sujet. Mais on est d'accord sur le principe. J'avais même créé un compte il y a quelques semaines, mais ne suis pas aller plus loin pour le moment.

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 .....