My Pi 400 Travel Desktop

Good Morning from my Robotics Lab! This is Shadow8472, and today I am trying out my Raspberry Pi 400 as a lightweight daily driver. Let’s get started.

rPi 400

The Pi 400 is a special edition of Raspberry Pi – essentially a Pi 4 built into a keyboard. It’s missing a USB 2.0 port (made up for by the keyboard) and the 3.5mm audio jack. In theory, the miniature keyboard computer is perfect for travel – assuming you have a screen at your destination that is.

Choosing a Distro

My first thought was to try installing Arch. A brief search found an Arch on ARM project as vanilla Arch only supports x86 architecture. The instructions involved formatting a drive on the terminal. I bought a 256 GB SD card and did so on the first convenient rPi install I had – Kali linux.

It took a few failed attempts to install Arch. The pure open source method that reportedly works on the regular Pi 4 didn’t on my Pi 400, and the standard method wasn’t cooperative when installing a login manager and any of a few desktop environments. Running on a time crunch before leaving on a trip, I switched to DietPi, another lightweight distro I’ve worked with before for, but for a much different project. As with Arch, MATE was uncooperative, so I settled with XFCE. Special thanks to Balena Etcher for a special warning when formatting large drives.

Packing For a Trip

To shortcut setup, I copied my browser and LibreOffice data from my main desktop. LibreOffice worked for me, but didn’t carry the full dark mode – a problem I’ve encountered before, but ultimately decided to live with.

Firefox ESR –as installed from DietPi’s hedged garden– refused to accept my profile. Regular Firefox –installed from the apt repositories– was up to date and started as expected. Notably, it included my extensions – especially Bitwarden, my password vault.

A screen was not procured at my destination, so I packed one from home. The missing audio jack was also problematic, so I packed my Blue Yeti with plans to disable voice monitoring. For redundancy, I packed an HDMI monitor, but busted the ​​styrofoam while stuffing it into the slightly wrong box. As of writing, I have done nothing with sound.

Deployment

We left on our trip. Upon arriving, I found my over-packed tech bag lacked a long enough HDMI cable. I borrowed a longer one. The monitor signal kept flickering. For a while, I assumed I was overloading the Pi with a couple hundred browser tabs, but after a power blink and several reboots, it came out that the HDMI was bad. We bought a replacement, and it’s been working properly since.

Ejected Challenges

Arch wasn’t the only thing I had to back off from. I brought a couple additional Pi 4’s to have myself a nice, little network with Pi-Hole ad blocking, but Wi-Fi strength and configuration challenges meant those were both a no-go.

Another challenge I want to pull off is playing Stardew Valley. I copied the files over back home, but haven’t had time to try the conversion I found yet.

Takeaway

Finishing a project as a rule is better than stalling an overly ambitious one. I have an on-the-go workstation, even though it still lacks polish.

Of special interest, this week marks the 6th anniversary of my Robotics Lab. And some months ago, I decided I wanted to do a Sabbath year cycle. I’ve proven that I can be consistent at posting, even if I feel my quality slips some weeks. The facts of the matters is that weekly posts are getting a bit repetitive for me, so for the next year, I’m only going to post when I finish a major project, such as when I have the full software suite I have in mind for my homelab. After that, perhaps I’ll stick to monthly. We’ll see in a year’s time.

Final Question

Setting up a travel computer on the quick was a bit of a trick. What must-haves would you include in a similar package?

I look forward to hearing your answers in the comments below or on my Socials.

Server Rebuild With Quadlet

Good Morning from my Robotics Lab! This is Shadow_8472, and today I am continuing my work on my home’s network. Let’s get started!

State of the Homelab

Bitwarden. I self host using Vaultwarden, a 3rd party server. Done properly, it fits nicely in a larger homelab stack, but its OCI container can stand alone in a development environment. Due to skill limitations, I’ve been using it in this configuration. My recent network work has invalidated my manually self-signed certificates, and I’d rather focus my efforts on upgrades instead of re-learning the old system to maintain it.

Today, I am working on my newest server, Joystick (Rocky Linux 9). I compiled some command-by-command notes on using `podman generate systemd` to make self-starting, rootless containers, but just as I was getting the hang of it again, a warning message encouraged me to use a newer technique: Quadlet.

Quadlet

Quadlets? I’ve studied them before, but failed to grasp key concepts. It finally clicked though: they replace not just running `podman generate systemd` once I have a working prototype setup, but also everything I might want to do leading up to that point including defining Podman networks and volumes. Just make your Quadlet definitions once, and the system handles the rest.

