HomeLab Side-Quest #1

After setting up my "gateway" homelab raspberry pi and keeping it in relatively good uptime for a few months a few things became clear to me:

• Adding features that are already production-ready containers is easy! I've added audiobookshelf, nextcloud, freshrss, all kinds of containers!

• Messing around with code on the bare metal of the Pi or messing with the DietPi OS is a great way to kill the reverse proxy and restarts are annoying.

• The natural conclusion here is obvious, dev and prod servers are separated for good reason!

An extremely limited dev server

I was going through a box of spare parts and found 2 Raspberry Pi Zero's, and one 3B, not including the Zero-2w I was using as a fileserver. I wanted a server to write golang on without fear that I would accidentally stop important services on the gateway, and after the briefest investigation running my OLED status screen (as described in Step One) took up about 15% CPU and running hello world for the first time in go took over 3 minutes. So I knew I needed to use the 3B for this task, and I'll put off my plans to use it for Home Assistant.

And one more interesting thing, that OLED I put on the gateway is already showing signs of age. I knew OLEDs burn, but I was surprised at the speed so I looked up some more about it and of course there is a very insightful Hackaday post on the topic. Turns out, you're supposed to dim, cycle, turn off, or screen-save these little displays. That should have been obvious to me, but I happily followed the tutorials that come up when you search "raspberry pi oled monitor" and once the lights started blinken I left it on a shelf.

Flipping the screen to an inverted status is all I have done so far, so at least now the pixels will burn relatively evenly. I like the way of changing screens in the Luma.OLED example. Instead of keeping track of any states in this simple python script, just do a modulo on system time and do one of two things.

SSD1306_NORMALDISPLAY = 0xA6
SSD1306_INVERTDISPLAY = 0xA7
...
screen_flip = oled_serial.SSD1306_INVERTDISPLAY
screen_flop = oled_serial.SSD1306_NORMALDISPLAY
...
def invert_oled(device, interval):
    flopper = datetime.now().second % (interval * 2)
    if flopper < interval:
        #flip
        device.command(screen_flip)
    else:
        #flop
        device.command(screen_flop)

With that fun diversion handled, it's time to install Go and take care of one back burner item i had been putting off for a long time, a version control system. Both of them are completely trivial to bring in with dietpi-software:

• Go Lang: https://dietpi.com/docs/software/programming/#go

• Forgejo: https://dietpi.com/docs/software/cloud/#forgejo

For a long time I had avoided running a version control server in my homelab because the scripts I was using are always so small I thought it wasn't necessary to keep track of them in that level of detail, or big enough I kept them offsite on a 'real' git provider.
But that is not the spirit of homelab! So I installed Forgejo just because I read an article about their fork from Gitea (which was briefly on the original homelab).
Now I should have really committed to this and put it on the gateway pi with a real subdomain and behind the reverse proxy. I wasn't sure yet how I would like Forgejo and I wanted to work out a "polite" and terse system of SSH keys to protect access to the repos so this is the path of moderate commitment. If I rework this to be a container on the gateway pi I'll definitely write an article on the subject because I have already seen a few posts that combining a reverse proxy and ssh keys and git urls is fine balance.

Back burner: PaaS the Pi

There are 2 major projects to run your own heroku-style PaaS on the Raspberry Pi:

• Dokku

  • More feature complete, even though the best features like web interface are behind a hefty license fee.

  • Requires at least 1GB RAM. Not a whole lot in this day and age, but more than the 3B can provide, so this got back-burner'ed indefinitely

• Piku

  • Runs light and lean since it was made with the Pi as it's primary platform

  • Doesn't use docker or heroku tools because when the project originated, these ports to aarch64/arm64 were immature.

  • Runs on python.

  • Requires a fresh debian install that you feel comfortable modifying because there is no uninstall plan.

Overall, these were a fun distraction to research but since none of my go scripts are mature enough that I want them highly available and automatically updating. Plus as this user posted you can just make checking version control a part of your make build, or part of a shell script that starts things up.

Since DietPi dietpi-autostart and dietpi-cron supervisors are useful enough and more importantly super light and included in the image... I have no reason to install a PaaS on this wimpy Pi.

So this side-quest is complete. I have a place to learn Go and it doesn't need to be overcomplicated any further.