[TUTO] Mise à jour automatique des images et conteneurs Docker

le 16 octobre 2020

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

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.

Jeff777 · le 16 octobre 2020

@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. 🙂

le 16 octobre 2020

@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

Jeff777 · le 16 octobre 2020

J'ai essayé sans succès. Le serveur Gmail refuse les email provenant de l'appli.

le 16 octobre 2020

@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. 😞

Jeff777 · le 16 octobre 2020

Ok merci je lirai cela demain.😪

oracle7 · le 17 octobre 2020

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

.Shad. · le 17 octobre 2020

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.

le 17 octobre 2020

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.

oracle7 · le 17 octobre 2020

@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 :
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.

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 :

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é le 17 octobre 2020 par oracle7

le 17 octobre 2020

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

oracle7 · le 17 octobre 2020

@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é le 17 octobre 2020 par oracle7

le 17 octobre 2020

Tu a mi en place un proxy inverse ?

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

oracle7 · le 17 octobre 2020

@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é le 17 octobre 2020 par oracle7

le 17 octobre 2020

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 ?

oracle7 · le 17 octobre 2020

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

le 17 octobre 2020

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 ?

oracle7 · le 17 octobre 2020

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

le 17 octobre 2020

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 ?

oracle7 · le 17 octobre 2020

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

le 17 octobre 2020

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.

oracle7 · le 17 octobre 2020

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

le 17 octobre 2020

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.... ?

oracle7 · le 17 octobre 2020

@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é le 17 octobre 2020 par oracle7

le 17 octobre 2020

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é le 17 octobre 2020 par Invité

Connexion

[TUTO] Mise à jour automatique des images et conteneurs Docker

Messages recommandés

Invité

Lien vers le commentaire

Partager sur d’autres sites

Meilleurs contributeurs dans ce sujet

Jours populaires

Meilleurs contributeurs dans ce sujet

Jours populaires

Messages populaires

.Shad.

.Shad.

.Shad.

Images postées

Lien vers le commentaire

Partager sur d’autres sites

Invité

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Invité

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Invité

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Invité

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Invité

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Invité

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Invité

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Invité

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Invité

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Invité

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Invité

Lien vers le commentaire

Partager sur d’autres sites

Rejoindre la conversation

Qui est en ligne 0 membre, 0 anonyme, 302 invités (Afficher la liste complète)

Contributeurs populaires

Annonces

Information importante