.Shad.

Mise à jour proposée rapidement pour une fois sur le RS422+, RAS

Bienvenue parmi nous !

Bienvenue dans la communauté 🙂

@morgyann En ce cas, pour que Wordpress puisse utiliser FFMpeg via Docker, il faudrait que l'image Wordpress incorpore Docker ou puisse utiliser le socket Docker de l'hôte. Les images Linuxserver prévoient ce genre de cas avec le mod Docker ou Docker-in-Docker, mais pas l'image Wordpress à ma connaissance. Tu as la possibilité de créer ton propre Dockerfile et y intégrer l'installation de ffmpeg pour pouvoir t'en servir, l'inconvénient c'est que tu devras rebuild fréquemment si tu veux suivre les màj de Wordpress. Tu as aussi la possibilité de basculer sur une VM et d'y installer Wordpress et FFMpeg en natif, niveau portabilité c'est encore mieux que Docker, mais c'est plus gourmand en ressources. Il y a peut-être d'autres solutions mais je n'en vois pas comme ça de prime abord.

L'image de Linuxserver est dépréciée, du coup j'utilise celle du créateur initial.

J'éviterais à tout prix de recourir à cette solution. @Aurore23 Tu parles de la redirection de ports dans la Box, mais qu'en est-il du pare-feu du NAS ? Si tu as changé de Freebox, il se peut que l'adressage ait également changé et que tu aies oublié de le modifier dans le pare-feu DSM.

Welcome !

Pourquoi n'as-tu pas contacté le support Synology ? C'est la première chose à faire si un problème persiste. Si tu n'arrives plus à le démarrer, on ne pourra pas t'aider.

Tu peux déjà suivre les recommandations de @morgyann Plus simplement, tu peux réactualiser le page avec CTRL+F5 sur Chrome, ou faire un test en navigation privée.

@morgyann De ce que je lis ici : https://hub.docker.com/r/linuxserver/ffmpeg J'ai l'impression que ton WP (Conteneur ou natif ?) doit pouvoir exécuter les commandes de création éphémère de conteneur pour transcoder un fichier donné, soit dans le même répertoire, soit dans un répertoire précis. Ca pourrait déjà être intéressant que tu nous dises ce que tu as tenté, et où ça a échoué. C'est une image inhabituelle c'est tout à fait normal que tu rencontres des obstacles.

Il faudra passer par la création d'un projet pour monter tes disques, la création d'un conteneur ne suffira pas, mon setup utilisé pour mon serveur Debian : version: "2.1" services: scrutiny: image: ghcr.io/analogj/scrutiny:master-omnibus container_name: scrutiny networks: - net-proxy cap_add: - SYS_ADMIN - SYS_RAWIO environment: - COLLECTOR_CRON_SCHEDULE=10 6 * * * - TZ=Europe/Brussels volumes: # config - /opt/scrutiny/config:/opt/scrutiny/config - /opt/scrutiny/influxdb:/opt/scrutiny/influxdb # system mounting - /run/udev:/run/udev:ro devices: # disks - /dev/sda:/dev/sda - /dev/sdb:/dev/sdb - /dev/sdc:/dev/sdc - /dev/sdd:/dev/sdd - /dev/nvme0:/dev/nvme0 - /dev/nvme1:/dev/nvme1 labels: # watchtower label only monitoring - "com.centurylinklabs.watchtower.enable=true" restart: unless-stopped networks: net-proxy: external: true A adapter à ton besoin, les disques (/dev/sdX) peuvent s'appeler différemment sur ton installation de DSM. Concernant /opt/scrutiny/config, il faut transformer ça en /volume1/docker/scrutiny/config par exemple, même chose pour /opt/scrutiny/influxdb.

Bienvenue parmi nous!

Salut, un reset mode 1 permet de rétablir la configuration réseau d'usine sans perte de données, la seule chose à faire est de redéfinir les credentials du compte administrateur. https://kb.synology.com/fr-fr/DSM/tutorial/How_to_reset_my_Synology_NAS_7

Pas sûr de comprendre, ton site en construction intègre la page d'accès au Synology dans un genre d'iFrame ?

Bienvenue parmi nous ! Profite de ton passage ici pour vérifier que la sécurisation de ton NAS est suffisante :

Salut, soit j'ai pas compris soit ton setup, très sympa au demeurant, n'a rien à voir avec Synology ?

Passe le paramètre debug à true dans ton fichier conf.

