Aller au contenu
bobjouy

[App Tierce] Teslamate : datalogger local et gratuit

Messages recommandés

En regardant mes données, j'ai l'impression que c'est la coupure sauvage de la VM (coupure de courant) qui a provoqué mes soucis : parti le 10, je n'ai rien entre le 12 et mon retour cette nuuit....

 

Ca vous est déjà arrivé ? Quand la VM redémarre, elle n'est pas censée relancer le docker ?

Partager ce message


Lien à poster
Partager sur d’autres sites

Montre voir le résultat d'un "systemctl status docker*" ? Peut-être que docker ne démarre pas tout seul.

 

Concernant le docker-compose.yml tu devrais avoir "restart: always" pour chaque container pour que les containers soient lancés au boot time, et bien sûr tu lance le docker-compose avec -d pour que ce soit daemonisé dès le début.

Partager ce message


Lien à poster
Partager sur d’autres sites

Je n'ai aucune certitude en matière de Linux ^^
 
Ah si, celle que je suis un boulet (je fais un beau CTL-C au milieu d'un docker-compose up pour montrer le résultat.... du coup, j'ai tout arrêté comme un sauvage...)
 
Bon, aux dernières nouvelles, ça remarche... O_o
 

Good news c’est l’essentiel... mais tu as perdu de l’historique du coup

Partager ce message


Lien à poster
Partager sur d’autres sites

il y a une heure, Yann73 a dit :

Montre voir le résultat d'un "systemctl status docker*" ? Peut-être que docker ne démarre pas tout seul.

 

Concernant le docker-compose.yml tu devrais avoir "restart: always" pour chaque container pour que les containers soient lancés au boot time, et bien sûr tu lance le docker-compose avec -d pour que ce soit daemonisé dès le début.

Citation

 

freebox@Debian:~$ systemctl status docker
● docker.service - Docker Application Container Engine
   Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2020-08-24 21:59:50 UTC; 11h ago
     Docs: https://docs.docker.com
 Main PID: 492 (dockerd)
    Tasks: 21
   Memory: 62.8M
   CGroup: /system.slice/docker.service
           └─492 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock

Aug 25 08:24:42 Debian dockerd[492]:         /usr/local/go/src/runtime/asm_arm64.s:70 +0xb8 fp=0xffffd37fd9a0 sp=0xffffd37fd970 pc=0xaaaadb4170c0
Aug 25 08:24:42 Debian dockerd[492]: time="2020-08-25T08:24:42.395876666Z" level=warning msg="Failed to disable IPv6 on all interfaces on network namespace \"/var/run/docker/netns/57e48aa66
Aug 25 08:24:42 Debian dockerd[492]: time="2020-08-25T08:24:42.398453596Z" level=warning msg="Failed to disable IPv6 on all interfaces on network namespace \"/var/run/docker/netns/842ba5539
Aug 25 08:24:43 Debian dockerd[492]: time="2020-08-25T08:24:43.461210145Z" level=info msg="ignoring event" module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"
Aug 25 08:25:43 Debian dockerd[492]: time="2020-08-25T08:25:43.026997936Z" level=info msg="ignoring event" module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"
Aug 25 09:50:44 Debian dockerd[492]: time="2020-08-25T09:50:44.645743116Z" level=info msg="ignoring event" module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"
Aug 25 09:50:44 Debian dockerd[492]: time="2020-08-25T09:50:44.655529272Z" level=info msg="ignoring event" module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"
Aug 25 09:50:44 Debian dockerd[492]: time="2020-08-25T09:50:44.733468599Z" level=info msg="ignoring event" module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"
Aug 25 09:50:54 Debian dockerd[492]: time="2020-08-25T09:50:54.333186216Z" level=info msg="Container 576097a79da845d0fadd536ec8008a907e6c206782ebdfd027e34ded57655f31 failed to exit within 1
Aug 25 09:50:54 Debian dockerd[492]: time="2020-08-25T09:50:54.533310954Z" level=info msg="ignoring event" module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"
lines 1-20/20 (END)

 

 

