bruno78

Bonjour, @oracle7, @Audio, @Pinpon_112, @PPJP je viens rajouter mon grain de sel 😃 pour la partie script Python : c'était un "nice to have" à la suite du Tuto d' @oracle7, afin d'avoir une automatisation complète. Mais on est bien d'accord, renouveler son certificat et ré-affecter les services à la main, 1 fois tout les 3 mois, ce n'est pas la mer à boire (et ça permet de revérifier périodiquement ses paramètres, et les mettre à jour si nécessaire) au delà du "nice to have", c'était un petit défi pour moi, en tant qu'amateur ...., et cela m'a permis / obligé à rentrer un peu plus en profondeur dans le Syno, ce qui est toujours intéressant. Au tout début, il y a eu débat Python 2.7 vs 3.x. J'avais commencé en 3.x, mais au final on s'est dit qu'il valait mieux le faire sans paquet supplémentaire à installer, et donc utiliser le Python 2.7 embarqué de base du Syno La conséquence, évidemment, @PPJP a raison, c'est l'obsolescence de cette version. Ceci dit, les fonctions utilisées sont basiques, donc au pire a priori on risque une évolution de syntaxe en passant en Python3. Donc soit je travaille dessus en dés à présent en Python3, soit on attend la sortie du DSM7 ..... et à mon avis ce ne sera pas le passage python2 vers python3 le plus grand défi ! Par ailleurs, je suis en train de faire une évolution du script actuel, pour y intégrer un log au niveau python lui-même (pas uniquement le log du script acme.sh). Cdt Bruno78

Bonjour, @Audio le fichier account.conf étant généré automatiquement, je ne m'explique pas l'absence de la ligne CERT_HOME='xxxx' ??? sur la deuxième erreur (nom de domaine erroné), on effectue les vérifications suivantes : # on verifie le repertoire ACMECERT (ACMECERT = /volume1/Certs/) # dans ACMECERT on verifie l'existance du repertoire domain # dans le repertoire ACMECERT/domain, on verifie la presence du fichier domain.conf # dans domain.conf, on verifie les lignes LE_DOMAIN=domain et LE_Alt=*.domain # Le_Domain='ndd.tld' # Le_Alt='*.ndd.tld' Ton fichier ne doit pas être correct ? Peux-tu faire ces vérifications à la main stp ? @Pinpon_112 les certificats sont indéxés par une valeur aléatoire, ici dans ton cas "dxIeo0". Tu retrouves cet index dans le répertoire /usr/syno/etc/certificate/_archive/dxIeo0 c'est là que se trouvent les fichiers *.pem cet index est utilisé dans les fichiers DEFAULT et INFO pour pointer sur le bon certificat. et oui, puisque ton certificat n'a pas atteint sa date d’émission + 60j, il est inutile de le renouveler. On conserve donc "l'ancien" certificat, tout à fait opérationnel. Cdt Bruno78 @Audio, comme le suggère @oracle7, je crains que ta création de certificat n'ait pas été aussi "nickel" qu'il n'y parait ..... Il n'est pas normal que les fichiers de référence ne soient pas populés correctement. Cdt Bruno78

@Audio, @oracle7, bonjour, curieux ... . peux-tu stp vérifier le fichier /usr/local/share/acme.sh/account.conf ? tu dois y trouver une ligne du style : CERT_HOME='/volume1/Certs' Cdt, Bruno78

@Audio, effectivement, j'ai supprimé le reverse proxy pour photo.ndd.tld ..... et les redirections semblent toujours fonctionnelles .... J'avoue ne pas être capable de l'expliquer .... Bruno78

Bonjour @Audio, c'était quoi exactement ton entrée dans le reverse Proxy ? as-tu configuré un DNS local (DNS server synology) ? je viens de refaire le test avec NAS : reverse proxy (https://photo.nd.tld => http://localhost) DNS Serveur local (CNAME photo.nd.tld => ns.nd.tld) (pour la resolution locale) redirection .htaccess pour acceder au repertoire ~/photo OVH DNS Zone : CNAME photo.nd.tld => nd.tld. depuis un accès internet externe et via VPN L2TP, je ne suis pas chez moi, et je n'ai aucun soucis. Je ne vois pas très bien comment cela peut fonctionner sans l'entrée reverse proxy ? Cdt Bruno78

Bonjour @.Shad., alors j'ai quand même un problème : j'ai donc voulu voir si je pouvais corriger le problème de lien sur l'icone "Photo Station" du bureau DSM, qui pointait toujours vers le DSM et me donnait une erreur (sorry the page you are looking for is not found) ..... et je m’aperçois, quelques heures plus tard, que le lien a changé et est parfaitement fonctionnel : il dirige bien vers le nouveau sous-domaine créé (photo.ndd.tld/photo/#!Albums) !! En fait non. Test fait trop vite. Et alors de quoi je me plains !!!??? n'ayant fait entre temps aucune modification, (sûr de moi à 99,99%) .... j'aimerai simplement comprendre ..... grand mystère ..... Bon, inutile de passer trop de temps là dessus, mais je suis intrigué ! L'icone PhotoStation sur le Bureau DSM ne pointe pas vers la bonne adresse, comme vu plus haut. Le problème reste entier. Bonne journée, Bruno78

Oui je suis assez d'accord sur le principe. Je vais essayer 2 3 trucs pour voir, .... Mais si tu n'y es pas arrivé .... Envoyé de mon STF-L09 en utilisant Tapatalk

En vérifiant, il reste un dernier problème : l'icone "Photo Station" sur le bureau DSM continue de pointer vers le sous domaine du DSM, et non pas le sous domaine "photo" que je viens de créer, et donc ce raccourci ne fonctionne pas. Il doit me manquer un dernier point ....

@.Shad., @oracle7, du coup, pour prendre en compte le répertoire ~/photo, mon .htaccess est comme suit : RewriteEngine On RewriteCond %{HTTPS} off RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] RewriteCond %{HTTP_HOST} ^photo.ndd.tld$ RewriteRule ^$ https://photo.ndd.tld/photo [L,R=301] Cdt Bruno78

Merci, c'est tout bon

Merci @.Shad., c'est exactement cela ! 👍. Et du coup, pour s'affranchir du "/photo", cela va se passer au niveau du .htaccess ? Merci

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