To be able to monitor hardware health, status and information on HP servers running RHEL, it is required to install the HP’s Service Pack for Proliant packages. It seems the Management Component Pack is the same(agent software but for community distros, for enterprise, use SPP. There is more info about those HP tools on the HP site Basically you just need to add a yum/dnf repository, install the packages and start a service (actually the service is started as part of the RPM post-install, which is not a good practice…)

When deploying OpenShift IPI on baremetal, there is only so much you can tweak at installation time in terms of networking. Of course you can do changes after the installation, such as applying bonding configurations or vlan settings via machine configs… but what if you need those changes at installation time? In my case, I have an OpenShift environment composed by physical servers where each of them have 4 NICs. 1 unplugged NIC, 1 NIC connected to the provisioning network and 2 NICs connected to the same switch and to the same baremetal subnet.

In this blog post I’m trying to perform the integration of an external registry with an OpenShift environment. The external registry can be any container registry, but in this case I’ve configured harbor to use certificates (self generated), the ‘library’ repository in the harbor registry to be private (aka. require user/pass) and created an ‘edu’ user account with permissions on that ‘library’ repository. Harbor installation 🔗Pretty straightforward if following the docs , but for RHEL7:

Introduction 🔗I’ve been using Nextcloud for a few years as my personal ‘file storage cloud’. There are official container images and docker-compose files to be able to run it easily. For quite a while, I’ve been using the nginx+redis+mariadb+cron docker-compose file as it has all the components to be able to run an ‘enterprise ready’ Nextcloud, even if I’m only using it for personal use :) In this blog post I’m going to try to explain how do I moved from that docker-compose setup to a podman rootless and systemd one.

Running a rootless Nextcloud pod 🔗Instead of running Nextcloud as independant containers, I’ve decided to leverage one of the multiple podman features which is being able to run multiple containers as a pod (like a kubernetes pod!) The main benefit to me of doing so is they they use a single network namespace, meaning all the containers running in the same pod can reach each other using localhost and you only need to expose the web interface.

Nextcloud in container user IDs 🔗The nextcloud process running in the container runs as the www-data user which in fact is the user id 82: $ podman exec -it nextcloud-app /bin/sh /var/www/html # ps auxww | grep php-fpm 1 root 0:10 php-fpm: master process (/usr/local/etc/php-fpm.conf) 74 www-data 0:16 php-fpm: pool www 75 www-data 0:15 php-fpm: pool www 76 www-data 0:07 php-fpm: pool www 84 root 0:00 grep php-fpm /var/www/html # grep www-data /etc/passwd www-data:x:82:82:Linux User,,,:/home/www-data:/sbin/nologin NFS and user IDs 🔗NFS exports can be configured to have a forced uid/gid using the anonuid, anongid and all_squash parameters.

Introducing bunkerized-nginx 🔗I heard about bunkerized-nginx a while ago and I thought it would be nice to use it as a reverse proxy so I can expose my internal services to the internet ‘safely’. A non-exhaustive list of features (copy & paste from the README): HTTPS support with transparent Let’s Encrypt automation State-of-the-art web security : HTTP security headers, prevent leaks, TLS hardening, … Integrated ModSecurity WAF with the OWASP Core Rule Set Automatic ban of strange behaviors with fail2ban Antibot challenge through cookie, javascript, captcha or recaptcha v3 Block TOR, proxies, bad user-agents, countries, … Block known bad IP with DNSBL and CrowdSec Prevent bruteforce attacks with rate limiting Detect bad files with ClamAV Easy to configure with environment variables or web UI Automatic configuration with container labels A must have for me was having support for Let’s Encrypt and having an easy way to configure it.

podman play kube 🔗One of the cool things about podman is that is not just a docker replacement, it can do so much more! The feature I’m talking about is being able to run Kubernetes YAML pod definitions! How cool is that? You can read more about this feature in the podman-play-kube man, but essentially, you just need a proper pod yaml definition and podman play kube /path/to/my/pod.yaml will run it for you.

Introduction 🔗Inspektor Gadget is a collection of tools (or gadgets) to debug and inspect Kubernetes applications. Inspektor Gadget is deployed to each node as a privileged DaemonSet. It uses in-kernel BPF helper programs to monitor events mainly related to syscalls from userspace programs in a pod. The BPF programs are run by the kernel and gather the log data. Inspektor Gadget’s userspace utilities fetch the log data from ring buffers and display it.

Preparation 🔗Ensure your workers have the virtualization flag enabled: for node in $(oc get nodes -o name | grep kni1-worker); do oc debug ${node} -- grep -c -E 'vmx|svm' /host/proc/cpuinfo done That snippet should return the number of cpu cores with virtualization enabled (it should be all of them). Subscription 🔗cat <<EOF | oc apply -f - apiVersion: v1 kind: Namespace metadata: name: openshift-cnv --- apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: kubevirt-hyperconverged-group namespace: openshift-cnv spec: targetNamespaces: - openshift-cnv --- apiVersion: operators.