bruno78

bonjour @GrOoT64, de ce que je viens de regarder, sous DSM7, les packages sont gérés via "systemctl" : bruno@ds918blam:~$ systemctl status sshd ● sshd.service - OpenBSD Secure Shell server Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: disabled) Drop-In: /usr/lib/systemd/system/sshd.service.d └─synorelay-service-handler.conf Active: active (running) since Wed 2021-05-12 17:14:51 CEST; 2 days ago Main PID: 8225 (sshd) CGroup: /sshd.slice/sshd.service ├─ 4420 sleep 1 ├─ 4481 systemctl status sshd ├─ 8225 sshd: /usr/bin/sshd -D [listener] 0 of 10-100 startups ├─13125 sshd: bruno [priv] ├─13418 sshd: bruno [priv] ├─13419 sshd: bruno@pts/0 ├─13662 -sh ├─13732 sshd: bruno@notty ├─13733 sh -c while [ -d /proc/$PPID ]; do sleep 1;head -v -n 8 /proc/meminfo; head -v -n 2 /proc/stat /proc/version /proc/uptime /proc/loadavg /proc/sys/... └─13736 sshd: bruno@internal-sftp Mais si Synology a fait des utilitaires spécifiques, c'est qu'ils doivent bien faire quelque chose de plus ? Donc sous DSM7 il y a la commande Syno "synosystemctl" : bruno@ds918blam:~$ synosystemctl -h synosystemctl {COMMAND} ... Commands: start [--no-block] NAME... Start (activate) one or more units stop [--no-block] NAME... Stop (deactivate) one or more units enable NAME... Enable one or more unit files disable NAME... Disable one or more unit files restart [--no-block] NAME... Start or restart one or more units try-restart [--no-block] NAME... Restart one or more units if active reload [--no-block] NAME... Reload one or more units reload-or-restart [--no-block] NAME... Reload or restart one or more units reenable NAME... Reenable one or more unit files isolate [--no-block] NAME... Start one unit and stop all others mask [--runtime] NAME... Mask one or more units unmask [--runtime] NAME... Unmask one or more units uninstall NAME Remove units from system, as well as relating symlinks and flags daemon-reload Reload unit config get-default Get the name of the default target set-default NAME Set the default target get-enable-status NAME Get the enable status of given unit get-active-status NAME Get the active status of given unit get-load-status NAME Get the load status of given unit stop-service-by-reason REASON NAME... Stop one or more services by a reason start-service-by-reason REASON NAME... Start one or more services by a reason remove-service-reason REASON NAME... Remove reason for one or more services list-service-reason NAME List service reason get-unit-by-pid PID Get unit name that the pid belongs to list-service-by-mnt-path PATH List services using given mount path register-volume NAME VOLUME Register a volume for a unit package-register-volume NAME VOLUME Register a volume for a package unregister-volume NAME VOLUME Unregister a volume for a unit package-unregister-volume NAME VOLUME Unregister a volume for a package Donc dans ton cas 2 options a priori : via la commande native systemctl : systemctl restart sshd via la commande syno : synosystemctl restart sshd Cdt, bruno78 PS : et oui, le login root c'est toujours avec la clé ssh !

@RaZor83 merci pour ces évolutions. Si tu n'y vois pas d’inconvénient, elles seront intégrées (et te seront attribuées) dans ma prochaine édition du script (rien de planifié à ce jour). Cdt, Bruno78

Bonsoir, le script python pour le monitoring de la Freebox a été mis à jour, et est passé en version 061. Le Tuto a été mis à jour en première page. Je vous redonne le lien : https://github.com/bruno78310/Freebox-Revolution-Monitoring.git Les évolutions sont les suivantes : Prise en compte de l’agrégation de liens xdsl / lte-4g pour les Freebox Delta. Pour faire remonter ces compteurs, il faut invoquer le paramètre '-4' dans la liste des paramètres disponibles. Correction d'un bug lors de la demande de statistiques disques ('-D') sur une Freebox Mini4K qui n'a pas de disque. La demande faisait planter le script. Correction d'un bug lorsque l'état de la connexion est 'down' (paramètre 'state' lors de la requête sur la connexion) : dans ce cas, le script plantait. Désormais on positionne : media='None' ipv4='None' ipv6='None' ipv4_port_range=[0,0] Je remercie ici vivement @Galm et @Denisra76Frog qui m'ont prêté main forte pour valider cette évolution du script sur leur modèles respectifs de Fbox. Ainsi, le script est passé sur une Mini4K (fibre), une Delta (xdsl/4g) et une Révolution v2 (fibre). N'hésitez pas à me faire part de vos remarques. Cdt, bruno78

@adelac le problème n'est pas le transfert des données (des photos), mais de la base de données qui va avec : albums, regroupement visages, ... . Et comme Synology Photo ne propose pas (en espérant que ça vienne rapidement) de sauvegarde de l'application (donc de ses "réglages" ) .... . Le tout est de savoir si c'est acceptable de recréer à partir de zéro, ou si il faut transférer proprement l'environnement. J'ai commencé à regarder comment faire ce backup / restore de la base de données, mais je n'ai pas regardé comment discriminer selon tel ou tel utilisateur.

