Aide pour installation noeud Duniter v1 sur une VM Ubuntu arm64/aarch64 (Oracle Cloud Always free tier)

Nicolas80 · 26 April 2023 11:30

J’avais démarré le docker le 7/4 on dirait, donc ça à tenu à peu près 3 jours.

Est-ce qu’on ne sait pas facilement adapter la variable d’environnement pour la mémoire autorisée pour NodeJS ?

Normalement, c’est cette variable-ci… par contre, je ne sais pas comment le configurer dans le docker-compose ou s’il faut recréer une image ou …

export NODE_OPTIONS=--max-old-space-size=8192

Pini · 26 April 2023 11:37

La synchro passe avec 4Go. En mode run on ne devrait jamais avoir besoin de plus 2Go. Positionner une limite à 8Go sans redémarrage planifié ne va que repousser le pb. Je me permets d’insister sur l’importance de redémarrer quotidiennement car il y a manifestement des fuites mémoires.

Nicolas80 · 26 April 2023 12:30

J’ai tout de même adapté pour tester, mais il semblerait que la configuration mémoire est hardcodée (en tout cas pour le processus que je vois tourner pour le moment, pendant la synchro):

node --max-old-space-size=4096 bin/duniter_js --home /var/lib/duniter --loglevel info direct_webstart --webmhost 0.0.0.0

Je vais voir pour prévoir un redémarrage du coup

J’imagine qu’un

docker compose -f /path/to/docker-compose.yml restart

Sera suffisant ?

Pini · 26 April 2023 14:19

Oui.

Et je t’invite à mettre l’image à jour (prendre pinidh/duniter:dev qui est maintenant valide à la fois pour amd64 et arm64) car il y a eu un bug corrigé récemment pour éviter une corruption de la base de donnée sur ce type de manip.

Nicolas80 · 26 April 2023 18:20

@Pini, j’ai réussi à faire une installation nginxproxy/nginx-proxy + nginxproxy/acme-companion (j’ai pris les repos de base, car ils ont des arm64 à jour)

J’ai réussi à faire un test en démarrant un autre docker-compose faisant tourner un petit serveur http python sur port 8080; qui se fait automatiquement forward sur https (port 443) avec le certificat correct.

Par contre, je pense que je dois modifier ma configuration pour le serveur Duniter, car je n’arrive pas à faire de même (pour le port 10901 - est-ce que ça devrais être un autre port ?)

Et quelle partie de configuration doit être remplie dans la page Paramètres>Réseau pour que mon serveur devienne utilisable depuis les clients cesium ?

Pour le moment, j’ai rempli ceci:

Enable WS2P Private Access - coché et valeurs par défaut
Enable WS2P Public Access - coché
- UPnP - décoché
  - private(computer) : l’ip docker de duniter
  - public(remote host) : g1.brussels.ovh
  - private port : 10901
  - public port : 443
  - WebSocket web path : (vide)
Configuration.create_network.bma (non coché)

Pour info; j’ajoute également mon docker-compose.yml pour duniter:

version: "3.8"

services:
  duniter:
    image: pinidh/duniter:dev
    platform: linux/arm64/v8
    container_name: duniter
    restart: unless-stopped
    environment:
      - VIRTUAL_HOST=g1.brussels.ovh
      - VIRTUAL_PORT=10901
      - LETSENCRYPT_HOST=g1.brussels.ovh
      - LETSENCRYPT_EMAIL=monemail@protonmail.com
    ports:
      - 9220:9220
      - 20901:20901
      - 10901:10901
    expose:
      - "10901"
    volumes:
      - duniter_etc:/etc/duniter
      - duniter_data:/var/lib/duniter

volumes:
  duniter_etc: {}
  duniter_data: {}

networks:
  default:
    name: nginx-proxy
    external: true

Nicolas80 · 26 April 2023 22:22

J’ai adapté la configuration réseau comme ceci et redémarré le serveur et cela semble mieux…
J’ai maintenant bien le port 10901 qui répond, et qui est également disponible juste en https (port 443)

Enable WS2P Private Access - coché et valeurs par défaut
Enable WS2P Public Access - coché
- UPnP - décoché
  - private(computer) : l’ip docker de duniter
  - public(remote host) : g1.brussels.ovh
  - private port : 20901
  - public port : 20901
  - WebSocket web path : (vide)
Configuration.create_network.bma - coché
- network.ipv6: none
- network.ipv4
  - local : l’ip docker de duniter
  - remote : none (aucune valeur correcte dans la liste disponible)
