bruno78

Bonjour, j'avoue avoir suivi cet échange et fait les différents essais (.htaccess, reverse-proxy), .... je ne comprends pas. Cela ne fonctionne pas. Je tourne en rond. les ports 80 et 443 sont ouverts (Fbox et FW NAS) sans même parler de redirection ou de reverse proxy : http://nas.ndd.tld/photo => OK j'arrive en http sur la page d'accueil de PhotoStation https://nas.ndd.tld/photo => KO : message : "Synology, Sorry the page you are looking for is not found" bien sûr, si je lance https://nas.ndd.tld, j'arrive bien en https sur mon NAS et lorsque je suis connecté au NAS sous DSM, en https, si je clique sur l'icone "PhotoStation", même chose : "Synology, Sorry the page you are looking for is not found" je pense (je suis sûr) que j'ai raté une marche ..... mais laquelle ????? Merci de vos lumières. Bruno78

@oracle7, @kerod, je vois que les échanges sont nombreux. Donc je vais résumer ma position en ce qui concerne le script Python je me suis lancé dans ce script afin de terminer l'automatisation du renouvellement de certificats. Au mois autant par défi que réelle nécessité (réaffecter les services une fois tous les 3 mois, ce n'est pas la mer à boire) je ne suis ni informaticien ni programmeur professionnel, donc j'accepte les critiques constructives (et surtout les conseils !) sur la façon de coder, pas de soucis .... et bien évidemment sur les erreurs typo si il y en a. Ainsi que les ajouts fonctionnels si nécessaire. Et il y a 6 mois je ne connaissais pas Python, ...... 🙂 suite à une première mouture, @oracle7 m'a donné une aide précieuse en acceptant de jouer les cobayes et en validant le script., et en me donnant un certain nombre de pistes à explorer. A cet occasion le script a fait un bond en avant ! encore merci @oracle7 qui est l'auteur de ce Tuto. ensuite, on a décidé de le "lâcher", estimant son niveau "suffisant" On savait très bien que des mains expertes allaient s'en emparer, et c'est tant mieux. Sur les échanges ci-dessus que je n'ai parcouru qu'en diagonale (je suis en congés , pas chez moi, ..... peu de connexion, .... ) l'option log -l --log fait reference à l'option log de acme.sh. Pas de acme.sh => pas de log. Si nécessaire, cela peut entrer dans ma todo list ! si quelqu'un souhaite améliorer le script, pas de problème non plus si c'est partagé. Je ne m'estime pas propriétaire exclusif. Par contre si vous me demandez de faire des évolutions, j'y répondrai dans la mesure de mes moyens. comme je le disais, je ne reviendrai vraiment sur le forum que mi août. Je prendrai la liste des évolutions à réaliser à ce moment là. Merci de votre compréhension. Bien à vous Bruno78

@pascalg57, c'est relativement clair : si tu n'as pas le serveur SFTP actif .... Lorsque tu te connectes donc a priori en "root" et SFTP avec WinSCP, que vois-tu indiqué en bas à droite de la fenêtre WinSCP ? un petit cadena jaune, puis "SCP" ou SFTP-3 ? ou ???

