Linux

So I have formatted the external drive to ext4 and have it ready for NextCloud. Issue now is how to provide enough power for the RPi, 7” touch screen and an external HDD from a single USB-C charge brick. Ideas?

Spent the morning deploying my local NextCloud instance on a Raspberry Pi. Will be adding an external HDD storage tomorrow - or maybe wait for an external SSD instead. #deGoogle

Who is running Vaultwarden here? Does it need the annual license from Bitwarden to use multi-user and Yubikeys? #FOSS

Going 64 and saying good-bye to “pi”

RaspberryPi OS just got refreshed — this time, it ditched the default user account, “pi”, in favor of user-created account name on first run. In addition to this, you can now pair a Bluetooth keyboard and mouse during the configuration process, making it easier to setup a RaspberryPi without messing with USB cables. These are just some of the new features added in the 04-04-2022 release.

This morning, I figured that I might give the 64-bit version another try and see if I can finally replace the 32-bit Bullseye install currently running on the RPi. So, off I went to download the installer.

I unwrapped a new 32GB SD card and flashed it with the new 64-bit RaspiOS. Using the spare Raspberry Pi 4, I booted the new OS to test the new features. As advertised, it asked me to provide the username. The RPi is connected to a touchscreen display, so there is no need for a mouse, but a keyboard is required since the installer did not come with on-screen keyboard support enabled at the get go. Tapping the Bluetooth icon quickly detected an old wireless Logitech keyboard (bought this a couple of months ago and have not used it yet).

Doing the usual — removed Geany, Thonny and Chromium, since they’re useless to me, but added Midori (but was replaced by Firefox-ESR since Midori was acting a bit weird) as browser. Installing Pi-Hole hit a snag since it didn’t detect the usual operating system, but a quick addition of a parameter to ignore the OS check did the trick. Log2ram, VNC, Unbound, Rclone, Plexmedia, and YT-dlp were added and configured. With the basic software up and running, the new 64-bit RaspiOS now powers the home media server and the Pi-Hole that protects the home network.

Lastly, the Siri shortcuts that I have on my iPhone, iPad and Mac need to be modified to reflect the new user subdirectory as /home/pi is no longer valid. Also need to change the SSH keys.

Everything is up and running now – hoping that the next OS upgrade can be done without re-installing the entire thing again. Now time to clone the SD card.

Spinning up my own cloud desktop

Sometimes I find myself wishing that I have a Linux desktop that I can access remotely. Whilst having a cloud-based desktop is not new, it is, however, a bit expensive when used sparingly. If, however, you prefer working on the cloud-based desktop most of the time, then it becomes affordable (Shells.com offer one at $4.95/mo for 10 hours of use, Microsoft and Amazon have similar products, though not sure of their pricing).

Ponying up $4.95/mo for 10 hours of use for a single purpose subscription is not really an option for me. I do have Linux servers running 24x7 for the same price — currently have one running the kids’ Minecraft server and works as WireGuard VPN server at the same time. Heck, I have another server on Oracle that is on the free-tier, but this one is exclusively running WireGuard VPN.

I decided to give VNC on the Minecraft server a try and see if it’ll work. So I went off armed with the guide, “How to Install and Configure VNC on Ubuntu 20.04”, written by Mark Drake. It does not take you long to do the install and configuration.

With the Minecraft server now running VNC, the next step is to test it. On the iPad Pro, I use Screens as my Remote Desktop app. I use it to access my Raspberry Pi desktop when I need to run SD Copier to clone the main system. I also use it when rclone.org requires a browser to generate the access tokens.

The guide protects the VNC by limiting access to localhost, i.e., you cannot connect directly to the server from the internet (besides, the ports are also blocked). First, I tried connecting to the server via the WireGuard VPN and then get Screens to connect, but that failed. Yeah, I know this was not part of Mark’s guide — tried it, even with the firewall deactivated. No dice.

With the firewall up and ports blocked again, I configured Screens to establish an SSH tunnel (as written on Mark’s guide) and then connect VNC. Copying the SSH keys from the MacBook Pro and setting Screens to connect to localhost got it working. The desktop appeared on my iPad Pro! Not bad.

A quick install of a lightweight browser, Midori, completed the exercise. A couple of reboots made sure that everything is automatically launched on boot. Now my cloud desktop is up and running.

Anyway, I prefer working locally, i.e., not on the cloud (yeah, I don’t like using online productivity suites like Google Docs or Office365), and on the device (not a fan of Chromebooks, too). When your internet connection is expensive and unreliable, then you’d understand.

screenshot of Screens Remote Desktop iPadOS app

Took me several hours to update pfSense. *whew*

pfSense released a new version with lots of bug fixes. Since I’m a sucker for new firmware, I immediately tried to upgrade the appliance. It used to be easy - just click on the link (web-based admin interface) and confirm, that is it. This time was different. Hmm…

The appliance couldn’t download the update. Weird, I thought, must be the DNS. Used the built-in tools to check and it was not the DNS. I even played with several DNS IP addresses that I use (and unblocked some known ones on the firewall as well). Still no go.

Time to go CLI-ninja. Installed SSH, but it took a long time. Hmm. Internet connection wasn’t the issue. What then? A reboot might help – there, ssh is now up. Launched Terminal on the Mac. Ah, good ole reliable CLI! SSHed and got in, but I don’t have privileges. What the! A few DuckDuckGo searches schooled me that I needed to add more admin privileges. The pfSense web-based interface provided those settings, good.

Armed with new root priveleges, SSHed again and there! I can initiate the firmware update via CLI. And what did you know, that, too, failed!

A few more DuckDuckGo searches and I was reminded that it might actually be the network. I remember apt-get failing on my Raspberry Pi before, and it was not because of whatever issue, except that the network was set to prioritize IPv6 connections. An eureka moment - let’s see if “forcing IPv4 even if IPv6 is available” works. What do you know? That was it. All these reboots, DNS, etc., and it was just that setting on the gateway that did it. Silly, I agree.

Why can’t repositories support IPv6 reliably? Oh well. At least it only takes one switch on pfSense to do that. Now, I turned off that setting and I am back on “IPv6 first”.

What does Akamai buying Linode mean to Linode subscribers? Hmmm…

Is it a good idea to upgrade to 64-bit Raspberry Pi OS (heard full-upgrade only upgrades the kernel) or start from scratch (again) or wait awhile for more applications to be 64-bit?

Zoom client for Linux Mint works! Yay! Now using this revived Acer Aspire laptop as an alternative Zoom terminal.

Now downloading a Zoom client for Linux Mint. Let’s see how this goes…