bruno78

@.Shad. OK je regarde ce que je peux faire de plus.

@.Shad., bonjour, tu as raison, il s'agit bien de l'interface virtuelle du sous réseau macvlan, et pas du Pihole lui-même. aucun changement en autorisant les ports L2TP uniquement sur l'interface eth0 (les interfaces disponibles dans le pare-feu sont global, LAN1, LAN2, PPPoE, VPN) Par contre, j'ai remarqué que dans l'interface de gestion du serveur VPN, onglet "Paramètres Généraux", le champ Interface Réseau est vide, et il est impossible d'y rentrer une quelconque valeur. Mais je ne suis pas sûr de ce qi devrait y figurer ?? bruno78

Bonjour, j'ai un problème sur lequel je butte depuis plusieurs jours ... Pour des raisons qui n'ont rien à voir avec le VPN, j'ai du entièrement ré-initialiser mon NAS. En ce qui concerne le VPN, redémarrage sans problème du serveur Openvpn. Par contre, impossible d'établir une connexion L2TP, quelle que soit l'origine (Win10, Android, Ubuntu ....). Après de multiples traces infructueuses, je finis par aller voir le log /var/log/auth.log. ... Et là ... Ça part plutôt bien : Ensuite ça se gâte ... (mais je ne sais pas si 'est normal ou pas .... mais je n'aime pas les ERROR ... Ça poursuit quand même : a priori tout va bien Et ça termine en apothéose : => il attribue les ports 500 et 4500 à l'interface macvlan utilisée pour le docker PiHole !!! ???? Ce qui est confirmé par un netstat : Et donc si pour le test je mets disable le link "bridgemacvlan", du coup il me dit qu'il n'y a plus d'interface publique : A ce stade, j'ai épuisé les idées .... et si ça se trouve l'erreur doit être grosse comme une maison, .... mais je ne vois pas .... Merci de votre aide. bruno78

Hello, @MilesTEG1 ça ne serait pas par hasard mon post du 10/février en page 29 ?? Bruno78 PS : dsl je ne suis pas très assidu, mais outre le taff, je suis toujours en train de restaurer mon DS918 après son dernier crash et la perte complète du volume1. Je me rends compte que mes sauvegardes n'était pas si parfaites que cela, loin de là. Même si au final je ne perds pas de données (ça reste encore à prouver), la remise en route est longue et fastidieuse. Je ferai à l'occasion (après) une petite synthèse là dessus, ça peut être utile.

@MilesTEG1 bonjour, j'avais donné, en page 22 de ce fil dans un post du 7/janvier une méthode pour ne pas avoir à utiliser un user admin pour la db ... parce que oui, sinon, avec cette image par defaut pour tester la connexion à la bdd il utilise un compte admin. J'avais modifié le script Python pour éviter cela, mais cela demande une modification de l'image speedtest. Cdt, bruno78

Oui, je pense que je vais un peu séparer les variables. Je viens de re-installer DSM7 (partition système). Il voit toujours le volume1 manquant. Dois-le supprimer et le recréer avant de lancer la restauration HyperBackup ?

@maxou56 bonjour, et si on pousse encore plus loin, avec 2 SSD MVNe, je pense qu'on doit pouvoir faire du cache SSD en lecture seule pour chacun des 2 volumes ? 1 SSD par volume, qu'ils soient ou non dans le même groupe de stockage ?

@.Shad., ça va finir comme ça ! Je ne suis pas sûr de les remettre en service en tant que cache SSD. Dommage. Je vais attaquer la re-installation, puis la restauration des données. Moi qui me disait "faudra quand même faire un test de restauration un de ces jours .... ", => test en grandeur réelle. Si je devais perdre toutes mes photos, je sens que ça ne me mettrait pas de bonne humeur, mais a priori toutes les précautions ont été prises, donc ... on croise les doigts. Après, ça fait réfléchir sur le fait de tout faire sur le même NAS : stockage, serveur web, serveur multimédia .... . Ce n'est pas forcement la bonne stratégie.

