Aller au contenu

.Shad.

Membres
  • Compteur de contenus

    6648
  • Inscription

  • Dernière visite

  • Jours gagnés

    150

Tout ce qui a été posté par .Shad.

  1. .Shad.

    Petit nouveau

    Bienvenue parmi nous 😉 N'hésite pas à détailler ton matériel, ça permettra de cibler nos réponses suivant ses capacités.
  2. .Shad.

    Bonjour à tous

    Bienvenue parmi nous !
  3. Là tu as créé des actions qu'il va interpréter ligne par ligne au démarrage, donc il va exécuter : case $1 in puis : start) Forcément ça ne peut pas marcher. Il te faut créer un fichier S99mount.sh par SSH et le compléter avec le script cité par le tutoriel. S'assurer aussi qu'il soit exécutable : chmod u+x S99mount.sh Pour moi si tu places ce fichier dans le dossier en question, tu n'as pas besoin de faire de tâche planifiée. Après c'est clairement pas le genre de manipulation que j'irais faire...
  4. Oui et là je ne peux pas t'aider, j'y connais rien. 😛
  5. Tu n'as pas réagi à cette partie 😉
  6. J'avais dû utiliser cette image un temps pour faire fonctionner LibreNMS : https://hub.docker.com/_/memcached Il existe peut-être un démon memcache sur le NAS, à investiguer.
  7. 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.
  8. Il y a un tutoriel complet à ce sujet justement :
  9. 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é. 😉
  10. J'ai répercuté dans le tutoriel le changement de nom de l'image (linuxserver/letsencrypt ->linuxserver/swag). Si vous avez mis en place cette solution, il suffit de changer le nom de l'image dans le fichier docker-compose et de recréer le conteneur : docker-compose pull puis : docker-compose up -d
  11. 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 :
  12. @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.
  13. Sachant que c'est l'argument qui me fait choisir WD plutôt que Seagate, ça me ferait mal au c*l quand même. 🤬
  14. Ç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.
  15. 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. 😉
  16. .Shad.

    [Tuto] Reverse Proxy

    Apparemment la méthode lan.list est l'ancienne méthode, as-tu essayé la fonction Custom DNS directement disponible dans le GUI de Pi-hole ? Essaie de reproduire ce que tu as avec lan.list dans la GUI. Puis tu fais sur ton PC par exemple dans l'invite de commandes ou sur Linux : nslookup video.ndd.fr IP_du_Pi-Hole Tu as installé Pi-Hole de quelle manière ?
  17. 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.
  18. 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 😉).
  19. 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.
  20. 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 compte admin/admin ou admin/password. Ou alors tu laisses "public" et 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. Le tutoriel a comme postulat une installation locale, avec des applications isolées dans un bridge personnalisé et un minimum de NAT NAS <-> conteneur, dans ce cas-là il n'y a aucun risque de laisser "public" comme communauté. Ce n'est pas la même histoire quand on prendre l'autoroute de l'Internet. 😉
  21. Ben il faut exposer le port 161 publiquement sur le NAS2 si tu veux que NAS1 y accède, ou alors mettre en place un VPN site à site. C'est toi qui vois. La communauté est définie sur un périphérique, et dans Telegraf pour chaque inputs.snmp tu définis la communauté du périphérique qui va être pollé. Je ne vois pas en quoi ça affecte ce que tu as déjà mis en place.
  22. Tu peux c'est juste que tu dois ouvrir le port 161 (SNMP) vers l'extérieur. Utiliser SNMPv2 au minimum avec un nom de communauté costaud 🙂 Je ne sais pas si on peut utiliser SNMPv3 mais ce serait préférable.
  23. .Shad.

    [Tuto] Reverse Proxy

    Quasi certain que le problème vient des alias DNS renseignés dans Pi-Hole, est-ce que tous les sous-domaines utilisés pour faire du proxy inversé pointent bien vers le NAS, quelque soit la machine hébergeant le service derrière ? Si tu peux mettre une impression d'écran (en cachant ton nom de domaine) de tes alias dans Pi-Hole stp.
×
×
  • 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.