Et du coup, après avoir fait un certains nombre de tentatives (sur une VM DSM et l'avoir plantée plusieurs fois) je crains que la restriction posée par Syno sur l'accès "root" en sftp au NAS ne soit guère surmontable, en tout cas pour moi. DOnc oui, l'option de @.Shad. de passer par un Docker openssh-server doit pouvoir contourner le problème. Perso, pour l'usage que j'en fais, je peux me contenter des limitations actuelles. Bien à vous, Bruno78

@oracle7, je ne dirais pas que ça me rassure, mais au moins on est cohérent. En fait c'est ce qui se passe quand tu n'actives pas sftp sur le NAS. Alors WinSCP se replie sur le protocole SCP. Mais lorsque le sftp tourne sur le NAS, alors même si il y a un problème, WinSCP ne se replie pas sur SCP et on reste en erreur essayant désespérément de passer par sftp. C'est configuré là sur WinSCP : Bruno78

Bonjour @pascalg57, WinSCP user "root" protocole "SFTP" fonctionne avec une paire de clés ssh-2 ??? quels sont tes réglages stp ? @oracle7, comme de bien entendu, le compte "admin" standard DSM est désactivé. J'utilise donc un autre compte "toto" appartenant au groupe "administrators". après la génération de la paire de clé, je teste d'abord avec Putty, user = "root" => OK. Ici je ne mentionne pas du tout le user "toto" du groupe "administrators". L'échange de clés est bien fonctionnel. Puis sous WinSCP, avec la même paire de clé, le même user = "root" : si protocole SCP : puis connexion OK : si protocole SFTP, toutes choses égales par ailleurs : mais ensuite et si je prends l'utilisateur "toto" du groupe "adminsitrator" en SFTP : puis en saisissant le mot de passe du compte "toto" (pas de la clé refusée) : connexion OK en SFTP => donc le serveur SFTP fonctionne Et donc le seul problème, c'est le user "root" avec le protocole "SFTP" .... Donc si quelqu'un sait faire fonctionner ce cas là. .... Merci Bruno78

Bonjour @pascalg57, merci mais ..... non . Sans effet. Bruno78

Merci @.Shad., j'avais pourtant l'impression que certains y arrivait. Mais oui cela ne semble pas évident. Pour ce qui est de l'utilisateur "root", cela fonctionne parfaitement en SCP (y compris la console), donc je vais rester là dessus pour le moment. Juste un mot : j'ai essayer d'utiliser la paire de clés privée/publique pour un autre utilisateur que "root" ou "admin" (utilisateur disable suivant les bonnes pratiques), et WinSCP me répond : "le serveur a refusé la clé". Alors que j'avais pourtant bien créé et rempli le <home>/.ssh/autorized_keys pour cet utilisateur ... ? Il y a t'il quelque chose de plus à configurer ? Cdt Bruno78

Bonjour, là je m'arrache les cheveux ! suivi le tuto à la lettre (enfin je crois, je l'ai refais plusieurs fois, et même résultat à chaque fois) bref je génère la paire de clé, l'installe sous /root/.ssh/authorized_keys, puis la prend en compte sous putty et WInSCP ça fonctionne parfaitement avec putty ça ne fonctionne jamais avec WinSCP en sftp ("verifier que le serveur SFTP est bien démarre sur votre serveur) avec root. Sur le NAS, ce qui apparait, c'est SFTP client [root] from [192.168.1.116] was rejected to log in the server. par contre cela fonctionne systématiquement avec : root mais en protocole SCP autre user admin avec mot de passe en sftp Je ne comprends pas pourquoi root en sftp ne passe jamais. Et oui : j'ai desinstallé et reinstallé Putty et WinSCP plusieurs fois j'ai mis un mot de passe pour la clé ssh sans caractères spéciaux ... Bref je ne sais plus où chercher . Si une âme charitable passe par ici ..... Merci d'avance Bruno78

Merci @.Shad., dmesg -T donne le résultat suivant, mais le reboot est déjà en route ! on ne voit pas ce qui se passe juste avant : [Tue Jul 14 23:56:07 2020] Initializing cgroup subsys cpuset [Tue Jul 14 23:56:07 2020] Initializing cgroup subsys cpu [Tue Jul 14 23:56:07 2020] Initializing cgroup subsys cpuacct [Tue Jul 14 23:56:07 2020] Linux version 4.4.59+ (root@build3) (gcc version 4.9.3 20150311 (prerelease) (crosstool-NG 1.20.0) ) #25426 SMP PREEMPT Tue May 12 04:54:55 CST 2020 [Tue Jul 14 23:56:07 2020] Command line: root=/dev/md0 earlyprintk=apl console=ttyS2,115200n8 ihd_num=4 netif_num=2 HddHotplug=1 SataPortMap=23 sata_remap=0>2:1>3:2>0:3>1 syno_hw_version=DS918+ vender_format_version=2 syno_hdd_detect=18,179,176,175 syno_hdd_enable=21,20,19,9 syno_usb_vbus_gpio=13@0000:00:15.0@1,11@0000:00:15.0@2 sn=xxxxxxxxxx macs=xxxxxxxxxx,xxxxxxxxxx [Tue Jul 14 23:56:07 2020] KERNEL supported cpus: [Tue Jul 14 23:56:07 2020] Intel GenuineIntel [Tue Jul 14 23:56:07 2020] x86/fpu: xstate_offset[3]: 960, xstate_sizes[3]: 64 [Tue Jul 14 23:56:07 2020] x86/fpu: xstate_offset[4]: 1024, xstate_sizes[4]: 64 [Tue Jul 14 23:56:07 2020] x86/fpu: Supporting XSAVE feature 0x01: 'x87 floating point registers' [Tue Jul 14 23:56:07 2020] x86/fpu: Supporting XSAVE feature 0x02: 'SSE registers' [Tue Jul 14 23:56:07 2020] x86/fpu: Supporting XSAVE feature 0x08: 'MPX bounds registers' [Tue Jul 14 23:56:07 2020] x86/fpu: Supporting XSAVE feature 0x10: 'MPX CSR' [Tue Jul 14 23:56:07 2020] x86/fpu: Enabled xstate features 0x1b, context size is 1088 bytes, using 'standard' format. [Tue Jul 14 23:56:07 2020] e820: BIOS-provided physical RAM map: [Tue Jul 14 23:56:07 2020] BIOS-e820: [mem 0x0000000000000000-0x0000000000057fff] usable [Tue Jul 14 23:56:07 2020] BIOS-e820: [mem 0x0000000000058000-0x0000000000058fff] reserved [Tue Jul 14 23:56:07 2020] BIOS-e820: [mem 0x0000000000059000-0x0000000000085fff] usable [Tue Jul 14 23:56:07 2020] BIOS-e820: [mem 0x0000000000086000-0x00000000000fffff] reserved [Tue Jul 14 23:56:07 2020] BIOS-e820: [mem 0x0000000000100000-0x000000000fffffff] usable [Tue Jul 14 23:56:07 2020] BIOS-e820: [mem 0x0000000010000000-0x0000000012150fff] reserved [Tue Jul 14 23:56:07 2020] BIOS-e820: [mem 0x0000000012151000-0x0000000067c17fff] usable J'ai ouvert un ticket de support, et j'ai eu comme réponse un "plantage de la Virtualization / kvm", sans autre forme de procès ... : "kernel panic caused by kvm functions" A priori j'ai retrouvé une situation stable et saine, et je ne pense pas avoir perdu de données malgré le vidage des caches NVME. Je vais continuer à surveiller de prêt. Cdt Bruno78