Bonjour, ça ne sent vraiment pas bon pour le volume1. Autant volume2 est là (il n'avait pas de cache ssd !), autant volume1 ..... root@ds918blam:~# df -h Filesystem Size Used Avail Use% Mounted on /dev/md0 2.3G 1.9G 276M 88% / devtmpfs 3.9G 0 3.9G 0% /dev tmpfs 3.9G 100K 3.9G 1% /dev/shm tmpfs 3.9G 15M 3.8G 1% /run tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup tmpfs 3.9G 1.7M 3.9G 1% /tmp tmpfs 781M 0 781M 0% /run/user/196791 /dev/mapper/cachedev_0 5.3T 495G 4.8T 10% /volume2 root@ds918blam:~# cd /volume1 root@ds918blam:/volume1# ls @eaDir root@ds918blam:/volume1# du 8 ./@eaDir/video2 8 ./@eaDir/FreeFileSync 8 ./@eaDir/Drive_Alain_ActiveBackup 8 ./@eaDir/homes 8 ./@eaDir/Share 8 ./@eaDir/web 8 ./@eaDir/file_history 8 ./@eaDir/Equipe 8 ./@eaDir/photo 8 ./@eaDir/web_packages 8 ./@eaDir/video 8 ./@eaDir/ActiveBackupforBusiness 8 ./@eaDir/music 8 ./@eaDir/NetBackup 8 ./@eaDir/docker 8 ./@eaDir/MailPlus 132 ./@eaDir 136 . root@ds918blam:/volume1# du -sh 136K . root@ds918blam:/volume1# du -sh @eaDir/homes 8.0K @eaDir/homes root@ds918blam:/volume1# Sauf idée géniale de dernière minute, j'attaque la ré-installation de DSM puis lance une restauration de ma dernière sauvegarde (Syno C2) de volume1. Pas beaucoup de risque puisque les données ne semblent plus être accessibles ....

Super ! cette fois, je suis dans la mouise !! Au redémarrage forcé, Il a perdu le volume 1 : Et je ne vois pas ce que je peux faire. Je ne peux même pas supprimer le cache SSD ... Demain il fera jour ! (PS : et à la question : as tu des sauvegardes, la réponse est oui .... au moins de l'essentiel !! )

Bonsoir, finalement pas si terminé que je ne le pensais !! En 8 jours, 2 plantages, avec toujours les caches SSD impliqués de près ou de loin. dans l'avant dernier plantage, il y a 8 jours, les SSD NVME étaient toujours physiquement dans la machine, mais le cache SSD désactivé. => plantage pour le dernier plantage, ce soir, avec de nouveaux SSD NVME (WD au lieu de Samsung, 500GB au lieu de 250GB), pareil, replantage de la machine qui reste dans un état très bizarre. Certains services fonctionnent, pas d'autres. Mais à chaque fois les SSD Cache disparaissent du monitoring. Du coup au niveau piste d'investigation, il ne me reste que la carte mère qui pourrait avoir des vapeurs au niveau de ses ports NVME ?? ou alors (je sais qu'on en a déjà parlé) un pb avec les 16GB de RAM ???? Ce dernier point est facile à gérer, j'ai toujours mes 2 barrettes de 4GB d'origine. Je vais les remettre en place momentanément (ce qui sera aussi plus facile lors des contacts avec le support Syno). Après je me dis qu'une ré-installation complète de DSM pourrait aussi être salutaire ? (3 plantages rapprochés avec des effets de bord bizarres même si apparemment pas de perte de données perso ....). D'ailleurs, comment faire une installation de DSM 7 Beta propre ?? Repasser par DSM6 puis upgrade ? ou alors peut’ on installer l'image DSM7 directement ? Arrrrggggg !!!! Cdt, Bruno78

@niklos0 bonjour, la dernière analyse (Nov/2020) que j'avais lancée donne les résultats suivants : ce sont en très grandes majorité de petits fichiers.

Bonjour , expérience personnelle : je n'ai pas fait de vrai tests comparatifs chiffrés je suis en environnement mono utilisateur / perso mais : HyperBackup : (à volume de données à sauvegarder équivalent) sans cache SSD : backup vers C2 = env. 30 min avec cache SSD : backup vers C2 = env. 11 min WordPress : 4 installations WordPress (natives) avec le plugin WordFence. sans cache SSD : echec des Scan périodiques en timeout au bout de 3 heures (on peut rallonger la tempo, mais est-ce bien raisonnable ?) avec des taux d'utilisation des disques autour de 80%, avec ralentissement général du NAS. avec cache SSD : les scan périodiques sont exécutés en environ 20 à 40 minutes, sans impact sur la réactivité générale pendant ce temps. fluidité légèrement accrue de la réactivité de l'interface graphique Meilleure réactivité des dockers et VM (je n'ai pas d'éléments chiffrés) Cependant : fonctionnement sans problème pendant 12 mois et depuis 4 mois j'ai accumulé plusieurs problèmes de crash du NAS vraisemblablement dus à une défaillance matérielle de mes SSD NVME (2 * Samsung 970 EVO+ 250GB). Je les ai remplacés cette semaine par des WD Black 500GB. Je n'ai pas assez de recul pour me prononcer sur la fiabilité.

Bonjour, est-ce que tu as ce genre de notifications : "Système : Certaines pages Web ne peuvent plus fonctionner correctement" ??

@Jeff777 pour le PI, tu peux déjà prendre ça dans les input plugins ############################################################################### # INPUT PLUGINS # ############################################################################### # Read metrics about cpu usage [[inputs.cpu]] ## Whether to report per-cpu stats or not percpu = true ## Whether to report total system cpu stats or not totalcpu = true ## If true, collect raw CPU time metrics. collect_cpu_time = false ## If true, compute and report the sum of all non-idle CPU states. report_active = false # Read metrics about disk usage by mount point [[inputs.disk]] ## By default stats will be gathered for all mount points. ## Set mount_points will restrict the stats to only the specified mount points. # mount_points = ["/"] ## Ignore mount points by filesystem type. # ignore_fs = ["tmpfs", "devtmpfs", "devfs", "iso9660", "overlay", "aufs", "squashfs"] # Read metrics about disk IO by device [[inputs.diskio]] ## By default, telegraf will gather stats for all devices including ## disk partitions. ## Setting devices will restrict the stats to the specified devices. # devices = ["sda", "sdb", "vd*"] ## Uncomment the following line if you need disk serial numbers. # skip_serial_number = false # ## On systems which support it, device metadata can be added in the form of ## tags. ## Currently only Linux is supported via udev properties. You can view ## available properties for a device by running: ## 'udevadm info -q property -n /dev/sda' ## Note: Most, but not all, udev properties can be accessed this way. Properties ## that are currently inaccessible include DEVTYPE, DEVNAME, and DEVPATH. # device_tags = ["ID_FS_TYPE", "ID_FS_USAGE"] # ## Using the same metadata source as device_tags, you can also customize the ## name of the device via templates. ## The 'name_templates' parameter is a list of templates to try and apply to ## the device. The template may contain variables in the form of '$PROPERTY' or ## '${PROPERTY}'. The first template which does not contain any variables not ## present for the device is used as the device name tag. ## The typical use case is for LVM volumes, to get the VG/LV name instead of ## the near-meaningless DM-0 name. # name_templates = ["$ID_FS_LABEL","$DM_VG_NAME/$DM_LV_NAME"] # Get kernel statistics from /proc/stat [[inputs.kernel]] # no configuration # Read metrics about memory usage [[inputs.mem]] # no configuration # Get the number of processes and group them by status [[inputs.processes]] # no configuration # Read metrics about swap memory usage [[inputs.swap]] # no configuration # Read metrics about system load & uptime [[inputs.system]] ## Uncomment to remove deprecated metrics. # fielddrop = ["uptime_format"]

@Jeff777 pour Portainer, je ne pratique pas, donc attendre l'avis de @.Shad. pour se connecter sur influxdb : (remplacer les user/mot de passe par les bons !!) se connecter sur le container : docker exec -it influxdb /bin/bash se logger sur influxdb : influxdb -username <admin> -password <"admin"> lister les databases : > show databases se connecter sur une database particulière : > use <database_name> lister les "measurements" présents : > show measurements puis tu peux lister une table : > select * from <measurement_name> root@influxdb:/# influx -username admin -password "admin" Connected to http://localhost:8086 version 1.8.4 InfluxDB shell version: 1.8.4 > show databases name: databases name ---- nas_telegraf_vps _internal pi_telegraf ovh_vps_telegraf fbx_telegraf_v8 sl_stats nas_telegraf sl_ip_stats nas_speedtest pi4_telegraf > use pi4_telegraf Using database pi4_telegraf > show measurements name: measurements name ---- cpu disk diskio docker docker_container_blkio docker_container_cpu docker_container_health docker_container_mem docker_container_net docker_container_status ifTable ipNetToMediaTable kernel mem net processes rpi4B_model rpi4B_temp snmp.rpi4 storageTable swap system tcpConnTable > et pour finir tu peux lister par exemple un measurement : > select * from <measurement_name> .... mais ca peut être volumineux ...

@Jeff777, As-tu essayé de te connecter sur le docker influxdb et vérifié ce qui est populé dans la base "raspi_telegraf" ? On voit à la fois des données telegraf arriver (semble t'il) , et des requetes Grafana. Donc en toute logique ..... Soit la requete grafana n'est pas bonne, soit les données ne sont pas celles attendues => d'où l'idée de vérifier sur influxdb ce qui est réellement enregistré dans la db. Tous mes docker telegraf, influxdb, grafana sont en mode bridge, sans pb, certains colocalisés sur la meme machine, d'autres distants .

@Jeff777 bonjour, pour le log du container telegraf du RPi, as-tu positionné les variables correspondantes dans le fichier de configuration de telegraf ? ## Log at debug level. debug = true ## Log only error level messages. quiet = false ## Log target controls the destination for logs and can be one of "file", ## "stderr" or, on Windows, "eventlog". When set to "file", the output file ## is determined by the "logfile" setting. logtarget = "file" ## Name of the file to be logged to when using the "file" logtarget. If set to ## the empty string then logs are written to stderr. logfile = ""

@Jeff777 alors voilà : sous DSM7, pas de "synoservicecfg" ensuite, je me suis aperçu qu'à chaque tentative de réparation, il me sortait également une alarme "certaines pages web ne peuvent pas fonctionner" (alors que les sites hebergés fonctionnent) du coup je me suis dit qu'il y avait peut-être un lien entre AudioStation et Web Station ???? donc arrêt propre de WebStation (incl. Apache 2.2 et Apache 2.4) re-installation de AudioStation depuis centre de paquets DSM => OK redémarrage WebStation , Apache 2.2 et Apache 2.4. et cela semble fonctionner correctement, aussi bien l'appli Desktop que via DSAudio Android. J'avoue que je ne m'explique pas le lien entre les 2 ...

@EVOTk, @Jeff777, même ainsi, ça ne passe pas ..... root@ds918blam:/var/packages/AudioStation# synopkg install AudioStation-x86_64-7.0.0-5058.spk {"error":{"code":0},"results":[{"action":"install","beta":true,"betaIncoming":true,"error":{"code":276,"description":"failed to acquire postinst worker","worker_msg":[]},"finished":true,"installReboot":false,"installing":true,"language":"enu","last_stage":"postreplace","package":"AudioStation","packageName":"Audio Station","pid":22602,"scripts":[{"code":0,"message":"","type":"preinst"},{"code":0,"message":"","type":"postinst"}],"spk":"AudioStation-x86_64-7.0.0-5058.spk","stage":"install_failed","status":"stop","success":false,"username":""}],"success":false}

@EVOTk @Jeff777, merci pour vos retours, je m'en occupe dans la journée. Cdt, bruno78

bonjour @Jeff777, peux-tu stp m'expliquer la marche à suivre pour installer manuellement en ssh un paquet qui refuse la réparation ? (Audio Station en l’occurrence) ? Merci d'avance

@Einsteinium j'ai relancé la commande de déploiement à la main ("docker exec Acme sh -c "acme.sh --deploy -d 'mydomain.com' --deploy-hook synology_dsm"") est tout est rentré dans l'ordre. Peut-être (c'est même probable) ne l'avais-je pas exécutée lors de la mise en place initiale comme indiqué (point 3.B.3 du Tuto) ... cdt, Bruno78

@Einsteinium, Il n'est pas exclu que je sois sur la version n-1 du Tuto ... Je regarde . Bruno78

@oracle7 bonjour, oui mais j'avais cru comprendre que c'était réglé .... . Bruno78