DEV Community: Ana Villar

Building an OpenShift 4.18 Cluster from Scratch: Part 1 – The Network Foundation & Utilities Server

Ana Villar — Tue, 30 Jun 2026 19:21:50 +0000

Note: This is Part 1 of a multi-part series.

[Part 2: Generating Ignition Configs & VM Prep] (Coming Soon)

[Part 3: The Deployment Lifecycle & Troubleshooting] (Coming Soon)

[Part 4: Post-Install Hardening & User Management] (Coming Soon)

In this series, I walk through a full OpenShift Container Platform 4.18 deployment from scratch. While most tutorials target cloud providers or pre-provisioned infrastructure, this guide replicates a true platform-agnostic (bare metal) installation—executed within a lab of Virtual Machines hosted on RHEL 10.

This approach allows us to master the critical underlying infrastructure—DNS, DHCP, PXE booting, and load balancing—without the cost of physical hardware. By the end of Part 1, you will have a fully functional Utilities Server that acts as the command center for the entire cluster, handling:

DNS: Internal resolution for all cluster nodes.
DHCP: IP allocation and iPXE boot redirection via Kea.
TFTP & HTTP: Serving bootloader images, RHCOS ISOs, and Ignition configs.
HAProxy: Load balancing for the Kubernetes API and Ingress traffic.

We won't run openshift-install just yet; first, we must build the foundation upon which the cluster relies.

📚 References & Background

This lab strictly follows the Platform-Agnostic installation methodology defined by Red Hat. The setup was heavily inspired by the DO322: Red Hat OpenShift Installation Lab training course, ensuring we cover the same critical edge cases and network requirements found in production environments.

Why use VMs for a "Bare Metal" guide? While running on virtual machines provides speed and portability for this lab, the network stack (DNS/DHCP/PXE) and the Ignition configuration flow are identical to what you would encounter on physical hardware. Following the DO322 methodology ensures this tutorial remains relevant for real-world bare-metal deployments.

Let's get the foundation laid.

🛠 Lab Environment Overview

Before diving in, here is the topology I'm working with. All these VMs are hosted on a RHEL 10 hypervisor.

Role	VM Name	IP Address	Specs
Utilities Server	utilities	192.168.110.20	4 vCPU, 8GB RAM, 250GB Disk
Bootstrap Node	bootstos	192.168.110.100	4 vCPU, 16GB RAM, 100GB NVMe
Control Plane	masteros01-03	.101 to .103	4 vCPU, 24GB RAM, 100GB NVMe
Compute Nodes	workeros01-03	.111 to .113	2 vCPU, 8GB RAM, 100GB SSD

1. Setting Up the Utilities Server

We start with a fresh RHEL 10 installation. Once installed, we register the system and ensure all packages are up to date.

$ sudo subscription-manager register --username <YOUR_USER> --password <PASSWORD>
$ sudo dnf update redhat-release
$ sudo dnf upgrade -y
$ sudo reboot

After reboot, we verify connectivity and prepare for the services.

Network Configuration

The utilities server has two interfaces. I configured them via nmtui to assign static IPs:

enp1s0: 192.168.1.20 (Management/Internet Gateway)
enp7s0: 192.168.110.20 (Internal Cluster Network)

and then, add two extra IP addresses to interface enp7s0, 192.168.110.21 and 192.168.110.22, to be used by OpenShift services.

$ nmcli
enp1s0: connected to enp1s0
        "Red Hat Virtio 1.0"
        ethernet (virtio_net), 52:54:00:C5:C1:9E, hw, mtu 1500
        ip4 default
        inet4 192.168.1.20/24
        route4 default via 192.168.1.1 metric 100
        route4 192.168.1.0/24 metric 100
        inet6 fe80::5054:ff:fec5:c19e/64
        route6 fe80::/64 metric 1024

enp7s0: connected to enp7s0
        "Red Hat Virtio 1.0"
        ethernet (virtio_net), 52:54:00:E6:D1:A4, hw, mtu 1500
        inet4 192.168.110.22/24
        inet4 192.168.110.21/24
        inet4 192.168.110.20/24
        route4 192.168.110.0/24 metric 101
        route4 192.168.110.0/24 metric 101
        route4 192.168.110.0/24 metric 101
        inet6 fe80::5054:ff:fee6:d1a4/64
        route6 fe80::/64 metric 1024
...

2. Installing & Configuring DNS (BIND)

OpenShift relies heavily on proper DNS. We need records for the API VIPs, ingress VIP, and every node.

Installation

$ sudo dnf install bind bind-utils -y

Configuration

I modified the default config (/etc/named.conf) to listen on both interfaces and allow recursion only for our internal subnets. Crucially, we define our zones here.

# /etc/named.conf snippet
options {
    listen-on port 53 { 127.0.0.1; 192.168.1.20; 192.168.110.20; };
    allow-query { localhost; 192.168.1.0/24; 192.168.110.0/24; };
    allow-recursion { localhost; 192.168.1.0/24; 192.168.110.0/24; };
    forwarders { 8.8.8.8; 8.8.4.4; }; # Or your ISP DNS
    recursion yes;
};

zone "internal.local" {
    type master;
    file "internal.local.zone";
    allow-query { any; };
};

zone "110.168.192.in-addr.arpa" {
    type master;
    file "110.168.192.in-addr.arpa.zone";
    allow-query { any; };
};

Zone Files

We create the forward and reverse lookup zones. Notice the VIPs for the API (192.168.110.21) and Ingress (192.168.110.22). These point to our HAProxy server (which runs on the utilities node).

/var/named/internal.local.zone:

$TTL 8h
@ IN SOA ns1.internal.local. hostmaster.internal.local. (
    2026042601 ; serial
    1d         ; refresh
    3h         ; retry
    3d         ; expire
    3h )       ; minimum

IN NS ns1.internal.local.

ntp               IN A    192.168.110.20
dns               IN A    192.168.110.20

