.Shad.

Tu peux mettre une impression d'écran du pare-feu de ton NAS ? Que donne en SSH un nslookup dsm.exemple.ovh ?

Et tu as bien activé les ports personnalisés pour les applications en question dans Portail des applications ?

Regarde sur ton impression d'écran, on voit que le port local c'est 32783, 8083 c'est le port du conteneur. Et qu'est-ce qu'il fait là le port 3389 ? Actuellement, ça marchera (sous réserve que tout a bien été paramétré) si tu vas à l'adresse http://192.168.1.11:32782 Reprend le tutoriel, il y a des choses qui t'ont échappé à mon avis.

Ce n'est pas le problème car mon domaine racine pointe vers une IP OVH bidon, je me sers de mon DynDNS pour atteindre mon IP publique. Vers quelle IP peux-tu vouloir faire pointer ton domaine racine dans ta zone DNS quand ton IP est dynamique ? Il faut plus d'informations, des impressions d'écran par exemple, concernant : - la configuration de tes entrées de proxy inverse. - les redirections de port faites dans ta box Ce que tu as écrit là me fait penser que tu n'as pas tout saisi à l'intérêt du proxy inversé. Ou qu'il y a un défaut de configuration dans DSM.

Quelle est l'adresse que tu entres dans ton navigateur ? (aucun besoin de cacher l'adresse IP, c'est une IP privée on n'en fera rien)

Bienvenue, mais il existe un tutoriel qui couvre ta question : Le fait d'avoir une IP dynamique ou fixe ne change quasi rien à ce sujet.

