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. @oracle7 je fais simplement des mapping id <=> value dans grafana
  2. @.Shad. en capture speedtest je peux te proposer celui-ci ? (le dernier, synchro Fbox, ne vient pas de speedtest bien sur).
  3. @oracle7, j'ai inclus le fichier xml contenant la liste des serveurs de tests juste pour info. Je n'ai pas eu le temps de voir si on pouvait l’intégrer "automatiquement" dans le code du dashboard. Je mets à jour à la main dans grafana le mapping serveur_id => sponsor lorsqu'un nouveau serveur est utilisé. En quelques jours, mon speedtest a utilisé 7 serveurs différents. Le contenu est sous la forme suivante : <server url="http://lafibre.info/pingtest/speedtest/upload.php" lat="45.7597" lon="4.8422" name="Lyon" country="France" countrycode="FR" sponsor="LaFibre.info" sponsorurl="http://lafibre.info/" id="2023" gid="0" url2="http://lafibre.info/pingtest/speedtest/upload.php" bigsamples="1" /> Le docker speedtest de son côté remonte les champs suivants : [{ 'measurement': 'speed_test_results', 'fields': { 'download': 829307849.259161, 'upload': 474337693.37657595, 'ping': 6.907, 'server': '24215', 'server_name': 'Paris' }, 'tags': { 'server': '24215', 'server_name': 'Paris', 'server_country': 'France' } }] Remarque : sur le net, on trouve plusieurs fichiers censés lister ces serveurs, .... aucun n'est exhaustif .... il faudra donc faire son marché si on souhaite récupérer des champs supplémentaires. Au lieu du "sponsor", on peut aussi vouloir récupérer l'url du serveur ...
  4. @.Shad. oui mais là je ne suis absolument pas à l'aise ... mais tu as raison sur le fonds
  5. @oracle7, Aie ... j'en déduis que tu ne l'avais pas fait avant ? Sinon la procédure (de mémoire) : influxdb -username 'admin' -password 'admin' create database speedtest use speedtest create user speedtest with password 'speedtest' grant all on speedtest to speedtest
  6. Attention, on ne modifie pas les paramètres de Wordpress à la légère, et en particulier aller directement dans la base MySQL n'est pas une bonne idée a priori car le risque de créer des incohérences est grand. Par exemple, lorsque l'on veut changer de domaine, on passe par des plugin d'export / import / migration. Ce n'est peut-être pas là ton problème, mais prudence ! je n'ai pas vu si tu avais indiqué être ou ne pas être derrière une LiveBox 4 ... ?
  7. @oracle7, oui la mise à jour watchtower ne fonctionnera pas ici. Mais comme j'ai dit à Jeff777, ce n'est pas comme si elle était mise à jour toutes les semaines. Et effectivement, si mise à jour de l'image de base, alors il faut juste refaire le docker build .... => mais cela suppose que les modifications faites dans l'image de base ne ruinent pas ma modif .... Je dirai donc qu'en cas de modification de l'image de base, il ne faudra pas trop se précipiter ....
  8. Mode d'emploi pour utiliser speedtest sans usr/pwd admin d'influxdb Prérequis : une database dédiée configurée sous influxdb, avec son user/pwd dédié. Télécharger le fichier speedtest2.tar (à la fin du message). Il contient : Dockerfile : fichier de commande pour générer la nouvelle image InfluxdbSpeedtest.py : fichier de lancement du test, très légèrement modifié (on fait un simple 'ping' de la base influxdb) SpeedTest_Net_Server_List.xml : en prime la liste des serveurs utilisés, avec leurs identifiants. Pour amélioration du dashboard grafana (source github) Etat avant modification : image root@ds918blam:/volume1/docker/speedtest# docker image ls REPOSITORY TAG IMAGE ID CREATED SIZE ... atribe/speedtest-for-influxdb-and-grafana latest 99c2c10d1e41 16 months ago 111MB ... container root@ds918blam:/volume1/docker/speedtest# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES ... bc4340b44afd atribe/speedtest-for-influxdb-and-grafana:latest "python -u /src/infl…" 3 days ago Up 43 hours speedtest ... On arrete le container speedtest en cours root@ds918blam:/volume1/docker/speedtest# docker stop speedtest speedtest On construit la nouvelle image /!\ ne pas oublier le "." (point) à la fin de la commande /!\ root@ds918blam:/volume1/docker/speedtest# docker build -f Dockerfile --rm --tag speedtest2 . Sending build context to Docker daemon 959kB Step 1/2 : FROM atribe/speedtest-for-influxdb-and-grafana:latest ---> 99c2c10d1e41 Step 2/2 : COPY ./InfluxdbSpeedtest.py /src/influxspeedtest/ ---> 08847e4b7b5e Successfully built 08847e4b7b5e Successfully tagged speedtest2:latest on vérifie que l'image speedtest2 a bien été créée (on a toujours l'ancienne) root@ds918blam:/volume1/docker/speedtest# docker image ls REPOSITORY TAG IMAGE ID CREATED SIZE speedtest2 latest 08847e4b7b5e 15 seconds ago 111MB ... atribe/speedtest-for-influxdb-and-grafana latest 99c2c10d1e41 16 months ago 111MB ... on met à jour le docker-compose.yaml pour prendre en compte cette nouvelle image root@ds918blam:/volume1/docker/speedtest# cat docker-compose.yaml version: "2.1" services: speedtest2: image: speedtest2:latest container_name: speedtest2 volumes: - ./config.ini:/src/config.ini restart: unless-stopped mem_limit: 256M network_mode: bridge on met à jour le fichier config.ini pour modifier le user/pwd à utiliser root@ds918blam:/volume1/docker/speedtest# cat config.ini [GENERAL] # Duree en secondes entre deux mesures # Delay = 3600 Delay = 10800 [INFLUXDB] Address = xxx.xxx.xxx.xxx Port = 8086 Database = nas_speedtest #Username = admin #Password = admin Username = speedtestuser Password = speedtestpwd Verify_SSL = True [SPEEDTEST] # Leave blank to auto pick server Server = [LOGGING] # Valid Options: critical, error, warning, info, debug Level = debug On peut enfin lancer le nouveau container avec la nouvelle image : root@ds918blam:/volume1/docker/speedtest# docker-compose up -d Creating speedtest2 ... done on attend une petite minute et on vérifie que tout est en place : root@ds918blam:/volume1/docker/speedtest# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 498d69abfe03 speedtest2:latest "python -u /src/infl…" About a minute ago Up About a minute speedtest2 ... root@ds918blam:/volume1/docker/speedtest# docker logs speedtest2 Loading Configuration File config.ini Configuration Successfully Loaded 2021-01-07 13:22:38,148 - DEBUG: Testing connection to InfluxDb using provided credentials 2021-01-07 13:22:38,341 - DEBUG: Successful connection to InfluxDb 2021-01-07 13:22:38,341 - INFO: Starting Speed Test For Server None 2021-01-07 13:22:38,357 - DEBUG: Setting up SpeedTest.net client 2021-01-07 13:22:38,586 - DEBUG: Picking the closest server 2021-01-07 13:23:08,886 - INFO: Selected Server 16676 in Paris 2021-01-07 13:23:08,887 - INFO: Starting download test 2021-01-07 13:23:13,306 - INFO: Starting upload test 2021-01-07 13:23:16,028 - DEBUG: [{'measurement': 'speed_test_results', 'fields': {'download': 741713644.1996006, 'upload': 549366763.0788989, 'ping': 5.709, 'server': '16676', 'server_name': 'Paris'}, 'tags': {'server': '16676', 'server_name': 'Paris', 'server_country': 'France'}}] 2021-01-07 13:23:16,242 - DEBUG: Data written to InfluxDB 2021-01-07 13:23:16,242 - INFO: Download: 741.71Mbps - Upload: 549.37Mbps - Latency: 5.709ms 2021-01-07 13:23:16,242 - INFO: Waiting 10800 seconds until next test et je retrouve ce test dans mon dashboard (je n'ai pas mis à jour le fuseaux horaire ...) : Le fichier tar à télécharger :speedtest2.tar Remarque : effectué sous DSM7 Beta. Pas de raison que ce soit différent sous DSM6 Si il y a une coquille quelque part, merci de me la signaler. Bruno78
  9. @Jeff777 oui c'est exact, mais ce n'est pas comme si cette image était mise à jour toutes les semaines ....
  10. Je vérifie et revérifie pour être certain que c'est propre et qu'il n'y a pas de coquille ... Il s'agira d'une mise à jour (très simple) de l'image docker d'origine. Il faudra donc mettre à jour le user/pwd dans le fichier config.ini, et mettre le nom de la nouvelle image (locale) que l'on va créer dans le docker-compose. C'est tout 🙂
  11. Bonjour, les sujets se croisent. A propos de Speedtest : Si quelqu'un est intéressé, je pense pouvoir donner la manip (simple) pour ne plus utiliser le compte influxdb admin/admin (quel qu'il soit) mais bien uniquement un user/pwd dédié à la base utilisée pour stocker les mesures speedtest. Cela implique évidemment que cette base soit créée à l'avance et configurée avec un utilisateur dédié. Peut-être pas avant ce weekend néanmoins, pas mal d'occupations ....
  12. Bonjour, Pour la petite histoire, je suis allé voir pourquoi le docker "speedtest" demande les droits admin/admin sur influxdb. En regardant le code, je trouve cela (qui ne manque pas d'humour #TODO .... ) log.debug('Testing connection to InfluxDb using provided credentials') influx.get_list_users() # TODO - Find better way to test connection and permissions Pour faire son get_list_users(), il semble qu'il ai besoin des privilèges admin/admin, tout ça pour "simplement" vérifier la connexion vers influxdb. Je vais regarder si il n'y a pas moyen de faire autrement, sans admin/admin .
  13. bruno78

    Wordpress depuis l'extérieur

    Bonjour @rytal, peux-tu stp préciser ton mode opératoire ? je ne comprends pas très bien. Utilises-tu le paquet WordPress ? comment est configuré le domaine du site ? c'est l'accès depuis l'exterieur (comment tu le testes ?) qui plante ? avec quel code précis ? quel est ton accès internet ? ... Merci
  14. @MilesTEG1@Jeff777 pareil, un dashboard dédié, mais trop de dashboards dédiés .... donc oui surement faire un dashboard de synthèse.
  15. @oracle7@Jeff777@Drickce Kangel , merci à vous pour vos travaux sur speedtest. Du coup je l'ai mis en place également relativement facilement. J'ai rajouté dans le dashboard les données de synchro de la Freebox. Cela donne ceci : 2 remarques néanmoins : il est tout à fait possible d'héberger le docker SpeedTest sur son NAS, et de viser une instance influxdb distante (mon influxdb/grafana se trouve sur une VPS OVH) je trouve anormal (je vais aller voir comment c'est fait, il y a peut-être une bonne raison ?) de devoir indiquer le usr/pwd admin d'influxdb, et pas uniquement le user/pwd dédiée à la db dédiée créee pour cela dans influxdb. Cdt Bruno78
  16. @Drickce Kangel , Du coup je ne vois pas ce qui pourrait empêcher grafana d'écrire dans son répertoire ..... Le problème est'il persistant ? Un point quand même : as tu vérifié que ton user est bien le 1026 ?
  17. @Drickce Kangel peux tu nous montrer le montage des volumes dans le docker compose stp ? Envoyé de mon STF-L09 en utilisant Tapatalk
  18. Quand tu as configuré ta source de données dans grafana, normalement il la teste puis dit OK. As tu eu ce message ? Envoyé de mon STF-L09 en utilisant Tapatalk
  19. Problème d'adressage vraisemblablement. Est ce que telegraf fonctionne et remonte des données vers influxdb ? Est ce que grafana accède bien à influxdb (adresse, mot de passe) .... Envoyé de mon STF-L09 en utilisant Tapatalk
  20. Bon il faut refaire l'enregistrement. Donc -r Pour la validation .... De mémoire flèche de droite, puis ok. Mais si ton afficheur beugue, ça ne va pas faciliter ! Envoyé de mon STF-L09 en utilisant Tapatalk
  21. @Drickce Kangel Pour réaliser l'authentification initiale, le volume ./py ne doit pas être monté en 'ro' dans le docker compose, pour pouvoir justement y écrire le fichier .credentials . Ensuite seulement il pourra être mis en read only 'ro'. Sauvegarde ce fichier .credentials, il ne changera pas, et pourra toujours, éviter à l'avenir de refaire cette phase d'enregistrement. Tant que tu as la même freebox ' ce fichier restera valable
  22. Bonjour, oui il s'agit du module python request qui n'a pas, ou mal, été installé. Essaye de reprendre juste cette partie . Bruno78 Envoyé de mon STF-L09 en utilisant Tapatalk
  23. Bonjour , J'avais également ce problème de coupure openvpn toutes les 24 heures avec le serveur openvpn sur le vps et le nas en client, même si la case 'reconnexion automatique ' était cochée. Sur le conseil de .Shad, mis le client sur le vps et le serveur openvpn sur le nas ... et depuis il n'y a plus de déconnexion. Parfaitement stable.
  24. Je vais vérifier mais il est possible que je n'ai pas utilisé la bonne méthode. ....
  25. Je viens d'aller voir là méthode signalée par @oracle7 : le scscript que j'utilise est très semblable. L'article est effectivement très clair à un détail près : autant installer docker sur un rpi ne pose pas de problème, autant installer docker-compose demande un peu plus de finesses ! En tout cas moi j'en ai bavé, et quelques recherches complémentaires ont été nécessaires (tout simplement il semble que docker-compose ne soit pas compatible ARM, donc pour le Pi ....) Cdt Bruno78
×
×
  • 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.