Grain

DietPi + Gitea: SQLite and CIFS Mount Installation Gotchas

Sun, 11 Feb 2024 23:44:00 +0000

Recently, I discussed with a friend how they organize their docker-compose stacks into their personal home lab.They told me they used Portainer to manage all their containers. So I decided to give it a go.

At first glance, it seemed similar to what I already had: a tmux session, with each docker-compose stack in its pane. But then I saw that you can setup a Portainer stack by pointing it to a Git repository. Now this is more appealing! Doing this allows the following:

Version controlled docker-compose.yaml files
Trigger stack update via the UI or webhook
Environment variables via the UI

I was sold!

I thought all I needed to do was install Portainer and Gitea, then set up some webhooks.

Planning

My home lab setup is simple: an old laptop with Ubuntu and a Raspberry Pi with DietPi. I run all my Docker workloads on the laptop and lightweight web applications on the Raspberry Pi. Both machines do not have a lot of storage, so files are store on my NAS via CIFS mounts. These mounts are accessed directly or mounted as volumes for Docker containers.

The plan was simple:

DietPi
- Install Portainer and connect to Ubuntu’s dockerd via TCP
- Install Gitea and create repos for each stacks
- Create webhooks on Portainer and trigger them from Gitea after each push
Ubuntu
- Keep everything the same, except create git repos for each stack and publish to Gitea

Execution

As expected, things didn’t go according to plan. DietPi makes it super simple to install software, but when you need to deviate…it is HELL!

Problems and Solutions

Without a doubt, following the default instructions on the DietPi website will get Gitea up and running in under 5 minutes.

To be clear, we’re installing Gitea on a Raspberry Pi running the DietPi distribution. We will be using SQLite as our database and storing all of Gitea’s files on a CIFS mount.

If you’re following this as a guide, now is the time to install Gitea using dietpi-software. But hold off on anything else; we’ll need to tweak a few things.

Here’s the list of changes that were required to make this all work.

Setup `gitea` user

The gitea is setup without shell access, but it needs it ¯\(ツ)/¯.

To solve this, execute the command:

$ useradd -s ${SHELL} gitea

You may encounter LC_LANG warnings. To address these, run:

$ locale-gen
Generating locales (this might take a while)...
  en_US.UTF-8... done
Generation complete.

CIFS Mount Permissions

This change will allow Gitea to create directories in our CIFS mount.

DietPi includes a useful tool for mounting external drives, named dietpi-drive_manager. Use it to connect your network drive.

DietPi uses systemd to manage mounts, with /etc/fstab serving as the key reference.

Our initial step is to assign ownership of the CIFS mount to the gitea user. This is done by setting the uid option to gitea.

#----------------------------------------------------------------
# NETWORK
#----------------------------------------------------------------
//192.168.1.33/git-hosting /mnt/git-hosting cifs cred=/var/lib/dietpi/dietpi-drive_manager/mnt-git-hosting.cred,iocharset=utf8,uid=gitea,gid=dietpi,file_mode=0770,dir_mode=0770,vers=2.1,nofail,noauto,x-systemd.automount

To play it safe, let’s keep the gid as dietpi. This precaution ensures that other processes running under dietpi can still modify the directory if needed.

Remember to run systemctl daemon-reload whenever you change fstab.

To check if it worked, look at the directory’s owner with:

$ ls -lah /mnt/git-hosting
total 4.0K
drwxrwx--- 2 gitea dietpi    0 Feb  9 03:53 .
drwxr-xr-x 7 root  root   4.0K Feb  9 04:27 ..
drwxrwx--- 2 gitea dietpi    0 Feb  9 03:53 @Recycle
drwxrwx--- 2 gitea dietpi    0 Feb  9 03:56 gitea

SQLite on a CIFS mount

Using SQLite on a CIFS mount is optional. You might prefer to use the MySQL database that DietPi recommends and comes pre-installed.

If you place the database in a CIFS mount, you’ll get errors about the database being locked. This is a known issue and the workaround is to mount the CIFS mount with the nobrl option.

Don’t use nobrl as the default, this option prevents file locking. Multiple users modifying the same files could lead to corruption.

To enable this, let’s modify /etc/fstab by adding this option. Follow the same steps above, now my entry looks like so:

#----------------------------------------------------------------
# NETWORK
#----------------------------------------------------------------
//192.168.1.33/git-hosting /mnt/git-hosting cifs cred=/var/lib/dietpi/dietpi-drive_manager/mnt-git-hosting.cred,iocharset=utf8,uid=gitea,gid=dietpi,file_mode=0770,dir_mode=0770,vers=2.1,nofail,noauto,nobrl,x-systemd.automount

Lastly, run systemctl daemon-reload to save changes.

For more context, check out Lee Cheng Hui’s blog post.

Dropbear SSH Server

Although DietPi recommends Dropbear for SSH, it doesn’t seem compatible with Gitea’s SSH logins.

To fix this, run dietpi-software > SSH Server > OpenSSH Server.

Although OpenSSH Server is noted to use more resources, it was necessary for my setup to function correctly.

Access Local Ports from Portainer

After installing Portainer on DietPi with dietpi-software, I encountered an issue: Portainer couldn’t access the Gitea server on the same machine.

Gitea is running directly on the Raspberry Pi, while Portainer is running in a Docker container. Here’s Gitea’s Portainer install script. Portainer performs basic checks, essentially boiling down to a Docker run command flagged with restart=always.

We can choose to forgo DietPi’s version and run this ourselves or modify the dietpi-software script.

I chose to modify.

vim /boot/dietpi/dietpi-software

Whichever your choice is, you need to update the docker run command by adding --add-host=host.docker.internal:host-gateway. This will allow processes running inside Docker containers to access hosts’ processes via host.docker.internal instead of localhost.

My command now looks like this:

G_EXEC_OUTPUT=1 G_EXEC docker run -d -p '9002:9000' --add-host=host.docker.internal:host-gateway --name=portainer --restart=always -v '/run/docker.sock:/var/run/docker.sock' -v 'portainer_data:/data' 'portainer/portainer-ce'

Again, you can simply run this command without modifying the script.

Completing Gitea Setup

We haven’t finished setting up Gitea yet. Please visit the Gitea URL on port 3000 to complete the process. You can now select SQLite as the database and opt to store all of Gitea’s data on the CIFS mount.

You will need to create a user, which will become the administrator of the Gitea instance. Create a repository with a docker-compose.yaml and you should be good to go!

Webhooks on Portainer and Gitea

With a Gitea repository ready, you can add a stack as follows:

Then enable GitOps, to reveal the webhook link.

The webhook url may have a host using your .local address. This didn’t work for me, so I replaced that with 127.0.0.1 when adding it on Gitea’s webhook settings.

Conclusion

After applying all these changes, we can now commit changes to docker-compose.yaml files push them to Gitea and have it trigger a stack reload if there were any changes.

Discovering all these issues set me back a whole afternoon, if this helps at least one person it was time well spent :D

Snap Docker Read-Only Error

Fri, 09 Dec 2022 01:30:00 +0000

I repurposed a laptop with a broken display as an Ubuntu server on my local network. I did the installation via the Ubuntu live USB wizard and opted to have it install Docker. I didn’t realize that this would install it via snap.

Why is this a problem?

Honestly, it wasn’t.

Until I attempted to mount a volume bound to a directory under /opt/. I kept getting this error:

docker: Error response from daemon: error while creating mount source path '/cache': mkdir /cache: read-only file system.

I tried the following:

Create the directory with my $USER and as root
Give the directory 777 access permissions
Verified that there was enough space in the partition

Nothing worked.

Solution

Completely remove the Docker snap

sudo snap stop docker
sudo snap remove docker

Then install Docker using the official installation instructions.

Change Keyboard Layout on WSL2 for X11 Apps

Fri, 08 Jul 2022 16:48:00 +0000

For better or worse (worse really), I use the dvorak keyboard layout. Typically, I manage the layout using the Operating System, which means my physical keyboard is a normal qwerty layout keyboard and it changes to dvorak via software. However, I recently started using an ErgoDox EZ and chose to flash the keyboard’s firmware to map physical keyboard to the dvorak layout. I can now plug in this keyboard on any machine, and, without change the OS settings, the keyboard will be in dvorak as expected. NICE!

This worked well up until I tried using Emacs via X11 on WSL2. Ubuntu set my keyboard layout as dvorak (probably something I set up and forgot about it), so when using the ErgoDox, none of the keys mapped to the correct value.

