manintheit.org

NixOS

Tue, 24 Feb 2026 21:00:00 +0000

T the emergence of Docker and Kubernetes was a massive leap in how we build and deploy software. They accelerated the shift from monolithic applications to microservices architectures and fundamentally changed deployment strategies. For the first time, we could package an application together with its runtime and dependencies into a container image. When built correctly (with pinned base images and fixed versions), that image behaves deterministically.

However, our development machines remains far from this. Traditional Linux distributions such as Ubuntu or Red Hat Enterprise Linux use mutable package management systems. They install packages into a global filesystem, resolve dependencies dynamically, and depend on the current state of remote repositories. That means it does NOT guarantee you will get the same package version, when you try to install the same package after a month or a year. Reproducing the same environment is diffucult, unless you have `Satellite` or `Foreman` like system management tools.

This is where NixOS comes into play. NixOS is immutable Linux distribution which allows us to define our sytem configurations as code. When your system configuration is declared declaratively, every rebuild produces the same result — consistently, predictably, and reproducibly.

Feature	Traditional Linux (Ubuntu/RHEL)	NixOS
State Management	Imperative (Manual changes)	Declarative (Config files)
File System	Mutable (Files can be changed)	Immutable (Read-only /nix/store)
Reproducibility	Low (Depends on install timing)	High (Guaranteed by hashes)
Rollbacks	Difficult / Manual	Atomic (Instant via Boot Menu)

Under the hood, packages

stored in /nix/store
Each build is content-adddressed and hashed.
Dependencies are isolated.
System generations are atomic.

Above features provides us following advantages

Reproducibility
Rollbacks
Isolation

NixOS has its own programming language. At first glance, it may seem unusual or even intimidating. However, once you become familiar with it, you realize it is a powerful tool for defining system configuration in a precise and reproducible way.

There is definitely a learning curve when it comes to understanding the Nix language and the core NixOS concepts. However, once you become familiar with overlays, modules, and Home Manager, things start to feel much more intuitive.

I’m still learning and exploring NixOS myself. I have to admit that the configuration I’m sharing below may be far from best practices. As I continue learning, I plan to refine and improve it over time.

Mine: I am using NixOS on my local machine and I have defined my system configuration as code. I am using it to manage my development environment and to ensure that I have the same environment on all my machines.
Michellh: He is one of creator of Vagrant, Packer and Terraform.

Longhorn on Talos Linux

Sun, 23 Nov 2025 08:00:00 +0000

I am using Talos Linux as my main operating system for Kubernetes clusters. Talos is a modern, secure, and minimal operating system designed specifically for running Kubernetes. Since it does not have a package manager, adding additional packages a bit different procedure than traditional Linux distributions. In this blog post, I will walk you through how to setup Longhorn on Talos Linux so that your stateful workload can run happily.

Add Extensions to Talos Linux

Since we are deploying Longhorn, we need to add necessary packages to Talos Linux. iscsi-tools and util-linux-tools are the required packages for Longhorn to work properly on Talos Linux.

# extensions.yaml
customization:
  systemExtensions:
    officialExtensions:
      - siderolabs/iscsi-tools
      - siderolabs/util-linux-tools

$ curl -X POST --data-binary @extensions.yml https://factory.talos.dev/schematics
{"id":"613e1592b2da41ae5e265e8789429f22e121aab91cb4deb6bc3c0b6262961245"}

Add Extensions to Talos Linux

Do not forget to add --preserve flag.

talosctl upgrade --nodes 10.181.176.4 --image factory.talos.dev/metal-installer/613e1592b2da41ae5e265e8789429f22e121aab91cb4deb6bc3c0b6262961245:v1.11.1 --preserve
talosctl upgrade --nodes 10.181.176.5 --image factory.talos.dev/metal-installer/613e1592b2da41ae5e265e8789429f22e121aab91cb4deb6bc3c0b6262961245:v1.11.1 --preserve
talosctl upgrade --nodes 10.181.176.6 --image factory.talos.dev/metal-installer/613e1592b2da41ae5e265e8789429f22e121aab91cb4deb6bc3c0b6262961245:v1.11.1 --preserve
talosctl upgrade --nodes 10.181.176.7 --image factory.talos.dev/metal-installer/613e1592b2da41ae5e265e8789429f22e121aab91cb4deb6bc3c0b6262961245:v1.11.1 --preserve

Adding Block Disks to your Worker Nodes

Adding block disks to varies based on your virtualization platform or cloud provider. Since I am using incus for my lab , procedure as follows.

incus storage volume create pool-nvme-samsung-lvm lh-w0 size=200GiB  --type=block
incus storage volume create pool-nvme-samsung-lvm lh-w1 size=200GiB  --type=block
incus storage volume create pool-nvme-samsung-lvm lh-w2 size=200GiB  --type=block

incus config device add talos-w0 lh-w0 disk pool=pool-nvme-samsung-lvm source=lh-w0
incus config device add talos-w1 lh-w1 disk pool=pool-nvme-samsung-lvm source=lh-w1
incus config device add talos-w2 lh-w0 disk pool=pool-nvme-samsung-lvm source=lh-w2

Verify the Block Devices on Talos Linux

You can run the following command for each of nodes you want to add block devices for Longhorn usage.

root@debian-vm:~# talosctl get volumestatus -n 10.181.176.5
NODE           NAMESPACE   TYPE           ID                                  VERSION   TYPE        PHASE   LOCATION    SIZE
10.181.176.5   runtime     VolumeStatus   /dev/sdb-1                          2         partition   ready   /dev/sdb1   215 GB
...(omitted)