- network.port
  - lport : 10901
  - rport : 10901
- network.dns
  - dns : g1.brussels.ovh

g1.brussels.ovh

Est-ce que quelqu’un peut confirmer si cela semble correct ?
Est-ce que je n’ai pas mélanger des ports ?
Est-ce que je devrais mettre 443 à la place du dernier “rport” ou “public port” de WS2P Public ?

Pini · 27 April 2023 07:41

Attention : l’objet de mon fork est de permettre l’utilisation de plusieurs ports différents sur le même conteneur, ce que ne permet pas encore la version upstream. Tout le problème est là…

Nicolas80 · 27 April 2023 09:47

Ah ok, par contre, je n’ai pas compris comment on peut le configurer…

Pour Duniter, j’imagine que l’idée est donc de pouvoir mapper les ports pour WS2P & BMA tous les 2 vers 443

Un exemple de ce que je pourrais vouloir configurer du coup

BMA
- DNS : g1.brussels.ovh
- PORT : 10901
WS2P
- DNS : g1.ws2p.brussels.ovh
- PORT : 20901

Par contre, je ne comprends pas comment on peut configurer ce mapping là dans ta version de acme-companion

J’imagine que ce serait avec “DNS mode challenge” ? Mais j’avoue que je ne connais pas du tout comment ça fonctionne.

Pini · 27 April 2023 11:11

Sur le volet acme-companion

Pour ma part j’utilise un wildcard certificate qui couvre *.pini.fr, car à un moment j’ai trouvé ça plus “élégant”. Mais ce n’est pas une obligation.

Voici la conf type qui en découle :

VIRTUAL_HOST: "subdomain.example.org"
VIRTUAL_PORT: "<port_kivabien>"
CERT_NAME: "example.org"

Sans wildcard certificate ça donnerait :

VIRTUAL_HOST: "subdomain.example.org"
VIRTUAL_PORT: "<port_kivabien>"
LETSENCRYPT_HOST: "subdomain.example.org"

Sur le volet nginx-proxy

La conf multiport d’un noeud duniter v1 est typiquement :

VIRTUAL_HOST: "duniter.example.org"
VIRTUAL_PORT: "10901,20901:/ws2p,30901:/gva/playground"

Pour ma part j’utilise à la place :

VIRTUAL_HOST: "duniter.example.org"
VIRTUAL_PORT: "9220:~ ^/(admin|fonts?|images|webmin)/,10901,20901:/ws2p,30901:/gva/playground"

Mais attention, dans ce cas l’interface d’administration est ouverte à tout le monde ! Je verrouille ça avec la mise en place d’une authentification par certificat (configuration dans un fichier include dans le volume vhost.d).

Nicolas80 · 27 April 2023 11:58

Ha, sympa, je ne savais pas qu’on pouvait mapper sur le même dns, en précisant les path pour certains ports

Du coup, cette gestion des ports est ajouitée dans ta version de nginx-proxy, je vois maintenant la section Multiport Syntax (peut-être que tu devrais mentionner ce qui est ajouté dans le début du README de pini-gh/nginx-proxy, parceque j’avais cru qu’il n’y avait pas de différence avec la version de base )

J’ai vu sur ta version récente de duniter qu’il y a effectivement ce port 30901 en plus exposé, mais par contre, je ne vois pas de configuration associée dans la page admin Paramètres>Réseau…

A quoi sert ce port du coup ?

Nicolas80 · 27 April 2023 12:02

Pour la page d’admin, je me contente de garder le port non exposé à l’extérieur, et faire une redirection temporaire de port en effectuant une connection SSH sur mon serveur.

Pini · 27 April 2023 12:19

C’est pour l’interface GVA. Ce n’est pas obligatoire.

Nicolas80 · 27 April 2023 17:37

@Pini Je viens de tester avec tes containers nginx, en gardant la même configuration simple de redirection d’un seul port (10901) pour duniter (le même docker-compose.yml que j’avais mis plus haut et qui fonctionne avec les containers nginx de base)

J’ai des erreurs dans nginx & acme-companion quand duniter démarre :-/

Mon docker-compose pour nginx-proxy & acme-companion:

version: '3.5'

