Perte d'accès via navigateur

#1

Salut

Depuis quelques temps, je perds l’accès à Gladys depuis le navigateur :

  • que ce soit avec gladys.local
  • ou l’ip locale directement

J’ai crû que c’était mon modem 4G qui faisait des siennes mais j’ai toujours un accès ssh via l’ip locale…
Du coup, je fais un sudo reboot et Gladys revient via gladys.local mais seulement quelques temps.

Des idées ?
J’ai croisé un truc sur les certificats https, certbot et tout le tralala, ça pourrait venir de là ?

#2

ça me dit rien. Tu as quoi comme erreur?

#3

Dans le navigateur : ERR_CONNECTION_REFUSED

Dans Gladys, je ne sais pas, faut que je prenne le temps de remonter dans les logs.
J’ai l’impression que mon install part en vrille, j’ai des erreurs NPM à l’install du module CalDAV et j’ai plus de courbes qui s’affichent.

#4

Mmm et si tu ping ton Raspberry Pi ça marche?
Si tu accéde via le port 8080 en HTTP ça te donne quoi?

Ca m’a l’air d’être des problèmes différents.

Le module CalDav c’est possible que certaines dépendances s’installent pas chez toi, à voir avec le développeur du module CalDav pour identifer quelle dépendance à des problèmes… ( tu comprends pourquoi je veux changer ça dans la v4 :stuck_out_tongue: )

Les courbes il va me falloir plus d’informations!

#5
MacBook-Pro-de-Damien:~ dguillot$ ping 192.168.1.123
PING 192.168.1.123 (192.168.1.123): 56 data bytes
64 bytes from 192.168.1.123: icmp_seq=0 ttl=64 time=13.116 ms
64 bytes from 192.168.1.123: icmp_seq=1 ttl=64 time=74.853 ms
64 bytes from 192.168.1.123: icmp_seq=2 ttl=64 time=26.582 ms
64 bytes from 192.168.1.123: icmp_seq=3 ttl=64 time=14.232 ms
64 bytes from 192.168.1.123: icmp_seq=4 ttl=64 time=40.606 ms
64 bytes from 192.168.1.123: icmp_seq=5 ttl=64 time=43.206 ms
64 bytes from 192.168.1.123: icmp_seq=6 ttl=64 time=3.952 ms
^X64 bytes from 192.168.1.123: icmp_seq=7 ttl=64 time=21.189 ms
^C
--- 192.168.1.123 ping statistics ---
8 packets transmitted, 8 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 3.952/29.717/74.853/21.212 ms

Ca marche.
Et avec accès en http sur port 8080 : ça marche.

#6

BOn, du coup, j’ai nettoyé un peu pour voir ce que ça donne.

J’avais sur un nom de domaine (que je n’utilisais plus depuis mon abo sur Gladys Gateway) un certificat https via le tuto sur le forum avec let’s encrypt et certbot.

J’ai tout nettoyé pour repartir sur une base saine sur le https.

J’ai effectué la commande certbot-auto delete dans le répertoire de let’s encrypt, puis j’ai enlevé les lignes dans le fichiers ngynx en rapport avec mon ancien ndd.

J’ai restart ngynx : pas d’avancement dans mon problème.
J’ai reboot le pi : il n’est plus présent sur le réseau… oO

Mauvais manip ?
Ou juste coïncidence de panne matériel ?

En regardant de plus près ma box, j’ai un matos avec une adresse MAC mais sans IP…
J’ai donc branché un câble ethernet et j’ai retrouvé accès à Gladys mais toujours impossible via https://gladys.local

Bref, je suis dans le cambouis jusqu’au cou, si une âme charitable a une idée pour nettoyer tout ça sans mettre plus de cambouis encore… :smiley:

Edit : je pensais à un problème matériel wifi mais en lançant :
sudo iwlist wlan0 scan
Il me détecte bien mon réseau…

#7

J’ai le ème problème depuis le passage à https…
Je relance le script pour y accéder mais c’est pas une solution viable…

#8

Une piste, nginx peut se lancer avant le network manager. La prochaine fois que ça arrive essayez juste de relancer nginx

#9

comment repartir de zero en annulant la commande :

/home/pi/enable-ssl-gladys.sh

??

#10

Salut, une recherche sur internet avec le terme “https nginx” t’aurais sûrement aidé un petit peu à comprendre ce qui ne va pas @jeremy37.

Dans /etc/nginx/sites-enabled tu dois avoir un vhost, poste nous son contenu entre les balises code stp.

De nos jours, désactiver https même en local n’est pas prudent je trouve…

#11

oui je me doute j’ai refais un backup avec une ancienne image. Je m’occupe de refaire les scénarios etc refaire une sauvegarde et je m’y remet :slight_smile:

1 Like