Mic13710

Sauf erreur de ma part, le reverse proxy du Syno n'est pas capable de résoudre une adresse du type ndd/xxxx/

https:\\ndd.fr\photo ne te renvoie pas vers photo station ? On voit bien ici que c'est acme-v02 qui est utilisé parce que tu as pris un wildcard. La même ligne chez moi est en acme-v01 puisque je n'ai que des ndd en dur.

Moi je n'ai qu'un seul dossier pour le ndd. Dans ce dossier, il y a un ndd.conf dans lequel on trouve : Le_Domain='ndd' Le_Alt='file.ndd,audio.ndd,etc.....' Regardes dans ton ndd.conf si tu ne retrouves pas le wildcard. Dans la suite de mon ndd.conf, il y a aussi : Le_Webroot='dns_ovh' Le_PreHook='' Le_PostHook='' Le_RenewHook='' Le_API='https://acme-v01.api.letsencrypt.org/directory' Le_Keylength='' La dernière ligne est intéressante. La tienne devrait indiquer 4096.

A mon avis la commande devrait être : 0 10 2 * * root root/.acme.sh/acme.sh --cron --home root/.acme.sh/

Ta ligne n'est pas bonne. Il faut que tu remplaces /usr/local/share/acme.sh/acme.sh par l'emplacement de ton acme.sh et /usr/local/share/acme.sh/ par celui de tes clés dans le dossier acme.sh.

Comme on n'a pas suivi le même tuto, ça explique que nous ne soyons pas dans le même bus. L'emplacement sur le tuto Gihub a été modifié le 28 juin 2017 par un des intervenants pour je cite : change the acme.sh install home to a persistent location Je présume que l'ancien emplacement était sujet à modif à chaque maj de DSM. Si ton acme.sh est installé ailleurs, il est bien évident que tu dois modifier le chemin dans le cron.

Euh, corrige ta ligne parce que là, ça ne le fait pas. T'as fumé la moquette ? 0 10 2 * * root root/.acme.sh/ndd.tld --cron --home root/.acme.sh/ Non tu ne changes rien. Le cron fait simplement appel au script qui va vérifier que ton certificat est valide. Sauf erreur, ton script est installé dans /usr/local/share/acme.sh/acme.sh et les clés de ton certificat sont bien dans un dossier ***.fr du dossier parent /usr/local/share/acme.sh/ Vérifie que tu as bien toi aussi le dossier ***.fr dans acme.sh. Rassures-toi, j'ai moi aussi le même dossier ***.fr dans root/.acme.sh Il faudrait éplucher en détail le script pour savoir si c'est lui qui fait le boulot dans les 2 dossiers. Je pense que oui. Ceci étant dit, j'ai lancé la tache planifiée manuellement car il se trouve que j'avais forcé le renouvellement de mon certif hier et que tous ceux qui étaient dans les dossiers du CERTROOTDIR étaient encore sous l'ancien certificat. Le script a bien fonctionné, tous les dossiers se sont mis à jour avec le nouveau, mais ensuite DSM m'a annoncé qu'il y avait un problème. Je me suis dit qu'à cela ne tienne, je vais redémarrer le NAS. Mais après le redémarrage, mon certif n'était plus acceptés et j'ai dû me connecter avec une exception. Pour retrouver mes petits, j'ai été obligé de revalider tous les domaines pour les passer sur le certificat Synology que j'ai heureusement gardé, puis j'ai à nouveau remis les domaines sur leur certificat pour que ça fonctionne à nouveau. Il y a donc un processus interne à DSM qui permet la validation des certificats du reverse proxy. Il doit y avoir autre chose à rajouter dans le script pour que les nouveaux certif soient acceptés. Quoi ? Je n'en sais rien. Pas simple cette affaire.

