Mic13710

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.

Si vous ne voulez accéder à votre NAS qu'à travers wireguard, alors laissez comme vous êtes. Modifiez juste l'IP et le masque de sous-réseau de la première règle à 255.255.0.0 pour couvrir toutes les IP privées de la tranche 192.168.0.0, ou créez une nouvelle règle qui autorise la plage du wireguard de la freebox. Il n'y a pas de problème de conserver wireguard actif. Je ne sais pas si c'est possible sur celui proposé par la freebox (je ne l'utilise pas), mais il me semble que vous pouvez créer plusieurs profils de connexion. Si c'est le cas, je vous conseille de créer un profil par équipement. C'est plus restrictif (un seul utilisateur par profil) mais plus sûr car en cas de perte ou vol d'un équipement vous supprimez le profil ce qui supprime l'accès de cet équipement sans altérer les autres profils.

CQFD. C'est pourtant l'évidence et c'est ce que vous avez observé en passant par wireguard. puisque les IP de wireguard sont autorisées dans le parefeu. Par contre, sans règle de parefeu pour autoriser les IP publiques (ce que nous vous répétons depuis pas mal de messages), vous ne pourrez pas vous connecter directement au NAS.

Ce ne risque pas de marcher si vous limitez l'ip source à votre ip publique. Il faut choisir "toutes" pour que les IP externes puissent atteindre le NAS.

Parce que votre IP est partagée, vous n'avez pas la totalité des ports disponibles. Il faut aller dans votre interface client Free et demander un IP full stack. Après cette opération, votre IP publique changera et vous aurez la totalité des ports.

Que voulez-vous dire par "IP de chez moi" ? IP publique, privée ? Non. La règle doit être : Ports : uniquement ceux des applications que vous voulez utiliser de l'extérieur (https uniquement), IP source : toutes les IP de France pour commencer. Et encore une fois, ce sera la dernière, il faut ouvrir dans la freebox les ports des applications que vous voulez utiliser de l'extérieur et les diriger vers l'IP du NAS.

Pour pouvoir lire des disques en SHR sur une distribution linux, il faut installer mdadm et lvm2. Ce dernier permet de gérer le mode multiraid propre au SHR. C'est expliqué dans la procédure donnée par firlin.

En utilisant wireguard, vous devez pouvoir vous connecter au NAS directement avec son IP locale. C'est un peu le principe du VPN. Ceci bien entendu à condition que les adresses de wireguard soient ouvertes dans le parefeu. Sans wireguard, il faut faire ce que dit PiwiLabruti : créer une règle qui autorise les IP de France vers les applications que vous voulez utiliser de l'extérieur. Par exemple file station dont le port par défaut est 7001. Et pour que ce port puisse être rejoint de l'extérieur, il faut l'ouvrir dans la box et le diriger vers l'ip du NAS.

C'est normal. Le parefeu tel qu'il est paramétré n'autorise que les adresses locales et l'IP du routeur. Toutes les autres IP sont bloquées. Le tuto sert à protéger le NAS localement. Si vous voulez l'ouvrir vers l'extérieur, il faut rajouter des règles pour autoriser les IP externes à se connecter aux applications. Les IP peuvent être toutes autorisées, filtrées géographiquement, ou peuvent être dans une plage, et les applications sont à choisir dans la liste ce qui va ouvrir les ports correspondants. Ce n'est pas tout. Si vous n'utilisez pas le reverse proxy, alors il faudra aussi ouvrir les ports dans le routeur. Règle évidente de sécurité : ne jamais exposer les ports http vers l'extérieur. Seulement des ports https.