PiwiLAbruti

Je n'ai pas lu tout le fil. Normalement, réinstaller la même version ne pose pas de problème. Sinon la méthode de modification de la version fonctionne.

https://kb.synology.com/fr-fr/DSM/tutorial/Which_Synology_NAS_models_support_the_facial_recognition_feature_on_Synology_Photos

La migration est une mauvaise idée vu l'écart de génération entre les deux NAS, et en particulier le dimensionnement de la partition système (à vérifier). Il faut aussi vérifier l'âge des disques.

L'autre souci est que ta Freebox utilise un réseau IPv6 natif. C'est-à-dire que pour communiquer en IPv4 sur internet, ta box encapsule le trafic IPv4 dans IPv6. Une passerelle chez Free se charge ensuite de décapsuler le trafic vers IPv4. Pour résoudre ton problème, tu as le choix entre ne pas configurer IPv6 sur ton routeur (désactiver le relais par exemple), ou désactiver IPv6 dans les paramètres Wi-Fi de ton iPhone (si c'est possible).

C'est une adresse IP locale appartenant à fc00::/7 [fc00:: - fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff], elle n'est pas routable sur l'espace d'adressage public. C'est très probablement une adresse de serveur DNS annoncée par la box. Ton iPhone n'ayant pas d'adresse dans ce réseau, il ne peut pas communiquer avec cette adresse (ou alors j'ai loupé un truc sur IPv6 😅), ce qui me paraît étrange (pourquoi annoncer une adresse de serveur DNS non-joignable ?). Comme ton Pi-hole est configuré en macvlan, il n'a probablement pas d'IPv6 : https://docs.docker.com/network/macvlan/#use-ipv6 Vérifie au préalable que le support d'IPv6 est activé dans Docker (pas testé) : https://docs.docker.com/config/daemon/ipv6/

Je l'avais testé il y a quelques temps avec une myriade de petits fichiers (75 000 fichier pour 12Go), ça fonctionnait très bien. J'ai particulièrement apprécié le fait de pouvoir le faire fonctionner indépendamment de relais ou trackers, c'est super efficace. Par contre c'est beaucoup moins user-friendly que Synology Drive pour le configurer. Je pense qu'il vaut mieux passer par une gestion centralisée (via les API) mais ce n'est pas gratuit.

DeLorean, ce n'est pas si douloureux que ça 😉 @oracle7 Est-ce que tu peux me donner en MP le résultat du tirage EuroMillions de demain ? 😅

5 switches ? Tu comptes les alimenter en PoE ? @Varx Est-ce que ce switch est manageable via le contrôleur ? (VLAN et IGMP ?)

Effectivement, il vaut mieux créer un partage avec une arborescence de dossiers à sa racine, surtout si les droits d'accès sont communs.

Le RAID 0 ne s'applique qu'à partir de 2 disques dans un même groupe de stockage. L'option que je t'ai suggérée précédemment consiste à créer un groupe de stockage par disque (il n'y a alors pas de RAID possible), puis créer un volume sur chaque groupe de stockage. Ainsi tu te retrouveras avec deux volumes sur lesquels tu devras répartir tes dossiers partagés. Tu auras l'arborescence suivante dans le Gestionnaire de stockage : Stockage Groupe de stockage 1 Volume 1 Groupe de stockage 2 Volume 2 Dans ce cas, la panne d'un disque n'entrainera "que" la perte des données du disque en question.

Si tu as déjà appliqué les bonnes pratiques, tu as dû mettre en place une sauvegarde des données importantes du NAS sur un support de stockage externe. L'avantage du RAID 0 est de pouvoir bénéficier de la totalité de l'espace des disques. Son énorme inconvénient est que si un seul des disques du groupe tombe en panne, le volume et les données sont perdus. C'est pourquoi on préconise en règle générale de créer un groupe de stockage par disque plutôt qu'un seul en RAID 0, c'est moins contraignant en cas de problème avec un disque.

3ème au top 10, pas mal 😎

Qu'on mutualisme les ressources, je trouve que c'est une excellente idée tant que ca reste maitrisé. Que le système permettant de faire cela soit ouvert au premier venu est une aberration. Un système qui me semble le plus sain est basé sur des nœuds de confiance (également appelés pods chez certaines solutions). Je ne vais m'étaler plus sur le sujet. La solution présentée dans ce sujet apporte satisfaction aux utilisateurs ne l'évaluant que sur des critères quantitatifs de performances (et parfois même un seul). Pour ceux qui ne savent pas trop de quoi il est question, il existe une très bonne vulgarisation avec l'histoire des deux Francis.

J'ai testé avec la commande nslookup, et ton nom de domaine se résout bien en ton adresse IP. Au passage, il ne sert à rien de cacher ton adresse IP dans ta capture d'écran si tu laisse le domaine visible. Masque également ton nom de domaine.

Ce n'est pas la demande de @BALIXE, il souhaite éradiquer tout trafic torrent pouvant émaner de son réseau.

J'avais eu le cas sur mon DS109, les symptômes étaient une impossibilité de démarrer DSM après un double reset et installation. L'installation fonctionnait, mais au reboot le NAS repassait dans un état indiquant que DSM n'est pas installé (je n'ai plus le terme exact). Le changement de la pile avait résolu ce problème. Si tu veux faire le test, éteins ton NAS, enlève la pile, et démarre ton NAS. Tu verras si ça pose problème.

