Forem: 12ww1160

ConfDroid Puppet Modules - Selinux

12ww1160 — Sat, 11 Apr 2026 10:04:51 +0000

Introducing confdroid_selinux: Declarative SELinux Management for Your Rocky 9 Servers

Security-Enhanced Linux (SELinux) is one of the most powerful built-in defenses on modern Linux systems. Unlike traditional permission-based security (user/group/other), SELinux adds mandatory access control (MAC) at the kernel level. It labels every process, file, directory, and network port with a security context and enforces strict policies that say exactly what each subject is allowed to do with each object — no matter what the file permissions say.

This means even if an attacker gains root or tricks a service into writing a malicious file, SELinux can still block the attack because the file simply doesn’t have the right context.
Many enterprise Linux distributions enable SELinux by default in enforcing mode on fresh installs:

Rocky Linux 9
AlmaLinux 9
Red Hat Enterprise Linux (RHEL) 9
Fedora

On these systems, SELinux is not an afterthought — it’s a core part of the security model.

How SELinux Stops Real-World Attacks

Imagine an attacker sends a phishing email with a malicious script disguised as a legitimate configuration file. The user (or a compromised service) downloads and places the file in /tmp or a web directory.

Without SELinux:

If the file has execute permissions, the attacker might be able to run it.

With SELinux (enforcing mode):

The file gets created with the wrong security context (for example, user_tmp_t instead of httpd_exec_t).
Even if the attacker somehow makes the file executable, SELinux denies execution or access because the policy doesn’t allow it.
The attack is stopped cold, and an audit log entry is generated.

SELinux turns potential disasters into harmless denied operations.

The Problem with Manual SELinux Management

While SELinux is powerful, managing it consistently across many servers is painful:

Forgetting to run restorecon after placing files
Accidentally setting the wrong mode (setenforce)
Configuration drift between hosts

That’s exactly why I built confdroid_selinux.

What confdroid_selinux Does

This new Puppet 8 module (tested on Rocky 9) gives you full declarative control over SELinux:

Installs all required SELinux tools and binaries
Manages the main configuration file /etc/sysconfig/selinux with correct permissions and SELinux contexts
Controls the global SELinux mode (enforcing or permissive) — the Puppet equivalent of setenforce
Ensures every file and directory managed by other Confdroid modules receives the proper SELinux context
Works cleanly on enforcing-mode systems

All other Confdroid modules (see the full collection overview) already include proper SELinux context handling:

and many more.

They work even better when **confdroid_selinux** is present, because the global policy and mode are managed in one place.

SELinux Management Flow with the Module

Here’s how the module turns your Puppet run into reliable SELinux enforcement:

Easy Deployment

Simple inclusion: in your site.pp or nodes.pp:

include confdroid_selinux

with Foreman (recommended):

Add the confdroid_selinux::params class to the host or host group and override parameters (mode, etc.) as smart class parameters.

Important notes:
Test in a non-production environment first.
If you are switching from disabled to enforcing mode, a reboot is required (the module does not reboot automatically to avoid surprises).

You can find the full module, source code, and parameter reference here:
→

Final Thoughts

SELinux is no longer optional on modern enterprise Linux. With confdroid_selinux, you get consistent, version-controlled, and fully automated SELinux management that works hand-in-hand with the rest of the Confdroid collection.
Your servers stay secure by default — even when things go wrong elsewhere.
Have you been running SELinux in enforcing mode across your fleet, or are you still in permissive because of management headaches? Would you like to see more advanced features (custom Booleans, custom modules, etc.) in a future version? Let me know in the comments!

Did you find this post helpful? You can support me.

ConfDroid Puppet Modules - Automatic

12ww1160 — Tue, 07 Apr 2026 10:59:02 +0000

Introducing confdroid_automatic: Hands-Off OS Updates for Your Rocky 9 Servers

Keeping operating systems patched is one of the most important — yet often neglected — parts of server maintenance. Security updates arrive regularly, and manually applying them across dozens or hundreds of machines quickly becomes a burden and a source of risk.

That’s why I’m happy to release confdroid_automatic, the latest addition to the Confdroid Puppet collection.

This module brings reliable, automated OS updates to Rocky 9 (and other RHEL 9-based) systems by managing dnf-automatic declaratively with Puppet 8. It installs the necessary packages, configures update behavior, applies correct SELinux contexts, and ensures the systemd timer runs as expected.

Why Automated Updates Matter

Security patches close vulnerabilities before attackers can exploit them. dnf-automatic already does most of the heavy lifting out of the box — it can download and apply updates on a schedule, send notifications, and even reboot when needed. The challenge is managing it consistently across your entire fleet without configuration drift.

Additionally, production systems may need a different set of policies for updates than development or staging system, i.e. only security updates, while other stages use fully updated systems.

confdroid_automatic solves that by turning dnf-automatic into a fully Puppet-controlled service.

Key Features

Installs and configures the dnf-automatic package
Manages the main configuration file (/etc/dnf/automatic.conf) with proper permissions and SELinux contexts
Controls the dnf-automatic.timer systemd service
Supports flexible parameters you can override via Foreman ENC or Hiera
Includes sensible defaults for production use while allowing fine-tuning

Main tunable parameters include:

ac_upgrade_type- 'default', 'security', 'minimal' or 'all'
ac_apply_updates — whether to actually install updates (or just download them)
ac_download_updates — enable downloading of available packages
ac_random_sleep — add a random delay (in seconds) to prevent all servers from updating at the exact same moment
ac_reboot - when to reboot after applied updates
ac_email_to - which email address to notify

Automatic Update Flow

Here’s how the module turns Puppet configuration into real-world automated patching:

The flow ensures updates are applied safely and predictably. The optional random sleep helps avoid “thundering herd” problems in larger environments.

How to Use It

Import the module via r10k (Puppetfile).

The simplest way to enable automatic updates on a node is in site.pp:

include confdroid_automatic

To apply via Foreman:

Assign confdroid_automatic::params to the host or hostgroup in Question and override parameters as required.

Important Notes

Test thoroughly in a non-production environment first. Automatic updates can cause reboots or service restarts.
If you already have a manual dnf-automatic configuration, the module will overwrite it — start clean or review the generated config carefully.
The module handles SELinux contexts automatically, so it works smoothly on enforcing-mode Rocky 9 systems.

You can find the full module, source code, and parameter reference here: https://sourcecode.confdroid.com/confdroid/confdroid_automatic

Final Thoughts

