bruno78

@EVOTk, tu dois créer une route vers un réseau / subnet, pas vers une machine / host individuelle. Sauf erreur de ma part, ta commande d'ajout de route devrait donc être a priori : ip route add 192.168.0.96/28 dev maclan-swag @.Shad. par ailleurs ce matin de bonne heure j'en ai profité pour regarder le problème de perte de connectivité avec le docker Pihole : sur un reboot complet du NAS, les interfaces et les routes remontent bien avec le timer originel de 60s dans la tache planifiée au demarrage. j'ai par contre reproduit le problème en faisant un stop / start du paquet Docker. Je ne sais pas si c'est réellement ce qui c'était passé pour moi à l'origine. Il y a peut-être d'autres cas dans lesquels cela arrive ? ... je continue le monitoring. Évidemment une solution pourrait être de relancer automatiquement la création de l'interface et du routage vers le docker PiHole en cas de détection de perte de connectivité, mais pour le moment je préfère laisser "en manuel" pour voir si cela se reproduit et en quelles circonstances. Bruno78

@EVOTk bonjour, je serais surpris que 192.168.0.100/24 représente 192.168.0.96 à 192.168.0.111 .... Le /24 représente l'ensemble de la plage 192.168.1.0 à 192.168.1.255. Si tu veux 16 adresses (14 adresses utilisables pour des hosts) de 192.168.0.96 à 192.168.0.111, il te faut un réseau en /28

Bonjour, (à propos du script, pas de nginx) j'utilise ce script depuis déjà un bon moment (pour le docker PiHole). Il est lancé au démarrage du NAS, moyennant un timer du 60secondes (sleep 60) pour être sûr que les interfaces réseau sont montées au moment de l’exécution du script. Or j'ai eu depuis quelques jour des déboires avec justement la résolution DNS, jusqu'à m’apercevoir que ce réseau n'était plus opérationel (link down et route absente). Il a suffit de le remettre up et recréer la route pour que cela reparte. => je ne sais pas pourquoi il était passer down, mais cela est concomitant dans le temps avec un reboot du NAS. J'ai donc passé le timer à 90sec, et rajouter via grafana une surveillance de l'accessibilité du docker Pihole (sinon tout le monde bascule sur le DNS secondaire et on ne se rend pas compte du problème tout de suite). => je vérifie cela au prochain reboot. Bruno78

Bonjour, je suis sur un DS918+, en DSM7 Beta avec cache SSD (2*MVNE montés en R/W). Aucun problème a priori.

@X260-dpaulet, D'où l'intérêt de la containairisation ..... merc pour ce message

Hello, avec un Pi3B, aucun soucis .... (et il ne fait pas que ça)

@Jeff777, non a priori ça ne résout pas le problème : msg="Unable to update container \"/fbx_py\": Error response from daemon: pull access denied for fbx_py, repository does not exist or may require 'docker login'. Proceeding to next." Par contre, une mise à jour periodique via un script shell lancé par une tache planifiée, ça doit pouvoir se faire. Bruno78

@Jeff777, je vois que tu galères pas mal avec ce fichu docker telegraf dans lequel on ajoute python. Je n'ai pas eu le temps de regarder watchover, donc je ne peux guère t'aider. Mais pour info, je suis en train de voir à remplacer, pour la freebox uniquement, le docker telegraf par un docker python. Je ne sais pas si cela pourrait rendre l'utilisation de watchover plus facile, car de toute façon même ainsi il faut légèrement modifier l'image et créer une image locale, mais cela se ferait via "docker build". Je vais voir si il y a des possibilités ... et jeter un coup d'oeil à Wacthover (mais il y a 11 pages de posts à lire .....) Cdt Bruno78