Patch the Machine Config

You need to patch the worker nodes with the following maching config in order to mount the block devices properly for Longhorn usage.

# patch.yml
machine:
  kubelet:
    extraMounts:
      - destination: /var/mnt/storage/longhorn
        type: bind
        source: /var/mnt/storage/longhorn
        options:
          - bind
          - rshared
          - rw
  disks:
      - device: /dev/sdb
        partitions:
          - mountpoint: /var/mnt/storage/longhorn

export TALOSCONFIG=~/talosconfig
talosctl patch mc --nodes 10.181.176.5  --patch @patch.yml  # do it for each worker nodes

root@debian-vm:~# talosctl get discoveredvolumes -n 10.181.176.5
NODE           NAMESPACE   TYPE               ID      VERSION   TYPE        SIZE     DISCOVERED   LABEL       PARTITIONLABEL
...(omitted)...
10.181.176.5   runtime     DiscoveredVolume   sdb     1         disk        215 GB   gpt
10.181.176.5   runtime     DiscoveredVolume   sdb1    1         partition   215 GB   xfs

root@debian-vm:~# talosctl get mountstatus -n 10.181.176.5
NODE           NAMESPACE   TYPE          ID                                  VERSION   SOURCE      TARGET                              FILESYSTEM   VOLUME
10.181.176.5   runtime     MountStatus   /dev/sdb-1                          2         /dev/sdb1   /var/mnt/storage/longhorn           xfs          /dev/sdb-1
...(omitted)...

Install Longhorn via Helm

You can install Longhorn via Helm as usual. With exception, you need to label longhorn-system namespace with privileged pod security policy.

apiVersion: v1
kind: Namespace
metadata:
  name: longhorn-system
  labels:
    pod-security.kubernetes.io/enforce: privileged
    pod-security.kubernetes.io/audit: privileged
    pod-security.kubernetes.io/warn: privileged

helm repo add longhorn https://charts.longhorn.io

helm repo update

helm install longhorn longhorn/longhorn --namespace longhorn-system --create-namespace --set defaultSettings.defaultDataPath="/var/mnt/storage/longhorn" --version 1.10.0

Git Pre-commit

Sat, 25 Oct 2025 08:00:00 +0000

W hether you are doing Software development or writing Infrastructure code in a team, it is of utmost importance to define some standards for the codebase. There are plenty of plugins for code linting, formatting and much more integrated with IDEs such as VSCode, JetBrains etc. But the problem is that everyone has their own IDE setup. For example, some developers add config to "delete trailing spaces", while others do not. Secondly, not every developer uses the same IDE. In order to eliminate such problems, Git pre-commit hooks can be useful. Even though people on the Internet have different opinions, I am going to list some benefits of it.

Allows developers to see and fix their code almost instantly.
It keeps the codebase clean and standardized independently of the IDE being used.
Besides linting, it also performs secret checks and many other things…

However, using it intensively could disrupt the developer’s workflow. It can shift their focus from bug fixing and adding new features to linting.

In this blog post, I will walk you through, how we can add pre-commit hooks to our IaC codebase.

Install pre-commit

Since pre-commit written in python you need to install the pre-commit module.

pip install pre-commit

Add a pre-commit Configuration

create .pre-commit-config.yaml file. For demonstration purposes, I will add some basic hooks such as check-yaml, end-of-file-fixer, trailing-whitespace and terraform_fmt hook to format terraform files.

repos:
- repo: https://github.com/pre-commit/pre-commit-hooks
  rev: v6.0.0
  hooks:
  -   id: check-yaml
  -   id: end-of-file-fixer
  -   id: trailing-whitespace
- repo: https://github.com/antonbabenko/pre-commit-terraform
  rev: v1.103.0
  hooks:
  - id: terraform_fmt

After add the configuration file, next step to instruct pre-commit to install the hooks.

pre-commit install
pre-commit installed at .git/hooks/pre-commit

Using pre-commit

In this example, variables.tf file generated and some variables are defined. Of course without any linting.

pre-commit run
check yaml...........................................(no files to check)Skipped
fix end of files.........................................................Passed
trim trailing whitespace.................................................Passed
Terraform fmt............................................................Failed
- hook id: terraform_fmt
- files were modified by this hook

variables.tf

As you see above, the terraform_fmt hook has failed because the file is not formatted well. At first run it failed but plugin has fixed the file.

index 6b70073..3f21cc1 100644
--- a/terraform/variables.tf
+++ b/terraform/variables.tf
@@ -1,5 +1,5 @@
 variable "environment" {
-  type          = string
+  type = string
 }

We can now add it to the staging area and run the pre-commit again.

pre-commit run
check yaml...........................................(no files to check)Skipped
fix end of files.........................................................Passed
trim trailing whitespace.................................................Passed
Terraform fmt............................................................Passed

At this time no issue detected. By the way, you can also run pre-commit for all files in the repository.

pre-commit run --all-files

Tip:

You can still bypass the hooks.

git commit -m "I will fix it next time" --no-verify

For more information you can check following urls about the pre-commit.

https://git-scm.com/book/ms/v2/Customizing-Git-Git-Hooks
https://pre-commit.com/
https://github.com/antonbabenko/pre-commit-terraform

Upgrade Openshift Cluster Logging Operator from 5 to 6

Sun, 12 Oct 2025 18:00:00 +0000

