bruno78

Pour le monitoring Freebox, il s'agit du docker telegraf dans lequel on installe Python. Là il n'y a pas le choix.

@oracle7, bonne nouvelle, testé rapidement, mais a priori le script python reste compatible avec le python de base embarqué avec DSM. Il ne doit donc pas être indispensable d'installer un module python supplémentaire. Donc a priori pas de prérequis spécifique.

@oracle7, oui, le module python est un prérequis. Mais ce n'est pas le paquet le plus compliqué à installer, et Python est un prérequis aussi pour le module MailPlus . "Python modules" suffit, pas besoin de Python 3 en revanche. Je ne pense pas que ce soit un prérequis trop contraignant (surtout quand on se lance dans les manipulations sur les certificats ...). Mais je suis d'accord pour la remarque. Par contre, je suis incapable du travail de @PPJP ....en shell .... . Par contre, je ne sais pas si il y a des modèles sur lesquels ce module Python ne serait pas compatible ?

@oracle7, ben en fait j'avais penser à te demander de le tester également 🙂 .... avec toutes les précautions d'usage. C'est plus sage avant de le lâcher ... Laisse moi 1 ou 2 jours pour faire un test complet, avec génération de certificat etc ..... Et il faut aussi que je fasse un peu de mise au propre du code, commentaires, .... bref ... parce que là, à coup de rustine à droite et à gauche ... ! Après on est d'accord : un pro dira, à raison, que c'est codé avec les pieds .... Je ne suis pas pro du codage, et je ne connaissais pas python il y a 6 mois .... Mais fonctionnellement je pense que ça tient à peu prêt. Dés que c'est prêt, je t'envoie une copie en MP. Bruno78

Hello, a priori grâce à la commande synopkg list --depend-on <package> , j'ai a priori pris en compte le problème des packages dépendants. Ils sont maintenant identifiés et relancés à la suite des autres packages. Encore quelques vérifications et un test grandeur nature à faire, et je pense ne pas être loin du but. 🙂 Ci-dessous la trace de la partie finale du script, concernant le redémarrage des packages, liste établie dynamiquement à partir des informations du fichier INFO du certificat LE, et avec prise en compte des packages dépendants de ceux directement impactés dans le certificat. --- Redemarrage global des Packages et services, incl. dependants --- package AudioStation restart successfully ---- cmd #00 : /usr/syno/bin/synopkg restart AudioStation Duree 42.90 sec. package VPNCenter restart successfully ---- cmd #01 : /usr/syno/bin/synopkg restart VPNCenter Duree 24.49 sec. package SynologyDrive restart successfully ---- cmd #03 : /usr/syno/bin/synopkg restart SynologyDrive Duree 58.71 sec. package LogCenter restart successfully ---- cmd #04 : /usr/syno/bin/synopkg restart LogCenter Duree 8.46 sec. package ReplicationService restart successfully ---- cmd #05 : /usr/syno/bin/synopkg restart ReplicationService Duree 59.68 sec. package MailPlus-Server restart successfully ---- cmd #06 : /usr/syno/bin/synopkg restart MailPlus-Server Duree 132.55 sec. package FileStation restart successfully ---- cmd #07 : /usr/syno/bin/synopkg restart FileStation Duree 40.26 sec. package WebStation restart successfully ---- cmd #08 : /usr/syno/bin/synopkg restart WebStation Duree 55.49 sec. ftpd start/running, process 2924 ---- cmd #09 : initctl restart ftpd Duree 0.33 sec. package SynologyMoments restart successfully ---- cmd #10 : /usr/syno/bin/synopkg restart SynologyMoments Duree 41.42 sec. package Virtualization restart successfully ---- cmd #11 : /usr/syno/bin/synopkg restart Virtualization Duree 39.49 sec. package MailClient restart successfully ---- cmd #12 : /usr/syno/bin/synopkg restart MailClient Duree 56.96 sec. package Apache2.4 restart successfully ---- cmd #13 : /usr/syno/bin/synopkg restart Apache2.4 Duree 8.74 sec. package phpMyAdmin restart successfully ---- cmd #14 : /usr/syno/bin/synopkg restart phpMyAdmin Duree 24.65 sec. package Apache2.2 restart successfully ---- cmd #15 : /usr/syno/bin/synopkg restart Apache2.2 Duree 8.40 sec. --- Duree totale du script 605.67 sec. C'était un essai à blanc, donc sans appel à acme.sh. Les contrôles effectués ensuite ne montrent pas d'anomalie pour le moment. Tous les services semblent opérationnels. Me reste à valider de bout en bout avec la génération du nouveau certificat ....

