.Shad.

Est-ce que c'est bien le même utilisateur qui exécute le script et celui pour lequel tu édites crontab ? Quand tu fais crontab -e ça t'ouvre le fichier des tâches propres à cet utilisateur.

Ben nos idées on te les a données. D'ailleurs en voilà une autre, c'est une très mauvais idée que d'activer l'uPnP sur son routeur, et de s'en servir avec le NAS. Si un malware s'y loge, il peut ouvrir tous les ports qui lui chantent.

C'est bien aussi de ne pas dépendre d'un seul périphérique ! Bienvenue 🙂

Salut, attention ne pas confondre l'IP statique de ton routeur délivrée par le serveur DHCP de la box (ou fixée dans le routeur) et l'IP sur la patte WAN de ta Freebox, ce sont deux choses qui n'ont rien à voir. Je rejoins @maxou56 sur le fait que tu n'as sûrement pas d'IP full stack. Sinon pour accéder à DSM via Internet, il te faudra soit router le port 443 comme suggéré conjointement avec un proxy inversé, ou router le port 5000 (http) ou 5001 (https) depuis la box jusqu'au NAS comme précisé ci-avant.

Top, ça va sûrement en aider plus d'un 🙂

Avec LibreNMS j'avais réussi à avoir les infos aussi, et LibreNMS n'utilisent que le SNMP, en tout cas si tu arrives à trouver ça ce serait super ! Et bravo pour le tutoriel pour la Freebox, je vais ajouter un lien dans mon tutoriel.

J'avais trouvé une discussion sur Github à ce sujet, apparemment c'est simplement que Synology a changé ses MIB pour l'UPS et du coup ceux renseignés dans telegraf.conf n'extraient plus les données, car ils se basent sur des noms d'OID qui ne sont plus valables. Si on voulait que ça marche il faudrait directement faire appel aux OID, mais comme je n'ai jamais pris le temps de me plonger là-dedans, je ne sais pas exactement comment réparer ça.

Salut, Normalement il faut choisir le measurement "snmp.SYNO" et le field "sysUpTime". Pour l'affichage, une métrique "mean" ou "last" doit marcher. Je n'y ai pas accès là je peux pas te dire, mais je n'ai pas rencontré de problème avec ce champ. En revanche je n'ai jamais réussi à remonter les infos de l'UPS via le telegraf.conf du NAS.

Malheureusement je n'ai jamais rencontré le moindre problème avec Windows, ce que ça signifie par contre c'est qu'au niveau de ton NAS il n'y a aucun problème. Il faut investiguer du côté de W10.

Tu as beaucoup de données ? Tu n'as pas plus vite fait d'enregistrer tout sur un disque externe, et faire une installation from scratch en brefs avec tes deux disques en SHR ? Tu peux toujours exporter la config de DSM avant de reset et la réimporter apres.

Bienvenue 🙂

Ca c'est ce qu'on met dans /etc/fstab pour faire un automount au démarrage du rpi. Tu dois plutôt tester ça : sudo mount -t cifs -o vers=3.0,credentials=/home/pi/.smbcred //192.168.1.12/documents /mnt/nas/documents Justement ne pas mettre vers=1.0, pour voir si ça marche en SMB3 avec un Linux.

Pas d'infos plus précises dans /var/log/messages ? Sur aucun des 3 NAS ?

Est-ce que tu peux essayer un montage SMB depuis une distrib Linux ?

Et il y a certains paramètres pour lesquels on est obligé de passer par SSH, genre par exemple définir les comptes habilités à se connecter à la partie Admin du serveur ? ou définir un serveur SMTP pour l'envoi de mails ? Après ce n'est pas foncièrement différent, et ça consomme beaucoup moins de mémoire, par contre attention, certaines fonctionnalités ne sont pas implémentées : https://github.com/dani-garcia/bitwarden_rs/issues/246

Oui ça devrait marcher, s'il a bien associé nas.ndd.net chez son registrar à son IP, dynamique ou statique. Mais avec la redirection HTTP -> HTTPS (voir son dernier post), ça tente de l'amener sur le port 5001, qui lui n'est pas redirigé, à mon avis ça coince par là. S'il décoche cette option, je pense que ça marchera, tout autre problème mis de côté. Mais il faut qu'il abandonne l'idée d'utiliser https://nas.ndd.net pour accéder au NAS tant qu'il n'a pas mis en place un proxy inversé. @PiwiLAbruti : Je pense qu'il était question d'accéder à son NAS depuis l'extérieur dans cette question, non ? Dans ce cas-là c'est juste sa zone DNS qui doit être bien réglée. Sauf s'il est héberge aussi sa partie publique, mais ce n'est pas clair dans ses propos.