Before jumping directly into the upgrade, it’s worth highlighting a few important points. This blog post is not only about upgrading the OpenShift Logging Operator — it also covers how to continue sending logs without disrupting external systems that use Fluentd Forward.

To achieve this, we’ll introduce an additional Aggregator component (via Log Forwarding), shown in the diagram below. This component receives OpenShift/Kubernetes logs over HTTP, applies necessary transformations, and then forwards them to external logging systems — such as those using Fluentd Forward or SIEM solutions like Splunk.

In this upgrade approach, we won’t be performing a direct upgrade from version 5.x to 6.x.Instead, we’ll remove the OpenShift Logging Operator 5 and install the OpenShift Cluster Logging Operator 6 from scratch.

Also, note that we won’t deploy the full Operator stack (which includes the LokiStack for log storage). This post focuses only on the collector and forwarder components. The Loki setup will be covered in a separate blog post.

Only update to an N+2 version, where N is your current version. For example, if you are upgrading from Logging 5.8, select stable-6.0 as the update channel. Updating to a version that is more than two versions newer is not supported.

Upgrading the OpenShift Logging Operator from version 5.x to 6.x introduces several breaking changes due to significant technological and architectural updates in the operator. Some of the key changes are listed below.

Only supported collector agent now is vector. So, fluentd is not supported anymore.
Since fluentd is not a supported collector Fluentdforward is not available as output type.
Elasticsearch is replaced with Loki
Kibana is replaced with the UIplugin provided by COO.
The API for log collection is changed from logging.openshift.io to observability.openshift.io.
ClusterLogForwarder and ClusterLogging have been combined under the ClusterLogForwarder resource in the new API.

As mentioned at the beginning of this post, with the upgrade to Logging Operator 6, FluentdForward is no longer an available output type.

If you still rely on FluentdForward for external integrations, there’s a workaround using the LogForwarding component. You can think of this component as a log aggregator and routing layer — it collects logs, processes them, and forwards them to external systems while maintaining compatibility with existing Fluentd-based setups.

Uninstall Openshift Logging Operator 5

Do not to forget to make backup of resources before deleting CRDs other definitions deleted below.

oc -n openshift-logging delete subscription cluster-logging
oc -n openshift-logging delete operatorgroup openshift-logging
oc -n openshift-logging delete clusterserviceversion cluster-logging<old-version>


oc delete crd clusterlogforwarders.logging.openshift.io
oc delete crd clusterloggings.logging.openshift.io
oc delete crd logfilemetricexporters.logging.openshift.io

Install OpenShift Logging Operator 6

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: openshift-logging
  namespace: openshift-logging
spec:
  targetNamespaces:
  - openshift-logging


apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: cluster-logging
  namespace: openshift-logging
spec:
  channel: stable-6.0
  installPlanApproval: Automatic
  name: cluster-logging
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  startingCSV: cluster-logging.v6.0.7

Create necessary service account and assign necessary ClusterRoles to the Service Account.

oc create sa logging-collector -n openshift-logging

oc adm policy add-cluster-role-to-user collect-application-logs -z logging-collector -n
openshift-logging

oc adm policy add-cluster-role-to-user collect-audit-logs -z logging-collector -n
openshift-logging

 oc adm policy add-cluster-role-to-user collect-infrastructure-log -z logging-collector -n
openshift-logging

Define ClusterLogForwarder Definition

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  collector:
    tolerations: {}
  inputs:
  - application:
      includes:
      - namespace: ns1
    name: ns1
    type: application
  - application:
      includes:
      - namespace: ns2
    name: ns2
    type: application

  outputs:
  - http:
      url: http://logforwarding.openshift-logging.svc:24224/kubernetes/var/log/pods/appgrp
    name: appgrp
    type: http
  - http:
      url: http://logforwarding.openshift-logging.svc:24224/kubernetes/var/log/pods/extlogging
    name: externallogging
    type: http
  - http:
      url: http://logforwarding.openshift-logging.svc:24224/kubernetes/splunk
    name: splunk
    type: http

  pipelines:
  - inputRefs:
    - audit
    name: audit
    outputRefs:
    - splunk
  - inputRefs:
    - infrastructure
    name: infrastructure
    outputRefs:
    - splunk
    - inputRefs:
        - application
      name: application
      outputRefs:
        - splunk
  - inputRefs:
    - ns1
    name: ns1
    outputRefs:
    - appgrp
  - inputRefs:
    - ns2
    name: ns2
    outputRefs:
    - appgrp
    - externallogging
  serviceAccount:
    name: logging-collector

Deploy Logforwarding Component

The LogForwarding component is not part of the Cluster Logging Operator. Instead, it serves as a separate log aggregation and forwarding layer that can send logs over various protocols.

Since the new Logging Operator no longer supports FluentdForward, this component will receive logs over HTTP and forward them using your desired protocols.

You can easily deploy this component using a Helm chart or a simple YAML definition. In this post, I’ll share only the ConfigMap definition for the Fluentd configuration.

