MilesTEG1 Posté(e) le 9 septembre 2020 Posté(e) le 9 septembre 2020 il y a 1 minute, .Shad. a dit : Tu n'as pas dû faire de NAT du port 161 entre ta box et ton second NAS ? Je te déconseille de laisser la communauté par défaut sur tes NAS si tu utilises le même [inputs.snmp] que pour ton premier NAS. C'est l'équivalent d'un mot de passe, en terme de sécurité c'est comme si tu exposais DSM sur l'extérieur avec un compote admin/admin ou admin/password. Si tu disposes d'une IP publique statique là où se trouve ton premier NAS, je te conseille de faire une règle de pare-feu sur ton second NAS avec comme source cette seule IP. Non j'ai rien routé sur le box. Depuis le 214play, y a rien qui sort du LAN. Mais je vais modifier la communauté 🙂 merci du conseil. En gros, j'ai : INTERNET <--> Box <--> Switch <--> NAS 920+ <--> NAS 214play Seule le 920+ est exposé sur le NET avec certains ports (j'ai bien suivi le tuto de sécurisation 😉 et j'accède au NAS depuis l'extérieur avec le VPN du NAS). Et comme je n'ai rien routé sur la box concernant le 214play, ce dernier ne craint rien. Et en plus il ne contient aucune donnée... Ce qui n'est pas le cas du 920+, mais sur celui là j'ai bien configuré le parefeu ^^ Ce qui nécessitera une configuration plus poussée, c'est si je veux faire pareil avec le NAS chez mes parents... mais là pour le coup, je ne pense pas le faire... ça ne vaut pas le coup ^^ 0 Citer
.Shad. Posté(e) le 9 septembre 2020 Auteur Posté(e) le 9 septembre 2020 Ok je pensais que ton 214play était dans un autre LAN, je comprends mieux, aucun souci pour la communauté alors. Ce que je dis est valable pour le NAS chez tes parents effectivement. 1 Citer
oracle7 Posté(e) le 9 septembre 2020 Posté(e) le 9 septembre 2020 @.Shad. et @bruno78 Bonjour, Voilà mon fichier docker-compose.yml : Citation version: "2" services: influxdb: image: influxdb:latest container_name: influxdb hostname: influxdb environment: - INFLUXDB_DB=nas_telegraf - INFLUXDB_ADMIN_USER=admin - INFLUXDB_ADMIN_PASSWORD=admin - INFLUXDB_USER=nas_telegraf - INFLUXDB_USER_PASSWORD=nas_telegraf - INFLUXDB_HTTP_AUTH_ENABLED=true volumes: - "/volume1/docker/influxdb/data:/var/lib/influxdb" mac_address: d2:ca:ab:cd:00:02 networks: monitoring: ipv4_address: 172.20.0.2 ports: - 8086:8086 restart: unless-stopped telegraf: image: telegraf:latest container_name: telegraf hostname: telegraf volumes: - "/volume1/docker/telegraf/telegraf.conf:/etc/telegraf/telegraf.conf:ro" - "/proc:/host/proc:ro" - "/usr/share/snmp/mibs:/usr/share/snmp/mibs:ro" - "/var/run/docker.sock:/var/run/docker.sock:ro" mac_address: d2:ca:ab:cd:00:03 networks: monitoring: ipv4_address: 172.20.0.3 ports: - 8125:8125/udp - 8092:8092/udp - 8094:8094 restart: unless-stopped grafana: image: grafana/grafana:latest container_name: grafana hostname: grafana volumes: - "/volume1/docker/grafana/data:/var/lib/grafana" user: "1030" mac_address: d2:ca:ab:cd:00:04 networks: monitoring: ipv4_address: 172.20.0.4 ports: - 3000:3000 restart: unless-stopped networks: monitoring: external: true C'est bon ? Cordialement oracle7😉 0 Citer
.Shad. Posté(e) le 9 septembre 2020 Auteur Posté(e) le 9 septembre 2020 Tu as réessayé avec le paramètre user dans Grafana ? N'hésite pas à supprimer le contenu de /volume1/docker/grafana/data, ça sera généré avec ton nouvel utilisateur lors de la re-création du conteneur. Je te conseille de supprimer le NAT des ports dans Telegraf, sauf si tu souhaites qu'un périphérique externe accède à Telegraf (donc Telegraf recevant des infos entrantes), le NAS ayant accès au conteneur nativement via l'IP 172.20.0.3. Pour InfluxDB si tu comptes l'utiliser pour une utilisation distante tu peux laisser le NAT, et Grafana c'est nécessaire. Pour la version en tout début de fichier, tu peux passer en 2.1 plutôt que 2, la version 2.1 gère beaucoup mieux les labels, il se peut qu'à l'avenir tu t'en serves, autant faire le changement maintenant. Mais sinon tout m'a l'air bon, même sans mes suggestions ça devrait fonctionner pour moi. N'hésite pas à supprimer le contenu de tous les dossiers montés pour une installation propre avant de refaire un docker-compose up -d (garde quand même une copie de telegraf.conf 😉). 0 Citer
bruno78 Posté(e) le 9 septembre 2020 Posté(e) le 9 septembre 2020 @oracle7, ça me parait bien pour grafana, si ton user est bien "1030" . 0 Citer
oracle7 Posté(e) le 9 septembre 2020 Posté(e) le 9 septembre 2020 @.Shad. et @bruno78 Bonjour, Citation root@xxxxxxx:/volume1/docker/scripts_instal# id oracle7 uid=1030(oracle7) gid=100(users) groups=100(users),101(administrators),1023(http),65536(Kodi),65537(WebDav_Users) il y a 9 minutes, .Shad. a dit : Tu as réessayé avec le paramètre user dans Grafana ? Lors de mes essais, j'avai déjà le paramètre "user" dans la section grafana. J'ai donc fait le nettoyage indiqué des répertoires + un "docker-compose down" pour repartir sur du "neuf". J'ai supprimée l'image grafana et re téléchargée et relancé la création des conteneurs : Citation root@xxxxxxx:/volume1/docker/scripts_instal# docker-compose up -d Creating grafana ... done Creating telegraf ... done Creating influxdb ... done root@xxxxxxx:/volume1/docker/scripts_instal# docker logs -f grafana GF_PATHS_DATA='/var/lib/grafana' is not writable. You may have issues with file permissions, more information here: http://docs.grafana.org/installation/docker/#migration-from-a-previous-version-of-the-docker-container-to-5-1-or-later mkdir: can't create directory '/var/lib/grafana/plugins': Permission denied Je comprends pas ... 😰 Cordialement oracle7😉 0 Citer
.Shad. Posté(e) le 9 septembre 2020 Auteur Posté(e) le 9 septembre 2020 (modifié) Essaie d'ajouter le gid du groupe administrateurs du NAS : user: "1030:101" Voir si c'est bien un problème lié aux permissions. Ce n'est pas idéal et définitif mais ça permet de cerner le problème. 2ème étape, créer un groupe dédié qui aura des droits R/W sur le volume monté. Supprimer le contenu des volumes et réessayer. Modifié le 9 septembre 2020 par .Shad. 0 Citer
oracle7 Posté(e) le 9 septembre 2020 Posté(e) le 9 septembre 2020 (modifié) @.Shad. CA MARCHE !!! il suffisait effectivement de préciser le groupe 101. C'est vraiment c... d'avoir bloqué sur çà. Je vais donc pouvoir poursuivre, MERCI encore de ton aide et de ta patience ... 😃 Edit : Peut-être qu'il faudrait préciser cela dans le TUTO ? (cas d'un utilisateur membre du groupe administrateurs) Cordialement oracle7😉 Modifié le 5 juillet 2021 par oracle7 0 Citer
MilesTEG1 Posté(e) le 9 septembre 2020 Posté(e) le 9 septembre 2020 Cool que ça fonctionne ^^ Par contre, je n'ai pas spécifié le groupe d'utilisateur de l'utilisateur spécifié, et je n'ai pas eu ces problèmes... L'utilisateur que j'ai créé est juste membre du groupe "users", pas du groupe "admin". J'ai aussi fait en sorte de mettre cet utilisateur en propriétaire du dossier /docker/grafana (et des autres aussi telegraf et infludb). 0 Citer
.Shad. Posté(e) le 9 septembre 2020 Auteur Posté(e) le 9 septembre 2020 (modifié) C'est pas la meilleure solution, il serait préférable que tu crées un groupe dédié avec les droits sur ces dossiers. Et utiliser son gid dans Grafana. Mais ça peut faire l'affaire. Ça dépend les droits que donnent les gens au groupe "users" utilisé par défaut dans DSM. Et de qui est propriétaire des dossies en question. C'est vraiment propre à DSM toutes ces emm*rdes liées aux permissions, c'est pour ça que j'ai depuis longtemps déporté tout ça sur un VPS. Aucun problème sur une distribution Linux classique... La gestion des ACL de Synology a ses avantages, mais surtout des inconvénients je trouve. 😉 Modifié le 9 septembre 2020 par .Shad. 0 Citer
MilesTEG1 Posté(e) le 9 septembre 2020 Posté(e) le 9 septembre 2020 L'utilisateur que j'ai créé n'a des droits de lecture et d'écriture que sur le partage /volume1/docker. J'ai aussi mis en interdit toutes les applications dispo dans les permissions de DSM à la création de l'utilisateur : Sinon, je vois souvent parler de VPS, c'est quoi exactement ? J'imagine que c'est un serveur, genre dédié à un truc... Et j'imagine aussi que c'est payant ? (à moins de dédier une machine chez soi pour ça... ?) 0 Citer
oracle7 Posté(e) le 9 septembre 2020 Posté(e) le 9 septembre 2020 @.Shad. Bonjour, Du coup tu me mets un doute : il y aurait un inconvénient du point de vue sécurité que j'utilise mon user "admin" pour gérer ce monitoring car ce sont au demeurant des données système donc de son "niveau", Non ? Cordialement oracle7😉 0 Citer
.Shad. Posté(e) le 9 septembre 2020 Auteur Posté(e) le 9 septembre 2020 Ça c'est une question très subjective, pour ma part j'évite d'exécuter des conteneurs avec des utilisateurs admin, tu es soumis aux failles potentielles dans les images que tu télécharges. Mais c'est plus une question de philosophie que de danger réel. 0 Citer
.Shad. Posté(e) le 9 septembre 2020 Auteur Posté(e) le 9 septembre 2020 @MilesTEG1 VPS c'est un serveur virtuel oui, j'ai pris la formule de base chez OVH (3€ par mois). A plusieurs fins : - Faire des tests (serveur mail, nouvelles applications, etc...) plutôt qu'expérimenter sur mes périphériques. - InfluxDB bouffe des ressources, et génèrent beaucoup de lecture et écriture, je préfère autant abîmer les SSD (oui en plus ce sont des SSD, donc pas le même niveau de réactivité que des disques durs) d'OVH que mes disques de stockage. - Serveur CardDAV - Hébergeur de fichiers à la volée pour uploader rapidement quelque chose et le partager avec un collègue => Sharry - Si mon NAS s'éteint, redémarre, ou plante, je perds les données de supervision de mon NAS dans Grafana mais aussi des autres périphériques (routeur, pi-hole, serveur debian, etc...). Ici, si mon NAS plante je suis sûr que toutes les données possibles ont été transférées, j'ai du recul. Et l'uptime d'OVH est très haut, en un an je crois que j'ai eu une seule coupure, qui avait été annoncée. - J'ai un OpenVPN dessus, ce qui me permet de me connecter à une IP française (j'aurais pu choisir un serveur en Allemagne, USA, ou autre, à la création du VPS). - Tout ce que tu veux ? Tu peux aussi jeter un oeil au tutoriel de @Einsteinium sur la mise en place d'un proxy inversé pour modem/routeur 4G sur VPS. Par contre c'est sûr faut mettre un peu plus les mains dans le cambouis que sur DSM, mais c'est aussi ça qui est excitant. 0 Citer
MilesTEG1 Posté(e) le 10 septembre 2020 Posté(e) le 10 septembre 2020 Hello @.Shad. Merci pour ces explications 😇 3€/mois c'est un tarif raisonnable 🙂 Cela dit, je ne suis pas sur d'avoir besoin d'un VPS vu ce que je fais avec mon NAS et mon réseau ^^ Le 09/09/2020 à 12:17, .Shad. a dit : - Si mon NAS s'éteint, redémarre, ou plante, je perds les données de supervision de mon NAS dans Grafana mais aussi des autres périphériques (routeur, pi-hole, serveur debian, etc...). Ici, si mon NAS plante je suis sûr que toutes les données possibles ont été transférées, j'ai du recul. Et l'uptime d'OVH est très haut, en un an je crois que j'ai eu une seule coupure, qui avait été annoncée. Quand tu parles de transfert de données, tu parles de celles de la base de donnée influDB ? Ou bien d'autres données à la base stockées sur le NAS ? Et si je comprends bien ce que tu as dis, tu fais passer l'accès à ton NAS (et services dessus) par un proxy-inversé présent sur le VPS ? Il va falloir que je regarde la mise en place d'un proxy-inversé avec Traefik, car il permet (d'après ce qu'on m'a expliqué sur HFR) de gérer les certificats wildcards LE, et de faire les certificats des conteneurs docker que je voudrais exposer sur le net 😉 PS : y a eu une MAJ du forum ? j'ai l'impression que la mise en page a changé... 0 Citer
.Shad. Posté(e) le 10 septembre 2020 Auteur Posté(e) le 10 septembre 2020 (modifié) il y a 12 minutes, MilesTEG1 a dit : Quand tu parles de transfert de données, tu parles de celles de la base de donnée influDB ? Ou bien d'autres données à la base stockées sur le NAS ? Si j'héberge InfluxDB sur mon NAS et que je redémarre celui-ci, je perds les données du NAS + celles qui n'ont pas été envoyées par les autres périphériques. Alors il existe un buffer dans Telegraf, qui permet de stocker une certaine quantité de données avant d'envoyer un paquet. On le voit bien dans les logs de Telegraf si on a activé le mode debug. Mais cela implique que Telegraf soit présent sur les autres machines, pas que la machine hôte aille poll via SNMP les autres périphériques. il y a 12 minutes, MilesTEG1 a dit : Et si je comprends bien ce que tu as dis, tu fais passer l'accès à ton NAS (et services dessus) par un proxy-inversé présent sur le VPS ? Non c'est ce que fait @Einsteinium ça, il a un proxy inversé sur le VPS qui redirige via VPN vers son LAN. Moi j'ai un proxy inversé sur mon VPS, qui permet d'accéder via le port 443 à tous ses services. Et un proxy inversé sur mon routeur pfSense, pour tout ce qui se trouve sur mon LAN, NAS inclus. il y a 12 minutes, MilesTEG1 a dit : Il va falloir que je regarde la mise en place d'un proxy-inversé avec Traefik, car il permet (d'après ce qu'on m'a expliqué sur HFR) de gérer les certificats wildcards LE, et de faire les certificats des conteneurs docker que je voudrais exposer sur le net 😉 J'ai rédigé un tutoriel avec l'image linuxserver/swag (anciennement linuxserver/letsencrypt) qui fait la même chose que Traefik, en un peu moins automatique, mais Traefik joue sur les labels de conteneurs pour tout automatiser, donc tes services qui n'utilisent pas docker (Moments, File Station, etc...) tu ne peux rien faire avec. Il n'a pas intéressé grande monde (personne ? 😄) pour le moment, mais c'est ce que j'utilise sur le VPS, et ça remplace avantageusement le proxy inversé du NAS : Modifié le 10 septembre 2020 par .Shad. 0 Citer
MilesTEG1 Posté(e) le 10 septembre 2020 Posté(e) le 10 septembre 2020 il y a 6 minutes, .Shad. a dit : Si j'héberge InfluxDB sur mon NAS et que je redémarre celui-ci, je perds les données du NAS + celles qui n'ont pas été envoyées par les autres périphériques. Alors il existe un buffer dans Telegraf, qui permet de stocker une certaine quantité de données avant d'envoyer un paquet. On le voit bien dans les logs de Telegraf si on a activé le mode debug. Mais cela implique que Telegraf soit présent sur les autres machines, pas que la machine hôte aille poll via SNMP les autres périphériques. Non c'est ce que fait @Einsteinium ça, il a un proxy inversé sur le VPS qui redirige via VPN vers son LAN. Moi j'ai un proxy inversé sur mon VPS, qui permet d'accéder via le port 443 à tous ses services. Et un proxy inversé sur mon routeur pfSense, pour tout ce qui se trouve sur mon LAN, NAS inclus. J'ai rédigé un tutoriel avec l'image linuxserver/swag (anciennement linuxserver/letsencrypt) qui fait la même chose que Traefik, en un peu moins automatique, mais Traefik joue sur les labels de conteneurs pour tout automatiser, donc tes services qui n'utilisent pas docker (Moments, File Station, etc...) tu ne peux rien faire avec. Il n'a pas intéressé grande monde (personne ? 😄) pour le moment, mais c'est ce que j'utilise sur le VPS, et ça remplace avantageusement le proxy inversé du NAS : Ok, je vais aller voir ce tuto 😄 Il peut m'intéresser 😄 je constate en te lisant que tu as carrément un autre niveau en réseau 😄 Et aussi des besoins plus conséquents 😉 Je pense que je vais rester sur le tout hébergé sur mon NAS 😉 Même si en cas de crash de ce dernier je n'aurais plus les données... (en ce qui me concerne, ce ne sera pas ces données là qui vont me faire défauts si ça crash 🤪 Mais bon j'ai des backups programmés qui se font toutes les nuits 😉 ) 0 Citer
.Shad. Posté(e) le 10 septembre 2020 Auteur Posté(e) le 10 septembre 2020 (modifié) Clairement je n'ai pas un suivi au jour le jour, mais quand j'ai un plantage je vais toujours jeter un œil pour vérifier ! Ce n'est vraiment pas une nécessité. 😉 Modifié le 10 septembre 2020 par .Shad. 1 Citer
oracle7 Posté(e) le 10 septembre 2020 Posté(e) le 10 septembre 2020 @.Shad. Bonjour, Pour commencer à m'initier à grafana et voir comment cela s'articule, j'ai installé la dashbord préconisée (celle de Yann Bizeul). Là un truc qui va pas : sans rien avoir modifié dans la requête qui donne de N°de serie du NAS (en principe l'hôte ou est installé docker and cie) en fait il m'est retourné le N° de série de mon second NAS sur le réseau local. J'ai pourtant bien renseigné le telegraf.conf avec "agents = [ "@IPduNAS" ]" dans la partie INPUT PLUGINS. Par ailleurs dans le log de influxdb (détail conteneur sous docker) je suis envahi d'erreur elles que : et dans le log de telegraf j'ai ceci : D'où mon incompréhension. Une idée peut-être car je ne sais pas décrypter ces messages ? Cordialement oracle7😉 0 Citer
.Shad. Posté(e) le 11 septembre 2020 Auteur Posté(e) le 11 septembre 2020 Tu n'as pas ajouté les 2 IP à un moment par hasard dans agents ? ou l'autre seulement ? Sinon en haut de la dashboard tu as normalement la liste des variables, de souvenir agent_host en est une, et tu as une liste déroulante avec les différents agents (les différentes IP). Pour la première impression d'écran j'ai aussi ça depuis une mise à jour récente avec Telegraf, il affiche un code erreur 204 (requête réussie mais pas de données), pourtant j'ai bien toutes les données transmises à InfluxDB. Pour la deuxième impression d'écran, ça dit que tu as un timeout sur tes requêtes. Vu que tu as renseigné l'IP locale du NAS (192.168.2.10) dans agents, il faut t'assurer que le pare-feu de ton NAS accepte les requêtes de Telegraf, 172.20.0.x, si tu as mis la règle de Fenrir 172.16.0.0/255.240.0.0 c'est bon normalement. Le plus simple étant de ne pas mettre l'IP locale, mais l'IP du NAS dans le réseau bridge que tu as créé, 172.20.0.1, normalement ainsi ça devrait fonctionner. 0 Citer
MilesTEG1 Posté(e) le 11 septembre 2020 Posté(e) le 11 septembre 2020 Avec tous les erreurs qu'a Oracle, je suis aller voir mes logs pour voir si j'avais des trucs similaires : Bah déjà imposssible d'accéder aux log d'influxDB... soit ça me fait ça : Soit j'ai les dates à gauche, mais rien dans les logs... Après redémarrage des conteneurs, j'ai de nouveau accès aux logs : Pour Telegraf : Et grafana : des erreurs avant le redémarrage du paquet... Bon bah je sais pas expliquer, interpréter ces erreurs... D'autant qu'avant que je fasse un redémarrage des conteneurs, je n'avais pas de problèmes visible dans grafana... Les mystères et joies de l'informatique 🤪 0 Citer
oracle7 Posté(e) le 11 septembre 2020 Posté(e) le 11 septembre 2020 (modifié) @.Shad. Bonjour, Il y a 8 heures, .Shad. a dit : Tu n'as pas ajouté les 2 IP à un moment par hasard dans agents ? Oui, j'ai mis à un moment cela : Citation agents = [ "192.168.2.10", "192.168.2.11" ] afin d'afficher des infos de mes deux NAS en regard l'une de l'autre (pour avoir tout dans un même écran quoi ...) puis j'ai supprimé pour le second NAS mais même punition : toujours seul les infos du second sont récoltées. Pb de droits quelque part sur le premier NAS ? J'ai revérifié le fichier "telegrah.conf" que j'ai "allégé" au passage, je te le joins pour avis : telegraf.conf Mais toutes mes requêtes grafana me revoient toujours les infos liées à mon second NAS en 192.168.2.11. Le premier (et support de docker and co) n'apparait même pas lors que je sélection le champ "sysName" tout simplement et j'ai toujours cette erreur qui boucle (journal telegraf) : Pour le coup je suis complètement perdu. Est-ce que je réinitialise tout ? cela fera jamais que le n ième fois ... Edit : A ce propos, à chaque réinitialisation je perd les règles docker dans le pare-feu, c'est normal docteur ? Cordialement oracle7😉 Modifié le 11 septembre 2020 par oracle7 0 Citer
.Shad. Posté(e) le 11 septembre 2020 Auteur Posté(e) le 11 septembre 2020 Il y a 9 heures, .Shad. a dit : Pour la deuxième impression d'écran, ça dit que tu as un timeout sur tes requêtes. Vu que tu as renseigné l'IP locale du NAS (192.168.2.10) dans agents, il faut t'assurer que le pare-feu de ton NAS accepte les requêtes de Telegraf, 172.20.0.x, si tu as mis la règle de Fenrir 172.16.0.0/255.240.0.0 c'est bon normalement. Le plus simple étant de ne pas mettre l'IP locale, mais l'IP du NAS dans le réseau bridge que tu as créé, 172.20.0.1, normalement ainsi ça devrait fonctionner. Tu n'as pas réagi à cette partie 😉 0 Citer
oracle7 Posté(e) le 11 septembre 2020 Posté(e) le 11 septembre 2020 @.Shad. Bonjour, Bah Oui, effectivement cela marche tout de suite mieux en mettant dans agent l'@IP du NAS sur le réseau bridge. En tout cas Merci. Maintenant je continue de me battre avec les requêtes grafana. Pas simple, même quand on connait SQL ... Cordialement oracle7😉 0 Citer
.Shad. Posté(e) le 11 septembre 2020 Auteur Posté(e) le 11 septembre 2020 Oui et là je ne peux pas t'aider, j'y connais rien. 😛 0 Citer
Messages recommandés
Rejoindre la conversation
Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.