Bitmessage/Remote : Différence entre versions

Version actuelle datée du 17 février 2018 à 16:08

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. Ce problème se règle normalement en fixant la variable (non documentée) maxtotalconnections. A priori, il se consomme 10MB/connection, donc maxtotalconnections = 30 serait un bon choix.

• BM n'est pas invulnérable et il y a des attaques
  • donc, pour un usage en remote où il n'y a pas besoin de clés dans keys.dat ... inutile d'en laisser traîner dedans

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é. Un port est l'adresse d'une application sur une machine.
  • 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

Attention cependant à ne pas faire faire à BM des choses qui n'en font pas partie. Par exemple, si on veut des informations sur la machine remote (boot, cpu, ram, etc) peut-être que l'obtention par un code parallèle à BM, mais hors BM est plus indiqué.

• -> paquet psutil

Questions

• Peut-on limiter le nombre de connexions ? (pour limiter la conso de RAM) -> oui, voir maxtotalconnections

• à 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

• Ouverture de port
• Raspberry
• VPS