Mic13710

Comme @firlin, je conseille de repartir de zéro. Oui, la migration est possible mais elle embarque avec elle toutes les limitations du NAS d'origine. La taille maximum du groupe en est une mais la plus importante à mes yeux est l'impossibilité de passer au btrfs. Les disques sont en ext4 et le resteront ce qui ne permet pas d'exploiter correctement le futur NAS.

Ici : https://global.download.synology.com/download/Package/spk/CloudStation/3.2-3501/CloudStation-evansport-3.2-3501.spk Il s'agit de la version 3.2 qui semble être la dernière pour votre NAS (cpu Evansport). A votre place, j'attendrais encore un peu car Synology semblent être disposés à mettre à jour DS Cloud pour qu'il soit compatible avec la dernière version de Drive. I En effet, Drive était compatible avec la suite Cloud Station jusqu'à la version 3. Cette compatibilité a été abandonnée depuis, ce qui explique que DS Cloud ne soit plus fonctionnel. Mais vu les retours négatifs des utilisateurs, DS Cloud devrait être à nouveau disponible dans la suite Drive. Quand ? Aucune idée.

Malheureusement, les bruits inhérents aux disques classiques sont difficilement gérables. Les disques red pro sont particulièrement bruyants du fait qu'ils soient en 7200tr. Même au repos, le nas continue de travailler sur différentes opérations générant des accès disques quasi permanents. La fixation des disques dans le NAS peut aussi être une source de bruit non négligeable. Vous pouvez aussi opter pour un pad anti vibration à placer sous le NAS pour éviter que les bruits soient transmis à l'étagère et au meuble.

@jacaj oui, je connais le fil de catimini, mais il n'est pas arrivé plus loin que DSM6 et c'est extrêmement compliqué. La méthode rapportée par Xims et tout de même plus digeste et surtout elle assure les maj jusqu'à la dernière version de la branche DSM6. J'ai consulté la page facebook de simkard et effectivement, il semble avoir franchi le pas sur un 710. J'ai d'ailleurs trouvé étrange que le CPU indiqué soit celui du 712 (Atom D425 au lieu de 410) alors que sur le 1010, c'est toujours le CPU d'origine (Atom D510) qui est indiqué. Pour ce qui concerne les tests, je ne suis pas chaud bouillant. Tout d'abord par manque de temps ces derniers mois et ceux à venir et ensuite que mon 710 me sert toujours, même s'il n'est que pour une deuxième sauvegarde à distance. Je cherche plutôt une méthode qui a fait ses preuves pour limiter les risques de devoir galérer des heures en cas de pépin. Mon but est de pouvoir utiliser hyperbackup sur le 710 ainsi que le reverse proxy qui sont absents de DSM5.2.

C'est du côté serveur le transfert du port, pas du côté client. Pas que je sache. Il se peut que ce soit l'IPV6 qui pose problème.

Le changement d'adresse MAC n'est pas un problème en soit (le DHCP attribuera une autre IP et il suffira de modifier la réservation). L'ennui c'est que le 710 n'a qu'une seule prise Ethernet alors que le 712 en a deux. Du coup, le problème est plutôt de savoir si le port manquant n'est pas un point bloquant qui transformerait le NAS en brique.

Pour le moment... Je vous souhaite que ça dure. Comme @.Shad., j'ai un peu de mal à saisir la logique de cette phrase. En principe, c'est pour éviter/limiter les soucis qu'on fait une, voire plusieurs, sauvegarde(s). Quelqu'un a t'il tenté de faire un upgrade sur un 710+ (Intel Atom D410) ? Faut-il le faire passer pour un 712+ (Intel Atom D425) ? Tous les deux ont une architecture x86 1 coeur 2 threads, mais 1Go de RAM DDR2 pour le 710, DDR3 pour le 712.

Avant de commencer à penser accès extérieur, il faut d'abord sécuriser autant que faire se peut le NAS. Mon conseil : laissez tomber uptobox pour le moment et contentez vous de bien paramétrer votre NAS pour vos usages courants. C'est seulement après cette étape indispensable que vous pourrez envisager la mise en place d'un VPN externe. Comme le dit Fenrir dans le tuto sur la sécurisation de nos NAS, un VPN sur un NAS non sécurisé peut devenir un danger potentiel d'intrusion non sollicitée.

Ce type de VPN sert à se connecter vers l'extérieur de manière (pseudo) anonyme. Ca n'a rien à voir avec le serveur VPN qui lui vous permet de rejoindre votre réseau privé de l'extérieur à travers un tunnel sécurisé. Si vous n'avez pas l'utilité immédiate de uptobox, vous pouvez laisser tomber pour le moment, il n'est pas du tout nécessaire pour paramétrer votre NAS.