Je refais mon docker-compose avec -d :D

 

Partager ce message


Lien à poster
Partager sur d’autres sites

Bon, je viens de reproduire le problème en redémarrant la Freebox...

 

J'ai :

 

Citation

● docker.service - Docker Application Container Engine
   Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2020-08-25 10:04:02 UTC; 37s ago
     Docs: https://docs.docker.com
 Main PID: 495 (dockerd)
    Tasks: 42
   Memory: 78.5M
   CGroup: /system.slice/docker.service
           ├─495 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
           ├─830 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 3000 -container-ip 172.18.0.2 -container-port 3000
           ├─860 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 4000 -container-ip 172.18.0.4 -container-port 4000
           └─877 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 1883 -container-ip 172.18.0.5 -container-port 1883

Aug 25 10:04:01 Debian dockerd[495]: time="2020-08-25T10:04:01Z" level=error msg="set up rule failed, [-t nat -I DOCKER_OUTPUT -d 127.0.0.11 -p tcp --dport 53 -j DNAT --to-destination 127.0
Aug 25 10:04:01 Debian dockerd[495]: time="2020-08-25T10:04:01Z" level=error msg="set up rule failed, [-t nat -I DOCKER_POSTROUTING -s 127.0.0.11 -p udp --sport 56525 -j SNAT --to-source :5
Aug 25 10:04:01 Debian dockerd[495]: time="2020-08-25T10:04:01Z" level=error msg="set up rule failed, [-t nat -I DOCKER_POSTROUTING -s 127.0.0.11 -p tcp --sport 41291 -j SNAT --to-source :5
Aug 25 10:04:01 Debian dockerd[495]: time="2020-08-25T10:04:01Z" level=error msg="set up rule failed, [-t nat -I DOCKER_OUTPUT -d 127.0.0.11 -p tcp --dport 53 -j DNAT --to-destination 127.0
Aug 25 10:04:01 Debian dockerd[495]: time="2020-08-25T10:04:01Z" level=error msg="set up rule failed, [-t nat -I DOCKER_POSTROUTING -s 127.0.0.11 -p tcp --sport 35151 -j SNAT --to-source :5
Aug 25 10:04:02 Debian dockerd[495]: time="2020-08-25T10:04:02.075876001Z" level=info msg="Loading containers: done."
Aug 25 10:04:02 Debian dockerd[495]: time="2020-08-25T10:04:02.167612978Z" level=info msg="Docker daemon" commit=48a6621 graphdriver(s)=overlay2 version=19.03.12
Aug 25 10:04:02 Debian dockerd[495]: time="2020-08-25T10:04:02.168770022Z" level=info msg="Daemon has completed initialization"
Aug 25 10:04:02 Debian dockerd[495]: time="2020-08-25T10:04:02.328999489Z" level=info msg="API listen on /var/run/docker.sock"
Aug 25 10:04:02 Debian systemd[1]: Started Docker Application Container Engine.

 

Mais rebelote :

 

Citation

dial tcp: lookup database on 127.0.0.11:53: read udp 127.0.0.1:52123->127.0.0.11:53: read: connection refused

 

Partager ce message


Lien à poster
Partager sur d’autres sites

A priori c'est plutôt le serveur DNS hébergé en 127.0.0.11 qui ne répond pas. 

C'est bien de reproduire le cas déjà, tu sais que c'est au boot que ça pose souci. 

 

Juste à titre de test une connexion à la base fonctionne avec la commande que j'ai cité au dessus ? Que donne un 'docker ps'? 

Modifié par Yann73

Partager ce message


Lien à poster
Partager sur d’autres sites

il y a 41 minutes, Yann73 a dit :

A priori c'est plutôt le serveur DNS hébergé en 127.0.0.11 qui ne répond pas. 

C'est bien de reproduire le cas déjà, tu sais que c'est au boot que ça pose souci. 

 