With confdroid_automatic, keeping your Rocky 9 fleet patched becomes a truly hands-off process. Combined with the rest of the Confdroid collection (including monitoring via confdroid_nagios), you get a consistent, secure, and maintainable update strategy.

Automated patching is no longer a nice-to-have — it’s a baseline security requirement. This module makes it simple, repeatable, and fully integrated into your Puppet workflow.

Have you been managing OS updates manually or with scripts? Would you like automatic reboots enabled or prefer a download-only approach? Drop your thoughts or questions in the comments — I’d love to hear how you handle patching in your environment.

Did you find this post helpful? You can support me.

Kubernetes - Argo-CD - Custom Installation

12ww1160 — Sat, 04 Apr 2026 13:42:24 +0000

Installing Argo CD the GitOps Way: A More Stable and Maintainable Approach

I recently deployed Argo CD in my dev cloud and I’m already impressed with how much it improves my Kubernetes workflow. Instead of following the quick official installation method, I adapted the process for better version control, reproducibility, and long-term stability.

The Official Quick-Start Method

The fastest way to get Argo CD running is this one-liner:

kubectl create namespace argocd
kubectl apply -n argocd --server-side --force-conflicts -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

This works great for testing or throwaway environments. For production or long-lived setups, however, I strongly recommend a more deliberate approach.

Why a GitOps-First Installation Is Better

Argo CD is almost entirely configured through Kubernetes ConfigMaps and other manifests. While you can tweak some settings in the web UI, most changes live in YAML files. Relying on ad-hoc kubectl commands makes it easy to lose track of changes, forget why something was modified, or end up with inconsistent configurations across team members.

Here’s the recommended workflow I followed:

Create a dedicated Git repository for Argo CD configuration.
Download the official manifests and commit them to your repo.
Use a CI/CD pipeline to deploy the manifests (use --server-side --force-conflicts on the very first apply).
After the initial deployment, you can let Argo CD manage its own configuration (self-management) or continue using the CI/CD pipeline. Both approaches work well.

The big advantages are clear version history, proper editing with your favorite tools, and a stable local copy that doesn’t change unexpectedly with every upstream update.

Note on --server-side --force-conflicts
This is required because some Argo CD Custom Resource Definitions (like ApplicationSet) exceed the size limit for client-side apply. Server-side apply avoids storing the large last-applied-configuration annotation. The force flag safely takes ownership of fields during fresh installs or upgrades.

Installing the Argo CD CLI (Optional but Handy)

The Argo CD CLI is useful for scripting, automation, and quick checks from your workstation or CI/CD pipelines.
On Linux, install it with:

curl -sSL -o argocd-linux-amd64 https://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-amd64
sudo install -m 555 argocd-linux-amd64 /usr/local/bin/argocd
rm argocd-linux-amd64

Adapting Argo CD for My Environment

Because I expose all services through an external HAProxy that handles TLS termination, I needed to run Argo CD in insecure mode (disabling its built-in TLS). Same is required when you use argocd cli.

apiVersion: v1
kind: ConfigMap
metadata:
  labels:
    app.kubernetes.io/name: argocd-cmd-params-cm
    app.kubernetes.io/part-of: argocd
  name: argocd-cmd-params-cm
data:
  server.insecure: "true"

Exposing Argo CD via NodePort

The official docs don’t clearly document NodePort as an option, so I customized the Service:

apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/component: server
    app.kubernetes.io/name: argocd-server
    app.kubernetes.io/part-of: argocd
  name: argocd-server
spec:
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 8080
    nodePort: 30080   # adjust to your needs
  selector:
    app.kubernetes.io/name: argocd-server
  type: NodePort

Since HAProxy forwards everything to HTTP on port 80, the HTTPS port isn’t needed. The --insecure flag prevents redirect loops.

Setting Up OIDC Authentication with Keycloak

For centralized authentication, I configured Argo CD to use my existing Keycloak instance via OIDC, which his why I needed the service to be accessible from outside Kubernetes in first place:

First, create a client in Keycloak, then add this to the argocd-cm ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cm
data:
  url: https://argocd.yourdomain.com
  oidc.config: |
    name: Keycloak
    issuer: https://keycloak.yourdomain.com/realms/your_realm
    clientID: argocd
    clientSecret: $oidc.keycloak.clientSecret
    refreshTokenThreshold: 2m
    requestedScopes: ["openid", "profile", "email", "groups"]

This gives me single sign-on with Keycloak, which is especially useful in company environments that already use centralized identity management.

Visualizing the GitOps Flow with Argo CD

Here’s how the GitOps loop looks when Argo CD manages applications — and even itself:

Keycloak OIDC Authentication Flow

And here’s the authentication flow once OIDC is configured:

Next Steps

At this point, Argo CD is up and running with a clean GitOps foundation, external load balancing, and centralized authentication. In the next post, I’ll cover how to add and manage your first applications declaratively.
If you’re setting up Argo CD in your own environment — especially with external TLS termination or OIDC — I hope these tweaks save you some time.
Have you tried managing Argo CD declaratively yet? Do you prefer the CLI or the UI for day-to-day operations? Share your thoughts in the comments!

Did you find this post helpful? You can support me.

Puppet with Foreman - PuppetDB Reporting Errors

12ww1160 — Mon, 30 Mar 2026 13:59:16 +0000

Fixing Missing OS, Environment, and Fact Data in Foreman When Using PuppetDB

Recently, I re-introduced PuppetDB into my infrastructure to support the new confdroid_nagios module. Everything worked as expected on the Puppet side — PuppetDB stored facts, catalogs, and reports correctly.

However, when I checked Foreman, something looked wrong. All hosts showed empty fields for basic information such as Operating System, Environment, and many other facts. The core Puppet functionality was fine, but Foreman’s host overview and reporting appeared broken.
After some investigation, I found a simple but important configuration mismatch.

The Root Cause

When Foreman is used as an External Node Classifier (ENC), Puppet needs a specific routing configuration to properly handle facts. This is defined in the file:

/etc/puppetlabs/puppet/routes.yaml

An older default configuration (still present in some Foreman installations) looked like this:

master:
  facts:
    terminus: puppetdb
    cache: yaml

This setup worked in earlier versions of Puppet Server, but modern Puppet Server (starting around version 7) prefers JSON for the fact cache because it is faster and avoids certain quirks of YAML.

The Correct Configuration

Update the file to use JSON as the cache format:

master:
  facts:
    terminus: puppetdb
    cache: json