Bonjour @Fabe56, des nouvelles de tes disques durs ???? as tu pris contact avec le support ? as tu redemarré de zéro ?

@oracle7 de ce que je comprends du script de @PPJP, il vérifie bien que le package est lancé, mais je ne crois pas qu'il regarde les dépendances. Ceci dit ce que fait exactement le script start-stop-status pour chaque package n'est pas clair pour moi ....

Bonsoir @oracle7, en fait je viens de vérifier, et on trouve l'information grâce à # synopkg list --depend-on <package> Par exemple : root@ds918xxxx:# synopkg list --depend-on WebStation Apache2.4-2.4.43-0015: Apache HTTP Server est un serveur HTTP open source pour les systèmes d'exploitation modernes, notamment Unix et Windows. Avec ce pack est installé, vous pouvez choisir Apache comme serveur principal dans Web Station. phpMyAdmin-4.9.2-0183: phpMyAdmin est un outil logiciel gratuit conçu pour gérer les bases de données MariaDB. Gérez les bases de données MariaDB stockées sur votre Synology NAS en installant ce programme. Apache2.2-2.2.34-0020: Apache HTTP Server est un serveur HTTP open source pour les systèmes d'exploitation modernes, notamment Unix et Windows. Avec ce pack est installé, vous pouvez choisir Apache comme serveur principal dans Web Station. root@ds918xxxx:# Ce qui correspond bien à ce que j'ai constaté ! à savoir que Apache 2.2, 2.4 et PhpMyAdmin dépendent bien de Webstation. A partir de là, le traitement doit être possible, .... mais encore du travail à faire alors que je me croyais prêt du but .... J'avoue que je ne sais pas si cela est traité dans le script de @PPJP, que je n'ai pas encore fait tourner .....

Bonsoir, j'ai donc aujourd'hui généralisé le script de renouvellement. Je ne lance pas réellement le renouvellement (acme.sh), mais je simule le résultat en termes de redémarrage de packages et daemons compte tenu de ma configuration. A partir du fichier INFO du certificat LE, j'obtiens la liste suivante des packages et daemons à redémarrer : --- Commandes restart Packages & Service Enable & daemon --- ---- cmd [00] /usr/syno/bin/synopkg restart AudioStation ---- cmd [01] /usr/syno/bin/synopkg restart VPNCenter ---- cmd [02] /usr/syno/bin/synopkg restart SynologyMoments ---- cmd [03] /usr/syno/bin/synopkg restart SynologyDrive ---- cmd [04] /usr/syno/bin/synopkg restart LogCenter ---- cmd [05] /usr/syno/bin/synopkg restart ReplicationService ---- cmd [06] /usr/syno/bin/synopkg restart MailPlus-Server ---- cmd [07] /usr/syno/bin/synopkg restart FileStation ---- cmd [08] /usr/syno/bin/synopkg restart WebStation ---- cmd [09] initctl --restart ftpd Avant de le lancer en automatique, je teste une à une chaque commande. Et là je m’aperçois des contraintes suivantes : le restart de SynologyDrive arrête le package SynologyMoments, mais ne le redémarre pas. Il faut donc penser à redémarrer SynologyMoments après SynologyDrive le restart de ReplicationService arrête le package VMM Manager, mais ne le redémarre pas. Il faut donc redémarrer VMM après le redémarrage de ReplicationService le restart de MailPlus-Server arrête le package MailPlus, mais ne le redémarre pas. Il faut donc le redémarrer ensuite le restart de WebStation arrête les package Apache2.2, Apache2.4 et PhpMyAdmin., mais ne les relance pas. Il faut donc les relancer ensuite. (... peut-être d'autres impacts que je n'ai pas vu .... ???) => il y a t'il une liste de dépendances des packages qui pourrait être utilisée pour que ces constatations ne soient pas empiriques ? Et être sur que cette liste est complète. Là c'est ce que j'ai pu constater de visu, mais j'ai pu rater quelque chose qui serait moins évident ! Ou alors simplement faire une liste exhaustive des packages enable/running avant le renouvellement, et s'assurer après que tout est de nouveau en service, même si pas explicitement touché par le certificat ? Par ailleurs, le redémarrage des packages est relativement long. Bien plus long en tout cas que le temps de mise à jour lorsque l'on passe par l'interface graphique du DSM pour affecter un certificat à un service ou un package. Je suis donc à peu prêt certain que DSM ne redémarre pas les packages lors d'une mise à jour de certificat. Que peut'il faire d'autre ... ???? Bruno78