Si on garde précieusement le code de récupération, c'est intéressant en effet ! Car si ton portable tombe en rade ou qu'il faille le reset usine, t'es bien embêté 😛

Le moyen le plus sûr de protéger les données comme l'a dit @maxou56 est d'avoir une porte 5 points de verrouillage, d'une bonne épaisseur, et avec un système de sécurité qui prévient en cas de tentative d'intrusion. C'est ton pare-feu et le paramétrage de DSM qui est cette porte. L'autre implication, et elle n'est pas minime, c'est que ce tutoriel ouvre l'ensemble des ports au réseau local. Parce qu'on part du postulat que le réseau est sûr. Mais un exemple simple, si tu montes les dossiers partagés de ton NAS via SMB avec des utilisateurs ayant des droits en écriture sur le NAS ou si tu utilises Drive en bi-directionnel, le pare-feu ne fera pas son office parce qu'il a "confiance" en ton PC, ton Mac, ton iPhone, etc... Et quand on voit comment certaines personnes cliquent sur les PJ de n'importe quel mail, ou ne sont pas prudents lorsqu'ils naviguent sur le web, je me dis que les moyens de contamination restent conséquents chez beaucoup.

Très intéressant. 😮

Je vais, comme @Jeff777 essayer de te résumer ce à quoi doit ressembler ton architecture pour que ce que tu veux faire fonctionne. il y aura de la redite sûrement, mais je n'ai pas le courage de parcourir les 3 dernières pages avec des infos dans tous les sens. Tu souhaites atteindre l'interface de ton NAS, que tu sois en local ou à l'extérieur, depuis https://nas.ndd.net, juste ? https://nas.ndd.net c'est équivalent à https://nas.ndd.net:443, donc ça veut dire qu'il faut utiliser un proxy inversé, sauf erreur de ma part, je ne vois nulle part que tu en as mis un en place, donc déjà ça ne peut pas marcher. Pour la partie LAN : PC 1 souhaite accéder à https://nas.ndd.net | PC 1 interroge le(s) serveur(s) DNS que le serveur DHCP lui renseigne, si tu veux une résolution locale, il doit pousser uniquement l'IP de ton NAS | Ta zone locale ndd.net dispose des entrées précisées plus avant par @Jeff777 (une entrée NS, A et CNAME). Attention aux vues, si tu les as configurées (voir ce tutoriel). | Le serveur local fait autorité pour ta requête, il transmet donc la requête à IP_PRIVEE_DU_NAS:443. Si tu n'as pas mis de proxy inversé en place, il n'y aura aucune raison que cette requête soit redirigée vers IP_PRIVEE_DU_NAS:5000 ou IP_PRIVEE_DU_NAS:5001, c'est le port 443 qui va être sollicité. | Une fois le proxy inversé en place, deux choses vont activer le mécanisme du proxy inversé, le nom de domaine demandé (nas.ndd.net) et le port (443). C'est ce qu'on appelle un frontend, c'est ce qui fait face, l'association de ces deux critères va, lorsque tu auras créé l'entrée appropriée, lui permettre de dire que ça correspond au backend (service en arrière-plan) officiant sur IP_PRIVEEE_DU_NAS:5000 (ou localhost:5000 vu que le proxy inversé et DSM sont sur la même machine) en http ou IP_PRIVEE_DU_NAS:5001 (localhost:5001) en https (on recommande d'utiliser le port HTTP lorsqu'on passe par un proxy inversé). ATTENTION : SI tu utilises le port HTTP, la redirection HTTP -> HTTPS doit être désactivée dans le paramétrage du NAS (voir tutoriel sur la sécurisation, c'est précisé noir sur blanc) | Ta requête aboutira sur la page de login de DSM A aucun moment on ne passe par le routeur dans cette chaîne, il intervient juste en amont dans l'adresse DNS qu'il aura poussée par son serveur DHCP. Les conditions à remplir : - Les ports 443, 5000 sont ouverts vers l'environnement local (voir tutoriel sur la sécurisation du NAS) - Tu disposes d'un certificat pour le domaine ndd.net (voir tutoriel sur la sécurisation du NAS) - Le certificat est associé pour chaque service exposé par ton proxy inversé ________________________________ Bien maintenant la partie WAN : Mobile 1 souhaite accéder à https://nas.ndd.net | Il interroge ses DNS, ceux de Google ou de ton FAI ou qu'importe | La réponse n'étant pas trouvée sur ces serveurs, la requête part aux serveurs racines, et va descendre la chaîne (root -> .net -> .ndd.net). Ok c'est là que ta zone DNS chez ton registrar entre en jeu. Si tu es IP statique, tu as les mêmes enregistrements que dans ta zone locale, avec ton IP publique statique à la place de IP_PRIVEE_DU_NAS. Si tu es en dynamique, alors tu dois créer un Dynhost, moi je partirais sur dynhost.ndd.net (différent de toute entrée de proxy inversé que tu pourras créer) qui va faire le lien entre ton IP dynamique et ta zone DNS, tu n'auras pas d'enregistrement de type A, mais un alias CNAME entre nas.ndd.net et dynhost.ndd.net | Donc là tu interroges l'IP associée à ton Dynhost, donc https://nas.ndd.net correspond à IP_PUBLIQUE:443, c'est ton routeur qui va recevoir ça. Tu veux que ton proxy inversé reçoive la requête, il faut donc qu'il redirige le port 443 vers l'IP prviée de ton NAS, ainsi le proxy inversé va être le frontend. | A partir de ce moment-là, on retombe dans le cas de figure de la résolution locale, le proxy inversé va voir une requête avec un domaine (nas.ndd.net) et un port (443). Il va ensuite rediriger vers le backend correspondant. Les conditions à remplir sont similaires à celles pour la partie LAN, avec en outre : - dynhost.ndd.net qui doit faire partie des alias repris par le certificat - Le port 443 correctement redirigé vers le NAS depuis ton routeur ________________________________ En dernier lieu, je ne comprends pas ton acharnement à ne pas essayer de comprendre ce que tu fais, appliquer c'est bien, mais ce forum n'est pas un SAV, si tu n'as pas le temps ou/ni l'envie de comprendre ce qui y est proposé, peut-être devrais-tu te contenter de QuickConnect ou d'un accès à ton NAS en précisant les ports. La mise en place d'un serveur DNS local (et encore plus d'un publique) avec un nom de domaine valable suivant plusieurs vues est l'aboutissement d'au moins 3 ou 4 tutoriels références de ce forum, ça demande clairement que les notions abordées dans les autres tutoriels soient assimilées (et encore une fois, Fenrir le précise noir sur blanc d'emblée dans son tutoriel)