After making this change, restart the relevant services:

systemctl restart puppetserver
systemctl restart foreman

As soon as the services came back up, all the missing facts — OS details, environments, custom facts, and more — started populating correctly in Foreman.

How the Pieces Fit Together

To make the interaction clearer, here’s a visual overview of the data flow between the Puppet agent, Puppet Server, PuppetDB, and Foreman:

Key flow explained:

The Puppet agent reports facts to the Puppet Server.
Puppet Server stores them in PuppetDB (using the puppetdb terminus).
When Foreman acts as the ENC, the Puppet Server also needs to retrieve facts from PuppetDB to display rich host information in the Foreman UI. The routes.yaml file tells Puppet Server exactly how to read and cache those facts. Using cache: json aligns with current Puppet Server defaults and ensures Foreman receives complete, properly formatted data.

Quick Tip

If you are running a modern Puppet Server (7 or 8) with Foreman and PuppetDB, always double-check that routes.yaml uses cache: json. The older yaml setting can silently cause missing or incomplete data in Foreman without breaking Puppet itself.

This small change took only a few minutes but restored full visibility and reporting in my Foreman dashboard.
Have you run into similar fact synchronization issues between PuppetDB and Foreman? What versions are you running? Feel free to share your experiences or additional tips in the comments.

Did you find this post helpful? You can support me.

ConfDroid Puppet Modules - Fail2ban

12ww1160 — Sat, 28 Mar 2026 18:22:55 +0000

Introducing confdroid_fail2ban: Automated Brute-Force Protection for Your Puppet-Managed Servers

Brute-force attacks remain one of the most common threats to internet-facing services. Attackers continuously scan for open ports and try thousands of username/password combinations against SSH, web logins, admin panels, and other services. Left unchecked, these attacks can lead to compromised accounts, data breaches, or even full server takeovers.

Fail2Ban has been the go-to open-source solution for years. It monitors log files for suspicious patterns — such as repeated failed login attempts — and automatically bans the offending IP addresses by updating firewall rules (usually via iptables).

Out of the box, Fail2Ban already does an excellent job protecting common services like SSH (sshd jail) and Apache with its default settings. It requires almost no manual tuning for basic protection, making it a set-it-and-forget-it tool that quietly strengthens server security.

Taking Fail2Ban Further with Puppet

While Fail2Ban works great on its own, managing it consistently across multiple servers — especially with custom jails for non-standard services — quickly becomes tedious. That’s where my new Puppet module comes in.

I’m happy to announce the release of confdroid_fail2ban, now available in the Confdroid Forge.
This module provides a clean, declarative way to install, configure, and manage Fail2Ban on RHEL/Rocky 9 systems using Puppet 8. It handles everything from package installation and directory setup (with correct SELinux contexts) to managing the core configuration files and systemd service.

Key Features

Full management of fail2ban.conf, fail2ban.local, jail.conf, and jail.local (using the standard .local override pattern)
Proper filesystem permissions and SELinux context handling
Easy parameter overrides via Foreman ENC or Hiera (e.g., ban time, destination email for notifications, Nagios monitoring integration)
Support for enabling/disabling the service
Seamless integration with iptables for automatic IP banning
Designed to work smoothly alongside other Confdroid modules

Custom Jails for Modern Services

Many self-hosted applications (Gitea, custom Apache setups, Nagios, etc.) are not covered by Fail2Ban’s default jails. The confdroid_fail2ban module makes it simple to add and tune custom jails for these services.

For example, when you use the confdroid_apache module, you can easily enable a tailored Apache authentication jail that monitors the correct log paths and applies appropriate thresholds.
Going forward, other Confdroid modules that expose authentication or admin interfaces will include their own recommended custom jails where needed. This creates a consistent, zero-touch security layer across your entire infrastructure.

Why This Matters

In today’s threat landscape, relying solely on strong passwords or basic firewall rules is no longer enough. Automated brute-force protection like Fail2Ban adds a critical defensive layer that reacts in real time — banning attackers before they succeed.
By managing Fail2Ban declaratively with Puppet, you gain:

Consistent security posture across all servers
Version-controlled configuration
Easy customization without editing files by hand
Reduced risk of configuration drift

Getting Started

Deploying the module is straightforward. Simply deploy it via R10k and include the class in your node definition:

include confdroid_fail2ban

Via Foreman by adding *confdroid_fail2ban::params * to your hosts or hostgroups.

You can then fine-tune parameters (ban time, email notifications, specific jails, etc.) through your ENC.
Note: If you already have a manually configured Fail2Ban installation, test this module in a non-production environment first, as it manages configuration files comprehensively.

You can find the full module, documentation, and parameter reference here: https://sourcecode.confdroid.com/confdroid/confdroid_fail2ban

Final Thoughts

Security should be automated and consistent. confdroid_fail2ban makes it easy to bring reliable brute-force protection to all your Puppet-managed servers while keeping configuration clean and maintainable.
If you run self-hosted services like Gitea, Apache-based apps, or internal tools, I highly recommend pairing this module with the rest of the Confdroid collection for a cohesive and secure setup.
What services do you protect with Fail2Ban today? Have you run into challenges managing custom jails? Feel free to share your experiences in the comments.

Did you find this post helpful? You can support me.

Wordpress - Caching riddles

12ww1160 — Sat, 28 Mar 2026 15:58:03 +0000

When Caching Breaks Your WordPress REST API: A Debugging Story and Why Caching Still Matters

For the past six months, my custom publishing pipeline has worked flawlessly. I write a blog post once in Markdown with YAML frontmatter, push it to Git, and a Jenkins-based CI/CD pipeline automatically publishes it to multiple platforms. WordPress serves as the canonical source, with the pipeline using the WordPress REST API to create or update posts, upload media, set tags, and handle everything else.

Then, two days ago, everything stopped. The pipeline started throwing tracebacks on every run. Nothing in my code or setup had changed — only a new post was being published. Even after removing the new post, the errors persisted. A similar pipeline on another site broke at the same time.

After a full day of troubleshooting, I narrowed it down: the WordPress REST API was returning completely empty responses for posts and tags endpoints. That left only two likely culprits — a recent WordPress core update or a plugin update.
I rolled back the latest WordPress update (not ideal, as database schema changes can cause issues). No improvement. Then I began disabling plugins one by one. The culprit? W3 Total Cache.