Je comprends tout à fait ta remarque, mais ce tutoriel n'a pas pour vocation de pousser le cran de la sécurité au maximum. Une fois les utilisateurs un peu plus aguerris, ils pourront tout à fait réduire par exemple la plage 192.168.0.0/16 à leur sous-réseau en particulier. Même chose pour 10.0.0.0/8 avec le sous-réseau qu'ils vont utiliser avec leur éventuel serveur VPN. Et comme tu dis, on peut tout à fait réduire la surface d'exposition par rapport à celle préconisée ici. L'idée est aussi qu'à la moindre d'installation de paquet, ils ne se retrouvent pas bloqués parce que les règles sont trop restrictives (je pense à VPN Server et Container Manager par exemple). Les considérations que tu évoques pourraient probablement l'objet d'un tutoriel axé sur la sécurisation pour utilisateur avancé.

As-tu réellement besoin d'attribuer une IPv6 à ton Pi-hole ? Personnellement mon trafic est grande partie en IPv6 (dual stack natif chez mon fournisseur), et les requêtes sont traitées par mon Pi-hole qui ne dispose que d'une IPv4.

@CMDC83 Je ne comprends pas ton propos, la partie spoofing dont tu parles concerne les attaques sur ton IP publique, dans ce cas on parle de plage d'IP bogon, les ranges d'IP qui n'ont pas vocation à apparaître dans les échanges publiques, dont les plages d'IP privées définies par la RFC1918 ainsi que certains autres blocs Bogon IP addresses, ipv4 and ipv6 bogon IP Ranges (ipgeolocation.io) Sauf à ce que ton NAS établisse une connexion PPPoE directe avec ton fournisseur d'accès, cas qui n'est pas prévu par le tutoriel, il ne dispose pas d'une IP publique IPv4. Et tout les fournisseurs d'accès intègrent dans leurs box les règles de drop pour le spoofing. 10.0.0.0/8 est dans l'extrême majorité utilisé par les réseaux VPN. Or, pour la portabilité des noms de domaine, il est pratique de pouvoir atteindre une adresse en 192.168.0.0/16 depuis 10.0.0.0/8. Si tu établis un serveur VPN chez toi pour te connecter de manière sécurisée, je ne vois aucun problème à autoriser cette plage d'adresses. Les utilisateurs plus avancés pourront mettre en place un serveur DNS local avec des vues VPN et LAN séparées. Mais ce tutoriel va à une solution plus simple avec très peu de (voire aucun selon moi) compromis sur la sécurité.

Visiblement c'est la partie IPv6 qui pose problème. Est-ce que la gateway a bien toujours la même IP link-local que celle renseignée dans le réseau macvlan ? Sans être une solution, un contournement : https://github.com/moby/libnetwork/issues/2455 La team Docker n'a pas l'air pressée de traiter ce problème. Mais ici : https://github.com/moby/moby/issues/43466 Apparemment c'est l'utilisation de SLAAC sur le NAS qui engendre ce problème. Est-ce que tu obtiens tes IP via SLAAC ou DHCPv6 ?

@CyberFr L'idée de ce tutoriel est de limiter les réglages à un usage basique néanmoins sécurisé pour néophyte. C'est pourquoi seule la configuration de LAN 1 est évoquée, c'est transposable à LAN 2, etc... Paramétrer l'interface VPN de DSM implique généralement qu'on a mis en place VPN Server. Qui implique selon moi l'assimilation et la mise en places des recommandations du présent tutoriel. Configurer les règles par interface permet notamment de maîtriser beaucoup plus facilement ce qui est exposé et où c'est exposé. Pour un utilisateur tel que toi, tu apprendras assez peu de choses, ça reste intéressant de le lire en diagonale, notamment les règles concernant IPv6.

Dans la résolution DNS elle n'intervient pas, elle communique au moment de l'octroi du bail DHCP quel(s) serveur(s) DNS utiliser, ça c'est vrai. Pour ton problème, je n'ai jamais eu le moindre souci, mais j'utilise les connexions RJ45 natives du NAS. Quand tu dis que le Pi-hole reste en plan, tu veux dire que le conteneur n'est pas créé ? ou que la résolution DNS ne fonctionne pas ? ou que l'interface virtuelle n'est pas encore montée ? Pour la température elle correspond à celle du capteur CPU.

Je ne suis pas très calé sur ce sujet-là, je laisse @Mic13710 et @maxou56 donner leur avis, ils sont bien plus compétents en la matière.

Je trouve la suggestion intéressante, j'en ouvrirai aussi une dans ce sens. 🙂