services:
  reverse-proxy:
    image: pinidh/nginx-proxy:alpine-latest
    platform: linux/arm64/v8
    container_name: reverse-proxy
    restart: always
    ports:
      - "80:80"
      - "443:443"
    #environment:
      # Uncomment to enable multiple nginx-proxy instances
      # e.g. to use with docker-compose-testing.yml
      #- HTTPS_PASSTHROUGH_PORT=444
    labels:
    - reverse-proxy.nginx-proxy=true
    volumes:
      - vhost:/etc/nginx/vhost.d:ro
      - html:/usr/share/nginx/html
      - dhparam:/etc/nginx/dhparam
      - certs:/etc/nginx/certs:ro
      - /var/run/docker.sock:/tmp/docker.sock:ro

  letsencrypt:
    image: pinidh/acme-companion:latest
    platform: linux/arm64/v8
    container_name: letsencrypt
    restart: always
    depends_on:
      - reverse-proxy
    environment:
      - DEFAULT_EMAIL=admin@example.com
      - NGINX_PROXY_CONTAINER_LABEL=reverse-proxy.nginx-proxy
    volumes:
      - acme:/etc/acme.sh
      - html:/usr/share/nginx/html
      - certs:/etc/nginx/certs:rw
      - /var/run/docker.sock:/var/run/docker.sock:ro

volumes:
  vhost:
  acme:
  html:
  dhparam:
  certs:


networks:
  default:
    name: nginx-proxy
    external: true

Logs pinidh/acme-companion:latest

2023/04/27 17:20:41 Received event start for container a692c5daf75e
2023/04/27 17:20:46 Debounce minTimer fired
2023/04/27 17:20:46 Generated '/app/letsencrypt_service_data' from 3 containers
2023/04/27 17:20:46 Running '/app/signal_le_service'
Warning: /etc/nginx/conf.d not mounted; skipping standalone configuration
[Thu Apr 27 17:20:48 UTC 2023] Create account key ok.
[Thu Apr 27 17:20:48 UTC 2023] Registering account: https://acme-v02.api.letsencrypt.org/directory
[Thu Apr 27 17:20:49 UTC 2023] Registered
[Thu Apr 27 17:20:49 UTC 2023] ACCOUNT_THUMBPRINT='KvwmFxsFvgJU0s42dGYfFEsRDtUJB9fB4u2hihxxxxx'
Creating/renewal g1.brussels.ovh certificates... (g1.brussels.ovh)
[Thu Apr 27 17:20:50 UTC 2023] Using CA: https://acme-v02.api.letsencrypt.org/directory
[Thu Apr 27 17:20:50 UTC 2023] Creating domain key
[Thu Apr 27 17:20:53 UTC 2023] The domain key is here: /etc/acme.sh/myemail@protonmail.com/g1.brussels.ovh/g1.brussels.ovh.key
[Thu Apr 27 17:20:53 UTC 2023] Single domain='g1.brussels.ovh'
[Thu Apr 27 17:20:53 UTC 2023] Getting domain auth token for each domain
[Thu Apr 27 17:20:55 UTC 2023] Getting webroot for domain='g1.brussels.ovh'
[Thu Apr 27 17:20:55 UTC 2023] Verifying: g1.brussels.ovh
[Thu Apr 27 17:20:58 UTC 2023] g1.brussels.ovh:Verify error:141.145.210.46: Invalid response from http://g1.brussels.ovh/.well-known/acme-challenge/0l_QG08joLgwt8sJ5beWxRIRbXcEiaNTwVwbYzXl-vs: 404
[Thu Apr 27 17:20:58 UTC 2023] Please check log file for more details: /dev/null
Sleep for 3600s

Logs pinidh/nginx-proxy:alpine-latest