@Galm merci, je regarde à intégrer cela.

@Galm peux-tu m'indiquer les numéros de lignes, ou m'envoyer le fichier corrigé que j'intègre ces modifs dans la prochaine version ? Merci. (je vais sortir dans la semaine une version prenant en compte l’agrégation xdsl / lte, donc autant inclure ces maj.) @.Shad. oui c'est vrai que finalement, une fois passée la "surprise", ça fait sens.

@frlevel en minutes !!!! as-tu des logs Apache et MariaDB ? PArce que là, effectivement, ....

Bonjour @frlevel, quand tu parles de temps de réponses "anormalement longs", on parle de dizaines de ms, de dizaine de secondes ? Je suppose que c'est mesuré en local ? Je suppose qu'avec Drupal il y a une gestion de cache ? Je commencerai à regarder par là. Quelle est ta configuration DS920 ? Utilisation de la mémoire ? saturation ? swap ? cache SSD MVNE ? bruno78

@RaZor83 Ok, dans ce cas, ... je retire ma remarque .... . C'est juste un peu déroutant si on ne connait pas ta convention. Cdt, Bruno78

@RaZor83 bonsoir, bonne idée de publier tes dashboards. Si je peux juste me permettre un commentaire, d'après les screenshots, une petite correction des dashboards serait nécessaire pour éviter les débits négatifs .... 🙂

@Jeff777 désolé de mon ignorance, mais pour mon info à quoi sert la carte SD de la POP ? Sinon je viens de passer en 4.3.0 ... et tout est remonté nickel 🙂 Je vais allez voir l'aide sur la documentation de l'API

@Jeff777 bonjour, a priori, je ne vois pas de rapport entre le changement de firmware de la box et la "perte" du dashboard. Jusqu'à présent à chaque redémarrage de la box et chargement d'un nouveau firmware, je n'ai pas eu a refaire le dashboard. D'ailleurs il faut que je la redémarre pour prendre cette maj. Il y a un point qui m'interesse (outre les résolutions de bugs et autres), c'est l'annonce de la maj. de la documentation de l'API v8 dans l'aide ....

@.Shad. non non, c'est toujours sous forme de code ..... Après je n'ai peut-être pas le tout dernier grafana ... alors je suis en 7.5.2, et la plus recente est une 7.5.4 qui vient de sortir, mais je ne vois rien dans le change log qui suggère une telle évolution ....

@Galm @arnostress merci pour votre retour, c'est toujours bien de voir qu'un travail est utile. Juste pour info, je suis en train de finaliser, avec @Denisra76Frog , une petite evolution du script permettant de remonter les compteurs dans le cas d'aggregation xdsl / 4G sur le lien uplink. Les dashboards, ... il y en plein partout, à commencer par ici sur ce forum. Et d'autre part, je suis maintenant entièrement passé sous influx-V2, qui demande une syntaxe de dashboard sous grafana assez différente de la version influx-V1. Mes anciens dashboards V1 sont sauvegardés quelque part .... :-). Par contre, si quelqu'un se lance sur influx-V2, je pourrai donner un coup de main. Cdt, bruno78

