Jeep Wrangler Modification

I'm a car guy.  I'm usually into sports cars and motorcycles.  As this blog is named "All Things Tech", this post fits.

I bought a 2018 Jeep Wrangler Sport S in the fall of 2018, trading in my 2011 Subaru WRX STI sedan.  Before then, I had a 2001 Jeep Wrangler Sport, and bought it used, but it had very bad frame rot, so I had to get rid of it.  I still wanted a Wrangler, so I bought a new one.

It was basically unmodified up until last year (other than a roof rack and side steps).  Last year, I needed new tires and I decided to have larger tires installed.  No, I didn't have it lifted.  I installed the largest tires that wouldn't rub against the undercarriage and/or suspension.  I installed Toyo Open Country AT IIIs (C load) in 285/75/17, which is basically Rubicon size but with a wider footprint.

Those larger sized tires will throw off the speedometer (was aware of that before I bought them).  It took me a year to get around to correcting the speedometer.

I bought a vLinker MC+, which is a bluetooth-enabled OBD II reader.  The reader is designed for use with the Jeep Wrangler.  I also installed Jscan on my iPhone, which is an OBD II tuner - I had to buy a user license to use it, but it was maybe $30.

I also had to by a set of $20 security bypass cables, as the Jeep has an integral firewall.  The cables bypass the firewall.

I used Jscan to reconfigure the tire size within the ECU.

I took a long trip to NC last weekend and found that the speedometer was spot on - I used Waze (car nav software) to determine my true speed and compared it to the speedometer's measurement...it was spot-on at all speeds.

I shouldn't have waited a full year to do this, but as I get older (I'm almost 60 now), I've less patience with car things, which is why I got the Jeep in the first place - the STI ended up being too much work for me...I'll always love STIs but mine was modded and you can't fire and forget with Subarus (you can, but it will eventually catch you out).

Testing Out Dockge

I've decided to give Dockge a test run.

I installed it on the Rasberry Pi 500+ (as I also did with Arcane).  It's simplistic.  Sometimes I think Portainer is a bit too busy.  Arcane is less so, and Dockge is lesser so.

One thing I like about Dockge is that it is also designed to work as an agent.  I wanted to also manage the containers that I'm hosting on a non-Pi device (there are mabye 7-8 containers on that host).  I installed Dockge on that machine and then pointed the Pi Dockge console to it - it now shows containers that reside on two hosts!

Dockge was also created by the Uptime Kuma developer, as well, which is another great tool for a home lab.

Portainer Alternatives?

I've been using Portainer for a while now.  I'm not using it as efficiently as I should, but that's a discussion for another day.

I wanted to explore other alternatives to Portainer and landed on Arcane.

I had serious issues getting Arcane set up as a Docker instance, but there's an alternative method - I ran the following command:

curl -fsSL https://getarcane.app/install.sh | sudo bash

No, this does not leverage Docker, but I was frustrated in getting Arcane to run within a container.  I'll double back to get that working later.

What I like is that Arcane detects all the pre-existing containers.  I didn't have to set anything up.

One thing I've noticed is that, when I restarted a Wordpress container, Arcane froze and wouldn't let me back in.  As I was going to restart the Arcane service, it came back up.  Arcane is running on a Pi 500, but it is pretty robust as far as Pis go.

Another thing - I'm unable to see the containers' compose files from the Arcane console.  Maybe I'm not looking in the correct areas of the console.  This is something to research.

The very cool thing is that Arcane has security findings if you enable container security scanning!  I think it's using the Trivy scanner.  As well, if you click on a discovered CVE, it points directly to the NIST CVE entry.

I'll also be testing Dockge, Dokploy, Coolify, and Dockhand, as well.  I'll share my thoughts as I test.

Uptime Kuma Has No Built-In Backup Strategy!

I've been using Uptime Kuma to monitor my LAN and external systems.

I'd noticed that Uptime Kuma had an update.  I was hesistant to apply the update because I might lose my configuration data, but tried it anyways.  Yeah, I lost everything.

I'd looked into the settings to see if there was a backup strategy but didn't see anything.

I used AI to determine if there was an alternative backup solution.  The AI stated that the Uptime Kuma (UK) developer had issues with a configuration backup solution and had reverted what existed.

I asked it to give me a script to use as a backup solution.  Based on the Docker compose file that I'm using (which I provided to the AI), it presented me this:

#!/bin/bash

# --- CONFIGURATION ---

CONTAINER_NAME="uptime-kuma"

#SOURCE_DIR="/app/data" # Or your specific host path found in Step 1

SOURCE_DIR="/data/compose/28/uptime-kuma-data"

BACKUP_DIR="/opt/stacks/backups/uptime-kuma"

TIMESTAMP=$(date +"%Y%m%d_%H%M%S")

BACKUP_NAME="kuma_backup_$TIMESTAMP.tar.gz"

RETENTION_DAYS=30

# ---------------------

# Ensure backup directory exists

mkdir -p "$BACKUP_DIR"

echo "Starting Uptime Kuma backup..."

# 1. Stop the container to freeze the SQLite DB safely

docker stop "$CONTAINER_NAME"

# 2. Compress the data directory

tar -czf "$BACKUP_DIR/$BACKUP_NAME" -C "$(dirname "$SOURCE_DIR")" "$(basename "$SOURCE_DIR")"

# 3. Restart the container immediately

docker start "$CONTAINER_NAME"

# 4. Clean up backups older than X days

find "$BACKUP_DIR" -type f -name "kuma_backup_*.tar.gz" -mtime +$RETENTION_DAYS -exec rm {} \;

echo "Backup completed successfully: $BACKUP_DIR/$BACKUP_NAME"

I tested it several times.  There was an issue with the source directory values, which I sorted.  Once I sorted that, the script worked.

I then created a cron job for the script:

# Backup of Uptime-Kuma

0 2 * * 1 /usr/local/bin/backup-kuma.sh > /dev/null 2>&1

One cool option is that I can set the retention days for the backup data.  Anything older than 30 days, for example, gets removed.  That value can also be changed (it was initially set to backup on a daily basis).

I also asked the AI to present restoration steps, which it did.  I documented that for later use.  I will ask it, later, to create a script of the restoration steps.

That is my backup solution.

The backup solution is mainly so that I do not have to recreate the UK monitors if I lose them during an upgrade of Uptime Kuma.