MilesTEG1

Et bien je sais pas ce qu'il s'est passé de mon coté... Peut-être qu'après le reboot, l'interface virtuelle ne s'est pas remise comme il faut... Bref, tout semble refonctionner correctement... J'ai mis l'IP de mon routeur dans la partie DNS personnalisé du NAS, et c'est tout. Dans le cas où l'interface virtuelle ne fonctionnerait plus, le NAS pourra toujours accéder à un serveur DNS fonctionnel ^^ PS : question annexe... Hormis les paquets installés sur le NAS et DSM lui-même, qu'est-ce qui pourrait faire des requêtes DNS en passant par ce réglage ? Tous les conteneurs le peuvent ?

Heu non... Mais après un reboot, elle est censé être présente vu que j'ai un script qui se lance après le reboot... Du coup la prochaine fois je vérifierais. LoL J'ai oublié de faire le copier/coller ici aussi 😉 Ou alors j'ai voyagé dans une faille spatio-temporelle pour atterrir en 2340 😄 Synology a changé de nom au moins 5 fois d'ici là 😜

Ok donc normalement après le reboot que j’ai fait hier soir vers 20h mon interface virtuelle a du être recréée. Ce qui normalement permettait à mon watchtower de ce matin 6h de fonctionner correctement… étrange…

Donc si je comprend bien , si on utilise pas --privileged=true à la création d’un conteneur on n’a pas besoin de refaire l’installation. D’autant plus que ça ne concerne que l’interface dans dsm … pas via la ligne de commande et docker compose car j’ai le souvenir d’avoir déjà mis des cap-add dans certains yml…

Faut que notre spécialiste étudie la nouveauté, et nous prodigue ses bons conseils et son expertise 🙂 @.Shad.

Ha je pensais avoir mis la version 😅 dsm7. Faut que j’ajoute la version dans ma signature 😊

Ok merci ☺️ j’ai donc compris que ça permettait d’améliorer la sécurité des conteneurs. mais du coup faut-il modifier nos docker-compose.yml pour bénéficier de cet ajout de sécurité ? Et du oui comment ?

