.Shad.

Bienvenue parmi nous !

Je ne sais même plus si cette application est encore développée, elle l'était (et assez répandue) au moment de la rédaction du tutoriel, tu trouveras des alternatives beaucoup plus intéressantes à l'heure actuelle telles que Dashy ou Flame. C'est là à titre purement didactique. Pour le certificat, si tu veux utiliser le certificat LE du NAS il faut passer par le proxy inversé, parce qu'Heimdall n'embarque qu'un certificat auto-signé.

Bienvenue parmi nous !

Un article très instructif que j'avais trouvé pour IPv6 autrefois : https://www.bortzmeyer.org/9099.html

Je confirme tout ce que dit @PiwiLAbruti, j'ai mis l'IPv6 en production chez moi. Ce n'est pas une mince affaire, mais ça vaut le coup, et c'est très instructif. @MilesTEG1 Le problème étant que chaque FAI a sa façon de faire aussi. Par exemple chez Proximus on récupère un /56, parmi ce /56 on choisir généralement un /64 par interface "LAN" du routeur (par exemple LAN classique, Guest, IoT, etc...). Et pour répondre à une de tes questions antérieures, tu ne fixes pas l'IPv6 d'un périphérique normalement. Soit il obtient une IPv6 routable et de lien local par adressage sans état (stateless ou SLAAC), dans ce cas-là les IPv6 sont générées aléatoirement via le préfixe et la mac. Soit il obtient une IPv6 par un adressage avec état (stateful ou DHCPv6). Il faut savoir par exemple qu'Android ne supporte pas un adressage stateful mais uniquement stateless (pas un bug, une volonté de Google). Pour Apple aucune idée. Pour ma part j'utilise un adressage stateless. Et mon résolveur DNS (Unbound, mais ça pourrait être DNS Server, Pi-hole, Adguard, etc...) reprend les IPv4 et v6 de mes périphériques pour mon réseau local. EDIT : Le client tentera d'abord de communiquer dans son langage par défaut, IPv6 chez moi par exemple, s'il n'y arrive pas il se rabat sur de l'IPv4.

Pour Docker par exemple, surtout sur Syno où Docker IPv6 n'est à ma connaissance, pas activable dans le démon. A ma connaissance, la plupart des switchs administrables gèrent effectivement la couche L3. Mais un bête switch L2 n'empêchera pas a priori un équipement qui lui est relié d'obtenir une IPv6.

Oui, ça s'appelle SSH. 😄 Concrètement le bash n'est peut-être pas le plus simple des langages, pour autant je ne trouve pas PowerShell plus accessible. 🤔 Comme l'a dit @PiwiLAbruti, DSM ne prévoit pas d'exécuter des scripts depuis DSM autrement qu'en passant par le planificateur de tâches. Ca ne me choque pas, surtout d'un point de vue sécurité.

Merci pour ce tuto, même si je n'utilise pas le LiveTV. Juste une remarque, ton conteneur xteve est en bridge d'après ton docker run, et tu NAT sur le NAS le port 34400. Mais de souvenir sur ton tutoriel, Plex est en macvlan, du coup localhost:34400 depuis Plex ne devrait mener à rien, sauf si Plex est en host (mais dans ce cas-là, pas besoin de NAT le port). Si Plex en macvlan, et xteve en bridge, c'est plutôt http://IP_VIRTUELLE_DU_NAS:34400 qu'il faudrait taper.