; Static infrastructure
;hostname IN A 192.168.110.x
utilities.internal.local.  IN A    192.168.110.20

; OpenShift VIPs
api.internal.local.       IN A    192.168.110.21
api-int.internal.local.   IN A    192.168.110.21
*.apps.internal.local.    IN A    192.168.110.22

; Bootstrap Node
bootstos.internal.local.     IN A 192.168.110.100

; Master Nodes
masteros01.internal.local. IN A 192.168.110.101
masteros02.internal.local. IN A 192.168.110.102
masteros03.internal.local. IN A 192.168.110.103

; Worker Nodes
workeros01.internal.local. IN A 192.168.110.111
workeros02.internal.local. IN A 192.168.110.112
workeros03.internal.local. IN A 192.168.110.113

/var/named/110.168.192.in-addr.arpa.zone:

$TTL 8h
@ IN SOA ns1.internal.local. hostmaster.internal.local. (
          2026041901 ; serial number
          1d         ; refresh period
          3h         ; retry period
          3d         ; expire time
          3h )       ; minimum TTL

 IN NS   ns1.internal.local.

20                IN PTR  ns1.internal.local.
20                IN PTR  utilities.internal.local.

21    IN PTR api.internal.local.
21    IN PTR api-int.internal.local.

100  IN PTR bootstos.internal.local.
101  IN PTR masteros01.internal.local.
102  IN PTR masteros02.internal.local.
103  IN PTR masteros03.internal.local.

111  IN PTR workeros01.internal.local.
112  IN PTR workeros02.internal.local.
113  IN PTR workeros03.internal.local.

Check configuration and start the service

Change ownership and permissions, and check the configuration:

$ sudo named-checkconf
$ sudo chown root:named /var/named/internal.local.zone
$ sudo chown root:named /var/named/110.168.192.in-addr.arpa.zone
$ sudo chmod 640 /var/named/internal.local.zone
$ sudo chmod 640 /var/named/110.168.192.in-addr.arpa.zone
$ sudo named-checkzone internal.local /var/named/internal.local.zone
zone internal.local/IN: loaded serial 2026041901
OK
$ sudo named-checkzone 110.168.192.in-addr.arpa /var/named/110.168.192.in-addr.arpa.zone
zone 110.168.192.in-addr.arpa/IN: loaded serial 2026041901
OK
$

Enable and start the service

$ sudo systemctl enable --now named

and allow the service through the firewall.

$ sudo firewall-cmd --permanent --add-service=dns
$ sudo firewall-cmd --reload

3. Time Synchronization (Chrony)

Kubernetes clusters are extremely sensitive to time skew. If the clocks drift, certificates and authentication will fail immediately.

