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

[Nicolas80]

Bonjour,

Je voudrais installer un noeud Duniter v1 sur une VM Ubuntu avec 4 cpu arm64/aarch64 et 24 GB ram.

J’ai cherché dans la documentation Duniter (Duniter | Install a Duniter node) et sur ce forum, mais je n’ai pas trouvé de version récente spécifiquement prévue pour arm64.

Version packagée

Actuellement, la seule version packagée que j’ai trouvée est prévue pour arm 32bits: duniter-server-v1.8.5-linux-armv7l.deb (source: Releases · nodes / typescript / duniter · GitLab)

Elle s’installe correctement, mais impossible de terminer une synchronisation; j’ai à chaque fois des problèmes de mémoire avant la fin.

Version Docker

Je remarque que l’on vient de mettre à jour la référence vers la bonne image docker duniter/duniter mais par contre, je n’y vois que des versions amd64; pas de arm64 (Docker)

YunoHost ?

Je dois dire que je n’ai jamais testé YunoHost, mais je n’ai pas trop envie de réinstaller ma VM.

Je vois qu’il serait théoriquement possible d’installer YunoHost via une image docker; du genre domainelibre/yunohost-arm; mais de nouveau, c’est pour du armv7 (32bits) et donc toujours avec les limitations mémoire, …


Je pense que si on peut avoir une ou plusieurs manières bien documentées pour comment installer un noeud Duniter sur ce genre d’architecture arm64; on pourrait potentiellement ajouter beaucoup de noeuds à moindre frais.

Tant qu’Oracle continue à fournir leur Always free resources; n’importe qui peut avoir 1 compte avec 4 cpu arm64, 24GB ram et 200GB disque (pour ceux qui veulent plus d’info : Always Free Resources)

Merci d’avance.

Nicolas.

[Pini]

@Nicolas80

Version Docker

J’ai une image pour arm64 sur DockerHub : pinidh/duniter:dev-arm64.