dockergen.1 | 2023/04/27 17:20:41 Received event start for container a692c5daf75e
dockergen.1 | 2023/04/27 17:20:41 Generated '/etc/nginx/conf.d/default.conf' from 3 containers
dockergen.1 | 2023/04/27 17:20:41 Running 'nginx -s reload'
dockergen.1 | 2023/04/27 17:20:41 Contents of /etc/nginx/nginx-stream.conf did not change. Skipping notification 'nginx -s reload'
nginx.1     | 2023/04/27 17:20:41 [notice] 54#54: signal 1 (SIGHUP) received from 68, reconfiguring
nginx.1     | 2023/04/27 17:20:41 [notice] 54#54: reconfiguring
nginx.1     | 2023/04/27 17:20:41 [notice] 54#54: using the "epoll" event method
nginx.1     | 2023/04/27 17:20:41 [notice] 54#54: start worker processes
nginx.1     | 2023/04/27 17:20:41 [notice] 54#54: start worker process 69
nginx.1     | 2023/04/27 17:20:41 [notice] 54#54: start worker process 70
nginx.1     | 2023/04/27 17:20:41 [notice] 54#54: start worker process 71
nginx.1     | 2023/04/27 17:20:41 [notice] 54#54: start worker process 72
nginx.1     | 2023/04/27 17:20:42 [notice] 61#61: gracefully shutting down
nginx.1     | 2023/04/27 17:20:42 [notice] 59#59: gracefully shutting down
nginx.1     | 2023/04/27 17:20:42 [notice] 60#60: gracefully shutting down
nginx.1     | 2023/04/27 17:20:42 [notice] 61#61: exiting
nginx.1     | 2023/04/27 17:20:42 [notice] 59#59: exiting
nginx.1     | 2023/04/27 17:20:42 [notice] 60#60: exiting
nginx.1     | 2023/04/27 17:20:42 [notice] 61#61: exit
nginx.1     | 2023/04/27 17:20:42 [notice] 59#59: exit
nginx.1     | 2023/04/27 17:20:42 [notice] 60#60: exit
nginx.1     | 2023/04/27 17:20:42 [notice] 62#62: gracefully shutting down
nginx.1     | 2023/04/27 17:20:42 [notice] 62#62: exiting
nginx.1     | 2023/04/27 17:20:42 [notice] 62#62: exit
nginx.1     | 2023/04/27 17:20:42 [notice] 54#54: signal 17 (SIGCHLD) received from 60
nginx.1     | 2023/04/27 17:20:42 [notice] 54#54: worker process 60 exited with code 0
nginx.1     | 2023/04/27 17:20:42 [notice] 54#54: signal 29 (SIGIO) received
nginx.1     | 2023/04/27 17:20:42 [notice] 54#54: signal 17 (SIGCHLD) received from 59
nginx.1     | 2023/04/27 17:20:42 [notice] 54#54: worker process 59 exited with code 0
nginx.1     | 2023/04/27 17:20:42 [notice] 54#54: signal 29 (SIGIO) received
nginx.1     | 2023/04/27 17:20:42 [notice] 54#54: signal 17 (SIGCHLD) received from 61
nginx.1     | 2023/04/27 17:20:42 [notice] 54#54: worker process 61 exited with code 0
nginx.1     | 2023/04/27 17:20:42 [notice] 54#54: signal 29 (SIGIO) received
nginx.1     | 2023/04/27 17:20:42 [notice] 54#54: signal 17 (SIGCHLD) received from 62
nginx.1     | 2023/04/27 17:20:42 [notice] 54#54: worker process 62 exited with code 0
nginx.1     | 2023/04/27 17:20:42 [notice] 54#54: signal 29 (SIGIO) received
nginx.1     | g1.brussels.ovh 3.134.76.249 - - [27/Apr/2023:17:20:56 +0000] "GET /.well-known/acme-challenge/0l_QG08joLgwt8sJ5beWxRIRbXcEiaNTwVwbYzXl-vs HTTP/1.1" 404 209 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)" "172.24.0.4:10901"
nginx.1     | g1.brussels.ovh 23.178.112.203 - - [27/Apr/2023:17:20:56 +0000] "GET /.well-known/acme-challenge/0l_QG08joLgwt8sJ5beWxRIRbXcEiaNTwVwbYzXl-vs HTTP/1.1" 404 209 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)" "172.24.0.4:10901"
nginx.1     | g1.brussels.ovh 54.202.80.79 - - [27/Apr/2023:17:20:56 +0000] "GET /.well-known/acme-challenge/0l_QG08joLgwt8sJ5beWxRIRbXcEiaNTwVwbYzXl-vs HTTP/1.1" 404 209 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)" "172.24.0.4:10901"

Est-ce que je devrais modifier la configuration quelque part quand j’utilise tes versions ?

Nicolas80 · 27 April 2023 18:09

Je viens de d’activer le debug pour acme-companion pour tenter d’avoir plus d’infos (mais ça fais beaucoup plus de logs )

acme-companion_debutLogs.txt (69,4 Ko)

Pini · 27 April 2023 18:10

Tout d’abord tant que ta config n’est pas opérationnelle, il faut que tu définisses LETSENCRYPT_TEST=true. Sinon si ça plante trop tu vas être blaklisté pendant une semaine chez letsencrypt.org.

Ensuite après lecture en diagonale de ce que tu as posté comme logs ça ne me parle pas plus que ça.

J’ai de la dispo demain en journée. Je te propose de se caler un créneau pour qu’on regarde ensemble via un partage de terminal tmate (tmate.io). Qu’est-ce qui t’arrange ?