A priori, ce tuto ne vous est d'aucune utilité puisque d'après votre présentation vous n'avez pas de routeur Synolgy, juste une livebox.

C'est là tout mon problème. Nous sommes seulement deux abonnés sur le même poteau (propriété de FT et donc d'Orange) situé sur une propriété privée à 50-60 m du point de liaison fibre. Et nous sommes tout les deux chez Free. On peut raisonnablement penser que ça ne va pas se bousculer pour tirer un câble vers 2 abonnés de la concurrence. Surtout que le gars qui est venu faire le survey des travaux m'a dit qu'il faudra probablement changer le poteau..... ce qui complique encore un peu la chose. A moins que j'arrive à convaincre mon voisin de passer son adsl chez orange (je ne vais pas me tirer une balle dans le pied 😉) pour booster le processus, l'attente risque d'être encore trèèès longue. Allez, je vais rester optimiste 🥳 : peut-être jusqu'en 2045 ou plus, quand la fibre sera devenue obsolète, qu'on sera passé à autre chose et que ça fera bien longtemps que je ne serai plus de ce monde pour en profiter.

Pas sûr que ce soit encore le cas car Free ne m'aurait pas envoyé un message m'annonçant que je pourrai bientôt migrer ma freebox révolution vers la fibre. Sur quatre liaisons, c'est pas un peu too much ? Dans le tas, l'adsl orange ne doit pas servir à grand chose face à la 4G et au 2 5G. Même la 4G doit être largement supplantée par les 5G.

@maxou56 sur ta signature je vois "Adsl Orange + 4G Bouygues ∞ + 5G Free ∞ + 5G Orange ∞" 4 liaisons, rien que ça. Tu crains une panne internet ? 😆 Et pas de fibre pour toi non plus 🙄

Rien de tel chez moi. C'est ADSL ou fibre. Et même si elle arrive un jour chez moi, orange va tout faire pour tenter de récupérer des clients avant de permettre à free ou à d'autres opérateurs d'utiliser leur réseau. Il faudra encore attendre parce-que orange, c'est pas ma tasse de thé.

Question fibre, c'est selon. Chez moi, elle est sur la route en limite de propriété. Tous ceux en face sont raccordés depuis des mois. Ce sont des lotissements relativement récents, si bien que le déploiement ne pose pas de difficultés. De mon côté, il parait que c'est programmé. Pour quand ? personne n'est capable de me donner une réponse. Les travaux sont un peu plus compliqués car les habitations sont plus disséminées ce qui engendre des tirages de câbles plus importants pour distribuer vers moins de points de terminaison. C'est moins rentable pour l'exploitant du réseau (Orange). D'où probablement la lenteur de mise en oeuvre. Pourtant, j'ai moi aussi reçu un message de free m'annonçant un raccordement imminent. Ca fait 6 mois. J'espère simplement que les travaux seront réalisés d'ici la fin de l'année. Il y a bien une obligation de fournir la fibre avant la fin de l'année, mais la crise sanitaire est passée par là....

Je trouve en effet cette approche plus sure puisqu'on maitrise chaque domaine. Mais ça c'était avant. Maintenant je suis passé au wildcard pour ma zone WAN. Ce faisant, il faut prendre des précautions pour bien protéger ses ndd car sans profils de contrôle d'accès, tout ndd existant dans le reverse proxy sera résolu aussi bien côté WAN que côté LAN. Il ne faut pas oublier de réduire la zone d'IP pour les ndd qui sont destinés à être utilisés avec des IP ou plages d'IP particulières. Par contre, je continue à alimenter ma zone LAN avec les CNAME individualisés.

Le port http par défaut pour calendar est le 20002 qui doit être activé dans l'onglet application du portail des applications pour pouvoir être utilisé dans le reverse proxy.

C'est le coupable et c'est dû a une mauvaise utilisation du paquet. Ceci est d'autant plus impactant avec l'EXT4. Pour son fonctionnement Drive s’appuie sur un dossier caché dont le contenu est sensiblement égal à la somme des dossiers Drive gérés par le NAS. De plus il conserve l'historique de tous les fichiers, même ceux qui ont été supprimés. Ce dossier caché peut très vite prendre des proportions importantes. L'erreur la plus fréquente c'est d'y mettre des dossiers et fichiers multimédia qui occupent beaucoup de place pour un intérêt quasi nul. Drive ne devrait contenir que des dossiers de travail ou qui sont susceptibles d'être consultés à tout moments. Les dossiers multimedia ont leurs propres applications (photo station, video station, audio station etc..) qui sont beaucoup plus indiquées pour ces types de fichiers. Même si les miniatures occupent une certaine place, ce n'est pas l'indexation qui peut poser problème car elle peu gourmande en espace disque.

