Bitmessage/Remote

Comment opérer un noeud BM à distance ?

Installation de bitmessage sur un noeud distant

• un OS linux, Debian, c'est mieux
  • pour une utilisation 100% remote CLI, on peut d'ailleurs prendre un OS minimal, ie sans GUI

• un OS sécurisé (ssh, root, etc) c'est mieux (-> VPS)

• pour minimiser les opérations sur place, essayer de faire le maximum de choses d'avance (ce n'est pas obligatoire hein)
  • install des paquets
  • install de bitmessage
  • 1° lancement, de manière à charger la (parfois lourde) pile des messages et à tester

• si le noeud peut tourner sur une petite machine, peu gourmande c'est bien. eg raspberry raccordé en ethernet
  • avec un raspberry, inclure une clé USB, histoire de ménager la carte micro-SD qui fait office de disque dur
  • le raspberry chauffe un peu (pointes à 70°C), donc prendre un emplacement adéquat, un petit radiateur, etc
  • attention, en 2018, un noeud complet avec une centaine de connections, utilise 1.5GB de RAM (mesuré sur VPS). Un RPI3W n'ayant que 1GB de RAM (et pas entièrement dispo), ça va coincer ! Sans doute du swap sur le "disque dur" ie la petite carte micro-SD qui en tient lieu ... et qui ne va pas faire de vieux os.

Opérations à effectuer sur place

Le noeud doit être raccordé à une IP de préférence fixe/statique.

• de préférence raccordement filaire ethernet si possible (=> avoir un cable RJ45)
• sinon wifi => connaître et entrer les identifiants de la box sur laquelle se raccorder : SSID + motdepasse

Il faut également procéder à l'ouverture du port 8444 pour/vers le noeud. Et cela ne peut se faire que sur le routeur -> Ouverture de port

Pour le contrôle à distance, le sympathique hébergeur du noeud doit communiquer son IP :

• https://www.whatismyip.com/
• http://www.whatsmyip.org/
• https://whatismyipaddress.com/
• http://whatismyip.host/

• une alim électrique avec parafoudre est un plus

Pilotage remote

• si c'est 100% ssh CLI, alors inutile de lancer le desktop, d'envoyer du signal sur la broche HDMI etc
  • https://www.raspberrypi.org/documentation/configuration/config-txt/README.md

• via ssh (un peu sécurisé, c'est mieux) -> Ssh

• bitmessage doit être lancé en mode daemon, sinon il plante (daemon = true dans keys.dat),

• on peut consulter régulièrement l'état du répertoire ~/.config/PyBitmessage

• a priori, même si le port 8444 est ouvert sur le routeur de l'IP hébergeuse, le port reste indiqué fermé tant que BM n'est pas lancé.
  • ping permet eg de savoir si le port 8444 est ouvert ou pas, ie si BM tourne ou pas
  • mais c'est mieux de checker le port via netstat -antp

• netstat -antp donne pas mal d'infos
  • ESTABLISHED = connexion en cours, en train de se faire (et pas connection terminée)

• ps -x pour voir si le process est toujours actif (attention, time est le temps processeur utilisé par le process, pas le temps depuis le lancement)
  • d'après des 1° estimations sur un noeud complet (Z), BM consomme ~50% du temps processeur ... c'est assez considérable).

• /opt/vc/bin/vcgencmd measure_temp mesure température sur raspberry

• Don't change keys.dat while PyBitmessage is running as it may get overwritten. PS

• pour stopper ... je n'ai actuellement pas trouvé mieux que lister les process ps -x et de killer le process python bitmessagemain.py. C'est aussi la méthode recommandée par Peter Surda.

• filezilla est également utile pour rapatrier des fichiers de logs etc

• voir aussi : psutil ,

Monitoring remote automatique

à long terme c'est comme cela qu'il faudrait procéder.

• un script + cron : bash, python, whatever, si ça se trouve il y a déjà des trucs tous faits

• on peut utiliser l'API, elle fonctionne. L'API n'est pas très riche pour le monitoring, mais au moins elle fonctionne.

• on peut également parallèlement faire des choses depuis l'intérieur du code python de BM.
  • on pourrait imaginer qu'une fonction toute prête soit appelée, fonction vide par défaut, mais définissable par l'opérateur du noeud.
  • ou une fonction, activable selon une variable de keys.dat. If enableMonitoring == True monitor()
  • ou intégration dans debug.log

Questions

• à quoi sert singleton.lock ? -> c'est l'id du process, voir ps -x

• comment savoir la couleur de la led en mode daemon ?
  • a priori, netstat répond largement à cette question (nécessite un 2° ssh)
  • ou via l'API

• comment stopper proprement ? kill recommandé par PS himself

• raccordement filaire Pi0 sur box (ie a priori sur USB)
  • quelles boxs ont 1 ou des ports USB ?

Liens

• https://openclassrooms.com/courses/introduction-au-scan-de-ports

Pages connexes

• Bitmessage/Headless
• Ouverture de port
• Raspberry
• VPS