Ca pourrait sans doute fonctionner pour les dossiers existants. Par contre, toute création d'un nouveau proxy reprendra les fichiers du cert actif qui ne seront pas mis à jour lors du prochain renouvellement, sauf a rajouter manuellement les liens symboliques. Amha, autant laisser le script faire tout seul son boulot de maj.

Il est inutile de forcer le renouvellement si le cert est toujours valide. Inspire toi de ce qui a été fait dans le tuto que j'ai utilisé. En gros, tu as une tâche cron qui se déclenche tous les 2 de chaque mois pour vérifier si le certificat est à jour, et s'il ne l'est pas, acme.sh lance le renouvellement. La copie auto des 3 fichiers n'est pas suffisante. Il faut aussi la faire dans tous les dossiers du reverse proxy. Là aussi regarde la tâche planifiée du même tuto. En gros, tu balayes tous les dossiers contenus dans /usr/syno/etc/certificate et tu mets à jour tous les .pem. Puis tu redémarres tous les packages pour que le nouveau cert soit pris en compte.

C'est étonnant car c'est dans le script acme.sh. Il n'accepte peut-être pas le wildcard. Et pourtant il est sensé pouvoir le prendre en compte.

@Balooforever C'est ce que j'avais fait aussi parce que l'installation n'avait pas fonctionné. Et du coup le script de maj ne fonctionnait pas. Je viens de refaire l'install complète en force et ça a l'air de fonctionner. Je verrai dans un mois si le renouvellement se fait. Le message est normal. Il fallait ensuite revenir dans OVH avec le lien pour le credential token qui était donné dans les messages. C'est ce qui permet de mettre en place l'api et évite de rajouter des txt dans la zone. Pour la mise en place du certificat, il faut suivre l'alternative method du tuto https://github.com/Neilpang/acme.sh/wiki/Synology-NAS-Guide Les certificats se trouvent dans /usr/syno/etc/certificate/_archive/"nom aléatoire du dossier que tu dois aller chercher"/

Je viens de reprendre le tuto Github et il y a à mon avis une erreur de dossier, ce qui a empêché la mise à jour. Il est préférable d'utiliser la "Alternative method that preserves your Synology NAS system default certificate" car elle ne touche pas au certificat Synology (qu'on peut supprimer manuellement si besoin à partir de DSM) et qui utilise le même "Ramdom_Folder" que celui du script de renouvellement.

Ce n'est pas un scoop....

Oui. export OVH_AK="ton application key donnée par OVH" export OVH_AS="ton application secret donné par OVH" Ne pas oublier les guillemets

Il n'y a pas de problème. On peut faire cohabiter des disques différents au sein d'un même groupe de disques. Il est tout de même plus prudent (mais non obligatoire) d'utiliser des disques aux performances similaires. En l’occurrence, la différence entre 5400 et 5900 est minime et les temps d'accès sont du même ordre. Donc pas de souci.

Il faut d'abord que tu obtiennes les clés en allant sur le lien du 1. Tu te connectes avec tes identifiants OVH et tu auras les clés que tu exportes dans le NAS comme c'est indiqué.

Tu suis simplement les points 2, 3 et 4 du lien que je t'ai donné. Dans le message du 2, tu auras un lien du genre : https://eu.api.ovh.com/auth/?credentialToken=n0Qbjm6wBdBr2KiSqIuYSEnixxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx que tu vas utiliser pour le 3. Si c'est OK, le point 4 devrait être OK aussi.

Inutile de prendre des disques RED. Les bleu font parfaitement le job. La seule vrai différence c'est la garantie de 3 ans au lieu de 2, garantie qui se retrouve dans le prix. A vous de voir si ça vaut le coup. Inutile non plus de prendre des 7200 qui consomment plus pour aucun gain en performance. Vous pouvez augmenter la taille de vos disques. Il faudra le faire pour les 2 disques d'un même raid pour pouvoir étendre la taille du volume. Par contre, le déplacement du volume 1 vers des disques 1 et 2 n'est pas envisageable. La seule possibilité c'est de créer un nouveau volume et d'y transférer les dossiers via DSM.

