oracle7

@Jeff777 Bonjour, Oui, c'est bien ce que je fais lorsque je modifie un fichier docker-compose.yml. Cordialement oracle7😧

@Jeff777 Bonjour, Tu me mets finalement un doute. J'ai effectivement relancé les conteneurs lors de la premières utilisation de Watchtower, mais depuis, suite à différents autres essais j'ai supprimé puis réinstallé Watchtower plusieurs fois. J'aurais dû alors relancer aussi à chaque fois les autres conteneurs (on est d'accord : relancé = arrêt puis redémarrage et pas arrêt, suppression et réinstallation) ? Je commence à y perdre mon latin dans tout cela ...😧 Cordialement oracle7😉

@.Shad. Bonjour, Je souhaite monitorer mes caméras vidéo HIKvision. J'ai donc trouvé les fichiers MIB qui vont bien (enfin j'espère) et je me demandais si on peux les mettre directement dans le répertoire "/usr/share/snmp/mibs/". Mais dans ce cas, je crains qu'ils ne soient effacés de ce répertoire lors d'une mise à jour de DSM ? J'ai bon ? O/N Sinon peut-on les mettre ailleurs (du style dans "/volume1/docker/MIBs") et dans ce cas comment vont-ils être pris en compte ? Il faut rajouter un lien symbolique dans "/usr/share/snmp/mibs/" sur le NAS vers "/volume1/docker/MIBs" pour chacun de ces fichiers (il y en a en fait deux) ? OU Tout simplement dans le fichier "docker-compose.yml" pour le service "telegraf" on rajoute une ligne à "volumes:" du style " - "/volume1/docker/MIBs:/usr/share/snmp/mibs:ro" " ? Mais dans ce cas comme on a déjà une ligne " - "/usr/share/snmp/mibs:/usr/share/snmp/mibs:ro" " pour monter les MIBs Synology, cela ne va pas poser de problèmes de monter deux répertoires différents dans un même répertoire du conteneur ? Merci de vos réponses avisés. PS : En plus d'ajouter les fichiers MIBs, bien évidemment, le fichier "telegraf.conf" est aussi modifié en conséquences pour collecter les données des caméras. EDIT : Je viens de tester la solution d'ajouter une ligne du style " - "/volume1/docker/MIBs:/usr/share/snmp/mibs:ro" " dans le fichier "docker-compose.yml" pour le service "telegraf". Ce n'est pas bon du tout : je récupère un message (un peu prévisible d'ailleurs) : ERROR: Duplicate mount points: [/usr/share/snmp/mibs:/usr/share/snmp/mibs:ro, /volume1/docker/MIBs:/usr/share/snmp/mibs:ro] J'en reviens donc à ma première question ci-avant. Cordialement oracle7😉

@Jeff777 Bonjour, Oui et Oui aux deux questions. Je me demande si je vais pas mettre finalement tous mes conteneurs dans le même réseau (celui de monitoring). Puisque que c'est un réseau local, il n'est pas vu de l'extérieur, non ? Alors quel est le risque ? Ce serait quand Watchtower se connecte à l'extérieur pour aller chercher les mises à jours d'images ? J'avoue que je m'y perds un peu (même beaucoup !)... Ton avis STP ? Cordialement oracle7😉

@.Shad. Bonjour, Sans surprise, l'usage du port 465 ne fonctionne pas malgré que la connexion soit encryptée, c'est le serveur d'autorisation d'orange qui refuse alors la connexion : J'ai donc rétabli le port 587 (qui est celui que j'utilise couramment avec ma boite mail avec un encryptage réglé sur automatique) et je retrouve ce message : Ce qui me laisserait pensé qu'il manque un paramètre lié à l'encryptage de la connexion, dans les variables d'environnement liées aux notifications. J'ai pourtant regardé la doc de Watchtower mais rien vu (ou bien je suis aveugle ...). J'ai aussi essayé en ajoutant la variable d'environnement "WATCHTOWER_NOTIFICATION_EMAIL_SERVER_TLS_SKIP_VERIFY" mais toujours pareil "Failed to send notification email: unencrypted connection". Donc si tu a une idée, car là je ne comprends pas, il semblerait que @Jeff777 ai aussi ce problème. EDIT : Watchtower semble ne "scanner" que les conteneurs situés sur le réseau bridge par défaut 172.17.0.0. Il ne semble pas "scanner" mon réseau spécifique 172.20.0.0 dédié au monitoring. J'ai compris qu'il doit y avoir une certaine "étanchéité" entre les conteneurs dans docker, mais comment fait alors watchtower pour atteindre tous les autres conteneurs à vérifier car manifestement il ne "scanne" que son réseau ? Là non plus je ne comprends pas ... Cordialement oracle7😉

