.Shad.

Bienvenue !

Ou alors je n'ai pas trouvé comment faire. En outre je ne sais plus aller consulter mon profil.

Et impossible d'éditer ses propres messages.

Toujours pas trouvé comment on accède à ses messages privés. Soit ce n'est pas faisable, soir je suis complètement aveugle.

Est-ce que tu avais bien mis une validité infinie à la création de l'API ? Il se pourrait que la validé ait expiré et que du coup l'authentification ne fonctionne pas car les credentials n'existent plus. Il faut vérifier dans l'API d'OVH.

Bienvenue parmi nous !

En réalité, il faut bien différencier ce que fait : user: "x:y" et ce que font les variables PUID, PGID. Dans le premier cas, ça revient à chown dans le conteneur de ce qu'on met dans "volumes:" Donc les fichiers et dossiers auront pour utilisateur x et groupe y. Ca peut parfois mener à des problèmes de fonctionnement. PUID et PGID, variables généralisées sur les images Linuxserver, mais on trouve l'équivalent sur bien d'autres images, fait correspondre l'utilisateur dans le conteneur, souvent "abc" dans les images de LS, avec l'utilisateur dont on précise les uid/gid. C'est beaucoup plus subtil et n'impacte pas le fonctionnement du conteneur.

Toutes ces variables sont des variables créées par le conteneur nécessaire pour son fonctionnement. La liste des variables qui représentent un intérêt pour l'utilisateur : https://hub.docker.com/r/linuxserver/calibre-web Quand tu ne précises rien, le conteneur est créé en mode bridge, c'est lié aux réglages par défaut du démon dockerd (et c'est l'utilisation qu'on désire habituellement). Exactement.

Et bien j'imagine la même utilité qu'ailleurs pour le PATH, mais pour tous les binaires situés à l'intérieur du conteneur. HOME c'est assez clair ^^ TERM j'imagine que ça a un rapport avec le terminal, mais comme ça... je ne sais pas.

A partir du moment où tu as exécuté acme.sh une fois et déployé dans la foulée, le fichier ndd.tld.conf comprend d'une part les variables SAVED_SYNO et d'autre part l'option Le_DeployHook avec l'appel au plugin synology_dsm.sh qui déclenche le déploiement automatiquement après le renouvellement du certificat. Sans possibilité de l'empêcher. Supposons que je souhaite déployer le script sur 2 instances de DSM, la première fois que je vais exécuter le script, il n'y aura pas de fichier ndd.tld.conf, donc il va faire un issue, puis un renew, puis un deploy_1 et un deploy_2. 60j après, lors du premier renouvellement de certificat, au moment du renew, il va directement déployer dans la foulée. Si j'ai laissé les variables SAVED_SYNO dans le fichier .conf, il va déployer sur le NAS2, puis viendra le déploiement sur NAS1, puis re-NAS2. Avec le même script j'ai donc un comportement différent suivant qu'un certificat antérieurement ou pas. En supprimant également la ligne Le_DeployHook, je m'assure qu'il reproduise à chaque exécution le même script : issue -> renew -> deploy_1 ->deploy_2 En supprimant les variables SAVED_SYNO, je suis sûr et certain de l'ordre dans lequel les certificats vont se déployer. Si des variables SAVED_SYNO existent déjà dans le fichier ndd.tld.conf, acme.sh --deploy ne les écrasera pas, même si on en spécifie d'autres avant le déploiement.

Ces variables sont créées par l'image lors du déploiement du conteneur. Oui tout se fait par l'interface d'administration par après.

De rien 🙂

Salut @oracle7 Merci de ton retour, alors pour la première remarque tu as vu juste, elle est obligatoire après chaque déploiement pour supprimer notamment le "cache" des variables SYNO_XXXX qui peut mener à des erreurs, surtout si on déploie sur plusieurs NAS. Ok pour le DID, je l'ai ajouté et je vais préciser ceci dans le tutoriel en pointant vers le tien. Pour les variables à récupérer, ok pour récupérer le CERT_DIR (renommé CERT_HOME pour une question de cohérence avec la variable dans le fichier account.conf). Pour le fichier .conf du certificat, je n'ai rien à y récupérer (acme.sh oui mais ça c'est son problème), je dois même justement enlever des variables (Le_DeployHook et les SAVED_SYNO en l'occurrence). Pour la commande cp -p, bonne remarque merci c'est ajouté. 🙂 PS : Idéalement j'aurais souhaité utiliser la commande getopts pour passer les variables de personnalisation dans la commande du script, j'en ai compris les grands traits mais pas réussi à la mettre en application pour le moment, si tu as un point de vue je suis tout ouïe. 😉

Les permissions pour Photo Station se gèrent dans Photo Station, c'est moche je suis d'accord mais c'est comme ça. 😞

Ca ne peut pas fonctionner car tu fais correspondre le port 32785 (tu as sûrement laissé en "auto") du NAS avec le port 8083 du conteneur, en gros il te faut : et toi tu fais : Pour l'accès à la DB, il faudrait voir ce que tu as monté comme volume, quel est l'équivalent chez toi de l'image de @quart-temps ?

Bienvenue !

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.