Juste à titre de test une connexion à la base fonctionne avec la commande que j'ai cité au dessus ? Que donne un 'docker ps'? 

docker ps donne

Citation

freebox@Debian:~$ docker ps
CONTAINER ID        IMAGE                        COMMAND                  CREATED             STATUS              PORTS                    NAMES
e4afc581b314        postgres:12                  "docker-entrypoint.s…"   11 hours ago        Up 52 minutes       5432/tcp                 freebox_database_1
82c59b2e2aae        eclipse-mosquitto:1.6        "/docker-entrypoint.…"   11 hours ago        Up 52 minutes       0.0.0.0:1883->1883/tcp   freebox_mosquitto_1
576097a79da8        teslamate/teslamate:latest   "/sbin/tini -- /bin/…"   2 weeks ago         Up 52 minutes       0.0.0.0:4000->4000/tcp   freebox_teslamate_1
b30a3301196a        teslamate/grafana:latest     "/run.sh"                2 weeks ago         Up 52 minutes       0.0.0.0:3000->3000/tcp   freebox_grafana_1

 

Et systemctl status docker donne

Citation

freebox@Debian:~$ systemctl status docker
● docker.service - Docker Application Container Engine
   Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2020-08-25 10:04:02 UTC; 56min ago
     Docs: https://docs.docker.com
 Main PID: 495 (dockerd)
    Tasks: 42
   Memory: 73.9M
   CGroup: /system.slice/docker.service
           ├─495 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
           ├─830 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 3000 -container-ip 172.18.0.2 -container-port 3000
           ├─860 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 4000 -container-ip 172.18.0.4 -container-port 4000
           └─877 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 1883 -container-ip 172.18.0.5 -container-port 1883

Aug 25 10:04:01 Debian dockerd[495]: time="2020-08-25T10:04:01Z" level=error msg="set up rule failed, [-t nat -I DOCKER_OUTPUT -d 127.0.0.11 -p tcp --dport 53 -j DNAT --to-destination 127.0
Aug 25 10:04:01 Debian dockerd[495]: time="2020-08-25T10:04:01Z" level=error msg="set up rule failed, [-t nat -I DOCKER_POSTROUTING -s 127.0.0.11 -p udp --sport 56525 -j SNAT --to-source :5
Aug 25 10:04:01 Debian dockerd[495]: time="2020-08-25T10:04:01Z" level=error msg="set up rule failed, [-t nat -I DOCKER_POSTROUTING -s 127.0.0.11 -p tcp --sport 41291 -j SNAT --to-source :5
Aug 25 10:04:01 Debian dockerd[495]: time="2020-08-25T10:04:01Z" level=error msg="set up rule failed, [-t nat -I DOCKER_OUTPUT -d 127.0.0.11 -p tcp --dport 53 -j DNAT --to-destination 127.0
Aug 25 10:04:01 Debian dockerd[495]: time="2020-08-25T10:04:01Z" level=error msg="set up rule failed, [-t nat -I DOCKER_POSTROUTING -s 127.0.0.11 -p tcp --sport 35151 -j SNAT --to-source :5
Aug 25 10:04:02 Debian dockerd[495]: time="2020-08-25T10:04:02.075876001Z" level=info msg="Loading containers: done."
Aug 25 10:04:02 Debian dockerd[495]: time="2020-08-25T10:04:02.167612978Z" level=info msg="Docker daemon" commit=48a6621 graphdriver(s)=overlay2 version=19.03.12
Aug 25 10:04:02 Debian dockerd[495]: time="2020-08-25T10:04:02.168770022Z" level=info msg="Daemon has completed initialization"
Aug 25 10:04:02 Debian dockerd[495]: time="2020-08-25T10:04:02.328999489Z" level=info msg="API listen on /var/run/docker.sock"
Aug 25 10:04:02 Debian systemd[1]: Started Docker Application Container Engine.

 

 

Partager ce message


Lien à poster
Partager sur d’autres sites

Il y a 2 heures, Yann73 a dit :

