Aller au contenu

Messages recommandés

Posté(e)

je viens d'essayé chez moi, aucun soucis avec Gmail, vers mon adresse gmail

eCVFtyT.png

Voici ce que j'ai fait :

Création d'un passe d'application : https://support.google.com/mail/answer/185833?hl=fr

Ajout des paramètres dans le compose :

      - WATCHTOWER_NOTIFICATIONS_LEVEL=debug
      - WATCHTOWER_NOTIFICATIONS=email
      - WATCHTOWER_NOTIFICATION_EMAIL_FROM=monmail@gmail.com
      - WATCHTOWER_NOTIFICATION_EMAIL_TO=monmail@gmail.com
      - WATCHTOWER_NOTIFICATION_EMAIL_SERVER=smtp.gmail.com
      - WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PORT=587
      - WATCHTOWER_NOTIFICATION_EMAIL_SERVER_USER=monmail@gmail.com
      - WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PASSWORD=mon_mot_de_passe_dapplication
      - WATCHTOWER_NOTIFICATION_EMAIL_DELAY=2

Modifier monmail@gmail.com par mon adresse gmail

Modifier mon_mot_de_passe_dapplication par le mot de passe d'application fourni par gmail.

Posté(e)

@EVOTk

Je n'ai pas la double authentification et je n'ai pas envie de l'activer. Je vais rester comme cela ou utiliser Gotify.

Merci d'avoir chercher une solution. 🙂

Posté(e)

@Jeff777

Si tu n'a pas la double identification, au lieu du mot de passe d'application, en théorie tu as juste a mettre ton mot de passe "normal".

je vais essayer avec un autre compte gmail sans double auth

Posté(e)

@Jeff777

je viens d'essayé avec mon compte gmail sans double identification, et effectivement, cela ne marche pas, google refuse la connexion !

time="2020-10-16T23:26:31+02:00" level=info msg="Starting Watchtower and scheduling first run: 2020-10-17 00:00:00 +0200 CEST",
Failed to send notification email:  535 5.7.8 Username and Password not accepted. Learn more at,
5.7.8  https://support.google.com/mail/?p=BadCredentials y10sm5182484wrq.73 - gsmtp

Comme ils conseils ici : https://support.google.com/mail/answer/7126229?p=BadCredentials

J'ai par exemple activé l'accès moins sécurisé des applications mais cela ne change rien. 😞

 

Posté(e)

@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😉

Posté(e)

Perso avec OVH en STARTTLS (587) ça marche parfaitement.
Aucun réglage particulier hormis les variables que j'avais données il y a quelques posts de cela.

Posté(e)

Si vraiment tu tien a etre notifié par mail via gmail sans double auth, je pense qu'il va te falloir ouvrir un ticket sur le github de wathtower. ( se qui est bien, c'est que le problème est facile a reproduire ! )

Si c'est un problème dans watchtower, quelqu'un se penchera probablement dessus pour le fixer.

Posté(e) (modifié)

@EVOTk

Bonjour,

Du coup je me suis rabattu sur gotify et voici mon retour :

  1. Installation de Gotify :
    D'abord impossible d'installer avec le réseau proposé "gotify-network" défini en external.
    La notation :
    Citation
    
    
     
    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.

  2. 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"
  3. 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  :
    image.thumb.png.3670aa8fb2b962e3d8c23cb76fe8e16a.png
    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.
     
  4. Maintenant quand je regarde le log de watchtower j'ai cette erreur :
    Citation

    root@MonNAS:/volume1/docker/scripts_instal/watchtower# docker logs -f watchtower
    time="2020-10-17T15:21:01+02:00" level=debug
    time="2020-10-17T15:21:01+02:00" level=debug msg="Sleeping for a second to ensure the docker api client has been properly initialized."
    time="2020-10-17T15:21:02+02:00" level=debug msg="Retrieving running containers"
    time="2020-10-17T15:21:02+02:00" level=debug msg="There are no additional watchtower containers"
    time="2020-10-17T15:21:02+02:00" level=info msg="Starting Watchtower and scheduling first run: 2020-10-18 01:30:00 +0200 CEST"
    Failed to send Gotify notification:  Post "https://gotify.ndd.tld/message?token=xxxxxxxxxxxxxx": dial tcp 192.168.2.10:443: connect: connection timed out

    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😉

Modifié par oracle7
Posté(e)

Salut,

Le docker-compose ne créer par le reseau lui meme, il faut donc le créer manuellement avec la commande présente dans l'erreur :

docker network create gotify-network

Mais en bridge cela fonctionne très bien aussi 😉