Bonjour, désolé un peu éloigné du forum ces derniers temps (je travaille à une version sans telegraf pour le monitoring de la freebox (remplacement du docker telegraf par un simple docker python; et je me frotte aux joies de l'exploitation des logs via promtail/loki .... ca prend du temps). Bref pour en revenir aux interfacex LAN/WAN de la Freebox, je les atteins simplement car l'API mis à disposition le permet, mais ce n'est pas du SNMP. Donc je ne vois pas comment transposer ici ... Cdt Bruno78

il y a un espace entre le -- et accountemail => supprimer ce caractère espace

@nebelnic bonjour, a priori le script est bien disponible en page 1, chap 6 du tuto Bruno78

@Jeff777, l'adresse MAC fixée pour le docker telegraf .... ne sert à rien ici. Je l'avais mise en place pour certains dockers en mode macvlan et donc pour lesquels l'adresse IP et l'adresse MAC sont visibles sur le réseau. C'est le cas en particulier de mon docker pihole. Mais ici pour telegraf .... aucun intérêt on est d'accord. C'est un reliquat. Bruno78

@Jeff777, pour ce que l'on veut faire ici, càd disposer d'une image telegraf incluant l'installation de Python3, la commande "docker commit" fait le boulot. Voici donc comment j'ai procédé : (les outputs sont tronqués car trop longs) 1) Je charge une image de telegraf vierge, je vérifie qu'il n'y a pas de python et j'y installe mon python3 selon la procédure du tuto : root@vdsm2:/volume1/docker/monitoring# cat docker-compose.yaml services: test_telegraf: image: telegraf:latest container_name: test_telegraf hostname: test_telegraf mac_address: d2:ca:ab:cd:00:06 networks: data_grafana: ipv4_address: 172.18.0.6 environment: - PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/bin:/sbin:/usr/local:/usr/src - TZ=CET volumes: - "/volume1/docker/dev3/telegraf/telegraf.conf:/etc/telegraf/telegraf.conf:ro" - "/volume1/docker/dev3/telegraf/py:/usr/local/py:ro mem_limit: 50M ports: - 5125:8125/udp - 5092:8092/udp - 5094:8094 restart: unless-stopped root@vdsm2:/volume1/docker/monitoring# root@vdsm2:/volume1/docker/monitoring# docker-compose up -d test_telegraf Creating test_telegraf ... done root@vdsm2:/volume1/docker/monitoring# docker images REPOSITORY TAG IMAGE ID CREATED SIZE telegraf latest 79fd1e5d0a8f 3 months ago 276MB root@vdsm2:/volume1/docker/monitoring# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 0de5d8966d84 telegraf:latest "/entrypoint.sh tele…" 16 seconds ago Up 11 seconds 0.0.0.0:5092->8092/udp, 0.0.0.0:5094->8094/tcp, 0.0.0.0:5125->8125/udp test_telegraf root@vdsm2:/volume1/docker/monitoring# docker exec -it test_telegraf /bin/bash root@test_telegraf:/# python -V bash: python: command not found root@test_telegraf:/# python3 -V bash: python3: command not found root@test_telegraf:/# apt update root@test_telegraf:/# apt upgrade …. root@test_telegraf:/# dpkg --configure -a root@test_telegraf:/# apt-get install apt-transport-https ca-certificates curl gnupg-agent software-properties-common root@test_telegraf:/# wget https://bootstrap.pypa.io/get-pip.py root@test_telegraf:/# apt-get install python3-distutils root@test_telegraf:/# python3 get-pip.py --prefix=/usr/local root@test_telegraf:/# python3 -m pip install requests root@test_telegraf:/# pip install unidecode root@test_telegraf:/# python3 -V Python 3.7.3 root@test_telegraf:/# exit exit 2) je fais dessus un "docker commit -p <reference docker> <nom_nouvelle_image>". Cela produit une nouvelle image contenant toutes les modifications effectuées auparavant. L'option -p met en pause le docker pendant la création de la nouvelle image afin de garantir qu'il n'y ai pas d'incohérence dans le file system. root@vdsm2:/volume1/docker/monitoring# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 0de5d8966d84 telegraf:latest "/entrypoint.sh tele…" 16 minutes ago Up 15 minutes 0.0.0.0:5092->8092/udp, 0.0.0.0:5094->8094/tcp, 0.0.0.0:5125->8125/udp test_telegraf root@vdsm2:/volume1/docker/monitoring# docker commit -p 0de5d8966d84 telegraf_py:latest sha256:e9ac730929f7698a4264ff762f2b86a34a28113a48fda598d065fa04a19260cf root@vdsm2:/volume1/docker/monitoring# docker images REPOSITORY TAG IMAGE ID CREATED SIZE telegraf_py latest e9ac730929f7 8 seconds ago 466MB telegraf latest 79fd1e5d0a8f 3 months ago 276MB root@vdsm2:/volume1/docker/monitoring 3) je modifie mon docker-compose.yaml pour utiliser cette nouvelle image version: "2" services: test_telegraf: image: telegraf_py:latest container_name: test_telegraf hostname: test_telegraf mac_address: d2:ca:ab:cd:00:06 networks: data_grafana: ipv4_address: 172.18.0.6 environment: - PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/bin:/sbin:/usr/local:/usr/src - TZ=CET volumes: - "/volume1/docker/dev3/telegraf/telegraf.conf:/etc/telegraf/telegraf.conf:ro" - "/volume1/docker/dev3/telegraf/py:/usr/local/py:ro" mem_limit: 50M ports: - 5125:8125/udp - 5092:8092/udp - 5094:8094 restart: unless-stopped 4) j'efface le docker mis à jour manuellement, et je relance le docker-compose avec la nouvelle image telegraf_py:latest root@vdsm2:/volume1/docker/monitoring# docker stop test_telegraf test_telegraf root@vdsm2:/volume1/docker/monitoring# docker rm test_telegraf test_telegraf root@vdsm2:/volume1/docker/monitoring# docker-compose up -d test_telegraf Creating test_telegraf ... done root@vdsm2:/volume1/docker/monitoring# 5) je vérifie les détails du nouveau docker : il a bien pris en compte l'image telegraf_py:latest root@vdsm2:/volume1/docker/monitoring# docker inspect test_telegraf [ { "Id": "a778a6d7d5e50a1e29837205d3fbe5710dafc2884f0f26e5cae09981b0737219", "Created": "2020-11-28T06:29:51.30628885Z", "Path": "/entrypoint.sh", "Args": [ "telegraf" ], …. "Env": [ "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/bin:/sbin:/usr/local:/usr/src", "TELEGRAF_VERSION=1.15.2", "TZ=CET" ], "Cmd": [ "telegraf" ], "ArgsEscaped": true, "Image": "telegraf_py:latest", "Volumes": { "/etc/telegraf/telegraf.conf": {}, "/usr/local/py": {} }, ….. } } } } ] root@vdsm2: 6) et enfin je vérifie que mon docker basé sur l'image commitée telegraf_py:latest contient le python fonctionnel : root@vdsm2:/volume1/docker/monitoring# docker exec -it test_telegraf /bin/bash root@test_telegraf:/# python3 -V Python 3.7.3 Voilà. Désolé c'était un peu long, mais je voulais être sûr que c'était bon. Donc pas besoin de docker save/load. Cdt Bruno78

alors a priori il serait conseillé de faire un docker commit -p ... avant le backup, et de ne pas le faire dans la partition / qui n'est pas taillée pour cela. Si on se met dans /homes ca ne pose pas de problème. J'essaie de mettre cela au clair ce weekend.

@Jeff777, oui ça n'a pas l'air si évident ... Je pense qu'il faut creuser un peu .... J'ai le même type de comportement ... Je vais chercher un peu ....

@Jeff777, a priori les commandes docker save et docker load devraient répondre à ton problème de sauvegarde d'image docker (ps je n'ai pas testé). https://docs.docker.com/engine/reference/commandline/save/ https://docs.docker.com/engine/reference/commandline/load/

