Author: dejvino

Categories
Guides Privacy Self-hosting Technology

Offsite backup solution – Part 0

Our digital belongings are growing in size and importance. Family photos, accounting documents, beloved video games, losing them would be a nightmare. Having a backup is definitely mandatory. And if you’re self-hosting a lot like me, an offsite backup is a good way to be able to sleep calmly at night. I recently needed to rebuild my offsite storage system and so I decided to share my setup and my experience using it. This might be a long series, so hold on!

What Are Offsite Backups?

Offsite backups mean storing copies of your data in a different physical location from your main data. That means outside of your house! This way, if something unexpected happens (like a fire, theft, or hardware failure), your data is not completely lost. You could use cloud services for this, but we’ll focus on self-hosted solutions. I like to be in control, plus it gives me good understanding of how it all works.

Benefits of Offsite Backups

  1. Data Security: Keeping your data in a separate place protects it from local disasters.
  2. Redundancy: Extra copies of your data mean you’re covered if something goes wrong.
  3. Peace of Mind: Knowing your data is safe offsite gives you one less thing to worry about.

Additionally, if your backup is offline (in cold storage), it will be cheaper to run. No electricity or compute needed. And no need for fancy firewalls or access management, no one has access to the data unless they physically get to the hard drive.

My Self-Hosted Offsite Backup Setup

I run a local NAS with mirrored hard drives, shared over SMB on the LAN. This is the primary storage.

Next, there is a tiny ARM computer with an external hard drive that receives a weekly snapshot from the NAS, stored and encrypted via BorgBackup.

Lastly, a lonely external hard drive lives in my relative’s flat. And every time I make a visit there, I bring the other hard drive and swap them out.

Self-Hosted Backup Solution Overview

Step 1: Set Up Your Backup Server

  1. Choose Your Hardware: An old computer, a NAS, a Raspberry Pi. Make sure you have enough storage space on two separate drives.
  2. Install Linux: A lightweight Linux distro like Ubuntu Server or Debian works great.
  3. Secure Your Server: Set up SSH for remote access, configure a firewall, and keep your system updated.

Step 2: Configure the Backup Software

  1. Install the backup software: BorgBackup in this case.
  2. Configure mount points: both to the source and the destination of the backup.

Step 3: Automate and Monitor Your Backups

  1. Set up the automation: Fetch the data diff, compress and encrypt it, store it.
  2. Monitoring: Make sure you periodically find out that things DO work.
  3. Swap the drives: This is the actual offsite step!

Step 4: Test Your Backups

  1. Regular Testing: Periodically try and restore some data to make sure your backups and tools work.
  2. Health Checks: Inspect the state of the drives to replace them before they go ERR!

Is that it?

I didn’t even start yet! This was just a brief introduction of what I’m about to discuss in this series. More details to come in the next part where I’ll look into setting up the hardware.

Categories
Games Open source Programming Projects

Moon Bus :: PICO-8 game

Handheld console showing Moon Bus game running.

I couldn’t resist the temptation to get down to coding a game like it was the 1980s again: small screen, huge pixels, 8-bit values, limited resources, limited instruction set, lots of fun.

PICO-8 is a fantasy console that only ever existed as an emulator. But oh boy, what a fun and well executed concept. I bought the license (sic, this is not a free nor open source software) so that I could play it on my Anbernic RG35XX H emulator console. And it is an amazing experience, being able to play 8-bit retro games that are freshly released and wirelessly downloaded onto a handheld device.

Since PICO-8 provides an all-in-one environment for games development, I decided to give it a try. Enter Moon Bus. This is a simple ‘Lunar Lander’-like game, where you have to travel from station to station, landing several times in a row to carry passengers around a low-gravity planet. I had a lot of fun building this and subsequently playing this on my handheld.

You can find the game on the official PICO-8 site: Moon Bus at www.lexaloffle.com

I love that there are still options to get into simple programming, without any need for massive frameworks and libraries. It is a refreshing experience and it really reminds me of coding way back when you didn’t have that many options or expectations. You definitely don’t need a cluster of GPUs to compile shaders like with other current platforms.

