.Shad.
-
Compteur de contenus
6679 -
Inscription
-
Dernière visite
-
Jours gagnés
156
Tout ce qui a été posté par .Shad.
-
Ok je pense voir le problème pour docker-compose, l'installation a été faite pour l'utilisateur, pas le système. Donc tu tapes : pip3 uninstall docker-compose Je pense que tu avais oublié le "sudo" devant quand tu l'as installé. Ca n'explique pas les problèmes liés à Docker par contre. Donc je t'invite à tout désinstaller (suivre les liens données plus avant, modulo la commande sans le sudo au-dessus). Puis tu réinstalles tout en étant connecté avec pi, pas avec root. Toutes les commandes sont précédées de sudo. Logiquement ça devrait te permettre de repartir sur une base saine.
-
Ouh le vilain ! Bienvenue 😉
-
Ça : Ton Rpi veut absolument être en mode swarm. Ce n'est pas normal.
-
En quoi c'est normal ? Tu as dit : Si le proxy inversé est sur le NAS1, drive aussi bien que video.alexisg.com doivent pointer sur le proxy inversé. Là tu sollicites le port 443 du NAS2, y a rien dessus donc il te renvoie le port DSM du protocole demandé, ici HTTPS... On s'en balance du certificat sur NAS2 sauf pour les services non proxiables du NAS2 comme le transfert de données Drive sur le port 6690, Active Backup for Business, etc...
-
Que donnent : nslookup video.alexisg.com IP_locale_NAS nslookup drive.alexisg.com IP_locale_NAS
-
Je ne vois pas ce qui peut clocher honnêtement, à la limite ce que tu peux essayer de faire : - désinstaller docker-compose sudo pip uninstall docker-compose - désinstaller complètement Docker : https://docs.docker.com/engine/install/debian/#uninstall-docker-engine - réinstaller via : https://docs.docker.com/engine/install/debian/#install-using-the-convenience-script Et si vraiment ça ne marche toujours pas, tu peux toujours générer le fichier sur ton NAS et l'envoyer sur ton Raspberry Pi.
-
Tu peux taper : journalctl -u docker.service Et poster les logs ici.
-
Essaie avec pi peut-être oui, je suis jamais en root sur mon Rpi perso.
-
Chez moi : cd /opt/containers/telegraf docker run --rm telegraf telegraf config | sudo tee telegraf.conf La configuration s'affiche à l'écran (pour ça que je n'ai pas mis les impressions d'écran, ça dégage toutes les anciennes commandes). Si je fais un : ls -l EDIT : Tu as supprimé le dossier avant de retester ?
-
On va mettre de côté pour l'instant le problème de Portainer agent, tu as forcément des logs dans Telegraf, regarde dans le fichier telegraf.conf du Rpi, dans la première partie, avant InfluxDB, tu as une ligne : # debug = false Tu décommentes et tu passes la valeur à true : debug = true Tu redémarres le conteneur, puis tu tapes : docker logs telegraf -f
-
Ca a l'air bon de ce côté-là, pour moi le plus important ce sont les logs de Telegraf sur le Rpi, il précise généralement pourquoi il n'arrive pas à envoyer les données.
-
@Jeff777 Pour Portainer voir ma réponse juste avant la tienne. Pour l'url de InfluxDB, est-ce que tu as bien translaté le port 8086 sur le NAS depuis le conteneur : ports: - 8086:8086 dans la description du service InfluxDB dans le fichier docker-compose ?
-
C'est une erreur qui s'est glissée dans la refonte, c'est bien : networks: monitoring: external: true et pas : networks: external: name: monitoring J'ai aussi corrigé une erreur dans le docker-compose de Grafana, pour lequel j'avais oublié d'ajouter : networks: - monitoring Fallait bien que quelqu'un me debug tout ça @Lestat69, c'est tombé sur toi. 😄 ✌️ @Jeff777 : Tu peux renommer le endpoint que tu as créé, tu cliques sur "docker-swarm" et tu changes le nom pour ce que tu veux tout simplement. Ensuite quand tu cliques sur "Home" dans le menu latéral tout en haut, normalement tu as la liste de tes endpoints :
-
Oui et non, en fait j'ai déjà eu le cas où une indexation restait bloquée, et le fait de relancer la machine résolvait le problème. Dans les faits il aurait peut-être suffi de relancer le service d'indexation, mais il y a parfois des services secondaires qui sont impliqués. Bref tant mieux si tu as résolu ton problème.✌️ -
Regarde ce qu'il y a dans /var/log/messages, tu y trouveras peut-être des informations plus concrètes. Piste à 2 balles : As-tu réessayé de relancer le NAS ?
-
Bienvenue parmi nous. 🙂
-
A partir du moment où le périphérique sur lequel tu visualises tes vidéos peut lire nativement tes vidéos 4K UHD (ça peut être ta TV Samsung, ou une android box reliée en HDMI à ta TV) la seule chose qui va jouer ce sont les débits sur ton réseau local. Un DS215j est compatible Gigabit, et même s'il ne l'était pas tout à fait, ce serait amplement suffisant pour ton utilisation (je crois qu'on monte au max à 80 Mbps sur les grosses vidéos 4K UHD, pour une bande passante de 1 Gbps = 1000 Mbps). Est-ce que tu rencontres des ralentissements en l'état ? Tu ne parles pas d'éventuels ralentissements ou saccades à la lecture, et si cela arrivait ce serait probablement la TV qu'il faudrait mettre en cause plus que ton NAS. 🙂
-
Welcome !
-
Bon rétablissement 🙂
-
Bienvenue dans la communauté. 😉
-
Bienvenue parmi nous 🙂
-
Pas mieux que @Einsteinium, ou alors adresse-toi au support directement, mais je doute qu'ils souhaitent t'aiguiller, ça sort clairement du scope de l'utilisation prévue de DSM.
-
Problème redémarrage incorrect après un reboot
.Shad. a répondu à un(e) sujet de Alindil dans Vos commentaires et suggestions
Salut, La prochaine fois que tu as un redémarrage incorrect, peux-tu te connecter en SSH en root et taper la commande : dmesg -T Et tu mets des copies d'écran de ce qui se produit au moment du reboot intempestif ou simplement ce qui est dit au redémarrage. S'il y a un problème hardware on le verra sûrement ici. -
Ce qu'a dit @bruno78 ainsi que les logs de Telegraf du Raspberry Pi (moi j'ai mis un Portainer agent sur les deux que j'ai pour faciliter leur gestion, et la lecture de logs est pratique) et les logs d'InfluxDB, Grafana n'a pas vraiment d'importance, je doute que le problème vienne de là.
-
Si, c'est mieux effectivement, par contre attention si tu changes de box ou de routeur et que le sous-réseau est différent.