Salut par ici 🙂 J'ai fait la MAJ du paquet Docker DSM hier soir, et j'ai eu quelques soucis (voir ici : Qu'est-ce que de support de "fine grained control..." ?

Hello par ici 🙂 Dites, depuis que j'ai fait la MAJ du paquet Docker DSM hier soir, j'ai plein de petits soucis... Ça a commencé par Tautulli qui ne pouvait plus se connecter à mon PMS... (je n'ai rien changé niveau réglages...)... Puis j'ai vu cette erreur dans DSM : System failed to get External IP. J'ai rebooté le NAS, et ce dernier s'est éteint (oui je ne me suis pas trompé de ligne pour le clic, j'ai bien choisi redémarrer ^^), et pas moyen de le rallumer au bouton... il a fallu que je débranche la prise d'alimentation du NAS et que je la rebranche pour qu'il se rallume. Bref, voilà pour la mise en situation... Et ce matin, je reçois cet email de Watchtower : Could not do a head request for "lissy93/dashy:latest", falling back to regular pull. Reason: Get "https://index.docker.io/v2/": dial tcp: lookup index.docker.io on 192.168.2.210:53: read udp 172.17.0.4:42909->192.168.2.210:53: i/o timeout Unable to update container "/Dashy": Error response from daemon: Get "https://registry-1.docker.io/v2/": context deadline exceeded (Client.Timeout exceeded while awaiting headers). Proceeding to next. Could not do a head request for "gitea/gitea:1", falling back to regular pull. Reason: Get "https://index.docker.io/v2/": dial tcp: lookup index.docker.io on 192.168.2.210:53: read udp 172.17.0.4:58762->192.168.2.210:53: i/o timeout Could not do a head request for "grafana/grafana:latest", falling back to regular pull. Reason: Get "https://index.docker.io/v2/": dial tcp: lookup index.docker.io on 192.168.2.210:53: read udp 172.17.0.4:41298->192.168.2.210:53: i/o timeout Could not do a head request for "ghcr.io/linuxserver/tautulli:amd64-latest", falling back to regular pull. Reason: Get "https://ghcr.io/v2/": dial tcp: lookup ghcr.io on 192.168.2.210:53: read udp 172.17.0.4:34463->192.168.2.210:53: i/o timeout Could not do a head request for "vaultwarden/server:latest", falling back to regular pull. Reason: Get "https://index.docker.io/v2/": dial tcp: lookup index.docker.io on 192.168.2.210:53: read udp 172.17.0.4:38384->192.168.2.210:53: i/o timeout Could not do a head request for "ttionya/vaultwarden-backup:latest", falling back to regular pull. Reason: Get "https://index.docker.io/v2/": dial tcp: lookup index.docker.io on 192.168.2.210:53: read udp 172.17.0.4:39918->192.168.2.210:53: i/o timeout Could not do a head request for "ghcr.io/linuxserver/plex:latest", falling back to regular pull. Reason: Get "https://ghcr.io/v2/": dial tcp: lookup ghcr.io on 192.168.2.210:53: read udp 172.17.0.4:49616->192.168.2.210:53: i/o timeout Found new ghcr.io/linuxserver/plex:latest image (b3c421db2d05) Could not do a head request for "telegraf:latest", falling back to regular pull. Reason: Get "https://index.docker.io/v2/": dial tcp: lookup index.docker.io on 192.168.2.210:53: read udp 172.17.0.4:55395->192.168.2.210:53: i/o timeout Could not do a head request for "telegraf:latest", falling back to regular pull. Reason: Get "https://index.docker.io/v2/": dial tcp: lookup index.docker.io on 192.168.2.210:53: read udp 172.17.0.4:49073->192.168.2.210:53: i/o timeout Could not do a head request for "telegraf:latest", falling back to regular pull. Reason: Get "https://index.docker.io/v2/": dial tcp: lookup index.docker.io on 192.168.2.210:53: read udp 172.17.0.4:52051->192.168.2.210:53: i/o timeout Could not do a head request for "influxdb:1.8", falling back to regular pull. Reason: Get "https://index.docker.io/v2/": dial tcp: lookup index.docker.io on 192.168.2.210:53: read udp 172.17.0.4:53334->192.168.2.210:53: i/o timeout Could not do a head request for "ghcr.io/linuxserver/calibre-web:latest", falling back to regular pull. Reason: Get "https://ghcr.io/v2/": dial tcp: lookup ghcr.io on 192.168.2.210:53: read udp 172.17.0.4:48934->192.168.2.210:53: i/o timeout Could not do a head request for "portainer/portainer-ce:latest", falling back to regular pull. Reason: Get "https://index.docker.io/v2/": dial tcp: lookup index.docker.io on 192.168.2.210:53: read udp 172.17.0.4:47582->192.168.2.210:53: i/o timeout Found new portainer/portainer-ce:latest image (a1c22f3d250f) Could not do a head request for "ghcr.io/crazy-max/fail2ban:latest", falling back to regular pull. Reason: Get "https://ghcr.io/v2/": dial tcp: lookup ghcr.io on 192.168.2.210:53: read udp 172.17.0.4:40619->192.168.2.210:53: i/o timeout Could not do a head request for "adguard/adguardhome:latest", falling back to regular pull. Reason: Get "https://index.docker.io/v2/": dial tcp: lookup index.docker.io on 192.168.2.210:53: read udp 172.17.0.4:37464->192.168.2.210:53: i/o timeout Stopping /portainer (439b51c93047) with SIGTERM Stopping /plex_PlexMediaServer (476f6d42f77f) with SIGTERM Creating /plex_PlexMediaServer Creating /portainer Removing image 6fd0acb4c97f Removing image bc46de77a3ff Et en copiant/collant ce log... je me rends compte que c'est probablement la résolution DNS qui n'a pas marché... Car 192.168.2.210 c'est mon serveur adguard... Hier j'avais modifié les IP DNS dans DSM pour mettre en 2ème IP celle du routeur, la première étant celle de AdGuard (macvlan). Et pour une raison que j'ignore, ce matin ça a merdé... J'ai tenté là, de mettre que l'IP de mon routeur : pas de soucis cette fois-ci J'ai tenté de repasser sans configurer manuellement le DNS, donc en prenant ce qui est fourni par le serveur DHCP du routeur (donc l'IP de mon AdGuard), et là aussi watchtower n'a pas remonté d'erreurs. (J'ai bien changé le cron pour ce dernier ^^) J'ai remis le DNS personnalisé avec l'IP du routeur. Bref, je ne sais pas ce qu'il s'est passé... je verrais demain. Je vais aller aussi poser ma question sur la dernière MAJ de docker dans le bon sujet ^^ @tout de suite sur l'autre topic. PS : la maj de docker a eu lieu hier soir à 19h30, en même temps que plein d'autres paquets 😉

Haa ok c’est via la page du pms directement 😅 je suppose que tu peux faire confiance mais d’abord tu as installé ton pms comment ? en installant le paquet fourni dans le centre de paquet de dsm ? ou en récupérant sur le site de Plex le spk pour ton nas ?

En ce qui me concerne, vu que suis avec une installation sous Docker, j'ai watchtower qui met à jour tout seul comme un grand l'image fournie par Linuxserver. Donc oui j'ai la version 1.24.4.5081. PS : je ne mets pas à jour avec une version beta 🙂 Tu as récupéré le spk sur quel site ?

Vu les NAS qu'il possède, ce serait probablement une meilleure idée de passer par Docker pour installer Plex 😄

Mon .ovh me coute dans les 3€ par an 😇

Oui tout à fait. Je procédais de la sorte il y a quelques mois. nas1.ndd.tld -> dynhost du nas1 nas2.ndd.tld -> dynhost du nas2 Tu peux même créer des blabla.nas1.ndd.tld

En fait j’utilise une autre méthode pour créer un certificat wildcard (voir tuto docker acme de ce forum ) pour mon nom de domaine ovh : ça passe par une validation dns donc pas besoin des ports 443 et 80. pour mon nom de domaine synology, même si je sais pas vraiment comment il fonctionne, le certificat est aussi renouvelé correctement dans erreurs. pour ton autre question sur le VPN : j’utilise le paquet VPN Plis Server de mon routeur synology. À l’époque où j’utilisais le paquet du nas je crois que je faisais passer par le reverse proxy mais pas sûr à 100%… +1

Peut-être parce que les tests se faisaient avec DoH et FDN n'a pas encore de DoH. Enfin il me semble ^^

Rien de tout ça. Rien n'arrive sur le port 80, donc je ne l'ouvre pas. Dans mon routeur je ne route que le port 443 (et le 6690 pour Drive Server). Je n'accède jamais à mes services en HTTP sur le port 80. Donc ce port n'est pas ouvert sur internet. Je l'ai cependant autorisé pour les IP de mon LAN et les IP FR dans le parefeu du NAS, mais normalement rien n'est censé y accéder. Sauf peut-être un script php que j'avais fait à une époque pour une application. Hmmm, je ne sais pas... ta demande de certificat LE est-elle faite depuis DSM ? Edit : à la reflexion, Free est en France, donc ça doit être normal ^^

Perso le port 80 n'est pas ouvert sur mon routeur. Je fais tout passer par le port 443 et le reverse proxy 🙂 Tu utilises un nom de domaine Synology ? Si oui c'est normal que ça fonctionne même si ton port 443 n'est pas ouvert au monde 🙂 Par contre, si tu utilises un nom de domaine tiers, ça ne devrait pas fonctionner, car LE a besoin d'accéder au port 443 depuis une IP étrangère...

Oui oui je sais bien 😉 Ce que je voulais dire c'est que depuis DSM 7, je n'avais pas vu ce paquet être mis à jour ^^

Sur mon DSM 7.0.1, j'ai eu ce matin la proposition de MAJ du paquet SMB. Je crois que c'est la première fois que je vois passer une MAJ pour SMB 🙂

Salut 🙂 La même pour moi 🤪

Ouah, tu gardes tous tes certificats 😄 Moi je laisse faire le NAS ou le routeur et ils se débrouillent 😛 Du coup je ne pourrais pas confirmer ou infirmer ce que tu dis précédemment...

Pour les certificats, peut-être que celui généré pour un nom de domaine Synology ne change pas alors que c'est le cas pour un nom de domaine autre ??

Mon certificat s’est renouvelé plusieurs fois depuis que j’ai mis en route OpenVPN sur le routeur et je n’ai pas eu besoin de récréer le fichier ovpn pour mon smartphone… comment ça se fait si le certificat change au renouvellement ?

En ce qui me concerne, c'est le certificat LE du routeur pour mon nom de domaine Synology.