bonjour @oracle7, pour le FTPS, finalement c'est le process ftpd qu'il faut redemarrer via la commande initctl. root@xxxxxx:/# initctl restart ftpd ftpd start/running, process 13147 root@dxxxxx:/# Et du coup le bon certificat est immediatement utilisé pour ce service. Je vais regarder si et comment ce serait généralisable ....

Bonjour, je viens de refaire un essai. Pour ce qui touche au package WebStation, ça fonctionne bien. 👍. Renouvellement du certificat puis redémarrage du package, et le nouveau certificat est bien pris en compte. Donc OK. Mais pour le FTPS, { "display_name" : "FTPS", "isPkg" : false, "owner" : "root", "service" : "ftpd", "subscriber" : "smbftpd" }, le nouveau certificat n'est pas pris en compte (essais sous FileZilla et WinSCP). Il faut donc surement redémarrer un service sur le DSM ??

D'accord, donc si l'un de ses 2 disques 2To est en panne, alors le RAID5 est en panne mais pas le RAID1. Il aurait donc du pouvoir réparer le RAID5 avec un disque de 2To, et a fortiori avec son nouveau disque de 4To. Me trompe-je ? A ce stade, @Fabe56 a peut-être interêt à se tourner vers le support pour connaitre la marche à suivre ?

Oui ..... mais .... d'une part DSM dit "2 disques à réparer" (donc je me dis qu'il s'agit des 2 disques 2To ? ) d'autre part, oui on serait en tolerance de panne de 1 disque si on était en 4+4+4. Or ta conf de départ était en 4+4+2+2 .... et là je ne sais pas comment ca marche la tolerance ..... En tout cas ca ne marche pas comme on le croit, sinon tu aurais pu réparer ton groupe et ton volume , "normalement", avec le nouveau disque de 4To à la place du 2To en panne. Il y a une subtilité quelque part . Mais laquelle .... ??

Juste une suggestion / question : est-ce qu'en retirant le second disque 2To (il va donc rester les 2 disques 4To de départ + le nouveau 4To) il ne sera pas possible de réparer le groupe de stockage puis le volume ?

@Fabe56, as-tu une sauvegarde complète de tes données ?

Merci @PPJP, je vais donc refaire des tests un peu plus complets ce weekend, en ne redémarrant que les packages (isPkg=True). Bruno78

ouais, en me relisant, j'avoue ne pas comprendre ce que j'ai écrit ou voulu dire. Dsl, trop confus. J'essayai, j'imagine, de comprendre pourquoi DSM indique 1 disque en panne, et 2 disques à réparer .... .

@Fabe56, je ne suis pas spécialiste du SHR, mais j'analyse comme suit (avec un vocabulaire intuitif, les spécialistes me pardonneront) : si tu regardes bien, tu as 1 disque en panne, mais 2 disques à réparer. en fait, ton volume SHR est composé de 3 "unités" de 4Go : les 2 disques de 4Go, et la dernière "unité" est composée par les 2 disques 2Go qui représenteraient ensembles le 3ème disque 4Go. je suppose que si on allait voir les tables de partitions des différents disques, cela se verrait d'une façon ou d'une autre. je ne vois pas d'autre méthode pour le DSM de construire un volume SHR de 7.2To avec la combinaison de disques dont tu disposes. Donc : as-tu un backup externe de tes données ?? sinon, il est temps d'en faire un ! ensuite, si ma vision est exacte, cela veut dire que tu peux sortir les 2 disques de 2Go : ton volume SHR sera en mode dégradé, mais il devrait toujours être accessible et operationnel à ce moment, voir ce que demande DSM pour reparer le volume SHR, et en particulier si un troisieme disque de 4Go fait l'affaire ou pas ? je ne vois pas pourquoi il refuserai .... J'insiste : avant toute chose : t'assurer d'avoir sauvegardées toutes tes données. et peut-être attendre un second avis, plus spécialisé, sur ce forum

