Cutting the (ethernet) cable

The MiniPiRack is designed for simple setup and expansion. Just plug in a network cable and power and you’ve got three ready-to-use Linux instances at your ssh-tips. However, in many scenarios, acquiring an active network cable is difficult ask. Most offices and homes these days use primarily WiFi for network access.

Last weekend Kali the Wonder Dog and I created an ansible configuration script that sets the MiniPiRack so that it uses a WiFi network for its main connection instead of a required wired connection. Once the config is complete, the MiniPiRack only requires power, unless of course you are chaining multiple MiniPiRacks together, in which case you’ll still need to connect each MiniPiRack together with an ethernet cable. But the requirement for a hardwire network drop is gone!

To configure the MiniPiRack to use wifi, one of the boards (p1-r1, but let’s call it ‘master’) is configured to run as a gateway, DHCP server and a NAT. On the master, the wifi network interface (wlan0) is enabled with ssid and password set so it’ll happily connect to an existing wifi network. That gives the master (p1-r1) access to the network and (hopefully) Internet.

The ethernet adapter (eth0) on the master is then switched from DHCP to static. Additionally, a DHCP server is started on that adapter and routing rules are set so that any traffic is forwarded back and forth to the wireless adapter. This setup creates two networks: one external and one internal.

WiFi enabled MiniPiRack with an internal NAT

In this configuration, p1-r1 essentially becomes a jump server. To access p2-r1 or p3-r1, 1st log into p1-r1 from your main PC using its wifi IP address. Then, from the same shell prompt, ssh into either p2-r1 or p3-r1. All three can see the outside network and all three can see each other internally. But no one from outside the MiniPiRack internal network can access the internal network without going through p1-r1 first!

Adding more MiniPiRacks just works. All the additional MiniPiRacks are addressable through p2-r1. It’s a private lan built just for the MiniPiRacks!

Now, here’s a fun question. After you’ve enabled the MiniPiRack to use the WiFi and you reboot, how do you find the IP address of the master/p1-r1? If you are lucky and your network supports Avahi service discovery, then it’s likely that ‘p1-r1.local’ will resolve to the correct IP address. (For the record, all the networks I’ve tested this on support Avahi, or a compatible Bonjouir or Zeroconf.)

However, what if p1-r1.local doesn’t resolve? How do you find out what the IP address of p1-r1? The new ansible script helps by enabling the Bluetooth adapter on the master. Once enabled, you can pair the Bluetooth on your laptop using your OS-specific Bluetooth tools.

Pairing a MiniPiRack with OS X over Bluetooth

After that, creating a tty session through Bluetooth gives you full access to the master, just like using a typical ssh terminal session. From there, you can use all the tools you are used to using in a terminal session, like ifconfig to find the IP address of the wlan0 adapter and then you are off to the races. Simple!

Check out the ansible script and all the details on the official MiniPiRack github.

How MiniPiRack Started

MiniPiRack was started out of frustration that I know you and many others have had before. I just needed some servers, VMs, hosts – whatever – to test out some architectural changes or to test some new ideas. I had no idea at the time what a wild ride this would turn into.

My first major WTF moment was around June of 2015 when I was working at a well-known Austin tech firm. I was officially titled a “Technical Architect”, what ever that means. We were in the process, like all growing and future-minded companies are, of scrutinizing and potentially redesigning our stack to deliver better service for our customers with more visibility into operations while (hopefully!) reducing op and support costs.

I had some pretty big and divergent plans that took the current architecture and turned it on it’s ear. But to implement it, I needed servers – lots of them. (Lots is relative these days. For my POC, I could have used about 10.) Unfortunately, and this is absolutely no knock against WPE, getting my own servers was just impossible. I won’t go into the details here but it involved sign-offs, multi-department agreement and collaboration, etc, etc. All the same type of things you’d expect. Eventually, I gave up trying to use “proper channels” and just opened my own AWS account. And that, kids, is how I ended up with a $2,500 AWS bill with no one to blame but myself.

My second major WTF moment was around February of 2016 when I was working at a large multinational networking hardware company. We were doing a massive project that hit all the cloud bingo words: data pipelines, clustering, fault tolerant, highly-available, auto-scaling. It was a huge undertaking. However, servers (VMs in this case) were at a premium. Our minimal deploy took about 15 VMs but for some reason, the company couldn’t find extra VMs to provide the developers a sandbox. We often deployed our test code right into production spaces. Policy was “Don’t deploy anything that will break the pipelines.” Genius.

The company acknowledged that we needed test sandboxes to *cough* test our code before deploying it into the main pipelines. The policy there was to use VMs aka VirtualBox via vagrant. I’ll let you do the easy math of 15 VMs and laptops with a max of 2 gig of memory. For some reason, the management a layer up couldn’t do this same math.

Having learned my lesson with AWS, I pondered how to build my own lab. I could buy a bunch of cheap PCs and routers, install Linux, etc. Painful. Then I though of the Raspberry Pi. Yes, it was ARM-based but it didn’t take long to find that nearly everything I needed was either:

A) Interpreted
B) ARM compatible or available
C) Compilable

I didn’t need speed. I only needed deployability and data deliverability. I didn’t even need huge memory because all the components had reasonably low memory requirements as long as throughput expectations were kept low. The Raspberry Pis just might work!

I had a solution! Maybe. I’ll just get a stack of Raspberry Pis up and running. Surely it can’t be that complicated….