oracle7

@EVOTk Bonjour, Mon certificat LE est un wilcard et j'ai vérifié, il est bien configuré pour "gotify.ndd.tld". J'ai bien renseigné l'entête personnalisé dans le proxy inversé. J'ai aussi vérifié que mon profil de contrôle d'accès dans le proxy inversé autorisait bien le réseau 172.16.0.0/12. Je vais faire un arrêt/redémarrage du NAS, on ne sait jamais ... Cordialement oracle7😉

@EVOTk Bonjour, OUI pour le proxy invé. Oui absoluement, comme indiqué dans le TUTO sur la sécurisation du NAS : PS : J'ai édité ma précédente réponse, tu n'as peut-être pas vu. Cordialement oracle7😉

@kroumi Bonjour, Cela me paraît être une sage et bonne résolution. Tu ne le regretteras pas ... Cordialement oracle7😉

@EVOTk Bonjour, OK je reste donc comme cela avec le réseau. Eh justement le problème est là. L'URL que j'ai indiqué "https://gotify.ndd.tld" dans le docker-compose.yml est bien celle avec la quelle j'accède au NAS via le proxy inversé qui pointe bien vers "http://localhost:2222". A la réflexion, je me demandais s'il ne fallait pas aussi ouvrir le port 2222 dans le pare-feu du NAS vu le timeout indiqué dans le message d'erreur ? j'ai bon ou pas ? EDIT : Je viens d'ajouter chez OVH le sous-domaine "gotify.ndd.tld", je verrais donc demain après la diffusion mondiale sur les serveurs DNS. Pour l'instant en local, mon serveur DNS est à jour avec ce sous-domaine, donc j'arrive à connecter avec et sans problème mais cela ne suffit peut-être pas pour watchtower ... Ton avis STP ? Cordialement oracle7😉

@EVOTk Bonjour, Du coup je me suis rabattu sur gotify et voici mon retour : Installation de Gotify : D'abord impossible d'installer avec le réseau proposé "gotify-network" défini en external. La notation : ne passe pas et donne ce message d'erreur : root@MonNAS:/volume1/docker/scripts_instal/gotify# docker-compose up -d ERROR: Network gotify-network declared as external, but could not be found. Please create the network manually using `docker network create gotify-network` and try again. Mais il y avait peut-être une bonne raison à utiliser ce type de réseau et j'ai sûrement alors raté quelque chose. Mais quoi dans ce cas ? J'ai donc essayé avec "network_mode: bridge" et là aucun problème. Le conteneur gotify s'est créé correctement. Mon fichier "docker-compose.yml" : version: "2" services: gotify: image: gotify/server:latest container_name: gotify network_mode: bridge ports: - 2222:80 environment: - GOTIFY_DEFAULTUSER_PASS=custom - GOTIFY_DATABASE_DIALECT=sqlite3 - GOTIFY_DATABASE_CONNECTION=data/gotify.db - GOTIFY_DEFAULTUSER_NAME=admin - GOTIFY_DEFAULTUSER_PASS=admin - GOTIFY_PASSSTRENGTH=10 - GOTIFY_UPLOADEDIMAGESDIR=data/images - GOTIFY_PLUGINSDIR=data/plugins - TZ=Europe/Paris volumes: - /volume1/docker/gotify/data:/app/data labels: - "com.centurylinklabs.watchtower.enable=true" Ensuite dans l'application Gotify (lancée dans un navigateur avec un "gotify.ndd.tld" défini dans le proxy inversé du NAS avec l'entête personnalisé qui va bien), j'ai ajouté une application que j'ai nommée "watchtower" et j'ai récupéré le token correspondant : J'ai renseigné ce token dans le fichier "docker-compose.yml" de watchtower que voici : version: '2.1' services: watchtower: image: containrrr/watchtower:latest container_name: watchtower hostname: watchtower network_mode: bridge environment: - TZ=Europe/Paris - WATCHTOWER_POLL_INTERVAL=21600 - WATCHTOWER_SCHEDULE=0 30 1 * * * - WATCHTOWER_LABEL_ENABLE=true - WATCHTOWER_CLEANUP=true - WATCHTOWER_REMOVE_VOLUMES=true - WATCHTOWER_NOTIFICATIONS_LEVEL=debug - WATCHTOWER_DEBUG=true - WATCHTOWER_TIMEOUT=30s - WATCHTOWER_NOTIFICATIONS=gotify - WATCHTOWER_NOTIFICATION_GOTIFY_URL=https://gotify.ndd.tld - WATCHTOWER_NOTIFICATION_GOTIFY_TOKEN=xxxxxxxxxxxxxx labels: - "com.centurylinklabs.watchtower.enable=true" volumes: - /var/run/docker.sock:/var/run/docker.sock restart: unless-stopped La création du conteneur watchetower se fait ensuite sans problème. Maintenant quand je regarde le log de watchtower j'ai cette erreur : Je pense que cela doit être l'URL renseignée pour la variable "WATCHTOWER_NOTIFICATION_GOTIFY_URL" qui n'est pas bonne. J'ai essayé avec "https:/gotify.ndd.tld", puis avec "https://gotify" mais les deux retournent dans le log le même type de message d'erreur. Là je ne vois/comprends pas quelle URL il faut effectivement renseigner. Une idée peut-être ? Cordialement oracle7😉

