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.

Ce n'est pas le script acme qui utilise les données Saved_SYNO. C'est synology_dsm.sh. Ce script n'a pas été modifié depuis 2023. Si le script mentionne bien SAVED_SYNO_Username et SAVED_SYNO_Password c'est uniquement pour les convertir en SAVED_SYNO_USERNAME et SAVED_SYNO_PASSWORD pour une question de rétrocompatibilité. En effet, les anciennes versions utilisaient les minuscules et pour pouvoir les convertir sans avoir à intervenir sur le fichier de configuration, le script accepte l'ancienne écriture et réécrit la nouvelle dans le fichier .conf. Ce sont ces lignes dans le script qui font l'opération de rétrocompatibilité. _migratedeployconf SYNO_Username SYNO_USERNAME _migratedeployconf SYNO_Password SYNO_PASSWORD _migratedeployconf SYNO_Device_ID SYNO_DEVICE_ID _migratedeployconf SYNO_Device_Name SYNO_DEVICE_NAME La fonction _migratedeployconf dit en substance : si tu trouves une valeur sauvegardée sous l'ancien nom, copie-la automatiquement sous le nouveau nom. Sauf si votre script n'est pas à jour, le fait d'avoir ou pas des minuscules n'aurait pas du bloquer son déroulement, et le passage en tout majuscule lors de la mise à jour est normal puisque c'est l'écriture reconnue dans le script. Pour SYNO_DEVICE_ID inscrit dans le fichier ndd.conf, je parlais par rapport à mes NAS. Je n'utilise pas la méthode de ce script mais je passe par docker et il se peut que le fonctionnement soit un peu différent d'une méthode à l'autre, bien que le principe d'obtention et de déploiement du certificat soit rigoureusement le même.

Bonjour @AlexB12 , soyez le bienvenu sur ce forum

Ce n'est pas ce que disent les logs : Vous êtes sûr que le renouvellement a été fait ? SYNO_DEVICE_ID est une donnée qui correspond à l'identification du syno. Je ne sais pas comment acme.sh la récupère ni comment il l'utilise (il faudrait analyser le script) mais elle est inscrite en dur dans le fichier XXXXXXXXX.com.conf. Vérifiez qu'elle existe bien dans ce fichier.

Il ne faut pas confondre détection de mouvement et enregistrement. Si la caméra gère la détection de mouvement, elle envoie toute détection vers SS même si on est en home mode. La caméra ne peut pas faire de détection du home mode de SS. Elle fait juste son boulot selon le planning dans ses paramètres. C'est pour cela que dans la partie Enregistrement de SS - Mouvement, tous les mouvements détectés par les caméras sont répertoriés. Si le home mode est désactivé, l'enregistrement sera lancé et créera un fichier. S'il est activé et que l'enregistrement est désactivé dans le home mode, alors aucun enregistrement ne sera effectué. La détection de mouvement sera simplement listée dans Mouvement avec une vignette de la détection mais aucun enregistrement ne sera déclenché.

C'est effectivement curieux que le monitoring ne soit pas fait sur l'arrêt non contrôlé du NAS. Mais est-ce que l'ups est connecté au NAS pour assurer une mise en sécurité en cas de perte secteur ? Si c'était le cas, il y aurait pu avoir quelque chose dans les logs sur le passage en mode secouru, à condition que l'ups soit en état de fonctionner et avec une capacité réelle de la batterie suffisante pour alimenter le nas pendant tout le processus de mise en sécurité.

Quel volume avez vous agrandi ? Si c'est le 1 alors DSM a fait le déplacement du 2 vers la fin du stockage. En tout cas, c'est super que vous ayez pu étendre votre volume comme vous le souhaitiez.

Je ne pense pas que ça corresponde à ta configuration car tes NAS sont sur deux sites différents. L'action dont je parle se passe avec le CMS de surveillance station, pas celui des NAS et concerne plutôt des NAS opérant sur le même site. Lorsque tu actives ou désactives le home mode sur le NAS principal, tu peux envoyer une url vers le NAS distant pour qu'il active ou désactive son home mode. C'est en créant et appliquant des règles d'action On Off qu'on peut le faire. Il faut deux règles séparées, une pour le On et une pour le Off. Mais je ne développerai pas ici car nous sommes hors sujet.

Malheureusement, les 2 volumes sont contigus. Vous pouvez seulement étendre le volume 2 avec l'espace disponible. Pour étendre le volume 1, il faut supprimer le volume 2. Ce que vous pouvez faire c'est déplacer les dossiers partagés du volume 2 sur le volume 1 Pour cela il faut changer le volume de destination du dossier à déplacer dans le menu Dossiers partagés. DSM fera le déplacement du dossier et de son contenu du volume 2 sur le volume 1. Par contre, je ne peux pas vous dire comment procéder pour le site web. Il va falloir creuser la question. Une fois ce point résolu, vous pourrez supprimer le volume 2, puis augmenter la taille du volume 1 soit sur la totalité de l'espace disponible, soit en laissant de l'espace pour recréer un nouveau volume 2. Je vous recommande de ne garder qu'un seul volume car la solution à plusieurs volumes n'est pas un cloisonnement efficace. C'est plus simple à gérer. Autre solution moins contraignante si vous ne voulez ou ne pouvez pas déplacer votre site web c'est d'étendre le volume 2 et d'y déplacer des dossiers partagés du volume 1. Ce n'est pas très élégant mais ça a le mérite de ne pas détruire l'existant.

Oui mais il faut utiliser les règles d'action pour que le home mode maitre active ou désactive le home mode des autres NAS.

Le plus simple c'est d'essayer. Mais si vous voulez un conseil, il serait préférable de faire des sauvegardes restaurations avec hyperbackup. Ainsi vous préserverez les time codes des fichiers puisque les données seront restaurées à l'identique et vous pouvez aussi sauvegarder restaurer les paramètres des applications qui sont disponibles dans hyperbackup pour la sauvegarde.