[armv7] Duniter-v2s fonctionne sur mon raspberry pi 4 (binaire disponible)

Certains ont dû exploser de joie en lisant le titre, je vous rassure vous ne rêvez pas, non nous ne somme pas le 1er avril (je vous ai vu regarder la date :stuck_out_tongue: ).

Bon, trêve de plaisanterie, pourquoi me suit finalement penché là-dessus:

Dans le cadre du débuggage de la ĞDev, j’ai eu besoin d’intégrer try-runtime en urgence, mais try-runtime est cassé dans la version de substrate qu’on utilise (on est sur la version de février, ça a été corrigé depuis). J’ai donc cherry-pick le correctif de parity sur notre fork du substrate, que j’ai dû adapter un peu car c’était basé sur un code plus récent, et dans cette tache j’ai dû gérer des histoires de dépendances optionnelles liées à wasmtime.

Je me suis alors souvenu que @tuxmain m’avais dit aux RML16 que le problème avec ARM venait plus de wasmtime (un interpréteur wasm utilisé pas substrate) que de substrate lui-même.

En travaillant sur try-runtime je ne suis rendu compte que wasmtime est optionnel, si on ne l’inclut pas, substrate utilise wasmi (un autre interpréteur wasm, qui lui conpile pour armv7).
Je me suis alors dit, c’est bizarre que @tuxmain est bloqué là-dessus, puisque wasmtime n’est normalement pas inclus si on compile pour une target qu’il ne supporte pas.

Ça m’a donné envie de re-regarder, j’ai tapé « substrate cross compile arm » dans mon moteur de recherche, et je suis tombé sur ce gist, créé par un dev de parity: Substrate Raspberry PI cross-compile build · GitHub

J’ai adapté ce gist à notre cas (on a besoin d’une version bien spécifique de rust), et ça à juste marché du premier coup :smiley:

J’ai donc testé mon binaire fraichement cross compilé sur mon raspberry pi 4… et erreur de GLIBC, mon rapsbian buster est trop vieux :stuck_out_tongue:

J’ai upgade sur bulleyes, mais mon raspi ne voulait plus démarrer :confused:
Le lendemain matin, ja’i fait une nouvelle install fraiche de bulleyes sur une autre carte SD formatée, et cetet fois mon rpi4 boot de nouveau !!

Je reteste donc le binaire de duniter-v2s, et à ma grande stupéfaction, ça semble fonctionner.
Depuis ce midi j’ai donc un nœud ĞDev mirroir sur mon rpi4 (pas exposé sur internet par contre, et c’est un nœud temporaire monté dans /dev/shm).

Pour ceux qui veulent tester, le binaire est disponible dans les release notes de duniter-v2S v0.1.0:

Svp ne testez que en nœud miroir pour le moment, et faites-moi part de vos retours :slight_smile:

Et voici les instructions de cross-compilation:


Attention: parity ne fournit pas de support officiel pour armv7, ni aarch64, donc ça peut très bien ne plus fonctionner dans de futures versions de subtrate.

Je ne peux pas m’engager à garantir la maintenante du support de armv7 dans la durée, mais on peut utiliser duniter-v2s sur armv7 tant que ça juste marche sans effort particulier de maintenance de notre part.

Gardez dont en tête qu’il est possible que l’on ne puisse plus utiliser duniter-v2s sur arm à l’avenir !

En tout cas tant que ça marche, je suis ok pour qu’on essaye de baser nos benchmarks des poids sur un raspberry pi 4 avec 4 Go de RAM et SSD usb3 (parce que c’est ce que j’ai).

Par contre, j’ai encone besoin d’être rassuré sur la capacité à s’en servir comme noeud authorité créant des blocs. Il faut aussi que je creuse ce qui ça donne en termes de monitoring, je me demande par exemple si ma stack prometheus/grafana est déployable sur un rpi :thinking:
Pour limiter les downtime, il faudrait avoir deux rpi, dont l’un contenant un backup du keystore de l’autre, et un sytème automatique qui injecte les sessions keys dans le 2ème rpi si le 1er ne répond plus.

Bref, il y a du boulot pour vérifier l’éventuelle viabilité des raspberry pour la production des blocs.

6 « J'aime »

De toute façon on peut pas goOnline() sans toi pour l’instant :wink:

Mais bonne nouvelle vu que le RPi est assez répandu dans la communauté G1, plusieurs personnes vont pouvoir faire tourner les benchmarks.

à terme un noyau rust sans autre systeme d’ exploitation je dirais un serveur oxydé natif sans m.à.j pour optimiser le déploiement arm

J’ai pu le compiler directement sur mon Pi, sans Docker ! (ce n’est pas si long que ça finalement)

cargo +nightly-2021-11-12-armv7-unknown-linux-gnueabihf install --git https://github.com/alexcrichton/wasm-gc --force
cargo build --target=armv7-unknown-linux-gnueabihf --release

J’essaie de le faire tourner…

Edit: ça sync. Je ferai ce soir la config Apache et tout.

Edit: il est synchro ! Par contre je n’arrive pas encore à faire marcher la config ws avec Apache.

5 « J'aime »

Passe à nginx ce sera bien plus simple, y a une config d’exemple dans la doc: docs/user/rpc.md · master · nodes / rust / Duniter v2S · GitLab

1 « J'aime »

Ça marche, il fallait juste ouvrir les ports dans le pare-feu de la box. (je suis rentré chez moi hier soir)

  • http://txmn.tk:5558/http
  • ws://txmn.tk:5558/ws
  • https://txmn.tk:5559/http
  • wss://txmn.tk:5559/ws

Maintenant j’essaie de terminer la config pour pouvoir être validateur.

Config Apache
<VirtualHost *:5558 [::]:5558>
	ServerName txmn.tk
	ServerAdmin t@txmn.tk
	DocumentRoot /var/www/none
	Protocols h2 http/1.1	

	RewriteEngine On
        RewriteCond %{HTTP:Upgrade} websocket [NC]
        RewriteRule /ws ws://127.0.0.1:9944/ [P,L]

	ProxyPreserveHost Off
	ProxyRequests Off
	ProxyTimeout 600
	
	<Location /http>
		ProxyPass http://127.0.0.1:9933/
	</Location>
	
	<Location /ws>
		ProxyPass ws://127.0.0.1:9944/
	</Location>
	
	ErrorLog ${APACHE_LOG_DIR}/duniter-gdev.error.log
	CustomLog ${APACHE_LOG_DIR}/duniter-gdev.access.log common env=!dontlog
</VirtualHost>

<IfModule mod_ssl.c>
	<VirtualHost *:5559 [::]:5559>
		ServerName txmn.tk
		ServerAdmin t@txmn.tk
		DocumentRoot /var/www/none
		
		SSLEngine on
		SSLCertificateFile /etc/letsencrypt/live/txmn.tk-0001/fullchain.pem
		SSLCertificateKeyFile /etc/letsencrypt/live/txmn.tk-0001/privkey.pem
		
		ProxyPreserveHost Off
		ProxyRequests Off
		ProxyTimeout 600
		
		<Location /http>
			ProxyPass http://127.0.0.1:9933/
		</Location>
		
		<Location /ws>
			ProxyPass ws://127.0.0.1:9944/
		</Location>
		
		ErrorLog ${APACHE_LOG_DIR}/duniter-gdev.error.log
		CustomLog ${APACHE_LOG_DIR}/duniter-gdev.access.log common env=!dontlog
	</VirtualHost>
</IfModule>
1 « J'aime »

@tuxmain tu ne peux pas être validateur et avoir une API RPC publique sur le même nœud. Il te faut 2 machines différentes, une qui fournit une API RPC publique pour les wallet, et un autre en mode validateur.

EDIT: tu peux aussi être validateur seul et ne pas fournir de endpoint RPC public, ça n’a rien d’obligatoire,
mais si tu veux le faire ça doit être avec une machine dédiée.

Un nœud validateur ne doit pas utiliser ses ressources pour répondre aux requêtes des wallet, ça peut -être très dangereux, encore plus pour une machine proche de la machine de référence. Il ya un risque de ne pas pouvoir exécuter les blocs assez vite, et donc de ne pas pouvoir produire des blocs quand c’est ton tour.

Aussi, il faut que tu configures correctement le endpoint p2p de ton nœud validateur avec l’option --public-addr, et que tu nous communiques ce endpoint, c’est lui que je testerai quand ton nœud validateur sera prêt :slight_smile:

1 « J'aime »