The tutorial I found that best matches my use case can be found at mo8it.com [1]. Follow the link under Works Cited for the full text. It’s very detailed; I couldn’t have done a better job myeslf. But it doesn’t cover everything, like how `sudo su user` isn’t a true login for `systemctl –user …`. I had to use a twitchy Cockpit terminal for that (Wayland-Firefox bug).

Caddy

Caddy is the base of my dream homelab tech tree, so I’ll start there. My existing prototype calls for a Podman network, two Podman volumes, and a Caddyfile I’m mounting as a volume from the file system. I threw together caddy.container based on my script, but only the supporting network and volumes showed up. Systemd picked up on “mysleep.container,” an example from RedHat.

As it turned out, caddy.container had missed a capitalization. I found the problem by commenting out lines, reloading, and running `systemctl –user list-unit-files` to see when it didn’t load. Likewise, my Caddyfile volume had a file path bug to squash.

Vaultwarden

Good, that’s started and should be stable. On to Vaultwarden. I updated both ButtonMash and Joystick’s NFS unit files to copy over relevant files, but Joystick’s SELinux didn’t like my user’s fingerprints (owner/group/SELinux data) on the NFS definitions. I cleaned those up with a series of cp and mv commands with sudo and then I could enable the automounts.

Vaultwarden went up with simple enough debugging, but the challenge was in accessing it. I toyed with Cerberus/OPNsense (hardware firewall) DNS overrides until Caddy returned a test message from <domain.lan>:<port#>.

Everything

My next battle was with Joystick’s firewall: I forgot to forward tcp traffic from ports 80 and 443 to 8000 and 44300, respectively. Back on Cerberus, I had to actually figure out the alias system and use that. Firefox needed Caddy’s root certificate. Bouncing back to the network Quadlet, I configured it according to another tutorial doing something very similar to what I want [2]. I configured mine without an external DNS. A final adjustment to my Caddyfile to correct Vaultwarden’s fully qualified domain name, and I was in – padlock and everything.

Takeaways

I come out of this project with an intuition of how to manage Systemd files – especially Quadlet. The Quadlet workflow makes Podman container recipes for Systemd, and a working container will work forever – baring bad updates. I would still recommend prototyping with scripts when stuck though. When a Quadlet fails, there is no obvious error message to look up – it just fails to show up.

Even though it is still new, a lot of my time on Joystick this week was diagnosing my own sloppiness. Reboots helped when I got stuck, and thanks to Quadlet, I didn’t have to worry about spaghetti scripts like how I originally organized ButtonMash and never stabilized this victory I re-achieved today.

Final Question

NextCloud is going to be very similar, which I will make a pod along with MariaDB and Redis containers. But I am still missing one piece: NFS. How do I do that?

I look forward to your answers below or on my Socials.

Works Cited

[1] mo8bit, “Quadlet: Running Podman containers under systemd,” mo8it.com, Jan. 2-Feb. 19, 2024. [Online]. Available: https://mo8it.com/blog/quadlet/. [accessed: Sept. 13, 2024].

[2] G. Coletto, “How to install multi-container applications with Podman quadlets,” giacomo.coletto.io, May 25, 2024. [Online]. Available: https://giacomo.coletto.io/blog/podman-quadlets/. [accessed: Sept. 13, 2024].

Replacing My Tablet’s Battery

Good Morning from my Robotics Lab! This is Shadow8472 with a side project of the week. Let’s get started!

I’ve had my Samsung Galaxy Tab A 10.1 (2016) since before my new Android device lockout. It’s held out for the most part, but several months ago, it developed a problem where it would lose power while plugging it in or unplugging it. At worst, it would pulse its battery charging picture until eventually moving to a charge meter. The problem grew worse over time, and new power cables didn’t solve the problem. The parts to replace the USB connector and battery were out of my price range. One day, I even made a “Goodbye” backup.

I don’t know how I found this, but a little pressure on the back let my tablet boot again. Sometimes, the battery would register as empty and shut down once Android loaded – even when connected to wall power and the battery showed up as 100% again a moment later.

I zeroed in on the left-middle (viewed from the front in portrait mode) as the place to press. As I got used to this arrangement, I had to keep pressing harder. Eventually, I pried the back cover off with an orange peeler. The battery has two sections, and I’d been pressing on the bottom-outside corner of the upper pack. The battery itself did not appear bloated or otherwise damaged, and continued to work applying pressure directly to the battery pack (DUMB IDEA, by the way; DO NOT TRY) and pressing the tiny, exposed power button.