A priori c'est plutôt le serveur DNS hébergé en 127.0.0.11 qui ne répond pas. 

C'est bien de reproduire le cas déjà, tu sais que c'est au boot que ça pose souci. 

 

Juste à titre de test une connexion à la base fonctionne avec la commande que j'ai cité au dessus ? Que donne un 'docker ps'? 

Et ce DNS, c'est la Freebox ou c'est un "faux DNS" à l'intérieur de la VM ?

Partager ce message


Lien à poster
Partager sur d’autres sites

Si c'est en 127.0.0 c'est local à ta VM, peu importe le dernier nombre, ça équivaut à 127.0.0.1 (tu peux pinger au pif 127.0.0.xx ça répondra tu verras).

 

J'ai regardé le docker-compose il ne démarre pas de container DNS ou similaire (aucune raison en même temps), donc ça me parait bizarre, pourquoi il chercherait à taper sur un serveur DNS local, peut-être une fausse piste également et quelque chose d'inhérent à docker.

 

Du coup là quand tu fais ton docker ps on voit que les 4 sont bien running, mais ça ne fonctionne pas ? Cette erreur tu la vois où précisément ? Montre voir aussi quand même un "netstat -tulpen" et le résultat de la commande SQL.

Modifié par Yann73

Partager ce message


Lien à poster
Partager sur d’autres sites

il y a 11 minutes, Yann73 a dit :

Si c'est en 127.0.0 c'est local à ta VM, peu importe le dernier nombre, ça équivaut à 127.0.0.1 (tu peux pinger au pif 127.0.0.xx ça répondra tu verras).

 

J'ai regardé le docker-compose il ne démarre pas de container DNS ou similaire (aucune raison en même temps), donc ça me parait bizarre, pourquoi il chercherait à taper sur un serveur DNS local, peut-être une fausse piste également et quelque chose d'inhérent à docker.

 

Du coup là quand tu fais ton docker ps on voit que les 4 sont bien running, mais ça ne fonctionne pas ? Cette erreur tu la vois ou précisément ? Montre voir aussi quand même un "netstat -tulpen" et le résultat de la commande SQL.

L'erreur apparaît comme ça par exemple.

 

Pour le Netstat :

Citation

freebox@Debian:~$ sudo netstat -tulpen
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       User       Inode      PID/Program name
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      0          13564      497/sshd
tcp6       0      0 :::22                   :::*                    LISTEN      0          13566      497/sshd
tcp6       0      0 :::3000                 :::*                    LISTEN      0          16439      830/docker-proxy
tcp6       0      0 :::1883                 :::*                    LISTEN      0          15751      877/docker-proxy
tcp6       0      0 :::4000                 :::*                    LISTEN      0          16642      860/docker-proxy
udp        0      0 0.0.0.0:68              0.0.0.0:*                           0          12563      391/dhclient
udp        0      0 0.0.0.0:68              0.0.0.0:*                           0          11835      346/dhclient
udp        0      0 172.18.0.1:123          0.0.0.0:*                           106        17504      485/ntpd
udp        0      0 192.168.0.99:123        0.0.0.0:*                           0          13532      485/ntpd
udp        0      0 127.0.0.1:123           0.0.0.0:*                           0          13530      485/ntpd
udp        0      0 0.0.0.0:123             0.0.0.0:*                           0          13526      485/ntpd
udp6       0      0 fe80::389b:a9ff:fe0:123 :::*                                106        17518      485/ntpd
udp6       0      0 fe80::f0be:31ff:fe4:123 :::*                                106        17516      485/ntpd
udp6       0      0 fe80::34ea:ecff:fe6:123 :::*                                106        17514      485/ntpd
udp6       0      0 fe80::6ceb:43ff:fe5:123 :::*                                106        17512      485/ntpd
udp6       0      0 fe80::42:ff:feeb:e4:123 :::*                                106        17510      485/ntpd
udp6       0      0 2a01:e34:edc0:6400::123 :::*                                106        17507      485/ntpd
udp6       0      0 fe80::8c13:68ff:fec:123 :::*                                0          13538      485/ntpd
udp6       0      0 ::1:123                 :::*                                0          13534      485/ntpd
udp6       0      0 :::123                  :::*                                0          13523      485/ntpd

 