Pour l'installation, j'ai utilisé ce tuto : https://github.com/Neilpang/acme.sh/wiki/Synology-NAS-Guide Pour l'API OVH, celui-ci : https://github.com/Neilpang/acme.sh/wiki/How-to-use-OVH-domain-api Je n'ai rien trouvé pour ce qui est du wildcard. Comme tu dis, il faut attendre que quelqu'un se penche sur le sujet et nous ponde un beau tuto . Ceci étant dit, j'ai tout de même un soucis pour le renouvellement auto. Le cron a fonctionné mais le certificat n'a pas été mis à jour. Je vais en toucher un mot à l'auteur.

Je ne cherche pas spécialement à avoir un certificat wildcard. Mon intervention avait simplement pour but de signaler que l'opération n'est pas triviale. C'est sur que pour une première mise en oeuvre, le wildcard permet de ne pas avoir à lister tous les domaines et de pouvoir en créer à l'infini. Néanmoins, je préfère cibler les domaines auxquels j'accède. Sauf cas particuliers, on en crée pas tous les jours non plus. Une fois la liste en place, les renouvellements automatiques évitent de devoir y toucher. J'ai dû utiliser la méthode DNS-01 pour le NAS de mon frère car le port 80 est bloqué par son FAI. Je suis passé par l'API OVH et j'ai créé un certificat standard avec tous les SAN dont il a besoin. Je n'ai pas creusé d'avantage le projet acme.sh, mais il semblerait qu'il supporte l'ACME v2 wildcard certs. Voir https://github.com/Neilpang/acme.sh Le tout est de savoir comment le mettre en place sur nos NAS.

C'est impossible. Les disques seront formatés et vous perdrez toutes les données qui sont dessus. Il vous faut trouver un moyen de lire un de vos disques sur un PC et de procéder au transfert des données sur le NAS en montant des lecteurs distants.

Petit quiz. Soit un couloir avec 2 portes : une porte extérieure qui s'appelle 7002 et qui conduit dans un hall comportant plusieurs portes. Une de ces portes s'appelle 7001. Derrière cette porte, il y a une glace au chocolat. Quand je suis dehors et que j'ouvre la porte 7002, ma domotique ouvre automatiquement la 7001, et à condition qu'il n'y ait pas de barrière, j'accède à la glace au chocolat. Question : quand je suis dans le hall et que je veux accéder à la glace, qu'elle porte dois-je ouvrir ? Si vous indiquez : 192.168.....:7002, il y a peu de chance pour que vous atteignez le nas. Ensuite : avez-vous autorisé le port 7001 dans le portail des applications du 415 et ce port est il autorisé dans le parefeu ?

Qu'est ce que vous voulez dire par là. Le nom du NAS n'a rien à voir avec le serveur DNS. Le serveur DNS ne peut résoudre que des noms de domaine. Vous pouvez ensuite faire pointer un ndd vers l'IP du NAS. Par exemple : nas.mondomaine vers l'IP privée du NAS. Vous avez dejà la réponse dans votre autre fil. Allez voir le lien donné par InfoYann (partie dynamique uniquement) Faire vos enregistrements CNAME dans la zone DNS d'OVH. Inspirez vous de mon tuto en page 2. Les enregistrements restent similaires quel que soit l'endroit où est localisée la zone, dans le NAS dans mon cas, chez OVH dans le votre.

@Chris_B merci de ne pas répéter inutilement le message précédent. Est-ce que dans la vie de tous les jours vous répétez la question de votre interlocuteur avant de répondre ?

Il n'y a pas de profil par défaut. La liste est vide au départ. S'il y a des règles enregistrées, c'est que vous avez installé des paquets qui ont eux mêmes créé leurs règles. Tous les ports sont ouverts parce que vous n'avez pas encore mis de règle de blocage. Relisez le tuto de Fenrir sur ce point.