As it turns out, Android sees the battery as a critical part (unlike laptops), and I don’t have the tools or know-how to simulate one, but some kind of wall-only power mode would have been a courteous gesture, even if it were buried deep within the firmware.

Through another month or two of observations, I learned how the battery failed when I stopped pressing too soon after booting or if the tablet started drawing too much power, such as when turning on when when plugging it in while off. With this, I narrowed my diagnostic to just the battery pack, which I figured was worth trying to replace. Reviews of different compatible replacement batteries said not to expect more than a year out of it – even genuine ones. My guess is that it’s all old stock, changes pushed to the operating system intended to slow battery aging, or a combination thereof.

Replacing the battery once it arrived was only a matter of formality. The screwdriver that came with the kit was worthless, but I had access to a better one. I expected little of the battery, and I got little of it. It’s a step or two above junk, but it’s worlds better than the old one. I just need to be a bit more careful about how I handle my tablet from now on. If it only lasts another year or less, my plan is to replace it entirely.

Final Question

I can’t find any information online about applying pressure to batteries. Do you have any insights? If so, I look forward to hearing from you in the comments below or on my Socials.

Responsibility of the Network

Good Morning from my Robotics Lab! This is Shadow_8472, and today I have a doozy of a network week to cover. Let’s get started!

Meet the Computers

  • Cerberus – the main star today. It is our new hardware firewall running OPNsense
  • Red Router – a tp-link gaming Wi-Fi router fancied up beyond what it should have been
  • LAB – my homelab with a few servers
  • LAN – everything else connected via Wi-Fi or Ethernet

Network Implosion

It all started with revisiting a .lan domain. Cerberus’ extensive webUI left me with the hunch I’d need one machine in charge of DHCP assigning dynamic IP addresses. Red Router’s “operation mode” to work as an access point was hidden in literally the last menu to click through.

It was afternoon and no one would be using the network for the 30 seconds to 5 minutes I estimated switching the LAB and LAN Ethernet cables from Red Router over to Cerberus would take. Nope. No traffic made it through. DHCP mis-configuration? Cue a slow back and forth, bopping a setting from a workstation and trying a different physical configuration. Eventually, Cerberus ended up on my desk with Red Router talking directly to our ISP’s gateway/modem.

Order of events is a bit fuzzy from here, but when the Wi-Fi stopped working, I was without a good access to online answers. I worked the problem into the night. Around 1:00 AM, I knew I had done too much for a clean reversion. For two hours, I worked in loops hoping to spot something different. So much waiting! Cerberus would behave on my desk, then fail when redeployed. Worse: when I re-connected all the wires to Red Router, it started dancing between 192.168.0.1 and 192.168.1.1 every 45 seconds or so. I configured its IP manually, but gave up on Internet by morning at 3:00 AM, preparing to concede to my father’s suggestion earlier about hiring a professional to untangle my mess.

The Next Day

Newtork Loop. In my brain fog, I had Red Router talking to itself on a cable leftover from removing Cerberus for the night. With the house to myself for several hours, I alternated between bursts of intense diagnostics and mental processing. Somewhere in there, I rebooted the ISP’s modem.

Around noon, I realized the extra ports on Cerberus aren’t a switch as is Red Router’s default configuration, but were following firewall rules – which explained its behavior the previous day when I tried a computer from LAB without anything in-between. At around 3 PM, I got a Discord notification while mentally checked out, letting me know the network was back on.

6 PM on the second day: I situated my workstation in Cerberus’ LAN port and a Raspberry Pi in one I named LAN2. I’d previously copied firewall rules from LAN to LAN2 and LAB, but to no obvious effect – until I had the two computers ping each other. LAN2 failed as expected, but LAN’s ping was returned. I corrected the interfaces’ rules to allow them to reach out, and that was it.

Fallout

Without going into too much detail, a subnet shift like this is a major undertaking for networks with static IP servers on them. Not only do the network and computers need to be adjusted, but all traces of the old subnet need to be corrected. NFS clients needed to be told where the server was now, and the NFS server shares needed to be updated about what IP’s were allowed to mount them. I also still have Bitwarden to clients to update at my leisure.

Takeaway

OPNsense is a heavy weight in terms of configuration options. It has a learning curve compared to products simple enough to for Grandma and Grandpa to use. I may have solved my own emergency, but it may be wise to get someone looking at it professionally anyway to grade my work and give me some pointers on rootless Podman mounting NFS shares, or other long-term places where I’ve gotten stuck.

Final Question

I admit: networking is more fun than I gave it credit for before I knew basically anything. I still find it a bit taxing to mentally reach around my mental map, but I manage. How do you visualize networks?