Mic13710

Il semblerait que ce soit cette url qui n'a pas fonctionné. C'est un JSON qui permet de récupérer les liens pour les api et dérouler la suite du script. Tu as ensuite accumulé les time out, le script n'a pas pu aller plus loin et s'est arrêté après plusieurs tentatives. Le site était peut-être indisponible au moment de ta demande. Attends demain pour voir si ça a évolué.

Est-ce que ça fonctionne avec les HDD ? Si oui, ce sont les ssd qui ont un problème, sinon, c'est le NAS qui a un pet' au casque. Vous pouvez faire un test de la carte mère : https://kb.synology.com/fr-fr/DSM/tutorial/Why_am_I_unable_to_install_my_Synology_NAS_and_why_is_my_power_LED_is_flashing_constantly

Je ne suis pas utilisateur de quickconnect mais il me semble que tout peut se faire sans ouverture de port, y compris les sauvegardes. Il faut seulement que les NAS distants soient des synology qui ont chacun leur propre ID quickconnect. Si ce n'est pas le cas ou que vous souhaitez utiliser les ports, voici la liste synology avec les protocoles : https://kb.synology.com/fr-fr/DSM/tutorial/What_network_ports_are_used_by_Synology_services

Les deux HDD sont aussi impactés ? Etrange. Avez-vous essayé un reset mode 2 qui permet la réinstallation de DSM ? https://kb.synology.com/fr-fr/DSM/tutorial/How_to_reset_my_Synology_NAS_7#t2 Pour le formatage, il n'y a rien de particulier à faire. Un simple formatage rapide sur un PC suffit, le but étant de détruire la partition système (la première) pour que DSM parte sur une nouvelle installation. Si vous voulez un formatage plus profond, vous trouverez facilement des outils sous linux en interfaces graphiques et/ou en lignes de commandes. Gparted par exemple devrait répondre à votre besoin.

Que tout ceci me semble compliqué ! Je ne comprends pas ce que vient faire l'upnp là dedans ni à quoi servent ces redirections côté LAN. Si vous utilisez uniquement quickconnect, vous n'avez pas besoin d'ouverture et de redirection de ports. Je pense qu'il suffit de rétablir la connexion de quickconnect et c'est tout. Néanmoins, la freebox pro comporte certaines lacunes en matière de paramétrage contrairement à la révolution et il se peut qu'il faille creuser un peu plus et vous orienter vers une configuration plus classique qui sera de toute manière bien meilleure que quickconnect.

Si je comprends bien, les deux ssd ont fonctionné dans le NAS (votre premier message). Si ça ne fonctionne plus maintenant après avoir remis les disques dans le NAS, ce n'est pas de l'incompatibilité mais seulement un problème de disque. Pour le vérifier, ne montez qu'un seul disque et faite une installation de DSM. Si ça fonctionne avec un disque et pas avec l'autre, vous aurez trouvé le coupable.

MariaDB est bien dans /var/packages/MariaDB10/ Pour la suite, je ne peux guère vous aider je n'utilise pas.

Pour la vérification de la date, c'est la date d'expiration qui est recherchée dans la fonction certificat_check() avec openssl x509 -checkend $(( (90 - RENEWAL_CYCLE) * 86400 ))Vu comment c'est construit, checkend va lire la fin de validité du certificat (en secondes) et s'il reste moins que le renewal_cycle, un nouveau certificat est demandé. Avec le certificat actuel sur 90 jours, le renewal_cycle à 61 donne en réalité un certificat renouvelé tous les 29 jours. Donc, tu as déjà un script qui tient compte de la nouvelle donne. Néanmoins, la validité du certificat LE va diminuer ces prochains mois et ça va coincer dans le bocal. Il va falloir corriger le script pour qu'il couvre les validités réduites. Edit : Désolé, j'ai mal interprété checkend. 90 = durée standard d’un certificat Let's Encrypt (pour le moment) RENEWAL_CYCLE=61 Donc : 90 - 61 = 29 jours => Le script vérifie que le certificat est encore valide dans 29 jours. C'est toujours sur une durée de 60 jours avant renouvellement. Donc, c'est bien ce que je disais, il faut passer RENEWAL_CYCLE à 31 pour que le renouvellement intervienne après 30 jours. Ceci n'est que temporaire car le problème va se poser à nouveau lorsque la durée de validité du certificat va diminuer. Cette manière de gérer la durée du certificat sur une durée fixe de 90 jours est extrêmement bizarre de toute façon. Aussi, pourquoi ne pas laisser acme.sh gérer les validités ou plus simplement utiliser les infos de ndd.conf qui donne Le_NextRenewTime et Le_NextRenewTimeStr qui sont directement écrit par acme.sh ? J'aurais bien un correctif à te proposer mais ce n'est pas le lieu pour le faire (hors sujet)

