Classement

Bonsoir @oracle7 et merci, Je prends tous conseils ! Je me bats en effet constamment contre la poussière j'ai peur de l'échauffement à le cloisonné de trop mais je pense le transférer de place après l'upgrade pour le mettre plus à l'abris et éviter d'avoir 4/6disque un peu bruyant dans le salon.

@bliz Bonjour, Sauf erreur de ma part, c'est le cas. Il faut choisir l'une ou l'autre. Cordialement oracle7😉

Je ne suis pas certain que l'upscale d'une vidéo 1080p en 2160p améliore grandement les détails…

Peu de chance que tu ais besoin de transcodage pour ça.

Bonsoir, Un compromis pour quoi? Au début cela concernait la connexion local via le nom de domaine au lieu de l'IP et maintenant la connexion internet via un VPN. Si c'est pour accéder au réseau local, via le nom de domaine? C'est pas vraiment une bonne solution, car la le trafic passe par internet. PC/Mac/TV... (réseau local) > Routeur Synology > Tunnel VPN > Serveur VPN > Internet > Box internet > Routeur Synology > NAS (réseau local) Si c'est pour que certains appareils ce connectent à internet via la VPN, et tous les autres directement par l'opérateur? Alors oui c'est correct.

Sinon, le tuto de @.Shad. sur l'installation de pi-hole en docker ça peut aussi être une bonne solution 😉 et en prime tu gagnes le bloquage des publicités. Perso, j'ai essayé pi-hole, mais je n'ai pas trop aimé... j'ai préféré utiliser Adguard Home. J'ai suivi le tuto de @.Shad. jusqu'aux étapes de pii-hole, où j'ai switché sur AdGH.

@Vista1967 Bonjour, Ne te décourage pas si vite ! 🤪 Lis bien au moins une fois entièrement le TUTO DNS serveur avant de te lancer. Prends ton temps et renseignes toi sur les points techniques qui te generaient. Tu verras ce TUTO n'est pas plus difficile à appliquer que celui que tu viens de faire avec ton routeur RT. Si tu butes vraiment sur un point n'hésites pas à revenir ici, il y aura toujours quelqu'un pour t'aiguiller dans le bon sens ... Au final tu sera gagnant car cela te facilietra la vie de ne plus avoir à saisir/retenir d'@IP. Cordialement oracle7😉

@Vista1967 Bonjour, Si ta box ne gère pas le loopback (ce qui semble être le cas) le plus simple est d'installer le package DNS Serveur sur ton routeur RT et de configurer uniquement la zone locale selon le TUTO : DNS Server. Ne pas oublier alors de bien renseigner l'@IP du DNS Serveur (soit celle de ton routeur 192.168.167.1) sur le routeur dans Centre Réseau/Internet/Connexion. Cordialement oracle7😉

Si depuis le LAN il est possible d'accéder à son ton NAS via son nom de domaine c'est que le loopback fonctionne, sinon non. Et dans les deux cas, il faut que l'accès via le nom de domaine soit OK depuis l'extérieur de ton réseau. Faire un serveur DNS local (soit via vpn server, soit via un pi-hole ou Adguard Home en docker).