@Atarax500mg Bonjour, Il me semble (je te dis cela sous réserves et je peux me tromper) que le système NFS utilise (tout comme SAMBA) des bails temporels pour gérer ses connexions. Du coup, cela pourrait expliquer de le widget "Utilisateurs connectés" voille toujours l'adresse IP de mon ordi connecté en NFS et ce jusqu'à l'expiration du dit bail. Sinon ici un petit mémo pour mieux comprendre le partage NFS. Cordialement oracle7😉

@McBernic Bonjour, Pour re situer les choses, si j'ai bien compris : Depuis l'extérieur avec un PC pas de de soucis En local, en Wifi depuis le Smartphone avec DSCam : pas de soucis. Depuis l'extérieur, en 4G depuis le Smartphone avec DSCam : çà rame. J'ai bon ? O/N Un truc à vérifier dans Surveillance Station car peut-être que tu utilises une résolution trop grande qui en fait "sature" la transmission du flux vidéo. Sur les petits écrans tel que ceux d'un smartphone la plus faible résolution est préférable pour limiter le volume de données vidéo à lui transmettre. Aussi essaies si tu veux bien, cette piste : dans SS, règles le profil de diffusion 2 de la caméra sur la résolution la plus faible soit 640x480 avec FPS = 10 images/s, bitrate variable et qualité = 5. Cordialement oracle7😉

@.Shad. Bonjour, Eh bien non, j'utilise aussi le port 587 du serveur smtp d'orange. Je vais faire un test avec le port 465 pour voir, vu que le message parle de unencrypted connection ... Cordialement oracle7😉

@.Shad. Bonjour, J'avais déjà cette variable de positionnée et voilà ci-dessous le log : Je constate que cela semble avoir marché aujourd'hui pour les images watchtower, calibre-web et calibre mais pas pour influxdb ni grafana qui ne sont même pas cités alors que dans mon fichier docker-compose.yml du monitoring j'ai bien la même instruction pour chaque conteneur à savoir : Par ailleurs, je ne comprends pas les erreurs surlignées car je n'ai pas de ligne dans mon docker-compose.yml : volumes: - ./config.json:/root/.docker/config.json Pour le problème de notifications emails j'ai juste renseigné avec mes infos personnelles les champ de notification que tu avais fourni plus haut dans une de tes réponses en page 1. Il manquerai quelque chose à ce niveau ? Cordialement oracle7😉

@.Shad. Bonjour, J'ai utilisé la méthode "CRON" avec cette variable d'environnement : "- WATCHTOWER_SCHEDULE=0 30 1 * * *". Sachant que le paramétrage du cron se fait maintenant sur 6 données (voir ici) et non plus 5 comme "avant". Cordialement oracle7😉

@.Shad. Bonjour, J'ai donc installé sur tes conseils le conteneur "watchtower" mais après plusieurs jours de fonctionnement, je n'ai pas l'impression qu'il mette à jour les autres conteneurs/images comme prévu par essence. Par exemple, pour influxdb je suis en v1.8.2 alors que sur le site dockerhub la latest est la v1.8.3. Idem pour grafana j'ai la v7.1.5 et la latest est la v7.2.1. Du coup, d'après toi est normal O/N ? ou bien c'est parce que les évolutions de versions ne sont pas assez "importantes" vu de watchtower ? Je pensais qu'il mettait à jour à chaque publication de "nouvelle" latest, non ? Cordialement oracle7😉

@MilesTEG1 Bonjour, Pour info, on fichier docker-compose.yml comporte aussi les champs "ports" et je n'ai jamais eu aucun problème. Sinon, je ne saurais l'expliquer mais pour la version j'utilise sur les conseils de @.Shad. la version "2.1" et là aussi aucun problème. C'est pas grand chose mais cela peut t'aider ? Cordialement oracle7😉

@McBernic Bonjour, Sans garantie, mais essaies de désinstaller et réinstaller DSCam sur ton smartphone. Cordialement oracle7😉

@TuringFan Bonjour, Content pour toi que tu ais réussi à obtenir ton certificat par cette méthode. Si tu regardes bien le messages, tu verras que "acme.sh" s'y reprend à plusieurs fois pour finalement télécharger le fichier "master.tar.gz". Donc c'est bon, pas d'inquiétude à avoir. Pas à ma connaissance. Pour le routeur il faut copier les fichiers "ndd.tld.key", "ndd.tld.cer" et "ca.cer" depuis le répertoire "Volume1/Certs/ndd.tld/" pour ensuite les importer sur le routeur. A l'heure actuelle on n'a pas le choix de procéder autrement. EDIT : Pour le DID, cela peut venir du fait que tu ais nettoyé les cookies de ton navigateur en effaçant les données de sites. Cordialement oracle7😉

@seb46 Bonjour, Ton pare-feu est bien réglè comme cela. Si tu souhaites ajouter une règle pour les ports 80 et 443 (utiles pour pouvoir assurer la création et le renouvellement d'un certificat Let'sEncrypt) alors il faut te faut mettre "Tous" pour l'@IP source. Le cas affiché dans le TUTO de @Fenrir est spécifique à un besoin particulier de pouvoir communiquer en HTTP et/ou HTTPS avec un serveur particulier (192.0.2.3). C'est tout. Cordialement oracle7😉