Categories
Brainwaves

Keeping PinePhone Awake With Podcasts

Lately, I experimented with listening to podcasts on my PinePhone. The idea was to listen to some interesting topics while I’m on a walk, returning home. As you’d expect, nothing “just works” on a Linux phone.

I set up an automated download process via podget so that I can listen even with no network access. I got a pair of Bluetooth headphones to avoid fighting with headphone cords and to make this easy and convenient (as much as using a Linux phone can be). I picked up pragha as my new dedicated podcast player (‘P’ as in ‘Podcasts’!). The player even supported MPRIS2 via a plugin, so everything was great. Well, apart from my phone auto-suspending while the player was running.

One day later, I was halfway into creating a sleep-inhibit plugin for the pragha player. And then I found out there is an even better solution: sleep-inhibitor. This is a system service that monitors the audio output and if there is some sound playing through ALSA, it keeps the system from suspending. Just what I needed!

The service is even better than a player plugin, since this solution is generic. I also had a similar problem with the VLC player. And seeing this VLC ticket, I wasn’t the only one. Actually, this ticket brought me to the sleep-inhibitor, while researching ways to inhibit the system suspend.

Categories
Brainwaves Linux

PinePhone Daily Cron Fixed

I needed to run a daily cron job on my PinePhone, but that turned out to be trickier than expected. How can you schedule a job to be run in the morning, when the phone is most likely asleep (suspended) at that time?

My solution (workaround?) was to have the cron job run every 10 minutes, checking if the job was already executed today and if not, run the actual job command. This check is pretty cheap and I don’t need to wake the phone up to run my job. All I need is to get the job executed “today, whenever you have the time”.

The Cron Limiter tool (crolim for short) is available in my snippets repository.

With this tool, the crontab is as easy as: */10 * * * * crolim podget. Now my daily podcasts can be downloaded daily, when the phone is awake.

Categories
Brainwaves

PinePhone Printing Receipts (pt. 2)

Another way to print on a POS Printer on Linux is to use the python_escpos library. It requires programming, but if you really want to get a lower level access to the printer, this is a nice solution.

All you need is to connect the printer over USB, find out the vendor and product ID via lsusb, create a short python script using the escpos library and you can print text, images, barcodes, whatever!

This is the code I used for my Sewoo SLK-TS400 printer, identified as “0525:a700 Netchip Technology, Inc. POS PRINTER”:

from escpos.printer import Usb

p = Usb(0x0525, 0xa700)
p.text("Hello World\n")
p.barcode('1324354657687', 'EAN13', 64, 2, '', '')
p.cut()

Easy! Time to build a “Today’s News Headlines” service. Or maybe a “Error logs needing your attention” syslog service?

Categories
Brainwaves Linux Open source

PinePhone Printing on a Thermal Receipt Printer

I like using PinePhone as a general purpose computer for various tasks and purposes, such as a dedicated alarm clock, trying out networking software (I have several of them), etc. This time I tried attaching a POS Printer, creating a print server.

Linux is great when it comes to printers support, thanks to CUPS. It usually just works. For the POS Printer I needed to install additional drivers, but luckily there are some generic ones available, covering most of the 58mm / 80mm thermal printers (they share the same ESC/POS protocol, making them widely compatible).

Initially I wanted to use the official vendor-supplied printer drivers for Linux ARM, but there are several ARM architectures and this wasn’t the right one. Therefore I used these CUPS drivers instead: github.com/klirichek/zj-58. And since this is open source, I was able to compile them for the PinePhone’s ARM architecture and get it working.

Adding a printer can be done through the CUPS web interface running on localhost:631, where you can add the printer connected over USB. You can also connect a printer over serial or Bluetooth, all you need is a special connection URL: serial:/dev/ttyXXX or bluetooth://123456789a/ where you specify the serial file or the device address.

Once the printer is added, you can use all the lp* commands to manage your print jobs, such as lpoptions to configure the printer defaults, or lp tux.png to print out an image on a thermal printer!

Categories
Brainwaves Raspberry Pi