@EVOTk et @Jeff777 Je confirme, j'ai le même message de refus de Gmail lorsque j'essaie avec une @Mail gmail sans double authentification. Mais dans cette affaire, il me semble plus que c'est Watchtower qui ne gère mal voire pas du tout le TLS/STARTTLS pour le port 587. De fait quelque soit l'opérateur utilisé, la connexion est rejetée. C'est une explication qui vaut ce qu'elle vaut. Votre avis ? Cordialement oracle7😉

@YannMilou Bienvenue à toi sur ce forum, tu verras c'est une mine d'informations 😀 Cordialement oracle7😉

@YannMilou Bonjour, C'est dommage car elles sont importantes dans la résolution du problème : Taper WIN + R et saisir "services.msc" Dans la fenêtre qui affiches la liste des services windows, pour chacun des services précités : clic droit sur le service et sélectionner "Propriétés" Régler le démarrage (popup "type de démarrage") sur Automatique Si le service est au statut arrêté : cliquer sur le bouton Démarrer Appliquer et OK Reboot PC quand c'est fait pour tous les services Taper WIN + R et saisir "control panel" Aller sur "Centre réseau réseau et partage" puis sur "Modifier les paramètres de partage avancés" Vérifier que tout est correct. Taper WIN + R et saisir "control panel" Aller sur "Centre réseau réseau et partage" puis sur "Modifier les paramètres de la carte" Clic droit sur l'adaptateur réseau "Ethernet" correspondant à la carte réseau active et sélectionner "Propriétés" Sélectionner "Protocole IPv4" et cliquer sur "Propriétés" Cocher "Utiliser l'adresse de serveur DNS suivante" et saisir les @IP des serveurs FND Reboot PC après 2 et/ou 3 Bien voir que toutes ces manipulations ne sont que des pistes de résolution de ton problème. Enfin en complément de ce que t'a dit @firlin il te faut comprendre ceci (j'ai repris ici une explication donnée en son temps par @Kramlech il me semble) : Dans le cas "Périphérique médias (5)", c'est le "Périphérique médias NAS" (client DLNA) qui te répond, et il ne voit que les trois répertoire DLNA standard (music, video et photo)... Dans le cas "Ordinateur (4)" , c'est "l'ordinateur NAS" qui répond, et tu vois tes répertoires partagés. 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😉