We install chrony (it's already present in RHEL, but we configure it):

# /etc/chrony.conf snippet
pool 2.rhel.pool.ntp.org iburst
allow 192.168.1.0/24
allow 192.168.110.0/24
local stratum 10

This allows the utility server to act as a local NTP source for all nodes while syncing itself with external sources.

Enable and start the service

$ sudo systemctl enable --now chronyd
Created symlink '/etc/systemd/system/multi-user.target.wants/chronyd.service' → '/usr/lib/systemd/system/chronyd.service'.
$

and allow the service through the firewall.

$ sudo firewall-cmd --add-service=ntp --permanent
$ sudo firewall-cmd --reload

4. DHCP with Kea

Instead of the legacy ISC DHCP server, I used Kea, which is the recommended choice for RHEL 10.

Installation & Config

sudo dnf install kea -y

The configuration /etc/kea/kea-dhcp4.conf is where the magic happens for PXE booting. We define client classes to distinguish between iPXE clients and standard UEFI/BIOS PXE clients.

{
  "Dhcp4": {
    "interfaces-config": {
      "interfaces": [ "enp7s0/192.168.110.20" ]
    },

    "client-classes": [
        { 
            "name": "iPXE Clients", 
            "test": "option[175].exists", 
            "option-data": [
               { "name": "tftp-server-name", "data": "192.168.110.20" },
               { "name": "boot-file-name", "data": "http://192.168.110.20/boot.ipxe" }
            ]
        },
        {
            "name": "UEFI PXE Clients",
            "test": "option[93].hex == 0x0007 and not option[175].exists",
            "next-server": "192.168.110.20",
            "boot-file-name": "ipxe-snponly-x86_64.efi"
        },
        {
            "name": "BIOS PXE Clients",
            "test": "option[93].hex == 0x0000 and not option[175].exists",
            "next-server": "192.168.110.20",
            "boot-file-name": "undionly.kpxe"
        }
    ],

    "subnet4": [
      {
        "id": 1,
        "subnet": "192.168.110.0/24",
        "pools": [
          {
            "pool": "192.168.110.200 - 192.168.110.250"
          }
        ],

        "reservations": [
          { "hw-address": "AA:BB:CC:DD:EE:01", "ip-address": "192.168.110.100", "hostname": "bootstos.oc41827.internal.local" },

          { "hw-address": "AA:BB:CC:DD:EE:02", "ip-address": "192.168.110.101", "hostname": "masteros01.oc41827.internal.local" },
          { "hw-address": "AA:BB:CC:DD:EE:03", "ip-address": "192.168.110.102", "hostname": "masteros02.oc41827.internal.local" },
          { "hw-address": "AA:BB:CC:DD:EE:04", "ip-address": "192.168.110.103", "hostname": "masteros03.oc41827.internal.local" },

          { "hw-address": "AA:BB:CC:DD:EE:05", "ip-address": "192.168.110.111", "hostname": "workeros01.oc41827.internal.local" },
          { "hw-address": "AA:BB:CC:DD:EE:06", "ip-address": "192.168.110.112", "hostname": "workeros02.oc41827.internal.local" },
          { "hw-address": "AA:BB:CC:DD:EE:07", "ip-address": "192.168.110.113", "hostname": "workeros03.oc41827.internal.local" }
        ],

        "option-data": [
          { "name": "routers", "code": 3, "data": "192.168.110.1" },
          { "name": "domain-name-servers", "code": 6, "space": "dhcp4", "data": "192.168.110.20" },
          { "name": "domain-name", "data": "internal.local" },
          { "name": "domain-search", "data": "oc41827.internal.local internal.local" }
        ]

      },
    ]
  }
}

Note: Ensure you replace the MAC addresses with the actual ones assigned to your VMs.

Check the configuration and enable Kea

$ sudo kea-dhcp4 -t /etc/kea/kea-dhcp4.conf

You might see some warnings, you might ignore them (but do not ignore any error), see this as an example:

$ sudo kea-dhcp4 -t /etc/kea/kea-dhcp4.conf
2026-04-21 20:52:38.159 WARN  [kea-dhcp4.dhcpsrv/6313.140336065439872] DHCPSRV_MT_DISABLED_QUEUE_CONTROL disabling dhcp queue control when multi-threading is enabled.
2026-04-21 20:52:38.159 WARN  [kea-dhcp4.dhcp4/6313.140336065439872] DHCP4_RESERVATIONS_LOOKUP_FIRST_ENABLED Multi-threading is enabled and host reservations lookup is always performed first.
2026-04-21 20:52:38.160 INFO  [kea-dhcp4.dhcpsrv/6313.140336065439872] DHCPSRV_CFGMGR_NEW_SUBNET4 a new subnet has been added to configuration: 192.168.110.0/24 with params: valid-lifetime=7200
2026-04-21 20:52:38.160 INFO  [kea-dhcp4.dhcpsrv/6313.140336065439872] DHCPSRV_CFGMGR_SOCKET_TYPE_SELECT using socket type raw
2026-04-21 20:52:38.160 INFO  [kea-dhcp4.dhcpsrv/6313.140336065439872] DHCPSRV_CFGMGR_USE_ADDRESS listening on address 192.168.110.20, on interface enp7s0
2026-04-21 20:52:38.160 INFO  [kea-dhcp4.dhcpsrv/6313.140336065439872] DHCPSRV_CFGMGR_SOCKET_TYPE_DEFAULT "dhcp-socket-type" not specified , using default socket type raw
2026-04-21 20:52:38.160 INFO  [kea-dhcp4.dhcpsrv/6313.140336065439872] DHCPSRV_LEASE_MGR_BACKENDS_REGISTERED the following lease backend types are available: memfile
2026-04-21 20:52:38.160 INFO  [kea-dhcp4.hosts/6313.140336065439872] HOSTS_BACKENDS_REGISTERED the following host backend types are available: 
2026-04-21 20:52:38.160 INFO  [kea-dhcp4.dhcpsrv/6313.140336065439872] DHCPSRV_FORENSIC_BACKENDS_REGISTERED the following forensic backend types are available: 
2026-04-21 20:52:38.160 INFO  [kea-dhcp4.database/6313.140336065439872] CONFIG_BACKENDS_REGISTERED the following config backend types are available: 
$

Enable and start the service:

$ sudo systemctl enable --now kea-dhcp4

and allow the service through the firewall.

$ sudo firewall-cmd --add-service=dhcp --permanent
$ sudo firewall-cmd --reload

5. Web Services & iPXE Boot

OpenShift uses a live-boot mechanism. We need an HTTP server to serve the RHCOS kernel, rootfs, and ignition files, plus TFTP for the initial bootloader.

Apache Setup

Install Apache

$ sudo dnf install httpd -y

To prevent interferences with haproxy, change the listen port to include the IP address:

$ sudo nano /etc/httpd/conf/httpd.conf

From

Listen 80

Listen 192.168.110.20:80

Allow the service through the firewall.

$ sudo firewall-cmd --add-service=http --permanent
$ sudo firewall-cmd --reload

and enable and start the service:

$ sudo systemctl enable --now httpd.service

TFTP Setup

Install TFTP:

$ sudo dnf install tftp-server -y

Enable and start the service:

$ sudo systemctl enable --now tftp.socket

and allow the service through the firewall.

$ sudo firewall-cmd --add-service=tftp --permanent
$ sudo firewall-cmd --reload

iPXE Setup

We are going to deploy the OpenShift nodes using ipxe and tftp-server. The key is the boot.ipxe script, which we will discuss in the next blog. For now, we prepare iPXE.

Install iPXE

$ sudo dnf install ipxe-bootimgs

and prepare the basic structure.

$ sudo cp /usr/share/ipxe/undionly.kpxe /var/lib/tftpboot/
$ sudo cp /usr/share/ipxe/ipxe-snponly-x86_64.efi /var/lib/tftpboot/
$ sudo restorecon -Rv /var/lib/tftpboot

It can be later used to install other OS, like RHEL or Ubuntu.

6. Load Balancing with HAProxy

This is critical for High Availability. HAProxy listens on the API VIP (192.168.110.21) and Ingress VIP (192.168.110.22) and forwards traffic to the backend nodes.

Install HAProxy

$ sudo dnf install haproxy -y

HAProxy Configuration for Openshift

Use nano or vim to update the configuration file (/etc/haproxy/haproxy.cfg). See below the changes I made:

# /etc/haproxy/haproxy.cfg snippet
    chroot      /var/lib/haproxy
    #pidfile     /var/run/haproxy.pid

defaults
    mode                    tcp
    log                     global
    option                  tcplog
    retries                 3
    timeout connect         10s
    timeout client          1m
    timeout server          1m
    maxconn                 3000

#---------------------------------------------------------------------
# round robin balancing for RHOCP Kubernetes API Server
#---------------------------------------------------------------------
 listen api-server-6443
   bind 192.168.110.21:6443
   mode tcp
   option httpchk GET /readyz HTTP/1.0
   option log-health-checks
   balance roundrobin
   server bootstos bootstos.oc41827.internal.local:6443 verify none check check-ssl inter 10s fall 2 rise 3 backup
   server masteros01 masteros01.oc41827.internal.local:6443 weight 1 verify none check check-ssl inter 10s fall 2 rise 3
   server masteros02 masteros02.oc41827.internal.local:6443 weight 1 verify none check check-ssl inter 10s fall 2 rise 3
   server masteros03 masteros03.oc41827.internal.local:6443 weight 1 verify none check check-ssl inter 10s fall 2 rise 3

# ---------------------------------------------------------------------
# round robin balancing for RHOCP Machine Config Server
# ---------------------------------------------------------------------
 listen machine-config-server-22623
   bind 192.168.110.21:22623
   mode tcp
   server bootstos bootstos.oc41827.internal.local:22623 check inter 1s backup
   server masteros01 masteros01.oc41827.internal.local:22623 check inter 1s
   server masteros02 masteros02.oc41827.internal.local:22623 check inter 1s
   server masteros03 masteros03.oc41827.internal.local:22623 check inter 1s

# ---------------------------------------------------------------------
# round robin balancing for RHOCP Ingress Insecure Port
# ---------------------------------------------------------------------
 listen ingress-router-80
   bind 192.168.110.22:80
   mode tcp
   balance source
   server workeros01 workeros01.oc41827.internal.local:80 check inter 1s
   server workeros02 workeros02.oc41827.internal.local:80 check inter 1s
   server workeros03 workeros03.oc41827.internal.local:80 check inter 1s

# ---------------------------------------------------------------------
# round robin balancing for RHOCP Ingress Secure Port
# ---------------------------------------------------------------------
 listen ingress-router-443
   bind 192.168.110.22:443
   mode tcp
   balance source
   server workeros01 workeros01.oc41827.internal.local:443 check inter 1s
   server workeros02 workeros02.oc41827.internal.local:443 check inter 1s
   server workeros03 workeros03.oc41827.internal.local:443 check inter 1s

Updating firewalld and SELinux

We need to allow the tcp ports used by OpenShift through firewalld

$ sudo firewall-cmd --permanent --add-service=https
$ sudo firewall-cmd --permanent --add-port=6443/tcp
$ sudo firewall-cmd --permanent --add-port=22623/tcp
$ sudo firewall-cmd --reload

and also ensure SELinux allows those ports to be used as HTTP ports

$ sudo semanage port -a -t http_port_t -p tcp 6443
$ sudo semanage port -m -t http_port_t -p tcp 6443
$ sudo semanage port -a -t http_port_t -p tcp 22623
$ sudo semanage port -m -t http_port_t -p tcp 22623

Configuration check and enabling the HAProxy service

Check the configuration file:

$ sudo haproxy -c -f /etc/haproxy/haproxy.cfg

Note that no output from the previous command is good news!

and enable and start the service.

$ sudo systemctl enable --now haproxy

🔜 Coming Up in Part 2

Now that the network is breathing correctly, we need to generate the Ignition files.

Downloading RHCOS and OpenShift CLI tools.
Creating the install-config.yaml.
Running openshift-install to generate manifests.
Critical Step: Disabling Secure Boot on VMs (the "secret" to getting iPXE to work).
Powering on the nodes and watching the magic happen.

Stay tuned!

Did you find this guide helpful? Let me know in the comments if you'd prefer using Ansible for the setup instead of manual commands! Also, subscribe to follow the rest of the series.

Building a Kubernetes Cluster on Red Hat Enterprise Linux 10: A kubeadm Guide

Ana Villar — Thu, 18 Jun 2026 18:22:11 +0000

Introduction

In this post, I'll walk you through deploying a production-ready Kubernetes cluster on Red Hat Enterprise Linux 10 using kubeadm. This lab was inspired by Anthony E. Nocentino's excellent Certified Kubernetes Administrator (CKA): Using kubadm to Install a Basic Cluster training course, which is part of the official Certified Kubernetes Administrator (CKA) path on Pluralsight.

⭐ Shout-out: Anthony is a fantastic trainer! His course uses Ubuntu 22.04 as the base OS. I adapted his approach to work on RHEL 10, adding some additional considerations specific to Red Hat's ecosystem.

One intentional decision in this setup: I deployed Kubernetes v1.35 and CRI-O v1.35, which wasn't the latest version available at installation time.

This was purposeful. Anthony's course includes a dedicated section on upgrading clusters, and using a slightly older baseline makes that learning path clearer.

The upgrade procedures (not covered here) are what really solidify your understanding of cluster lifecycle management.

Lab Infrastructure Overview

Nodes Configuration

Node	Role	RAM	vCPUs	IP Address
rh-cp1	Control Plane	12 GiB	2	192.168.110.120
rh-node1	Worker	6 GiB	2	192.168.110.121
rh-node2	Worker	6 GiB	2	192.168.110.122
rh-node3	Worker	6 GiB	2	192.168.110.123

Note: The IP address schema is just an example and what was more convenient for me.

Supporting Infrastructure

A dedicated utilities VM (also RHEL 10) provides essential services:

DNS (BIND/named)
NTP (chrony)
HTTP (Apache/httpd)
DHCP (Kea)

This centralized infrastructure simplifies name resolution across all cluster nodes. But this is not essential for this project. You can, instead, ensure the nodes are able to reach each other updating the file /etc/hosts on all nodes.

Prerequisites & OS Preparation

Before diving into Kubernetes, we need consistent node preparation across all machines.

1. System Registration and Updates

$ sudo subscription-manager register --username <username> --password <password>
$ sudo dnf update redhat-release
$ sudo dnf upgrade
$ sudo reboot

2. Disable Swap (Required by Kubernetes)

Edit /etc/fstab to comment out swap entries:

UUID=xxxxxxxx-xxx-xxxx-xxxx-xxxxxxxxxxxx none swap defaults 0 0
# ^ Comment this line out

Verify:

$ sudo swapoff -a
$ free

3. Disable Firewalld

Disable firewalld, as indicated in the Calico System requirements for Kubernetes:

$ sudo systemctl stop firewalld
$ sudo systemctl disable firewalld
$ sudo systemctl mask firewalld

⚠️ Production Note: Use Calico to maintaining security and enforce network policies later.

4. Load Kernel Modules and Enable IP Forwarding

$ cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF

$ sudo modprobe overlay
$ sudo modprobe br_netfilter

Configure sysctl parameters:

$ cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward = 1
EOF

$ sudo sysctl --system

Verify the modules loaded correctly:

$ lsmod | grep overlay
$ lsmod | grep br_netfilter

Installing Kubernetes Components

Setting Version Variables

$ KUBERNETES_VERSION=v1.35
$ CRIO_VERSION=v1.35

Adding Repositories

Create the Kubernetes repo:

$ cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://pkgs.k8s.io/core:/stable:/$KUBERNETES_VERSION/rpm/
enabled=1
gpgcheck=1
gpgkey=https://pkgs.k8s.io/core:/stable:/$KUBERNETES_VERSION/rpm/repodata/repomd.xml.key
EOF

Create the CRI-O repo:

$ cat <<EOF | sudo tee /etc/yum.repos.d/cri-o.repo
[cri-o]
name=CRI-O
baseurl=https://download.opensuse.org/repositories/isv:/cri-o:/stable:/$CRIO_VERSION/rpm/
enabled=1
gpgcheck=1
gpgkey=https://download.opensuse.org/repositories/isv:/cri-o:/stable:/$CRIO_VERSION/rpm/repodata/repomd.xml.key
EOF

Installing Packages

$ sudo dnf install -y kubelet kubeadm kubectl cri-o container-selinux

Configuring CRI-O

Create a cgroup manager configuration file:

$ cat <<EOF | sudo tee /etc/crio/crio.conf.d/02-cgroup-manager.conf
[crio.runtime]
conmon_cgroup = "pod"
cgroup_manager = "cgroupfs"
EOF

Enable and start services:

$ sudo systemctl enable --now crio kubelet
$ sudo systemctl restart crio

Version Locking

To prevent accidental upgrades:

$ sudo dnf install 'dnf-command(versionlock)'
$ sudo dnf versionlock add kubeadm-1.35.4 kubelet-1.35.4 kubectl-1.35.4 cri-o-1.35.2

Note: Review the output from the installation of the packages kubeadm, kubelet, kubectl and cri-o, and update the versions to lock in the command above.

Initializing the Control Plane

On rh-cp1, download and configure Calico networking. To know the current lastest version, check Tigera documentation, in the Manifest tab:

$ wget https://raw.githubusercontent.com/projectcalico/calico/v3.32.0/manifests/calico.yaml

Edit the CALICO_IPV4POOL_CIDR value to match your pod network plan:

- name: CALICO_IPV4POOL_CIDR
  value: "10.244.0.0/16"

Initialize the cluster, to use the same subnet:

$ sudo kubeadm init \
  --kubernetes-version v1.35.4 \
  --pod-network-cidr=10.244.0.0/16 \
  --cri-socket unix:///var/run/crio/crio.sock \
  --upload-certs

Once successful, save the join commands that appear at the end of the output—you'll need these for worker nodes!

To start using your cluster, you need to run the following as a regular user:

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

Alternatively, if you are the root user, you can run:

  export KUBECONFIG=/etc/kubernetes/admin.conf

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  https://kubernetes.io/docs/concepts/cluster-administration/addons/

Then you can join any number of worker nodes by running the following on each as root:

kubeadm join 192.168.110.120:6443 --token xxxxxx.xxxxxxxxxxxxxxxx \
 --discovery-token-ca-cert-hash sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx  
$

Your Kubernetes control-plane has initialized successfully!

Configuring kubectl

$ mkdir -p $HOME/.kube
$ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
$ sudo chown $(id -u):$(id -g) $HOME/.kube/config

Deploy Calico Network

$ kubectl apply -f calico.yaml

Wait a few minutes and verify pods are running:

$ kubectl get pods --all-namespaces
$ kubectl get nodes

Expected output:

$ kubectl get pods --all-namespaces
NAMESPACE     NAME                                       READY   STATUS    RESTARTS   AGE
kube-system   calico-kube-controllers-6b4b6457d5-p98c2   1/1     Running   0          2m47s
kube-system   calico-node-5vjrr                          1/1     Running   0          2m47s
kube-system   coredns-7d764666f9-r4vqp                   1/1     Running   0          4m9s
kube-system   coredns-7d764666f9-vh7df                   1/1     Running   0          4m9s
kube-system   etcd-rh-cp1                                1/1     Running   0          4m28s
kube-system   kube-apiserver-rh-cp1                      1/1     Running   0          4m28s
kube-system   kube-controller-manager-rh-cp1             1/1     Running   0          4m27s
kube-system   kube-proxy-4r6h8                           1/1     Running   0          4m10s
kube-system   kube-scheduler-rh-cp1                      1/1     Running   0          4m28s
$ kubectl get nodes
NAME     STATUS   ROLES           AGE     VERSION
rh-cp1   Ready    control-plane   4m40s   v1.35.4
$

Joining Worker Nodes

On each worker node (rh-node1, rh-node2, rh-node3), run the join command saved during kubeadm init:

$ sudo kubeadm join 192.168.110.120:6443 \
  --token <token> \
  --discovery-token-ca-cert-hash sha256:<hash>

Verify the cluster health from the control plane:

$ kubectl get nodes

All nodes should show Ready status.

$ kubectl get nodes
NAME       STATUS   ROLES           AGE     VERSION
rh-cp1     Ready    control-plane   10m     v1.35.4
rh-node1   Ready    <none>          2m11s   v1.35.4
rh-node2   Ready    <none>          113s    v1.35.4
rh-node3   Ready    <none>          102s    v1.35.4
$

Install bash completion for kubectl:

$ sudo dnf install bash-completion
$ echo "source <(kubectl completion bash)" >> ~/.bashrc
$ source ~/.bashrc

Testing the Deployment

Deploy a test application:

$ kubectl create deployment hello-world --image=psk8s.azurecr.io/hello-app:1.0
$ kubectl get pods -o wide

Expose it via a service:

$ kubectl expose deployment hello-world --port=80 --target-port=8080
$ kubectl get service hello-world

For example:

$ kubectl get service hello-world
NAME          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
hello-world   ClusterIP   10.99.168.218   <none>        80/TCP    8s
$

Then, test it. You should see a response from your running container!

$ curl http://10.99.168.218:80
Hello, world!
Version: 1.0.0
hello-world-b5b7f67cc-d26dt
$

Clean up after testing:

$ kubectl delete service hello-world
$ kubectl delete deployment hello-world

Key Considerations When Moving from Ubuntu to RHEL

Here are the main differences I encountered adapting Anthony's tutorial:

Aspect	Ubuntu Approach	RHEL 10 Adaptation
Package Manager	apt/dpkg	dnf/rpm
Firewall Management	ufw/firewalld optional	firewalld disabled (use Calico policies)
Subscription	N/A	subscription-manager required
SELinux	Permissive mode default	Need to handle SELinux context
CRI Runtime	containerd	CRI-O

What's Next?

This setup provides a solid foundation for learning Kubernetes administration. From here, you could explore:

Cluster upgrades (covered extensively in Anthony's course)
Network policy enforcement with Calico
High availability with multiple control plane nodes
Storage classes and persistent volumes
Monitoring stack with Prometheus/Grafana

If you found this walkthrough helpful, I'd highly recommend checking out the original Pluralsight course. Anthony's explanations are crystal clear, and adapting them to different distributions is an excellent way to deepen your understanding of what happens under the hood.

Resources

Pluralsight: Certified Kubernetes Administrator Certification Path
Official Kubernetes Documentation
Calico Project GitHub

Thanks for reading! Feel free to share your own experiences with Kubernetes on RHEL in the comments below.

Complete Guide: Setting Up XWiki 17 on Premises

Ana Villar — Fri, 12 Jun 2026 19:04:27 +0000

This guide walks through deploying XWiki 17.10.8 on Red Hat Enterprise Linux 10.2 with Apache Tomcat and PostgreSQL. Total setup time: ~45 minutes. Requires minimum 8GB RAM and 4 vCPUs for acceptable performance.

If you're looking to deploy a self-hosted wiki solution with enterprise-grade features, XWiki is an excellent choice. Unlike some alternatives, it offers powerful permission management, structured data, and extensibility through extensions. However, the on-premises setup can be intimidating due to multiple moving parts.

This guide details setting up XWiki 17 on Red Hat Linux Server 10.2 with 16GB RAM and 4 vCPUs. I initially validated these steps in a Mac-hosted VM before deploying them to my production environment on a Dell OptiPlex 7050 Micro.

What You'll Need

Hardware Requirements

Resource	Minimum	Recommended
CPU	2 cores	4+ cores
RAM	4 GB	16 GB
Storage	20 GB	100 GB

Note: During my initial setup on a 2GB RAM old laptop, XWiki was functional but painfully slow. The jump to 16GB made a night-and-day difference in responsiveness.

Software Stack

Operating System: Red Hat Enterprise Linux 10.2 or Fedora Server
Servlet Container: Apache Tomcat 10.1.x (Jetty is also supported)
Database: PostgreSQL 16.x
Java: OpenJDK 21
XWiki Platform: 17.10.8 WAR package

Comments:

As Operating System, you can use other Linux Distributions, including Ubuntu, Windows Server and Docker Engine.
As Servlet Container, Jetty is also a supported option.
Other supported databases are HyperSQL, MariaDB, MySQL, or Oracle.
For more information, review XWiki prerequisites.

Time Investment

Installation: ~30 minutes
Configuration: ~15 minutes
Testing: ~10 minutes

Preparation Steps

Install Your Base OS

For this guide, I'm using Red Hat Enterprise Linux, but most steps work equally well on Fedora Server if you don't have RHEL subscriptions.

Download from Red Hat Developer Program or Fedora Server.

Once installed, register (if using RHEL), update, and reboot:

~$ sudo subscription-manager register --username <username> --password <password>
~$ sudo dnf upgrade -y
~$ reboot

Installing Dependencies

Install and configure Apache Tomcat

Tomcat serves as our servlet container for hosting XWiki:

~$ sudo dnf install tomcat -y

This command pulls in Java 21 along with necessary dependencies automatically. Review the installation output to confirm java-21-openjdk-headless was included.

Architecture Note:
Package names vary by architecture:

x86_64: java-21-openjdk-headless.x86_64
aarch64: java-21-openjdk-headless.aarch64

If it seems to be missing:

~$ sudo dnf install java-21-openjdk-headless.x86_64 -y

~$ sudo dnf install java-21-openjdk-headless.aarch64 -y

Configure Firewall

Allow HTTP traffic on port 8080 (Tomcat's default):

~$ sudo firewall-cmd --permanent --add-port=8080/tcp
~$ sudo firewall-cmd --reload

Verify it's open:

~$ sudo firewall-cmd --list-all

Configure Tomcat Memory Settings

By default, Tomcat won't allocate enough memory for XWiki to perform well. Create a custom setenv.sh file:

~$ sudo mkdir -p /var/lib/tomcat/bin
~$ sudo chown tomcat:tomcat -R /var/lib/tomcat
~$ sudo nano /var/lib/tomcat/bin/setenv.sh

Add this configuration:

#!/bin/sh
export JAVA_OPTS="${JAVA_OPTS} -Djava.awt.headless=true"
export CATALINA_OPTS="-server -Xms1080m -Xmx1600m -Dfile.encoding=utf-8 \
-Djava.awt.headless=true \
--add-opens java.base/java.lang=ALL-UNNAMED \
--add-opens java.base/java.io=ALL-UNNAMED \
--add-opens java.base/java.util=ALL-UNNAMED \
--add-opens java.base/java.util.concurrent=ALL-UNNAMED"

Memory Explanation:

Setting	Value	Purpose
-Xms	1080MB	Initial heap size (prevents startup allocation spikes)
-Xmx	1600MB	Maximum heap size (prevents runaway memory consumption)
--add-opens	N/A	Required for Java 17+ compatibility with certain libraries

Set ownership and test:

~$ sudo chown tomcat:tomcat /var/lib/tomcat/bin/setenv.sh
~$ sudo systemctl enable --now tomcat
~$ sudo systemctl status tomcat

Test from another machine by visiting http://your-server-name:8080. You should see the Tomcat welcome page. Once confirmed, stop the service — we'll restart after XWiki deployment:

~$ sudo systemctl stop tomcat

Database Configuration (PostgreSQL)

Install PostgreSQL

~$ sudo dnf install postgresql-server postgresql-contrib -y

Initialize and Start PostgreSQL

~$ sudo postgresql-setup --initdb
~$ sudo systemctl enable --now postgresql
~$ sudo systemctl status postgresql

Create XWiki User and Database

Switch to the postgres user:

~$ sudo su postgres
bash-5.2$ psql

Then run these SQL commands:

CREATE USER xwiki PASSWORD 'xwikipassword';
CREATE DATABASE xwiki WITH OWNER=xwiki;
GRANT ALL ON SCHEMA public TO xwiki;
\q

⚠️ Security Warning: Replace 'xwikipassword' with a strong, unique password. Never use default credentials in production. Consider using environment variables or secret management tools like HashiCorp Vault for sensitive data.

Configure PostgreSQL Authentication

Find the authentication config file:

~$ sudo su postgres
bash-5.2$ psql -c "SHOW hba_file;"

By default, the file and location is /var/lib/pgsql/data/pg_hba.conf

Edit the pg_hba.conf file to change authentication method:

~$ sudo nano /var/lib/pgsql/data/pg_hba.conf

Replace these lines:

# OLD (insecure)
host    all             all             127.0.0.1/32            ident
host    all             all             ::1/128                 ident

# NEW (secure)
host    all             all             127.0.0.1/32            scram-sha-256
host    all             all             ::1/128                 scram-sha-256

Reload PostgreSQL to apply changes:

~$ sudo systemctl reload postgresql

Verify Database Connection:

~$ psql postgresql://xwiki:xwikipassword@localhost
xwiki=> \l  # Should list databases including 'xwiki'
xwiki=> \q  # Exit psql
~$

Deploying XWiki

Download Required Files

Get these two files from official sources:

XWiki WAR Package: Production Installation → Select "WAR Package for Servlet Container"
PostgreSQL JDBC Driver: Official Downloads

Place them in a download directory:

~$ mkdir ~/downloads
~$ cd ~/downloads
# wget the links here from browser or CLI
~$ ls downloads/
postgresql-42.7.11.jar  xwiki-platform-distribution-war-17.10.8.jar
~$

Deploy the WAR Package

Copy and extract the XWiki WAR:

~$ sudo cp ~/downloads/xwiki-platform-distribution-war-17.10.8.jar /var/lib/tomcat/webapps/
~$ cd /var/lib/tomcat/webapps
~$ sudo unzip xwiki-platform-distribution-war-17.10.8.jar
~$ sudo mkdir xwiki
~$ sudo mv META-INF redirect resources skins templates WEB-INF xwiki/
~$ sudo rm xwiki-platform-distribution-war-17.10.8.jar
~$ sudo chown -R tomcat:tomcat xwiki/

Common Pitfall: If you get an error about moving files into themselves, ensure you're not inside the extracted directory when creating the target folder.

Add PostgreSQL JDBC Driver

~$ cd /var/lib/tomcat/webapps/xwiki/WEB-INF/lib
~$ sudo cp ~/downloads/postgresql-42.7.11.jar .
~$ sudo chown tomcat:tomcat *.jar

Configure Hibernate for PostgreSQL

Edit the Hibernate configuration:

~$ cd /var/lib/tomcat/webapps/xwiki/WEB-INF
~$ sudo nano hibernate.cfg.xml

Find and comment out the default database section:

    <!--
    <property name="hibernate.connection.url">jdbc:hsqldb:file:${environment.permanentDirectory}/database/xwiki_db;shutdown=true</property>
    <property name="hibernate.connection.username">sa</property>
    <property name="hibernate.connection.password"></property>
    <property name="hibernate.connection.driver_class">org.hsqldb.jdbcDriver</property>
    -->

Find and uncomment the PostgreSQL section:

    <!-- PostgreSQL configuration.
         Uncomment if you want to use PostgreSQL and comment out other database configurations.
         Notes:
           - "hibernate.jdbc.use_streams_for_binary" needs to be set to "false",
             see https://community.jboss.org/wiki/HibernateCoreMigrationGuide36
           - "xwiki.virtual_mode" can be set to either "schema" or "database". Note that currently the database mode
             doesn't support database creation (see https://jira.xwiki.org/browse/XWIKI-8753)
           - if you want the main wiki database to be different than "xwiki" (or "public" in schema mode)
             you will also have to set the property xwiki.db in xwiki.cfg file
    -->

    <property name="hibernate.connection.url">jdbc:postgresql://localhost:5432/xwiki</property>
    <property name="hibernate.connection.username">xwiki</property>
    <property name="hibernate.connection.password">**xwikipassword**</property>
    <property name="hibernate.connection.driver_class">org.postgresql.Driver</property>
    <property name="hibernate.jdbc.use_streams_for_binary">false</property>
    <property name="xwiki.virtual_mode">schema</property>

    <property name="hibernate.connection.charSet">UTF-8</property>
    <property name="hibernate.connection.useUnicode">true</property>
    <property name="hibernate.connection.characterEncoding">utf8</property>

    <mapping resource="xwiki.postgresql.hbm.xml"/>
    <mapping resource="feeds.hbm.xml"/>
    <mapping resource="instance.hbm.xml"/>
    <mapping resource="notification-filter-preferences.hbm.xml"/>
    <mapping resource="mailsender.hbm.xml"/>


    <!-- Oracle configuration.
...

⚠️ Password Reminder: Update the password value to match what you set earlier!

Configure Permanent Directory

Create a dedicated directory for XWiki data:

~$ sudo mkdir -p /var/lib/xwiki/data
~$ sudo chown -R tomcat:tomcat /var/lib/xwiki

Edit the properties file:

~$ nano /var/lib/tomcat/webapps/xwiki/WEB-INF/xwiki.properties

Uncomment and verify this line:

environment.permanentDirectory = /var/lib/xwiki/data/

Starting the Application

~$ sudo systemctl start tomcat

Wait 3-5 minutes for Tomcat to fully initialize XWiki (it compiles resources on first boot). Monitor logs:

~$ sudo tail -f /var/log/tomcat/catalina.out

Look for messages like XWiki context has been initialized successfully.

XWiki Configuration Wizard

Running the Configuration Wizard

Navigate to your server: http://your-server-name:8080/xwiki.

You'll see an initialization banner briefly, then the wizard will appear.

Wizard Steps

Press Continue to begin

Create Administrator Account: Set a strong admin password (save this securely!).

Press Register and Login.

Press Continue

Install Standard Flavor: Select "XWiki Standard Flavor" from the dropdown—this includes useful built-in applications

Press Install this flavor: Wait 2-5 minutes depending on hardware

Press Install

Once you see it has been Installed, Press Continue to completion.

After finalization, press Continue and you'll be redirected to your XWiki home page with example documentation.

Your XWiki server is ready!

Post-Installation Checklist

Security Hardening

Action	Priority	Command/File
Change default PostgreSQL password	High	psql ALTER USER command
Update Tomcat manager passwords	High	tomcat-users.xml
Enable HTTPS via reverse proxy	High	nginx/Apache configuration
Restrict database access	Medium	pg_hba.conf network rules
Regular backups	High	XWiki GUI + cron jobs + pg_dump

Performance Tuning

With 16GB RAM, you may want to increase XWiki's maximum heap:

# Edit setenv.sh
CATALINA_OPTS="-Xmx2048m ..."  # Increase if needed

Enable query caching in xwiki.properties:

cache.default.maxSize = 5000

Backup Strategy

Using XWiki GUI

Go to Administer Wiki:

Select Content:

And select Export:

You can select what pages to export/backup.

Database:

pg_dump -U xwiki xwiki > xwiki_backup_$(date +%Y%m%d).sql

File Data:

tar czf xwiki_files_$(date +%Y%m%d).tar.gz /var/lib/xwiki/data/

Schedule these as cron jobs for automated backups.

Troubleshooting Common Issues

Issue: XWiki Won't Load After Startup

Symptoms: Browser shows blank page or timeout at /xwiki

Solutions:

Check logs: tail -f /var/log/tomcat/catalina.out
Verify database connection is active
Ensure hibernate.cfg.xml has correct credentials
Restart Tomcat completely

Issue: Slow Page Loading

Symptoms: Pages take 5+ seconds to load

Solutions:

Increase JVM heap in setenv.sh
Check available RAM with free -h
Disable unnecessary extensions in XWiki admin panel
Consider upgrading to SSD storage

Issue: Database Connection Error

Symptoms: "Cannot connect to database" during wizard

Solutions:

Verify PostgreSQL is running: sudo systemctl status postgresql
Test connectivity: psql -U xwiki -d xwiki
Check pg_hba.conf has scram-sha-256 authentication
Ensure firewall allows localhost PostgreSQL connections (port 5432)

Why On-Premises Over Cloud?

You might wonder why choose self-hosted instead of XWiki Cloud. Here are compelling reasons:

Factor	On-Premises	Cloud
Data Control	Full	Limited by provider
Customization	Unlimited	Restricted
Cost (Long-term)	Lower	Subscription-based
Offline Access	Yes	Requires internet
Integration	Direct system access	API-only

For organizations handling sensitive data or requiring deep integration, on-premises deployment provides the flexibility you need.

Final Thoughts

Setting up XWiki on-premises involves coordinating several components, but once configured, you have a powerful, self-contained knowledge management platform. The setup I've outlined balances security, performance, and maintainability.

Got questions or encountered different errors? Drop a comment below — I'm happy to help troubleshoot!

Further Resources

Hello, DEV Community! 👋

Ana Villar — Sat, 30 May 2026 15:53:23 +0000

I'm Ana, and I'm excited to start sharing my technical journey here. This is a brief post to introduce myself and give you a heads-up on what's coming.

What to Expect

In upcoming posts, I'll be diving into hands-on, infrastructure-focused tutorials and walkthroughs, including:

Setting up a XWiki server on-premises — from installation to configuration, getting a collaborative wiki platform running in your own environment.
Deploying Kubernetes on RHEL 10 virtual machines — step-by-step guidance on building a Kubernetes cluster on Red Hat Enterprise Linux 10.
Deploying OpenShift as virtual machines on a RHEL 10 host — exploring how to run OpenShift on top of RHEL 10, combining the power of containers with VM-level control.

My goal is to keep things practical, clear, and rooted in real-world experience — the kind of content I wish I'd had when tackling these setups myself.

Why These Topics?

Because on-premises infrastructure is far from dead. Whether it's compliance requirements, performance needs, or simply wanting full control over your stack, there's still a strong case for running things yourself. And RHEL was my choice for certification purposes, and it's given me the flexibility to keep using hardware that other vendors have discontinued.

Stay tuned, and feel free to follow me so you don't miss the upcoming posts. If any of these topics spark your interest, I'd love to hear about it in the comments! 🚀