Tu as plus de maitrise que ce que j'avais avec mon hébergement chez Fenrir puisque tu y as accès quand bon te semble. De mon côté, le changement brutal d'IP par Free a fait perdre la liaison du DNS secondaire vers le principal et n'arrivant pas à rentrer en contact avec Fenrir pour qu'il corrige, j'ai été contraint d'abandonner l'hébergement public de ma zone. Elle fonctionnait très bien au demeurant mais était susceptible de me laisser en rade à tout moment car attachée à des systèmes autrement moins solides et fiables que les serveurs des registars.

Je la fais aussi, mais uniquement en ipv4. Chaque NAS est son propre serveur DNS principal et chacun renvoi le DNS secondaire vers le routeur. Dans le serveur DHCP du ER-X, j'ai les IP des deux NAS respectivement comme serveur DNS principal et secondaire. Il est bien évident que chaque NAS à aussi sa zone en propre et son propre proxy inversé. Ainsi, si le NAS principal tombe en rideau, les requêtes sont redirigés par le routeur vers le secondaire. Il ne pourra pas résoudre bien évidemment les adresses redirigées vers le NAS principal mais pourra traiter celles des autres équipements du réseau. Les zones des deux NAS ne fonctionnent pas en maitre/esclave car elles ont un enregistrement A différent, ce qui m'oblige à faire les modifications des CNAME sur les deux zones. Idem pour les règles du proxy inversé.

@.Shad. Finalement, ça n'a pas fonctionné. Impossible de recharger le dashboard, ni même de le recréer. La nuit portant conseil, j'ai réalisé où était mon erreur. Au lieu de créer le dossier grafana et son dossier data via putty ce qui leur aurait donné des droits root, je les avais créés via file station, ce qui bien évidemment leur donnait les droits admin de ma connexion. 🤔 Ne me demande pas pourquoi. Comme j'étais dans DSM à ce moment là, j'ai créé par facilité les dossiers dans le dossier docker, sans penser aux droits. D'où l'impossibilité d'écrire dans les dits répertoires et le refus du container de se lancer. Bref, j'ai repris l'installation de grafana et maintenant tout est ok.

@.Shad. Merci pour ton retour. J'ai fait un chmod sur le dossier data et indiqué user 472 et c'est ok.

Non, je n'avais déclaré que le mien.

Lorsque ta zone publique est chez ton registar, l'enregistrement GLUE est automatique puisque ton domaine est inscrit dans les serveurs DNS du registar. Lorsque tu héberges à la fois ta zone publique et ton serveur DNS, il faut indiquer aux serveurs externes où est situé le serveur DNS pour ton ndd. C'est le rôle de l'enregistrement GLUE qui en fournissant l'adresse IP de ton serveur DNS permet de faire le lien entre ton registar (hébergeur de ton ndd) et ton serveur DNS. A vrai dire, je n'en sais rien. Je l'avais mis en place dès le début, une fois mes zones fonctionnelles. Mais ça fonctionnait aussi sans. C'est juste à mon sens de rendre plus rapide la résolution des noms et surtout d'éviter des boucles. Tu aurais pu (dû) installer ton serveur principal chez toi et le secondaire chez HE car si les services HE tombent en panne, ton ndd est injoignable. Tu me diras que c'est la même chose chez OVH, mais là le service est payant donc on peut penser qu'il est plus stable. Non. Tes serveurs DNS peuvent être où tu veux. S'ils ne sont pas chez OVH (ton cas), la zone chez eux n'a aucune utilité puisqu'elle ne sera pas utilisée pour la résolution des ndd. Tant que ton serveur principal est fonctionnel et que tu ne fais pas appel au secondaire, tu peux très bien te passer de ce dernier. Les demandes se font d'abord sur le principal, puis s'il n'est pas dispo, sur le secondaire, etc.. Si le secondaire est absent, les requêtes qu'il devrait traiter ne seront pas résolues. En réalité, l'usage "temporaire" du serveur de Fenrir a été permanent, jusqu'à ce que Free ait eu la bonne idée de changer mon IP. Le serveur secondaire hébergé chez lui ne s'est pas mis à jour et ça à mis comme toi un patacaisse pas possible avec certains ndd qui pouvaient être résolus et d'autres pas. N'ayant pas réussi à le contacter rapidement, j'ai basculé ma zone chez OVH où je l'ai gardée depuis. Il a fallu cependant que je supprime l'enregistrement GLUE et j'ai dû faire intervenir OVH car je n'arrivais pas à le supprimer. Pas vraiment non. La preuve juste au dessus. Je n'en n'ai pas. C'est effectivement le propriétaire qui doit le faire.