Mic13710

La demande n'est pas très claire. Qu'est-ce qui est branché en USB ? Si c'est entre le DAC et le NAS, ça ne peut pas fonctionner car la diffusion des contenus multimedia du NAS en DLNA se fait par le réseau Ethernet. Il faut donc que votre DAC soit connecté sur le même réseau que le NAS soit en wifi, soit en ethernet.

Je vous invite à consulter ce tuto :

Le message me semble assez clair : il y a un ou plusieurs problèmes du côté de votre zone DNS chez ovh. Est-ce que vous avez bien un dynhost sur votre ndd et est-ce que l'IP est bien l'IP publique actuelle de votre box ? Dans ce cas, vous ne devez pas avoir dans la zone DNS d'enregistrement A pour le ndd. Est-ce que vous avez bien un enregistrement wildcard *.ndd CNAME ndd dans votre zone ? Est-ce que vous avez paramétré la mise à jour automatique de l'IP dans le menu Accès externe / DDNS ? Ne pas oublier aussi que Let's Encrypt limite le nombre de tentatives de création de certificats pour le même domaine à 5 je crois. Si c'est le cas, il faut attendre 7 jours depuis la dernière tentative avant de pouvoir demander un nouveau certificat.

@d_mu je ne comprends toujours pas pourquoi vous vous obstinez à utiliser un nom de domaine qui n'est probablement pas celui que vous souhaitez avoir au final. Je vous ai déjà dit dans un autre post qu'il fallait créer votre dynhost directement sur votre ndd. Si vous créez votre dynhost avec l'adresse dynhost.ndd comme vous le faite, toutes vos adresses devront être sur ce nom et votre wildcard aussi devra être *.dynhost.ndd. Je ne vois pas l'intérêt de travailler avec un ndd aussi compliqué. La seule utilisation d'un dynhost avec un ndd spécifique c'est lorsque vous avez plusieurs sites avec des IP dynamiques qui utilisent le même ndd commun. Dans ce cas, vous créez un dynhost pour chaque site : site1.ndd site2.ndd etc... Et dans ce cas aussi, vous créez un certificat pour chaque site : site1.ndd et son wildcard *.site1.ndd pour atteindre les services du site1 site2.ndd et son wildcard *.site2.ndd pour atteindre les services du site2 etc... Comme je suppose que vous n'avez qu'un ndd pour un seul site, pas besoin d'un dynhost de second niveau. Je pense que vous vous mélangez les pinceaux entre dynhost.ndd et ndd. Aussi, je vous conseille de tout effacer : vos API chez OVH, vos certificats, votre session Docker, le contenu de votre dossier Acme et de tout reprendre à partir de votre ndd uniquement.

Merci pour ce partage. Je ne connaissais pas. Son labo est effectivement impressionnant, même pour un professionnel.

Le problème est maintenant résolu. N'hésitez pas à ouvrir un nouveau message en cas de problème. Ceci est une réponse automatique.

@PiwiLAbruti c'est comme ça depuis des années (plus de 10 ans pour mes plus lointains souvenirs) et ça n'a jamais été corrigé. De ce que j'ai constaté, il s'agit d'applis qui n'ont pas été fermées correctement. Est-ce pour autant que la connexion reste active ? je ne sais pas mais en regardant ma liste, j'ai des connexions de plus de 320h dont l'IP n'est plus valable. Et si j'ouvre la même appli DS à partir du même terminal, j'ai une nouvelle session qui s'affiche. Si je la ferme proprement, elle disparait. Il est clair que la gestion de ces connexions devrait être améliorée.

Je pense qu'une mini centrale nucléaire devrait faire l'affaire 😄. C'est pas un peu too much ? A moins d'avoir des équipements qui nécessitent une alimentation permanente, je ne vois pas ce qu'apporterait un groupe électrogène en terme de sécurité pour le NAS. Ce qui importe c'est de permettre à ce dernier de se mettre en sécurité proprement en cas de coupure secteur, c'est ce qu'assure l'UPS.

GET me/api/application/{applicationid}. Vous indiquez le numéro de l'application puis Execute, ce qui vous donnera le nom, la description, le status et l'applicationKey de l'api.

Je ne crois pas que les clés soient accessibles. Le mieux c'est de recréer une nouvelle API et de bien sauvegarder les clés pour une utilisation future. Pour voir les API actives : https://api.ovh.com/console/ Vous vous connectez avec vos identifiants. GET me/api/application puis Execute. La liste de vos API actives apparait. Pour les supprimer : DELETE me/api/application/{applicationid}. Vous indiquez le numéro de l'application donné par le GET que vous voulez supprimer puis Execute.

Et pourquoi ne pas tout simplement créer votre dynhost directement sur le ndd ? Il suffit de laisser le champ vide et c'est le ndd qui sera pris en compte.

Oui mais ce n'est pas dans about me mais dans Paramètres du compte, menu Signature !

Pour qu'une signature soit visible, il faut remplir le champ Signature dans votre profil, ça aide 😉

Et par les temps qui courent, c'est loin d'être un point de détail : la consommation. Un NAS DIY est en général beaucoup plus gourmand en énergie qu'un Synology ou un QNAP.