Solution

To solve this, install X11 XKB utilities and use setxkbmap to manually change the keyboard layout:

sudo apt-get install x11-xkb-utils

# Change the layout to qwerty
setxkbmap us

# Change the layout back to dvorak
setxkbmap us -variant dvorak

I use x410 to manage the X11 display server, highly recommended. They also have a cookbook on managing your keyboard layout.

Migrate H2 from 1.x.y to 2.x.y

Tue, 01 Mar 2022 00:00:00 +0000

If you have seen the following error:

[HY000][50000] General error: "The write format 1 is smaller than the supported format 2 [2.1.210/5]" [50000-210]
The write format 1 is smaller than the supported format 2 [2.1.210/5].

You probably upgraded your H2 dependency from 1.x.y to 2.x.y due to a suggestion from Dependabot, like this one:

While I’m glad these alerts exist, there’s little information on how to update your existing H2 database.

Solution

I’ve gone about this by doing the following steps:

Create a backup of the v1 H2 database
Create a new database v2 H2 database with that backup

Download H2 Lib

The tricky part is that you must use the correct library version for this to work out, but otherwise it’s a straightforward process. Let’s begin by obtaining the H2 jar from Maven Central, we’ll need both v1 and v2:

# Download v1
curl -Lo h2-v1.jar https://search.maven.org/remotecontent\?filepath\=com/h2database/h2/1.4.200/h2-1.4.200.jar

# Download v2
curl -Lo h2-v2.jar https://search.maven.org/remotecontent\?filepath\=com/h2database/h2/2.1.210/h2-2.1.210.jar

Create Backup SQL Script

Please create a backup of your current H2 database at this time, it would be a shame if it got deleted.

The H2 library contains a tool called Script that we will use to generate the backup.sql script:

# For a set of all possible options, run with -help
java -cp h2-v1.jar org.h2.tools.Script -url "jdbc:h2:file:path/to/database/h2.db" -script backup.sql

I’d take a quick peek at the backup.sql file just to make sure the data is there, but otherwise we’re done with this step.

Create new database from SQL Script

Just like with the tool above, there’s a tool to run a script called RunScript that we will use to create a new database from backup.sql:

# For a set of all possible options, run with -help
java -cp h2-v2.jar org.h2.tools.RunScript -url "jdbc:h2:file:path/to/database/h2-v2.db" -script backup.sql

This should create a new H2 database as h2-v2.db. At this point, change your application to use this database, if everything works well, then you can delete the old one and rename the new one.

Enjoy!

Java Localization: Indonesia

Tue, 24 Aug 2021 00:16:00 +0000

Recently, I went through the exercise of externalizing the strings on a Discord bot, pawa, so that I can provide different translations. Since this is a JVM code base, the preferred path is to use a ResourceBundle. This would allow me to have different Properties files for each of the languages that the application would support, and as long as these Properties files are located in the classpath, the getBundle method will find the correct one to load.

In a contrived example, this is how it would work:

fun main() {
  // Default Bundle
  var bundle = ResourceBundle.getBundle("strings")
  var greeting = bundle.getString("greeting")

  println("greeting = $greeting")
  //=> greeting = hello

  // Spanish Bundle
  bundle = ResourceBundle.getBundle("strings", Locale("es"))
  greeting = bundle.getString("greeting")

  println("greeting = $greeting")
  //=> greeting = hola
}

You can use built in locales such as Locale.CHINESE or you can specify your own as I did in the example above. The only requirement is that you stick to the ISO-639 language codes. While the Locale constructor will accept 2-letter codes, it’s best to use the 3-letter code as it’s less ambiguous.

Incorrect Indonesian Language Code

When I was adding support for the Indonesian language, I made the mistake of using the language code id code. I structured my resources as follows:

❯ exa -T src/main/resources
src/main/resources
├── strings.properties
├── strings_es.properties
└── strings_id.properties

I did that because if you go to the Indonesian language wikipedia page, it that the code is id.

And this is the code snippet with the result:

  // Indonesian Bundle
  bundle = ResourceBundle.getBundle("strings", Locale("id"))
  greeting = bundle.getString("greeting")

  println("greeting = $greeting")
  //=> greeting = hello

