diy
- Set up the runner user. Since I was using Podman, not Docker, I didn’t have to add it to the
docker
group. As root: - Allow that user to run commands via
systemctl
without logging in and launching them manually: - Use
machinectl
instead ofsu
to become theforgejo-runner
user. Without this, mostsystemd
commands will fail with theFailed to connect to bus: No medium found
message. I’m certain there’s a way to getsu
orsudo
to play nicely withdbus
but I had more interesting problems to solve today than this. - Run
podman-system-service
as theforgejo-runner
user: - Run the
forgejo-runner
program as theforgejo-runner
user. I lightly modified the standard forgejo-runner.service file:
Forgejo Runner in rootless Podman on Debian
I wanted to experiment with Forgejo’s Actions as a DIY alternative to GitHub Actions, using a nearby Raspberry Pi as a build server. I also wanted to deviate slightly from their Runner installation process by executing the Runner and rootless Podman as a regular, non-privileged user and without using the system-level systemctl
. It was pretty easy once I wrapped my head around it.
root# useradd --create-home forgejo-runner
This created user number 1001
on my system. Remember that number later when it’s time to configure systemd
.
root# loginctl enable-linger forgejo-runner
root# apt install systemd-container
root# machinectl shell forgejo-runner@
$ systemctl --user enable podman.socket
$ systemctl --user start podman.socket
$ cat > .config/systemd/user/forgejo-runner.service <<EOHD
[Unit]
Description=Forgejo Runner
Documentation=https://forgejo.org/docs/latest/admin/actions/
After=podman.socket
[Service]
ExecStart=/usr/local/bin/forgejo-runner daemon
ExecReload=/bin/kill -s HUP $MAINPID
# 1001 is the forgejo-runner user's UID
Environment="DOCKER_HOST=unix:///run/user/1001/podman/podman.sock"
# This user and working directory must already exist
WorkingDirectory=/home/forgejo-runner
Restart=on-failure
TimeoutSec=0
RestartSec=10
[Install]
WantedBy=default.target
EOHD
$ systemctl --user daemon-reload
$ systemctl --user enable forgejo-runner.service
$ systemctl --user start forgejo-runner.service
I rebooted my RPi to make sure it would start on its own and it did. Yay! Now I can run Forgejo Actions on my little server and everything works as documented.
Fixing the Casper Glow Light charger
Our Casper Glow Lights are nice. However, their charging bases are poorly made, and as seen in user reviews, they often break in a specific way. Inevitably, one or both of the little spring-loaded charging pins will permanently stick in the lowered position so that they don’t contact the charging elements on the light.

In this photo, the outer pin on the left sticks up a little above the charger’s base. When the light sits on this charger, that pin touches one of the light’s charging rings. The inner pin on the right is flush with the surface and doesn’t touch its corresponding charging ring.
That’s easy to fix. Rather than disassemble the base and try to mechanically repair the pin, I added a tiny glob of solder to the top of the pin. Then I used an emery board and trial and error to smooth it to a good height.

Ta-da! Now the Glow Light is charging away on the resuscitated charger.

After cleaning, the charger looks and acts like new, and I bet that cheap little solder glob will outlast the original spring mechanism.
Use local Git repos for personal work
I’ve heard a lot of online arguments about whether you should host your Git-based projects in GitHub or GitLab, but a lot of them miss an obvious option. Is this repo for your own personal work that you don’t intend to share with others? Great! You can host unlimited, free, completely private repositories on your own system. Here’s the complete process:
$ mkdir -p ~/src/myproject
$ cd ~/src/myproject
$ git init --bare
$ cd ~
$ git clone ~/src/myproject
$ cd myproject
There, you’re done. Now you have a 100% fully functional Git repo that doesn’t require a network connection and supports every single Git feature. Pull it, push it, branch it, revert it, whatever: it’s your own repo and you can do whatever you want with it. And you don’t have to sign up for anything, or agree to a Terms of Service, or share your work, or trust a company you don’t know very well.
If you want to move your repo to another server later, you can copy ~/src/myproject
to its new home via whatever means you find most convenient, use git remote set-url origin [...]
to point your existing work toward the new location, and then go on about your business as usual without changing any of your workflow.
GitHub and GitLab have a lot of nice features that may be totally irrelevant if you’re not collaborating with a team. Never forget that you can host Git projects yourself, easily and for free.
Oh, and if you do find yourself needing to work with a handful of people and don’t need all of the integration features of the commercial options, I highly recommend Gitea. It’s a tiny little service you can host yourself and it takes very few resources. I use it whenever I need my Git repo to be accessible across the Internet.