recu la ram ce jour 2x16 go https://www.compuram.biz/memory/synology/nas/diskstation/series/ds1621-ds1821/32gb-dual-channel-memory-kit-2x-d4ecso-2666-16g-xd85c.htm reconnu directement par le ds1621+ sans aucun problème. je lance le test ce soir Test ram OK 2023-01-09T20:14:59+01:00 DS1621 findhostd[20576]: util_fhost.c:1196 Memtest passed! # dmidecode 3.2 Getting SMBIOS data from sysfs. SMBIOS 3.1.1 present. Handle 0x001E, DMI type 16, 23 bytes Physical Memory Array Location: System Board Or Motherboard Use: System Memory Error Correction Type: Multi-bit ECC Maximum Capacity: 64 GB Error Information Handle: 0x0021 Number Of Devices: 2 Handle 0x001F, DMI type 17, 40 bytes Memory Device Array Handle: 0x001E Error Information Handle: 0x0022 Total Width: 72 bits Data Width: 64 bits Size: 16384 MB Form Factor: SODIMM Set: None Locator: DIMM 0 Bank Locator: P0 CHANNEL A Type: DDR4 Type Detail: Synchronous Unbuffered (Unregistered) Speed: 3200 MT/s Manufacturer: Hynix Serial Number: 841F0302 Asset Tag: Not Specified Part Number: HMA82GS7DJR8N-XN Rank: 2 Configured Memory Speed: 2400 MT/s Minimum Voltage: 1.2 V Maximum Voltage: 1.2 V Configured Voltage: 1.2 V Handle 0x0020, DMI type 17, 40 bytes Memory Device Array Handle: 0x001E Error Information Handle: 0x0023 Total Width: 72 bits Data Width: 64 bits Size: 16384 MB Form Factor: SODIMM Set: None Locator: DIMM 0 Bank Locator: P0 CHANNEL B Type: DDR4 Type Detail: Synchronous Unbuffered (Unregistered) Speed: 3200 MT/s Manufacturer: Hynix Serial Number: 841F0264 Asset Tag: Not Specified Part Number: HMA82GS7DJR8N-XN Rank: 2 Configured Memory Speed: 2400 MT/s Minimum Voltage: 1.2 V Maximum Voltage: 1.2 V Configured Voltage: 1.2 V

bonjour Marque: Crucial Version : DSM 7.1-42962 Update 3 Référence: CT2K16G4SFRA266 Caractéristiques: 32Go Kit (2x16Go) DDR4 2666MHz CL19 Taille: 2x16 go Modèle du NAS: DS1621+ Compatibilité: oui 32 GB affiché Test synology RAM OK (Memtest passed)