@oracle7, là, c'est au-delà de mes connaissances. je ne peux faire que des suppositions. Et dans le doute, je redémarre tout ce qui touche au certificat .... mais c'est un peu bourrin ! encore des essais à faire (et là tu m'as donné une nouvelle piste à explorer .... 🙂 )

Hello, j'ai aussi par exemple le cas d'AudioStation : "display_name" : "AudioStation - audio", "isPkg" : false, "owner" : "root", "service" : "AudioStation", "subscriber" : "AppPortal" }, { "display_name" : "AudioStation - 45000", "isPkg" : false, "owner" : "root", "service" : "AudioStation_AltPort", "subscriber" : "AppPortal" isPkg est à "false", et pourtant AudioStation est bien un package. Je me demande que faire dans ce cas ....??? redemarrage ? Je peux tester 1 par un, pour ceux qui sont configurés chez moi, quoi faire (si redemarrage necessaire ou pas), mais je préfèrerai une règle générale, connaitre le principe de la mécanique mise en place. Sinon c'est difficilement généralisable.

Bonjour Fabe56 et bienvenu sur ce forum, un petit tour par la case "présentation" sera appréciée pour mieux connaitre ta configuration et ainsi permettre de mieux te répondre. Peux-tu ici détailler la configuration de tes disques ? (volumes, groupes de stockage, ...) afin de mieux cerner ta config ? Ainsi que les erreurs que DSM remonte ? Bruno78

Bonjour @PPJP, @oracle7, je n'ai pas encore testé le script de @PPJP. Je comprends bien le redémarrage des packages (IsPkg=true) et la distribution des fichiers *.pem du nouveau certificat. Je suis arrivé au même résultat. Mais si je comprends bien, on ne redémarre pas les services (IsPkg=false) ? Par exemple, pas de redémarrage de smbftpd/ftpd ou de ReverseProxy/a0c1ca98-2ef5-4c98-85c1-xxxxxx ? Dans ces cas là on enregistre bien les nouveaux *.pem, mais pas de redémarrage ? Merci de votre éclairage avisé Bruno78

Bonjour @PPJP, inutile de préciser que je vais regarder de près ce script. Merci pour ce travail dont je suis bien incapable (et j'ai assez peu de temps libre en ce moment , donc ca traine ) De mon côté, j'étais (je suis encore ... ) bloqué à l'étape de récupération de la liste des packages concernés et actifs, puis à leur redemarrage ... en essayant d'exploiter la sortie de la commande # synoservicecfg --status .... et c'est galère !

@vincentbls oui ca doit passer manuellement. Sauvegarde tes anciens fichiers *.pem avant. Ensuite, je ne suis pas certain de la nécessité de redemarrer, ou pas, nginx. Il me semble avoir constaté que cela est pris en compte même sans redemarrer nginx, ... mais bon au cas ou ....

@vincentbls, oui, si on regarde sur l'interface graphique du DSM (securité > certificat), le certificat est installé et on y voit les services associés. Maintenant si tu effaces le cache de ton navigateur, et que tu recharges le site en question, puis que tu examines le certificat utilisé par le navigateur, je suis prêt à parier que c'est toujours l'ancien (verifie par exemple la date d'expiration). En fait il en est ainsi, pour un certificat web, car dans la procedure tu n'as pas mis à jour les fichiers *.pem dans le repertoire /usr/local/etc/certificate/WebStation/vhost_xxxxx correspondant. Ce sont toujours les anciens fichiers.