PiwiLAbruti

Si tu as de la chance, ce sera peut-être disponible avec DSM 7.

Même avec cette correction, ce n’est toujours pas bon : m : milli M : mega Promis, je m'arrête là 😇

Tu vas réussir à l’embrouiller encore plus @niklos0 car tu confonds toi-même les bits (b) et les bytes (B) 🤔

En iSCSI, le cluster est obligatoire pour pouvoir écrire depuis différents hôtes en même temps. S’il n’y a pas de cluster, il y a un fort risque d’incoherence des données. Si les hôtes n’en sont jamais utilisés simultanément, ça peut être jouable mais ça reste risqué. Si un seul des hôtes est utilisé en écriture (masking), pas de problème.

Quel est le modèle de ton NAS ? Quel est le débit de ta connexion internet ? Quel gain y aurait-il à asset par le NAS pour accéder à internet ? Le NAS n’est pas prévu pour ça. Le paquet Proxy Server permet de relayer les communications HTTP uniquement mais n’est plus maintenu par Synology.

Il s'agit de connexions sortantes et non entrantes. Pour voir les programmes qui utilisent ces connexions, utilise la commande netstat -netpal.

Si tu as un nom de domaine chez un registrar qui propose du DDNS (comme OVH), tu peux t’en sortir très simplement.

Et il y a un client iOS contrairement à Syncthing. Syncthing reste excellent (open source, forte communauté), surtout avec son API gratuite (vs. Resilio Connect) qui permet de gérer une multitude de noeuds de manière centralisée. Malheureusement, ce n'est pas encore assez mature pour être adopté par n'importe qui.

Resilio Sync : https://www.resilio.com/individuals/ Synology devrait d’ailleurs s’en inspirer.

Après avoir lu le problème je ne voyais pas ce que ça aurait pu être d’autre. N'hésite pas à abuser de cette commande (nslookup) pour vérifier les enregistrements DNS que tu crées, aussi bien pour vérifier l’enregistrement en lui-même que sa propagation.

Utilise la commande nslookup pour vérifier que les résolutions se font bien vers la bonne adresse IP.

La solution de @maxou56 est effectivement la plus simple. Concernant l’autre solution, il faut également modifier les valeurs dans /etc.defaults/synoinfo.conf pour que la modification persiste après une mise à jour de DSM.

Le serveur ne dispose d’aucun codec. Il ne fait que servir le contenu au client qui va lui-même décoder la vidéo. Essaye d’attribuer un profil au client détecté dans le NAS.

Il n’y a rien de ridicule à utiliser un NAS pour ce qu’on en a besoin. C’est toujours mieux que d’autres qui tentent désespérément de faire marcher un truc qui ne leur sert à rien sur leur NAS.

Si tu as besoin d’une granularité au niveau de chaque partage, ce n’est pas possible (à moins que j’aie loupé des ACLs par IP au niveau des partages). Par contre tu peux interdire l’accès aux partages au niveau service dans le pare-feu du NAS.

Pour compléter la réponse de @firlin, il faut créer un compte Synology dans lequel il faut ajouter le NAS concerné grâce à son n° de série et ouvrir un ticket de support.

Aucun client iSCSI n'est inclus dans DSM.

Par exemple, stopper les mises à jour peut te permettre de faire des tests sur ton DNS principal sans impacter les clients qui utilisent les DNS esclaves. C’est très pratique et pour passer en production il suffit de rétablir les mises à jour vers les DNS esclaves. Il y a probablement d’autres cas d’utilisation.

Les explications de l'interface me paraissent pourtant suffisamment explicites. Je ne peux que paraphraser ce qui est déjà expliqué : Le transfert de zone sert à définir quels clients peuvent demander le contenu intégral de la zone principale (ou master) pour en faire une copie dans une zone esclave (ou slave). La mise à jour de zone sert à définir les zones esclaves qui peuvent se mettre à jour depuis la zone principale. Sans ce réglage, la zone esclave ne peut pas demander à se mettre à jour avec les modifications faites à la zone principale. Un client est un serveur DNS qui va communiquer avec le serveur DNS principal. Une zone esclave (ou slave) est une copie de la zone master du serveur DNS principal. Elle est créée sur le client. C'est la même chose.

Si l’option 4 (Limiter la mise à jour de zones) n’est pas cochée, il n’y a aucune restriction IP pour les mises à jour des clients.

Petite correction : 😉 Non, il s'agit de réseaux.

Le temps que tu trouves comment faire via SSH, tu auras depuis longtemps rétabli la situation avec un simple reset.

Attention à Ubiquiti, c’est beaucoup moins user-friendly que Synology car ça reste malgré tout du (très bon) matériel professionnel. Avant d’acheter, je te conseille vivement de tester le contrôleur qui permet de gérer la gamme de produits Unifi (Unifi Controller). Ça te donnera déjà un bref aperçu qui t’aidera à faire ton choix (quel qu’il soit). J’ai profité d’une petite entité qu’il a fallu équiper pour tester cette marque avec 3x nanoHD et un contrôleur dans une VM Debian 9 LTS. Ça fonctionne pour l’instant très bien (et déjà deux mises à jour du contrôleur et les AP). Le suivi des mises à jour est exemplaire avec des notes de versions détaillées et une communauté très active.

Il n’y a pas de solution officielle. Le reste c’est de la bidouille sans aucune garantie de résultat. L’operation consisterait à faire détecter le RS810+ comme un RS812+ pour y installer DSM 6. Pour cela il faut savoir comparer les similitudes techniques de ces deux modèles et être familier avec les commandes Linux car tout se fait en ligne début commande. Si tu trouves déjà que ça risque d'être compliqué, mieux vaut rester avec un DSM 5 qui fonctionne qu’un NAS H.S.

Le moyen le plus efficace (mais probablement pas le plus simple) est d'utiliser la commande tcpdump via Telnet/SSH : # tcpdump not port '(22 or 23 or 5000 or 5001)' -nq La commande ci-dessus va exclure les ports Telnet, SSH et DSM de la capture et n'afficher que les autres protocoles/services.