Even though it was explicitly configured not to cache the REST API, it was still interfering and returning empty pages. Disabling the plugin instantly fixed the problem. What surprised me most was that this same setup had worked without issues for several years. I tried flushing all caches, re-saving settings, and restarting services multiple times — nothing helped. In the end, I switched to WP Super Cache (developed by Automattic) and so far, everything is running smoothly again.
I still want to keep caching on my WordPress sites — it’s simply too important for performance to give up.

Why Caching Is Essential for WordPress Sites

Caching dramatically improves website speed and user experience by storing ready-to-serve versions of your content instead of regenerating it from scratch on every request. Without it:

Every page load hits the database and PHP processor heavily.
Server load increases, especially under traffic spikes.
Visitors experience slower load times, which hurts both user satisfaction and SEO.

Modern caching plugins typically combine several layers:

Page caching — Stores full HTML output as static files.
Object caching — Caches database queries and expensive operations (often using Memcached or Redis).
Browser caching — Tells visitors’ browsers how long to keep assets like images, CSS, and JavaScript.
Minification and CDN integration — Reduces file sizes and delivers content from edge locations.

The challenge arises when caching touches dynamic endpoints like the WordPress REST API, which my publishing pipeline relies on. API calls need fresh, up-to-date data — not stale cached responses.

How Object Caching Works with Memcached (Visualized)

Here’s a simplified flow of how object caching (using Memcached) typically works in a WordPress environment:

In this flow:

On a cache hit, the response is served almost instantly from memory.
On a cache miss, WordPress does the heavy work once, then stores the result in Memcached so future requests are lightning-fast.
Keys usually include a version or hash so updates can invalidate old entries.

The trick is configuring the cache plugin to exclude dynamic paths like /wp-json/ while still benefiting from full-page and object caching everywhere else.

Lessons Learned

Even well-configured caching plugins can suddenly interfere with the REST API after years of smooth operation.
When debugging API issues, always consider caching plugins early in the process.
Simpler solutions like WP Super Cache can sometimes be more reliable for certain setups than feature-heavy ones like W3 Total Cache.
Caching remains one of the highest-ROI performance improvements you can make on a WordPress site — just make sure it plays nicely with your automation and API-driven workflows.

My publishing pipeline is back online, and I’ll continue monitoring how WP Super Cache behaves over the coming weeks. If you run a similar automated publishing setup or rely heavily on the WordPress REST API, double-check your caching exclusions.

Have you ever had a caching plugin silently break your API calls? Which caching solution are you using now — W3 Total Cache, WP Super Cache, or something else? Share your experiences in the comments.

Did you find this post helpful? You can support me.

Git - Verified Commits with SSH keys

12ww1160 — Thu, 26 Mar 2026 18:09:41 +0000

Why Verified Commits Matter in Git — And How I Fixed Mine with SSH Signing

When I first started using Git, I had no idea that anyone could easily impersonate me — or anyone else — in the commit history. It turns out it’s shockingly simple.
All you need to do is run a couple of commands like:

git config user.name "Someone Important"
git config user.email "ceo@bigproject.com"

Suddenly, your commits appear as if they came from that person. The commit message, author field, and history all reflect the fake identity. No hacking required.
This isn’t just a theoretical issue. Many supply chain attacks rely on exactly this technique: an attacker creates a convincing pull request under a trusted name, gets it merged, and malicious code slips into the project. Without verified commits, there’s no cryptographic proof that the person who pushed the code is really who they claim to be.

That’s why verified commits are a critical security practice. Whether you’re running your own GitLab instance, using GitHub, or managing any shared repository, you should strongly consider requiring verified commits — either through automatic enforcement (if your platform supports it) or rigorous peer review.

My First Step: Switching to GPG Signing

Once I understood the risk, I created a GPG key, uploaded the public key to my GitLab account (with a verified email address), and enabled commit signing. From that point on, my commits showed up with a nice “Verified” badge. It felt secure and professional.

The Keycloak Integration That Broke Everything

Earlier this year, I connected my self-hosted GitLab instance to Keycloak to centralize authentication across all my applications. The move was mostly smooth and improved my overall security posture.
But then something strange happened: all my new commits suddenly appeared as “Unverified.”
I spent nearly two full days troubleshooting — checking keys, emails, configurations, and even re-uploading keys — with no success. The problem felt impossible to pinpoint.

The Simpler Solution: SSH Commit Signing

Yesterday I finally dug deeper and discovered that modern Git supports two main ways to sign commits: GPG keys and SSH keys.

Since I already use SSH keys to authenticate and push to GitLab, switching to SSH signing was straightforward. Here’s exactly what I did:

Tell Git to use SSH for signing:

git config --global gpg.format ssh

Point Git to my existing SSH public key:Bash

git config --global user.signingkey ~/.ssh/id_ed25519.pub

(Replace with the path to your own public key file.)

I already had these settings enabled for automatic signing:

git config --global commit.gpgsign true
git config --global tag.gpgsign true

That’s it.

Because my SSH public key was already uploaded to my GitLab account (required for SSH access anyway), and the key supports both authentication and signing (the default for most modern keys), all my commits immediately started showing as Verified again.

Why SSH Signing Feels Easier Than GPG

No need to upload the public key to external GPG keyservers.
You’re probably already using an SSH key for Git operations. It is much more convenient than using credentials via https.
The configuration is lightweight and integrates cleanly with your existing setup.
GitLab and GitHub both support SSH commit verification out of the box.

The Bigger Picture: Make Verified Commits Non-Negotiable

Verified commits close a dangerous gap in the supply chain. They provide cryptographic proof that the code came from the claimed author and hasn’t been tampered with after signing.

If you administer repositories or run a Git instance:

Enable “Reject unsigned commits” push rules where available (i.e. Gitlab Premium and Ultimate tiers).
On GitHub, use branch protection rules to require signed commits.
Encourage (or require) your team to sign every commit.

It only takes a few minutes to set up, but it adds a meaningful layer of protection against impersonation and supply chain attacks.
In my case, switching to SSH signing restored my verified status in minutes and reminded me how important this practice really is. My Git workflow now feels secure again — and the world (or at least my private cloud) is a little safer.

Have you started signing your commits yet? Are you using GPG, SSH, or both? I’d love to hear what worked best for you in the comments.

Why Verified Commits Matter – Visualized

To make the process easier to understand, here’s a clear flowchart of the Git Commit Verification Flow. It shows how easy it is to impersonate someone without signing, and how cryptographic signing (especially with SSH keys) creates a trustworthy, verifiable chain.

How to Read the Diagram