ok parfait

Bonjour, sur un ancien projet en PHP et mariaDB10, j'ai une syntaxe de connexion legèrement differente : mais il y a un moment que je ne suis pas revenu dessus. Mais ça fonctionne. $dbconnect=mysqli_connect($hostname,$username,$password,$db); if (!$dbconnect) { echo "Erreur : Impossible de se connecter MySQL." . PHP_EOL; echo "Errno de dbogage : " . mysqli_connect_errno() . PHP_EOL; echo "Erreur de dbogage : " . mysqli_connect_error() . PHP_EOL; exit; }

Bonjour, sur le /var/log/message : il ne se passe rien à 1900 : entre 13:42 et 19:48, rien. A 19:48 c'est le VPN qui redemarre (après 24h). 2020-07-14T13:42:01+02:00 ds918blam synoupgrade_SYNO.Core.Upgrade.Server_2_check[20303]: updatechecker.cpp:69 synoinstall: Failed to get security json 2020-07-14T13:42:01+02:00 ds918blam synoupgrade_SYNO.Core.Upgrade.Server_2_check[20303]: updatechecker.cpp:224 synoinstall: Failed to get parser 2020-07-14T19:48:58+02:00 ds918blam synovpnc: connection.c:1530 SLIBCSzHashGetValue(ds_dns) failed 2020-07-14T19:48:58+02:00 ds918blam synonetd: base_hook.cpp:74 Hook environment is not valid 2020-07-14T19:48:58+02:00 ds918blam synovpnc: connection.c:246 Fail to get interface info. 2020-07-14T19:48:58+02:00 ds918blam openvpn[1736]: WARNING: file '/tmp/ovpn_client_up' is group or others accessible 2020-07-14T19:48:58+02:00 ds918blam openvpn[1739]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts ensuite à 23:57:37 c'est le reboot alors que l'antivirus a demarré quelques minutes plus tôt 2020-07-14T19:49:15+02:00 ds918blam synomustache: synomustache.cpp:88 Failed to load /var/packages/Spreadsheet/target/etc/Spreadsheet.mustache [No such file or directory] 2020-07-14T19:49:15+02:00 ds918blam synomustache: synomustache.cpp:88 Failed to load /var/packages/Spreadsheet/target/etc/Spreadsheet.mustache [No such file or directory] 2020-07-14T19:49:17+02:00 ds918blam synomustache: SYSTEM: Last message 'synomustache.cpp:88 ' repeated 1 times, suppressed by syslog-ng on ds918blam 2020-07-14T19:49:17+02:00 ds918blam [3302117.064932] init: scsi_plugin_server main process (6343) killed by TERM signal 2020-07-14T19:57:08+02:00 ds918blam [3302588.061774] init: synoscheduler-vmtouch main process (12602) killed by TERM signal 2020-07-14T23:41:59+02:00 ds918blam synoavscan: synoav_engine.c:122 Initialize engine with 25873 2020-07-14T23:52:57+02:00 ds918blam synoavscan: synoav_engine.c:122 Initialize engine with 25873 2020-07-14T23:57:37+02:00 ds918blam kernel: [ 0.000000] ACPI: RSDP 0x000000007AFFE014 000024 (v02 INSYDE) 2020-07-14T23:57:37+02:00 ds918blam kernel: [ 0.000000] ACPI: XSDT 0x000000007AFDA188 0000DC (v01 INSYDE INSYDE 00000003 01000013) 2020-07-14T23:57:37+02:00 ds918blam kernel: [ 0.000000] ACPI: FACP 0x000000007AFF5000 000114 (v06 INSYDE INSYDE 00000003 ACPI 00040000) 2020-07-14T23:57:37+02:00 ds918blam kernel: [ 0.000000] ACPI: DSDT 0x000000007AFE6000 00772B (v02 INSYDE INSYDE 00000003 ACPI 00040000) 2020-07-14T23:57:37+02:00 ds918blam kernel: [ 0.000000] ACPI: FACS 0x000000007AFAF000 000040 2020-07-14T23:57:37+02:00 ds918blam kernel: [ 0.000000] ACPI: FACS 0x000000007AFAF000 000040 2020-07-14T23:57:37+02:00 ds918blam kernel: SYSTEM: Last message '[ 0.000000] ACPI:' repeated 1 times, suppressed by syslog-ng on ds918blam 2020-07-14T23:57:37+02:00 ds918blam kernel: [ 0.000000] ACPI: UEFI 0x000000007AFFD000 000236 (v01 INSYDE INSYDE 00000001 ACPI 00040000) 2020-07-14T23:57:37+02:00 ds918blam kernel: [ 0.000000] ACPI: BDAT 0x000000007AFFB000 000030 (v02 INSYDE INSYDE 00000000 ACPI 00040000) 2020-07-14T23:57:37+02:00 ds918blam kernel: [ 0.000000] ACPI: UEFI 0x000000007AFFA000 000042 (v01 INSYDE INSYDE 00000002 ACPI 00040000) 2020-07-14T23:57:37+02:00 ds918blam kernel: [ 0.000000] ACPI: SSDT 0x000000007AFF9000 000554 (v01 INSYDE Tpm2Tabl 00001000 ACPI 00040000) 2020-07-14T23:57:37+02:00 ds918blam kernel: [ 0.000000] ACPI: TPM2 0x000000007AFF8000 000034 (v03 INSYDE INSYDE 00000002 ACPI 00040000)