Ce ne sont pas les disques qui sont protégés par un onduleur mais les données qu'ils stockent. Un line interactive est surtout recommandé sur des réseaux perturbés car il inclut un AVR en entrée qui permet de compenser des variations de tensions plus importantes que ne peut le faire un off-line. Le surcoût n'est pas négligeable. Si un line-interactive est quasi indispensable en zones rurales du fait des distances et de la distribution quasiment en aérien qui augmentent les instabilités des réseaux, il est très peu utile en zone urbaine où les réseaux de distribution sont mieux protégés des perturbations. On peut bien évidemment mettre un line interactive même si le réseau ne l'exige pas. En revanche, un off-line sur un réseau instable n'est pas le meilleur choix qu'il soit car l'onduleur sera trop souvent sollicité ce qui réduira la durée de vie de la batterie. C'est bien la qualité du réseau qui dicte la technologie à utiliser.

J'ai dit que je n'étais pas sûr que ça puisse fonctionner. Rien ne vous empêche d'essayer. Il faudra cependant être très prudent car il ne faudrait pas qu'une erreur de parametrage ne vienne purement et simplement effacer le contenu du dossier que vous voulez synchroniser. Il serait préférable de faire des essais sur un dossier de test avant de lancer la solution en prod. Synology Drive client existe aussi sous linux. A voir si votre serveur peut le supporter. Ceci étant dit, vous pouvez très bien passer par une solution de sauvegarde ou de synchro fonctionnant sous linux que vous installez sur le serveur. Je n'en n'ai pas à vous proposer, mais peut-être que d'autres intervenants pourront vous aider.

Tout d'abord, Drive ne peut synchroniser que des dossiers, pas des lecteurs. S'il y a plusieurs dossiers à synchroniser, il va falloir créer un dossier principal qui regroupe tous ces dossiers. Ensuite, pour ne l'avoir jamais essayé, je ne suis pas sûr que Drive permette de faire une synchro sur des dossiers localisés sur un lecteur réseau car il y a des risques de pertes de synchro. Ne serait-il pas possible d'installer Synology Drive client directement sur le serveur de l'entreprise ?

Vous pouvez tout à fait créer un compte spécifique pour votre sauvegarde, mais vous ne pourrez pas faire cohabiter sous une même session windows deux connexions sur des comptes utilisateurs différents. A vous de voir si ça peut correspondre à ce que vous voulez. Hyperbackup est une application qui nécessite un compte d'administration pour pouvoir mettre en place et effectuer une sauvegarde. Vous pouvez au choix utiliser votre compte d'administration ou un compte que vous créez pour cette tâche et qui a des droits d'administration limités à cette seule tâche. Mais votre demande initiale était de connecter un lecteur réseau, puis vous parlez de Synology Drive dans votre deuxième message ce qui n'a rien à voir avec un lecteur réseau, et maintenant on en est à Hyperbackup. J'avoue être un peu perdu.

Sans oublier de lui attribuer les droits aux utilisateurs qui y auront accès 😉

Dès lors qu'il y a un accès externe, les risques d'attaques existent. Le tout est de bien les évaluer et de faire en sorte de les contrer le mieux possible. Un parefeu bien réglé et des mdp forts sont des armes suffisamment efficaces pour arrêter la quasi totalité des tentatives de connexion non sollicitées et inciter les hacker à chercher des proies plus faciles. Vous pouvez aussi utiliser le serveur VPN du NAS pour sécuriser un peu plus vos échanges. Tout est affaire de compromis.

C'est très exactement ce qu'il ne faut pas faire. Un compte d'administration ne doit servir qu'à l'administration du NAS. Il ne doit pas être confondu avec un compte utilisateur. Je vous conseille de séparer les deux (ce qui vous permettra du même coup d'éviter la double authentification sur le compte utilisateur), et aussi de supprimer le compte par défaut "admin" qui est le plus sujet à des attaques (voir le tuto sur la sécurisation de nos NAS)

Perso, je réserve la double authentification au compte administrateur pour accéder à DSM car c'est la partie la plus sensible de nos NAS. Je ne l'applique pas pour l'accès aux comptes utilisateurs car j'estime qu'il doit se faire le simplement possible et que les données à protéger ne nécessitent pas de sécurité renforcée qui de plus peut poser des problèmes de connexions. Un MDP fort et un parefeu qui bloque intelligemment sont amplement suffisants pour protéger l'accès aux données sans avoir à rajouter une couche de sécurité supplémentaire.

Oui. Le SHR étant plus souple que le RAID classique, je vous conseille de choisir le SHR. C'est de toute manière l'installation par défaut.

C'est super ! Mais avant de vous lancer dans des transferts de fichiers et autres, je vous conseille vivement de commencer par consulter et mettre en pratique le tuto sur la sécurisation de votre NAS.

Pas vraiment. Un back-up c'est une sauvegarde or ce n'est pas le cas ici. Avec votre groupe, vous aurez les données préservées en cas de perte d'un disque, et ce quel que soit le disque du groupe.