bruno78

Merci @maxou56, @.Shad., Les traits rouges je ne sais pas, mais c'est toujours pareil sur un PC particulier avec une vieille version de Firefox. Bug graphique sur le navigateur je suppose j'ai commencé à regarder /var/log/messages, je ne trouve rien d'évident pour le moment (en fait mes manips ont été faites à 19:42, soit après la perte du moniteur). Rien fait de spécial à 19:00. entre 19:00 et 23:58, la où le moniteur de ressources semble planté, le monitoring Grafana ne rapport rien d'anormal. A 2330 puis 2345, c'est l'antivirus Essentials qui demarre le scan système puis le scan personnalisé Je vais aller voir les autres logs que vous indiquez. Merci Bruno78

@Dimebag Darrell, dans la partie "services" de ton docker-compose.yaml, tu dois introduire les montages suivants : volumes: - /volume1/docker/compose/piconfig/pietc:/etc/pihole - /volume1/docker/compose/piconfig/pidnsmasq:/etc/dnsmasq.d Le chemin /volume1/docker/compose/piconfig étant le chemin chez moi, à toi de l'adapter à ta configuration. Dés lors, au redemattage de Pihole même avec une nouvelle image, tes données précédentes seront toujours là.

Oui pour le réseau il doit être "mal supprimé". et du coup pour le recréer ca ne passe pas. Par ailleurs, tu ne montes pas de volumes pour la persistence (répertoires /etc/pihole et /etc/dnsmasq.d) ? Enfin, pour que les DNS personnalisés soient pris en compte, il faut les rajouter dans la section environment : environment: ServerIP: 192.168.x.xxx# <-- Update (match NAS ipv4_address) DNS1: 80.67.169.12 DNS2: 80.67.169.40

Bonjour, ce matin je viens vers vous car mon ds918 a redémarré cette nuit, tout seul et sans raison apparente. Apparemment le redémarrage s'est par la suite bien déroulé, et il est ce matin parfaitement fonctionnel. Mais que s'est' il passé ??? Je précise qu'il est évidemment sur onduleur, qu'il n'y a pas eu de coupure de courant ni de passage sur onduleur, et qu'il n'y avait pas de tache planifiée à l'heure du redémarrage. Ci dessous le journal : Niveau Journal Heure Utilisateur Evénement Information Système 2020/07/15 00:00:33 SYSTEM [Synology Drive Server] service was started. Information Système 2020/07/14 23:59:28 SYSTEM [Cloud Sync] service was started. Warning Système 2020/07/14 23:59:16 SYSTEM System booted up from an improper shutdown. Information Système 2020/07/14 23:58:59 SYSTEM VPN profile [Connection] is connecting to [142.xx.xxx.1]. (protocol[OpenVPN], IP[10.10.10.2], interface[tun0]) Error Système 2020/07/14 23:58:59 SYSTEM Failed to send email. (Failed to resolve host address.). Information Système 2020/07/14 23:58:30 SYSTEM IP address [169.254.90.208] and subnet mask [255.255.0.0] were assigned to the DHCP client on [ovs_eth1]. Information Système 2020/07/14 23:57:49 SYSTEM Local UPS was plugged in. Information Système 2020/07/14 23:57:38 SYSTEM System started to boot up. Information Système 2020/07/14 19:49:02 SYSTEM VPN profile [Connection] is connecting to [142.xx.xxx.1]. (protocol[OpenVPN], IP[10.10.10.2], interface[tun0]) Warning Système 2020/07/14 19:48:58 SYSTEM VPN profile [Connection] was disconnected by server. Quelles seraient les pistes d'investigations ? quels journaux / logs seraient pertinents à aller vérifier ? Merci d'avance Bruno78 PS : a priori pas de perte de données, mais il faut que je vérifie plus en détail seul point visible : le cache SSD (R/W) est passé d'une utilisation à 93% (depuis plus d'un mois), à seulement 12% .... . Alors qu'a priori lors d'un reboot normal par l'opérateur, de mémoire, on ne perd pas le cache SSD. PS2 : j'étais hier en train de faire des tests pour un script automatique de suppression de fichiers logs et sauvegardes, avec essai réel à 1900, or si je regarde le Moniteur de Ressources : => Il s'est passé un truc bizarre à 1900 ! et pourtant le système répondait normalement .....

Bonjour @Dimebag Darrell, pourras-tu stp nous montrer ton fichier docker-compose.yaml ? j'ai un script qui me fait l'update automatique du pihole 1 fois par mois, il est passé en 5.0 sans même que je n'y prête attention (mais il faut avoir les bons volumes déclarés dans le docker-compose ainsi que les variables d'environnement) ! Le script enchaine dans l'ordre les 4 commandes suivantes : docker-compose pull pihole docker stop pihole-pihole1 docker rm pihole-pihole1 docker-compose up -d pihole Ça doit surement pouvoir s'optimiser, mais cela fonctionne parfaitement. Si nouvelle image pihole:latest il y a , alors elle sera téléchargée et utilisée par le docker au redemarrage.