Pré-requis Ce tutoriel s'adresse à ceux qui ont déjà parcouru le tutoriel de @Fenrir sur la mise en place d'un serveur DNS, et qui sont allés jusqu'à héberger la zone publique de leur domaine. On part donc dans l'hypothèse que : vous hébergez votre zone DNS, qu'elle est SOA (Start of Authority). Le NAS hébergeant la zone est un serveur de nom (nameserver ou NS) pour cette zone et ce nom de domaine. vous avez éventuellement (c'est fortement recommandé mais non obligatoire) d'autres serveurs de noms, auto-hébergés (autre(s) NAS), votre registrar (OVH, etc...) ou des hébergeurs DNS (Cloudflare, GoDaddy, etc...). vous êtes relativement à l'aise avec le vocabulaire relatif au DNS. vous avez installé acme.sh sur votre NAS. Préambule L'origine de ce tutoriel vient de la volonté de @Jeff777 de trouver un moyen de mettre en place un renouvellement automatique de son certificat pour son domaine. Merci à lui pour le nombre incalculable de tests qu'il a effectués et pour les feedback complets qu'il m'a procurés. Dans la foulée, on s'est dit que ça pourrait intéresser d'autres personnes, d'où ce tutoriel. 😉 Même si on a bien conscience que le nombre de personnes concernées est très marginal. Actuellement, pour un nom de domaine Synology, DSM inclut la possibilité de renouveler automatiquement un certificat wildcard depuis l'interface dédiée dans l'onglet Sécurité. Pour tout autre nom de domaine, on est tributaire de logiciels tiers comme par exemple acme.sh, un script gérant l'obtention et le renouvellement automatique des certificats. Lorsqu'on héberge sa zone DNS chez un registrar ou un hébergeur DNS connu, on a des grandes chances qu'acme.sh dispose d'un plugin permettant de communiquer avec l'API de l'hébergeur en question. Sous réserve de bien configurer les paramètres du script, tout sera automatisé. Ce n'est évidemment pas le cas lorsqu'on héberge soi-même sa zone. Plusieurs solutions existent : https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mode : J'héberge sur mon NAS la zone publique maître de mon domaine, mais je dispose d'un autre nom de domaine hébergé chez un prestataire mettant à disposition une API par laquelle acme.sh peut communiquer (par exemple OVH). Je redirige donc les enregistrements _acme.challenge nécessaires pour la validation de notre premier domaine vers le second. Je me sers donc du 2ème nom de domaine pour valider le premier. Facile et malin, à prioriser quand applicable. https://github.com/acmesh-official/acme.sh/wiki/DNS-API-Dev-Guide : développer sa propre API en créant son propre plugin de communication. Clairement pas à la portée de tout le monde, mais sûrement la meilleure méthode qui soit. Développer un script permettant d'extraire les enregistrements TXT _acme.challenge et les ajouter à sa zone pour la validation. C'est cette dernière solution que nous nous sommes attachés à développer. Hypothèses Vous avez déjà installé acme.sh sur votre NAS via ligne de commande, vous pouvez trouver une procédure détaillée dans le tutoriel de @oracle7, à suivre jusqu'au point 2) inclus. J'attire l'attention sur les arguments utilisés lors de l'installation d'acme.sh --home : il permet de définir où est installé le script acme.sh et les fichiers qui l'accompagnent. --cert-home : c'est le dossier dans lequel les certificats sont sauvegardés lorsqu'ils sont générés. Paramétrage du script Maintenant qu'acme.sh est installé, vous pouvez téléchargez le script et le placer où vous le souhaitez dans votre NAS : dsm_public-dns-zone_renewal_automation_15-02-22.sh Il va falloir maintenant le configurer, je l'édite ici directement dans File Station avec le paquet Éditeur de texte dans le centre de paquets Synology. Vous pouvez évidemment l'éditer en SSH avec votre éditeur de texte préféré. Il va falloir attribuer une valeur à certaines variables pour que le script s'exécute sans encombre. Ces variables se trouvent dans la fonction init(), dans la sous-partie titrée VARIABLES TO SET. Par commodité, je reprends certains noms de variables utilisés dans le tutoriel de @oracle7. CERT_DOMAIN : c'est le nom de domaine racine ("root") pour lequel vous souhaitez obtenir un certificat CERT_WDOMAIN : le domaine wildcard ZONE_NAME : le nom de la zone telle qu'elle apparaît dans cet écran : ou via SSH dans le dossier /var/packages/DNSServer/target/named/etc/zone/master/ : RENEWAL_CYCLE : c'est le cycle de renouvellement du certificat tel que : 60 ≤ RENEWAL_CYCLE < 90 (en jours). acme.sh ne renouvellera pas "naturellement" un script dont l'âge est inférieur à 60 jours, l'expiration intervenant au 90ème jour. On peut pour autant, si on le souhaite, forcer le renouvellement en ajoutant le paramètre --force à l'issue et au renew du certificat : acme.sh --force --issue [...] acme.sh --force --renew [...] ACME_DIR : c'est le dossier dans lequel vous avez installé acme.sh en amont de ce tutoriel via --home. CERT_HOME : c'est le dossier que vous avez défini comme répertoire de sauvegarde des certificats via --cert-home lors de l'installation d'acme. REMARQUE : Pour les besoins du script, il est nécessaire de renseigner cette dernière variable, même si c'est le même dossier que celui défini via --home. Ne pas ajouter de / à la fin des chemins renseignés dans ACME_DIR et CERT_HOME. Si l'on souhaite déployer automatiquement le certificat sur le NAS, on va devoir également paramétrer la fonction certificate_deployment_1 un peu plus bas dans le script : Il faut compléter les différentes variables SYNO_, par exemple : SYNO_Scheme='http' SYNO_Hostname='ns.ndd.tld' SYNO_Port='5000' SYNO_Username='admin' SYNO_Password='password' SYNO_Certificate="un_nom_de_certificat" SYNO_DID="" Notes : ns.ndd.tld étant l'objet d'un enregistrement A ou CNAME pointant vers l'IP de mon NAS, qu'elle soit locale ou publique (dans ce dernier cas, ce sera l'IP de la box internet, par exemple dans le cas d'un NAS hors-site). 5000 étant le port HTTP par défaut de DSM (on a choisi HTTP comme protocole en première ligne), à adapter au besoin (en cas de NAS distant, le port DSM (ou 443 si proxy inverse) doit être redirigé vers le NAS). Si vous disposez déjà d'un certificat wildcard pour ce domaine, alors il faut que la variable SYNO_Certificate soit identique au nom du certificat existant (voir cadre rouge ci-dessous). Cela permettra que tous les services qui y sont actuellement associés soient redémarrés lors du déploiement du certificat dans DSM. Si on veut déployer le certificat sur un autre NAS, on s'aperçoit que le script contient une fonction certificate_deployment_2. Il suffit alors de décommenter cette fonction (enlever tous les # devant chaque ligne, de certificate_deployment 2() { à }) et de décommenter les 2 lignes reprises dans le script : On peut ainsi ajouter autant de NAS que l'on souhaite, il suffit de définir autant de nouvelles fonctions certificate_deployment que nécessaire, et d'ajouter juste avant la ligne echo -e "\n### STEP 6 ###" pour chaque NAS un couple de lignes certificate_deployment_N et saved_syno_values_removing. Typiquement, dans le cadre d'un NAS distant, vous utilisez peut-être un proxy inverse pour limiter le nombre de ports exposés, vous pouvez passer par celui-ci pour déployer le certificat, en modifiant les variables suivantes, par exemple : SYNO_Scheme='https' SYNO_Hostname='dsm.ndd.tld' SYNO_Port='443' dsm.ndd.tld étant le nom de domaine pointant vers l'interface DSM sur le NAS. SYNO_DID est à compléter si on utilise la double authentification pour se connecter à DSM, voir le point 5.1) du tutoriel de @oracle7 Il n'y a aucune obligation de procéder au déploiement du certificat, vous pourriez très bien vouloir l'utiliser sur un autre périphérique. Il suffit dans ce cas-là de commenter les lignes certificate_deployment_1 et saved_syno_values_removing qui suit immédiatement (voir impression d'écran ci-avant). Les certificats pourront être récupérés dans le dossier défini dans ${CERT_HOME}/ndd.tld Remarques Dans le cas où vous n'avez pas déjà de certificat pour ce nom de domaine importé sur le NAS, il y aura une étape supplémentaire à réaliser manuellement après la première exécution du script. En effet, les services et applications de votre NAS sont par défaut associés au certificat Synology.com créé à l'installation de DSM, ou à tout autre certificat créé par après. Lorsque le script va s'exécuter et que vous le déployez sur votre NAS, vous verrez apparaître le nouveau certificat dans l'onglet qui les liste. Il sera configuré par défaut, mais les services seront toujours configurés pour le certificat antérieur, exemple (nom de domaine Synology antérieur au nom de domaine OVH) : Il faut donc cliquer sur Configurer, et attribuer les services souhaités au nouveau certificat. Lors du prochain renouvellement, les services associés seront redémarrés et exploiteront le nouveau certificat. C'est donc une opération à ne réaliser qu'une seule fois, dans l'hypothèse où vous n'avez pas encore de certificat pour ce nom de domaine. @bruno78 a développé un script en python3 permettant de transférer les services d'un certificat à l'autre, au besoin consulter le tutoriel de @oracle7 dont le lien a été donné plus avant. Dans le cas où un certificat pour le nom de domaine existerait déjà sur votre NAS, le script redémarrera naturellement les services qui y sont déjà associés, il faut toutefois veiller à avoir le même nom de certificat (déjà expliqué en amont). Lors de l'exécution du script, le fichier de zone original est dupliqué dans le dossier ${CERT_HOME}/ndd.tld/backup_... et un log d'acme.sh est disponible dans ${CERT_HOME}/ndd.tld En cas d'interruption inopinée du script, le fichier de zone original reste accessible. Si le script s'exécute jusqu'au bout, le duplicata de la zone originale et le log sont effacés. En outre, si le script ne s'exécute pas entièrement, vous devrez peut-être amené à supprimer Planification du renouvellement Le script intègre une fonction de vérification de validité du certificat, tant que le certificat n'est pas âgé de plus de RENEWAL_CYCLE jours, le renouvellement sera bloqué en amont. Dès lors, vous pouvez très bien créer une tâche régulière qui vérifiera fréquemment, par exemple toutes les semaines ou tous les quelques jours, si le certificat a besoin d'être renouvelé. On va donc dans Panneau de configuration -> Planificateur de tâches -> Créer -> Tâche planifiée -> Script défini par l'utilisateur : On définit donc une tâche exécutant le script où qu'il se trouve, ici pour l'exemple dans /volume1/scripts/ et on génère un log complet du script dans le fichier /volume1/Certs/log_acme_$(date +"%d-%m-%y").log, ce qui donnera au moment où j'écris log_acme_30-09-20.log On peut demander au planificateur de tâches d'envoyer par mail le résultat du script, pour peu qu'on ait configuré le service de notification de DSM. MàJ : 15/02/22