Pourquoi ? On peut en parler sans en faire l'apologie.

Aucune idée. Il faudrait trouver la base de données utilisée pour vérifier, ou demander directement à Synology. D'ailleurs je ne pense pas que cette base soit mise à jour régulièrement, au mieux à chaque mise à jour de DSM (ce qui est insuffisant).

Faire ce qui est indiqué ou trouver un moyen de contourner la détection opérée par la HADOPI le CSA l'ARCOM. S'il est bien à l'origine du trafic constaté par l'ARCOM oui, sinon non. N'importe quelle machine utilisant un client Torrent quelconque peut également être détecté.

Le pays associé à une adresse IP est celle du client qui a réservé, auprès d'un RIR, la plage réseau à laquelle elle appartient. Les registres sont librement accessibles chez chacun des RIRs mais ne contiennent pas de données détaillées concernant l'identité du client, ... : ... ripencc|LU|ipv4|5.8.92.0|1024|20120425|allocated ripencc|IT|ipv4|5.8.96.0|8192|20120425|allocated ripencc|LB|ipv4|5.8.128.0|8192|20120426|allocated ripencc|RU|ipv4|5.8.160.0|4096|20120426|allocated ripencc|RU|ipv4|5.8.176.0|2048|20120426|allocated ripencc|ES|ipv4|5.8.184.0|2048|20120426|allocated ripencc|RU|ipv4|5.8.192.0|8192|20120426|allocated ripencc|RU|ipv4|5.8.224.0|4096|20120426|allocated ripencc|IQ|ipv4|5.8.240.0|2048|20120426|allocated ripencc|NL|ipv4|5.8.248.0|256|20210525|allocated ripencc|FR|ipv4|5.8.249.0|256|20210525|allocated ripencc|NL|ipv4|5.8.250.0|256|20210525|allocated ripencc|US|ipv4|5.8.251.0|256|20210526|allocated ripencc|ES|ipv4|5.8.252.0|1024|20180611|allocated ... ... sauf au RIPE-NCC. En reprenant la première ligne ripencc|LU|ipv4|5.8.92.0|1024|20120425|allocated : lu.gcorelabs G-Core Labs S.A. 20000126 213.156.136.0/21 ALLOCATED PA ... 20120425 5.8.68.0/22 ALLOCATED PA 20120425 5.8.92.0/22 ALLOCATED PA 20120626 5.101.216.0/21 ALLOCATED PA ... 20191107 91.199.87.0/24 ALLOCATED PA 20121207 2a03:90c0::/32 20121211 2a03:97c0::/31