Pour l'url de gotify, s'il est installé sur ton nas, en bridge, alors c'est tout simplement l'url du nas avec le port 2222 dans ton compose ( en faite, l'url que tu as utilisé pour accéder a l'interface d'administration 😉 )

Posté(e) (modifié)

@EVOTk

Bonjour,

OK je reste donc comme cela avec le réseau.

il y a 16 minutes, EVOTk a dit :

c'est tout simplement l'url du nas avec le port 2222 dans ton compose ( en faite, l'url que tu as utilisé pour accéder a l'interface d'administration 😉 )

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😉

 

Modifié par oracle7
Posté(e)

Tu a mi en place un proxy inverse ?

Dans ton pare-feu les sous-réseau de docker sont accepté ?

UGV39MG.png

 

Posté(e) (modifié)

@EVOTk

Bonjour,

OUI pour le proxy invé.

il y a 4 minutes, EVOTk a dit :

Dans ton pare-feu les sous-réseau de docker sont accepté ?

Oui absoluement, comme indiqué dans le TUTO sur la sécurisation du NAS :

image.png.2fd4dfedb3701732229fb8529ce7ac1f.png

PS : J'ai édité ma précédente réponse, tu n'as peut-être pas vu.

Cordialement

oracle7😉

Modifié par oracle7
Posté(e)

Effectivement, je n'avais pas vu 😉

Il n'y a donc pas de soucis de port, vu que le reverse est en place.

Si tu arrive a le résoudre en local, cela devrai être bon, je suppose que tu as générer le certificat https sur dsm et configurer sur dsm.

Tu as bien indiqué les entete personnalisé dans DSM ?

Posté(e)

@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😉

 

Posté(e)

Désolé, je n'est pas d'idée !

Si depuis une machine local sa marche avec https://gotify.ndd.tld, il n'y a pas de raison que cela ne marche pas par watchtower.

En SSH, sur le NAS, tu peu essayer directement si cela marche de cette façon

wget "https://gotify.ndd.tld/message?token=xxxxxxxxx" --post-data "title="test"&message="message_de_test"&priority=5" -O /dev/null

Tu es sur que ton nas peu résoudre localement ton reverse ?

Posté(e)

@EVOTk

Bonjour,

Au moins une bonne nouvelle : avec ta commande en SSH, cela marche !

Citation

 wget "https://gotify.ndd.tld/message?token=xxxxxxxxxxxxxxxxx" --post-data "title="test"&message="message_de_test"&priority=5" -O /dev/null
--2020-10-17 17:44:39--  https://gotify.ndd.tld/message?token=xxxxxxxxxxxxxxxxx
Resolving gotify.ndd.tld... 192.168.2.10
Connecting to gotify.ndd.tld|192.168.2.10|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 119 [application/json]
Saving to: '/dev/null'

/dev/null                                   100%[========================================================================================>]     119  --.-KB/s    in 0s

2020-10-17 17:44:39 (12.7 MB/s) - '/dev/null' saved [119/119]

image.png.8c3c42223a0b4b054304e0df484fe8e9.png

Par ailleurs, je viens de m’apercevoir que dans le docker-compose j'avais deux variables d'environnement qui ne peuvent cohabiter ensemble : "WATCHOWER_SCHEDULE" et "WATCHTOWER_POLL_INTERVAL". J'ai viré cette dernière. Un contrôle journalier est amplement suffisant. Enfin je crois...

Sinon le redémarrage du NAS n'a rien apporté.

Dans le log watchtower j'ai toujours failed to send et connexion time out.

il y a 27 minutes, EVOTk a dit :

Tu es sur que ton nas peu résoudre localement ton reverse ?

a priori Oui, puisqu'en local si je fais "gotify.ndd.tld" j'atteins bien l'application gotify.

Je ne sais plus quoi faire ... 😧

Cordialement

oracle7😉

 

Posté(e)

Si l'envoi en SSH est concluant, j'avoue ne pas comprendre ce qui pourrai coincer !

Dans les logs de Gotify rien d'anormal ? Je voit que tu as un RT2600ac, rien dans sa configuration pourrai expliquer se blocage ? De quelle manière ton serveur DNS résout les adresses locales ?

Posté(e)

@EVOTk

Bonjour,

Le log de gotify depuis la dernière commande directe en SSH :

Citation

[GIN] 2020/10/17 - 18:02:53 | 200 |      84.353µs |       127.0.0.1 | GET      "/health"
[GIN] 2020/10/17 - 18:03:04 | 200 |  140.855036ms |    192.168.2.10 | POST     "/message?token=xxxxxxxxxxxxxxxxx"
[GIN] 2020/10/17 - 18:03:04 | 206 |      630.21µs |    192.168.2.12 | GET      "/static/notification.ogg"
[GIN] 2020/10/17 - 18:03:23 | 200 |      82.048µs |       127.0.0.1 | GET      "/health"
[GIN] 2020/10/17 - 18:03:53 | 200 |      70.306µs |       127.0.0.1 | GET      "/health"
[GIN] 2020/10/17 - 18:04:24 | 200 |      81.161µs |       127.0.0.1 | GET      "/health"
[GIN] 2020/10/17 - 18:04:54 | 200 |      72.414µs |       127.0.0.1 | GET      "/health"
[GIN] 2020/10/17 - 18:05:24 | 200 |      79.013µs |       127.0.0.1 | GET      "/health"
[GIN] 2020/10/17 - 18:05:54 | 200 |      74.071µs |       127.0.0.1 | GET      "/health"
[GIN] 2020/10/17 - 18:06:24 | 200 |      68.102µs |       127.0.0.1 | GET      "/health"
[GIN] 2020/10/17 - 18:06:55 | 200 |      68.464µs |       127.0.0.1 | GET      "/health"
[GIN] 2020/10/17 - 18:07:25 | 200 |      70.151µs |       127.0.0.1 | GET      "/health"
[GIN] 2020/10/17 - 18:07:55 | 200 |      70.317µs |       127.0.0.1 | GET      "/health"
[GIN] 2020/10/17 - 18:08:25 | 200 |      74.262µs |       127.0.0.1 | GET      "/health"
[GIN] 2020/10/17 - 18:08:55 | 200 |      68.758µs |       127.0.0.1 | GET      "/health"
[GIN] 2020/10/17 - 18:09:26 | 200 |      73.309µs |       127.0.0.1 | GET      "/health"
[GIN] 2020/10/17 - 18:09:56 | 200 |      67.652µs |       127.0.0.1 | GET      "/health"
[GIN] 2020/10/17 - 18:10:26 | 200 |      78.771µs |       127.0.0.1 | GET      "/health"
[GIN] 2020/10/17 - 18:10:28 | 200 |     660.568µs |    192.168.2.12 | GET      "/current/user"
[GIN] 2020/10/17 - 18:10:28 | 200 |    1.335069ms |    192.168.2.12 | GET      "/"
[GIN] 2020/10/17 - 18:10:28 | 200 |    5.796029ms |    192.168.2.12 | GET      "/static/css/2.e27d1f00.chunk.css"
[GIN] 2020/10/17 - 18:10:28 | 200 |   12.472696ms |    192.168.2.12 | GET      "/static/js/main.d1092a6c.chunk.js"
[GIN] 2020/10/17 - 18:10:28 | 200 |   86.588193ms |    192.168.2.12 | GET      "/static/js/2.f3ca663c.chunk.js"
[GIN] 2020/10/17 - 18:10:28 | 200 |       88.06µs |    192.168.2.12 | GET      "/version"
[GIN] 2020/10/17 - 18:10:28 | 200 |    1.246047ms |    192.168.2.12 | GET      "/current/user"
[GIN] 2020/10/17 - 18:10:29 | 200 |    1.202553ms |    192.168.2.12 | GET      "/message?since=0"
[GIN] 2020/10/17 - 18:10:29 | 200 |    1.937422ms |    192.168.2.12 | GET      "/application"
[GIN] 2020/10/17 - 18:10:29 | 200 |     678.383µs |    192.168.2.12 | GET      "/stream?token=C8TY9F3rsoypE7Q"
[GIN] 2020/10/17 - 18:10:29 | 200 |     198.992µs |    192.168.2.12 | GET      "/static/favicon-16x16.png"
[GIN] 2020/10/17 - 18:10:29 | 200 |    1.550313ms |    192.168.2.12 | GET      "/static/favicon-196x196.png"
[GIN] 2020/10/17 - 18:10:29 | 200 |    2.201351ms |    192.168.2.12 | GET      "/static/defaultapp.png"
[GIN] 2020/10/17 - 18:10:56 | 200 |      80.918µs |       127.0.0.1 | GET      "/health"
[GIN] 2020/10/17 - 18:11:26 | 200 |      67.339µs |       127.0.0.1 | GET      "/health"
[GIN] 2020/10/17 - 18:11:57 | 200 |      66.672µs |       127.0.0.1 | GET      "/health"
[GIN] 2020/10/17 - 18:12:27 | 200 |      68.429µs |       127.0.0.1 | GET      "/health"
[GIN] 2020/10/17 - 18:12:57 | 200 |      70.329µs |       127.0.0.1 | GET      "/health"

....

 

 

il y a 9 minutes, EVOTk a dit :

Je voit que tu as un RT2600ac, rien dans sa configuration pourrai expliquer se blocage ? De quelle manière ton serveur DNS résout les adresses locales ?

Pour le RT, je ne vois pas. Le DNS Serveur installé sur le routeur est configuré comme dit dans le TUTO DNS Server. Je ne sais que te dire de plus.

Au fait, MERCI beaucoup de prendre de ton temps pour répondre à mes questions et essayer de me "dépatouiller" de cette installation Gotify/Watchtower. J'apprécie vraiment. 😀😀😀

Cordialement

oracle7😉

Posté(e)

Les logs sont parfait. et on voit bien qu'il n'y a rien de la part de watchtower, donc il n'arrive absolument pas a le contacter !

De plus en SSH c'est fonctionnel, ce qui m'intrigue encore plus !

De rien, Il n'y as pas de soucis ! mais je t'avoue que je suis a cours d'idée pour t'aider !

De se que je voit deux différences avec moi :

Tu es en bridge, mais sans réseau indiqué mais je suppose que docker t'a créé un sous réseau tout seul ? genre gotify_network donc cela ne doit pas avoir d'incidence.

De plus si dans WATCHTOWER_NOTIFICATION_GOTIFY_URL tu indique "http://192.168.2.10:2222" cela devrai fonctionner, les possibles problemes de dns, de reverse, de certificats,  ... ne rentre pas en compte !

Dans tes logs lors d'un envoi, tu as ton adresse ip locale qui apparait*, et moi c'est mon adresse ip externe ( mais mon serveur DNS est ma freebox, qui fait la résolution locale d'elle même, je suppose que c'est pour sa aussi !

 

*Connecting to gotify.ndd.tld|192.168.2.10|:443... connected.

Posté(e)

@EVOTk

Bonjour,

Cette affaire de réseau m'interpelle quand même. Je vais donc configurer Gotify pour qu'il ai son propre réseau comme dans ton TUTO car pour le moment il "partage" un réseau bridge avec watchtower. Serait-ce un problème ? On va bien voir ...

Accessoirement, ce qui m'ennuie juste c'est qu'on soit obligé de passer par une création manuelle de son réseau. Il n'y a vraiment pas moyen qu'il soit créer automatiquement via instruction adéquat dans le docker-compose ?

J'ai donc modifié le réseau Gotify, mais pas de changement.

Autre idée saugrenue : puisque le message passe lors d'une commande wget en SSH sous root, ne faut-il pas déclarer un puid/guid de type administrateur dans le docker-compose de watchtower ?

Cordialement

oracle7😉

 

Posté(e)

Salut,

Non pas besoin de PUID/GUID, le commande s’exécute dans le conteneur.

Quand watchtower me notifie , j'ai dans les logs de Gotify ceci :


[GIN] 2020/10/17 - 20:16:00 | 200 |    4.626075ms |   192.168.0.254 | POST     "/message?token=xxxxxxxx"

L'adresse "source" est donc ma freebox, configurer en serveur DNS sur le NAS.

Les ports dans ton pare-feu sont t'il ouvert pour ton sous domaine 192.168.... ?

Posté(e) (modifié)

@EVOTk

Bonjour,

il y a 59 minutes, EVOTk a dit :

Les ports dans ton pare-feu sont t'il ouvert pour ton sous domaine 192.168.... ?

Désolé, je ne comprend pas ta question. De quels ports tu parles ?

J'ai ouvert le port 2222 dans le pare-feu du NAS pour le cas où, mais a priori sans effet. Le port 80 est aussi ouvert. Le blocage n'est donc pas là.

il y a 59 minutes, EVOTk a dit :

L'adresse "source" est donc ma freebox, configurer en serveur DNS sur le NAS.

Si je te suis  par similitude, l'@ source devrait être alors l'@IP de mon routeur en 192.168.2.1 (lui même 192.168.1.2 derrière ma LiveBox 192.168.1.1 qui est DMZ) or c'est l'@IP de mon NAS 192.168.2.10 qui apparait dans le log de gotify lorsque j'exécute sous SSH une commande wget ... (nota : mon serveur DNS est sur le routeur).

Ce que je ne comprend pas : avec une commande wget en SSH donc en local, cela passe direct en interne de 172.16.0.0/12 à 192.1682.0/24. Si j'ai un blocage en utilisation normale c'est qu'il passe par ailleurs, non ? Mais comment savoir alors ?

EDIT : pourquoi dans le docker-compose de ton TUTO il y a deux fois la variable "GOTIFY_DEFAUTUSER_PASS" avec =custom et avec =admin ?

Cordialement

oracle7😉

Modifié par oracle7
Posté(e) (modifié)

Hello,

Vu que cela marche en SSH sur le NAS. Je pense qu'il n'y a aucun blocage a ce niveau.

Si dans les paramètres de Watchtower, pour Gotify tu indique "http://192.168.2.10:2222", quel message d'erreur obtient tu ?

Edit : Pour GOTIFY_DEFAUTUSER_PASS 2x, c'est une erreur que j'avais corrigé sur mon conteneur mais pas dans le tuto, voila qui est fait.

Modifié par Invité

Rejoindre la conversation

Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.