🤔 hmmm, the result should’ve been greeting = halo, however that’s not what I was seeing here.

This was confusing because, the locale object was correctly printing out the right language:

Locale("id").displayName //=> Indonesian

So what was going on?

Read the Docs

In the Locale documentation there’s a line that talks about deprecated ISO codes:

Deprecated ISO language codes “iw”, “ji”, and “in” are converted to “he”, “yi”, and “id”, respectively.

Which appears in the private static method Locale.convertOldISOCodes

private static String convertOldISOCodes(String language) {
    // we accept both the old and the new ISO codes for the languages whose ISO
    // codes have changed, but we always store the OLD code, for backward compatibility
    language = LocaleUtils.toLowerString(language).intern();
    if (language == "he") {
        return "iw";
    } else if (language == "yi") {
        return "ji";
    } else if (language == "id") {
        return "in";
    } else {
        return language;
    }
}

The confusing part was that I wasn’t specifying in but rather id. So something somewhere was over correcting for me, as we can see in the function above, id is converted to in.

So…could I rename the resource strings_id.properties to strings_in.properties and call it a day? Let’s try it!

❯ exa -T src/main/resources
src/main/resources
├── strings.properties
├── strings_es.properties
└── strings_in.properties

  // Indonesian Bundle
  bundle = ResourceBundle.getBundle("strings", Locale("id"))
  greeting = bundle.getString("greeting")

  println("greeting = $greeting")
  //=> greeting = halo

AHA!

Solution

So while that works, it’s misleading and may cause errors if…when I forget why I did that in the first place, so my final solution is to use the 3-letter code as specified in the ISO-639-2 Standard. Finally landing on this:

❯ exa -T src/main/resources
src/main/resources
├── strings.properties
├── strings_es.properties
└── strings_ind.properties

  // Indonesian Bundle
  bundle = ResourceBundle.getBundle("strings", Locale("ind"))
  greeting = bundle.getString("greeting")

  println("greeting = $greeting")
  //=> greeting = halo

Migrating to Cloudflare Pages

Thu, 19 Aug 2021 00:30:00 +0000

When I first created this blog in 2015 😱, I spent a lot of time bike shedding on questions like:

Which blogging platform should I use?
Where should I host this?
How should I go about hosting it?
Where should I host it?

I made decisions based on what I thought I knew, but now it’s been 7 years and some processes have too much overhead. Let’s look at each decision point and how I changed it to reach our ultimate goal of moving this whole thing to Cloudflare Pages.

Choosing a blogging platform

Initially, I tried using the Ghost blogging platform, but ended up turning into a nightmare because, while it was straightforward to get started, I needed to host this somewhere, and it was more maintenance than I cared for at the time.

After that, I realized that all I needed was a simple Static Site Generator (SSG), so switched over to Jekyll which is still true to date.

I began with Jekyll 3.4.0 inching my way to present day and landing on Jekyll 4.2.0.

Jekyll is straightforward:

Create a markdown file with front-matter
Put it in the _posts directory
Run jekyll build
Bam! Outcomes a static site under _site

I did spend a bit of time looking for a theme, and landed on gets, which I customized a bit.

The only issue here was that because I was dead set on using Windows, I created wrapper scripts that would execute Ruby commands inside a Docker container. This wasn’t ideal but it worked.

Hosting

This is where most of the complexity begins. At the time, GitHub Pages with Jekyll was well-supported, but I didn’t want to host both the source and blog on the same platform. So instead I went to AWS S3.

Hosting in AWS S3 is simple enough, all one has to do is create a public bucket and drop the static site in it.

At this point, we need to create a CNAME in Name.com and the blog will live!

HTTPS

The issue with the setup above, is that if I wanted to use HTTPS, I needed to add yet another layer – Amazon CloudFront.

At this point, I should’ve turned around and reevaluated my decision, but instead I pressed on!

In addition to this new layer, I also needed an SSL certificate for my domain, so I had two options:

Buy one
Use Let’s Encrypt

I opted to go with Let’s Encrypt, which is a great service that provides free SSL certificates. The only gotcha is that they only last 90 days.

Once I created the CloudFront distribution, I used a Python CLI tool to generate and update the SSL certificates. Everything worked great! This commands needs to run every 90 days.

