LinuxForHealth / connect-r-and-d

Linux For Health Connectors for Inbound Data Processing

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

investigate NameSpace / Handshake for decentralized addressing

tedtanne opened this issue · comments

HSD is an implementation of the Handshake protocol:

https://handshake.org/

github
https://github.com/namebasehq/hsd

me thinks we can use it to secure as well as provide decentralized addressing to LFH instances.

Investigated running the Handshake daemon (hsd) as a part of containerized LinuxForHealth. Implemented hsd as a separate container in LFH with the following docker-compose snippet:

  hsd:
    image: ${LFH_HSD_IMAGE}
    restart: unless-stopped
    networks:
      - main
    volumes:
      - chain:/root/.hsd
    ports:
      - ${LFH_HSD_API_SERVER_PORT}:${LFH_HSD_API_SERVER_PORT}
      - ${LFH_HSD_WALLET_PORT}:${LFH_HSD_WALLET_PORT}
      - ${LFH_HSD_HOST_DNS_PORT}:${LFH_HSD_DNS_PORT}/udp
    command: hsd --rs-host=0.0.0.0 --rs-port=${LFH_HSD_DNS_PORT} --http-host='::' --wallet-http-host='::' --api-key=${LFH_HSD_API_KEY}
volumes:
  chain: {}

and the following env vars:

# Handshake Daemon
# regtest network = 14037, 14039
LFH_HSD_IMAGE=ccorley/hsd:latest
LFH_HSD_API_SERVER_PORT=14037
LFH_HSD_WALLET_PORT=14039
LFH_HSD_HOST_DNS_PORT=53
LFH_HSD_DNS_PORT=5300
LFH_HSD_API_KEY=PASSWORD

This containerized hsd could be used if running an hsd client, such as https://github.com/handshake-org/hnsd in each container as a separate process.

Also investigated running hsd itself as a separate process in each container using a script.
Dockerfile:

# Start LinuxForHealth Connect and supporting services
USER root
CMD ["./services.sh"]

services.sh:

#!/bin/sh
# Start Handshake hsd for distributed DNS in the background
hsd --rs-host=0.0.0.0 --rs-port=${LFH_HSD_DNS_PORT} \
    --http-host='::' --wallet-http-host='::' --api-key=${LFH_HSD_API_KEY} > /var/log/hsd.log 2>&1 &
# Start LinuxForHealth Connect
java -XX:+UseContainerSupport ${JAVA_OPTS} -jar linux-for-health-connect.jar

However, since both approaches require running hsd/hsd client and the original container service, it may be better to run hsd as service started by the OS, as part of the LinuxForHealth Tiny Linux OS work: https://github.com/LinuxForHealth/connect/issues/362

Built hnsd on a Raspberry Pi 3B+ with piCore. Successfully ran hnsd and saw it connect to mainnet. Added hnsd to piCore to boot on startup of the OS, but had trouble getting wifi connected before running hnsd. In the process of tweaking that so that the boot would wait for wifi to connect, I added a parameter to the wifi startup that causes an infinite error to be printed out on boot, ostensibly with no way of recovering. So the next step is to rebuild the piCore image from scratch. Luckily, I have a transcript of all the steps required, but it will still take a bit to get back to this point. We'll plan that into the LFH OS work.

One other takeaway is that it looks like hnsd will work for Handshake DNS without having to have our own Handshake daemon (hsd). That means, if we decide to add hnsd to each LFH container, it should be a much smaller image size increase than adding hsd.

Recommendation: Include hnsd as a part of the LFH OS work.