Pour moi oui, et tu n'as même pas besoin de la permission d'exécution, r/w suffit donc chmod 600 c'est bon. 👌 Je ne te le conseille pas, car tu joues avec des fichiers système (/var/run/docker.sock), même si, théoriquement : si tu utilisais le groupe "docker" caché, ça pourrait le faire. Mais pour moi il ne faut pas jouer avec ça quand on monte des fichiers système, je te conseille de laisser root/root (donc ne rien préciser dans le docker-compose).

Quel est l'intérêt ? Si tu veux contrôler l'IP (pour quelle raison d'ailleurs pour ce conteneur ?), tu peux créer un réseau dans le docker-compose de watchtower où tu fixes son IP. Je ne vois pas l'intérêt de l'ajouter au réseau de monitoring ? Tu peux utiliser cette solution : https://docs.docker.com/compose/environment-variables/#the-env-file Seulement si tu autorises les utilisateurs standards à accéder à ce dossier en lecture. Pas compris la question, le fichier est juste là en cas de dépôt autre, comme des dépôts privés ou comme GitLab. Vu que j'utilisais l'image d'un ami un temps, j'avais dû monter ce fichier. Tu le places où tu veux, il faut juste que ça corresponde dans le conteneur à : /root/.docker/config.json Dans le .env_file si tu veux faire mieux d'un point de vue sécurité, sinon dans les variables d'environnement comme je l'ai fait, voir plus avant. Ce sont les identifiant et mot de passe de ton compte mail.

Ah ouais une coquille de ma part ! Merci de l'avoir vue, comme tu vois c'était tellement semblable que je suis reparti du même fichier, et y a eu un oubli au passage. Tu peux le mettre sur le réseau que tu veux, l'idéal étant d'éviter d'exposer des conteneurs entre eux si ce n'est pas utile. Attention par contre, dans le fichier docker-compose que j'ai fourni, j'utilise le paramètre : network_mode: bridge Ce qui veut dire que j'utilise le bridge par défaut, donc dans la plage 172.17.0.0, et le conteneur prend par défaut la prochaine IP libre. Dans ce cas-là il ne faut pas utiliser le paramètre networks. Ou alors inversement, tu supprimes network_mode: bridge et tu laisses bien le paramètre networks et les options que tu y adjoins. Quand tu mets des conteneurs dans un même réseau bridge personnalisé, tous les conteneurs exposent tous leurs ports entre eux. Pas forcément raccord avec la philosophie d'isolation de Docker. 😉

Salut, Personnellement j'utilise la méthode 1.2 plutôt, ainsi je n'ai rien à ajouter à ouroboros quand je crée un nouveau conteneur. Pour info j'ai switché vers watchtower qui est nouveau activement développé, mais c'est peu ou prou la même méthode que pour ouroboros : version: '2.1' services: ouroboros: image: containrrr/watchtower container_name: watchtower hostname: watchtower network_mode: bridge environment: - WATCHTOWER_NOTIFICATIONS=email - WATCHTOWER_NOTIFICATION_EMAIL_FROM=XXX - WATCHTOWER_NOTIFICATION_EMAIL_TO=XXX - WATCHTOWER_NOTIFICATION_EMAIL_SERVER=XXX - WATCHTOWER_NOTIFICATION_EMAIL_SERVER_USER=XXX - WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PASSWORD=XXX - WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PORT=XXX - WATCHTOWER_NOTIFICATION_EMAIL_SUBJECTTAG=[DS918+] - WATCHTOWER_CLEANUP=true - WATCHTOWER_DEBUG=true - WATCHTOWER_LABEL_ENABLE=true - WATCHTOWER_TIMEOUT=30s - WATCHTOWER_SCHEDULE=0 0 5 * * 6 - TZ=Europe/Brussels labels: - "com.centurylinklabs.watchtower.enable=true" volumes: - /var/run/docker.sock:/var/run/docker.sock - ./config.json:/root/.docker/config.json restart: unless-stopped

Personne ?

Oui si tu pouvais expliciter cette partie. A moins d'avoir un NAS avec plusieurs ports Ethernet je ne vois pas comment ton montage est possible. Normalement le nœud doit être le modem dans ton cas.

Je vais essayer d'apprendre un peu aussi, j'aimerais y héberger des fichiers docker-compose, pour les télécharger directement au lieu de devoir les transférer d'une machine à l'autre quand j'ai besoin. 🙂

Je ne sais pas si tu as pensé à faire un repo GitHub pour ton (tes?) script ça pourrait être intéressant 🙂

En tant que quadra tu fais partie des jeunes ici 😄 Bienvenue 😉

Pour être sûr de comprendre, ton NAS est relié comment au reste de ton réseau ? Un petit schéma (à la main ou sur draw.io par exemple) pourrait aider à comprendre d'où vient le problème.

Salut, bienvenue parmi nous. Il est intéressant que tu dises quel modèle de NAS tu possèdes de manière à ce qu'on adapte nos réponses à ses possibilités.

La section Networks ne concerne que les routeurs USG ou USW. Si tu as juste des points d'accès cette section ne sert à rien (c'est tordu car généralement tu as un flag USG pour indiquer que c'est une fonctionnalité qui ne concerne pas l'AP).

Bienvenue parmi nous 🙂

Bienvenue parmi nous 🙂

Je viens de tester sur mon NAS, le snmpwalk marche très bien, que ce soit l'adresse IP locale ou l'adresse passerelle. Essaie avec localhost ? Est-ce que "public" est bien le nom de ta communauté ? Pourquoi tu as à la fois l'IP locale du NAS et l'adresse passerelle ? tu pointes vers le NAS dans les deux cas.

Tu exécutes la commande depuis une session SSH du NAS ? Ou une autre machine du réseau ? PS : Évite d'utiliser le protocole SNMPv1 -v1, utilise plutôt -v2c

Là comme ça c'est difficile de t'aider, il nous faut plus d'éléments : est-ce qu'un ping de l'IP du NAS fonctionne ? Est-ce qu'il a déjà fonctionné normalement par le passé ? Un reset simple mode 1 pourrait peut-être résoudre le problème (reset des credentials + config réseau). Tu trouveras plus d'infos sur le reset mode 1 sur le site de Synology.

Bienvenue parmi nous ;)