@Juan luis je n'utilise de mon côté que HyperBackup (ça correspond à mon besoin). Le fait de sauvegarder ou pas des applis (et donc leurs données/paramétrages) ne dépend pas de la cible, mais du paquet lui-même. Certains paquets sont sauvegardables, .... d'autres non. Ma stratégie de backup est à présent la suivante avec HyperBackup (après être passé par une restauration complète qui fait bien flipper et qui instantanément met le doute sur ce que l'on a fait comme sauvegarde, jamais testée, ni jamais vraiment vérifié la complétude ou la cohérence) : j'ai 1 DD reservé aux backups dans le NAS => backup (données et appli) local en ligne des 3 autres DD toutes les 4 heures. Ce serait la source de restauration en première intention, locale donc rapide. je fais (à la main environ 1 fois par semaine, suivant les grosses évolutions ou pas ) un backup externe sur un DD USB, que je ne laisse pas en ligne. enfin je fais une fois par jour un backup en ligne externe (service Synology C2, pour les données les plus importantes) ..... en cas de scenario du pire localement .... Ces 3 backups, sur 3 supports distincts, sont faits avec HyperBackup, gèrent les versions, et permettent la sauvegardes des applis et leurs configurations ... pour celles qui y sont éligibles. Chacune de ces 3 taches est personnalisée en fonction de la capacité du support cible, mais aussi et surtout en fonction de la "valeur" des différentes données. A noter que je ne fais pas de "backup de backup" ! Chacune des 3 taches prend les données sources, initiales, comme source de la tache de backup. C'est vrai que rapidement il faut se poser 5 minutes, et faire le tour des scenarios : dd en panne, volume en panne, groupe de stockage en panne, NAS en panne, NAS détruit/volé.... . Dans chaque cas savoir et vérifier où se trouve la sauvegarde et comment je fais pour restaurer. Et pour être complet, se demander aussi comment je fais si l'un sur 3 des backups est KO/HS/inaccessible .... . Savoir si on est prêt à perdre 1 heure de boulot, 1 jour , 1 semaine ..... les dernières photos du weekend .....

@.Shad., @TuringFan je confirme !! pour avoir été confronté recemment à une restoration complète, la sauvegarde distante hors site (C2 dans mon cas) fonctionne parfaitement, .... mais les temps de restoration ne sont pas vraiment comparables avec une sauvegarde locale sur DD externe (même avec une connexion fibre) ! Je pense que les 2 sont nécessaires (en fonction de la "valeur" que l'on attribue à ses données évidemment) : sauvegarde locale sur DD externe, et sauvegarde hors site .... pour le scenario du pire !

@Jeff777 bonjour, oui c'est cela ...

@nebelnic bonjour, il serait tout de même bon de connaitre la cause de l’échec. Après, cela m'est déjà arrivé, ça peut planter un jour et passer le lendemain. Ce peut venir soit de LE, soit d'OVH, ..., des tempos ... Si tu recherches dans le log par exemple le mot clé "error", ca te dit quoi ? Pour sécuriser ton log, a minima, tu remplaces globalement ton domaine.tld par "ndd.tld", ça éliminera déjà pas mal de chose . Tu peux aussi envoyer ton log par MP. cdt, bruno78

Bonsoir, encore perdu les caches SSD (nouveaux jeux depuis le plantage précédent !!). Redémarrage du NAS au bouton (!) encore une fois. J’arrête les frais avec ces caches SSD. (modèles inclus dans la compatibility liste pourtant). Et par ailleurs, je suis revenu à 8GB de RAM avec mes barettes d'origine Syno. Je ne peux pas être plus conforme que cela aux spécifs Syno .... . Cette fois ci ils étaient montés en RO sans protection, chacun sur un volume différent. Les 2 ont planté en même temps. et les contenus ont été rincés (sans dommages puisque en Read Only). Je vais les sortir et les recycler ailleurs. Cdt, Bruno78 a priori les logs sont encore là, je vais voir si je trouve quelque chose ....

@.Shad. @oracle7 @MilesTEG1 @Jeff777, visiblement le problème speedtest apparu cette nuit est largement répandu. Une solution a été trouvée ici : https://github.com/sivel/speedtest-cli/pull/769/files Il faut donc inclure un nouveau script python "speedtest.py". Je vous propose donc une mise à jour de l'image "speedtest2". Vous trouverez dans le fichier joint 2 nouveaux fichiers : Dockerfile et speedtest.py . speedtest_fix.tar Placer ce fichier speedtest_fix.tar dans votre répertoire <speedtest>, Décompressez le (# tar xvf speedtest_fix.tar) puis relancer la procédure de création de l'image speedtest2 telle que décrite en page 22 de ce fil. Le nouveau Dockerfile va inclure dans l'image le fichier speedtest.py corrigé, et ensuite il ne doit plus y avoir de problème. Je ne relivre pas le fichier Influxdbspeedtest.py car il n'évolue pas. Testé rapidement chez moi ca semble OK, mais dites moi ce qu'il en est chez vous. bruno78

@.Shad. oui j'ai commencer à travailler avec cette image .... soit je ne l'ai pas configurée convenablement, soit elle me donne vraiment des résultats étranges .... du coup je tentais d'adapter l'image d'origine pour du influxv2. Il faut que je reprenne cette tache.

@oracle7 @Jeff777 bonjour, cela ressemble un un pb de mise à jour d'image speedtest que vous avez du subir en même temps ! Avez vous essayer de reconstruire l'image speedtest2 ? Je ne pourrai pas faire de tests avant ce soir .... bruno78

@oracle7 bonjour, de ce que je vois de ton log, le test de connectivité à influxdb est successful : Or il s'agit là de la seule modification que j'ai faite pour cette nouvelle image. L'erreur semble plutôt venir du module speedtest.py : Il faudrait aller voir ce qu'il y a en ligne 1174 de speedtest.py. Mon container speedtest n'est pas en service actuellement, je suis en train de l'adapter pour Influxdb-V2 (c'est pas gagné !). Je vais voir si je peux relancer temporairement avec influxdb-V1. Cdt, bruno78

@Spudboy, le seul conseil que je pourrais donner, c'est de mettre à jour globalement vers la dernière version DSM 6.2.4-25556-1 si je ne me trompe pas et de vérifier le comportement. Pas de comportement bizarre pour d'autres paquets Syno ? Pas de configuration "baroque" ou trop personnalisée ? Si le problème persiste (et semble systématique), faire appel à l'assistance Syno qui demandera surement à pouvoir prendre la main sur la machine.

@Spudboy heu .. non ça n'arrive pas a priori . Tu peux en dire un peu plus sur le contexte : quelle mise à jour ? de quoi ? comment ? Quels messages dans le journal après le reboot ? .... Quelle version de DSM ?