Continuous Deployment

Copying files to S3 by hand isn’t that bad, but I wanted the ability to simply push to the main branch and have something build the static files and push them to S3. Given how many blog posts I have written, this was definitely a waste of time 😅.

At that time, GitHub Actions wasn’t a thing, so I added TravisCI to the mix. Their documentation was great, so it was trivial to get started.

Where I went wrong is that I opted to use a Ruby Gem called s3_website that facilitated uploading files to the S3 bucket and invalidating the CloudFront cache. This all sounds great, but at some point this gem became unsupported, and it started to fail, leading to some issues and needed a workaround.

It all still worked!

Maintenance

There are some inactive resources that I must be aware of but don’t require any changes:

S3 Bucket
CloudFront distribution
TravisCI build scripts

But there’s one piece that requires active maintenance:

Renew Let’s Encrypt certificates every 90 days

Simple, right? NO!

Problems

Perhaps, I’m the problem here, and maybe I could’ve automated the process. However, since it was only run every 90 days, I would often forget some steps.

Yes, I did take notes. Yes, I scripted most of it. Yet, something would fail.

Wrong Python version
Wrong package version
Package deprecated and/or renamed
Wrong AWS credentials

So this week, I realized that most of my stack was obsolete, and I could move or eliminate parts of it. It was much simpler than I originally anticipated.

The Great Migration

Before I started any work, I took tally of the pieces that needed to change:

Blogging platform
- Unchanged
- Technically, I did upgrade the version of Jekyll, but that was unnecessary.
Hosting
- S3 ➔ Cloudflare Pages
  - I recently switched my domain name registrar from Name.com to Cloudflare, so this was an obvious choice
HTTPS
- CloudFront ➔ Cloudflare
  - Cloudflare would handle both the CDN and ensuring an up-to-date SSL certificate.
Continuous Deployment
- TravisCI ➔ Cloudflare Pages
  - Done via GitHub integration, Pages listens for changes on main branch, builds site and publishes it

As you can see, Cloudflare can handle most of the Ops side.

Cloudflare Pages

It was surprising how simple it was to get this going. To onboard onto Cloudflare Pages, I registered the Cloudflare Pages app with GitHub to give it access to the blog source. Then entered the build command and that was it!

This took care of the Continuous Integration and eliminated the need for S3-type of code hosting. I don’t know where the build artifacts are, and I don’t need to know.

Cloudflare Pages serves traffic via HTTPS and when using Cloudflare DNS to route the CNAME to the Pages location, it all just works. This eliminates the need for manually managing a Let’s Encrypt certificate. I don’t know where the certificate comes from, but it is a valid one and that’s all I need to know.

Maybe now I won’t have an excuse to not write :)

Less is More

That’s all!

If you have a process that you haven’t touched in some time, I urge you to take a second look. It may be simpler to update and improve than you think.

ripgrep (rg)

Sat, 06 Apr 2019 20:00:00 +0000

On a previous post I talked about how The Silver Searcher was a very fast way to search through a codebase. I was made aware of a different tool called ripgrep.

Let me just post this for comparison:

❯ rg -t clojure --stats -q main
matches
matched lines
files contained matches
files searched
bytes printed
1785713 bytes searched
171875 seconds spent searching
446368 seconds

❯ ag --clojure --stats-only main
matches
files contained matches
files searched
3435452 bytes searched
404591 seconds

Just, wow.

Yes, yes I see that ag searched in more files, this is because it didn’t fully understand .gitignore files.

I don’t think there’s much I can add to this except go try it out! It did take me some time to get used to the new CLI options but just read the manual and it’ll take care of you.

An Alternative to grep

Thu, 31 Jan 2019 00:00:00 +0000

As mentioned in the comments by @samatjain, ripgrep is a much faster alternative to both the_silver_searcher and ack. I’ve left this here for historical purposes.

If you spend any amount of time using a terminal, you have more than likely used grep to search for phrases or words in a pile of text files. grep is a great tool and it’s installed by default on many servers, but if you’re a developer, grep doesn’t do much aside from a simple text search.

As they say, you gotta use the right tool for the job, for this ack is the tool that’s very commonly recommended, but it’s less commonly installed. Since we’re already needing to install something, I recommend using The Silver Searcher.