@N.A.S. Bonjour, Si tu as créer à la main le dossier "docker" dans "volume1", eh bien il ne fallait pas ! Le dossier "docker" est et doit être créé automatiquement lors de l'installation du package "Docker" (voir ce TUTO). Ensuite seulement, tu crées à la main via une session SSH en tant que root, un dossier "calibre-web" dans le dossier "docker". Puis tu installes le conteneur "calibre-web" en suivant le TUTO que je t'ai indiqué précédemment (lis bien toutes les pages de ce post). C'est pas plus compliqué que cela ... Cordialement oracle7😉

@N.A.S. Bonjour, Suis ce TUTO, çà marche Nickel. Cordialement oracle7😉

@seb46 Bonjour, Sans trop m'avancer (mais je peux me tromper), ta connexion WIndows ne risque pas de marcher, vu que ton interface réseau Ethernet n'est connectée à rien. L'affichage est pourtant clair "Câble réseau non connecté" ! 😧 Indirectement, c'est indirectement la cause de ton message "toutes les cartes réseaux sont occupées" car en fait, aucune n'est vue disponible. Maintenant, c'est peut-être aussi dû au fait que si effectivement tu as un câble Ethernet en place, c'est qu'au moins une de ses deux prises RJ45 est mal enclenchée (mauvais contact aussi) ou encore que ton câble est tout simplement défectueux; remplaces le pour vérifier ce dernier point. Cordialement oracle7😉

Bonjour, Je confirme, c'est bien le cas sur une Libebox. Cordialement oracle7😉

@McBernic Bonjour, Oui. Je ne saisi pas bien ce que tu veux dire par "fluidité de connexion", si tu penses en fait à "facilité" et/ou "simplification", alors oui. PS astuce : Pour avertir un membre de ta réponse, tu tapes dans ton message "@" + les premiers caractères de son pseudo. Dans le popup qui apparaît tu cliques alors sur le pseudo recherché et il s'affiche sur fond bleu dans ton texte. Ainsi ton interlocuteur est informé/notifié de ta réponse sinon il ne voit rien sauf à rebalayer en arrière tous les messages (ce que peu de monde fait). Cordialement oracle7😉

@alan.dub Bonjour, Il me semble mais je ne suis pas sûr, à confirmer. Cordialement oracle7😉

Bonjour, Pour ajouter aux propos précédents, il y a aussi l'utilisation toute simple de VLC qui lui, se fiche pas mal des codecs quels qu'ils soient. Il lit tout. Cordialement oracle7😉

@Odeon1384 Bonjour, Je serai très curieux de lire ton retour suite à cette manipulation ...🤔 Cordialement oracle7😉

@romaintzark Bonjour, Toute la configuration correcte d'un routeur Synology derrière une LiveBox en DMZ est décrite ici dans ce TUTO. Cordialement oracle7😉

@McBernic Bonjour, Sur ta Livebox, le serveur DCHP attribue automatiquement une @IP à chaque nouveau périphérique qui se connecte. Cette @IP est prise dans la plage qui est définie, c'est à dire entre les @IP de début et de fin qui figurent dans l'onglet "Réseau / DHCP" de la Livebox. Donc, si tu fixes une @IP par un bail statique DHCP pour ton NAS et que cette @IP est dans la plage du DHCP alors il y a toutes les chances qu'à terme il y ait un conflit d'@IP avec un nouveau périphérique qui se connectera car le DHCP lui attribuera automatiquement la même @IP que tu as choisie pour ton NAS. C'est pour éviter ce conflit d'@IP que l'on fixe toujours les @IP de bails statiques à une valeur externe à la plage d'attribution automatique du DHCP. Donc, selon le nombre de périphériques pour les quels tu auras besoin de leur donner une @IP fixe, tu redéfinies la plage du DHCP en modifiant les @IP de début et de fin de celui-ci. Rebooter la LB pour que cette plage soit prise en compte ! Par exemple : Plage du DHCP --> @IP début = 192.168.1.50, @IP fin = 192.168.1.254 ce qui te permettra d'attribuer comme @IP fixe toutes les @IP de 192.168.1.2 à 192.168.1.49 ce qui te laisse finalement une assez grande latitude (pour mémoire l'@IP 192.168.1.1 (mais il arrive aussi que ce soit 192.168.1.254 à la place, il faut adapter alors la plage DHCP selon) est en principe réservée pour la passerelle du réseau (la Livebox elle même). Le DHCP, lui, attribuera automatiquement une @IP prise entre 192.168.1.50 et 192.168.1.254 à tous nouveau périphérique se connectant au réseau local. Cordialement oracle7😉