Tu as raison. Je n'étais pas connecté lorsque j'ai essayé de télécharger. Mia culpa.

D'autant que le script n'est plus disponible au téléchargement.... Déjà tu peux modifier RENEWAL_CYCLE=30 Le certificat LE est encore de 90 jours. Le renouvellement raccourci est là pour préparer l'obligation d'arriver à des certificats d'une durée de validité de 45 (ou 47 je ne sais plus) jours en 2027. Tu peux consulter le calendrier des étapes et des durées sur le net. Acme a choisi dès maintenant un délai de 30 jours pour laisser du temps (15 jours à terme) pour que le renouvellement puisse se faire avant l'échéance au moment de l'application d'une validité raccourcie. Donc mieux vaut anticiper aussi dans le script.

Pas à ma connaissance. Quand ça change, c'est un peu la surprise. Il faut suivre le github. C'est comme le passage du nom du certificat en base 64 dont la transition m'a posé quelques problèmes à l'époque sans que comprenne réellement pourquoi. Le script s'évertuait à le passer en base 64 mais j'étais obligé de le remettre en clair pour le renouvellement. Et puis c'est rentré dans l'ordre à la mise à jour suivante. Tu as noté que maintenant les certificats sont renouvelés tous les 30 jours depuis décembre ?

Ca confirme ce que j'ai déjà dit : le script python est obsolète tout comme ce tuto. Le nom du certificat en base64 est inscrit dans les fichiers de conf depuis au moins 3 ans. Le script lui le lit en clair. Je ne saurais trop vous recommander de laisser tomber ce tuto qui n'est plus maintenu depuis des années et vous tourner vers la solution de base dont je vous ai donné le lien ou vers la solution docker qui est dans la section des tutoriels. Cette dernière reprends le même fonctionnement que la solution de base dont il s'inspire.

Je viens de jeter un oeil sur le script python et effectivement, il n'est pas à jour puisqu'il recherche des valeurs qui ont été renommées comme vu plus haut : for ligne in LeNddConf : if "Le_NextRenewTime" in ligne : nextrenewtime = re.findall('\'(.*?)\'', ligne)[0] if "Le_NextRenewTimeStr" in ligne : nextrenewtimestr = re.findall('\'(.*?)\'', ligne)[0] if "SAVED_SYNO_Username" in ligne : SAVED_SYNO_Username = re.findall('\'(.*?)\'', ligne)[0] if "SAVED_SYNO_Password" in ligne : SAVED_SYNO_Password = re.findall('\'(.*?)\'', ligne)[0] if "SAVED_SYNO_DID" in ligne : SAVED_SYNO_DID = re.findall('\'(.*?)\'', ligne)[0] Ceci explique pourquoi ça ne fonctionne pas. Vous pouvez modifier le script pour les nouvelles dénominations mais cela ne garantit pas que le reste fonctionne encore.

Comme je l'ai dit, je n'utilise pas ce tuto. J'ai cru comprendre au fil de cette discussion que le script python n'est plus applicable avec les dernières versions de DSM, mais je n'en suis pas sûr. De toute manière, je n'ai jamais été convaincu de son utilité. De plus, je crois que le script en question n'est plus maintenu depuis des mois/années. J'ai un NAS dont je m'occupe qui n'est pas sous docker et pour lequel je passe par la procédure de base : GitHubSynology NAS GuideA pure Unix shell script ACME client for SSL / TLS certificate automation - acmesh-official/acme.shCa fonctionne très bien. Si votre NAS est compatible docker (ce que vous ne dites pas), alors je vous conseille de vous tourner vers le tuto correspondant.

Bonjour et bienvenue sur ce forum.