EDIT: L(image pour arm64 a maintenant le même nom que pour amd64 : pinidh/duniter:dev.

[Nicolas80]

Cool, je vais tester ça.

Est-ce que cette version peut être utilisée pour se connecter aux autres noeuds de “prod” (vu le nom “dev”) ?

[Pini]

Oui. Elle sera identifiée comme une version 1.9.0 par les autres noeuds.

[Nicolas80]

J’ai réussi à l’installer et à faire une synchro jusqu’au bout

Par contre, je pense que j’ai du oublier une partie de configuration car je n’arrive pas à utiliser mon serveur avec l’application cesium

Les infos du serveur:
ip publique: 141.145.210.46
dns: g1.brussels.ovh
nginx redirige le port 10901 vers 443 (avec certificat)

Je me retrouve avec ceci dans l’interface web:

Et la page config réseau:

Et si je teste d’ouvrir dans un browser
https://g1.brussels.ovh
il me renvoie “Upgrade Required”

Alors que si je fais la même chose sur un autre noeud en 1.9.0 - https://duniter.pini.fr
J’obient

{
  "duniter": {
    "software": "duniter",
    "version": "1.9.0",
    "forkWindowSize": 100
  }
}

Une idée de ce que j’ai loupé ou oublié de configurer pour que le serveur fonctionne avec Cesium ?

Et autre question, je ne sais pas si je devrais modifier le nombre de connections actives pour WS2P privé/publique; il m’a rempli la valeur à 10 tout seul…

[Pini]

Ça ne serait pas un souci dans ta conf nginx ? Je n’ai jamais eu cette erreur de mon côté.

[Nicolas80]

De fait, je trouve des posts qui rapportent de genre de soucis comme un problème de configuration de nginx…

Mais je ne comprends pas trop, parceque je semble avoir la config dont parle ces posts (j’avoue que je ne connais pas trop nginx et j’ai copier-coller + adapté un peu)

Ma config actuelle:

map $http_upgrade $connection_upgrade {
 default upgrade;
 '' close;
}

server {
 listen 443 ssl http2;
 listen [::]:443 ssl http2;
 server_name g1.brussels.ovh;

 access_log /var/log/nginx/duniter-access.log;
 error_log /var/log/nginx/duniter-error.log;

    location / {
        proxy_pass http://127.0.0.1:10901;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }

    location /ws2p {
                proxy_pass http://127.0.0.1:10901;
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection $connection_upgrade;
    }
}
 # HTTPS
 ssl_certificate /etc/letsencrypt/live/g1.brussels.ovh/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/g1.brussels.ovh/privkey.pem;
 ssl_protocols TLSv1.2 TLSv1.3;
 ssl_ecdh_curve prime256v1;
 ssl_ciphers EECDH+AESGCM:EECDH+AES;
 ssl_prefer_server_ciphers on;
 resolver 80.67.169.12 80.67.169.40 valid=300s;
 resolver_timeout 5s;
 ssl_session_cache shared:SSL:10m;
 add_header Strict-Transport-Security "max-age=15768000";

 add_header Referrer-Policy "strict-origin-when-cross-origin";

[Pini]

@Nicolas80

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;

Tu peux virer ces lignes du bloc location /.

[Nicolas80]

Même résultat

curl -i https://g1.brussels.ovh
HTTP/2 426 
server: nginx/1.18.0 (Ubuntu)
date: Fri, 07 Apr 2023 15:10:14 GMT
content-type: text/plain
content-length: 16

Upgrade Required

[Pini]

Tu as bien demandé à nginx de recharger la conf ?

nginx -s reload

[Nicolas80]

Oui, j’ai fais plus pour être sur

sudo systemctl reload nginx.service
sudo systemctl stop nginx.service 
sudo systemctl start nginx.service

[Nicolas80]

Est-ce que tu aurais une configuration nginx qui fonctionne pour comparer ?

[Nicolas80]

Je remarque également, que ton serveur (vu le nom je pense que c’est le tiens) a une autre version de nginx : 1.23.3

curl -i https://duniter.pini.fr
HTTP/2 200 
server: nginx/1.23.3
date: Fri, 07 Apr 2023 15:17:02 GMT
content-type: application/json; charset=utf-8
content-length: 99
x-powered-by: Express
access-control-allow-origin: *
etag: W/"63-mHCHCdWxoqjTnMSEi9w7GhE5vmc"
strict-transport-security: max-age=31536000

{
  "duniter": {
    "software": "duniter",
    "version": "1.9.0",
    "forkWindowSize": 100
  }
}

[Pini]

Ma config est générée automatiquement par nginx-proxy. Pas facile à partager.

Tu devrais d’abord tester en ne gardant que location / et en virant tout ce qui concerne l’upgrade, y compris la directive map.

[Nicolas80]

J’ai retiré les lignes en question, et j’ai toujours le même retour “Upgrade Required”

[Pini]

Eh bien je ne sais pas. Désolé.

[Nicolas80]

Sinon, tu aurais des infos quelque part sur comment configurer nginx-proxy comme tu le fais ?

[Pini]

J’utilise un fork perso de nginx-proxy plus acme-companion.

• GitHub - pini-gh/nginx-proxy: Automated nginx proxy for Docker containers using docker-gen
• GitHub - pini-gh/acme-companion: LetsEncrypt companion container for nginx-proxy

[Nicolas80]

@Pini Je voulais regarder pour utiliser les images dockers pour nginx-proxy et je viens de remarquer que mon serveur à planté entre temps :-/

J’utilise ton image pinidh/duniter:dev-arm64; et dans les logs docker, j’ai ceci comme erreur:

2023-04-10T13:04:55+00:00 - warn: WS2P OUT => Document detected 14 times: {"version":10,"currency":"g1","locktime":0,"hash":"31CBD453756FF294847FBA7739C36A3BA9A36AC6FF9A4C5911D3E4CF510AC042","blockstamp":"616962-00000024AF5AD381722E2C8A23BFC7F50C3564B614C60CE1F1E78EA071299AC1","blockstampTime":1681128504,"issuers":["HQvpc5EVTGxjWBF7zsUQR9qgAba3Mn2vNivCLphLQVpS"],"inputs":["180:0:T:9AC71989A03840DFFA4C56E945A944F634DD5251EDC10D0EA3B9573FDACB7717:1"],"outputs":["10:0:SIG(BrgsSYK3xUzDyztGBHmxq69gfNxBfe2UKpxG21oZUBr5)","170:0:SIG(HQvpc5EVTGxjWBF7zsUQR9qgAba3Mn2vNivCLphLQVpS)"],"unlocks":["0:SIG(0)"],"signatures":["Ly+/yuWtN9BMxMw30B1jFa6Rvi3nXZ4CCGkdgaMnom2PS7qmJ0QJ2K4/vGxPSDbzRP+TZXZSlKmHt4hK/SeyBg=="],"comment":"test 17"}
2023-04-10T13:04:55+00:00 - info: WS2P EnFfLNWnonXwxmzipLbbqa1fybSs7xdPoYhmbkMYzR3G: new incoming connection from 172.17.0.1:42896!

<--- Last few GCs --->

[19:0xaaaae1cb78a0] 263675979 ms: Mark-sweep 3821.1 (3961.9) -> 3821.0 (3928.9) MB, 4863.8 / 0.0 ms  (average mu = 0.922, current mu = 0.000) last resort GC in old space requested
[19:0xaaaae1cb78a0] 263680757 ms: Mark-sweep 3821.0 (3928.9) -> 3821.0 (3927.4) MB, 4777.7 / 0.0 ms  (average mu = 0.855, current mu = 0.000) last resort GC in old space requested


<--- JS stacktrace --->

==== JS stack trace =========================================

Security context: 0x00005eb9e6c1 <JSObject>
    0: builtin exit frame: parse(this=0x00005eb919f9 <Object map = 0x43f042a9>,0xfffe461f5cd9 <Very long string[14683]>,0x00005eb919f9 <Object map = 0x43f042a9>)

    1: /* anonymous */ [0xfffe4258c101] [/duniter/app/lib/dal/indexDAL/leveldb/LevelDBTable.js:~80] [pc=0x55787b38](this=0xfffe4258c139 <ReadStream map = 0xfffe2387fd49>,data=0xfffe90543b01 <Object map = 0xffff8fbff8d1>)
    2: emit [0...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory

Comme la machine à plein de mémoire disponible (24GB), est-ce que l’on peut facilement augmenter la quantité autorisée ?

[Pini]

Ça n’a rien avoir avec ton souci, mais entre temps j’ai mis une nouvelle image à disposition : pinidh/duniter:dev : cette référence est multiarch (valable pour amd64 et arm64).

Je n’ai pas de noeud en arm64 pour tester, donc je ne peux que tenter des hypothèses. Sur mon serveur en amd64 qui n’a que 4Go de RAM + 4Go de swap j’arrive à faire tourner deux noeuds duniter en même temps. En revanche au bout de quelques jours ça rame, puis ça plante. J’ai donc mis en place un crontab qui me redémarre mes noeuds tous les jours. Et là ça ronronne.

Ça faisait combien de temps que ton noeud tournait avant qu’il ne plante ainsi ?