The Silver Searcher

Before adding The Silver Searcher (ag) to my toolset, I hadn’t heard of ack, so if you haven’t heard of it yourself, don’t fret. In fact, both ag and ack share the same API so using one will give you the same muscle memory as the other. But if you’re already using ack, I’d recommend trying it out for it’s performance:

Ack and Ag found the same results, but Ag was 34x faster (3.2 seconds vs 110 seconds). My ~/code directory is about 8GB. Thanks to git/hg/ignore, Ag only searched 700MB of that.

Let’s get to it.

Installing

Getting this on macOS is just a brew command away:

brew install the_silver_searcher

On WSL, since it’s just Ubuntu you can do this:

sudo apt install silversearcher-ag

For other operating systems (even Windows), check out the manual.

As simple as that, if you’re comfortable with ack then you can stop here, and reap the benefits of ag’s increased performance!

Examples

Rather than going into the commands, let’s just dive into some examples of how I use ag which might provide some useful patterns.

Find Usages

Let’s say you’re exploring a codebase and want to know the usage of a function, main:

ag --clojure main

Which gives you this result:

❯ ag --clojure main
project.clj
7:  :main ^:skip-aot silver-demo.core

src/silver_demo/core.clj
4:(defn -main

ag ignores searching directories related to version control (.git, .hg) and because we provided a language flag, --clojure, then only Clojure files will be searched. In this case, there are two matches, we get the file path and the line number of where that word was found.

That’s it!

I find myself using this pattern most of the time, IDEs can also do this, but doing this across multiple projects or a big codebase is rarely a good experience.

Stats

Sometimes you don’t need to know where certain matches are, just that they exist and how many. Using the --stats-only flag will do just that.

Let’s try the same query on a much much larger

❯ ag --clojure --stats-only main
142 matches
35 files contained matches
149 files searched
649117 bytes searched
0.086319 seconds

Conclusion

I described a few use cases for the Silver Searcher (ag), I would urge you to try this out and see if it fits in your terminal toolbox. grep is great for some use cases, but if you’re searching through code a lot, consider installing ag.

Using Metabase with Docker and SQLite

Tue, 01 Jan 2019 00:00:00 +0000

Metabase, is an application that connects to a existing database allowing you to run analytics and create charts from their web application.

One of the great things about Metabase is that you can self-host it! Today, we’re specifically looking at the Running Metabase on Docker instructions.

Following the guide, I run Metabase as prescribed and load a small SQLite database:

docker run --rm -p 8080:3000 -v $PWD/data/settings.db:/opt/data.db metabase/metabase

Since it’s a SQLite database, the container needs to have physical access to the file

The Metabase application starts on http://localhost:8080 and I am able to begin with the setup. However, as soon as I submit the initial form, Metabase crashes.

01-01 20:59:28 DEBUG analyze.fingerprint :: Saving fingerprint for Field 55 'name'
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x000000000000a786, pid=1, tid=0x00007f8984a4cae8
#
# JRE version: OpenJDK Runtime Environment (8.0_181-b13) (build 1.8.0_181-b13)
# Java VM: OpenJDK 64-Bit Server VM (25.181-b13 mixed mode linux-amd64 compressed oops)
# Derivative: IcedTea 3.9.0
# Distribution: Custom build (Tue Oct 23 11:27:22 UTC 2018)
# Problematic frame:
# C  0x000000000000a786
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /tmp/hs_err_pid1.log
#
# If you would like to submit a bug report, please include
# instructions on how to reproduce the bug and visit:
#   http://icedtea.classpath.org/bugzilla
#

But we can’t stop there!

At a first glance, I didn’t know what the issue could be, but I got curious as to how this image was built, so I checked out the Github repo. I noticed that the base image used to run Metabase is Alpine based, openjdk:8-jre-alpine. So that could be the issue!

I came up with this minimal Dockerfile:

FROM openjdk:8-jre-slim

ENV VERSION 0.31.2

WORKDIR /app

ADD https://raw.githubusercontent.com/metabase/metabase/v$VERSION/bin/start /app/bin/
ADD https://downloads.metabase.com/v$VERSION/metabase.jar /app/target/uberjar/

CMD ["bash", "/app/bin/start"]

And it worked!!!

So now the full command to use this image would be:

docker build -t metabase/metabase:v0.31.2-custom -f Dockerfile .
docker run --rm -p 8080:3000 -v $PWD/data/settings.db:/opt/data.db metabase/metabase:v0.31.2-custom

This should get give you a Metabase instance that’s able to load your SQLite database, I’m currently running that on my server with no issues. If you find a better way to go about this, I’m all ears!

I searched the Github Issues for anything related to this, but there’s only one result that’s not this problem, so this could be an issue with my configuration alone.

Batch Rename using PowerShell

Sat, 22 Jul 2017 00:00:00 +0000

This is more of a self-documenting post, as it doesn’t come up often but when it does, it’s not immediately trivial. I’m talking about batch renaming a bunch of files in a folder.

In my particular case, I wanted to make this change:

Desktop 06.17.2017 - 22.34.02.01.mp4 -> Ori of the Blind Forest 06.17.2017 - 22.34.02.01.mp4

So it’s a simple prefix change. Normally, I stay stick to using Command Prompt in Cmder. If you haven’t used this on Windows, it makes Command Prompt much more usable. It includes some of the command line tools our friends in Linux land enjoy. Anyway, for a task like this PowerShell is a much more apt tool because of its extensive built-in commands.

TL;DR

If you want to replace the prefix (or any other part) of a filename with another type this command:

dir | Rename-Item -NewName {$_.name -replace "old-text","new-text"}

Explanation

Let’s breakdown the commands used here:

Get-ChildItem
|
Rename-Item
{...}

First, Get-ChildItem is aliased to dir, but what that command does is output every item in the current directory as an item. The |, or pipe, is used to pass each Item to the Rename-Item command.

Rename-Item has the following anatomy (simplified for this use case):

Rename-Item [-Path] <String> [-NewName] <String>

The [-Path] is coming from dir and [-NewName] is the result of the script block — {...}. The script block is an anonymous function that executes in place, in this case it is using the automatic variable, $_, which is an Item that came from the pipe. The function calls the .name attribute which returns a String, then we can call it’s -replace flag which will do what we want.

If we execute this command:

Rename-Item -NewName {$_.name -replace "Desktop","Ori of the Blind Forest"}

Taking this step by step and execute dir:

M:\Media\Videos\ShadowReplay\Ori of the Blind Forest
λ  dir

    Directory: M:\Media\Videos\ShadowReplay\Ori of the Blind Forest

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----        6/17/2017  10:34 PM       12703402 Desktop 06.17.2017 - 22.34.02.01.mp4

So then the command past the pipe will look like this:

Rename-Item Desktop 06.17.2017 - 22.34.02.01.mp4 -NewName {Desktop 06.17.2017 - 22.34.02.01.mp4 -replace "Desktop","Ori of the Blind Forest"}

Then finally reducing to:

Rename-Item Desktop 06.17.2017 - 22.34.02.01.mp4 -NewName Ori of the Blind Forest 06.17.2017 - 22.34.02.01.mp4

I hope this helps someone, I know it’ll definitely help me in the future!

Grain

DietPi + Gitea: SQLite and CIFS Mount Installation Gotchas

Planning

Execution

Problems and Solutions

Setup gitea user

CIFS Mount Permissions

SQLite on a CIFS mount

Dropbear SSH Server

Access Local Ports from Portainer

Completing Gitea Setup

Webhooks on Portainer and Gitea

Conclusion

Snap Docker Read-Only Error

Solution

Change Keyboard Layout on WSL2 for X11 Apps

Solution

Migrate H2 from 1.x.y to 2.x.y

Solution

Download H2 Lib

Create Backup SQL Script

Create new database from SQL Script

Java Localization: Indonesia

Incorrect Indonesian Language Code

Read the Docs

Solution

Migrating to Cloudflare Pages

Choosing a blogging platform

Hosting

HTTPS

Continuous Deployment

Maintenance

Problems

The Great Migration

Cloudflare Pages

Less is More

ripgrep (rg)

An Alternative to grep

The Silver Searcher

Installing

Examples

Find Usages

Stats

Conclusion

Using Metabase with Docker and SQLite

Batch Rename using PowerShell

TL;DR

Explanation

Setup `gitea` user