Bonjour à tous, - Marque: Kingston - Référence: KVR16LS11/8 - Caractéristiques: DDR3 / 8 Go / So-DIMM / 1600 Mhz / CL11 - Taille: 8 Go - Modèle du NAS: DS416play (d'origine 1Go de ram) - Compatibilité: fonctionne parfaitement. 8 Go de ram étant le maximum pour ce NAS 😉 ci dessous un lien vers les specs de la barrette Kingston KVR16LS11/8

Bonjour, ma contribution - Modèle : DS920+ à 4Go de RAM d'usine porté à 20 Go - Version : DSM 7.1-42661 Update 1 - Marque : Samsung - Référence : M471A2K43CB1-CTD - Type : 16 Go SO-DIMM DDR4 2666MHz NON ECC 2rx8 - Compatible : Oui l'important : double rang

Edition du 11/01/2023 : Veillez noter que ce fil à été créé il y a 5 ans. Certains chapitres sont maintenant obsolètes, notamment la partie concernant le certificat qui accepte le wildcard ce qui simplifie grandement sa mise en oeuvre. Les images ne sont plus accessibles car l'hébergeur a fermé ses portes. Ce descriptif étant ancien et quelque peu dépassé, je les mettrai à jour seulement si quelqu'un m'en fait la demande. J'ai conservé l'hébergement de ma zone publique à titre de test pendant quelque temps. Aujourd'hui cet hébergement est à nouveau chez OVH. Pour info, lors du rapatriement de ma zone chez OVH, je n'ai pas réussi à supprimer l'enregistrement GLUE à partir de mon interface client. Il a fallu pour cela que je contacte OVH. Mic13710 ________________________________________ Après quelques semaines d’utilisation, je viens vous faire part de ma petite expérience pour la mise en place de mon serveur DNS et de ce qui en a découlé. Tout d'abord je remercie Fenrir pour cet excellent tuto, et aussi (et surtout) pour son assistance lors de sa mise en oeuvre sans laquelle j'aurais sûrement abandonné. Il lui aura fallu beaucoup de patience et de bienveillance pour supporter un boulet tel que moi. Il est vrai que le sujet n'est pas des plus faciles quand on n'est pas de la partie. C'est mon cas. Bref, j'ai voulu aller au bout de la démarche. Possédant un nom de domaine chez OVH et une IP fixe (Free), j'avais les ingrédients nécessaires pour me lancer dans l'aventure. Mon objectif était de : pouvoir utiliser les mêmes url côté WAN et côté LAN, héberger mon propre serveur DNS, par la suite pouvoir m'affranchir des contraintes de ports en utilisant le reverse proxy qui est dispo en natif sur nos NAS depuis DSM 6.0. Il ne me restait plus qu'à trouver le courage et le temps, puis je me suis lancé. Je ne vais pas m'étendre sur la zone DNS locale qui est largement documentée sur le tuto (mais j'y reviendrai plus loin) pour passer sur la partie publique. L'idée étant de tester le tuto jusqu'au bout, j'ai opté pour la troisième possibilité : Être à la fois serveur SOA et NS c'est à dire le point 2 de mon objectif. Tant qu'à être dans la mouise, autant s'y mettre carrément. Mon compte chez OVH étant très basique (juste le nom de domaine) je n’ai pas la possibilité de créer un DNS secondaire. Et comme je n'ai pas non plus la possibilité de l'héberger ailleurs, c'est Fenrir qui m’a permis d'utiliser temporairement son domaine, le temps de la mise en place de mon serveur. Merci à lui. Après quelques errements sur des problèmes de NS, A et CNAME qui bloquaient le processus (Fenrir saura de quoi je parle), j’ai enfin réussi à passer le test Zonemaster pour nos deux serveurs DNS. Ne restait plus qu’à officialiser ces serveurs pour les faire connaître au monde entier. Pour ceux qui sont chez OVH, il suffit d’aller dans l’onglet Serveurs DNS du domaine, de cliquer sur "Ajouter un serveur DNS", de rentrer l’adresse du serveur principal (c’est l’adresse de l’enregistrement NS de la zone publique), d’indiquer son IP publique fixe puis de valider. Faire de même pour le serveur DNS secondaire. La procédure devrait être similaire chez les autres fournisseurs. Personnellement, j’ai rencontré un problème pour la mise en place du serveur de Fenrir. En effet, je n’ai pas pu faire l’enregistrement avec le nom du DNS et son adresse IP, chaque tentative se soldant par un échec. Il m’a fallu faire l’enregistrement en utilisant uniquement le DNS (sans l’adresse IP) et là c’est passé. Je n'ai pas compris pourquoi, mais si ça vous arrive vous pouvez essayer de faire de même. Enfin, j’ai fait un enregistrement GLUE de mon serveur DNS pour qu’il soit diffusé all over the world. Chez OVH, onglet GLUE, bouton "DNS Ajouter". On renseigne les informations du DNS principal (les mêmes que précédemment) et on valide. Une fois les serveurs DNS actifs, je n’avais plus besoin ni des enregistrements de zone que j’avais créé chez OVH ni des serveurs DNS d’OVH. Pour ces derniers, il m’a suffi de les supprimer dans l’onglet DNS (dans mon cas, il s’agissait de ns200.anycast.me et dns200.anycast.me). J’ai tout de même conservé les enregistrements de zone (juste au cas où j’aurais besoin de revenir en arrière ). Mes enregistrements Serveurs DNS ressemblent maintenant à ça : Pour info : puisque j’ai gardé mes anciens enregistrements, j’ai aussi un message dans la page Zone DNS qui m’informe gentiment que j'utilise les serveurs DNS que je viens d’activer (c’est rassurant) et que la zone que j’ai conservée n'est utilisable que si j’active les serveurs DNS d’OVH. A noter que la mise en place définitive des serveurs est quasi immédiate chez OVH mais peut prendre quelques jours pour être diffusée. J’ai dû attendre 3 à 4 jours pour qu’ils soient enregistrés partout. A ce stade, le tuto a été testé, le serveur DNS est fonctionnel et les points 1 (utilisation des mêmes url) et 2 (hébergement de mon serveur DNS) de mon objectif sont atteints. Premières conclusions Tout ça c’est très bien et à condition d’avoir correctement fait les redirections de ports du NAS et du routeur, ça fonctionne à merveille. Mais ça m’avance à quoi par rapport au loopback en natif chez free ? Certes, je ne passe plus par le routeur (loopback) pour mes requêtes sur le LAN (qui se limitaient en réalité à CloudStation), mais en pratique ça n’a rien changé côté utilisation. Si j’indique mondomaine:5001 de l’intérieur ou de l’extérieur j’accède bien en https à mon NAS, comme avant. Pareil pour CloudStation et toutes les autres applis. J'utilise les mêmes url qu'avant et je suis toujours obligé d’indiquer des ports pour accéder aux différents services. Oublier Quickconnect ? Je ne m’en servais pas de toute façon, donc sans intérêt pour moi. Bref, il n'y a aucune différence palpable sur l'utilisation de mon NAS. En l’état, et exception faite qu'il s'agissait aussi de tester le tuto, le serveur DNS ne me sert à rien. Pour que tout ce travail puisse avoir un impact concret sur mon utilisation de tous les jours, il fallait pousser plus loin la démarche en s'affranchissant notamment des contraintes de ports (point 3 de mon objectif). En parallèle, j’avais aussi un soucis à résoudre avec les certificats Domoticz de mes deux Raspberry qui ne sont pas bien reconnus par mon navigateur, ce qui m'obligeait à faire des exceptions pour pouvoir m'y connecter. Et tant qu'à faire, c’eut été bien de pouvoir aussi y apporter une solution. Et c‘est là qu’intervient le reverse proxy. Reverse proxy Une version simplifiée du proxy inversé (reverse proxy) est incluse dans DSM depuis la version 6.0. Elle se trouve dans le portail des Applications et elle est bien suffisante pour mon utilisation. Pour commencer, j’ai modifié et complété mes enregistrements DNS pour y intégrer un certain nombre de domaines. Voici une partie de ces enregistrements. DNS local : DNS publique : Je n’ai pas mis tous mes enregistrements publiques car ça n’apporte rien pour la suite. A noter : hormis le premier enregistrement NS dans la zone publique qui est l’adresse du DNS secondaire (Fenrir), tout ce qui est caché correspond à mon nom de domaine chez OVH. Pour ceux qui suivraient ce tuto et qui utilisent le DNS publique de leur bureau d'enregistrement (points 1 et 2 du DNS publique du tuto de Fenrir), la démarche est la même : les enregistrements sont à faire dans la zone DNS du bureau d'enregistrement (internet). Quelques explications sur les noms de domaine : audio, video, file, cam, get sont les noms que j’ai attribués pour accéder aux applications du NAS. Pour que ces noms soient utilisables à la fois sur le LAN et le WAN, ils sont enregistrés dans les deux zones DNS. domo accède à Domoticz sur le NAS, domo.s1 et domo.s2 à mes deux Raspberry sur lesquels tourne Domoticz. Ces noms sont enregistrés eux aussi dans les deux zones DNS pour être accessibles côté LAN et côté WAN. cam.bureau, cam.cuisine etc… sont les adresses pour accéder à mes caméras. Elles ne sont accessibles que sur le LAN (enregistrements dans le DNS local uniquement). sauvegarde c’est pour mon NAS de sauvegarde, routeur est suffisamment explicite, nas aussi, quant à tv1 c’est ma télé. Ces noms ne sont enregistrés que dans le DNS local. A noter que domo.s1 et domo.s2 ne pointent pas vers des adresses IP de mon LAN mais vers mon nom de domaine. C’est important pour la suite. Dans le portail des applications, j’utilisais jusqu'à présent les alias côté LAN (très pratique) mais c’est incompatible avec le DNS et le reverse proxy de DSM qui n'acceptent que des noms de domaine ou des IP. Je les ai donc désactivés et j’ai activé les ports DSM par défaut pour chaque application. J'aurais pu les modifier, mais ça n'aurait rien apporté en terme de sécurité, d'autant qu'ils ne sont pas accessibles de l'extérieur. A noter qu’il n’est pas utile d’activer les ports https pour le proxy inversé comme nous le verrons par la suite. Puis j’ai rempli les sources et destinations du proxy inversé comme ceci : Côté source, exception faite de video, toutes les adresses en http sont uniquement sur le LAN. Elles utilisent le port standard (80). Les autres (https) sont dispos des deux côtés, LAN et WAN. Elles utilisent le port standard (443). Côté destination, les adresses sont exclusivement en http vers les IP et les ports correspondants aux applications du NAS et aux autres équipements du réseau local (NAS de sauvegarde, Raspberry). Il est en effet inutile et contreproductif de doubler les chiffrements (une fois à la source, une autre fois à la destination). Et pour que ça puisse fonctionner, j’ai dirigé dans le routeur le port 443 vers le NAS, et je l’ai ouvert dans le pare-feu du NAS. Et là j’ai rempli mon dernier objectif : plus besoin d’indiquer des ports puisque tout passe par les ports standards http (80) ou https (443). Maintenant, quand je rentre par exemple https:\\file.mondomaine côté LAN ou WAN, j’accède à File Station via l’adresse http:\\localhost:7000. De même, avec https:\\audio.mondomaine, j’accède à Audio Station via l’adresse http:\\localhost:8800. Mais un des gros avantages que j’ai trouvé au serveur DNS combiné au reverse proxy c’est la possibilité d'accéder à mes Rasp en https sans utiliser leurs certificats. En effet, si je rentre https:\\domo.s1.mondomaine, j’accède bien à Domoticz sur mon Raspberry 1, sans passer par le certificat Domoticz puisque le reverse proxy communique avec lui via une adresse en http. Le serveur DNS transfère l’adresse https non pas vers le Rasp mais vers le NAS comme on l’a vu plus haut et de là, c’est le reverse proxy qui met en relation le NAS avec le Rasp. C’est donc le certificat du NAS qui est sollicité. Et voilà, tout devrait maintenant fonctionner comme prévu. Hélas non. Il reste encore une dernière action à mener, c’est justement sur les certificats : ils ne fonctionnent pas correctement ! Certificats Comme beaucoup ici, je suis chez Let’s Encrypt via le NAS et on ne peut pas dire que la documentation Synology soit foisonnante sur la manière de gérer ces certificats. Il faut d'abord commencer par comprendre comment se comporte DSM avec les noms de domaine nouvellement créés. Lorsqu’une nouvelle source en https est créée dans le proxy inversé, DSM inscrit automatiquement le nom du domaine dans la rubrique "Pour" du certificat par défaut. On pourrait croire que ce nouveau domaine est pris en compte par le certificat, or il n’en n’est rien. Il s'agit seulement pour DSM d'associer un domaine à un certificat et en l'occurrence, c'est celui défini par défaut qui est choisi. Ce n'est en aucun cas une validation. Les seuls domaines couverts par le certificats restent le domaine principal et ceux inscrits dans le SAN (rubrique "Autre nom de l’objet"). Il n'y a aucun changement ni sur la validité, ni sur le périmètre de couverture du certificat. Il faut donc éditer le certificat existant pour y inclure les nouveaux domaines, et comme DSM6.0 et au-delà permet de faire cohabiter plusieurs certificats, il sera peut-être nécessaire d’en rajouter. En effet, alors que chaque certificat Let’s Encrypt peut gérer jusqu’à 100 SAN en natif, la rubrique "Autre nom de l’objet" du NAS n'accepte pas plus de 256 caractères ce qui peut être rapidement atteint selon le nombre de noms à saisir et leurs longueurs. D’où la nécessité de devoir créer plusieurs certificats. Cette limite est semble t'il contournable mais il faut pour cela passer en SSH pour modifier les paramétrages. Je ne le conseille pas. On peut aussi les créer en externe (PC, MAC, Rasp, autre) et les importer dans le NAS, mais on perd du même coup le renouvellement automatique et il faudra alors le faire manuellement tous les 3 mois ou moins. Pour ma part, j’ai utilisé ceux proposés par DSM. Et puisque c'est possible et pour que ce soit plus clair, j’ai créé 3 certificats : un par défaut que j'ai appelé "Principal" qui couvre les applis de base (CloudStation, VPN, mail serveur, ..), un autre que j'ai appelé "Applications" qui couvre les applis DS (audio, video, file, cam, get ...), et un autre que j'ai appelé "Domoticz" pour la domotique. A partir de l'onglet "Certificats" du module "Sécurité" du panneau de configuration (vue ci-dessus), on peut soit créer un certificat, soit éditer un certificat existant. Dans les deux cas, il faut cliquer sur le bouton "Ajouter" et dans la page qui apparait on choisit soit "Ajouter un certificat", soit "Remplacer un certificat" et on sélectionne celui à remplacer. Selon le choix, sur la page suivante on rempli ou on modifie la description du certificat puis on choisi "Procurez-vous un certificat auprès de Let’s Encrypt". Dans l’exemple ci-dessous, j’ai choisi de modifier mon certificat Domoticz. En cliquant sur suivant, on arrive à la page des paramétrages. C’est la même, que ce soit pour une création ou une modification (les champs ne sont pas renseignés avec les données de l’ancien certificat). Après avoir complété le nom de domaine (mondomaine) et l’adresse email valide, il faut renseigner la rubrique "Autre nom de l’objet" (le fameux SAN) avec tous les noms de domaine complets à couvrir, séparés par des " ; " . Exemple pour mon certificat Domoticz : domo.mondomaine;domo.s1.mondomaine;domo.s2.mondomaine Important : il faut que tous les noms de domaine soient valides. Pour cela, ils doivent impérativement avoir un enregistrement A ou CNAME dans le serveur DNS publique car Let's Encrypt vérifie l'existence de chaque nom. Si on indique dans le SAN un nom de domaine qui n’existe pas ou pas encore, le certificat ne sera pas créé. A ce sujet, le message renvoyé par DSM en cas d’échec est assez déroutant. Au lieu de signaler qu'il y a un ou plusieurs domaine(s) qui n'existe(nt) pas, le message indique qu’il y a un problème sur le port 80 qui n'est pas ouvert. Comprend qui peut. Une fois tous les certificats créés, il reste une ultime étape : leur attribution pour chaque nom de domaine et chaque application. Pour cela, dans la page des certificats, il suffit de cliquer sur le bouton "Configurer", de choisir pour chaque ligne quel certificat est applicable puis de valider. Cette opération terminée, tout fonctionne correctement, je n’ai plus de soucis avec mes connexions https. Conclusion La mise en oeuvre a été longue et laborieuse, avec beaucoup d'erreurs de ma part, d'incompréhensions parfois car le sujet est assez complexe, mais au final je suis très satisfait du résultat. Objectif atteint. Voilà. Je suis sûr qu’il y a beaucoup à redire sur ce que j’ai fait, qu’il y a certainement mieux à faire. Certes, je suis ouvert à toute proposition d’amélioration. Je souhaite en tout cas que ça puisse aider la communauté.