Tu confonds les couches réseau, les switchs ne voient pas les adresses IP, ils sont de la couche 2. Pour l'IPv6, chez Proximus le FAI t'attribue un préfixe (PD = Prefix Delegation), qui correspond à un sous-réseau IPv6 à ta disposition. Chez nous c'est du /56 (/128 en IPv6 pour un réseau d'une seule IP, semblable au /32 en IPv4). Mais Proximus est en IP dual-stack, avec IPv6 natif (pas de tunnel d'encapsulation). De là, la box va attribuer à chaque périphérique une IPv6 de lien local (portée locale uniquement), basé sur la MAC des périphériques, et une IPv6 routable (comprendre publique) permanente ainsi que souvent une temporaire, basées sur le préfixe + la mac. C'est là l'importance d'avoir un pare-feu IPv6, car tous tes périphériques seront accessibles depuis l'extérieur, sans NAT (ON NE NAT PAS EN IPV6). En espérant que ta box permettre de créer des règles sur le pare-feu IPv6, à défaut le RT.

Bienvenue parmi nous ! 🙂

@stephane74240 Est-ce que tu as bien associé cette application au certificat LE dans DSM ?

Bienvenue parmi nous ! Au plaisir de te lire 🙂

Non du tout.

Bienvenue parmi nous !

Bienvenue parmi nous !

Bienvenue parmi nous 🙂

Re-bienvenue alors !

Si tu choisis un NAS pour transcoder du 4K HDR oublie, les processeurs sont axés faible consommation et "faibles" performances. Pour du 4K HDR il est préférable d'avoir des périphériques capables de lire nativement, ou utiliser des box android comme la Shield TV par exemple. Ou alors un serveur homemade bien beefy avec carte graphique dédiée, vu les prix de ces dernières actuellement, je ne pense pas que ce soit la solution. J'utilise Deluge via Docker qui marche du tonnerre. Cela nécessite un NAS de la série "+" (haut de gamme). Sinon tu peux te servir de Download Station, logiciel de téléchargement de la suite Synology, mais pour une raison que j'ignore, je n'ai jamais réussi à obtenir la même constance dans l'upload et dans le débit que sur Deluge, peut-être une mauvaise configuration de ma part, je ne sais pas.

Oui oui. 🙂 Je vais mettre à jour mon NAS ce week-end, je verrai si le chown bouge. 🙂

Quel protocole utilises-tu pour te connecter au NAS ? SMB ou NFS ? Quelle distribution de Linux ?

Bienvenue parmi nous !

Que dit la page d'erreur ? Si tu fais F12, est-ce que tu arrives à voir le numéro d'erreur ? (404, 503, ...)

Utiliser le groupe permet de ne pas toucher aux permissions. C'est toi qui vois la méthode que tu préfères.

J'expliquais juste à quoi ça servait.

Je ne sais plus comment c'était sous DSM 6, mais je doute que tu aies nativement du 666 sur ce fichier-là, je pense que tu devais avoir initialement du 660 voir plutôt du 640. En l'état tout utilisateur du système peut utiliser et effacer ton fichier. Tu as dû étendre les permissions à un moment donné. Le mieux étant de laisser root/root quand on a la possibilité, si pas, créer un groupe dédié à la manipulation de ce fichier, et attribuer ce groupe au fichier. C'est beaucoup plus sécurisé qu'un 666. C'est d'ailleurs le système utilisé par DSM 7 pour renderD128, qui autrefois appartenait à root/root, et maintenant root/videodriver. Ainsi si besoin qu'un utilisateur accède à ce fichier on peut se servir du groupe, et ne plus modifier les permissions en 666. Les autres distributions Linux fonctionnent sur le même principe, au moins pour Ubuntu et Debian en tout cas. renderD128 je pense que c'est pour le transcodage matériel avec Plex non ? Je ne sais plus comment c'était sous DSM 6, mais je doute que tu aies nativement du 666 sur ce fichier-là, je pense que tu devais avoir initialement du 660 voir plutôt du 640. En l'état tout utilisateur du système peut utiliser et effacer ton fichier. Tu as dû étendre les permissions à un moment donné. Le mieux étant de laisser root/root quand on a la possibilité, si pas, créer un groupe dédié à la manipulation de ce fichier, et attribuer ce groupe au fichier. C'est beaucoup plus sécurisé qu'un 666. C'est d'ailleurs le système utilisé par DSM 7 pour renderD128, qui autrefois appartenait à root/root, et maintenant root/videodriver. Ainsi si besoin qu'un utilisateur accède à ce fichier on peut se servir du groupe, et ne plus modifier les permissions en 666. Les autres distributions Linux fonctionnent sur le même principe, au moins pour Ubuntu et Debian en tout cas. renderD128 je pense que c'est pour le transcodage matériel avec Plex non ? De mon côté ça ne marche pas mieux avec un chmod 666 avec la 1.21.2, donc pour moi le problème ne vient pas de là. Mais d'où, je ne sais pas encore.