Right side (Insecure path): Anyone can fake an author identity with just two git config commands. The commit looks legitimate to the naked eye, but carries no proof of who really created it. This is the vector many supply chain attacks exploit.
Left side (Secure path): When you enable commit signing:

Git uses your private key (GPG or SSH) to create a cryptographic signature.
You upload the public key once to your Git hosting platform (GitHub, GitLab, etc.).
The platform automatically verifies the signature on every push.
Successful verification results in the trusted “Verified” badge.

SSH signing (as described in the post) makes this especially convenient because most developers already have an SSH key set up for pushing code. After setting gpg.format=ssh and user.signingkey, everything happens automatically with commit.gpgsign=true.

Quick Setup Reminder for SSH Signing

Add these lines to your global Git config:

git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub   # or your key path
git config --global commit.gpgsign true
git config --global tag.gpgsign true

Did you find this post helpful? You can support me.

Kubernetes - Adventures - Argo-CD

12ww1160 — Wed, 25 Mar 2026 15:36:21 +0000

From Push to Pull: How I Fully Embraced GitOps with Argo CD in My Confdroid developer cloud

After several days of experimentation, I have now fully implemented Argo CD — and the difference in day-to-day operations is night and day.

Here’s a clear before-and-after look at how my Kubernetes workflow has changed.

The Old Way (Push-Based Deployments)

Before Argo CD, my setup looked like this:

A single Git repository containing all raw Kubernetes manifests (YAML files) for both applications and core cluster components.
A CI/CD pipeline that used kubectl to connect to the cluster and (re)deploy everything — from the CNI and storage classes to Longhorn and other infrastructure pieces.
This pipeline acted as a safety net: if the cluster ever got into a bad state, a single pipeline run could restore it to a known-good configuration.
New applications could be added or updated simply by pushing changes to the repo. The pipeline would pick them up and apply them to the cluster.
Troubleshooting and manual adjustments were done directly with kubectl or a UI like the Kubernetes Dashboard, or in my case Headlamp. While convenient, this also opened the door to accidental changes — scaling a deployment and forgetting to update the manifests, for example.

Every git push triggered a push-based deployment. It worked well, but it relied heavily on discipline and perfect execution.

The New Way (Pure GitOps with Argo CD)

The old repository and pipeline still exist and continue to handle all low-level cluster reconfiguration (CNI, storage, base infrastructure, Argo CD configuration itself, including Keycloak integration). That safety net remains untouched.
What changed is the introduction of a dedicated second repository dedicated to Argo CD-managed applications.
Here’s how it works now:

Application manifests have been moved into the new Git repository.
Argo CD is installed and configured via the original pipeline.
Once running, Argo CD connects to the new repository and continuously synchronizes the cluster state with the desired state defined in Git. This requires one-off registration of the application via UI or CLI.
Synchronization can be triggered from the beautiful Argo CD web UI or via the CLI — the result is identical. Best though is setting auto-sync, which is what this is all about. This can be on done application level as required / desired.
Any drift is automatically corrected. If someone manually scales a deployment with kubectl or changes a ConfigMap in the dashboard, Argo CD will immediately revert it back to match the Git definition.
No more “I scaled it temporarily and forgot to update the YAML” accidents.
All changes — even small tweaks — must now go through Git. This enforces a true pull-based GitOps model. Stability over convenience!

Why This Feels So Much Better

Argo CD brings several powerful advantages:

It operates in a pure pull model, which is inherently more reliable than the previous push approach.
It can manage itself (though I chose not to enable that yet), multiple clusters, projects, and even different environments or stages — all without needing an external database.
The web UI is excellent. For every application, you can see pods, ReplicaSets, Services, ConfigMaps, and more at a glance.
As a massive bonus, it integrates beautifully with the Trivy Operator running in my cluster, displaying up-to-date vulnerability scan results directly in the Argo CD dashboard for each application.

Final Thoughts

Implementing Argo CD took me roughly four hours from start to finish, some fine-tuning pending — time extremely well spent.

The cluster now feels significantly more robust and predictable. By moving to a strict GitOps workflow, I’ve eliminated an entire class of human errors while gaining much better visibility and control.

This setup brings me noticeably closer to my goal of running cloud-native applications the way they were meant to be operated: declaratively, version-controlled, and automatically reconciled.

GitOps isn’t just a nice-to-have anymore — it has become the foundation of how I want to run Kubernetes going forward.

If you’re still managing Kubernetes with direct kubectl applies or traditional CI/CD push pipelines, I highly recommend giving Argo CD a try. The improvement in stability and peace of mind is immediate and very real.

In the next post of this series, I’ll share the exact steps I took to install and configure Argo CD with Keycloak integration, along with my recommended folder structure and best practices.
Until then — happy deploying!

Did you find this post helpful? You can support me.

Kubernetes - Adventures - Pilot

12ww1160 — Thu, 19 Mar 2026 13:50:44 +0000

My Kubernetes Journey: From a Fragile Single-Node Setup to a Stable GitOps-Powered Homelab Cluster

A few years back, I dipped my toes into Kubernetes by spinning up a simple lab cluster: one control-plane node, one worker, and a handful of basic services. To my surprise, that minimal setup ran reliably with almost zero maintenance for about two and a half years. Then it suddenly broke.

That failure became the catalyst for a complete rebuild. I set out to create a proper development cluster—one control-plane node and three workers—using a vanilla kubeadm installation. Over the next three months, I methodically reproduced every common pitfall I could find, reinstalling repeatedly until the process felt rock-solid and repeatable.

Early on, I shifted toward GitOps practices. I built CI/CD pipelines that handled every cluster change and installation step, relying heavily on kubectl to apply manifests directly. This approach gave me confidence and speed, turning deployments into automated, version-controlled events.

The CNI Rollercoaster

Networking proved to be the biggest source of headaches. I started with Weave Net, which worked nicely at first—but the project is no longer actively maintained, so it eventually became unsustainable.
I tried several other CNIs, and each came with its own quirks. Flannel was straightforward but fell short in certain scenarios. Kube-router performed decently overall, yet I could never get Ingress resources to behave reliably. Worse, one day it began overwriting my firewall rules, bringing the entire cluster down hard.

After multiple experiments, I landed on Calico. With some BGP tweaks to fit my environment, it delivered the stability I needed. Today, Calico remains my go-to CNI in the lab.

Handling Ingress and External Traffic