Bonsoir à toutes et à tous. Le week en dernier, j'ai eu le même problème avec le RAID5 Cassé avec 3 disques non initialisé, certainement à cause d'un problème électrique bien que j'ai un onduleur, mas cela doit être confirmer, mais passons sur la cause problème. Dimanche j'ai passer une partie de la l'après midi pur savoir comment me dépatouiller de ce problème et surtout comprendre que le support Synology peut et sait résoudre ces problèmes Dimanche soir : demande d'assistance faite chez Synology Lundi : Rien ... c'est flippant mais bon, l'impatience est là Mardi midi : réponse du support, me proposant l'accès à distance avec ouverture des port, mot de passe temporaire. n'étant pas un foudre de guerre coôté réseau, les instructions sont claires et le moyen de tester l'ouverture des port simple Mardi soir : Config du routeur, du Syno faite et testées ... et désactivation du bip pour le RAID cassé Mercredi matin : Tient, un petit bip du Syno me sort de la torpeur matinale. Toujours en pyjama je jette un oeuil une heure plus tard, tout est en order de marche Mercredi Message de synology me dit que c'est réparer avec quelques conseils Elle est pas belle la vie ? Comme quoi le support Syno est efficace et qu'il n'est pas nécessaire de se faire des noeuds au cerveau, il savent résoudre les problèmes et vite

Bonjour je vais t'expliquer la connerie qui a été faite en éteignant l'extension dx510 tu as cassé le raid5 c'est le ds1010 qui gère l'extension, tu aurais du passer par la dsm pour faire un arrêt propre avec 2 dd non initialisé le raid5 est difficilement réparable, soit tu as pris la précaution de faire une sauvegarde et tu recrées le volume, soit tu ouvres un ticket chez syno en leur donnant un acces ssh et ils vont tenter de recréer la grappe raid5 n'oublies pas qu'un nas en raid doit rester allumé 24/24 7/7 sur un onduleur et ne te dispense pas de sauvegarde régulière de tes données Patrick

Moche un truc hd sur une tv 4k sans travail par le nas.

Je ne veux pas regarder des vidéos de quelques années en noir et blanc (j'exagère, mais un peu)