Oui j'ai tendance à croire que c'est un faux problème, .... même si je ne vois pas ce que fait cet item dans le fichier INFO, ni à quoi correspond le sous répertoire system contenant des fichiers *.pem dans l'arborescence /usr/syno/etc/certificate/ ... Donc ce que je vais faire pour le moment, c'est copier dans ce répertoire les nouveaux fichiers *.pem du certificat renouvellé, mais ne rien redémarrer d'un tout .... car on ne sait pas ce qu'il faudrait, peut-être, redémarrer. Test complet de l'ensemble du script avec renouvellement effectif prévu demain :-).

@oracle7, j'ai passé une bonne partie de l'après midi à tourner autour de cette item : { "display_name" : "DSM Desktop Service", "display_name_i18n" : "common:web_desktop", "isPkg" : false, "owner" : "root", "service" : "default", "subscriber" : "system" }, le redémarrage du service DSM, oui ca se fait. synoservice --hard-disable DSM synoservice --hard-enable DSM Mais rien ne prouve que cela va bien traiter cette entrée du fichier INFO, et prendre en compte le certificat déposé dans /usr/syno/etc/certificate/system ensuite, je me suis intéressé au service system. Pas réussi à en faire grand chose. Impossible à arrêter / redémarrer en commande opérateur. Et je passe sur le fait que bien qu'enable, son status soit error root@ds918:/usr/syno/etc/certificate# synoservice --status system service [system] status=[error] required upstart job: [3rdparty-services] is stop. [before-halt] is stop. [dsm-services] is stop. [fullburnin] is stop. [fullburninbylan] is stop. [hostname] is stop. [kill-all-process] is stop. [logrotate] is stop. [network-interface] is stop. [network-pppoe] is stop. [network] is stop. [poweroff] is stop. [rc-sysinit] is stop. [rc] is stop. [reboot] is stop. [root-file-system] is stop. [smallupdate] is stop. [grinst-create-vol] is stop. [syno_poweroff_task] is stop. [syslog-ng] is start. [tty] is start. [umount-root-fs] is stop. [synolog-service-handler] is stop. [synorelay-service-handler] is stop. [udevd] is start. [udevtrigger] is stop. [dsmupdate] is stop. [syno-auth-check] is stop. [dhcp-client] is stop. [syno-network-check] is start. [synortc] is stop. [synoddsm-ctnd] is stop. [cgmanager] is start. [dhcp-client6] is stop. ======================================= root@ds918:/usr/syno/etc/certificate# Donc au final je ne sais toujours pas quoi faire de cet item. ....

@oracle7 .... non non pas du tout, au contraire. Je ne sais pas comment traiter ce point. Et d'ailleurs, à supposer que l'on redemarre DSM ou synoscgi ou synocgid (lequel ???), je ne sais pas vérifier si le nouveau certificat est pris en compte ou pas .... donc je ne sais pas quoi faire .... Mais je me dis que redemmarrer DSM Desktop n'est pas forcément anodin et/ou sans risque ... D'où le fait que je vais d'abord regarder sur un VDSM.

@oracle7, exact ! Par ailleurs : root@ds918:# synoservice --status DSM Service [DSM] status=[enable] required upstart job: [synoscgi] is start. ======================================= root@ds918:# synoservicecfg --status | grep synocgi Service [synocgid] status=[enable] [synocgid] is start. root@ds918:# je pense que je vais d'abord tester sur un Virtual DSM .... pas envie de tout planter !

@oracle7, dans le renouvellement du certificat, il reste un item que je n'ai pas su traiter : { "display_name" : "DSM Desktop Service", "display_name_i18n" : "common:web_desktop", "isPkg" : false, "owner" : "root", "service" : "default", "subscriber" : "system" }, De quoi s'agit'il ? comment le traiter ? Bruno78

@.Shad., je mets la methode (2) (container python independant) sur ma to-do list. Je n'y avais pas pensé.

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 ?