If your environment handles a large volume of logs or requires high throughput, consider using Fluent Bit instead of Fluentd for better performance.

  fluent.conf: |
    <system>
      log_level info
    </system>

    <source>
      @type  http
      @id    input1
      port  24224
      bind 0.0.0.0
    </source>

    <filter kubernetes.var.log.pods.appgrp>
      @type record_transformer
      enable_ruby
      <record>
        time-filename ${Time.new.strftime("%Y%m%d_%H%M")}
      </record>
    </filter>


    <filter kubernetes.var.log.pods.extlogging>
      @type record_transformer
      remove_keys $.kubernetes.annotations
    </filter>

    <match kubernetes.var.log.pods.appgrp>
      @type rewrite_tag_filter
      <rule>
        key $.kubernetes.namespace_name
        pattern ^(.+)$
        tag $1.${tag}
      </rule>
    </match>

    <match kubernetes.var.log.pods.extlogging>
      @type forward
      @id upstream
      transport tcp
      require_ack_response true
      <server>
        host extlogging.openshift-logging.svc
        port 24224
      </server>
      <buffer>
        @type file
        flush_interval 60s
        flush_mode interval
        flush_thread_count 2
        overflow_action block
        path /var/log/fluentd/extlogging-buffer
        retry_max_interval 30
        retry_max_times 3
        retry_timeout 60s
        retry_type exponential_backoff
        total_limit_size 600m
      </buffer>
    </match>

    <match *.kubernetes.var.log.pods.appgrp>
      @type file
      path /var/log/fluentd/backup/${tag[0]}/${tag[0]}.${$.time-filename}
      compress gzip
      <buffer tag,$.time-filename>
        @type file
        flush_interval 300s
        flush_mode interval
        flush_thread_count 2
        overflow_action block
        path /var/log/fluentd/backup-buffer/${tag}/${tag}
        retry_max_interval 30
        retry_max_times 3
        retry_timeout 60s
        retry_type exponential_backoff
        total_limit_size 600m
      </buffer>
    </match>

   <match ** >
      @type splunk_hec
      protocol https
      insecure_ssl false
      hec_host splunk
      sourcetype <source type>
      source <your source>
      index <index>
      hec_port 443
      hec_token <splunk token>
      host "#{ENV['NODE_NAME']}"
      <buffer>
        @type memory
        chunk_limit_records 100000
        chunk_limit_size 200m
        flush_interval 5s
        flush_thread_count 1
        overflow_action block
        retry_max_times 3
        total_limit_size 600m
      </buffer>
    </match>

References

How Fix Certificate Error on Azure Self-Hosted Agent

Sat, 13 Sep 2025 18:00:00 +0000

Working in a highly regulated corporate environment can often feel daunting, especially when it comes to connecting to the internet. Strict regulations, mandatory security inspections, proxy requirements, and self-signed certificates can all introduce unexpected challenges.

In such environment, I ran into a problem during the execution of the following pipeline on a self-hosted agent. One part of the pipeline is to fetch a secret from a specified Azure Key Vault.

Unfortunately, what should have been a straightforward task turned into a 30-minute troubleshooting session.

trigger:
- main

pool:
  name: self-managed-dev

steps:
- task: AzureKeyVault@2
  inputs:
    azureSubscription: 'svc-azpipeline-vault-reader'
    KeyVaultName: '<REDACTED>'
    SecretsFilter: 'webhooktest'
    RunAsPreJob: false
...

Azure pipeline Definition

...(omitted)
Downloading secret value for: webhooktest.
##[error]Error while trying to get OIDC token: Error: unable to get local issuer certificate
##[error]Error while trying to get OIDC token: Error: unable to get local issuer certificate
##[error]Error while trying to get OIDC token: Error: unable to get local issuer certificate
##[error]Error while trying to get OIDC token: Error: unable to get local issuer certificate

To make matters worse, the error logs were not very informative. Unless you explicitly enable diagnostic logs, the output doesn’t provide much detail about what’s really happening under the hood.

Nevertheless, there’s a high chance that issues like this are related to TLS verification.

After same search that Azure pipeline agent uses nodejs technology and it could the be the reason that nodejs does NOT use system CA certificate bundle, which is /etc/pki/tls/certs/ca-bundle.crt for RHEL based hosts.

Following snippet of code also confirmed that, nodejs is not aware of any system ca-bundle location.

<Agentfolder>./node -e 'const tls = require("tls"); console.log(tls.rootCertificates);'
undefined

According to nodejs documentation there is environment variable to define additional ca-bundle certificates.

NODE_EXTRA_CA_CERTS=/etc/pki/tls/certs/ca-bundle.crt

After updated the systemd service file definition and restart the service, on the self-hosted agent, it fetched the secrets successfully.

/etc/systemd/system/azure-pipeline-agent.service

[Unit]
Description=Azure Pipeline Agent
After=network-online.target
Wants=network-online.target

[Service]
User=1003
ExecStart=/home/user1/azure-agent/run.sh
Environment=NODE_EXTRA_CA_CERTS=/etc/pki/tls/certs/ca-bundle.crt
Environment=http_proxy="http://your-proxy:8080"
Environment=https_proxy="http://your-proxy:8080"
Environment=no_proxy="localhost,127.0.0.1"
[Install]
WantedBy=multi-user.target

Environment=NODE_EXTRA_CA_CERTS=/etc/pki/tls/certs/ca-bundle.crt
systemctl daemon-reload
systemctl restart azure-pipeline-agent.service

Starting: AzureKeyVault
==============================================================================
Task         : Azure Key Vault
Description  : Download Azure Key Vault secrets
Version      : 1.259.2
Author       : Microsoft Corporation
Help         : https://docs.microsoft.com/azure/devops/pipelines/tasks/deploy/azure-key-vault
==============================================================================
SubscriptionId: <REDACTED>
Key vault name: <REDACTED>
Downloading secret value for: webhooktest.
Finishing: AzureKeyVault