Ingress troubles pushed me toward an alternative: HAProxy running as an external load balancer on a separate VM. HAProxy handles TLS termination and forwards traffic to NodePort services. Because all my VMs (including the HAProxy host) are managed with Puppet, I can easily maintain proxy rules, renew certificates via Certbot, and keep everything consistent.
This hybrid setup let me migrate many workloads off older standalone VMs and onto Kubernetes, which saved noticeable hosting costs.

What Fits Kubernetes—and What Doesn't (Yet)

Not every service thrives in containers with my current constraints, especially on Hetzner Cloud where storage options are limited and latency-sensitive.
Stateful databases like PostgreSQL and MariaDB, along with Prometheus (which demands low-latency writes), struggled enough that I moved them back to dedicated VMs. The same went for Jenkins: the main controller performs better outside Kubernetes, though its agents run happily as pods.

Storage Solutions That Actually Work

For persistent storage, I first looked at Rook/Ceph—but it proved far too resource-heavy for my low-budget setup at Hetzner. Longhorn turned out to be the sweet spot: lightweight, feature-rich, and equipped with solid backup capabilities.

For ultra-low-cost volumes I sometimes fall back to SSHFS mounts. While SSHFS has clear performance and reliability limits, pairing it with Longhorn covers most use cases reasonably well.

The Cluster Today

Right now the cluster runs 18 internal services. Infrastructure components include Keycloak for identity, OpenBao for secrets, Trivy for vulnerability scanning, Longhorn itself, and PgBouncer for connection pooling. Application workloads cover SonarQube, Gitea, OpenProject, Wiki.js, and several others.

The combination delivers excellent stability. Deployments feel effortless thanks to CI/CD pipelines, while Puppet keeps the surrounding VM layer tidy. Puppet doesn't play nicely with container orchestration, though, so Ansible is steadily taking on more responsibility in the environment.

Tools like Argo CD (which I deployed just yesterday and already love), Kustomize, and plain YAML manifests round out the picture. I still lean toward raw manifests for simplicity and direct control, but GitOps patterns are clearly the future.

Looking Ahead: GitOps, Argo CD, and Beyond

With agentic development gaining momentum, I'm now looking into building applications designed to run as future SaaS offerings inside production-grade clusters. Kubernetes has proven to be the right foundation—even if there's still plenty left to master.

The lessons from this homelab will fuel an ongoing series. The next post dives straight into migrating to Argo CD and embracing proper GitOps workflows, which are becoming essential in modern software delivery.

If you're running Kubernetes at home, experimenting in the cloud, or just curious about real-world trade-offs, stay tuned. There's a lot more to share.
What challenges have you hit with Kubernetes in your own setups? Drop a comment—I'd love to hear your stories.

Did you find this post helpful? You can support me.

ConfDroid Puppet Modules - NRPE

12ww1160 — Sun, 15 Mar 2026 16:45:07 +0000

Secure Remote Monitoring Made Simple: confdroid_nrpe Completes Your Puppet-Powered Nagios Setup

If you’re already using confdroid_nagios for automated, exported-resource monitoring, the missing piece was always the client side. That piece is now here.

confdroid_nrpe is the clean, client-only Puppet module that installs and configures NRPE (Nagios Remote Plugin Executor) on every host you want to monitor. It works hand-in-hand with the Nagios server so checks run securely and automatically across your entire infrastructure.

source code: https://sourcecode.confdroid.com/confdroid/confdroid_nrpe

Detailed overview: https://deepwiki.com/grizzlycoda/puppet_collection/4.7-confdroid_nrpe

Why NRPE Matters

A central Nagios server can’t peek inside every machine without help. NRPE lets the server ask remote Linux hosts to run local check plugins (disk space, CPU load, processes, custom scripts, etc.) and return the result instantly. This keeps monitoring lightweight, secure, and fast — exactly what traditional VM and bare-metal environments need.

What confdroid_nrpe Delivers

The module is built for Rocky Linux 9 and similar RedHat-based EL systems (Puppet 8 ready) and follows the same clean philosophy as the rest of the confdroid collection:

Installs the NRPE daemon and creates the dedicated nrpe system user
Sets up proper directory structure with correct permissions and SELinux contexts
Manages nrpe.conf (including allowed_hosts from your Nagios server)
Handles nrpe.cfg for dynamic check commands
Grants sudo rights to the Nagios user when checks need elevated privileges
Dynamically defines custom NRPE commands (no manual config files)
Optionally opens the firewall port (TCP 5666) and applies SELinux exceptions
Ensures the NRPE service is running and enabled
Optionally enables SSL / TLS encryption

Seamless Integration with confdroid_nagios

Other confdroid modules (Apache, PostgreSQL, etc.) already export their Nagios checks via PuppetDB. When you apply confdroid_nrpe on a client:

The client registers itself (or gets collected by the server)
Check commands are written automatically into nrpe.cfg
The Nagios server starts actively querying the host over NRPE

No manual host definitions. No SSH keys. No guesswork.

How Nagios Connects to Clients and Runs Checks

Here’s exactly what happens behind the scenes:

The Nagios server simply connects to port 5666 on each client, tells NRPE which command to run, and receives the result in seconds.

## Quick Start

Add the module to your Puppetfile:

  mod 'confdroid_nrpe',
  git: 'https://sourcecode.confdroid.com/confdroid/confdroid_nrpe.git'

puppet

Then declare it:

via site.pp or nodes.pp

node 'example.example.net' {
  include confdroid_nrpe
}

through Foreman:

In order to apply parameters through Foreman, confdroid_nrpe::params- must be added to the host or host group in question, unless the defaults are fully acceptable across the estate.

That’s it. Your clients are now ready for fully automated monitoring.

Final Thoughts

With confdroid_nagios on the server side and confdroid_nrpe on every client, you get a complete, zero-touch Nagios setup driven entirely by Puppet and PuppetDB. No more manual config files, no more forgotten hosts, and rock-solid security on every endpoint.
If you’re running traditional infrastructure (VMs, bare metal, or a hybrid mix), this combination is hard to beat.
Ready to add remote checks to your stack? Grab the module today and let Puppet do the heavy lifting.
Questions or feedback? The source is open — comments welcome!

Did you find this post helpful? You can support me.

ConfDroid Puppet Modules - Nagios

12ww1160 — Sat, 14 Mar 2026 19:19:22 +0000

Automating Nagios Monitoring with Puppet: Introducing confdroid_nagios

Keeping an eye on servers, services, and applications remains essential in any infrastructure. While newer tools gain attention, classic threshold-based monitoring with Nagios still delivers reliable, straightforward alerting for many environments.