@EVOTk Bonjour, Merci pour les liens, je vais lire cela avec intérêt. Pour l'installation, ceal devrait pas poser de problème. Mais au final dans le cas de Watchtower, comment on met en œuvre ces notifications avec Gotify ? Cordialement oracle7😉

@EVOTk Désolé, pardonnes mon ignorance, mais c'est quoi Gotify, çà fait/sert à quoi ? Cordialement oracle7😉

@EVOTk Bonjour, Oui dans la mesure, où j'avais trouvé cette information sur un forum orange info donnée de la part d'un expert a priori reconnu sur ce forum (après c'est une question de confiance envers cet expert). Tu peux si tu veux lire la suite des échanges dans le lien. C'est justement ce qui me permet de contourner les choses dans la configuration de MailPlus Server que je décrit dans mon TUTO afin de lui permettre d'envoyer des eMails sans être considéré comme un spammeur. NON, j'utilise simplement les paramètres de ma boite Mail courante chez Orange. Au final, je me demande si je ne vais pas tout simplement me passer de cette notification par email pour Watchtower. Le principal étant qu'il son boulot c'est à dire mettre à jour les images des conteneurs quand une nouvelle version stable est diffusée/disponible. A moins, que la lumière nous descende du ciel ....😇 Cordialement oracle7😉

@EVOTk Ce comportement est devenu le standard. Tous les opérateurs appliquent ce type de restriction. Tu ne peux accéder qu'au serveur SMTP non authentifié de l'opérateur qui gère la ligne. Le port 25 n'est pas bloqué, mais un serveur SMTP ignore les connexions provenant d'un autre réseau si elles lui arrivent sur le port 25. Donc sur une LiveBox comme moi, je peux oublier le port 25. Pas d'autre choix que d'utiliser le port 587 car l'eMail de notification envoyé par Watchtower dans le cas présent, a pour origine le réseau docker (172.17.0.2).

@Jeff777 @EVOTk Après l'ajout de la variable : WATCHTOWER_NOTIFICATION_EMAIL_SERVER_TLS_SKIP_VERIFY Bien que la doc dit que son usage : "This should be used only for testing." Je récolte ceci : Maintenant c'est le serveur SMTP d'Orange qui n'aime pas la connexion !!! 😩 Cordialement oracle7😉

@Jeff777, @EVOTk J'ai donc rajouté les deux variables : WATCHTOWER_NOTIFICATIONS_LEVEL=debug WATCHTOWER_NOTIFICATION_EMAIL_DELAY=2 mais je récolte ceci : Une idée ? Cordialement oracle7😉

@Jeff777 Nous faisons donc exactement la même chose. @EVOTk Tu es sûr de ton coup avec cette variable, car sauf erreur de ma part, il n'en est aucunement fait mention dans la doc de Watchtower (partie notifications du moins) ? La seule variable que j'ai trouvé liée au debug est : WATCHTOWER_DEBUG dans la partie arguments de la doc. Chez moi cette variable est positionnée à TRUE. EDIT : OUPS !!! Désolé je suis miro, elle existe bien ! Je vais l'ajouter et tester donc. Cordialement oracle7😉

@Jeff777 Bonjour, Merci d'avoir regardé. J'en conclue que le problème est bien du coté de watchtower à moins que nous rations un truc mais je ne crois pas. Le paramétrage de celui-ci n'a rien d'extraordinaire, alors ... Pour les messages dans le log, je pense que c'est normal. Il est juste très verbeux en disant qu'il n'y a a pas de nouvelle image pour le conteneur concerné. Comme quoi il balaye bien chaque conteneur pour vérifier. Il fait son boulot en somme ... Cordialement oracle7😉

@.Shad. Bonjour, C'est réglé après avoir redémarrer (reconstruit) tous les conteneurs. Watchtower à bien vu les mises à jour à faire et les a réalisées. SUPER ! 😀 Il n'y a plus que le problème de notifications par emails qui ne fonctionne pas. @Jeff777 as-tu résolu le problème de ton coté et si oui qu'as-tu fait pour cela ? Cordialement oracle7😉

@.Shad. Bonjour, Désolé, cela ne marche pas. J'ai donc regardé le lien que tu m'as donné et j'ai créé dans "etc/snmp" un fichier "snmp.conf" telque : mibdirs +/volume1/docker/MIBs mibs +HIK-DEVICE-MIB J'ai ajouté dans le fichier "telegraf.conf" les lignes suivantes : #---------------------------------------------------------- ## HIKVISION IP Camera #---------------------------------------------------------- # Uses the HIK-DEVICE-MIB [[inputs.snmp]] agents = [ "192.168.2.21" ] interval = "60s" timeout = "10s" retries = 3 version = 2 community = "xxxxxxxxxxxxx" max_repetitions = 30 name = "snmp.HIK" # HIK Manufacturer [[inputs.snmp.field]] name = "manufacturer" oid = "HIK-DEVICE-MIB::manufacturer.0" # HIK Device Model [[inputs.snmp.field]] name = "deviceModel" oid = "HIK-DEVICE-MIB::deviceType.0" # HIK Version Software [[inputs.snmp.field]] name = "softwVersion" oid = "HIK-DEVICE-MIB::softwVersion.0" # HIK Cpu Precent [[inputs.snmp.field]] name="cpuPercent" oid = "HIK-DEVICE-MIB::cpuPercent.0" # HIK Mem Used [[inputs.snmp.field]] name="memUsed" oid = "HIK-DEVICE-MIB::memUsed.0" # HIK Static Ip [[inputs.snmp.field]] name="staticIp" oid = "HIK-DEVICE-MIB::staticIpAddr.0" # HIK MAC Address [[inputs.snmp.field]] name="macAddr" oid = "HIK-DEVICE-MIB::macAddr.0" # HIK Video Encode [[inputs.snmp.field]] name="vidEncode" oid = "HIK-DEVICE-MIB::videoEncode.0" [[processors.regex]] order = 1 namepass = ["snmp"] [[processors.regex.fields]] key = "cpuPercent" pattern = "^(\\d+).*" replacement = "${1}" [[processors.regex.fields]] key = "memUsed" pattern = "^(\\d+).*" replacement = "${1}" [[processors.converter]] order = 2 [processors.converter.fields] integer = ["cpuPercent","memUsed"] et redémarré le conteneur telegraf --> docker restart telegraf Maintenant il y a déjà un mieux en renseignant correctement la partie snmp de la caméra (dans son logiciel d'admin) et en redémarrant ensuite celle-ci, j'arrive à voir ses infos avec une commande : "snmpwalk -c xxxxxxxxxxxxx -v 2c 192.168.2.21 1.3.6.1.4.1.39165" : SNMPv2-SMI::enterprises.39165.1.1.0 = STRING: "DS-2CD2045FWD-I" SNMPv2-SMI::enterprises.39165.1.2.0 = STRING: "0" SNMPv2-SMI::enterprises.39165.1.3.0 = STRING: "V5.6.5 build 200316" SNMPv2-SMI::enterprises.39165.1.4.0 = STRING: "xx-xx-xx-xx-xx-xx" SNMPv2-SMI::enterprises.39165.1.5.0 = STRING: "1" SNMPv2-SMI::enterprises.39165.1.6.0 = STRING: "Hikvision" SNMPv2-SMI::enterprises.39165.1.7.0 = STRING: "71 PERCENT" SNMPv2-SMI::enterprises.39165.1.8.0 = STRING: "0.0 GB" SNMPv2-SMI::enterprises.39165.1.9.0 = STRING: "0 PERCENT" SNMPv2-SMI::enterprises.39165.1.10.0 = STRING: "512 MB" SNMPv2-SMI::enterprises.39165.1.11.0 = STRING: "54 PERCENT" SNMPv2-SMI::enterprises.39165.1.12.0 = INTEGER: 0 SNMPv2-SMI::enterprises.39165.1.13.0 = IpAddress: 192.168.2.21 SNMPv2-SMI::enterprises.39165.1.14.0 = IpAddress: 255.255.255.0 SNMPv2-SMI::enterprises.39165.1.15.0 = IpAddress: 192.168.2.1 SNMPv2-SMI::enterprises.39165.1.16.0 = IpAddress: 0.0.0.0 SNMPv2-SMI::enterprises.39165.1.17.0 = IpAddress: 0.0.0.0 SNMPv2-SMI::enterprises.39165.1.18.0 = IpAddress: 0.0.0.0 SNMPv2-SMI::enterprises.39165.1.19.0 = STRING: "2020-10-15 21:15:26" SNMPv2-SMI::enterprises.39165.1.20.0 = INTEGER: 1 SNMPv2-SMI::enterprises.39165.1.21.0 = STRING: "H.264" SNMPv2-SMI::enterprises.39165.1.22.0 = STRING: "H.264" SNMPv2-SMI::enterprises.39165.1.23.0 = INTEGER: 0 SNMPv2-SMI::enterprises.39165.1.24.0 = INTEGER: 0 SNMPv2-SMI::enterprises.39165.1.25.0 = INTEGER: 0 SNMPv2-SMI::enterprises.39165.1.26.0 = INTEGER: 1 SNMPv2-SMI::enterprises.39165.1.27.0 = INTEGER: 1 SNMPv2-SMI::enterprises.39165.1.28.0 = INTEGER: 1 SNMPv2-SMI::enterprises.39165.1.29.0 = STRING: "ETHERNET" SNMPv2-SMI::enterprises.39165.1.30.0 = INTEGER: 0 SNMPv2-SMI::enterprises.39165.1.31.0 = INTEGER: 0 SNMPv2-SMI::enterprises.39165.1.32.0 = IpAddress: 0.0.0.0 SNMPv2-SMI::enterprises.39165.1.33.0 = STRING: "192.168.2.10" SNMPv2-SMI::enterprises.39165.1.34.0 = INTEGER: 0 SNMPv2-SMI::enterprises.39165.1.34.0 = No more variables left in this MIB View (It is past the end of the MIB tree) mais et il y a un MAIS, une fois dans le monitoring impossible de sélectionner dans le "FROM" d'une requête la valeur "syno.HIK", elle n'apparait pas. Tout ce passe comme si l'ajout dans le fichier "telegraf.conf" n'avait pas été pris en compte. Du coup je suis un peu (beaucoup) perplexe voir perdu. Une idée ou piste de ta part serait très appréciée ... Cordialement oracle7😉

@YannMilou Bonjour, Une autre solution pour créer le lecteur réseau : plutôt que de saisir "\\NAS-D1019\Films", as-tu essayé en tapant "\\@IPduNAS\Films" car NETBIOS en fait souvent qu'à sa tête et certains noms attribués au périphériques ne passent pas - allez comprendre ? (voir aussi les règles de nommage en vigueur). Cordialement oracle7😉

@firlin Bonjour, Tes informations sont excellentes. Voilà qui répond à bon nombre de questions. MERCI pour le partage.😀 Cordialement oracle7😉

@YannMilou Bonjour, Comme sur tout forum, il est d'usage que les nouveaux membres passent par la rubrique [PRESENTATION] pour faire la leur. Certains ici, y sont sensibles et de plus cela facilite les réponses en fonction du niveau de compétences du membre. Cela dit rassures-toi il n'est pas trop tard pour bien faire ... Pour ton problème, essayes ces manipulations : Sinon pour ton Zappiti, as-tu essayer via le protocole NFS ? Je crois me rappeler qu'il accepte aussi ce protocole. Cordialement oracle7😉

@Audio Bonjour, Merci pour ce retour positif. Je suis juste étonné vis à vis que les clés OVH n'étaient pas sauvegardées. En principe c'est automatiquement réalisé par le script "acme.sh". Peut-être que lors de précédants essais (échoués), cela n'avait pu être fait et ensuite il saute cette phase pour aller directement lire les valeurs sauvegardées parce que pour lui, le certificat a déjà été créé ??? Toujours est-il, tu y es arrivé et c'est ce qui importe. Cordialement oracle7😉

@cadkey Bonjour, Sans être désobligeant, je crains que oui. Comme tu le dis toi-même, tu n'as effectivement pas compris l'intérêt de la méthode décrite dans ce TUTO. Je t'invites donc à bien relire tout le préambule du TUTO où j'ai essayé d'expliquer la problématique et la démarche suivie, de façon la plus détaillée possible et notamment comment on s'affranchit de l'ouverture du port 80, laquelle ne se résout pas, à mon humble avis, en installant simplement web station. Je peux simplement te garantir que la méthode marche et sans aucune autre intervention une fois en place. Maintenant si elle ne te convient pas pour x raisons, libre à toi d'en utiliser une autre, tu n'as aucune obligation. Je ne fais ici que proposer une solution parmi d'autres pour créer et assurer le renouvellement automatique d'un certificat "wilcard" Let'sEncrypt pour un domaine personnalisé. Cordialement oracle7😉

@.Shad. Bonjour, OUI, TOUS les fichiers docker-compose.yml de tous mes conteneurs comportent bien l'instruction "labels:" : labels: - "com.centurylinklabs.watchtower.enable=true" Et j'ai bien relancé tous les conteneurs et j'ai même redémarré le NAS ensuite. Je n'utilises pas les services d'OVH pour l'envoi de mail dans ce cas précis. J'ai simplement repris et entré les informations de connexion de ma boite mail Orange. Cordialement oracle7😉

@.Shad. Bonjour, En complément à ma tentative de configurer le monitoring de mes caméras HIKvision. Dans le logiciel de configuration des caméras HIK j'ai ceci à propos de la partie snmp : Est-ce qu'il faut bien renseigner comme cela ? (l'@IP est celle de la caméra). Au niveau des fichiers MIB, en attendant plus de précisions (voir mon post précédent), j'ai collé dans le répertoire "usr/share/snmp/mibs/" les deux fichiers MIB trouvés pour HIK ici. A leur examen, je constate d'une part : - que l'un (HIKVISION-MIB.txt) est valable pour une entreprise "50001" et l'autre (HIK-DEVICE-MIB.txt) pour une entreprise "39165". - que d'autre part, les données qu'il gèrent sont différentes même si certaines semblent se ressembler. ????? Est-ce un problème cette différence de validité ? A noter que les infos que j'ai récupérées par ailleurs dans un dashboard sur grafana.com semblent elles utiliser le fichier HIK-DEVICE-MIB. J'ai donc ajouter ces informations dans le fichier "telegraf.conf". Mais à bien y réfléchir, j'ai un doute, Est-ce que j'ai bien fait, Oui/Non ? Dans le fichier "telegraf.conf" j'ai aussi ajouté l'@IP de ma caméra dans le champ "agents" sous INPUT PLUGIN. Fort de tout cela, après avoir re généré le conteneur telegraf, j'ai essayé dans une session SSH la commande suivante pour voir si au moins je récupérais des infos de la caméra : "snmpwalk -c public -v2c 192.168.2.21 1.3.6.1.1.1.39165" mais "Timeout: No Response from 192.168.2.21". Idem en remplaçant l'@IP de la caméra par celle du conteneur telégraf 172.20.0.3. (public sera remplacé par la bonne valeur "secrète"). Le log de telegraf me donne aussi ceci : J'ai raté ou omis sûrement quelque chose mais je ne vois pas quoi ? Une idée ou une piste serait la bienvenue pour me permettre de dépatouiller tout cela ... Merci d'avance de ta réponse. Cordialement oracle7😉