De quelle commande SQL parles-tu ?

 

Merci pour ton aide !

Sans titre.png

Partager ce message


Lien à poster
Partager sur d’autres sites

Je parle de cette commande qui permet de vérifier si la BDD répond (ne tapes pas les ">" sur les 2ème et 3ème lignes, en gros tu dis à bash qu'il doit attendre un bloc complet sur plusieurs lignes qui va se terminer par ".") :

[yann@docker-server-1 teslamate]$ docker-compose exec -T database psql -U teslamate << .
> select 'toto';
> .

Qui devrait retourner :

 ?column?
----------
 toto
(1 row)

Peux-tu également mettre le contenu de ton docker-compose.yml ici please ? Ca ressemble quand même à une erreur dans la config.

Modifié par Yann73

Partager ce message


Lien à poster
Partager sur d’autres sites

il y a 11 minutes, Yann73 a dit :

Je parle de cette commande qui permet de vérifier si la BDD répond (ne tapes pas les ">" sur les 2ème et 3ème lignes, en gros tu dis à bash qu'il doit attendre un bloc complet sur plusieurs lignes qui va se terminer par ".") :


[yann@docker-server-1 teslamate]$ docker-compose exec -T database psql -U teslamate << .
> select 'toto';
> .

Qui devrait retourner :


 ?column?
----------
 toto
(1 row)

Peux-tu également mettre le contenu de ton docker-compose.yml ici please ? Ca ressemble quand même à une erreur dans la config.

J'ai bien ça :

Citation

freebox@Debian:~$ docker-compose exec -T database psql -U teslamate << .
> select 'toto';
> .
 ?column?
----------
 toto
(1 row)

 

Et voici mon docker-compose.yml

 

Citation

freebox@Debian:~$ cat docker-compose.yml
version: "3"

services:
  teslamate:
    image: teslamate/teslamate:latest
    restart: always
    environment:
      - DATABASE_USER=teslamate
      - DATABASE_PASS=secret
      - DATABASE_NAME=teslamate
      - DATABASE_HOST=database
      - MQTT_HOST=mosquitto
    ports:
      - 4000:4000
    volumes:
      - ./import:/opt/app/import
    cap_drop:
      - all

  database:
    image: postgres:12
    restart: always
    environment:
      - POSTGRES_USER=teslamate
      - POSTGRES_PASSWORD=secret
      - POSTGRES_DB=teslamate
    volumes:
      - teslamate-db:/var/lib/postgresql/data

  grafana:
    image: teslamate/grafana:latest
    restart: always
    environment:
      - DATABASE_USER=teslamate
      - DATABASE_PASS=secret
      - DATABASE_NAME=teslamate
      - DATABASE_HOST=database
    ports:
      - 3000:3000
    volumes:
      - teslamate-grafana-data:/var/lib/grafana

  mosquitto:
    image: eclipse-mosquitto:1.6
    restart: always
    ports:
      - 1883:1883
    volumes:
      - mosquitto-conf:/mosquitto/config
      - mosquitto-data:/mosquitto/data

volumes:
  teslamate-db:
  teslamate-grafana-data:
  mosquitto-conf:
  mosquitto-data:

C'est grave Docteur ?

Partager ce message


Lien à poster
Partager sur d’autres sites

Ok donc ta base semble bien up déjà et le yml semble ok.

 

Si je récapitule :

 

- Si tu lances à la mano avec un docker-compose up ça fonctionne entièrement

- Si tu reboot la VM les containers se lancent mais tu te tapes l'erreur

 

C'est ça ?

 

Tu peux éventuellement essayer de regarder les logs (ça crache pas mal mais t'auras peut-être plus d'infos du coup) :

docker-compose logs -f teslamate

docker-compose logs -f grafana

 

Côté Teslamate d'ailleurs est-ce qu'il accède bien aux données de la BDD où il te sort une erreur également comme sur Grafana ?

Partager ce message


Lien à poster
Partager sur d’autres sites

Ok donc les deux galèrent à accéder à la base.

 

En regardant à nouveau les logs de ton service docker on voit qu'il n'arrive pas à créer les règles firewall, est-ce que tu pourrais faire un "iptables -L -n" :

- Après un start manuel (qui fonctionne donc)

- Après le start auto au boot

 

Concrètement il doit merder sur le NAT avec les containers à cause des règles manquantes du coup ça communique mal.

Modifié par Yann73

Partager ce message


Lien à poster
Partager sur d’autres sites

Il y a 3 heures, Yann73 a dit :

Ok donc les deux galèrent à accéder à la base.

 

En regardant à nouveau les logs de ton service docker on voit qu'il n'arrive pas à créer les règles firewall, est-ce que tu pourrais faire un "iptables -L -n" :

- Après un start manuel (qui fonctionne donc)

- Après le start auto au boot

 

Concrètement il doit merder sur le NAT avec les containers à cause des règles manquantes du coup ça communique mal.

Quand ça ne marche pas :

 

Citation

freebox@Debian:~$ sudo iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy DROP)
target     prot opt source               destination
DOCKER-USER  all  --  0.0.0.0/0            0.0.0.0/0
DOCKER-ISOLATION-STAGE-1  all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
DOCKER     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
DOCKER     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain DOCKER (2 references)
target     prot opt source               destination
ACCEPT     tcp  --  0.0.0.0/0            172.18.0.2           tcp dpt:3000
ACCEPT     tcp  --  0.0.0.0/0            172.18.0.4           tcp dpt:4000
ACCEPT     tcp  --  0.0.0.0/0            172.18.0.5           tcp dpt:1883

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target     prot opt source               destination
DOCKER-ISOLATION-STAGE-2  all  --  0.0.0.0/0            0.0.0.0/0
DOCKER-ISOLATION-STAGE-2  all  --  0.0.0.0/0            0.0.0.0/0
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

Chain DOCKER-ISOLATION-STAGE-2 (2 references)
target     prot opt source               destination
DROP       all  --  0.0.0.0/0            0.0.0.0/0
DROP       all  --  0.0.0.0/0            0.0.0.0/0
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

Chain DOCKER-USER (1 references)
target     prot opt source               destination
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

 

Et après quelques tatonnements pour réparer (pull suivi de up ne marchait plus car j'étais déjà à jour... j'ai réussi avec un --force-recreate.

 

Du coup, maintenant :

 

Citation

freebox@Debian:~$ sudo iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy DROP)
target     prot opt source               destination
DOCKER-USER  all  --  0.0.0.0/0            0.0.0.0/0
DOCKER-ISOLATION-STAGE-1  all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
DOCKER     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
DOCKER     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain DOCKER (2 references)
target     prot opt source               destination
ACCEPT     tcp  --  0.0.0.0/0            172.18.0.2           tcp dpt:1883
ACCEPT     tcp  --  0.0.0.0/0            172.18.0.5           tcp dpt:4000
ACCEPT     tcp  --  0.0.0.0/0            172.18.0.3           tcp dpt:3000

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target     prot opt source               destination
DOCKER-ISOLATION-STAGE-2  all  --  0.0.0.0/0            0.0.0.0/0
DOCKER-ISOLATION-STAGE-2  all  --  0.0.0.0/0            0.0.0.0/0
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

Chain DOCKER-ISOLATION-STAGE-2 (2 references)
target     prot opt source               destination
DROP       all  --  0.0.0.0/0            0.0.0.0/0
DROP       all  --  0.0.0.0/0            0.0.0.0/0
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

Chain DOCKER-USER (1 references)
target     prot opt source               destination
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

 

 

Partager ce message


Lien à poster
Partager sur d’autres sites

De mon côté j'ai aussi eu une coupure de courant pendant que j'étais en trajet vendredi dernier.

 

Teslamate/Grafana était complètement dans les choux ensuite.

J'ai manuellement du relancer mon raspberry en arrivant à domicile quelques heures plus tard pour qu'il retrouve le droit chemin.

Donc je suis curieux de voir si vous trouvez comment bien faire en sorte que tout se lance que ce soit en cas normal (déjà bon) ou en cas de coupure (internet/électricité).

 

Edit :

J'ai reçu un RPi4 hier, j'ai basculé d'un simple déplacement de carte SD vers ce dernier sans soucis. (Ok j'ai également du régler l'IP sur la box pour que ça redirige bien sur lui désormais). 👍🏼

Modifié par J0kers

Partager ce message


Lien à poster
Partager sur d’autres sites

Hormis les IPs qui changent dans la chain DOCKER apparemment les règles sont bien appliquées, étrange tout ça !

 

Dans ton cas @J0kers le reboot a refait marcher le bouzin, donc le démarrage des containers au boot fonctionne au moins :) 

 

