Software on dev@iostream.pl

Seek & Destroy

Sat, 25 Jul 2026 00:20:00 +0200

Every respectable text editor supports searching and replacing text, whether interactively or automatically. Editors from the upper shelves can also work with regular expressions.

And then there is the editor from the highest shelf — Emacs — which handles all of this brilliantly, in several different ways.

Searching

In an average text editor, searching for text requires pressing a keyboard shortcut. Alternatively, you can try to remember beneath which pile of debris on your desk the mouse is buried, move it around until the pointer appears, and click whichever button opens the appropriate dialog box.

Then you type the search term, confirm it, and the text is found. Thank you very much, and we hope to see you again during your next search.

But not in Emacs.

By default, the King of Editors provides incremental search. Pressing C-s — or invoking M-x isearch-forward — starts the search and waits for input in the minibuffer.

With every character you type, Emacs attempts to find the entire string entered so far and moves the cursor to the matching location in the text. The current match is highlighted by default. Any other occurrences visible in the buffer are highlighted as well, using a different combination of foreground and background colours.

The search string is remembered between searches. Pressing C-s again moves the cursor to the next occurrence of the current search string.

When Emacs reaches the end of the buffer, it displays an appropriate message in the minibuffer. Pressing C-s once more wraps the search around and continues from the beginning of the buffer.

Searching backwards

Incremental search also works backwards.

The C-r shortcut — or M-x isearch-backward — behaves just like forward incremental search, except that it moves in the opposite direction.

After reaching the beginning of the buffer, Emacs displays an appropriate message in the minibuffer. Pressing C-r again wraps the search around and continues from the end of the buffer.

Search results

Pressing M-s o during an incremental search — which invokes M-x isearch-occur — opens another window containing the search results: every line in which the requested phrase occurs.

The matching phrase is, naturally, highlighted so that it stands out. At the top of the window, Emacs displays a summary showing how many matches were found, on how many lines, and in which buffer.

More importantly, the results are navigable. Move to any entry and press RET, and Emacs takes you directly to the corresponding line in the original buffer.

Non-incremental search

What if someone simply wants to enter a complete search string first and then jump to its first occurrence?

A traditional, non-incremental search can be performed as follows:

C-s RET <search text> RET — or M-x search-forward — searches forwards,
C-r RET <search text> RET — or M-x search-backward — searches backwards.

In other words, it works much like incremental search, except that you press RET before entering the phrase.

Case sensitivity

By default, Emacs uses a convenient mechanism known as case folding.

As long as the search string contains only lowercase letters, Emacs ignores case and attempts to match as many occurrences as possible. As soon as you enter an uppercase letter, the search becomes case-sensitive.

During an incremental search, M-c toggles case sensitivity explicitly, so there is no need to introduce an uppercase letter merely to change the matching behaviour.

Searching with regular expressions

Emacs also provides both incremental and non-incremental searches based on regular expressions:

M-x re-search-forward searches forwards for the next piece of text matching the given regular expression. When a match is found, the cursor is moved to its end. If no match exists, Emacs displays an appropriate message in the minibuffer.
M-x re-search-backward performs the same operation in the opposite direction.
C-M-s — M-x isearch-forward-regexp — starts an incremental forward search using a regular expression.
C-M-r — M-x isearch-backward-regexp — starts an incremental backward search using a regular expression.

Searching within a region

By default, Emacs searches through the buffer. To limit a search to a particular region, one can use a small but extremely useful trick: narrowing.

Press C-x n n — or invoke M-x narrow-to-region — to narrow the buffer to the currently selected region.

This is interesting because the rest of the text temporarily disappears. All subsequent operations, including searching, are restricted to the visible part of the buffer.

Once the work is complete, press C-x n w — or invoke M-x widen — to restore the hidden text to its rightful place.

Search history

Search history is, of course, preserved.

While searching, you can use:

M-p to recall the previous search string,
M-n to move to the next search string in the history.

Other useful commands

C-y — M-x yank — inserts the most recently killed text into the search string, because why would it not?
C-w adds the remainder of the word at point to the search string.

Replacing

Once again, the King of Editors refuses to blend in with the crowd and offers something better than the competition.

M-% — M-x query-replace — interactively replaces occurrences of one string with another, starting from the position at which the command was invoked.

At every match, Emacs asks the user what should happen next:

y replaces the current match and moves to the next one,
n skips the current match and moves to the next one,
q ends the replacement operation,
! replaces the current match and every remaining match without asking any more unnecessary questions.

Other available actions can be found, for example, by invoking:

M-x describe-function RET query-replace RET

C-M-% — M-x query-replace-regexp — works in the same way, but uses regular expressions.

Emacs also tries to preserve the capitalisation style of the replaced text.

Suppose that every occurrence of windows must be replaced with linux. Emacs may perform the following replacements:

windows becomes linux,
Windows becomes Linux,
WINDOWS becomes LINUX.

The author believes that Windows should be replaced with Linux not only in this example, but also in the lives of us all.

Non-interactive replacement

Emacs also provides commands that replace all matching occurrences without asking for confirmation:

M-x replace-string replaces every occurrence of one string with another, starting from the position at which the command was invoked.
M-x replace-regexp replaces every piece of text matching the given regular expression with the specified replacement string, again starting from the current position.

Replacing within a region

If a region is active, Emacs performs replacement commands within that region by default.

There is no need to narrow or widen the buffer manually — although, naturally, Emacs will not prevent anyone from doing so.

Jenkins, Part Two: Disposable Agents and Builder Images

Sun, 12 Jul 2026 17:20:00 +0200

Once again: why all these containers?

The Kubernetes approach — short-lived, disposable things — works beautifully for Jenkins and similar CI/CD systems.

Here is a list of tasks to execute in a place described by a specification, not by a physical location. Whether that place existed five minutes ago or will disappear five minutes from now does not matter all that much.

Look at how the approach to running CI/CD jobs has evolved over the last twenty years:

run the job in a blocking shell script,
run the job directly on the Jenkins master,
run the job on a dedicated Jenkins node,
run the job on one of several dedicated Jenkins nodes.

And now?

run the job inside an ephemeral Pod, created just before the work starts and removed when the work is done.

Hard not to admire that, is it?

And there is more to admire. Each container can provide a different set of tools. Instead of installing everything manually on physical machines, you can point Jenkins at a ready-made image, built by someone else — and if you do not like that one, you can use another.

All right, that is enough admiration for now.

What do we already have?

Quite a lot:

Jenkins running under Kubernetes,
a working container registry,
a PVC for Jenkins data,
a Kubernetes cloud definition in Jenkins,
two already built images that we are about to use.

What else do we need?

Eventually, Jenkins will run jobs such as:

building Python applications,
building Go applications,
building Hugo sites.

So we need three images.

Python builder

The Python image can be built from the following Dockerfile:

FROM registry.lab.local/base-builder:0.1

USER root

