Problème avec uptime-kuma

[Bruno21]

Bonjour,

Dans Uptime-kuma, j'ai un souci avec les sites hébergés sur le NAS (923+) . Ils apparaissent tous hors ligne avec le message 'certificate has expired'.

Pas de problèmes avec les dockers et les sites externes.

J'ai essayé une autre appli du même genre, statping-ng, et c'est pareil. Le message est un peu plus explicite: HTTP Error Get "https://menu.blabla.ovh": x509: certificate has expired or is not yet valid: current time 2024-02-19T20:02:23Z is after 2019-11-20T15:50:34Z

Le certificat LE du nas a été installé avec le tuto trouvé ici-même (LE, acme et docker). Il est classé A sur ssllabs. DSM est à jour.

 

version: "3.9"
services:
  uptimekuma:
    image: louislam/uptime-kuma
    container_name: Uptime-Kuma
    hostname: uptimekuma
    mem_limit: 3g
    cpu_shares: 1024
    security_opt:
     - no-new-privileges:false
    ports:
     - 3444:3001
    volumes:
     - /volume1/docker/uptimekuma:/app/data:rw
     - /var/run/docker.sock:/var/run/docker.sock
    environment:
      TZ: Europe/Paris
    restart: on-failure:5

 

[Invité]

Bonjour,

Il y a 1 heure, Bruno21 a dit :

Dans Uptime-kuma, j'ai un souci avec les sites hébergés sur le NAS (923+)

C'est récent ? avant cela fonctionnait ? ou cela n'a jamais fonctionné ?

Cela concerne uniquement les sites que tu héberges sur ton Nas ?

Ton script est bon. Quelle autorisation pour ton dossier "uptime-kuma" + propriétaire ?

Modifié le 21 février par morgyann

[Bruno21]

il y a 46 minutes, morgyann a dit :

C'est récent ? avant cela fonctionnait ? ou cela n'a jamais fonctionné ?

Cela concerne uniquement les sites que tu héberges sur ton Nas ?

Ton script est bon. Quelles autorisation pour ton dossier "uptime-kuma" + propriétaire ?

Non, j'ai le 923 depuis un mois, et c'est le 1er docker qui bloque.

drwxrwxrwx+ 1 root root    148 Feb 21 15:19 .
drwxrwxrwx+ 1 root root    536 Feb 21 15:08 ..
-rwxrwxrwx+ 1 root root    417 Feb 21 15:18 docker-compose.yml
drwxrwxrwx+ 1 root root      0 Feb 21 15:19 docker-tls
-rwxr-xr-x  1 root root 233472 Feb 21 15:20 kuma.db
-rwxrwxrwx+ 1 root root  32768 Feb 21 15:23 kuma.db-shm
-rwxrwxrwx+ 1 root root 848752 Feb 21 15:23 kuma.db-wal
drwxrwxrwx+ 1 root root      0 Feb 21 15:19 screenshots
drwxrwxrwx+ 1 root root      0 Feb 21 15:19 upload
bruno@DS923:/volume1/docker/uptime$

drwxrwxrwx+ 1 root  root     148 Feb 21 15:35  uptime
bruno@DS923:/volume1/docker$

dossier uptime crée bruno:users à la main, ainsi que le docker-compose. Modifié en root:root par le sudo docker-compose up -d

Le dossier docker-tls est vide.

[Invité]

Le propriétaire du dossier doit être "root". 

il y a 7 minutes, Bruno21 a dit :

Le dossier docker-tls est vide

J'ai aussi cette app et mon dossier tls est vide aussi.

Relance ton script, si tu es sur Portainer "update et repouse l'image".

[Bruno21]

Recrée dans Portainer, dans Container manager, avec latest / nightly, c'est toujours pareil.

Je vais laisser tomber pour le moment...

Merci de ton aide.

[Invité]

il y a 31 minutes, Bruno21 a dit :

Je vais laisser tomber pour le moment...

S'installe en 2 mn

-> supprime ton dossier et recrée le

-> donne l'autorisation avec le déclencheur de tâche : chown -R 1000:1000 /volumeX/docker/uptimekuma (pour certain script inutile d'utiliser une consolle SSH).

-> Puis vérifie si le propriétaire du dossier est bien root.

-> Et, remet ton script dans Portainer ...

Modifié le 21 février par morgyann

[Bruno21]

Pas mieux.

Il doit y avoir un truc avec le certificat puisque j'ai une erreur similaire avec statping-ng/

Je verrai après le renouvellement.

[Invité]

Il y a 4 heures, Bruno21 a dit :

un truc avec le certificat

Vérifier peut être :

-> Correspondance port local -> NDD et web-socket (nécessaire pour Uptime) - dans ton Proxy inversé

-> Correspondance Sécurité / certificat : Service NDD -> NDD 

Modifié le 22 février par morgyann

[Bruno21]

Je remonte ce sujet sur lequel je bloque toujours.

Apparemment, le nas qui héberge le service voit uniquement le certificat de la livebox.

moi@DS923:~$ echo | openssl s_client -connect kuma.xxxxx.ovh:443 2>/dev/null | openssl x509 -noout -dates -issuer -subject
notBefore=Nov 20 15:50:34 2014 GMT
notAfter=Nov 20 15:50:34 2019 GMT
issuer=C = FR, O = Orange, OU = 0002 380129866, CN = Orange Devices Auth Web CA
subject=C = FR, O = Orange, CN = Livebox V3 G5R0C3

Tandis que depuis toutes les autres machines:

❯ echo | openssl s_client -connect kuma.xxxxx.ovh:443 2>/dev/null | openssl x509 -noout -dates -issuer -subject
notBefore=Jul 10 14:55:12 2024 GMT
notAfter=Oct  8 14:55:11 2024 GMT
issuer=C=US, O=Let's Encrypt, CN=R10
subject=CN=xxxxx.ovh

Et sur Firefox, si je clique sur le cadenas, c'est bien le certificat LE qui est présenté.

[.Shad.]

Que donne un nslookup de kuma.xxx.ovh depuis ton NAS ? et depuis un autre périphérique ? (pour lequel le certificat renvoyé est le bon)

[Bruno21]

C'est identique:

$ nslookup kuma.xxxxx.ovh
Server:		1.1.1.1
Address:	1.1.1.1#53

Non-authoritative answer:
kuma.xxxxx.ovh	canonical name = xxxxx.ovh.
Name:	xxxxx.ovh
Address: 86.235.y.zzz

dans les 2 cas.