@M-ric tu as réussi à regarder un peu les logs ? C'est plus explicite ?

Partager ce message


Lien à poster
Partager sur d’autres sites

il y a 54 minutes, Yann73 a dit :

Hormis les IPs qui changent dans la chain DOCKER apparemment les règles sont bien appliquées, étrange tout ça !

@M-ric tu as réussi à regarder un peu les logs ? C'est plus explicite ?

Je n’ai rien vu de vraiment éclairant mais je passe par Putty pour l’administration et le log ne s’affiche pas dans son intégralité  ; je vais essayer de faire mieux ce soir

Partager ce message


Lien à poster
Partager sur d’autres sites

@Yann73

"Panne non reproduite au sol" : après une coupure "propre" de la VM via l'interface Free puis une coupure sauvage via un reboot de la box, mon Teslamate fonctionne toujours donc en attente de la prochaine panne...

Merci beaucoup pour ton aide !

Partager ce message


Lien à poster
Partager sur d’autres sites

Oh mais je désespère à voir vos beaux graphismes.@bobjouy c'est superbe !
Je au moins 3 Synology en état de marche et pas un sous Intel. En plus pour mon malheur je suis trop nul avec mon pi3 et n'arrive pas à plonger dedans.
Bref, personne connais une astuce pour mettre docker sur un 416 sans passer un licence en informatique ?