Kodi on Raspberry Pi 3 running Arch Linux ARM

When setting up Kodi under Arch Linux ARM running on Raspberry Pi 3, I encountered this error, which crashed the graphical environment right from the start:

[drm:vc4_bo_create [vc4]] ERROR Failed to allocate from CMA:
...

After some searching, I ran into an issue thread, where it was advised to increase the CMA memory (as a workaround that seems to just be the actual fix). You need to add ‘cma=256M’ to the kernel boot parameters. But how do you do that?

# Run as root...

# dependencies
pacman -S uboot-tools

# modify the kernel boot parameters
cd /boot
vim boot.txt # append cma=256M to the line with boot params
./mkscr
reboot

Before this fix, I had only 64 MB of CMA. This wasn’t enough. To check that this worked:

if the cma parameter is present and /proc/meminfo

cat /proc/cmdline
# should contain cma=256M

cat /proc/meminfo | grep Cma
# should say CmaTotal: 262144 kB

Now Kodi finally starts!

…though there are still some problems with the graphics driver (video doesn’t play, random switching to the console and back).

As it turns out, using the AArch64 version of Arch Linux ARM for Kodi is not the best option. Switching to the ARMv7 version helped a lot, everything worked from the start.

Categories
Brainwaves

Birdie: Alarm App for Linux Phones

Wouldn’t it be nice to have a way to be woken up by your phone in the morning? Well, any old Android phone can do that! That was not the case with Linux phones. Until Birdie came along. Let’s consider the options:

Gnome Clocks? Nope. The app needs to be running for the alarm to activate.

Cron? Nope. When the phone gets suspended to save power, it will miss the alarm.

Wake Mobile? Close, but nope. It has most of the technology that is needed, but the alarm sound is annoying and it is not convenient to use. To be fair, this was only a proof of concept app. Some people reportedly used it anyway.

Birdie? YES! This one brings the minimum of features that I consider are required for an alarm clock.

Birdie features

  • one recurring alarm for selected days
  • ON/OFF switch
  • pleasant alarm sound with gradually rising volume, starting from complete silence
  • stop / snooze buttons
  • configurable alarm sound
  • wakes the system from sleep
  • shows control buttons on the lock screen, without the need to log in

With this feature set, I can finally replace my Android phone as an alarm clock!

Categories
Brainwaves

What is MPRIS?

This week I found out about MPRIS: Media Player Remote Interfacing Specification. It is a standardized D-Bus interface for exposing metadata and controlls from a music player. Thanks to MPRIS, other apps can integrate such a music player seamlessly, e.g. onto the computer lockscreen.

What else can you do with MPRIS? Stop or Snooze your alarm clock! That’s right, the alarm clock Birdie designed for Linux phones (PinePhone) now acts as a music player. Now you don’t have to unlock the phone to stop an alarm in the morning!

Categories
Brainwaves

Building AArch64 Arch Linux packages on a x86_64 host

I was looking for a convenient way of easily building AArch64 (ARM64 / ARMv8-A) packages for Arch Linux ARM, namely for the PinePhone. One option is to cross-compile the packages, but maintaining a cross-compilation toolchain is a pain. I wanted the experience of compiling natively without the need to heat up the weak ARM CPU these devices have.

QEMU to the rescue! It is possible to run an emulated Arch Linux ARM on a non-ARM device. This way you can compile natively. And with armutils this whole process of building packages can be automated. All you need is to install a few AUR packages, create an AArch64 chroot and start building!

Dependencies

You’ll need qemu-user-static-bin, binfmt-qemu-static-all-arch and finally armutils-git, installed from AUR (e.g. via yay).

Creating a chroot


mkarmroot -u http://os.archlinuxarm.org/os/ArchLinuxARM-aarch64-latest.tar.gz <YOUR-PATH>/aarch64/root base-devel

Building a package

Assuming <YOUR-PATH>/pkg contains the package PKGBUILD file:

cd <YOUR-PATH>/pkg
sudo makearmpkg -r ../aarch64 -- --noconfirm

Done!