Raymii.org

Hi there!

I'm Remy, a developer from The Netherlands with a focus on C++, C, some C#, Linux and embedded systems.

I currently work on a C++ and Qt stack running on Yocto Linux. It controls hardware, runs the UI and has a few utilities for IoT connectivity and configuration. Technologies I'm fluid in include C, C# & C++, Windows (MFC/Win32), .NET (Core, Xaml, Framework and C++/CLI), Flash, Qt, Ansible, Bash & PowerShell. I was Linux and UNIX sysadmin for over 10 years before I got into development.

To read more or get in touch, click here. This is my personal website, these articles do not reflect or are based on work, opinions or policies of any of my (previous) employers. Any resemblance to reality is pure coincidence.

Latest Items

nameConstraints on your Self Signed Root CA in Kubernetes with cert-manager

If you have set up a Self Signed Root CA for your local Kubernetes Cluster and have trusted the Root Certificate, you are at risk if the key is compromised. If the key is stolen, it can be used to create trusted certificates for everything. Luckally there is something we can do, using nameConstraints to limit the scope of the Root Certificate to, in our case, a single domain (k3s.homelab.mydomain.org). This means that if your key would be compromised, it would only be able to issue certificates for anything under that domain, not your bank for example.

Self-signed Root CA in Kubernetes with k3s, cert-manager and traefik. Bonus howto on regular certificates

Now that I'm learning Kubernetes for a few weeks, I'm finally at the point where I was 20 years ago with regular boring old tech, being able to host multiple domains, password protection and high available clusters. It seems we have to re-invent the wheel every time but in the end, it's just resume-driven development, the underlying stack costs more, is way more complex but for the user, nothing changes, they see the same website as always. Not all change is progress. Enough of being a curmudgeon, time to continue with Kubernetes. In this episode of 'Remy discovers Kubernetes', I'm setting up cert-manager, not with Lets Encrypt, but with a self-signed certificate authority. I'll also show you how to set up a regular certificate, one you've for example bought somewhere. I'll also cover nameConstraints to make the risk of compromise of your trusted root ca lower.

OpenSSL get entire certificate chain from a domain or loop over entire chain in file

The openssl x509 command can be used to get information from a certificate. If you supply a filename, the command will only use the topmost certificate in the file, not all certificates in the file, like in the case of a certificate chain. The openssl s_client -connect command can connect to a server and show all certificates served by that server. The command I'm providing in this snippet splits up all certificates found in a file or as the result of openssl s_client and allows openssl x509 to loop over each one individually.

Password protect web services in Kubernetes (k3s/traefik) with basic auth

Now that I have a high-available local kubernetes cluster and am experimenting with deploying apps, it's also time to look into securing those apps using certificates and passwords. In this case I'm going to set up password authentication, like a .htaccess file in Apache2, to protect the Longhorn dashboad, which by default requires no authentication. This means deploying an Ingress, a Middleware and a Secret.

Leaf Node Monitoring v2024.02 released, autostart, ssl certificate expiry and minimize to tray

I'm pleased to announce the next version of Leaf Node Monitoring, the simple and easy to use open source site and server monitoring tool. Major new features include minimizing to the tray, automatic startup on Windows and Linux and a new check, SSL Certificate Expiry. This post goes over everything that is new in this release.

Using nodeSelector to deploy a Kubernetes Helm chart only on x86/amd64 nodes, not arm64

My k3s cluster runs on Orange Pi Zero 3 small board computers, with a 1.5 GHz Allwinner H618 Quad-Core Cortex-A53 ARM64 CPU. Nowadays most popular software has support for aarch64 due to the popularity of boards like the Raspberry Pi and the Apple M1 series processors, but smaller projects or niche software often can only run on x86/amd64. If you write your own yaml files for deployment you can use a nodeSelector combined with the kubernetes.io/arch=amd64, but with a Helm Chart this is not that obvious. This small snippets shows you the correct syntax to force deploy a Helm Chart to only amd64 nodes in your cluster. This assumes you have a mixed cluster, I added a small virtual machine to it for testing.

Kubernetes (k3s) Ingress for different domains (virtual hosts)

Now that I have a high-available local kubernetes cluster it's time to learn not just managing the cluster but actually deploying some services on there. Most examples online use a NodePort or a LoadBalancer to expose a service on a port, but I want to have domains, like, grafana.homelab.mydomain.org instead of 192.0.2.50:3000. Back in the old days this was called Virtual Host, using 1 IP for multiple domains. My k3s cluster uses traefik for its incoming traffic and by defining an Ingress we can route a domain to a service (like a ClusterIP). This page will show you how.

High Available k3s kubernetes cluster with keepalived, galera and longhorn

After my first adventure with Kubernetes, getting started with k3s on my small 3 node ARM cluster that boots via PXE / NFS, I noticed that there is only one k3s node that has the control-plane,master role. If that node fails you can no longer manager the cluster. Other nodes can fail and then the workloads (pods) will be restarted eventually after 5 minutes, but this node is special. Time to change that and make it a high available cluster. K3s supports high-availability with embedded etcd and with external databases like MySQL and postgres. etcd will thrash your storage (SD cards) so I decided to go with a MySQL cluster using Galera for the database and keepalived for the High Available Cluster IP. This guide will show you how to configure the HA database and HA-IP and I'll also setup longhorn for high-available block storage inside kubernetes. The end result is that I can pull the power from any two of the three nodes without the k3s cluster or workloads going down.

My First Kubernetes: k3s 'cluster' on 3 Orange Pi Zero 3's, including the dashboard, hello-node and failover

I've been working as an embedded C++ developer for over 5 years now so my sysadmin / devops skills are becoming a bit rusty. The odd bit of Ansible here and there but no new stuff. I figured it was time to expore Kubernetes, as it is what all the cool kids do these days. So I got myself 3 new SBC's, the Orange Pi Zero 3. I'll be using these to install and setup a basic Kubernetes cluster, getting the Dashboard working, installing a Hello World app and testing how the failover works.

Netboot (PXE) Armbian on an Orange Pi Zero 3 from SPI with NFS root filesystem

Because I wanted to experiment with Kubernetes I bought a few cheap SBC's and a Power over Ethernet switch to run k3s. Since Kubernetes is very resource intensive I wanted to try to boot the boards via the network without causing wear on the Micro SD card. The boards have built-in SPI flash from which it can boot u-boot and Armbian works quite well with a root filesystem over NFS. This guide will help you with netbooting an Orange Pi Zero 3 running Armbian.

Leaf Node Monitoring v2024.01 released, better notifications and history

I'm pleased to announce the next version of Leaf Node Monitoring, the simple and easy to use open source site and server monitoring tool. Major new features include better alerting and history of events. This post goes over everything that is new in this release.

View all Items