Parallel threading

With a goal of improving generic security plus adding flexibility, I am trying to modify my self-hosting set up



by shifting to a multi-box arrangement. Since I cannot afford to build a traditional server farm, I figured I would try to set up a couple SBC as the hardware – they are relatively inexpensive, relatively low-energy cost, and they are small.

There are now many varieties of SBC available marketed as ‘development boards’ for rapid prototyping of ideas for embedded computing. If you want to create a proof-of-concept of an electrical device which could be improved with the application of computing, these are your main tools.

But just because it is available, does not mean

with a reverse-proxy, which should allow me to distribute the web applications to a number of different machines inside my local area network. This should have several benefits:

    • Obscurity – the reverse proxy can hide the origin server, which might be in the LAN or a VPS/cloud server/hosted elsewhere
    • Application firewall, though I need to get beyond the recipe approach.
    • Load balancing – which has never been a problem so far but, you never know!
    • Caching, depending on the specific setup, can be a huge boon to web acceleration.
    • Compression – ditto.

The test, of course, is getting it up and running.

With my first RPi up and running a headless version of Raspbian I was able to begin experimenting. Nginx is the most-popular FLOSS server to use for reverse proxy work, and it installed flawlessly in this Debian-based arm OS.

Like most web servers, nginx is simple but infinitely configurable, which is where it becomes complex.  Also, it is documented mostly by people who are experts in its use for equally expert sysdmin/devops: nearly unintelligible formal Geek language, impossible for the average layperson to decipher.

For example, it took me a week to discover that, in a reverse proxy, the proxy manages the security certificates while the upstream server does nothing about security. This critical detail was not found in any tutorial, but extracted from an expert – and it took two questions to get the answer clearly.

However, testing this became an issue. Sticking the reverse proxy between the existing server and the internet fails. But I do not have a usable device to wipe and install a vanilla web server.

the computer is suitable to every task. Many of these devices are specialized controllers, unable to fill the rôle of a general computer.

Others which are more generalist in design use chips too slow, too under-powered, or they lack networking circuitry  to manage modern web server demands.

But a couple seem admirably suited to the task, such as the odroid and the Raspberry Pi. Others are more borderline, but which have other benefits, like the BeagleBone Black whose open hardware is libré, but slower.

it is really available.

Last Friday, August 23rd, I ordered a Raspberry Pi 3 B+, a wonderful little device which should handle the load. The seller informed me they would get back to me within 3 business days with the shipping information.

It is now the next weekend, which is a long holiday weekend, which is why I made sure my order could be filled and shipped well in advance. It was not. I have heard nothing from the seller. So the weekend I had set aside for this task is … not productive.

But, I had one Raspberry Pi in hand, and an order for a BBB turned around surprisingly quickly, so I now had two devices with which to experiment.

Unfortunately, they are rather different, physically. The RPi is small, but the BBB is dramatically smaller. The latter is actually specifically designed to use the tin of Altoids Curiously Strong Mints as its enclosure. The corners are radiused appropriately, the height is perfect as long as no expansion circuit boards need to be accommodated.

The RPi instead needs an enclosure designed to suit, rather than a found object. Further, the RPi is expected to be overclocked for performance, and needs both active and passive cooling to avoid over-heated throttling. The BBB is focused on passive cooling with an unusually robust PCB of 5+ layers serving as a heat sync in addition to better communication links between mounted components.

Waiting on the second order of RPi seemed like the best choice – there was a long weekend ahead when I should have the leisure to focus on getting it right.

But then, out of the blue, the BBB arrived.

Suddenly I had the option of running two separate servers, and do the real head-to-head testing in the wild! except, the BeagleBone is really not like the Raspberry Pi. First I had to learn how.


I do not know why I became fixated on using a separate vanilla server as my test. It is quite possible to reverse-proxy to the localhost, which is an easier POC. But there you have it; sometimes logic has little to do with things.

I suppose the two-server problem is more challenging, and at the same time more like the goal – a single front server dealing requests to various entirely separate devices.

More real, then.

Installing the BeagleBone into a carrier intended for a slightly differently sized SBC is not, on the face of it, bad. Or difficult. But it does mean it is more ‘resting within’ than actually attached. A single stand-off is screwed to the enclosure, the other three slide around every time I attempt to plug in the power.

And the BBB does not have dedicated pins to drive the case fan (Naturally not since it is designed to use the board itself as heat sink.) It worked well enough for the task, but it had me wondering if I should be sourcing an Altoids mint tin.

But one thing was a more-serious bother – the power supply port for the BBB is a mini-USB port. The cable which came with the device is a standard mini-USB cable – there is no on-off switch. If the only way one can turn on the device is to manually plug it in, that can be a serious problem. It powers down via software, but one needs to manually unplug and then replug to reboot. Definite drawback for use as a server. But then

Unfortunately, the challenge of learning how to use the BeagleBone Black were taking up more time than I wanted. First there was the problem of getting everything to update, which eventually worked, but nginx was not to be found in the updated repos after. Neither was man.

I honestly do not know how that got repaired. Maybe a random

sudo reboot -h now

But installing nginx and then poking at the configurations suddenly displayed BeagleBoard documentation. ⸘Progress‽

Of a sort. But then it ran into a death spiral: it ran out of room on the eMMC. This is hard-drive-like storage device on the SBC. The solution was to flash a microSD with the operating system and start rebuilding the operating system again.

All of which was taking time in a busy life until…


the second Raspberry Pi 3 B+ finally arrived. Considering how short a distance it needed to travel, it was a painfully long time between ordering and receiving.

And it took just about two hours of actually being able to work with it to prove that two separate installations of nginx can work just fine as proxy and upstream servers. And that I still cannot get the Apache server to work that way.

Still to be proven is how to manage ssl/tls. And whether raspberry pi zero can run nginx. And, if so, how to connect a large storage system to the system. Redis! cannot forget to work with Redis on the pis…