Aller au contenu

Messages recommandés

Posté(e)
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 ^^

Posté(e)

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.

Posté(e)

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

Posté(e)

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

Posté(e)

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

image.png.21a4093bce95ac2b920ade1d101c0877.png

Je comprends pas ... 😰

Cordialement

oracle7😉

Posté(e) (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é par .Shad.
Posté(e) (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é par oracle7
Posté(e)

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

Posté(e) (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é par .Shad.
Posté(e)

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 :

image.png.c5d870607b1acc54447158994164cf22.png

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

Posté(e)

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

Posté(e)

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

Posté(e)

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

Posté(e)

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

 

 

 

Posté(e) (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é par .Shad.
Posté(e)
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 😉 )

Posté(e) (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é par .Shad.
Posté(e)

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

image.png.d8668e7fb82aa5ee4ebb4709fc55a371.png

et dans le log de telegraf j'ai ceci :

image.png.1539584c91f6736902bf97c7074b32d0.png

D'où mon incompréhension. Une idée peut-être car je ne sais pas décrypter ces messages ?

Cordialement

oracle7😉

Posté(e)

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.

Posté(e)

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 :

image.thumb.png.f037b698348bc0cab115f5e3bd29239c.png

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 :

image.thumb.png.5279f1f780b7511a14814c2fa6d41d95.png

 

Pour Telegraf :

image.thumb.png.d969314535acf0596a461ec41eae05fa.png

 

Et grafana : des erreurs avant le redémarrage du paquet...image.thumb.png.1806b24236b93975abcb23f33254d95e.png
 

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 🤪

Posté(e) (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) :

image.thumb.png.b419f9d9f3be14be565e4f1b666cffcb.png

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é par oracle7
Posté(e)
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 😉 

Posté(e)

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

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.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

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