Bonjour, 27557 0 -rw-r--r-- 1 root root 0 Jul 15 00:57 dmesg 28746 52 -rw-r--r-- 1 root root 49864 Jul 14 23:58 dmesg.1.xz dmesg est vide, tandis que les fichiers dmesg.{1,2,3,4}.xz sont illisibles. Quant à /var/log/syslog.log : (l'IP du NAS est 192.168.1.171) 2020-07-14T09:51:43+02:00 ds918blam syslog-ng[4665]: Configuration reload request received, reloading configuration; 2020-07-14T21:55:02+02:00 ds918blam syslog-ng[4665]: Configuration reload request received, reloading configuration; 2020-07-14T23:57:37+02:00 ds918blam syslog-ng[4727]: syslog-ng starting up; version='3.7.3' 2020-07-14T23:57:46+02:00 ds918blam syslog-ng[4727]: Connection failed; fd='33', server='AF_UNIX(/var/run/synologan.sock)', local='AF_UNIX(anonymous)', error='No such file or directory (2)' 2020-07-14T23:57:46+02:00 ds918blam syslog-ng[4727]: Initiating connection failed, reconnecting; time_reopen='10' 2020-07-14T23:57:46+02:00 ds918blam syslog-ng[4727]: Error binding socket; addr='AF_UNIX(/var/packages/DNSServer/target/named/dev/log)', error='No such file or directory (2)' 2020-07-14T23:57:46+02:00 ds918blam syslog-ng[4727]: Connection failed; fd='39', server='AF_INET(192.168.1.171:9527)', local='AF_INET(0.0.0.0:0)', error='Network is unreachable (101)' 2020-07-14T23:57:46+02:00 ds918blam syslog-ng[4727]: Initiating connection failed, reconnecting; time_reopen='10' 2020-07-14T23:57:46+02:00 ds918blam syslog-ng[4727]: Connection failed; fd='39', server='AF_INET(192.168.1.171:9528)', local='AF_INET(0.0.0.0:0)', error='Network is unreachable (101)' 2020-07-14T23:57:46+02:00 ds918blam syslog-ng[4727]: Initiating connection failed, reconnecting; time_reopen='10' 2020-07-14T23:57:46+02:00 ds918blam syslog-ng[4727]: Connection failed; fd='39', server='AF_INET(192.168.1.171:9529)', local='AF_INET(0.0.0.0:0)', error='Network is unreachable (101)' 2020-07-14T23:57:46+02:00 ds918blam syslog-ng[4727]: Initiating connection failed, reconnecting; time_reopen='10' 2020-07-14T23:57:46+02:00 ds918blam syslog-ng[4727]: Connection failed; fd='39', server='AF_INET(192.168.1.171:9526)', local='AF_INET(0.0.0.0:0)', error='Network is unreachable (101)' 2020-07-14T23:57:46+02:00 ds918blam syslog-ng[4727]: Initiating connection failed, reconnecting; time_reopen='10' 2020-07-14T23:57:46+02:00 ds918blam syslog-ng[4727]: Configuration reload request received, reloading configuration; 2020-07-14T23:57:56+02:00 ds918blam syslog-ng[4727]: Connection failed; fd='48', server='AF_UNIX(/var/run/synologan.sock)', local='AF_UNIX(anonymous)', error='No such file or directory (2)' 2020-07-14T23:57:56+02:00 ds918blam syslog-ng[4727]: Initiating connection failed, reconnecting; time_reopen='10' 2020-07-14T23:57:56+02:00 ds918blam syslog-ng[4727]: Syslog connection accepted; fd='52', client='AF_INET(192.168.1.171:34343)', local='AF_INET(0.0.0.0:9527)' 2020-07-14T23:57:56+02:00 ds918blam syslog-ng[4727]: Syslog connection accepted; fd='53', client='AF_INET(192.168.1.171:41453)', local='AF_INET(0.0.0.0:9528)' 2020-07-14T23:57:56+02:00 ds918blam syslog-ng[4727]: Syslog connection accepted; fd='54', client='AF_INET(192.168.1.171:41176)', local='AF_INET(0.0.0.0:9529)' 2020-07-14T23:57:56+02:00 ds918blam syslog-ng[4727]: Syslog connection accepted; fd='55', client='AF_INET(192.168.1.171:41584)', local='AF_INET(0.0.0.0:9526)' 2020-07-14T23:57:56+02:00 ds918blam syslog-ng[4727]: Syslog connection established; fd='48', server='AF_INET(192.168.1.171:9527)', local='AF_INET(0.0.0.0:0)' 2020-07-14T23:57:56+02:00 ds918blam syslog-ng[4727]: Syslog connection established; fd='49', server='AF_INET(192.168.1.171:9528)', local='AF_INET(0.0.0.0:0)' 2020-07-14T23:57:56+02:00 ds918blam syslog-ng[4727]: Syslog connection established; fd='50', server='AF_INET(192.168.1.171:9529)', local='AF_INET(0.0.0.0:0)' 2020-07-14T23:57:56+02:00 ds918blam syslog-ng[4727]: Syslog connection established; fd='51', server='AF_INET(192.168.1.171:9526)', local='AF_INET(0.0.0.0:0)' 2020-07-14T23:58:06+02:00 ds918blam syslog-ng[4727]: Connection failed; fd='40', server='AF_UNIX(/var/run/synologan.sock)', local='AF_UNIX(anonymous)', error='No such file or directory (2)' 2020-07-14T23:58:06+02:00 ds918blam syslog-ng[4727]: Initiating connection failed, reconnecting; time_reopen='10' 2020-07-14T23:58:16+02:00 ds918blam syslog-ng[4727]: Syslog connection established; fd='28', server='AF_UNIX(/var/run/synologan.sock)', local='AF_UNIX(anonymous)' 2020-07-14T23:58:56+02:00 ds918blam syslog-ng[4727]: Transport aux data overflow, some fields may not be associated with the message, please increase aux buffer size; aux_size='1024' 2020-07-14T23:59:04+02:00 ds918blam syslog-ng[4727]: Configuration reload request received, reloading configuration; 2020-07-14T23:59:25+02:00 ds918blam syslog-ng[4727]: Configuration reload request received, reloading configuration; 2020-07-15T00:00:11+02:00 ds918blam syslog-ng: SYSTEM: Last message 'Configuration reload' repeated 1 times, suppressed by syslog-ng on ds918blam 2020-07-15T00:00:11+02:00 ds918blam syslog-ng[4727]: Configuration reload request received, reloading configuration; 2020-07-15T00:03:33+02:00 ds918blam syslog-ng[4727]: Configuration reload request received, reloading configuration; 2020-07-15T00:03:52+02:00 ds918blam syslog-ng[4727]: Configuration reload request received, reloading configuration; bizarre bizarre ...

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é.