The newly published confdroid_nagios Puppet module brings full automation to Nagios server setups — especially in traditional VM, bare-metal, or hybrid infrastructures.

Source: https://sourcecode.confdroid.com/confdroid/confdroid_nagios

What confdroid_nagios Delivers

This module handles the complete installation and configuration of a Nagios server (or client nodes) on Rocky Linux 9 (with Puppet 8 compatibility in progress).

Key highlights:

Role-based deployment — If a node's FQDN matches the configured ng_nagios_server, it installs the full Nagios server stack. Otherwise, it deploys only client packages and NRPE (when enabled).
Dynamic configuration via PuppetDB — Hosts, services, contacts, contact groups, host groups, service groups, commands, and templates are all managed through exported resources. Other confdroid modules (like confdroid_apache) automatically export their monitored services — no manual host or check definitions needed.
Secure and clean setup — Sets proper permissions, SELinux contexts, firewall rules, and creates a safe /etc/nagios/conf.d directory for any manual overrides without Puppet overwriting them.
Integration features — Optional NRPE client setup (ng_include_nrpe) and Fail2Ban jail for Nagios (ng_enable_fail2ban).
Admin UI access — Configures HTPasswd-based authentication with bcrypt-hashed passwords.

Once deployed with a simple include confdroid_nagios (and Hiera/ENC overrides for the server FQDN and credentials), Nagios stays current as your infrastructure changes — all driven by Puppet runs.

Threshold-Based vs. Metrics-Based Monitoring: A Quick Comparison

Nagios (and similar tools like Icinga) and Prometheus + Grafana represent two different philosophies. Both have valid places in modern setups.

Threshold-Based Monitoring (Nagios, Icinga)

Approach — Actively runs checks (plugins, NRPE, SNMP) against hosts/services at set intervals. Returns OK/WARNING/CRITICAL/UNKNOWN states based on predefined thresholds.
Strengths
- Excellent for uptime and availability alerting ("Is the web server responding? Is disk full?").
- Strong dependency handling, scheduled downtimes, and notification routing.
- Simple to understand and configure for traditional infrastructure.
- Very effective for mixed VM/metal environments where you want clear "something is broken" alerts.
Limitations
- Less suited for deep performance trending or high-cardinality data.
- No built-in long-term historical metrics storage or advanced querying.
- not very suitable for dynamic pods in Kubernetes

Metrics-Based Monitoring (Prometheus + Grafana)

Approach — Pulls time-series metrics from instrumented targets (exporters, app endpoints). Stores everything in a powerful time-series database. Uses PromQL for querying and Alertmanager for notifications.
Strengths
- Ideal for cloud-native, Kubernetes, and microservices — automatic service discovery, rich labels, and rate-based alerting (errors/sec, latency p99).
- Deep historical analysis, anomaly detection, and beautiful dashboards via Grafana.
- Handles high-volume, high-cardinality data well (with proper federation/scaling).
Limitations
- Steeper learning curve (PromQL, recording rules, alerting rules).
- Less "out-of-the-box" for simple host/service availability without extra exporters.
- Operational overhead increases at very large scale without Thanos/Mimir.

When to Choose Which (or Both)

Use Nagios / confdroid_nagios-powered setups for VM-heavy, bare-metal, or hybrid environments where clear, threshold-driven alerts and easy integration with existing Puppet workflows matter most.
Choose Prometheus + Grafana for containerized, Kubernetes-native, or microservices-heavy stacks that demand detailed performance insights and trend analysis.
Many teams run both — Nagios for critical "is it up?" paging alerts, Prometheus for capacity planning, SLO tracking, and debugging.

In short: Nagios excels at "something failed — notify the right person now." Prometheus shines at "how is the system behaving over time — and why?"

Workflow

Get Started Today

Deploying automated, zero-touch Nagios has never been easier in Puppet-managed environments.

Add confdroid_nagios via your Puppetfile or r10k:

mod 'confdroid_nagios',
  git: 'https://sourcecode.confdroid.com/confdroid/confdroid_nagios.git'

Then configure your Nagios server node and let exported resources do the rest.
If you're tired of manual Nagios config files and love declarative infrastructure, give it a try. It pairs beautifully with the rest of the confdroid collection for a clean, automated monitoring foundation.
Questions or feedback? The source is open — comments welcome!

Did you find this post helpful? You can support me.

Databases - Postgresql - PGbouncer

12ww1160 — Sat, 14 Mar 2026 16:30:45 +0000

Why PostgreSQL Needs a Connection Pooler – And How confdroid_pgbouncer Makes It Simple in Kubernetes

In today’s cloud-native applications, PostgreSQL stands out as a reliable, powerful database. Yet one challenge almost every growing team runs into is managing database connections at scale.
That’s exactly where PgBouncer shines — and why the confdroid_pgbouncer container makes it effortless to deploy in Kubernetes.

The PostgreSQL Connection Problem

PostgreSQL treats every client connection as a separate backend process. Each one needs memory, CPU, and authentication overhead. The database enforces a hard limit through the max_connections setting (often 100 by default, though you can raise it).

Raising that number too high quickly eats into server resources and hurts performance. When you raise the limit, you need adequate RAM memory. Consider the following calculation:

Base memory per connection: Each connection uses ~10–15 MB of RAM for session overhead, even when idle. This includes shared memory structures, connection state, and internal buffers.
work_mem impact: The work_mem setting is allocated per operation (e.g., sort, hash), not per connection. If a query performs multiple operations, memory usage scales accordingly. For example:
With work_mem = 16MB, a single complex query might use up to 16MB × (number of sort/hash operations). In high-concurrency scenarios, total memory usage per 100 connections can be approximated as:

(100 connections × 15MB base) + (100 × work_mem × avg operations per query)

For moderate workloads (e.g., 1–2 operations per query), this may add 1.6–3.2 GB beyond the base overhead.

What Happens When Connections Run Out or Stay Idle Too Long

When connections run out: New clients get the dreaded error “FATAL: sorry, too many clients already.” Applications fail, queues build up, and users see downtime — even when the database still has plenty of CPU and memory available.
When connections stay idle: They continue to consume memory (typically 5–10 MB each) and hold open slots. During traffic spikes, those idle connections suddenly compete with active ones, turning a manageable situation into a crisis.

The result? Unpredictable performance and constant firefighting.

Common Scaling Issues

These problems show up in three typical scenarios:

a) Many clients for one application
A popular web app or API with thousands of concurrent users (or many pods) can easily exhaust the database. Even built-in application pools multiply quickly across instances.
b) Many applications with limited or many clients
Microservices architectures are a classic example. When 15–30 different services each maintain their own connection pool to the same PostgreSQL instance, the total connection count explodes — often with lots of idle waste.
c) Read- and write demand
Writes must hit the primary database, while reads can go to replicas. Without smart routing and pooling, teams end up with complicated application logic, separate connection strings, and uneven load across the cluster.

These are true already for smaller environments. When it comes to big solutions scaling, the total amount of layers for performance tuning are growing rapidly.

PgBouncer: The Lightweight Solution

PgBouncer sits between your applications and PostgreSQL as a fast, efficient proxy. Instead of letting every client open its own direct connection, it reuses a small, controlled pool of real database connections.

Key wins:

Far fewer actual connections to PostgreSQL
Instant connection reuse (no repeated authentication)
Built-in queuing for spikes
Support for transaction pooling (perfect for most web workloads), session pooling (see my recent post about gitea and pgbouncer) or statement pooling.

The database stays happy, performance improves, and scaling becomes predictable. Fine-grained tuning becomes snappy.

confdroid_pgbouncer: Ready-to-Run in Kubernetes

To make PgBouncer truly Kubernetes-native, a clean container solution was built: confdroid_pgbouncer.

Highlights:

Small Debian-based image (around 47 MB)
Runs PgBouncer 1.24.1 as a non-root user (the official binaries)
Designed as a standalone service
Supports multiple instances running in parallel — each fully managing connections independently but using the exact same configuration manifest
Standard port 6432 with built-in health checks
Easy horizontal scaling and high availability
allows protecting connections via TLS at different levels between client <=> bouncer and serer <=> bouncer

Get it here:

Source code:
- https://sourcecode.confdroid.com/confdroid/confdroid_pgbouncer
Container image:
- https://sourcecode.confdroid.com/confdroid/-/packages/container/confdroid_pgbouncer/latest

Pull it with:

docker pull sourcecode.confdroid.com/confdroid/confdroid_pgbouncer:latest

Why This Approach Fits Modern Stacks

Because every instance uses the same manifest-driven configuration, you get perfect consistency across replicas — ideal for GitOps workflows. It integrates smoothly with load balancers, monitoring, and the rest of the confdroid collection.

Often, the bouncer is running on the same node as the postgres instance. But for one it adds load to the server, for two that does not allow loadbalancing between several server instances.

Using PGbouncer as standalone service in Kubernetes or similar cluster solutions allows centralized loadbalancing without even ever having to touch Postgres for reconfiguring.

Final Thoughts

Adding a proper connection pooler like PgBouncer is one of the highest-return improvements you can make for any PostgreSQL deployment. It protects your database, boosts performance, and removes a major scaling headache.

If you’re running PostgreSQL standalone or in Kubernetes (or planning to), try confdroid_pgbouncer today. It takes minutes to set up and delivers immediate relief.

Have you hit connection limits before? Drop a comment or leave it at the Confdroid Feedback Portal — I’d love to hear what worked for you!

Did you find this post helpful? You can support me.

Forem: 12ww1160

ConfDroid Puppet Modules - Selinux

Introducing confdroid_selinux: Declarative SELinux Management for Your Rocky 9 Servers

How SELinux Stops Real-World Attacks

The Problem with Manual SELinux Management

What confdroid_selinux Does

SELinux Management Flow with the Module

Easy Deployment

Final Thoughts

Related posts

ConfDroid Puppet Modules - Automatic

Introducing confdroid_automatic: Hands-Off OS Updates for Your Rocky 9 Servers

Why Automated Updates Matter

Key Features

Automatic Update Flow

How to Use It

Important Notes

Final Thoughts

Related posts

Kubernetes - Argo-CD - Custom Installation

Installing Argo CD the GitOps Way: A More Stable and Maintainable Approach

The Official Quick-Start Method

Why a GitOps-First Installation Is Better

Installing the Argo CD CLI (Optional but Handy)

Adapting Argo CD for My Environment

Exposing Argo CD via NodePort

Setting Up OIDC Authentication with Keycloak

Visualizing the GitOps Flow with Argo CD

Keycloak OIDC Authentication Flow

Next Steps

Related posts

Puppet with Foreman - PuppetDB Reporting Errors

Fixing Missing OS, Environment, and Fact Data in Foreman When Using PuppetDB

The Root Cause

The Correct Configuration

How the Pieces Fit Together

Quick Tip

Related posts

ConfDroid Puppet Modules - Fail2ban

Introducing confdroid_fail2ban: Automated Brute-Force Protection for Your Puppet-Managed Servers

Taking Fail2Ban Further with Puppet

Key Features

Custom Jails for Modern Services

Why This Matters

Getting Started

Final Thoughts

Related posts

Wordpress - Caching riddles

When Caching Breaks Your WordPress REST API: A Debugging Story and Why Caching Still Matters

Why Caching Is Essential for WordPress Sites

How Object Caching Works with Memcached (Visualized)

Lessons Learned

Git - Verified Commits with SSH keys

Why Verified Commits Matter in Git — And How I Fixed Mine with SSH Signing

My First Step: Switching to GPG Signing

The Keycloak Integration That Broke Everything

The Simpler Solution: SSH Commit Signing

Why SSH Signing Feels Easier Than GPG

The Bigger Picture: Make Verified Commits Non-Negotiable

Why Verified Commits Matter – Visualized

How to Read the Diagram

Quick Setup Reminder for SSH Signing

Kubernetes - Adventures - Argo-CD

From Push to Pull: How I Fully Embraced GitOps with Argo CD in My Confdroid developer cloud

The Old Way (Push-Based Deployments)

The New Way (Pure GitOps with Argo CD)

Why This Feels So Much Better

Final Thoughts

Related posts

Kubernetes - Adventures - Pilot

My Kubernetes Journey: From a Fragile Single-Node Setup to a Stable GitOps-Powered Homelab Cluster

The CNI Rollercoaster

Handling Ingress and External Traffic

What Fits Kubernetes—and What Doesn't (Yet)

Storage Solutions That Actually Work

The Cluster Today

Looking Ahead: GitOps, Argo CD, and Beyond

Related posts

ConfDroid Puppet Modules - NRPE

Secure Remote Monitoring Made Simple: confdroid_nrpe Completes Your Puppet-Powered Nagios Setup