How to Make Simple IR Sender(Samsung TV)

Sun, 03 Aug 2025 18:00:00 +0000

Although Infrared (IR) technology might seem outdated in today’s world of smart homes and wireless everything, it’s far from obsolete. In fact, IR is still widely used in many household devices—most notably, televisions. Even with the growing presence of Android-based smart TVs, IR remains an inevitable part of device control.

Most IR receivers are designed to detect signals modulated at 38 kHz. To be detected by the receiver, the IR signal must be modulated at (or very close to) 38 kHz.

Interestingly, this particular IR sender transmits a modulated signal at 40 kHz, slightly above the more common 38 kHz. Using the formula T = 1 / f, we can calculate the period of the signal:

T = 1 / 40,000 Hz = 25 microseconds (µs)

This means each cycle consists of 12.5 µs ON and 12.5 µs OFF, forming the standard square wave used for modulation.

Now, if you want to send a 4.5 ms burst at this frequency, you’d need to repeat this 25 µs signal 180 times:

4.5 ms / 25 µs = 180 cycles

4.5 ms = 4500 µs
4500/25 = 180

for (i = 0; i <= (duration / 25.0) ; i++){
  Set IR LED HIGH;
  delay  12.5 µs
  SET IR LED LOW
  delay  12.5 µs
}

The IR sender that I built for Samsung TV . It has some similarities with NEC protocol but not exactly. It uses following pattern;

9 ms. START Bit (4.5 milisecond ON , 4.5 milisecond OFF)
16 bit device code (0x0707)
A 16-bit command code typically consists of an 8-bit command followed by its 8-bit inverse (bitwise NOT). Example: If the command is 0xA2, the inverse would be ~0xA2 = 0x5D, so the full 16-bit command becomes 0xA25D.
ON IR Led for 560 µs and then OFF

Logic 1 (ON)- 560 µs HIGH, 1690 µs LOW

Logic 0(OFF) – 560 µs HIGH, 560 µs LOW

I am sharing you the schematic for IR Sender.

You can find my C code for IR sender in my GitHub repo.

You can also find the Logic Analyzer capture in the same GitHub repo. In order to view the capture, you need a program, which you can download from Saleae.

The model I captured the traffic from IR remote control model: BN59-01198Q

Hack Remote IR Controller with Logic Analyzer

Sun, 20 Jul 2025 18:00:00 +0000

A logic analyser is one of the cheapest and most powerful tools you can use in electronics. It helps you visualize how devices communicate — showing you logic levels, signal timing, and protocol data in a way that’s far more insightful than just reading datasheets.

Although I’ve owned a logic analyzer for a while, I had never used it — until now.

To analyse the IR remote control signals, I built a simple circuit on a breadboard. I’ve also shared the schematic below for reference.

After just a few keystrokes, I noticed that the Chinese remote sends each IR signal at least twice to the receiver.

By analyzing the timing with a logic analyzer, I discovered that the remote uses the SIRC protocol. It transmits data at a frequency of 40kHz, following a consistent pattern:

Start bit: 2.4 ms
Logic 1: 1.2 ms HIGH + 0.6 ms LOW
Logic 0: 0.6 ms HIGH + 0.6 ms LOW

It’s important to note that most IR receivers are active LOW, meaning they pull the signal LOW when they detect an IR pulse.

Please checkout the website for more information about SIRC and other IR communication protocols.

Although modern homes often include advanced automation systems like Alexa or Google Home, I decided to go back to basics and write a simple C program to build a SIRC receiver. This receiver toggles relays (or in this case, an LED) based on IR commands—perfect for understanding how things work under the hood.

You can check on my GitHub repo to see 12 bit version of Sony SIRC protocol.

Experiment:

Here is the output of the Serial monitor. Current version of code supports only two keys combination, which are Channel + and Channel -.

My Repair Note on DC – AC Inverter

Sun, 20 Jul 2025 18:00:00 +0000

Dear blog readers before sharing my repair note, I want to make you aware that this activity involves working with high voltage, which can cause serious injury or death. Do not attempt this repair unless you are fully trained and understand the risks. Improper handling of electrical components can be fatal. Safety precautions, proper tools, and a deep understanding of what you’re doing are essential.

Proceed at your own risk.

I wanted to share how I repaired an inverter that I had been using in my garden. The device had been out of service for quite some time, just sitting there unused. Luckily, I finally set aside some time to take a closer look at it.

The first step was removing the front panel of the inverter. At first glance, I noticed something unusual — the blade fuses (the small green components) didn’t look quite right. Their color seemed off, which immediately raised a red flag.

After checked them closely, I clearly saw them they were blown out.

Nevertheless, I was able to see the value of current for the fuses. (35 A). So, new fuses were ordered on the Internet and replaced old ones with the new ones carefully. Be careful with the replacement… Make sure that no DC supply is provided to inverter and no stored voltage in the capacitors.

Testing

It is now time for testing. As simple test, the inverter was supplied with small adjustable DC Power supply at 14V. As result, provided DC and current is enough to produce AC 220 Voltage to drive small RGB Led strip.

In order to drive more powerful appliances, you need to supply inverter with more powerful DC source such as car batteries.

OCP Upgrade with Canary Rollout Strategy

Sun, 20 Jul 2025 18:00:00 +0000

Node upgrades are a critical aspect of maintaining a healthy OpenShift cluster. Whether it’s applying security patches, updating underlying dependencies, or simply scaling up resources, the process must be executed with precision to avoid disruptions to running workloads.