J'aime bien faire la correspondance avec IPv4, même si elle n'est pas 100% exacte, ça permet aux débutants de s'y retrouver : ::/0 0/0 ::/128 0/32 ::1/128 127.0.0.1/32 fe80::/10 169.254/16 fc00::/7 10/8 172.16/12 192.168/16 ff00::/8 224/4 Il faut bien garder à l'esprit qu'IPv6 est ce qu'IPv4 aurait dû être avant qu'on ne se rende compte qu'il allait rapidement y avoir une pénurie d'adresses IPv4. Cette pénurie a favorisé la prolifération des passerelles NAT (plus précisément NAPT pour faire plaisir à Bortzmeyer) qui a totalement modifié l'usage d'IPv4 pendant des décennies. De manière générale, une machine adressée en IPv6 (sans DHCP) s'attribue une adresse locale dans fe80::/10 et une autre publique dans 2000::/3 (réduit au scope fourni pour l'opérateur évidemment). Si on fait l'analogie directe en IPv4, cette même machine devrait s'attribuer une adresse dans 169.254/16 et une autre publique (difficilement définissable étant donné que l'espace IPv4 publique est fragmenté de partout). Ça n'a donc rien à voir avec l'utilisation actuellement faite d'IPv4 (du moins en bout de chaîne). Cette réplique de Morpheus s'applique plutôt bien à IPv6 :

Même si cet article date, il reste d'actualité concernant la sécurité : https://blog.fenrir.fr/2013/06/28/ipv6-securite/ Ceux qui ont lu le nom de domaine savent qui est l'auteur 😉 Si vous vous posez encore des questions sur l'adressage IPv6 après la lecture de l'article Wikipedia, la source d'information ultime est la RFC (en anglais) : https://tools.ietf.org/html/rfc4291 ⚠️ Si vous n'avez jamais lu ce type de référence, ça peut piquer les yeux et le cerveau 😄

Malheureusement ça va faire beaucoup de déçus mais Wikipedia présente très bien ce qu'est IPv6 à condition de lire tout l'article dans l'ordre sans rien zapper : https://fr.m.wikipedia.org/wiki/Adresse_IPv6 Pour ceux que l'Anglais n'effraie pas (plus exhaustive de mémoire) : https://en.m.wikipedia.org/wiki/IPv6_address Par exemple, la section "Special addresses" > "Unicast addresses" donne l'équivalent IPv4 des adresses IPv6.

Ah ok, c'était surtout pour répondre à @MilesTEG1 : Il n'y a pas vraiment de réel avantage théorique à basculer en full-IPv6 pour le moment. Dans la pratique, il est préférable d'activer le protocole supporté nativement par votre connexion internet (pas d'encapsulation, meilleures latences, ...). Ce n'est pas propre à chaque opérateur mais au déploiement chez ces dernier (dans mon cas, IPv4 est encapsulé dans IPv6). En IPv6, chaque machine a sa propre adresse IP publique. Il est donc possible d'héberger des services utilisant les mêmes ports sur différentes machines, là où en IPv4 on n'a qu'une seule adresse IP publique qui implique soit d'utiliser un port différent par machine, soit d'utiliser un proxy inversé (dans le cas d'HTTP). Ce qui perturbe le plus les utilisateurs est que NAT n'est plus utilisé (enfin presque, mais ça reste une broutille). Ça change les habitudes et donc on voit une levée de boucliers chez ceux qui ne se sont pas assez documentés sur IPv6 et ne veulent pas faire l'effort de comprendre comment ça fonctionne. Pour faire un parallèle avec l'actualité, on pourrait dire que ce sont des anti-vax de l'IPv6 😄 Niveau sécurité, étant donné l'espace allouée pour l'adressage des machines (64 bits), les scans de ports vont drastiquement diminuer par rapport à IPv4. Le point qui pourrait faire mal, c'est sur toutes les machines où l'utilisateur a eu la lumineuse idée de désactiver le pare-feu local. Faut-il encore que les services ouverts sur ces machines puissent être détectés facilement. Il y aurait encore beaucoup de choses à dire sur IPv6 (et pas que du positif si on est suspicieux), mais il faut d'abord commencer par acquérir les bases techniques (les espaces et modes d'adressage, analogies avec IPv4, ...) avant de d'analyser les dérives possibles.

Ça ne me dit pas si tu as fait le test ou non. Peut-être que la carte-mère est considérée comme défectueuse avec les symptômes que tu rencontres.