Posts

Recently, I noticed that whenever my server, banan, was rebooted, containers running under the git user did not automatically start. ❯ podman --version podman version 5.6.0 ❯ cat /etc/os-release NAME="AlmaLinux" VERSION="9.7 (Moss Jungle Cat)" ID="almalinux" ID_LIKE="rhel centos fedora" VERSION_ID="9.7" PLATFORM_ID="platform:el9" PRETTY_NAME="AlmaLinux 9.7 (Moss Jungle Cat)" ANSI_COLOR="0;34" LOGO="fedora-logo-icon" CPE_NAME="cpe:/o:almalinux:almalinux:9::baseos" HOME_URL="https://almalinux.org/" DOCUMENTATION_URL="https://wiki.almalinux.org/" BUG_REPORT_URL="https://bugs.almalinux.org/" ALMALINUX_MANTISBT_PROJECT="AlmaLinux-9" ALMALINUX_MANTISBT_PROJECT_VERSION="9.7" REDHAT_SUPPORT_PRODUCT="AlmaLinux" REDHAT_SUPPORT_PRODUCT_VERSION="9.7" SUPPORT_END=2032-06-01 Let’s investigate and fix this issue. After switching to the git user, I encountered the following error when trying to list the running containers: ...

Oops… I just accidentally pushed a git commit containing code with a secret in plain text to a remote repo! Though it’s a private repository, I want to clean this mess up for security best practice. So, let’s fix it! Here are the last two commits. The secret resides in one of the files from the “add argocd infra to git” commit. $ git log -2 commit fe7b0510edc4fb160a16421352ba598e3f62703e (HEAD -> main, origin/main, origin/HEAD) Author: kenno <kenno@example.com> Date: Sat Dec 20 00:59:36 2025 +1100 add argocd infra to git commit c5a75ae14cf3528db1fea7677e2bdb54167037cd Author: kenno <kenno@example.com> Date: Thu Dec 18 14:38:17 2025 +1100 add basic auth middleware to longhorn httproute Since the commit had already been pushed to a remote repository, simply “undoing” the commit locally is not enough; it is required to overwrite the remote history. ...

This is a short note that serves as a self-reminder on how podman can automatically change the ownership of a source volume to match the default UID and GID within the container. TL;DR: Use the :U suffix on the volume definition. The following is an example of the issue I had and how to apply the fix. First, let’s list the current ownership of the directory to be used as the source volume for the container. ...

I recently ran into a classic problem on my long-running Fedora installation: my /boot partition was full. Back when I set up the system (around Fedora 20), 400MiB was more than enough. Now, with modern kernels, it can barely hold two versions, let alone the default three that Fedora manages. This meant I couldn’t run system updates. The challenge was that my disk was partitioned with /dev/sda1 for /boot and /dev/sda2 as a single large LVM physical volume for my /root and /home filesystems. This setup prevents a simple resize of /dev/sda1. ...

While running an Ansible playbook on one of my servers from an Arch device, I encountered the following error: TASK [Gathering Facts] ***************************************************************************************************************************************************** [ERROR]: Task failed: Failed to connect to the host via ssh: ssh_askpass: exec(/usr/lib/ssh/ssh-askpass): No such file or directory Host key verification failed. It looks like the /usr/lib/ssh/ssh-askpass file doesn’t exit. To find out what package the missing file comes from, we can use pacman -F or pacman --files. ...