OpenShift(Kubernetes) node upgrade methods often involve draining nodes, evacuating workloads, and performing the upgrade, leading to potential downtime and service interruptions. This can be particularly challenging in production environments where any disruption can have cascading effects on business operations.

Instead of upgrading all nodes simultaneously, a subset of nodes can be selected and upgraded, first.

In this post, I will walk you through, how to upgrade OCP nodes predictably, while some of workloads are running happily. This method can be useful when only particular set of nodes upgrade desired. Please note in that type of OCP upgrade, node restarts are still inevitable. Nevertheless, it could be useful when you need to postpone upgrading some of nodes and applications working on those nodes for sometime.

Key feature that gives us this capability in OCP is Machine Config Pool.

What is Machine Config Pool?

What is Role Binding to a User/Group, Machine Config Pool is to Nodes. It associates Nodes with Machine Configs. For more information about Machine Config Pool, you can follow, the post.

OCP Nodes in Sandbox2 To demonstrate Canary like OCP node upgrade, following cluster will be used. Current version of OCP Sandbox2 cluster version is 4.12.10 and it will be upgraded to the OCP 4.14.10.

Note: To find upgrade path you can use the Red Hat OCP Update Graph application.

According to the Application, OCP versions that we need to follow as below.

4.12.10(Current version) -> 4.12.47 -> 4.13.19 -> 4.14.10

$ oc get nodes
NAME                  STATUS   ROLES                  AGE   VERSION
sandbox2-dmzworker0   Ready    dmzworker,worker       11d   v1.25.16+5c97f5b
sandbox2-dmzworker1   Ready    dmzworker,worker       11d   v1.25.16+5c97f5b
sandbox2-infra0       Ready    infra,worker           35d   v1.25.16+5c97f5b
sandbox2-infra1       Ready    infra,worker           35d   v1.25.16+5c97f5b
sandbox2-master0      Ready    control-plane,master   35d   v1.25.16+5c97f5b
sandbox2-master1      Ready    control-plane,master   35d   v1.25.16+5c97f5b
sandbox2-master2      Ready    control-plane,master   35d   v1.25.16+5c97f5b
sandbox2-worker0      Ready    worker                 35d   v1.25.16+5c97f5b
sandbox2-worker1      Ready    worker                 35d   v1.25.16+5c97f5b

You can see the Node <-> MCP relation of sandbox2 cluster in the following table

Node Name	MCP Name
sandbox2-worker0	worker
sandbox2-worker1	worker
sandbox2-master0	master
sandbox2-master1	master
sandbox2-master2	master
sandbox2-dmzworker0	dmzworker
sandbox2-dmzworker1	dmzworker
sandbox2-infra0	infra
sandbox2-infra1	infra

Machine Config Pools in the Sandbox2 Cluster

$ oc get mcp
NAME        CONFIG                                                UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
dmzworker   rendered-dmzworker-4b77d58a5da76d5a8126d186460a28a6   True      False      False      2              2                   2                     0                      11d
infra       rendered-infra-4b77d58a5da76d5a8126d186460a28a6       True      False      False      2              2                   2                     0                      35d
master      rendered-master-ddad513671757f22d78d41940ab0255c      True      False      False      3              3                   3                     0                      35d
worker      rendered-worker-4b77d58a5da76d5a8126d186460a28a6      True      False      False      2              2                   2                     0                      35d

Before Update/Upgrade of the Cluster, it is required to create additional MCPs and join some of nodes to these new MCPs.

Create Additional MCP

In this section additional three MPCs will be created and some of nodes will be added to these new MCPs.

infra-canary

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  name: infra-canary
spec:
  machineConfigSelector:
    matchExpressions:
      - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,infra]}
  maxUnavailable: 1
  nodeSelector:
    matchExpressions:
      - {key: node-role.kubernetes.io/infra-canary, operator: Exists}
  paused: false

dmzworker-canary

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  name: dmzworker-canary
spec:
  machineConfigSelector:
    matchExpressions:
      - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,dmzworker]}
  maxUnavailable: 1
  nodeSelector:
    matchExpressions:
      - {key: node-role.kubernetes.io/dmzworker-canary, operator: Exists}
  paused: false

worker-canary

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  name: worker-canary
spec:
  machineConfigSelector:
    matchExpressions:
      - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker]}
  maxUnavailable: 1
  nodeSelector:
    matchLabels:
      node-role.kubernetes.io/worker-canary: ""
  paused: false

Update existing MCP

Existing MCPs will be updated with matchExpressions selector to disjoin desired nodes from its original MCPs.

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  name: dmzworker
spec:
  machineConfigSelector:
    matchExpressions:
      - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,dmzworker]}
  maxUnavailable: 1
  nodeSelector:
    matchExpressions:
      - {key: node-role.kubernetes.io/dmzworker-canary, operator: DoesNotExist}
    matchLabels:
      node-role.kubernetes.io/dmzworker: ""
  paused: false

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  name: infra
spec:
  machineConfigSelector:
    matchExpressions:
      - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,infra]}
  maxUnavailable: 1
  nodeSelector:
    matchExpressions:
      - {key: node-role.kubernetes.io/infra-canary, operator: DoesNotExist}
    matchLabels:
      node-role.kubernetes.io/infra: ""
  paused: false

Placing nodes to new MCPs

To place desired nodes to its new MCPs, additional label needs to be added to the nodes. In this post, nodes with odd number will be re-joined to the new MCPs.