Bonjour @Jeff777, tout d'abord je ne m'explique pas ces deconnexions intempestives. Je redemarre la box ou le NAS (bon pas tous les jours non plus !) mais c'est arrivé une fois ou 2 ces derniers temps, et je n'ai jamais à tout reconstruire ! Pour ce qui est d'éviter de tout retaper à chaque fois, je pense (je suis sûr) qu'il y a moyen de sauvegarder l'image une fois modifiée. Je vais regarder les docs Docker. Bruno78

Problème résolu : ayant fini par trouvé ce post (https://stackoverflow.com/questions/8384122/php-downloaded-binary-file-gets-an-additional-byte-0x0a-at-the-end ) , j'ai regardé de plus près mes balises php ... la balise PHPfermante d'un fichier include était suivie d'un "blanc" (donc peu détectable sauf à le chercher explicitement), pris en compte par la commande echo du fichier principal, et provoquait cet entête indésirable. PS : ça veut aussi dire que ce que je croyais être des tests à configuration "strictement identique" ne l'était pas tant que cela. Le diable se niche dans les détails.

Bonjour, je reviens sur ce post car j'avais besoin de faire quelques tests complémentaires, étant complètement dans le flou. La seule configuration que j'ai réussi à faire tourner sur le Pi, c'est un mettant un lien de chargement sur le site. Soit un syntaxe de ce type : file_put_contents($csv_filename, $csv_export); header('Location: http://pisl.ndd.tld/'.$csv_filename.''); qui donne le lien de chargement du fichier à rapatrier. Toute autre méthode a échoué et m'a toujours mis ces 2 octets d'entête parasites (0x09 0x0a càd <tab> <LF>). En faisant une trace réseau, j'ai confirmé que c'est bien au départ, sur le Rasp Pi, que se produit l'ajout des ces 2 octets, phénomène qui n'apparait pas lorsque le même code est hébergé sur le Syno. Je cherche toujours quelle est la différence de config. qui pourrait expliquer ce comportement bizarre : PHP7.3 d'un côté, PHP7.4 de l'autre ? LANG=en_US.utf8 d'un côté, LANG=fr_FR.UTF8 de l'autre ?

Bonjour, j'ai un site qui tourne sur mon DS918, sous wordpress / nginx / mariadb / PHP. Une des fonctionnalité est l'export de tableaux sql en csv via un script PHP. Pour cela, j'ai entre autre appliqué la méthode qui se trouve ici (https://gist.github.com/janschoepke/3e7a3639546d0d740c023e11289cf13d) donc j'ai un code comme ceci : ($ress étant le résultat de ma requête sql) // creation du fichier csv à exporter // gestion du BOM (pour MS Excel) Byte Order Mark // compatibilité MS Excel Windows $bom = chr(0xEF) . chr(0xBB) . chr(0xBF); /* vars for export */ // database record to be exported $db_record = 'Liste_Noms'; // optional where query $where = 'WHERE 1 ORDER BY 1'; // filename for export $csv_filename = 'OSL_'.$db_record.'_'.date('Y-m-d').'.csv'; $csv_export = ''; $field = mysqli_field_count($dbconnect); // create line with field names for($i = 0; $i < $field; $i++) { $csv_export.= mysqli_fetch_field_direct($ress, $i)->name.';'; } // newline $csv_export .= PHP_EOL; // loop through database query and fill export variable while($row = mysqli_fetch_array($ress)) { // create line with field values for($i = 0; $i < $field; $i++) { $csv_export.= '"'.$row[mysqli_fetch_field_direct($ress, $i)->name].'";'; } // newline $csv_export .= PHP_EOL; } // ajout BOM au fichier pour passage en UTF8-BOM // pour MS Excel (Byte Order Mark) // compatibilité MS Excel Windows $csv_export = $bom . $csv_export; // Export the data and prompt a csv file for download header("Content-type: text/x-csv; charset=utf-8"); header("Content-Disposition: attachment; filename=".$csv_filename.""); echo($csv_export); => cela fonctionne nickel sur le DSM. MAIS : faisant quelque fois des essais sur le Syno, j'ai installé le site à l'identique sur un Rasp Pi 3B+ pour pouvoir basculer au cas ou.. Après quelques réglages (wordpress, nginx, php) tout fonctionne à merveille et à l'identique, ... sauf cet export csv !! Symptôme : Excel me dit "fichier corrompu", et quand je regarde de plus près, je m'apperçois que le fichier csv transféré contient une première ligne "parasite" : Ce sont cette tabulation et "LF" en ligne 1 qui empêche Excel d'ouvrir le fichier. (alors que OpenOffice Calc s'en moque royalement et ignore cette ligne) Le même code sur le Syno donne un résultat propre, sans cette première ligne. Je crois avoir à peu près tout essayé pour supprimer cette ligne parasite (text/csv, application/csv, fputcsv, trim, ltrim, ....) Rien à faire. => je ne sais plus où chercher ..... J'ai tenté de regarder les configurations de PHP, c'est touffu, mais rien d'évident. Si quelqu'un à une idée géniale , je suis preneur. Merci d'avance, Bruno78

OK, pas de soucis. Moi j'ai un peu segmenté les choses : 3 dockers telegraf sur le NAS : 1 pour le NAS lui-même, 1 pour la Fbox et 1 dédié à la collecte de logs. + des telegraf "satellites" : 1 sur une VPS OVH, 1 sur un Rasp Pi. Les tout remonte vers des databases différentes de la même instance influxdb, puis vers grafana. Disons que quand je fais des tests ciblés, ca évite de faire tout planter. Au pire je ré-initialise le telegraf qui me pose problème, et j'efface et je recrée la database concernée d'influxdb.

@Jeff777, pour le polling time, c'est dans le fichier de conf de telegraf : telegraf.conf. ligne 25 : # Configuration for telegraf agent [agent] ## Default data collection interval for all inputs interval = "15s" ligne 51 : ## Default flushing interval for all outputs. Maximum flush_interval will be ## flush_interval + flush_jitter flush_interval = "15s" Puis dans les "input plugins" pour la partie Freebox (vers ligne 1681 mais ca depend où tu l'as positionné dans ton fichier) ############################################################################### # INPUT PLUGINS # ############################################################################### ############################################################################### # INPUT PLUGINS FREEBOX # ############################################################################### # Read metrics from one or more commands that can output to stdout [[inputs.exec]] ## Commands array # # API freebox OS V8 commands = ["python3 /usr/local/py/freebox_059.py -WXDHSP"] ## Timeout for each command to complete. # timeout = "5s" timeout = "12s"