RUN apt-get update && apt-get install -y --no-install-recommends \
 python3 \
 python3-pip \
 python3-venv \
 python3-build \
 && rm -rf /var/lib/apt/lists/*

RUN python3 -m pip install --break-system-packages \
 build \
 twine \
 wheel \
 setuptools \
 pytest \
 ruff

USER builder
WORKDIR /workspace

CMD ["sleep", "infinity"]

Wait a moment. Do not reach for docker build yet.

Actually, do not reach for it at all.

Put this Dockerfile into a source repository, preferably in a dedicated subdirectory. Later it will be much easier to tell what kind of creatures are being produced from it.

We are about to enable a tiny bit of magic. If you are not ready, perhaps take a short walk.

Jenkins can wait. That is, after all, usually its main job.

Create a Jenkinsfile with the following contents:

pipeline {
 agent {
 kubernetes {
 yaml '''
apiVersion: v1
kind: Pod
spec:
 hostAliases:
 - ip: "10.10.10.24"
 hostnames:
 - "registry.lab.local"
 containers:
 - name: base
 image: registry.lab.local/base-builder:0.1
 command: ["sleep"]
 args: ["infinity"]
 - name: kaniko
 image: registry.lab.local/kaniko-builder:latest
 command: ["sleep"]
 args: ["infinity"]
 volumeMounts:
 - name: docker-config
 mountPath: /kaniko/.docker
 volumes:
 - name: docker-config
 configMap:
 name: kaniko-docker-config
'''
 }
 }

 environment {
 IMAGE_NAME = 'registry.lab.local/python-builder'
 IMAGE_TAG = '3.11.1'
 }

 stages {
 stage('Prepare') {
 steps {
 container('base') {
 script {
 env.GIT_SHA = sh(
 script: 'git rev-parse --short HEAD',
 returnStdout: true
 ).trim()

 currentBuild.displayName = "#${env.BUILD_NUMBER} python-3"
 currentBuild.description = "python-builder:3, commit ${env.GIT_SHA}"
 }

 sh '''
 echo "IMAGE=${IMAGE_NAME}:${IMAGE_TAG}"
 ls -la
 '''
 }
 }
 }

 stage('Build and push image') {
 steps {
 container('kaniko') {
 sh '''
 /kaniko/executor \
 --context "${WORKSPACE}" \
 --dockerfile "${WORKSPACE}/python-builder/Dockerfile" \
 --destination "${IMAGE_NAME}:${IMAGE_TAG}" \
 --insecure \
 --skip-tls-verify \
 --insecure-registry registry.lab.local
 '''
 }
 }
 }
 }

 post {
 success {
 echo "Built and pushed ${IMAGE_NAME}:${IMAGE_TAG}"
 }
 }
}

Commit it to the same repository, in the same subdirectory as the Dockerfile.

The cluster needs one additional ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
 name: kaniko-docker-config
 namespace: jenkins
data:
 config.json: |
 {
 "auths": {}
 }

The Jenkinsfile refers to this ConfigMap in the agent section.

Now create a new Multibranch Pipeline job. Give it a sensible name, for example python-builder, and configure it:

enter the repository URL,
if credentials are required, select them, or add them first,
under Build configuration → Mode, make sure by Jenkinsfile is selected,
in Script Path, enter the path to the file, for example python-builder/Jenkinsfile.

Save the job and wait a moment.

Jenkins will start scanning branches in your repository, looking for the specified Jenkinsfile in each of them. If it finds one, it will try to run the job for that branch.

Once the Stage View starts rendering, you can observe what is happening in the jenkins namespace:

kubectl get pods -n jenkins -w

A new Pod will appear, do its job, and leave, as in the example below:

NAME READY STATUS RESTARTS AGE
jenkins-0 1/1 Running 12 (57m ago) 19d
python-builder-main-1-30xvv-l1cp7-vcw9m 0/3 Pending 0 0s
python-builder-main-1-30xvv-l1cp7-vcw9m 0/3 ContainerCreating 0 0s
python-builder-main-1-30xvv-l1cp7-vcw9m 3/3 Running 0 1s
python-builder-main-1-30xvv-l1cp7-vcw9m 3/3 Terminating 0 63s
python-builder-main-1-30xvv-l1cp7-vcw9m 0/3 Error 0 93s

The job completed successfully and the python-builder image landed in the registry.

You can verify that either through registry-ui or directly:

curl http://registry.lab.local/v2/python-builder/tags/list

The response should look like this:

{"name":"python-builder","tags":["3.11.1"]}

The image is now ready to use.

What just happened?

The contents of the Jenkinsfile definitely deserve an explanation, so let us start from the beginning.

`agent`

The agent section is without a doubt the most interesting part of this file.

Besides the type name, kubernetes, it contains a full Kubernetes Pod definition. In the specification we can see that:

hostAliases are used, because we do not have proper DNS here and still need to smuggle the registry address into the Pod,
all important containers are listed:
- base, which provides Git and basic shell tools,
- kaniko, which provides… well, kaniko.

Keeping the names consistent is important.

If you name the containers something like the_one_with_git and the_one_with_kaniko, you will have to use exactly those names later in the actual pipeline steps:

stages {
 stage('Prepare') {
 steps {
 container('the_one_with_git') {

In short: Jenkins creates an agent described in the agent section, and pipeline steps are executed inside specific containers from that Pod — the ones that provide the required tools.

This is the important part.

We are not installing build tools inside the main Jenkins server. The server only orchestrates work. The tools live in disposable containers, created only for the job that needs them.

That keeps the Jenkins controller cleaner, makes builds easier to reproduce, and avoids the traditional CI server problem where one machine slowly turns into a museum of forgotten compilers, package managers, SDKs, symlinks and emotional damage.

`kaniko`

Remember that kaniko is not Docker.

Its job is simply to build a container image and push it to a registry.

The important parameters are:

--context — the working directory, usually the job workspace,
--dockerfile — the location of the Dockerfile, in this case inside a subdirectory,
--destination — the registry location, image name and tag to push after the build.

Simple? Simple.

“But wait!” you might shout. “What about that mysterious kaniko-docker-config ConfigMap?”

Here it is.

kaniko likes to look inside /kaniko/.docker, mainly for a config.json file containing credentials, if they are required.

Our registry does not require authentication, but we still mount a ConfigMap there and provide an empty auths object:

{
 "auths": {}
}

This allows kaniko to try pushing the image anonymously right away.

Go builder

Not enough examples? Fine. Let us create a go-builder.

The Dockerfile could look like this:

FROM golang:1.26-bookworm

RUN apt-get update && apt-get install -y --no-install-recommends \
 git \
 openssh-client \
 ca-certificates \
 curl \
 wget \
 jq \
 make \
 rsync \
 && rm -rf /var/lib/apt/lists/*

RUN update-ca-certificates

USER root

WORKDIR /workspace

RUN go version

CMD ["sleep", "infinity"]

And the Jenkinsfile could look like this:

pipeline {
 agent {
 kubernetes {
 yaml '''
apiVersion: v1
kind: Pod
spec:
 hostAliases:
 - ip: "10.10.10.24"
 hostnames:
 - "registry.lab.local"
 containers:
 - name: base
 image: registry.lab.local/base-builder:0.1
 command: ["sleep"]
 args: ["infinity"]
 - name: kaniko
 image: registry.lab.local/kaniko-builder:latest
 command: ["sleep"]
 args: ["infinity"]
 volumeMounts:
 - name: docker-config
 mountPath: /kaniko/.docker
 volumes:
 - name: docker-config
 configMap:
 name: kaniko-docker-config
'''
 }
 }

 environment {
 IMAGE_NAME = 'registry.lab.local/go-builder'
 IMAGE_TAG = '1.26.1'
 }

 stages {
 stage('Prepare') {
 steps {
 container('base') {
 script {
 env.GIT_SHA = sh(
 script: 'git rev-parse --short HEAD',
 returnStdout: true
 ).trim()

 currentBuild.displayName = "#${env.BUILD_NUMBER} go-${env.IMAGE_TAG}"
 currentBuild.description = "go-builder:${env.IMAGE_TAG}, commit ${env.GIT_SHA}"
 }

 sh '''
 echo "GO_VERSION=${IMAGE_TAG}"
 echo "IMAGE=${IMAGE_NAME}:${IMAGE_TAG}"
 ls -la
 '''
 }
 }
 }

 stage('Build and push image') {
 steps {
 container('kaniko') {
 sh '''
 /kaniko/executor \
 --context "${WORKSPACE}" \
 --dockerfile "${WORKSPACE}/go-builder/Dockerfile" \
 --destination "${IMAGE_NAME}:${IMAGE_TAG}" \
 --insecure \
 --skip-tls-verify \
 --insecure-registry registry.lab.local
 '''
 }
 }
 }
 }

 post {
 success {
 echo "Built and pushed ${IMAGE_NAME}:${IMAGE_TAG}"
 }
 }
}

Yes, you do not need to rub your eyes in disbelief.

This Jenkinsfile looks almost identical to the previous one. The agent definition is the same, the kaniko invocation is the same, and the base image usage is the same. In practice, only names, version numbers and file paths change.

Simple? Simple.

Example use case

If you have a Go application lying around, you can use a Jenkinsfile like this one.

In this example, the test application is called rme:

pipeline {
 agent {
 kubernetes {
 yaml '''
apiVersion: v1
kind: Pod
spec:
 hostAliases:
 - ip: "10.10.10.24"
 hostnames:
 - "registry.lab.local"
 containers:
 - name: rme-go-builder
 image: registry.lab.local/go-builder:1.26.1
 command: ["sleep"]
 args: ["infinity"]
 - name: rme-kaniko
 image: registry.lab.local/kaniko-builder:latest
 command: ["sleep"]
 args: ["infinity"]
 volumeMounts:
 - name: docker-config
 mountPath: /kaniko/.docker
 volumes:
 - name: docker-config
 configMap:
 name: kaniko-docker-config
'''
 }
 }

 environment {
 IMAGE_NAME = 'registry.lab.local/rme'
 }

 stages {
 stage('Prepare') {
 steps {
 container('rme-go-builder') {
 script {
 env.VERSION = env.GIT_COMMIT.take(7)

 currentBuild.displayName = "#${env.BUILD_NUMBER} ${env.VERSION}"
 currentBuild.description = "${env.IMAGE_NAME}:${env.VERSION}"
 }
 }
 }
 }

 stage('Build binary') {
 steps {
 container('rme-go-builder') {
 sh '''
 git config --global --add safe.directory "$WORKSPACE"
 CGO_ENABLED=0 GOOS=linux go build -o rme .
 '''
 }
 }
 }

 stage('Build and push image') {
 steps {
 container('rme-kaniko') {
 sh '''
 /kaniko/executor \
 --context "${WORKSPACE}" \
 --dockerfile "${WORKSPACE}/Dockerfile" \
 --destination "${IMAGE_NAME}:${VERSION}" \
 --destination "${IMAGE_NAME}:latest" \
 --insecure \
 --skip-tls-verify \
 --insecure-registry registry.lab.local
 '''
 }
 }
 }
 }
}

The application Dockerfile can be very small:

FROM scratch

COPY rme /rme

EXPOSE 9101

ENTRYPOINT ["/rme"]

This is a more realistic example.

It uses a dedicated builder image, go-builder, to compile the Go application, and kaniko only for building and pushing the final container image.

A few details are worth noticing, because the devil usually lives exactly there:

container names matter, because they are later used in container(...) blocks,
the second --destination in the kaniko invocation:

--destination "${IMAGE_NAME}:latest" \

is intentional.

The latest tag will not magically appear in our registry by itself. If we want the most recently pushed image to also be available as latest, we need to tag and push it that way.

Summary and notes

As you can see, there is less and less that we strictly must do inside the cluster, and more and more that we can do in a controlled and repeatable way.

Versioned configuration, job history, artifact history, example applications, builds running inside containers — quite a lot is happening here.

Why use a Multibranch Pipeline?

Good question, but the answers are fairly obvious:

we do not have to clone the repository manually or hard-code credentials in the Jenkinsfile,
test branches do not require separate Jenkins jobs,
Jenkins detects new branches automatically,
deleted branches can disappear from Jenkins automatically as well,
each branch can have its own version of the Jenkinsfile,
pull requests are handled in a much cleaner way.

And now a suspicious thought appears.

What if we put all those YAML files under version control and let some clever mechanism take care of them automatically, instead of calling kubectl by hand every few minutes?

Could such a thing exist?

Who knows.

Jenkins in Kubernetes: Bring a Bucket

Sat, 11 Jul 2026 11:10:00 +0200

Warning: working with Jenkins requires a lot of determination. It is also wise to prepare a bucket in advance — for blood, sweat, tears, and all the failed pipelines.

There. I warned you.

Why Jenkins?

Jenkins has accumulated enough myths and urban legends to deserve several dedicated episodes of a good television show about mysterious phenomena and conspiracy theories.

For now, let us focus on a few practical facts:

Jenkins is a true Swiss Army knife in the CI/CD world.
Jenkins is worth knowing, because it may be lurking just around the corner in the organization you are about to join.
Jenkins is easy to run both locally and centrally.
Thanks to its many plugins, Jenkins can probably be used for almost anything.
You do not have to spend your life clicking around the UI. Jenkins Pipelines do their job.
It is worth getting familiar with Jenkins if only to form your own opinion about what you actually need from a CI/CD ecosystem.

A pinch of history

Jenkins originally started as a tool for building Java code, wrapped in a convenient web service available to everyone.

At first it was called Hudson, and perhaps it would still be called that today, but Sun Microsystems — where Hudson was created — was acquired by the large and not particularly cuddly company known for large and not particularly agile databases.

Then came a dispute over the name and project ownership. A fork appeared, someone proposed a new name, and off it went.

If this reminds you of MariaDB, congratulations: your pattern recognition module is working correctly.

Jenkins in a Kubernetes cluster

We will use Jenkins not only to build containers, but also to build regular applications and run ordinary tasks using purpose-built containers.

Requirements

Jenkins stores data on disk, so we will need a PersistentVolumeClaim.

From the cluster’s point of view, the main Jenkins server will run as a StatefulSet. An Ingress controller will provide HTTP(S) access through the address jenkins.lab.local.

As usual in this lab, add the following line to /etc/hosts on every machine that needs to access Jenkins, including your workstation:

10.10.10.24 jenkins.lab.local

The image

You can use an existing Jenkins image, for example the latest LTS image.

I do not recommend doing that here.

The bucket for blood, sweat and tears would need to be emptied far too often, with very little benefit. It is better to commit a custom image yourself — or in pairs, because at some point the basement nerds need someone to hold the light bulb.

Dockerfile

The Dockerfile looks like this:

FROM jenkins/jenkins:lts-jdk21 AS jenkins-tools

FROM eclipse-temurin:21-jre-jammy

ARG JENKINS_VERSION=2.555.3

USER root

RUN apt-get update && apt-get install -y --no-install-recommends \
 curl \
 git \
 openssh-client \
 ca-certificates \
 tini \
 fontconfig \
 jq \
 unzip \
 zip \
 && rm -rf /var/lib/apt/lists/*

RUN useradd -m -d /var/jenkins_home -u 1000 jenkins

RUN mkdir -p /usr/share/jenkins /var/jenkins_home /usr/share/jenkins/ref/plugins

RUN curl -fsSL \
 -o /usr/share/jenkins/jenkins.war \
 "https://get.jenkins.io/war-stable/${JENKINS_VERSION}/jenkins.war"

COPY --from=jenkins-tools /usr/bin/jenkins-plugin-cli /usr/bin/jenkins-plugin-cli
COPY --from=jenkins-tools /opt/jenkins-plugin-manager.jar /opt/jenkins-plugin-manager.jar

COPY plugins.txt /tmp/plugins.txt

RUN JENKINS_WAR=/usr/share/jenkins/jenkins.war \
 JENKINS_HOME=/usr/share/jenkins/ref \
 jenkins-plugin-cli \
 --war /usr/share/jenkins/jenkins.war \
 --plugin-file /tmp/plugins.txt

RUN chown -R jenkins:jenkins /usr/share/jenkins /var/jenkins_home

USER jenkins

ENV JENKINS_HOME=/var/jenkins_home

VOLUME /var/jenkins_home

EXPOSE 8080 50000

ENTRYPOINT ["/usr/bin/tini", "--"]
CMD ["java", "-Djenkins.install.runSetupWizard=false", "-jar", "/usr/share/jenkins/jenkins.war", "--httpPort=8080"]

You can put plugins in plugins.txt and install them directly into the image.

You can also install them later, because Jenkins will have persistent storage. Whether this is a convenience or the beginning of a future archaeology project depends on your level of optimism.

Building the image

The image is built for the arm64 architecture:

docker buildx build \
 --platform linux/arm64 \
 -t registry.lab.local/jenkins-lab:0.0.1 \
 --push .

The most likely result at this point is something like this:

> [stage-1 2/11] RUN apt-get update && apt-get install -y --no-install-recommends curl git openssh-client ca-certificates tini fontconfig jq unzip zip && rm -rf /var/lib/apt/lists/*:
0.126 exec /bin/sh: exec format error

Which means we need to help Docker understand how to run arm64 binaries:

docker run --privileged --rm tonistiigi/binfmt --install arm64

A successful installation should produce something like this:

Installing: arm64 OK
{
 "supported": [
 "linux/amd64",
 "linux/amd64/v2",
 "linux/amd64/v3",
 "linux/arm64",
 "linux/386"
 ],
 "emulators": [
 "python3.14",
 "qemu-aarch64"
 ]
}

Now we can build the image again:

docker buildx build \
 --platform linux/arm64 \
 -t registry.lab.local/jenkins-lab:0.0.1 \
 --push .

Cluster objects

For Jenkins to work properly, we need a few Kubernetes objects.

Namespace

The simplest way to create the namespace is:

kubectl create namespace jenkins

If you keep your configuration under version control — and you should, because future you has enough problems already — use a manifest instead:

---
apiVersion: v1
kind: Namespace
metadata:
 name: jenkins

PersistentVolumeClaim

The PVC definition looks like this:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: jenkins-home
 namespace: jenkins
spec:
 accessModes:
 - ReadWriteOnce

 resources:
 requests:
 storage: 20Gi

 storageClassName: local-path

ServiceAccount and Role

Jenkins needs permission to create and manage agent Pods in its namespace.

The following definitions are enough for this lab:

apiVersion: v1
kind: ServiceAccount
metadata:
 name: jenkins
 namespace: jenkins
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
 name: jenkins-agent-manager
 namespace: jenkins
rules:
 - apiGroups: [""]
 resources: ["pods", "pods/exec", "pods/log", "persistentvolumeclaims"]
 verbs: ["get", "list", "watch", "create", "delete", "patch", "update"]
 - apiGroups: [""]
 resources: ["secrets", "configmaps"]
 verbs: ["get", "list", "watch"]
 - apiGroups: [""]
 resources: ["events"]
 verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
 name: jenkins-agent-manager
 namespace: jenkins
subjects:
 - kind: ServiceAccount
 name: jenkins
 namespace: jenkins
roleRef:
 kind: Role
 name: jenkins-agent-manager
 apiGroup: rbac.authorization.k8s.io

Service and Ingress

Now we need a Service and an Ingress:

apiVersion: v1
kind: Service
metadata:
 name: jenkins
 namespace: jenkins
spec:
 selector:
 app: jenkins
 ports:
 - name: http
 port: 8080
 targetPort: http
 - name: agent
 port: 50000
 targetPort: agent
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: jenkins
 namespace: jenkins
spec:
 ingressClassName: nginx
 rules:
 - host: jenkins.lab.local
 http:
 paths:
 - path: /
 pathType: Prefix
 backend:
 service:
 name: jenkins
 port:
 name: http

StatefulSet

Finally, the StatefulSet:

apiVersion: apps/v1
kind: StatefulSet
metadata:
 name: jenkins
 namespace: jenkins
spec:
 serviceName: jenkins
 replicas: 1

 selector:
 matchLabels:
 app: jenkins

 template:
 metadata:
 labels:
 app: jenkins

 spec:
 serviceAccountName: jenkins
 nodeSelector:
 przeznaczenie: ci-cd

 volumes:
 - name: jenkins-home
 persistentVolumeClaim:
 claimName: jenkins-home

 containers:
 - name: jenkins
 image: registry.lab.local/jenkins-lab:0.0.1
 imagePullPolicy: Always

 ports:
 - name: http
 containerPort: 8080
 - name: agent
 containerPort: 50000

 env:
 - name: JENKINS_HOME
 value: /var/jenkins_home
 - name: JAVA_OPTS
 value: "-Djenkins.install.runSetupWizard=false"

 volumeMounts:
 - name: jenkins-home
 mountPath: /var/jenkins_home

 startupProbe:
 httpGet:
 path: /login
 port: http
 periodSeconds: 10
 failureThreshold: 60

 readinessProbe:
 httpGet:
 path: /login
 port: http
 periodSeconds: 10
 failureThreshold: 12

 livenessProbe:
 httpGet:
 path: /login
 port: http
 periodSeconds: 30
 failureThreshold: 10

Save all of the above definitions as YAML files and apply them with kubectl.

First start

Jenkins should start and greet us by asking for the initial token.

That token can be found in the depths of its home directory on the PVC. After that, it is the usual Jenkins ritual: administrator account, password, pending plugins, and all the other traditional rites of passage.

A freshly started Jenkins is a strange creature.

On one hand, it can be armed to the teeth with plugins. On the other hand, it is as naked as a jaybird. It does not have any build tools installed — but that is fine. We do not really need them.

The actual work will be done by purpose-built containers, created only when needed.

Configuring the Kubernetes cloud

This is where the Jenkins Cloud configuration comes in.

Configure it like this:

Manage Jenkins → Clouds → Add a new cloud → Kubernetes
Name: kubernetes, or any other name you prefer
Kubernetes URL: https://kubernetes.default.svc
Kubernetes namespace: jenkins
Enable WebSocket
Jenkins URL: http://jenkins.jenkins.svc.cluster.local:8080

Save the configuration.

Now all that remains is to create a few useful images, wire them into Jenkins pipelines, and then use them, use them, and use them some more.

Base builder

The first image will be… a base image for building other, better base images.

What does that mean?

The plan is for Jenkins to build many different applications, and also run jobs that may not build anything at all, but still need containers with specific tools inside.

There are two ways to approach this problem:

create one large image with every possible tool inside,
create many small, specialized images and use each one only when needed.

The second approach is easier to maintain.

The Dockerfile for the base builder looks roughly like this:

FROM debian:bookworm-slim

RUN apt-get update && apt-get install -y --no-install-recommends \
 ca-certificates \
 curl \
 wget \
 git \
 openssh-client \
 bash \
 make \
 jq \
 yq \
 tar \
 gzip \
 xz-utils \
 unzip \
 zip \
 rsync \
 file \
 procps \
 iputils-ping \
 dnsutils \
 && rm -rf /var/lib/apt/lists/*

RUN useradd -m -u 1000 builder

USER builder
WORKDIR /workspace

CMD ["sleep", "infinity"]

Build it like this:

docker buildx build \
 --platform linux/arm64 \
 -t registry.lab.local/base-builder:0.1 \
 --push .

Kaniko builder

The second image will contain kaniko, mainly for building container images.

Note: this is a lab setup. Kaniko works well enough for our purposes here, but before using it in production, check the current state of the project and consider alternatives such as Buildah or Podman. The CI/CD ecosystem moves quickly, usually while pretending it is doing so in a controlled manner.

Yes, kaniko is simpler to use than Docker in this setup. It does not require root privileges and it does not need a Docker daemon.

The Dockerfile can look like this:

FROM gcr.io/kaniko-project/executor:latest AS kaniko

FROM alpine:3.21

RUN apk add --no-cache \
 ca-certificates \
 bash \
 coreutils \
 curl \
 git

COPY --from=kaniko /kaniko /kaniko

ENV PATH="/kaniko:${PATH}"

WORKDIR /workspace

CMD ["sleep", "infinity"]

Build it like this:

docker buildx build \
 --platform linux/arm64 \
 -t registry.lab.local/kaniko-builder:0.1 \
 --push .

These two images need to be built manually.

All the other ones will be created later by Jenkins itself.

If you managed to get here in one piece, that is already quite good. In the next episode, we will learn how to make actual use of our newly assembled toys.

2026-06-30

Tue, 30 Jun 2026 19:10:00 +0200

Suit Up and March On!

What is Helm?

Kubernetes is popular enough that it was only a matter of time before someone came up with a way to install applications using one or two commands instead of manually assembling yet another small mountain of YAML files.

That tool is called Helm. It helps define, install, upgrade and manage applications running inside a Kubernetes cluster.

Think of it as the Kubernetes equivalent of apt, dnf or brew — except instead of installing packages on a machine, it installs applications into your cluster.

How does it work?

Helm introduces three basic concepts:

Chart — a package containing templates for all Kubernetes manifests required by an application.
Values — parameters used to customize those templates.
Release — a deployed instance of a chart inside a cluster. The first installation creates the initial revision, and every upgrade creates another one, making rollbacks straightforward.

In practice, you take a chart, adjust its values, install it into the cluster and get a named release that Helm can later upgrade, list, inspect or remove.

What do we need?

Not much:

a Kubernetes cluster,
kubectl,
helm.

Our first application will be Headlamp.

Kubernetes Dashboard still exists, but these days Headlamp is often the more pleasant choice, so that is what we will use here.

Headlamp is one of those rare applications that you install once and it simply works. Such things deserve appreciation.

Installing applications with Helm

Most applications are distributed through Helm repositories.

Adding one is simple:

helm repo add repository-name https://some.repo.url
helm repo update
helm install my-application repository-name/chart

repository-name is your local alias for the repository.

Likewise, my-application is the name of your release. It may look redundant at first, but imagine testing three different MariaDB installations from three different sources. Suddenly meaningful release names start looking less like ceremony and more like self-defense.

helm repo update works much like apt update: it refreshes the local cache with information about available chart versions.

You can also search through charts available in your configured repositories:

helm search repo headlamp
helm search repo bitnami

Where do the values come from?

The easiest way is to ask Helm for the default configuration:

helm show values repository-name/chart > values.yaml

Then edit the generated file and adjust it to your environment.

For Headlamp, the following values.yaml is enough for this lab:

config:
 inCluster: true

ingress:
 enabled: true
 ingressClassName: nginx
 hosts:
 - host: headlamp.lab.local
 paths:
 - path: /
 type: Prefix

nodeSelector:
 przeznaczenie: observability

We need to define the Ingress class, the hostname under which the application will be available, and optionally a nodeSelector if we want to control where the Pod runs.

As usual in this lab setup, we also need to add the hostname to /etc/hosts on every machine that will access the service, including the workstation:

10.10.10.24 headlamp.lab.local

Installing Headlamp

Now comes the easy part:

helm repo add headlamp https://kubernetes-sigs.github.io/headlamp/
helm repo update

helm install headlamp headlamp/headlamp \
 --namespace headlamp \
 --create-namespace \
 -f values.yaml

After opening the URL in a browser, we get a friendly login screen:

Headlamp asks for a Kubernetes authentication token.

Generating one is straightforward:

kubectl -n headlamp create token headlamp

The application itself is clean, tasteful and not overloaded with options. Most things are exactly where you expect them to be.

You can browse resources, inspect logs and click through various settings without leaving the browser.

Another excellent Kubernetes client is k9s. It runs entirely in the terminal, so you do not get fancy graphical topology views, but everything else is there — and it is fast.

As you can see, basic Helm usage is pleasantly simple.

Installing databases

There is not much point in overexplaining databases here. We are going to install a few of them from a popular public repository and see how little work is actually required.

We will use Bitnami’s repository:

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

kubectl create namespace databases

The separate namespace is not strictly magical, but it keeps things tidy.

PostgreSQL

Example values.yaml:

global:
 storageClass: local-path

architecture: standalone

auth:
 postgresPassword: "some-password"
 username: "marcin"
 password: "some-other-password"
 database: "utensils"

primary:
 nodeSelector:
 przeznaczenie: heavy-worker

 persistence:
 enabled: true
 size: 20Gi

 service:
 type: NodePort
 ports:
 postgresql: 5432
 nodePorts:
 postgresql: 30432

The database will be exposed through NodePort 30432.

Since this is not a web application, we need to remember which node actually hosts the Pod. Thanks to the nodeSelector, that should be 10.10.10.25.

Installation:

helm install postgresql bitnami/postgresql \
 --namespace databases \
 -f values.yaml

Afterwards Helm prints a few useful notes, including commands for retrieving generated credentials:

To get the password for "postgres" run:

export POSTGRES_ADMIN_PASSWORD=$(kubectl get secret --namespace databases postgresql -o jsonpath="{.data.postgres-password}" | base64 -d)

To get the password for "marcin" run:

export POSTGRES_PASSWORD=$(kubectl get secret --namespace databases postgresql -o jsonpath="{.data.password}" | base64 -d)

MariaDB

Example configuration:

global:
 storageClass: local-path

architecture: standalone

auth:
 rootPassword: "some-password"
 database: "utensils"
 username: "marcin"
 password: "some-other-password"

primary:
 nodeSelector:
 przeznaczenie: heavy-worker

 persistence:
 enabled: true
 size: 20Gi

 service:
 type: NodePort
 ports:
 mysql: 3306
 nodePorts:
 mysql: 30306

This database will listen on NodePort 30306, on the same node as PostgreSQL.

Installation:

helm install mariadb bitnami/mariadb \
 --namespace databases \
 -f values.yaml

Administrator credentials can be retrieved from the generated Secret:

Username: root
Password: $(kubectl get secret --namespace databases mariadb -o jsonpath="{.data.mariadb-root-password}" | base64 -d)

Redis

Example configuration:

architecture: standalone

auth:
 enabled: false

master:
 nodeSelector:
 przeznaczenie: heavy-worker

 persistence:
 enabled: true
 storageClass: local-path
 size: 5Gi

 resources:
 requests:
 cpu: 50m
 memory: 128Mi
 limits:
 memory: 512Mi

metrics:
 enabled: true
 serviceMonitor:
 enabled: true
 namespace: databases

Installation is exactly what you would expect:

helm install redis bitnami/redis \
 --namespace databases \
 -f values.yaml

At this point the cluster is starting to look like an actual environment instead of an empty playground.

As an exercise, I recommend installing a few well-known applications and checking how they are packaged, configured and exposed. There is no need to rediscover America when so many useful things are already available in public Helm repositories.

Updating an application

Sooner or later, you will change something in values.yaml.

Instead of uninstalling and installing the application again, upgrade the existing release:

helm upgrade headlamp headlamp/headlamp \
 --namespace headlamp \
 -f values.yaml

Helm applies the new configuration while preserving release history. If something goes sideways, that history becomes useful very quickly.

Removing applications

When an application outlives its usefulness — and why is it always Headlamp? — removing it is just as easy:

helm uninstall my-application

If it was installed in a specific namespace, add it explicitly:

helm uninstall my-application \
 --namespace namespace-name

Listing installed releases

This command shows releases from the current namespace:

helm list

Which is technically correct and practically disappointing most of the time.

Usually, this is what you want:

helm list -A

It lists releases across all namespaces.

And that is the nice thing about Helm: the basic workflow stays small.

Add a repository, inspect the values, install a release, upgrade it when needed, list what is running, remove what is no longer useful. Underneath, Kubernetes still does Kubernetes things, but at least you do not have to hand-write every single manifest like it is some YAML-based monastic ritual.

2026-06-29

Mon, 29 Jun 2026 19:15:00 +0200

Buffer Overflow

Today we begin in a slightly unusual place.

Interrupting the Current Operation

If there is one key binding worth remembering before you even open your first file in Emacs, it is this one:

C-g

While Emacs is executing some more complicated Lisp code, it may occasionally stop responding to user commands and give the impression that it has frozen.

Nothing could be further from the truth.

Emacs is not dead. It is merely busy executing that unfortunate piece of Lisp.

There are two possible approaches:

wait patiently until the Lisp interpreter finishes its work,
or interrupt it.

The latter is usually more practical.

C-g interrupts the current operation. It works when Emacs is running a long command, waiting for minibuffer input, or otherwise pretending not to hear you.
M-x keyboard-quit is the function bound to C-g by default. Calling it manually is usually pointless: when Emacs is busy, you cannot invoke it, and when Emacs is not busy, there is nothing to interrupt. Still, the name is worth knowing if you ever decide to remap keys.

If you forget everything else from this section, remember C-g.

When something goes wrong, Emacs will usually listen.

Lisp programmers are less predictable.

What Does This Key Do?

Let us continue.

Emacs contains an excellent built-in help system. One of its most useful features is the ability to ask:

What command is this key binding actually running?

To find out, use:

M-x describe-key
or, more conveniently, C-h k

Emacs will then ask you to press a key sequence, mouse button, or menu item.

For example:

C-h k C-p

opens a help buffer describing the command bound to C-p.

A shortened version looks like this:

C-p runs the command previous-line.

It is bound to C-p and <up>.

Move cursor vertically up ARG lines.

This function is for interactive use only;
in Lisp code use `forward-line' with negative argument instead.

Even this small fragment tells us quite a lot:

which function is bound to the key,
where the function comes from,
which other keys invoke the same command,
what the command does,
whether it is meant for interactive use,
and sometimes which related commands or variables are worth knowing about.

This is one of Emacs’ great strengths.

The program is not merely configurable. It is also unusually good at explaining itself.

Bookmark: if you have reached this point and started yawning, leave this article open. Tomorrow you will know exactly where to resume reading.

You do not have to thank me.

What Does This Function Do?

The same idea works in the other direction.

If you know the name of a function and want to inspect it, use:

M-x describe-function
or simply C-h f

For example:

C-h f find-file

opens a help buffer for the function used to visit files.

A shortened fragment looks like this:

find-file is an interactive function in `files.el`.

It is bound to <open> and C-x C-f.

Edit file FILENAME.
Switch to a buffer visiting file FILENAME, creating one if none already exists.

You can visit files on remote machines by specifying something like:

/ssh:SOME_REMOTE_MACHINE:FILE

You can also visit local files as a different user by specifying:

/sudo::FILE

To visit a file without conversion and without automatically choosing
a major mode, use M-x find-file-literally.

This is why reading Emacs help buffers is often surprisingly useful.

Even a command as ordinary as find-file turns out to do more than merely open files.

Several useful details appear immediately:

Wildcards — file name patterns can be expanded, allowing multiple files to be opened at once.
Remote files — paths such as /ssh:some-host:some-file open files over SSH.
Files as another user — paths such as /sudo::some-file allow editing files with elevated privileges.

The last option is useful for editing configuration files that require administrative access.

Other possible uses are left to the reader’s imagination and the local security department.

At this point, Dear Reader, I assume you have already typed a single * in some directory full of random files and discovered that Emacs can open rather more things than expected:

images,
PDFs,
OpenOffice and LibreOffice documents,
documents produced by that office suite which now apparently wishes to be known as a co-pilot,
EPUB and MOBI files,
archives,
and many other formats.

It probably will not play your movies, but it can certainly inspect archives.

What to do with all those joyfully opened files will be discussed a little later.

Buffers and Frames

Dividing the working area of a frame into two or more windows was invented mainly so that several buffers could be displayed side by side.

Anyone who writes code probably understands the value of that immediately.

The King of Editors can split a frame both horizontally and vertically. The resulting windows can be split again, although not forever. Once a window becomes too small, Emacs will politely refuse and display an appropriate message.

Useful key bindings:

C-x 2 — split the current window horizontally
C-x 3 — split the current window vertically
C-x 1 — delete all other windows and return to a single-window layout
C-x 0 — delete the current window
C-x 5 2 — create a new frame
C-x 5 1 — delete other frames
C-x 5 0 — delete the current frame
C-x o — move focus to the next window
C-x S-o — move focus to the previous window

A very important detail:

C-x 1 removes window splits, but it does not kill any buffers. The buffers remain open; only one of them is currently visible.

Working with Multiple Buffers

Emacs can open as many buffers as available memory allows.

Because of that, there is usually no point in starting another Emacs instance every time you want to open another file. When you need another file, open it in the same Emacs session.

Emacs was designed for working with many buffers at once. Running several separate instances is possible, but in everyday use it is rarely necessary.

Yes, this is the “a little later” mentioned above.

If a file is no longer needed, kill its buffer with:

C-x k

By default, Emacs asks what to do with buffers that contain unsaved changes.

You can move to the previous or next buffer with:

C-x Left
C-x Right

You can also switch directly to a named buffer using:

C-x b

If the buffer visits a file, its name is usually the same as the file name.

If you do not remember the exact name, press TAB. Emacs will display possible completions in a temporary window. You can also start typing and let completion narrow the list.

Completion, selection, and minibuffer behavior are, of course, topics for another volume of the Emacs saga.

To list all buffers, use:

C-x C-b

This opens a buffer containing the buffer list. You can move into that buffer and choose one of the listed entries.

The buffer list does not automatically refresh every time a new buffer is created. This makes sense once you realize that the buffer list is itself just another buffer.

Press:

to refresh it.

What else can be done inside the buffer list?

As homework, press:

and read the help page.

Scrolling Another Window

One of the more useful Emacs features is the ability to scroll the contents of another window while continuing to work in the current one.

No switching back and forth.

No mouse.

No unnecessary ceremony.

If you are writing in one window and need to inspect something above or below in another window, Emacs has you covered.

This is especially useful when both windows display different parts of the same file and you want to check what regrettable code you wrote earlier.

Useful key bindings:

C-M-v — scroll the other window down
C-M-S-v — scroll the other window up

Alternative bindings:

M-PageDown — scroll the other window down
M-PageUp — scroll the other window up

This is one of those features that sounds minor until you start using it. After a few days, working without it feels unnecessarily clumsy.

A note that will age badly and is not really on topic: at the moment, southern Poland is experiencing temperatures that feel entirely incompatible with human life. Some people of questionable judgment still insist that climate change does not exist, and that trains in the seventeenth century were also stuffy.

Drink enough water.

This is not a joke.

Otherwise, the seventeenth-century train will arrive for you personally.

2026-06-28

Sun, 28 Jun 2026 16:08:00 +0200

Listbox, anyone?

Many popular UI toolkits have their listbox control implemented to be as simple in use as possible. The most common operations are: creating the control, adding the data rows, deleting and editing data, handling the selection. Almost all toolkits provide single functions or suitable methods to realize above operations.

Gtk+ is quite different: it requires more abstract way of thinking and additional objects to be created, but the lists and trees are more flexible and elegant.

Storing the data

Before we can display a single string, let’s first earn a PhD in data models.

Unlike the the other toolkits, the gtk+ list allows to display a few values per a row. Gtk+ list also distinguishes between the types of data, while other lists treat its row data as a single string.

In fact, the TreeView widget will be used to display elements. The model lets the display widget know about data types to be used in the control, it also determines the type of the control (if it should be a list or a tree). Besides, the model is used to store all the data (it is common to find a “store” term instead of “model” in various papers or in someone’s code)

A store/model can be created by calling a proper constructor with at least one data type (to be used in the list) as argument:

store = Gtk.ListStore(type1, ...)

Example:

store = Gtk.ListStore(int, str, str)

Created store will contain one integer value and two strings per row. Although pygtk reference recommends to use build-in GObject types (for instance, gobject.TYPE_INT and gobject.TYPE_STRING instead of int and str respectively), python built-in types are also allowed (GObject names really matter in C or C++)

Adding the data rows

The method append from Gtk.ListStore class allows to append one row at the end of the store. Sequence with all values should be passed as a parameter:

store.append([val1, ...])

Example:

store.append([7, "str1", "str2"])

Columns and renderers

Control widget should know about columns it should display, their order and how to present data from the store. Gtk+ provides the column widget (Gtk.TreeViewColumn) to manage displaying the cells of data and renderer widgets (Gtk.CellRenderer and its derivatives) to realize rendering of particular cells.

Column widget is usually created by calling a constructor of Gtk.TreeViewColumn with a header title passed as the argument:

column = Gtk.TreeViewColumn(title)

Example:

column = Gtk.TreeViewColumn("Column header")

Column header is visible by default — passing an empty string to the constructor will not get rid of it.

Cell renderer should be one of Gtk.CellRendererAccel, Gtk.CellRendererCombo, Gtk.CellRendererPixbuf, Gtk.CellRendererProgress, Gtk.CellRendererSpin, Gtk.CellRendererText, Gtk.CellRendererToggle. The renderer object is usually created by calling the constructor with no parameters

Example:

renderer = Gtk.CellRendererText()

Renderers should be added to the column widgets: pack_start and pack_end methods are used to do the packing.

column.pack_start(renderer)

column.pack_end(renderer)

Example:

column1 = Gtk.TreeViewColumn("Column1")
renderer1 = Gtk.CellRendererText()
renderer2 = Gtk.CellRendererText()
renderer3 = Gtk.CellRendererText()
column1.pack_start(renderer1)
column1.pack_start(renderer2)
column1.pack_end(renderer3)

The column widget must know which data column from the model should be connected to any of these renderers. This could be done by calling set_attributes method:

column.set_attributes(renderer, ...)

All optional parameters are “key = value” pairs, where key is the data type and value is number of column in the store

Example:

column1.set_attributes(renderer1, text = 2)
column1.set_attributes(renderer2, text = 0)
column1.set_attributes(renderer3, text = 1)

TreeView control

The last step is to create a control and add all columns. Constructor of the control takes the store as first parameter:

listControl = Gtk.TreeView(model=store)

The method append_column adds given column to the tree/list control:

listControl.append_column(column)

Summary: at least, four objects should be created to have the tree/list control working: a model which determines types of data and stores all the rows, a renderer, which takes care of displaying the cells, a column, which glues together model columns and suitable renderers and a treeview control itself.

Working examples

Following examples illustrate the creation and displaying of the lists.

Very simple list control

The simplest list control contains only one column and displays only one value per row

#!/usr/bin/env python3
 
import gi

gi.require_version("Gtk", "3.0")
from gi.repository import Gtk
 
class ListBoxViewer1:
 def destroyCallback(self, widget, data=None):
 Gtk.main_quit()
 
 def __init__(self):
 self.listStore = Gtk.ListStore(str)
 self.listStore.append(["String 1"])
 self.listStore.append(["String 2"])
 self.listStore.append(["String 3"])
 self.listStore.append(["String 4"])
 self.listStore.append(["String 5"])
 self.listColumn = Gtk.TreeViewColumn("Sample column")
 self.textRenderer = Gtk.CellRendererText()
 self.listColumn.pack_start(self.textRenderer, True)
 self.listColumn.set_attributes(self.textRenderer, text = 0)
 self.mainWindow = Gtk.Window(type=Gtk.WindowType.TOPLEVEL)
 self.mainWindow.set_title('ListBoxViewer1');
 self.listBox = Gtk.TreeView(model=self.listStore)
 self.listBox.append_column(self.listColumn)
 self.mainWindow.add(self.listBox)
 self.mainWindow.connect('delete_event', self.destroyCallback)
 self.mainWindow.show_all()

if __name__ == "__main__":
 lbv1 = ListBoxViewer1()
 Gtk.main()

This example covers the theory of creating listboxes with additional routines necessary to run minimal gtk+ program. Additional method is added to provide termination of this example when its window has been closed.

All list-related routines are explained below:

self.listStore = Gtk.ListStore(str)
self.listStore.append(["String 1"])
self.listStore.append(["String 2"])
self.listStore.append(["String 3"])
self.listStore.append(["String 4"])
self.listStore.append(["String 5"])

The model is created: it can hold one string value per a row. Then it is populated by 5 rows.

self.textRenderer = Gtk.CellRendererText()

Text renderer is created.

self.listColumn = Gtk.TreeViewColumn("Sample column")
self.listColumn.pack_start(self.textRenderer, True)
self.listColumn.set_attributes(self.textRenderer, text = 0)

A column is created. Then the renderer is packed into the column, and the column is informed which column and what type of data from the store will be used.

self.listBox = Gtk.TreeView(self.listStore)
self.listBox.append_column(self.listColumn)

Main widget is created. The column is appended to the list.

It looks like the following:

Explanation of the next examples contains only the routines related to list control; other routines did not change if not mentioned.

Two values per row

 self.listStore = Gtk.ListStore(str, int)
 self.listStore.append(["String 1", 18000])
 self.listStore.append(["String 2", 1500])
 self.listStore.append(["String 3", 900])
 self.listStore.append(["String 4", 60])
 self.listStore.append(["String 5", 3])

Now the store holds a string an integer pair per a row.

self.listColumn = Gtk.TreeViewColumn("Sample column")
self.textRenderer = Gtk.CellRendererText()
self.numRenderer = Gtk.CellRendererText()
self.numRenderer.set_property('xalign', 1.0)

A column and two cell renderers are created. The set_property routine with xalign property to be set tells the renderer to align right the values in the row. Value of 0.0 means left alignment, 0.5 centers the text and 1.0 means right alignment.

self.listColumn.pack_start(self.textRenderer, True)
self.listColumn.pack_start(self.numRenderer, False)
self.listColumn.set_attributes(self.textRenderer, text = 0)
self.listColumn.set_attributes(self.numRenderer, text = 1)

The two renderers are packed into the column. The string value renderer will expand the cell if possible. Proper renderers are assigned to proper data columns from the store.

self.listBox = Gtk.TreeView(store=self.listStore)
self.listBox.append_column(self.listColumn)

The control is created and the column is appended to the control.

The following picture shows the result of this example:

Two columns in the control

self.listColumn1 = Gtk.TreeViewColumn("Ascii text")
self.listColumn2 = Gtk.TreeViewColumn("Numeric value")
self.textRenderer = Gtk.CellRendererText()
self.numRenderer = Gtk.CellRendererText()
self.numRenderer.set_property('xalign', 1.0)
self.listColumn1.pack_start(self.textRenderer, True)
self.listColumn2.pack_start(self.numRenderer, False)
self.listColumn1.set_attributes(self.textRenderer, text = 0)
self.listColumn2.set_attributes(self.numRenderer, text = 1)

Every column packs one of the renderes. It looks like the following:

Adding pixmaps to the list

Now, creating the store is like below:

self.sheetIcon = Gtk.gdk.pixbuf_new_from_file("sheet.xpm");
self.listStore = Gtk.ListStore(str, int, Gtk.gdk.Pixbuf)
self.listStore.append(["String 1", 18000, self.sheetIcon])
self.listStore.append(["String 2", 1500, self.sheetIcon])
self.listStore.append(["String 3", 900, self.sheetIcon])
self.listStore.append(["String 4", 60, self.sheetIcon])
self.listStore.append(["String 5", 3, self.sheetIcon])

The pixbuf is added in every row. Of course, it may be different in every row. This is only the example.

self.iconRenderer = Gtk.CellRendererPixbuf()

The icon requires a special kind of cell renderer.

self.listColumn1.pack_start(self.iconRenderer, False)
self.listColumn1.set_attributes(self.iconRenderer, pixbuf = 2)

Pixbuf cell renderer is now packed into the first column together with the text renderer.

It looks like the following:

Display the same values twice or more times

Displaying more values per row is achieved by multiplicating the renderes:

self.listColumn1 = Gtk.TreeViewColumn("Ascii text")
self.listColumn2 = Gtk.TreeViewColumn("Numeric value")
self.textRenderer = Gtk.CellRendererText()
self.textRenderer2 = Gtk.CellRendererText()
self.numRenderer = Gtk.CellRendererText()
self.numRenderer2 = Gtk.CellRendererText()
self.numRenderer3 = Gtk.CellRendererText()
self.iconRenderer = Gtk.CellRendererPixbuf()
self.iconRenderer2 = Gtk.CellRendererPixbuf()
self.numRenderer.set_property('xalign', 1.0)
self.numRenderer2.set_property('xalign', 0.0)
self.numRenderer2.set_property('xalign', 0.5)
self.textRenderer2.set_property('xalign', 1.0)
self.listColumn1.pack_start(self.iconRenderer, False)
self.listColumn1.pack_start(self.textRenderer, True)
self.listColumn2.pack_start(self.numRenderer, False)
self.listColumn2.pack_start(self.numRenderer2, False)
self.listColumn2.pack_start(self.iconRenderer2, False)
self.listColumn2.pack_start(self.numRenderer3, False)
self.listColumn2.pack_start(self.textRenderer2, True)
self.listColumn1.set_attributes(self.iconRenderer, pixbuf = 2)
self.listColumn1.set_attributes(self.textRenderer, text = 0)
self.listColumn2.set_attributes(self.numRenderer, text = 1)
self.listColumn2.set_attributes(self.numRenderer2, text = 1)
self.listColumn2.set_attributes(self.numRenderer3, text = 1)
self.listColumn2.set_attributes(self.textRenderer2, text = 0)
self.listColumn2.set_attributes(self.iconRenderer2, pixbuf = 2)

Also, the left, right and center alignment of text is shown.

It looks like the following:

2026-06-26

Fri, 26 Jun 2026 11:15:00 +0200

Why Do We Need a Registry?

Sooner or later, every Kubernetes cluster starts running applications that were built locally.

At first, using Docker Hub seems perfectly reasonable.

Then the first custom application appears.

Then another.

Eventually every deployment references images that exist only on your workstation.

Clearly, this is not a sustainable solution.

A private container registry solves this problem by providing a permanent home for your own images. Since the home lab already has plenty of storage available, hosting the registry locally is both the simplest and the fastest option.

PersistentVolume and PersistentVolumeClaim

One of the original design goals of Kubernetes was that Pods should be ephemeral.

Applications come and go.

Containers are recreated.

Nodes may disappear.

Unfortunately, databases tend to have rather strong opinions about losing their contents.

To bridge the gap between ephemeral workloads and persistent storage, Kubernetes introduced two API objects:

PersistentVolume (PV)
PersistentVolumeClaim (PVC)

PersistentVolume

A PersistentVolume represents an actual storage resource available inside the cluster.

Unlike Pods, a PersistentVolume exists independently of any application using it. Deleting a Pod does not automatically remove the underlying storage.

Think of it as the physical disk—or, more precisely, a piece of storage that Kubernetes knows how to manage.

PersistentVolumeClaim

A PersistentVolumeClaim is exactly what its name suggests: a request for storage.

Rather than asking for a specific disk, an application simply requests:

a certain amount of space,
an access mode,
and, optionally, a storage class.

The Pod never mounts a PersistentVolume directly. Instead, it references a PVC and lets Kubernetes handle the rest.

Binding

Whenever a PersistentVolumeClaim is created, Kubernetes searches for a suitable PersistentVolume that satisfies the requested parameters.

If one is found, the claim becomes permanently bound to that volume.

From the application’s point of view, none of this complexity exists.

The Pod simply mounts the PVC as a directory inside the container.

Access Modes

Access modes describe how Kubernetes nodes are allowed to mount a volume.

Four access modes currently exist:

ReadWriteOnce (RWO) — the volume may be mounted for reading and writing by only one node at a time. Multiple Pods may still use it, provided they all run on that node.
ReadWriteMany (RWX) — the volume may be mounted simultaneously by multiple nodes.
ReadOnlyMany (ROX) — multiple nodes may mount the volume, but only for reading.
ReadWriteOncePod (RWOP) — introduced more recently, this mode guarantees that exactly one Pod in the entire cluster has read-write access to the volume.

Note: the underlying storage backend must actually support the requested access mode. Kubernetes cannot magically turn a local SSD into a distributed filesystem.

Where Should the Data Live?

By default, k3s ships with the Local Path Provisioner, which stores dynamically created PersistentVolumes under:

/var/lib/rancher/k3s/storage

Personally, I prefer keeping persistent application data somewhere more obvious, such as:

/srv/storage

To do that, create the directory on every node:

sudo mkdir -p /srv/storage
sudo chmod 777 /srv/storage

The permissions are intentionally generous. This is a home lab, not Fort Knox.

Next, edit the local-path-config ConfigMap:

kubectl -n kube-system edit configmap local-path-config

The interesting part looks like this:

apiVersion: v1
data:
 config.json: |-
 {
 "nodePathMap":[
 {
 "node":"DEFAULT_PATH_FOR_NON_LISTED_NODES",
 "paths":["/var/lib/rancher/k3s/storage"]
 }
 ]
 }

Simply replace:

"paths":["/var/lib/rancher/k3s/storage"]

with:

"paths":["/srv/storage"]

Newly created PersistentVolumes will now live there instead.

Deploying the Registry

The registry will be available as:

registry.lab.local

Since there is no local DNS server yet, every machine—including your workstation—should receive the following /etc/hosts entry:

10.10.10.24 registry.lab.local

The registry should preferably run on the most capable machine in the cluster.

In my case, that is iridium.

Assign it an appropriate label:

kubectl label node iridium registry=true

The Deployment manifest below uses that label via a nodeSelector.

At first glance, a registry seems like a simple application.

Then you remember it needs persistent storage.

And a Service.

And an Ingress.

And perhaps its own namespace.

And a ConfigMap.

So, in the end, it turns out to require exactly six Kubernetes objects:

Namespace
PersistentVolumeClaim
ConfigMap
Deployment
Service
Ingress

Their complete definitions are shown below.

(YAML manifest unchanged.)

Save everything as:

registry.yaml

and deploy it using:

kubectl apply -f registry.yaml

Interesting Bits

The PVC requests persistent storage:

accessModes:
 - ReadWriteOnce

The registry is pinned to the node labelled earlier:

nodeSelector:
 registry: "true"

The ingress disables request size limits:

nginx.ingress.kubernetes.io/proxy-body-size: "0"

Without this annotation, pushing sufficiently large images eventually results in sadness, disappointment, and extensive arm waving.

The registry configuration itself is stored in a ConfigMap rather than a long list of environment variables.

Since the registry already expects a YAML configuration file, using a ConfigMap keeps the deployment considerably cleaner.

This setup stores all registry data on the local filesystem of a single node. That is perfectly adequate for a home lab. Production environments usually rely on distributed storage instead.

Running Without TLS

If the registry temporarily runs over plain HTTP, Docker must be told to trust it.

Create:

/etc/docker/daemon.json

containing:

{
 "insecure-registries": ["registry.lab.local"]
}

Likewise, every k3s node should receive:

/etc/rancher/k3s/registries.yaml

containing:

mirrors:
 "registry.lab.local":
 endpoint:
 - "http://registry.lab.local"

Finally, restart k3s:

sudo systemctl restart k3s || sudo systemctl restart k3s-agent

Don’t forget to update the ConfigMap as well if you’re switching from HTTPS to HTTP.

Verification

The usual suspects come first:

kubectl get pods -n registry
kubectl get pvc -n registry
kubectl get ingress -n registry
kubectl get svc -n registry
kubectl describe ingress registry -n registry
kubectl get configmap -n registry

If the PVC reports:

STATUS: Bound

everything is proceeding nicely:

the PersistentVolume exists,
the claim has been bound,
the Pod is successfully using it.

Smoke Test

Let’s put the registry to work.

docker pull php:8.4.22-zts-trixie

docker tag php:8.4.22-zts-trixie \
 registry.lab.local/php:8.4.22

docker push registry.lab.local/php:8.4.22

To make sure the image really came from the registry rather than your local cache, remove it first:

docker image rm registry.lab.local/php:8.4.22

docker pull registry.lab.local/php:8.4.22

Finally, query the registry directly:

curl https://registry.lab.local/v2/php/tags/list

which should return:

{"name":"php","tags":["8.4.22"]}

Or list every repository:

curl -s https://registry.lab.local/v2/_catalog | jq

Congratulations.

Your registry is officially alive.

Registry UI

A registry works perfectly well without a graphical interface.

Humans, however, tend to appreciate one.

The excellent Docker Registry UI provides browsing, searching, and deleting images from a web browser.

As before, add:

10.10.10.24 registry-ui.lab.local

to every /etc/hosts.

Deploy the accompanying Deployment, Service, and Ingress manifests (shown below), save them as:

registry-ui.yaml

and apply them:

kubectl apply -f registry-ui.yaml

The interface is intentionally simple.

It won’t win any design awards, but it makes exploring your registry significantly more pleasant than remembering API endpoints.

Wrapping Up

At this point, the cluster has become largely self-sufficient.

Applications can now be built locally, pushed into the private registry, and deployed without relying on Docker Hub.

It may not look particularly impressive yet, but from now on every new service added to the cluster can remain entirely within the home lab.

Which, after all, was the idea from the very beginning.

2026-06-25

Thu, 25 Jun 2026 11:15:00 +0200

Installation

There isn’t much to say about installing Emacs.

Every respectable Linux distribution includes Emacs in its package repositories. Simply use your distribution’s package manager.
The same is true for the BSD family.
On macOS, you can install it using Homebrew, MacPorts, or download a native build from https://emacsformacosx.com/.
On Windows, simply download the official installer (.exe) or the ZIP archive and extract it somewhere sensible.
On Android, install the official .apk package and allow applications from unknown sources in the system settings.

A small note: if you have no interest in running the graphical version, most Unix-like systems also provide an emacs-nox package.

Of course, you can always build Emacs from source.

But why would you, when you could spend that hour starting another flame war on Twitter (formerly “X”), Reddit, or simply improving your thumb’s scrolling endurance on social media?

Personally, I’d rather spend that hour weeding the vegetable garden.

Usenet has long since passed into history, and no equally entertaining place for operating-system flame wars has ever truly replaced it.

Getting Started

Launching Emacs

Launching the Finest Editor Known to Humankind is surprisingly simple.

On graphical desktops, Emacs should appear in your applications menu like any other program.
On Windows, if you extracted the ZIP archive instead of running the installer, start bin\runemacs.exe.
If you prefer a purely terminal-based experience, simply run:

emacs -nw

This is where the Emacs journey truly begins.

The first launch of an unmodified (vanilla) Emacs under X11, Windows, or macOS opens a window featuring the GNU antelope, a welcome screen, and a few introductory notes.

Curiously, what most desktop environments call a window, Emacs calls a frame.

The reason is historical.

Long before graphical user interfaces became commonplace, Emacs already knew how to divide a terminal screen into multiple independent editing areas called windows. When graphical support arrived, the terminology remained unchanged: the top-level GUI object became a frame, while the individual editing regions inside it continued to be called windows.

Some traditions are simply too old to change.

Meet the Interface

A default Emacs frame consists of:

a menu bar,
a toolbar (whose appearance ranges from “functional” to “deeply unfortunate”, although fortunately it can be hidden),
one or more editing buffers,
and the command line, better known as the minibuffer.

Buffers

A buffer is the place where text is edited.

Unlike most editors, however, an Emacs buffer is not necessarily associated with a file.

Buffers may contain:

source code,
documentation,
shell sessions,
email,
directory listings,
Git status,
help pages,
or virtually anything else.

This abstraction is one of the core ideas behind Emacs.

Every buffer contains an editing area together with a mode line, which displays useful information such as:

the buffer name,
whether the buffer has unsaved changes,
the current cursor position,
and the active editing mode.

Major Modes

Most editing behavior in Emacs is controlled by major modes.

A major mode typically corresponds to the type of document being edited.

Whether you’re writing C code, XML, Markdown, Lisp, YAML, or something entirely your own, the selected mode determines:

syntax highlighting,
indentation rules,
available commands,
keyboard shortcuts,
and countless editor behaviors.

Creating your own modes is also entirely possible, should inspiration strike.

The Minibuffer

The minibuffer serves as the communication channel between Emacs and its user.

Emacs displays prompts and status messages there, while the user enters commands, filenames, search patterns, and countless other parameters.

The minibuffer supports:

command history,
TAB completion,
and context-sensitive suggestions.

It may look like a single line of text, but it is one of the most heavily used parts of Emacs.

Windows and Frames

A frame may be divided into multiple windows.

Each window displays a buffer.

Interestingly, multiple windows may display the very same buffer simultaneously, each with its own cursor position and viewport.

Only the minibuffer is shared across the entire frame.

Keys and Commands

Emacs documentation uses a notation that initially looks mysterious but quickly becomes second nature.

The most common forms are:

C-x — hold the Control key while pressing x.
C-x C-f — execute the first key sequence, release the regular keys (you may keep holding Control if you like), then execute the second.
M-x — hold the Meta key. On most PC keyboards this is simply the left Alt key. I strongly recommend getting used to the left Alt immediately, since the right one is often reserved for national characters or other platform-specific input methods.
C-M-x — press both Control and Meta together.
S-x — press Shift together with the specified key.

Finally, one notation deserves its own paragraph.

M-x

M-x executes an Emacs command.

Press M-x, release the keys, type the command name into the minibuffer, and press Enter.

Almost everything Emacs can do—apart from simply inserting text—is ultimately implemented as a Lisp function.

Some of those functions appear in menus.

Some are bound to keyboard shortcuts.

All of them can be executed directly via M-x.

For example:

choosing File → Open…
pressing C-x C-f
executing M-x find-file

all invoke exactly the same underlying function.

Useful Keyboard Shortcuts

The following commands quickly become second nature:

C-x C-c — exit Emacs. Generally considered a questionable life decision, although shutting down the computer is usually accepted as a valid excuse.
C-x C-f — open an existing file or create a new one.
C-x C-s — save the current buffer.
C-x C-w — save the current buffer under a different name.
C-x k — kill (close) the current buffer.
C-x Left — previous buffer.
C-x Right — next buffer.
C-x C-b — list all buffers.
C-x h — select the entire buffer.

Editing Text

Unlike some other editors, Emacs does not have separate “insert” and “command” modes.

Open a file.

Start typing.

That’s all there is to it.

Modern keyboards provide cursor keys, Home, End, Page Up, and Page Down, and Emacs fully supports them.

For historical reasons—and because terminals were not always so well equipped—traditional Emacs key bindings are also available:

C-a — beginning of line
C-e — end of line
C-f — forward one character
C-b — backward one character
C-p — previous line
C-n — next line
M-v — previous page
C-v — next page
M-w — copy selected text
C-w — cut selected text
C-y — paste
M-y — immediately after C-y, cycle through previous clipboard entries
C-k — kill text from the cursor to the end of the line. Pressing it twice at the beginning of a line removes the entire line.
C-x h — select the whole buffer.
C-_ (or C-x u) — undo, with unlimited history.

Graphical Emacs naturally supports selecting text with the mouse.

Keyboard users, however, can set the beginning of a selection using C-SPC, move the cursor to the desired position, and then perform any operation on the selected region.

It is one of those habits that soon becomes completely automatic.

One unexpected benefit of learning Emacs is that the keyboard shortcuts tend to follow you.

Bash, the Python REPL, GDB, and many other command-line programs borrow their line-editing behavior from GNU Readline, whose default key bindings are deliberately Emacs-like.

Even if you eventually decide that Emacs is not your editor of choice, the time spent learning C-a, C-e, C-k, or M-f will continue to pay dividends every time you open a terminal.

In fact, many people use Emacs key bindings every day without realizing where they originally came from.

2026-06-24

Wed, 24 Jun 2026 11:15:00 +0200

k3s: Ingress

What exactly is an Ingress?

In the Kubernetes ecosystem, an Ingress is an API object that manages external access to applications running inside a cluster. It acts as an intelligent HTTP and HTTPS router, eliminating the need to create a separate load balancer for every service.

How Does Ingress Work?

Traditional service exposure methods, such as NodePort or LoadBalancer, typically require assigning an external IP address to each service. This quickly becomes tedious and difficult to manage as the cluster grows.

Ingress centralizes external access and operates at Layer 7 (the application layer) of the OSI model:

Single entry point — only one public IP address needs to be exposed to the outside world.
Rule-based routing — traffic is forwarded to the appropriate service based on the requested URL path (for example, my.domain/something) or hostname (for example, something.my.domain).
SSL/TLS termination — HTTPS certificates can be handled centrally, removing that responsibility from individual applications.

Ingress vs. Ingress Controller

This distinction is important.

An Ingress object itself is merely a collection of routing rules.

For those rules to have any effect, the cluster must run an Ingress Controller — a reverse proxy responsible for processing incoming traffic and applying the rules defined in Ingress manifests.

Popular examples include:

NGINX Ingress Controller
Traefik
HAProxy Ingress

This guide uses the NGINX Ingress Controller.

Domain Names

Since the cluster will eventually host various web applications, it makes sense to identify services by DNS names rather than IP addresses.

The examples below use:

.lab.local

as the local domain.

This allows services to be accessed using names such as:

grafana.lab.local
argocd.lab.local
whoami.lab.local

which is considerably more pleasant than remembering port numbers.

Certificates

Sooner or later, running everything without TLS becomes annoying.

For a home lab environment, generating your own Certificate Authority and issuing certificates locally is perfectly acceptable.

Root Certificate Authority

Create a dedicated CA:

mkdir -p certs
cd certs

openssl genrsa -out lab-ca.key 4096

openssl req -x509 -new -nodes \
 -key lab-ca.key \
 -sha256 \
 -days 3650 \
 -out lab-ca.crt \
 -subj "/CN=Lab Local CA"

Wildcard Certificate

A wildcard certificate can secure every host under:

*.lab.local

Create the configuration file lab-local.cnf:

[req]
default_bits = 2048
prompt = no
default_md = sha256
distinguished_name = dn
req_extensions = req_ext

[dn]
CN = *.lab.local

[req_ext]
subjectAltName = @alt_names

[alt_names]
DNS.1 = *.lab.local
DNS.2 = lab.local

Generate the key, request, and certificate:

openssl genrsa -out lab-local.key 2048

openssl req -new \
 -key lab-local.key \
 -out lab-local.csr \
 -config lab-local.cnf

openssl x509 -req \
 -in lab-local.csr \
 -CA lab-ca.crt \
 -CAkey lab-ca.key \
 -CAcreateserial \
 -out lab-local.crt \
 -days 825 \
 -sha256 \
 -extensions req_ext \
 -extfile lab-local.cnf

Namespace for the Ingress Controller

The ingress controller will live in its own namespace.

Create ingress-namespace.yaml:

apiVersion: v1
kind: Namespace
metadata:
 name: ingress-nginx

Apply it:

kubectl apply -f ingress-namespace.yaml

TLS Secret

The certificate must be stored inside Kubernetes as a TLS secret:

kubectl -n ingress-nginx create secret tls lab-local-tls \
 --cert=lab-local.crt \
 --key=lab-local.key

The secret is named:

lab-local-tls

and can be referenced as:

ingress-nginx/lab-local-tls

throughout the cluster configuration.

Installing the CA Certificate on Your Workstation

The root CA must also be trusted by your workstation:

sudo cp lab-ca.crt /usr/local/share/ca-certificates/lab-ca.crt
sudo update-ca-certificates

Firefox users should additionally import the CA certificate manually through the browser settings.

Deploying the Ingress Controller

A complete ingress controller deployment requires several Kubernetes resources:

ServiceAccount
IngressClass
ConfigMap
ClusterRole
ClusterRoleBinding
Deployment

The container image used in this setup is:

registry.k8s.io/ingress-nginx/controller:v1.14.0

which provides the familiar NGINX reverse proxy and load balancer functionality.

The deployment manifest is shown below.

# ingress.yaml
# (manifest unchanged from the original article)

Noteworthy Configuration

The ingress controller is pinned to the control-plane node:

nodeSelector:
 kubernetes.io/hostname: iridium

This is perfectly acceptable for a small home lab.

The controller also uses the wildcard certificate by default:

--default-ssl-certificate=ingress-nginx/lab-local-tls

which means every ingress can immediately benefit from TLS.

Verifying the Installation

Start with the usual checks:

kubectl get pods -n ingress-nginx -o wide
kubectl get rs -n ingress-nginx -o wide

Next, add a test host entry:

10.10.10.24 test.lab.local

to your workstation’s /etc/hosts.

Then run:

curl http://test.lab.local

Expected result:

<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx</center>
</body>
</html>

Surprisingly, this is good news.

The DNS lookup works.

The ingress controller works.

NGINX works.

There simply isn’t any application behind the hostname yet.

The infrastructure is doing exactly what it should.

TLS Verification

Next, test HTTPS:

curl -v https://test.lab.local

The interesting part is not the final HTTP response, but the TLS negotiation itself.

Look for output similar to:

SSL connection using TLSv1.3
...
subject: CN=*.lab.local
...
issuer: CN=Lab Local CA
...
subjectAltName: "test.lab.local" matches cert's "*.lab.local"
...
SSL certificate verified via OpenSSL

If these messages appear, the certificate chain is functioning correctly and the wildcard certificate is being served as expected.

Finally, open the URL in Firefox and confirm that the browser displays the expected lock icon and certificate information.

Conclusion

At this point:

DNS works,
the ingress controller is running,
TLS works,
wildcard certificates work,
external traffic reaches the cluster.

No actual applications are exposed yet, but the foundation is now in place.

The cluster is finally ready to host something more interesting than infrastructure components.

Which, as every Kubernetes administrator eventually discovers, is usually the easy part.

2026-06-23

Tue, 23 Jun 2026 11:15:00 +0200

Installing k3s

Warning:

This article describes the preparation, installation, and initial configuration of a Kubernetes cluster.

You are reading at your own risk. There is a non-zero chance that your life will never be quite the same afterward.

All procedures described here have been tested.

Also, no animals were harmed during the writing of this article. Unless we count two flies, six mosquitoes, and one unfortunate snail removed from a home cucumber plantation.

Hardware

The cluster consists of the following machines:

Hostname	IP Address	SBC	Architecture	RAM	Storage	Operating System	Intended Role
palladium	10.10.10.20	Odroid N2	arm64	4 GB	128 GB	Armbian	tiny-int
vanadium	10.10.10.21	Raspberry Pi 5	arm64	8 GB	512 GB	Ubuntu Server	ci-cd
iridium	10.10.10.24	Odroid M2	arm64	16 GB	512 GB	Armbian	control-plane
ruthenium	10.10.10.25	Orange Pi 5 Plus	arm64	16 GB	512 GB	Armbian	heavy-worker
tantalum	10.10.10.26	Raspberry Pi 500	arm64	16 GB	256 GB	Ubuntu Server	observability

All IP addresses are assigned by the home router using static DHCP reservations based on MAC addresses.

Operating System and Required Software

All nodes run either Ubuntu Server or Armbian based on Ubuntu Noble.

Versions may differ slightly, but package management remains identical across the cluster.

The first step is ensuring that every machine can resolve the names of every other machine.

At the moment there is no local DNS server, so each host requires an /etc/hosts entry similar to the following:

10.10.10.20 palladium
10.10.10.21 vanadium
10.10.10.24 iridium
10.10.10.25 ruthenium
10.10.10.26 tantalum

It is also worth adding the same entries to the workstation or laptop used to manage the cluster.

Windows users may perform the traditional rite of passage and figure out where Microsoft decided to hide the hosts file this decade.

Useful Tools

It is highly recommended to install kubectl on your workstation.

The official installation instructions can be found here:

https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/

On every cluster node, install a basic set of utilities:

sudo apt update && sudo apt install -y \
 curl \
 wget \
 vim \
 git \
 htop \
 net-tools \
 iproute2 \
 iptables \
 ca-certificates \
 gnupg \
 lsb-release \
 jq \
 socat \
 conntrack \
 open-iscsi \
 nfs-common \
 tmux \
 dnsutils \
 tcpdump \
 lsof \
 nc

If you prefer the Emacs lifestyle but do not enjoy “the Sixth Editor”, replace vim with mg.

You may also want:

sudo apt install mc

if navigating directories through a dual-panel interface reminds you of happier times.

On iridium, I additionally install:

sudo apt install -y sqlite3

Swap was already disabled during the preparation of the machines, but it is worth double-checking before proceeding.

Kernel Modules

Enable the required kernel modules:

cat <<EOF | sudo tee /etc/modules-load.d/k3s.conf
overlay
br_netfilter
EOF

sudo modprobe overlay
sudo modprobe br_netfilter

Then configure the required kernel parameters:

cat <<EOF | sudo tee /etc/sysctl.d/k3s.conf
net.bridge.bridge-nf-call-iptables=1
net.bridge.bridge-nf-call-ip6tables=1
net.ipv4.ip_forward=1
EOF

sudo sysctl --system

cgroups

It is also worth checking whether cgroups are properly enabled:

cat /proc/cgroups

Some systems may require additional kernel parameters in /boot/cmdline.txt:

cgroup_enable=cpuset cgroup_enable=memory cgroup_memory=1

Kubernetes

The chosen distribution is k3s.

It is fully compatible with “serious” Kubernetes while requiring significantly fewer resources, making it an excellent choice for home labs, edge computing, and IoT deployments.

Small, lightweight, easy to install, and surprisingly capable. What more could one ask for?

Control Plane

iridium has been selected as the control-plane node because it is the most powerful machine in the cluster.

The remaining nodes will join as workers with specific responsibilities.

Install k3s on iridium:

curl -sfL https://get.k3s.io | sh -s - server \
 --node-name iridium \
 --node-ip 10.10.10.24 \
 --advertise-address 10.10.10.24 \
 --write-kubeconfig-mode 644 \
 --disable traefik

Run this command directly on the machine, either through SSH or a local terminal session.

What Do These Flags Do?

--node-ip — forces a specific IP address and therefore a specific network interface.
--advertise-address — makes the API server reachable from the LAN.
--disable traefik — k3s ships with Traefik as its default ingress controller, but this cluster will use NGINX later.
--write-kubeconfig-mode 644 — creates the kubeconfig file with world-readable permissions.

That’s it.

Really.

After installation, verify that everything is running correctly:

sudo systemctl status k3s

More importantly:

kubectl get nodes

should produce something similar to:

iridium Ready control-plane

An even better command is:

kubectl get nodes -w

The -w option continuously watches for changes.

This is useful because a node that repeatedly transitions between Ready and some other state usually indicates an incomplete kernel configuration.

The most common culprits are missing overlay or br_netfilter modules.

If everything looks healthy, retrieve the cluster configuration:

cat /etc/rancher/k3s/k3s.yaml

Copy it to your workstation.

You may store it as:

~/.kube/config

or keep multiple cluster configurations separately.

For Bash:

export KUBECONFIG=~/.kube/my-cluster-config

For Fish:

set -x KUBECONFIG ~/.kube/my-cluster-config

Before using the file, edit the server address:

apiVersion: v1
clusters:
- cluster:
 certificate-authority-data: ...
 server: https://127.0.0.1:6443

Replace:

127.0.0.1

with:

10.10.10.24

You should now be able to run:

kubectl get nodes

directly from your workstation and obtain the same results.

Joining Worker Nodes

The node registration token can be found on the control-plane node:

sudo cat /var/lib/rancher/k3s/server/node-token

Use it on each worker node:

curl -sfL https://get.k3s.io | \
K3S_URL=https://10.10.10.24:6443 \
K3S_TOKEN='YOUR_TOKEN_HERE' \
sh -s - agent \
 --node-name vanadium \
 --node-ip 10.10.10.21

This example joins vanadium.

Remember to adjust both the node name and IP address accordingly.

Run the command directly on the target machine.

Once all nodes have joined, verify the cluster:

kubectl get nodes -o wide

Every node should eventually report:

Ready

Simple?

Simple.

A little time-consuming, perhaps, but there are no lengthy computations involved.

Only now is it safe to reach for your favorite book.

2026-06-20

Sat, 20 Jun 2026 08:15:00 +0200

What Is Emacs, and Do I Need It?

GNU Emacs is a text editor originally created by Richard Stallman for the PDP-10 platform.
GNU Emacs is a universal development environment available on Unix and Unix-like systems, Microsoft Windows, macOS, and many others.
GNU Emacs is an operating system disguised as a text editor.
GNU Emacs is a philosophy and a way of life.
GNU Emacs is a religion.

All right, let’s start over.

A Brief History

Richard Stallman, while working at MIT, became increasingly frustrated with proprietary software. Not only was it often full of bugs, but there was usually little anyone outside the vendor could do to fix them. Bug reports rarely led to meaningful improvements, and users were expected to simply accept whatever they were given.

Eventually, Stallman left MIT and launched the GNU Project, whose goal was to create a completely free Unix-like operating system.

Emacs itself began as a collection of macros for the TECO editor. After a rapid evolution, it became a standalone application and eventually one of the most influential pieces of software in the free software ecosystem. A large community of developers, thousands of articles, books, tutorials, and decades of active use suggest that Emacs still has a long future ahead of it.

Not everyone, however, was happy with the project’s leadership style. The most significant fork occurred when developers from Lucid, who wanted to use Emacs as the foundation of their development environment, split off and created Lucid Emacs. This project later evolved into XEmacs.

Incidentally, the “X” in XEmacs has nothing to do with whether the editor can run under the X Window System. Both GNU Emacs and XEmacs work perfectly well with or without X11.

Over the years, various other forks appeared, often for technical or political reasons. While some introduced interesting ideas, none managed to surpass GNU Emacs itself. XEmacs, despite its innovations, gradually lost momentum. A long period without significant releases and declining community activity eventually left the project effectively dormant. Its website still feels like a time capsule from the late 1990s, apparently untouched by mobile devices, TLS certificates, or modern web design.

What Is Emacs?

A Text Editor

At its core, Emacs is a text editor.

This remains the primary goal of the project: creating an exceptionally capable environment for editing text of all kinds. Source code, notes, books, articles, documentation, LaTeX manuscripts, configuration files—everything is ultimately text, and Emacs is designed to handle all of it.

A Lisp Interpreter and Runtime Environment

One of Emacs’ defining features is its built-in Lisp interpreter.

Through Emacs Lisp, users can extend the editor to perform virtually any task imaginable. Email clients, news readers, calendars, web browsers, file managers, games, and countless other tools are available either as part of the standard distribution or through third-party packages.

Need an AI assistant? Someone has almost certainly written one already.

Installing extensions is typically as simple as fetching the appropriate package from a repository and enabling it.

A Development Environment

For many users, Emacs serves primarily as an integrated development environment.

Support exists for an astonishing number of programming languages. Syntax highlighting, code navigation, language servers, debugging tools, build systems, version control integration, documentation generation, shells, terminals, and countless other development tools are readily available.

Whether you write C++, Go, Python, Rust, Lisp, or something more obscure, chances are that someone has already built excellent Emacs support for it.

An Environment for Markup Languages

Emacs is equally comfortable working with markup and document-oriented formats.

XML, HTML, YAML, Markdown, Org Mode, TeX, LaTeX, DocBook, and many others are all well supported. Validation, transformation, navigation, and editing tools are often available out of the box.

The live preview capabilities available for TeX and LaTeX workflows remain particularly impressive even today.

Anything You Can Convince Lisp to Do

Ultimately, Emacs is whatever you can persuade Emacs Lisp to become.

This flexibility is both its greatest strength and one of the reasons why Emacs users occasionally develop a reputation for eccentricity.

What Emacs Is Not

A Universal Solution

Emacs is an incredibly powerful tool, but it is not magic.

Installing Emacs will not automatically teach you a programming language, system administration, networking, or software architecture. It can help you work more effectively, but it cannot replace knowledge or experience.

Is Emacs for Me?

Perhaps.

Emacs may be a good fit if:

You want a consistent environment for editing, programming, writing, note-taking, and other text-oriented tasks.
You enjoy highly configurable tools.
You appreciate software that can evolve alongside your workflow.

Emacs may not be a good fit if:

Editing configuration files makes you uncomfortable.
You expect every feature to be immediately discoverable through graphical menus.
You are unwilling to invest time learning new tools.
Your primary computing activity consists of scrolling through social media feeds on a phone.

Emacs has a steep learning curve, but it rewards patience. For many users it eventually becomes much more than an editor; it becomes the environment in which a significant portion of their computing life takes place.

Whether that sounds exciting or alarming is entirely up to you.