Partager ce message


Lien à poster
Partager sur d’autres sites

@bobjouy Pas trop de gouttes de sueurs avant l'arrivée avec 1% ? :) 

Par curiosité la voiture indiquait une arrivée à combien à l'origine ? Avais-tu également vérifié ce qu'estimait un abrp ?

 

@njul Je pense que le plus simple est de t'orienter vers le pi3 quand même, à priori sur les Syno c'est plus la grouille qu'autre chose. Dis nous où tu bloques et ça finira par fonctionner ! ;)

Partager ce message


Lien à poster
Partager sur d’autres sites





×
×
  • Créer...
Automobile Propre

Automobile Propre est un site d'information communautaire qui est dédié à tout ce qui concerne l'automobile et l'environnement. Les thématiques les plus populaires de notre blog auto sont la voiture électrique et les hybrides, mais nous abordons également la voiture GNV / GPL, les auto à l'hydrogène, les apects politiques et environnementaux liés à l'automobile. Les internautes sont invités à réagir aux articles du blog dans les commentaires, mais également dans les différents forums qui sont mis à leur dispositon. Le plus populaire d'entre eux est certainement le forum voiture électrique qui centralise les discussions relatives à l'arrivée de ces nouveaux véhicules. Un lexique centralise les définitions des principaux mots techniques utilisés sur le blog, tandis qu'une base de données des voitures (commercialisées ou non) recense les voitures électriques et hybrides.