@Jeff777, par ailleurs, de mon côté je fais quelques évolutions sur le script python pour la Freebox (sur le DHCP), et je suis toujours à la limite : je viens de passer le polling interval à 15s au lieu de 10sec, (donc le flush interval également à 15sec) et le timeout à 12sec. je me suis aperçu que j'étais assez restrictif sur la mémoire allouée au docker fbx_telegraf. Je viens de le passer de 75M à 150M. A voir si cela supprime des message d'erreur aléatoires que j'ai de temps en temps. Mais en tout cas le docker fbx_telegraf s'est empressé d'utiliser cette espace mémoire supplémentaire. Donc je me dis que ça ne peut être que bénéfique. Bruno78

Bonjour @Jeff777, les problèmes de déconnexion avec la fenêtre rouge "unauthorized" .... Peux tu vérifier au niveau du journal telegraf si tu n'aurais pas par hasard des "timeout" pour la récupération des données par telegraf sur la Freebox ? ou un autre type d'erreur ? De mon côté j'ai été obligé d'augmenter légèrement le timeout dans telegraf.conf parce que la freebox avait du mal à tout me récupérer dans le temps imparti. Je suis passé de 5 à 8 sec. Bruno78

@Einsteinium@MagJ@Skylnex bonjour, j'avoue avoir été un peu fainéant, et avoir créé de nouvelles clés sans avoir effacé les anciennes. Ce n'est pas très propre, ... mais ça ne pose aucun soucis. Par ailleurs, j'ai pu mettre en œuvre relativement facilement la solution de notification par mail basée sur le service sendgrid.com. Ce n'est pas la configuration du docker qui est compliquée (très bien expliquée là https://github.com/acmesh-official/acme.sh/wiki/notify ) C'est la configuration du compte sendgrid.com qui est un peu "pénible" car ils demandent pas mal d'infos (bon on rentre ce qu'on veut, d'accord) , et ensuite ils poussent fortement à utiliser la double authentification pour l'accès à son compte sendgrid.com (basée sur l'application Authy). En ce qui concerne la génération de l'API sendgrid.com, on peut restreindre au maximum les droits sur cet API pour n'utiliser que ce dont on a besoin, à savoir l'envoi de mail. Au niveau de l'API, on choisit "restricted access" Puis on choisit uniquement "Mail Send" Cdt Bruno78