$ oc label node sandbox2-infra1 node-role.kubernetes.io/infra-canary=""
$ oc label node sandbox2-dmzworker1 node-role.kubernetes.io/dmzworker-canary=""
$ oc label node sandbox2-worker1 node-role.kubernetes.io/worker-canary=""

After adding label to the nodes, Node <-> MCP membership should be as in the table below.

Node Name	MCP Name
sandbox2-worker0	worker
sandbox2-worker1	worker-canary
sandbox2-master0	master
sandbox2-master1	master
sandbox2-master2	master
sandbox2-dmzworker0	dmzworker
sandbox2-dmzworker1	dmzworker-canary
sandbox2-infra0	infra
sandbox2-infra1	infra-canary

Note: No special configuration applied for control-plane nodes, as only one node will be unavailable at a time during the upgrade of OCP cluster.

$ oc get nodes
NAME                  STATUS   ROLES                          AGE    VERSION
sandbox2-dmzworker0   Ready    dmzworker,worker               3d4h   v1.26.12+9ed7eae
sandbox2-dmzworker1   Ready    dmzworker,dmzworker-canary,worker   3d4h   v1.25.7+eab9cc9
sandbox2-infra0       Ready    infra,worker                   3d4h   v1.26.12+9ed7eae
sandbox2-infra1       Ready    infra,infra-canary,worker           3d4h   v1.25.7+eab9cc9
sandbox2-master0      Ready    control-plane,master           3d5h   v1.26.12+9ed7eae
sandbox2-master1      Ready    control-plane,master           3d5h   v1.26.12+9ed7eae
sandbox2-master2      Ready    control-plane,master           3d5h   v1.26.12+9ed7eae
sandbox2-worker0      Ready    worker                         3d5h   v1.26.12+9ed7eae
sandbox2-worker1      Ready    worker,worker-canary                3d5h   v1.25.7+eab9cc9

$ oc get mcp  -o='jsonpath={range .items[*]}{.metadata.name} "------------->"{.spec.paused}{"\n"}'
dmzworker "------------->"false
dmzworker-canary "------------->"false
infra "------------->"false
infra-canary "------------->"false
master "------------->"false
worker "------------->"false
worker-canary "------------->"false

Pause -canary MCPs

This is the last and highly important step before the Update/Upgrade of the cluster. In this step, -canary MCPs paused set to true. With that, no cluster update/upgrade will take place on these nodes. Consequently, workloads running on these nodes will not be affected.

Note: Please do not forget to check deprecated/removed feature before OpenShift Upgrade, otherwise running applications can be affected due to removed API versions/features.

According to following setting any update/upgrade -canary will not be affected for nodes member of canary MCPs. (paused: true)

$ oc patch mcp/worker-canary --patch '{"spec":{"paused":true}}' --type=merge
$ oc patch mcp/infra-canary --patch '{"spec":{"paused":true}}' --type=merge
$ oc patch mcp/dmzworker-canary  --patch '{"spec":{"paused":true}}' --type=merge


$ oc get mcp  -o='jsonpath={range .items[*]}{.metadata.name} "------------->"{.spec.paused}{"\n"}'
dmzworker "------------->"false
dmzworker-canary "------------->"true
infra "------------->"false
infra-canary "------------->"true
master "------------->"false
worker "------------->"false
worker-canary "------------->"true

RHOCP Update (4.12.10 to 4.12.47)

Before the update/upgrade of OpenShift, required OpenShift version images are mirrored to container registry. You can follow the guide how to mirror image for disconnected update/upgrade of OpenShift, here.

$ oc apply -f scripts/signatures/rhocp-release-4.12.47.json

$ oc adm upgrade --allow-explicit-upgrade --to-image registry.local.io/openshift/openshift-release-dev@sha256:fcc9920ba10ebb02c69bdd9cd597273260eeec1b22e9ef9986a47f4874a21253

RHOCP Upgrade (4.12.47 to 4.13.29)

$ oc apply -f scripts/signatures/rhocp-release-4.13.29.json

$ oc adm upgrade --allow-explicit-upgrade --to-image registry.local.io/openshift/openshift-release-dev@sha256:9c4a4471bb93ab11d255925535ff719742cafa8ae06d622b870133787a72abc3

$ oc -n openshift-config patch cm admin-acks --patch '{"data":{"ack-4.12-kube-1.26-api-removals-in-4.13":"true"}}' --type=merge

RHOCP Upgrade (4.13.29 to 4.14.10)

$ oc apply -f scripts/signatures/rhocp-release-4.14.10.json

$ oc adm upgrade --allow-explicit-upgrade --to-image registry.local.io/openshift/openshift-release-dev@sha256:03cc63c0c48b2416889e9ee53f2efc2c940323c15f08384b439c00de8e66e8aa

$ oc -n openshift-config patch cm admin-acks --patch '{"data":{"ack-4.13-kube-1.27-api-removals-in-4.14":"true"}}' --type=merge

As you can see all Nodes which where member of existing MCPs are Updated/Upgraded. But member of -canary nodes are still the same version.

