Posts

As promised on my previous post, on this entry I’ll explain how I’ve set up forgejo actions on the source repository of this site to build it using a runner instead of doing it on the public server using a webhook to trigger the operation. Setting up the systemThe first thing I’ve done is to disable the forgejo webhook call that was used to publish the site, as I don’t want to run it anymore. Note: For now I’ve just removed the Active flag from the webhook, just in case I want to use it again in the future. I’ve left the system based on the json2file server running as it does nothing if no webhook is called, if we want to use it again it would be a good idea to disable actions to avoid conflicts if something is pushed, but it can be executed manually if needed and nothing will break, as both systems use the same directories to publish things). After that I added a new workflow to the repository that does the following things: build the site using my hugo-adoc image.push the result to a branch that contains the generated site (we do this because the server is already configured to work with the git repository and we can use force pushes to keep only the last version of the site, removing the need of extra code to manage package uploads and removals).uses curl to send a notification to an instance of the webhook server installed on the remote server that triggers a script that updates the site using the git branch....

Last week I decided I wanted to try out forgejo actions to build this blog instead of using webhooks, so I looked the documentation and started playing with it until I had it working as I wanted. This post is to describe how I’ve installed and configured a forgejo runner, how I’ve added an oci organization to my instance to build, publish and mirror container images and added a couple of additional organizations (actions and docker for now) to mirror interesting actions. The changes made to build the site using actions will be documented on a separate post, as I’ll be using this entry to test the new setup on the blog project. Installing the runnerThe first thing I’ve done is to install a runner on my server, I decided to use the OCI image installation method, as it seemed to be the easiest and fastest one. The commands I’ve used to setup the runner are the following: $ cd /srv $ git clone https://forgejo.mixinet.net/blogops/forgejo-runner.git $ cd forgejo-runner $ sh ./bin/setup-runner.sh...

With all the recent buzz about DeepSeek and its capabilities, I’ve decided to give it a try using Ollama and Open WebUI on my work laptop which has an NVIDIA GPU: $ lspci | grep NVIDIA 0000:01:00.0 3D controller: NVIDIA Corporation GA107GLM [RTX A2000 8GB Laptop GPU] (rev a1) For the installation I initially I looked into the approach suggested on this article, but after reviewing it I decided to go for a docker only approach, as it leaves my system clean and updates are easier. Step 0: Install dockerI already had it on my machine, so nothing to do here. Step 1: Install the nvidia-container-toolkit packageAs it is needed to use the NVIDIA GPU with docker I followed the instructions to install the package using apt from the NVIDIA website. Step 2: Run the Open WebUI container bundled with OllamaI could install ollama directly on linux or run it on docker, but I found out that there is a container with Open WebUI bundled with Ollama, so I decided to use it instead. To start the container I’ve executed the following command: docker run -d \ -e OLLAMA_HOST="0.0.0.0:11434" -p 127.0.0.1:11434:11434 \ -p 127.0.0.1:3000:8080 \ -v ollama:/root/.ollama \ -v open-webui:/app/backend/data \ --gpus=all --name open-webui --restart always \ ghcr.io/open-webui/open-webui:ollama...

Although I am a Debian Developer (not very active, BTW) I am using Ubuntu LTS (right now version 24.04.1) on my main machine; it is my work laptop and I was told to keep using Ubuntu on it when it was assigned to me, although I don’t believe it is really necessary or justified (I don’t need support, I don’t provide support to others and I usually test my shell scripts on multiple systems if needed anyway). Initially I kept using Debian Sid on my personal laptop, but I gave it to my oldest son as the one he was using (an old Dell XPS 13) was stolen from him a year ago. I am still using Debian stable on my servers (one at home that also runs LXC containers and another one on an OVH VPS), but I don’t have a Debian Sid machine anymore and while I could reinstall my work machine, I’ve decided I’m going to try to use a system container to run Debian Sid on it. As I want to use a container instead of a VM I’ve narrowed my options to lxc or systemd-nspawn (I have docker and podman installed, but I don’t believe they are good options for running system containers). As I will want to take snapshots of the container filesystem I’ve decided to try incus instead of systemd-nspawn (I already have experience with it and while it works well it has less features than incus). Installing incusAs this is a personal system where I want to try things, instead of using the packages included with Ubuntu I’ve decided to install the ones from the zabbly incus stable repository. To do it I’ve executed the following as root: # Get the zabbly repository GPG key curl -fsSL https://pkgs.zabbly.com/key.asc -o /etc/apt/keyrings/zabbly.asc # Create the zabbly-incus-stable.sources file sh -c 'cat <<EOF > /etc/apt/sources.list.d/zabbly-incus-stable.sources Enabled: yes Types: deb URIs: https://pkgs.zabbly.com/incus/stable Suites: $(. /etc/os-release && echo ${VERSION_CODENAME}) Components: main Architectures: $(dpkg --print-architecture) Signed-By: /etc/apt/keyrings/zabbly.asc EOF'...

For a long time I’ve been using the Terminator terminal emulator on Linux machines, but last week I read a LWN article about a new emulator called Ghostty that looked interesting and I decided to give it a try. The author sells it as a fast, feature-rich and cross-platform terminal emulator that follows the zero configuration philosophy. Installation and configurationI installed the debian package for Ubuntu 24.04 from the ghostty-ubuntu project and started playing with it. The first thing I noticed is that the zero configuration part is true; I was able to use the terminal without a configuration file, although I created one to change the theme and the font size, but other than that it worked OK for me; my $HOME/.config/ghostty/config file is as simple as: font-size=14 theme=/usr/share/ghostty/themes/iTerm2 Solarized Light...