Pour une utilisation desktop, un adblock, ublock, etc... sera beaucoup plus efficace que Pi-hole, car il redéfinit l'agencement de la page pour cacher les emplacements de pub, Pi-hole en est totalement incapable. Là où Pi-hole brille, c'est sur mobile, où on n'a pas d'outils aussi performants, voire pas d'outil du tout : objets connectés, Smart/Android TV, etc... Pour les objets connectés, ça permet de vérifier notamment qu'il n'y a pas de fuite de données vers des sites suspects 🙂

Salut, on aime bien que le premier post soit réservé à la présentation, même pour une question avant achat 🙂 Pour ta question, il n'y a pas besoin d'avoir des modèles aussi puissants pour l'utilisation que tu prévois, un modèle J conviendra parfaitement. Pour le nombre de baies, et bien ça c'est à toi de le définir suivant l'évolution à court, moyen, long terme ? Se poser aussi la question de la sauvegarde de ces données.

Bienvenue ! Normalement les tutoriels présents sur ce forum sont assez complets pour l'utilisation que vous prévoyez. Quand on ne connaît pas le mieux c'est de demander surtout 😛

En gros bind9 c'est la référence des serveurs DNS en ligne de commande, il y a pléthores de tutoriels sur le net pour le configurer. Quand tu n'as pas deux NAS c'est pratique 😛 Pi-hole c'est un bloqueur de pub par DNS, qui fonctionnent sur les noms de domaine et les expressions régulières. Et ça s'héberge facilement via Docker ou VM sur ton NAS 🙂

Il te faut dé-commenter dans le fichier de configuration ovpn la ligne : redirect-gateway def1