$ oc get nodes
NAME                  STATUS   ROLES                          AGE    VERSION
sandbox2-dmzworker0   Ready    dmzworker,worker               3d5h   v1.27.9+e36e183
sandbox2-dmzworker1   Ready    dmzworker,dmzworker-canary,worker   3d5h   v1.25.7+eab9cc9
sandbox2-infra0       Ready    infra,worker                   3d5h   v1.27.9+e36e183
sandbox2-infra1       Ready    infra,infra-canary,worker           3d5h   v1.25.7+eab9cc9
sandbox2-master0      Ready    control-plane,master           3d6h   v1.27.9+e36e183
sandbox2-master1      Ready    control-plane,master           3d6h   v1.27.9+e36e183
sandbox2-master2      Ready    control-plane,master           3d6h   v1.27.9+e36e183
sandbox2-worker0      Ready    worker                         3d6h   v1.27.9+e36e183
sandbox2-worker1      Ready    worker,worker-canary               3d6h   v1.25.7+eab9cc9

Upgrade Nodes in -canary MCP

There are two ways to upgrade paused nodes. (Nodes which have not been touched yet).

Set paused: false to new MCPs(-canary) OR remove label `node-role.kubernetes.io/-canary` on node.

Upgrade Nodes in infra-canary MCP(First Method)

Set paused: false which upgrade all nodes which member of infra-canary MCP.

$ oc patch mcp/infra-canary --patch '{"spec":{"paused":false}}' --type=merge

$ oc get nodes
NAME                  STATUS   ROLES                          AGE    VERSION
sandbox2-dmzworker0   Ready    dmzworker,worker               3d6h   v1.27.9+e36e183
sandbox2-dmzworker1   Ready    dmzworker,dmzworker-canary,worker   3d6h   v1.25.7+eab9cc9
sandbox2-infra0       Ready    infra,worker                   3d6h   v1.27.9+e36e183
sandbox2-infra1       Ready    infra,infra-canary,worker           3d6h   v1.27.9+e36e183
sandbox2-master0      Ready    control-plane,master           3d7h   v1.27.9+e36e183
sandbox2-master1      Ready    control-plane,master           3d7h   v1.27.9+e36e183
sandbox2-master2      Ready    control-plane,master           3d7h   v1.27.9+e36e183
sandbox2-worker0      Ready    worker                         3d6h   v1.27.9+e36e183
sandbox2-worker1      Ready    worker,worker-canary                3d6h   v1.25.7+eab9cc9

Upgrade Nodes in dmzworker-canary MCP (Second Method)

In this method label node-role.kubernetes.io/dmzworker-canary label will be removed and node dmzworker1 will rejoin to dmzworker MCP.

$ oc label node sandbox2-dmzworker1 node-role.kubernetes.io/dmzworker-canary-
node/sandbox2-dmzworker1 unlabeled

$ oc get mcp dmzworker-a
NAME          CONFIG                                                  UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
dmzworker-canary   rendered-dmzworker-canary-fce74906989201f3653152f435f3a9e3   True      False      False      0              0                   0                     0                      3d3h
$ oc get mcp dmzworker
NAME        CONFIG                                                UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
dmzworker   rendered-dmzworker-fce74906989201f3653152f435f3a9e3   False     True       False      2              1                   1                     0                      3d6h

Upgrade Nodes in worker-canary MCP (First Method)

$ oc patch mcp/worker-canary --patch '{"spec":{"paused":false}}' --type=merge

Share Serial Devices with WSL Machine

Sun, 23 Feb 2025 18:00:00 +0000

usbipd-win is a project to share serial devices with WSL machine. (Windows Subsystem for Linux).

It is highly useful when you develop embedded systems on Windows hosts inside WSL machine.

Download and install usbipd MSI Package in GitHub releases page.
Run CMD Prompt as Admin(Run as Administrator)

C:\Windows\System32>usbipd list
Connected:
BUSID  VID:PID    DEVICE                                                        STATE
1-4    0489:e0e2  MediaTek Bluetooth Adapter                                    Not shared
2-1    1a86:7523  USB-SERIAL CH340 (COM4)                                       Attached
4-1    05ac:12a8  Apple Mobile Device USB Composite Device                      Not shared
5-1    3277:0033  USB2.0 FHD UVC WebCam, USB2.0 IR UVC WebCam, Camera DFU D...  Not shared
7-3    046d:082d  HD Pro Webcam C920                                            Not shared

In this example, I want to share USB-SERIAL device in order to program ESP8266 chip.

Bind Serial Device:

C:\Windows\System32>usbipd bind  -i  1a86:7523
usbipd: info: Device with hardware-id '1a86:7523' found at busid '2-1'.

Attach Serial Device into WSL

C:\Windows\System32>usbipd attach --wsl -i  1a86:7523
usbipd: info: Device with hardware-id '1a86:7523' found at busid '2-1'.
usbipd: info: Using WSL distribution 'Ubuntu' to attach; the device will be available in all WSL 2 distributions.
usbipd: info: Detected networking mode 'nat'.
usbipd: info: Using IP address 172.19.144.1 to reach the host.

dmesg message on WSL(Ubuntu)

[ 6188.974470] usb 1-1: SetAddress Request (2) to port 0
[ 6189.019112] usb 1-1: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice= 2.54
[ 6189.019130] usb 1-1: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[ 6189.019134] usb 1-1: Product: USB2.0-Serial
[ 6189.050824] usbcore: registered new interface driver ch341
[ 6189.050843] usbserial: USB Serial support registered for ch341-uart
[ 6189.050857] ch341 1-1:1.0: ch341-uart converter detected
[ 6189.064874] usb 1-1: ch341-uart converter now attached to ttyUSB0
[ 6250.842958] vhci_hcd: unlink->seqnum 6680
[ 6250.842963] vhci_hcd: urb->status -104
[ 6250.843465] vhci_hcd: unlink->seqnum 6681