This guide walks through the process of setting up a SOPine64 Clusterboard for use as a Skycoin Miner. This idea was originally presented by Christian Ott's post PINE64 SKYMINER, which outlines the miner hardware and discusses design choices.
This guide is the result of purchasing the parts on Christian's parts list and setting the hardware up as a reasonable server that will run Skywire software.
If you encounter issues / questions / errors while following this guide, let it be known and I'll do my best to assist and/or update the guide.
- Downloading and flashing Operating System
- Configure OS-side networking
- Securing each OS instance
- Installing Skywire
Christian notes that he uses Armbian for his cluster. At the time of writing, I was unable to secure an image of armbian for Pine64 hardware.
Instead, I used an image of ubuntu provided by Pine64. The download and instructions on flashing are found here. A quicklink for the image download can be found here
Since the page includes decent instructions, I will not replicate them here. A general note, however, is that you are trusting that the image provided by Pine64 has not been bundled with malicious code. Whether or not you want to secure a fresh image of ubuntu for ARM is up to you.
Our goals are:
- be able to ssh into each node on the cluster
- assign static local IPs for simplicity in running Skyminer
- ensure server security
- run Skyminer Manager and Nodes
At this point, you have 7 Pine64 compute chips ("Chip"), each with a SD card with the image refernced above flashed. Because each installation on each SD card is identical, each Chip has the same MAC address which is an issue if we want to ssh into each node.
You will need to perform the following steps on each Chip with only ONE Chip installed into the development board at a time. You will also need access to your LAN router to view (and later assign) IP addresses.
Connect ethernet to your development board, power it on with one Chip, and check what IP it is assigned on your router DHCP page. Once you have the IP, ssh into the node with
$ ssh ubuntu@LAN_IP_ADDR
$ sudo apt-get update
$ sudo apt-get install macchanger
$ sudo macchanger -r eth0
Take note of the output MAC address, then edit interfaces
:
$ sudo vim /etc/network/interfaces
Paste the following at the bottom of the file...
auto eth0
iface eth0 inet dhcp
hwaddress ether aa:bb:cc:dd:ee:ff
...replacing aa:bb:cc:dd:ee:ff
with the address output by macchanger
While we're here, it will be easier to manage all the nodes if they have a unique hostname. Lets change it.
$ sudo vim /etc/hostname
$ sudo vim /etc/hosts
Edit the above files by changing the old hostname pine64
to a relevant hostname like pine-master
if its the 'master node', pine-node1
if its the first slave node, etc.
One Node down, six to go. Be sure to only have one Chip installed in the dev board at any time, and be sure to choose unique host names in Step 3.
I also recommend keeping track of MAC addresses and hostnames in a text document for upcoming steps.
Now each node believes it has its own network adapter, even though the development board is sharing a single network card. Plug all the Chips into the dev board and fire it up. Check your router's DHCP page- it should be assigning unique addresses to each node, and list each of the MAC addresses generated before.
You can test sshing into each node now:
$ ssh ubuntu@IP_NODE1
$ ssh ubuntu@IP_NODE2
...
$ ssh ubuntu@IP_NODE7
If you're able to successfully log into each node, congrats! Otherwise, something is amiss in your network configuration- either on LAN/router side, or the OS network-interfaces side. Go back and try to fix the issues before continuing.
Not only is it convienient to have static IPs (so that you can assign aliases to make sshing easy) but it is more or less required to run Skywire automatically.
Go back to your router interface and assign IPs to the 7 MAC addresses you have reassigned. How this is done varies from router to router, so you may need to read up or mess around for a while looking for it. On my DD-WRT router, it is under Services > Static Leases, and requires manual entry of MAC address, hostname and desired IP.
TIP: reserve an entire range for the cluster to make future debugging easy. Map your first node to x.y.z.121, second node to x.y.z.122, etc
After assiging static IPs locally, it may not immediately apply due to existing DHCP leases on the router. You can manually delete the leases if your router supports it.
You can now go back up to Logging In to test that everything still works, and that your shiny new DHCP leases are working as expected.
Now we will do the bare minimum to reduce the liklihood that the nodes are intruded by a 3rd party.
The default password is heinously simple and MUST be changed on each node for the root
and ubuntu
users.
You can do this with the following:
$ sudo passwd
$ sudo passwd ubuntu
The updated password should also be secure, otherwise whats the point?!
Simply update outdated security packages with
$ sudo apt-get update
$ sudo apt-get upgrade
fail2ban is a utility that will help detect abusive/bruteforce logins and will blacklist IPs suspected of doing so.
$ sudo apt-get install fail2ban -y
Another general safety precaution- root is a default user and the easiest account to log into from someone that doesn't know the system they're breaking into.
$ sudo vim /etc/ssh/sshd_config
Change PermitRootLogin X
to PermitRootLogin no
Or if PermitRootLogin
is missing, add it.
Rather an using passwords, log in remotely only using public keys. Once keys are shared, you can disable password logins by
$ sudo vim /etc/ssh/sshd_config
Adding or changing PasswordAuthentication no
. I would test that the keyswap was successful before disabling passwords, however.
Though this step is 'Optional', it is highly recommended.
Learn how to share ssh keys here.
You've made many changes, so go ahead and restart all the nodes. Its even better to do this incrementally (i.e., per node) to reduce the risk of making too many changes and discovering too late that you've mistakenly bungled something (ask my how I know)
At this point you should have a fully functioning system that is secure and able to be logged into locally. If you want to login remotely, outside of your local network, you will need a dedicated IP and a forwarded port (or 7).
To setup Skywire follow this great setup guide from Option 2 (Manual) forward.
Note that the guide indicates to download binaries of armv6l
which is for Raspberry devices. Pine64 is on the Arm64 or armv8
arch. The go binaries for this archiecture can be found here.
To take part in the testnet, the commands for running the Skywire Manager and Node changes. Consult the official release document for details. Be sure to look through the commands and change IP addresses as necessary.
And since you've got a Pine64 based miner, you may want to apply for testnet rewards access with the official whitelisting form.
I've included useful management scripts as a part of this gist that combines tidbits from the Skywire Github and Testnet Installation Guide.
Once saving them to file, be sure to make them executable with
$ chmod +x script_name.bash