This example is based on a Hetzner machine with a single public facing IP, but should apply to any such scenario.

The public IP should be shared with the Hypervisor that is installed on a Bare Metal host, that has only one Ethernet IF. In the case of Proxmox, firewall rules need to be configured, to only allow certain incoming ports.

We also need NAT and Masquerading, to forward ports to a virtualized firewall running on the Proxmox server.

This concerns Proxmox 9.x+ since nftables support is still in Beta and was only added recently. The same concepts should be applicable to iptables, but the commands and files referenced will be different.

I wanted to use my QNAP NAS as an NFSv4 Kubernetes nfs-csi target.

The Cluster is running on RHEL 9. Mounting from either the cluster hosts, or other RHEL 9 hosts didn't work.

The error was:

mount.nfs: mounting nas.example.com:/kubernetescsinfsslow failed, reason given by server: No such file or directory

Integration of the community.general.proxmox inventory dynamic source into AAP2.5+

• Add a PVE/LDAP/etc. User.
• Add Permission for your tree (For the whole cluster add to "/").
• For the inventory-sync "PVEAuditor" is sufficient (read-only).
• If you want to use this user for automation tasks (Create, edit, etc VMs) you need higher permissions. You can seperate those from your API Token by using "Privilege Separation" on your API token

How to setup Proxmox to use Keycloak as authentication realm.

root@proxmox:/etc/pve# cat domains.cfg
pam: pam
        comment Linux PAM standard authentication

Authenticating to the AAP2 Web-Gui using an OIDC-Based SSO like Keycloak is a requirement for many organizations.

This is why I wanted to try this out. Sadly the Red Hat Documentation is very thin on details on how to configure Keycloak itself to ensure a seamless integration.

Through some trial and error, I have found a solution that works. If there are any issues with this, please let me know!

I assume you already have a functioning realm.

This applies to Version (Dockerized) 24.3.2

Cloudbeaver does not document very well how to configure it to authenticate against an Active Diretory.

To do that, you have to edit the workspace/.data/.cloudbeaver.runtime.conf

The basic config looks like this:

Using a QNAP NAS connected to an EATON 3S UPS via USB, I wanted to do the following

In case of power loss:

• Go to UPS Power
• Start Timer
• Abort Timer if Power restored
• After 10 Minutes, shut down Proxmox (using ISCSI Storage provided by QNAP)
• After 15 Minutes, shut down QNAP

When upgrading (k3s) Kubernetes Nodes using Ansible to drain the nodes, the following error appears:

error when evicting pods/"instance-manager-xxxx" -n "longhorn" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.

I am using the CNPG-Operator to provision a few Postgres-Clusters in Kubernetes for my applications. These use Longhorn as a single-replica storage backend. More than one replicas would be pointless, since postgres itself manages data replication.

Since longhorn will not allow single-replica PVs to be evicted when a node is drained by default, we need to change that behaviour for node upgrades.

As per prometheus-operator/kube-prometheus#1392 Thank you to KaiGrassnick!

The underlying issue is a configuration setting in the kube-prometheus-stack helm chart, that does by default expect you to label your ServiceMonitor in a certain way. For me with no further configuration, the expected label was the helm-deployments "release" label. Since I deployed my blackbox_exporter with a separate helm-cart in ArgoCD, that label wasn't applied and the ServiceMonitor wasn't picked up.

I am assuming you already installed kube-prometheus-stack and it's working. I am also assuming you're using the blackbox_exporter chart from here: https://github.com/prometheus-community/helm-charts/tree/main/charts/prometheus-blackbox-exporter