Forem: William Kwabena Akoto

Dual-Booting Windows 11 & Rocky Linux — A Beginner's Complete Guide

William Kwabena Akoto — Sun, 03 May 2026 22:12:17 +0000

A step-by-step guide for beginners who want a gaming PC and a real enterprise Linux environment on the same machine — with every decision explained in plain English.

What Is Dual-Booting and Why Rocky Linux?
Key Concepts You Must Understand First
- UEFI, BIOS, and Secure Boot
- Partitions, File Systems, and GPT
- The GRUB Bootloader
Before You Begin — Checklist
Phase 1 — Shrink Your Windows Partition
Phase 2 — Download & Flash Rocky Linux
Phase 3 — Configure the HP BIOS
Phase 4 — Boot the Rocky Linux Installer
Phase 5 — Anaconda Installer Walkthrough
Phase 6 — First Boot & the GRUB Menu
Phase 7 — Post-Install DevOps Setup
Troubleshooting Common Problems

1. What Is Dual-Booting and Why Rocky Linux?

Dual-booting means installing two separate operating systems on the same physical computer, each living in its own isolated section of the hard drive called a partition. When you power on your laptop, a small program called a bootloader wakes up and shows you a menu: pick Windows or pick Rocky Linux. The two systems never interfere with each other.

This is different from a virtual machine, where you'd run Linux inside a window on top of Windows. Dual-booting gives each OS full, direct access to your hardware — better performance, real GPU access for your DevOps tools, and a genuine feel for what it's like to administer a server.

Why Rocky Linux specifically? Rocky Linux is a free, community-maintained and designed for 1:1, bug-for-bug downstream binary compatibility with Red Hat Enterprise Linux (RHEL) — the operating system that runs a huge chunk of the world's servers, cloud infrastructure, and enterprise data centres. When companies say they want "Linux experience", they usually mean RHEL-family experience.Rocky Linux is fullRocky Linux 10.1 is fully supported until May 2035, giving you a stable, long-term learning platform.

Rocky Linux will push you further: its default security model (SELinux), firewall tool (firewalld), and package manager (DNF) are all standard in enterprise environments that other linux distributions rarely appear in.

2. Key Concepts You Must Understand First

Before touching a single setting, you need to understand why you're making each decision. Skipping this section is how people accidentally wipe their Windows installation. Take ten minutes to read it.

UEFI, BIOS, and Secure Boot

What is UEFI / BIOS?
UEFI (or its older predecessor, BIOS) is firmware — a tiny program burned into a chip on your motherboard. It's the very first thing that runs when you press the power button, before any operating system loads. Its job is to inventory your hardware (CPU, RAM, drives) and then hand control to a bootloader on one of your storage devices.

Your computer mostly likely uses UEFI, the modern standard. UEFI uses a special partition called the EFI System Partition (ESP) — a small FAT32 partition that stores bootloader files for every OS installed. Windows already placed its bootloader there. Rocky Linux will add its own file alongside it without deleting Windows.

What is Secure Boot?
Secure Boot is a UEFI feature that checks a digital signature on every bootloader before running it. It prevents malware from hijacking the boot process. However, it can also block Linux installers that aren't signed with a trusted key.

Rocky Linux does have Secure Boot support, but to avoid any complications on first install, we will disable Secure Boot in the BIOS before installing. You can re-enable it afterwards once everything is working.

Partitions, File Systems, and GPT

What is a partition?
Imagine your hard drive as a single large plot of land. A partition is like drawing property lines to divide it into separate sections. Each section is completely independent — one can have Windows on it, another can have Linux, and they don't mix.

What is a file system?
A file system is the internal structure that a partition uses to organise files. Windows uses NTFS. Rocky Linux defaults to XFS — the same file system used on most RHEL enterprise servers.

What is GPT?
GPT (GUID Partition Table) is the modern standard for how partition information is stored on a disk. Your computer mostly already uses GPT since it might have come with Windows 10/11 already on it.

Here is what your disk will look like after the installation is complete:

[ EFI ][ Windows (C:) — ~400 GB ][ /boot ][ swap ][ /  root ][ /home ]

Mount Point	Size	File System	Purpose
`/boot/efi`	Reuse existing	FAT32	Already exists. Stores bootloaders for all OSes. Never format.
`/boot`	1 GB	ext4	Stores the Linux kernel. Kept separate for boot-process compatibility.
`swap`	= your RAM size	swap	Overflow RAM storage. Required for hibernation.
`/` (root)	40–60 GB	xfs	The OS, all installed software, and system configs.
`/home`	Remaining space	xfs	Your personal files and projects. Survives an OS reinstall intact.

The GRUB Bootloader

What is GRUB?
GRUB (Grand Unified Bootloader) is the program that Rocky Linux installs to manage booting. After installation, GRUB detects all installed operating systems and shows you a menu. When you select Windows, GRUB hands control to the Windows Boot Manager. When you select Rocky Linux, GRUB loads the Linux kernel directly.

GRUB installs itself into the EFI System Partition alongside the Windows bootloader. This is why we never format the EFI partition — doing so would delete the Windows bootloader and make Windows unbootable.

3. Before You Begin — Checklist

Work through this checklist completely before proceeding. Every item matters.

Back up your Windows data first. Partitioning operations carry inherent risk. If something goes wrong mid-operation, data loss is possible. Copy your important files to an external drive, a cloud service, or both. This is non-negotiable.

Check 1 — CPU Compatibility

Rocky Linux 10 requires a CPU supporting the x86-64-v3 instruction set. Any AMD Ryzen 2000+ or Intel 8th Gen (Coffee Lake)+ processor qualifies.

To confirm, open PowerShell on Windows and run:

wmic cpu get name

Check 2 — Disable Windows Fast Startup

Windows Fast Startup leaves the Windows file system in a "partially mounted" state on shutdown. If Linux then tries to read the Windows partition, it can corrupt the file system. Disable it permanently:

Press Win + S, search for Control Panel, open it
Go to Hardware and Sound → Power Options
Click "Choose what the power buttons do" in the left sidebar
Click "Change settings that are currently unavailable"
Under "Shutdown settings", uncheck "Turn on fast startup"
Click Save changes

Check 3 — Free Disk Space

Open Disk Management (Win + X → Disk Management). You need at least 60–80 GB of free space on your C: drive to shrink comfortably. You'll be carving that space out as unallocated room for Rocky Linux.

Check 4 — A 16 GB+ USB Drive

You'll flash the Rocky Linux ISO onto this drive. It will be completely erased. Don't use one with files you need.

Check 5 — Stable Power

Plug your laptop in during the entire process. A laptop dying mid-partition or mid-install can corrupt both operating systems.

Phase 1 — Shrink Your Windows Partition

Right now, Windows occupies the entire drive. Before we can install Rocky Linux, we need to shrink the Windows partition and leave behind unallocated space that the Rocky Linux installer will carve into its own partitions.

We use Windows' own built-in tool for this — not a third-party app, not the Linux installer. This ensures Windows is aware of the change and updates its own boot records accordingly.

How Much Space to Allocate?

Use Case	Minimum	Recommended
Occasional learning / labs	50 GB	70 GB
Active DevOps work, Docker, VMs	80 GB	120 GB
Heavy Kubernetes / container dev	120 GB	150+ GB

For a DevOps workstation, 80–100 GB is the sweet spot. Docker images alone can consume 20–30 GB over time.

Step 1 — Open Disk Management

Press Win + X on your keyboard. In the menu that appears, click Disk Management. You'll see a graphical view of your disk with all current partitions shown as coloured bars.

Step 2 — Identify Your C: Drive Partition

In the graphical area at the bottom, look for the large partition labelled (C:). This is your Windows installation. Right-click it.

Step 3 — Click "Shrink Volume..."

A dialog box appears. Enter your desired amount in the field "Enter the amount of space to shrink in MB". Convert GB to MB by multiplying by 1024:

80 GB → enter 81920
100 GB → enter 102400
120 GB → enter 122880

Step 4 — Click Shrink and Wait

Windows will resize the partition (typically 30 seconds to 2 minutes). When done, you'll see a new block of black/dark unallocated space in the disk map. Do not create a new volume in that space — leave it as "Unallocated". The Rocky Linux installer will handle it.

If Windows won't let you shrink enough: This happens when Windows has "immovable" system files near the end of the partition. Fix: disable hibernation by opening an Administrator Command Prompt and running powercfg /h off, then try shrinking again.

Phase 2 — Download & Flash Rocky Linux

Step 2.1 — Download the ISO

An ISO file is a complete, exact copy of the entire Rocky Linux installer. Go to:

https://rockylinux.org/download

Under Rocky Linux 10, select the x86_64 architecture and download the DVD ISO (~10 GB). Also download the accompanying CHECKSUM file from the same page.

Step 2.2 — Verify the ISO (Don't Skip This)

Verifying the checksum confirms the file downloaded completely and without corruption. A partially downloaded or tampered ISO can cause strange installer errors that are very hard to diagnose.

Open PowerShell and run (adjust the filename to yours):

Get-FileHash "$env:USERPROFILE\Downloads\Rocky-10.1-x86_64-dvd1.iso" -Algorithm SHA256

The 64-character hash must exactly match the SHA256 value in the CHECKSUM file. If they differ — even by one character — delete the ISO and re-download it.

Step 2.3 — Flash the USB Drive with Rufus

Download Rufus from https://rufus.ie. Plug in your 16 GB+ USB drive and open Rufus. Configure it as follows:

Rufus Setting	Value	Why
Device	Your USB drive	Double-check it's the USB, not your internal drive
Boot selection	Click SELECT → choose the ISO	Rufus will auto-detect most settings
Partition scheme	GPT	Required for UEFI systems
Target system	UEFI (non CSM)	Forces UEFI mode. CSM is a legacy compatibility mode.
File system	Leave as Rufus default	Rufus knows best for bootable drives

Click START. If a dialog appears, choose "Write in ISO Image mode" and click OK.

The USB drive will be completely wiped. All data on the USB will be gone after this step.

The flashing process takes 5–15 minutes. When Rufus shows READY in green, the USB is ready.

Phase 3 — Configure the HP BIOS

The BIOS needs to be told two things: disable Secure Boot and boot from the USB instead of the hard drive.

Step 1 — Enter the BIOS Setup

Fully shut down your laptop (not restart — shut down). Plug in the Rocky Linux USB. Power on and immediately, repeatedly tap F10 until you see the BIOS setup screen.

Alternative: power on → tap Esc → HP startup menu → press F10 to enter Setup.

Step 2 — Disable Secure Boot

Navigate to the Security tab. Find Secure Boot and set it to Disabled. You can re-enable it after installation.

Step 3 — Confirm UEFI Boot Mode

Under Advanced or Boot Options, verify UEFI Boot Mode is selected. Ensure CSM / Legacy Boot is disabled.

Step 4 — Set USB as First Boot Device

Go to Boot Order. Move the USB storage device to the top of the list using the function keys shown on screen (usually F5/F6 or +/-).

Step 5 — Save and Exit

Press F10 to save changes and exit. The laptop will reboot and boot from your Rocky Linux USB.

Alternative: One-time boot menu. Power on and press F9 immediately to choose a boot device for that startup only, without permanently changing the boot order.

Phase 4 — Boot the Rocky Linux Installer

With the BIOS configured, your laptop will boot into the Rocky Linux installer. You'll see a dark GRUB menu. Use the arrow keys to highlight "Install Rocky Linux" and press Enter.

The screen may go black for 30–60 seconds after you press Enter. The Linux kernel is loading and initializing your hardware. Do not panic and do not press any keys. Wait for the graphical installer (Anaconda) to appear.

Select English (United States) and click Continue.

Phase 5 — Anaconda Installer Walkthrough

Anaconda uses a hub-and-spoke model: one main summary screen with several sections listed. Complete them in any order. The "Begin Installation" button activates only once every required section has a green checkmark.

Time & Date

Click Time & Date. Click your region on the world map. Enable Network Time if connected to Wi-Fi. Click Done.

Software Selection

Recommended for a DevOps workstation: Choose "Workstation" for the full GNOME desktop. For a leaner, server-like experience, choose "Server with GUI" instead.

Under Additional Software, also check:

Development Tools — gcc, make, git, and other build essentials
System Tools — useful system administration utilities
Headless Management — includes the SSH server for remote access
Container Management — Podman and container tools (RHEL's Docker equivalent)

Click Done.

Installation Destination — Partitioning (Most Critical Step)

This is the most important step in the entire guide. Read every instruction carefully before clicking anything. An incorrect choice here can erase your Windows installation. There is no undo button once you accept changes.

Click Installation Destination. Select your internal drive. Under Storage Configuration, select Custom. Click Done to enter the manual partitioning screen.

Partitioning Scheme: Standard vs LVM

Scheme	Best For	Verdict
Standard Partition	Simplicity — what you see is what you get	Fine for beginners who want clarity
LVM	Flexibility — resize partitions later without data loss	Recommended for DevOps — standard in enterprise RHEL

What is LVM? LVM adds an abstraction layer between physical partitions and what the OS sees as drives. Instead of a fixed partition of exactly 40 GB, you have a "logical volume" that can be grown or shrunk while the system is running. In enterprise environments you'll constantly encounter LVM-managed disks. Choose LVM.

Creating the Partitions

Use the + button to add each partition in this order:

Never format the EFI partition. It contains the Windows Boot Manager. Formatting it will make Windows unbootable. Set the mount point to /boot/efi and ensure the format checkbox is unchecked.

Partition 1 — Reuse the EFI Partition

Click on the existing EFI System Partition in the left panel, then in the right panel:

Mount Point: /boot/efi
File System: FAT32
Ensure "Do not format" is selected

Partition 2 — /boot

Mount point: /boot
Desired capacity: 1 GiB
File system: ext4

Why ext4 for /boot? GRUB reads /boot at a very early stage when LVM may not yet be available. ext4 is simple, widely supported, and reliable in this context.

Partition 3 — swap

Mount point: swap
Desired capacity: same as your RAM (e.g., 16 GiB for 16 GB of RAM)
File system: swap

What is swap? When physical RAM fills up, Linux moves less-used data to the swap partition. It's also required for hibernation.

Partition 4 — / (Root)

Mount point: /
Desired capacity: 50 GiB
File system: xfs

Why XFS? XFS is the default file system for RHEL 7+ and Rocky Linux. It excels at large files, high I/O workloads, and parallel access — all common in server environments.

Partition 5 — /home

Mount point: /home
Desired capacity: leave blank (uses all remaining unallocated space)
File system: xfs

Why a separate /home? If you ever reinstall Rocky Linux, your user data, configurations, and project files survive untouched. Simply reinstall, mount /home without formatting it, and pick up where you left off.

Review & Accept Changes

Click Done. In the "Summary of Changes" dialog, verify:

The EFI partition is listed as "mount only" (not format)
/boot, swap, /, and /home are listed as "format and mount"
Your Windows C: partition does not appear in this list at all

If everything looks correct, click "Accept Changes".

Network & Hostname

Connect to Wi-Fi. Set your hostname. Click Apply then Done.

Root Account & User Creation

What is the root account? In Linux, root is the superuser with unlimited power over the entire system. In Rocky Linux, the root account is disabled by default — a deliberate security choice that mirrors how enterprise RHEL systems are configured. Instead, you create a regular admin user that uses sudo to gain root-level privileges when needed.

Root Account: Leave it disabled (the default).
User Creation: Set a full name, a short lowercase username , and a strong password. Check "Make this user administrator" — this adds your user to the wheel group, granting sudo access.

Begin Installation

Click "Begin Installation". The installer will format partitions, install the OS and all selected packages, and configure GRUB. This takes 15–45 minutes. When finished, click "Reboot System" and remove the USB.

Phase 6 — First Boot & the GRUB Menu

After the reboot, you'll see the GRUB boot menu with two entries:

Rocky Linux (and older kernel entries)
Windows Boot Manager

By default, GRUB auto-selects Rocky Linux after a 5-second countdown. Select Rocky Linux and let it boot to the GNOME login screen.

If GRUB doesn't appear and Windows boots directly: The HP BIOS is still prioritising the Windows Boot Manager over GRUB. Enter BIOS (F10 on startup) and move "Rocky Linux" or "GRUB" above "Windows Boot Manager" in the boot order. See the Troubleshooting section for a permanent fix.

Phase 7 — Post-Install DevOps Setup

Open the Terminal application (Ctrl + Alt + T) and run the following in order.

Step 7.1 — Full System Update

dnf is Rocky Linux's package manager:

sudo dnf -y upgrade

Step 7.2 — Enable EPEL Repository

EPEL (Extra Packages for Enterprise Linux) provides thousands of additional packages not in the base RHEL repos — like a major PPA trusted across the enterprise Linux world.

sudo dnf install -y epel-release
sudo dnf upgrade -y

Step 7.3 — Understand SELinux (Don't Disable It)

Do not disable SELinux. The most common beginner advice online is to set SELinux to permissive or disabled. This destroys the entire point of using a RHEL-based system. Every enterprise RHEL deployment runs SELinux in enforcing mode. Learning to work with it — not around it — is a core career skill.

sestatus                        # view current SELinux status
getenforce                      # should say "Enforcing"
sudo ausearch -m avc -ts recent # view recent SELinux denials
sudo sealert -a /var/log/audit/audit.log  # human-readable SELinux explanations

Step 7.4 — Understand firewalld

Rocky Linux uses firewalld instead of Ubuntu's ufw. Same concept, different syntax:

sudo firewall-cmd --state                         # check it's running
sudo firewall-cmd --list-all                      # see current rules
sudo firewall-cmd --permanent --add-service=http  # allow HTTP traffic
sudo firewall-cmd --reload                        # apply changes

Troubleshooting Common Problems

Problem: Windows Boots Directly (No GRUB Menu)

The HP BIOS is loading the Windows Boot Manager before GRUB. Open Command Prompt as Administrator on Windows and run:

bcdedit /set {bootmgr} path \EFI\rocky\grubx64.efi

Alternatively, boot from the Rocky Linux USB → Troubleshooting → Rescue, then run:

grub2-install /dev/nvme0n1          # for NVMe drives
grub2-mkconfig -o /boot/grub2/grub.cfg

Problem: Windows Missing from GRUB Menu

GRUB didn't detect Windows. Install os-prober and regenerate the GRUB config:

sudo dnf install -y os-prober
sudo os-prober                        # should output a line mentioning Windows
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
sudo reboot

Problem: Wi-Fi Doesn't Work After Install

Identify your network card first:

lspci | grep -i network
lspci | grep -i wireless

For Realtek cards:

sudo dnf install -y linux-firmware
sudo reboot

For Intel cards, check:

sudo nmcli device status     # list all network devices
sudo nmcli radio wifi on     # ensure Wi-Fi radio is enabled

Problem: Can't Shrink Windows Enough (Phase 1)

Disable hibernation and the pagefile temporarily. Run in Administrator Command Prompt on Windows:

powercfg /h off

Then retry Disk Management → Shrink Volume.

Problem: "No Space Left" Errors When Installing Packages

Your root partition (/) is full. Check usage:

df -h          # shows partition sizes and usage
du -sh /*      # shows what's consuming space in root

If you used LVM, you can extend the root logical volume using space from another volume — one of the main advantages of LVM over standard partitioning.

Problem: SELinux Blocking an Application

Don't disable SELinux — diagnose it:

sudo ausearch -m avc -ts recent | audit2why          # explains the denial in plain English
sudo ausearch -m avc -ts recent | audit2allow -M myfix  # generates a policy fix
sudo semodule -i myfix.pp                               # applies the fix

Conclusion

Congratulations, you have now completely dual-booted Windows 11 & Rocky Linux on the same physical hardware!

Horizontal Scaling PostgreSQL with Citus: A Practical Deep Dive

William Kwabena Akoto — Wed, 28 Jan 2026 20:45:01 +0000

Introduction

As databases grow beyond the capabilities of a single server, teams face a critical decision: scale vertically by adding more resources to one machine, or scale horizontally by distributing data across multiple servers. While vertical scaling eventually hits physical and economic limits, horizontal scaling offers virtually unlimited growth potential.

In this hands-on guide, we'll explore Citus—an open-source extension that transforms PostgreSQL into a distributed database. We'll build a real Citus cluster from scratch, demonstrate data distribution, implement foreign key relationships across distributed tables, and understand the principles that make horizontal scaling work.

By the end, you'll have practical experience with distributed databases and understand both their power and their limitations.

What is Horizontal Scaling?

Imagine a pizza restaurant with one chef making all the pizzas. During rush hour, orders pile up because one person can only work so fast. This is vertical scaling—you could train the chef to work faster (add more CPU), give them better tools (add more RAM), or expand their workspace (add more storage). But eventually, you hit limits.

Now imagine hiring three chefs, each handling different orders. This is horizontal scaling—you distribute the workload across multiple workers. The more customers you have, the more chefs you can add.

In database terms:

Vertical scaling: Bigger server (more CPU, RAM, storage)
Horizontal scaling: More servers working together

Citus brings horizontal scaling to PostgreSQL by:

Splitting your data across multiple worker nodes (sharding)
Keeping related data together on the same node (co-location)
Maintaining PostgreSQL's ACID guarantees and SQL compatibility

Architecture: Understanding Citus Components

A Citus cluster consists of at least three components:

1. Coordinator Node

The coordinator is like a project manager—it doesn't do the heavy lifting but knows where everything is. When you connect to a Citus cluster, you connect to the coordinator. It:

Routes queries to the appropriate workers
Combines results from multiple workers
Manages distributed transactions
Stores metadata about data distribution

2. Worker Nodes

Workers are the muscle of your cluster—they store the actual data and execute queries. Each worker:

Holds a subset of your data (shards)
Executes queries locally on its data
Communicates with other workers when needed
Functions as a full PostgreSQL instance

3. Shards

Shards are pieces of your distributed tables. Think of them as mini-tables that together form your complete dataset. When you distribute a table:

Citus creates 32 shards by default (configurable)
Shards are distributed across workers
Each row goes to exactly one shard based on a hash function
Related data can be co-located on the same worker

Setting Up a Citus Cluster on Digital Ocean

For this demonstration, we'll create a three-node cluster:

citus-01: Coordinator node
citus-02: Worker 1
citus-03: Worker 2

Step 1: Install PostgreSQL and Citus Extension

On all three droplets:

# Add PostgreSQL repository
sudo apt-get update
sudo apt-get install -y postgresql-common
sudo /usr/share/postgresql-common/pgdg/apt.postgresql.org.sh

# Install PostgreSQL 16
sudo apt-get install -y postgresql-16

# Install Citus extension
curl https://install.citusdata.com/community/deb.sh | sudo bash
sudo apt-get install -y postgresql-16-citus-12.1

# Configure PostgreSQL to load Citus
echo "shared_preload_libraries = 'citus'" | sudo tee -a /etc/postgresql/16/main/postgresql.conf

# Restart PostgreSQL
sudo systemctl restart postgresql

Step 2: Configure Network Access

Edit /etc/postgresql/16/main/postgresql.conf on all nodes:

listen_addresses = '*'

Edit /etc/postgresql/16/main/pg_hba.conf on all nodes to allow connections:

host    all             all             0.0.0.0/0               md5

Restart PostgreSQL:

sudo systemctl restart postgresql

Step 3: Initialize the Coordinator

On the coordinator node (citus-01):

-- Connect as postgres user
sudo -u postgres psql

-- Create the Citus extension
CREATE EXTENSION citus;

-- Add worker nodes to the cluster
SELECT citus_add_node('10.114.0.11', 5432);
SELECT citus_add_node('10.114.0.12', 5432);

-- Verify worker registration
SELECT * FROM citus_get_active_worker_nodes();

You should see both worker nodes listed:

  node_name  | node_port 
-------------+-----------
 10.114.0.11 |      5432
 10.114.0.12 |      5432

Step 4: Initialize Workers

On each worker node (citus-02 and citus-03):

sudo -u postgres psql
CREATE EXTENSION citus;

Your Citus cluster is now operational!

Demonstration 1: Basic Data Distribution

Let's create a simple distributed table and observe how data spreads across workers.

Creating a Distributed Table

-- On the coordinator
CREATE TABLE citus_demo (
    id SERIAL,
    user_name TEXT,
    city TEXT,
    age INT,
    created_at TIMESTAMP DEFAULT NOW()
);

-- Distribute the table by 'id' column
SELECT create_distributed_table('citus_demo', 'id');

The create_distributed_table function tells Citus to:

Create 32 shards (mini-tables) by default
Distribute these shards across available workers
Route future queries based on the distribution column (id)

Inserting Data

INSERT INTO citus_demo (user_name, city, age) VALUES
    ('Alice', 'New York', 25),
    ('Bob', 'Chicago', 30),
    ('Charlie', 'Seattle', 27),
    ('David', 'Boston', 35),
    ('Emma', 'Denver', 22),
    ('Frank', 'Portland', 29),
    ('Grace', 'Miami', 28),
    ('Henry', 'Atlanta', 31),
    ('Iris', 'Phoenix', 26),
    ('Jack', 'Dallas', 33);

Examining Distribution

Check how shards are distributed:

SELECT * FROM citus_shards WHERE table_name::text = 'citus_demo';

Result (abbreviated):

 table_name | shardid |    shard_name     | nodename    | nodeport | shard_size 
------------+---------+-------------------+-------------+----------+------------
 citus_demo |  102488 | citus_demo_102488 | 10.114.0.11 |     5432 |      16384
 citus_demo |  102489 | citus_demo_102489 | 10.114.0.12 |     5432 |      16384
 citus_demo |  102490 | citus_demo_102490 | 10.114.0.11 |     5432 |       8192
 ... (32 shards total)

We see 32 shards split between two workers. Some shards have data (16 KB), others are empty (8 KB).

Understanding Shard Assignment

See which shard each record belongs to:

SELECT id, user_name, city,
       get_shard_id_for_distribution_column('citus_demo', id) as shard_id
FROM citus_demo
ORDER BY id;

Result:

 id | user_name |   city   | shard_id 
----+-----------+----------+----------
  1 | Alice     | New York |   102489
  2 | Bob       | Chicago  |   102512
  3 | Charlie   | Seattle  |   102503
  4 | David     | Boston   |   102496
  5 | Emma      | Denver   |   102494
  6 | Frank     | Portland |   102508
  7 | Grace     | Miami    |   102496
  8 | Henry     | Atlanta  |   102488
  9 | Iris      | Phoenix  |   102516
 10 | Jack      | Dallas   |   102492

Notice that David (id=4) and Grace (id=7) share shard 102496—this happens when their IDs hash to the same shard. With only 10 records across 32 shards, collisions and empty shards are normal.

Viewing Data on Individual Workers

Connect directly to Worker 1 (10.114.0.11):

-- Query a specific shard
SELECT * FROM citus_demo_102488;

Result:

 id | user_name |  city   | age |         created_at         
----+-----------+---------+-----+----------------------------
  8 | Henry     | Atlanta |  31 | 2026-01-23 22:42:50.523619

Worker 1 only stores the data in its shards. Query other shards on this worker:

SELECT * FROM citus_demo_102512;  -- Bob
SELECT * FROM citus_demo_102496;  -- David and Grace

Connect to Worker 2 (10.114.0.12) and query:

SELECT * FROM citus_demo_102489;  -- Alice
SELECT * FROM citus_demo_102503;  -- Charlie

Key insight: Each worker only stores a subset of the data. When you query the main table through the coordinator, Citus automatically fetches data from all workers and combines the results.

Demonstration 2: Foreign Keys and Co-location

One of the biggest challenges in distributed databases is maintaining relationships between tables. Let's explore how Citus handles foreign keys through co-location.

The Challenge

Imagine you have users and their orders:

Users table: Alice, Bob, Charlie
Orders table: Order 1 (Alice's pizza), Order 2 (Bob's burger), Order 3 (Alice's soda)

In a distributed setup, what if:

Alice's user record is on Worker 1
Alice's orders are on Worker 2

When inserting an order for Alice, Worker 2 must verify Alice exists—but Alice is on Worker 1! This requires expensive cross-node communication for every foreign key check.

The Solution: Co-location

Co-location ensures related data lives on the same worker. Citus achieves this by distributing both tables using the same column.

Creating Co-located Tables

-- Create users table
CREATE TABLE users (
    user_id INT PRIMARY KEY, 
    name TEXT
);

-- Create orders table with composite primary key
CREATE TABLE orders (
    order_id SERIAL,
    user_id INT,
    item TEXT,
    created_at TIMESTAMP DEFAULT NOW(),
    PRIMARY KEY (order_id, user_id)  -- Must include distribution column
);

-- Distribute both tables by user_id
SELECT create_distributed_table('users', 'user_id');
SELECT create_distributed_table('orders', 'user_id');

-- Add foreign key constraint
ALTER TABLE orders 
ADD CONSTRAINT fk_user 
FOREIGN KEY (user_id) REFERENCES users(user_id);

Important: The orders primary key includes user_id because Citus requires the distribution column in unique constraints. This ensures uniqueness can be verified locally on each worker.

Inserting Related Data

INSERT INTO users (user_id, name) VALUES
    (1, 'Alice'),
    (2, 'Bob'),
    (3, 'Charlie'),
    (4, 'David'),
    (5, 'Emma');

INSERT INTO orders (user_id, item) VALUES
    (1, 'Pizza'),
    (1, 'Soda'),
    (1, 'Ice Cream'),
    (2, 'Burger'),
    (2, 'Fries'),
    (3, 'Taco'),
    (3, 'Burrito'),
    (3, 'Nachos'),
    (4, 'Pasta'),
    (5, 'Salad');

Verifying Co-location

Check which shards contain user and order data:

SELECT 
    u.user_id,
    u.name,
    o.item,
    get_shard_id_for_distribution_column('users', u.user_id) as user_shard,
    get_shard_id_for_distribution_column('orders', o.user_id) as order_shard
FROM users u
JOIN orders o ON u.user_id = o.user_id
ORDER BY u.user_id, o.order_id;

Result:

 user_id |  name   |   item    | user_shard | order_shard 
---------+---------+-----------+------------+-------------
       1 | Alice   | Pizza     |     102521 |      102553
       1 | Alice   | Soda      |     102521 |      102553
       1 | Alice   | Ice Cream |     102521 |      102553
       2 | Bob     | Burger    |     102544 |      102576
       2 | Bob     | Fries     |     102544 |      102576
       3 | Charlie | Taco      |     102535 |      102567
       3 | Charlie | Burrito   |     102535 |      102567
       3 | Charlie | Nachos    |     102535 |      102567

Wait, the shard IDs are different! This might seem wrong, but it's actually correct.

Understanding Different Shard IDs

The users table has its own set of shards (102521, 102544, 102535...), and the orders table has different shard IDs (102553, 102576, 102567...). However, what matters is that they're on the same physical worker node.

Verify this:

SELECT 
    table_name,
    shardid,
    nodename
FROM citus_shards 
WHERE shardid IN (102521, 102553)  -- Alice's user and order shards
ORDER BY nodename, table_name;

Result:

 table_name | shardid |  nodename   
------------+---------+-------------
 orders     |  102553 | 10.114.0.11
 users      |  102521 | 10.114.0.11

Both shards are on Worker 1 (10.114.0.11)! This is co-location—different shard tables, same physical location.

Think of it like two filing cabinets (users and orders) in the same office. Even though they're separate cabinets with different drawer labels, they're in the same room, so finding related information is instant.

Testing Foreign Key Constraints

Try inserting an order for a non-existent user:

INSERT INTO orders (user_id, item) VALUES (999, 'Ghost Pizza');

Error:

ERROR:  insert or update on table "orders" violates foreign key constraint "orders_user_id_fkey"
DETAIL:  Key (user_id)=(999) is not present in table "users".

Perfect! The foreign key constraint works. Because user_id=999 doesn't exist, and thanks to co-location, the worker can check this locally without network calls to other workers.

Performing JOINs

Count orders per user:

SELECT 
    u.user_id, 
    u.name, 
    COUNT(o.order_id) as num_orders
FROM users u
LEFT JOIN orders o ON u.user_id = o.user_id
GROUP BY u.user_id, u.name
ORDER BY u.user_id;

Result:

 user_id |  name   | num_orders 
---------+---------+------------
       1 | Alice   |          3
       2 | Bob     |          2
       3 | Charlie |          3
       4 | David   |          1
       5 | Emma    |          1

This JOIN is fast because each worker can join its local user and order data without coordinating with other workers. This is the power of co-location.

Key Concepts and Best Practices

1. Distribution Column Selection

Choose your distribution column carefully:

Good choices:

user_id for multi-tenant applications (each tenant's data together)
account_id for SaaS applications
customer_id for e-commerce

Bad choices:

created_at (causes temporal hotspots)
Low-cardinality columns (poor distribution)
Columns that change frequently

Rule of thumb: Pick a column that:

Appears in most queries (for query efficiency)
Enables co-location of related tables
Has high cardinality (many unique values)
Remains stable (doesn't change)

2. Co-location Requirements

For foreign keys to work across distributed tables:

Same distribution column: Both parent and child tables must be distributed by the same column
Include in constraints: The distribution column must be part of PRIMARY KEY and UNIQUE constraints
Foreign key on distribution column: The foreign key must reference the distribution column

3. Shard Count

Default: 32 shards per table

Too few shards: Limits parallelism and future scalability
Too many shards: Increases metadata overhead and query planning time

For most applications, 32-128 shards works well. Adjust based on:

Expected data size
Number of workers (more workers = more shards beneficial)
Query patterns

4. When to Use Citus

Good use cases:

Multi-tenant SaaS applications
Real-time analytics on time-series data
High-throughput transactional workloads
Applications that exceed single-server capacity
Workloads with natural sharding keys

Not ideal for:

Small databases (< 100GB)
Workloads requiring many cross-shard JOINs
Applications with no clear distribution key
Use cases where a single PostgreSQL instance suffices

Performance Considerations

Query Routing

Citus routes queries differently based on their scope:

1. Single-shard queries (fastest):

-- Routed to one worker because user_id=1 uniquely determines shard
SELECT * FROM orders WHERE user_id = 1;

2. Co-located JOINs (fast):

-- Each worker joins its local data, then results are combined
SELECT u.name, COUNT(o.*)
FROM users u
JOIN orders o ON u.user_id = o.user_id
GROUP BY u.name;

3. Broadcast queries (slower):

-- Must query all shards and combine results
SELECT * FROM orders WHERE item = 'Pizza';

4. Cross-shard queries (slowest):

-- Requires moving data between workers
SELECT o.item, p.product_name
FROM orders o
JOIN products p ON o.product_id = p.id
WHERE o.user_id = 1;
-- Only works if products is a reference table or co-located

Reference Tables

For small lookup tables (countries, products, categories), use reference tables:

CREATE TABLE countries (
    code CHAR(2) PRIMARY KEY,
    name TEXT
);

-- Replicate to all workers
SELECT create_reference_table('countries');

Reference tables are fully replicated to every worker, enabling efficient JOINs with distributed tables.

Monitoring and Maintenance

Checking Cluster Health

-- View active workers
SELECT * FROM citus_get_active_worker_nodes();

-- Check shard distribution
SELECT nodename, COUNT(*) as shard_count
FROM citus_shards
GROUP BY nodename;

-- Monitor distributed queries
SELECT * FROM citus_stat_statements;

-- Check replication lag (if using HA setup)
SELECT * FROM citus_replication_status();

Rebalancing Shards

As you add workers, rebalance shards:

-- Move shards to balance load
SELECT citus_rebalance_start();

-- Check rebalance progress
SELECT * FROM citus_rebalance_status();

Conclusion

We've successfully demonstrated horizontal scaling with Citus by:

Building a distributed cluster with one coordinator and two workers
Creating distributed tables and observing how data spreads across shards
Implementing foreign key relationships through co-location
Verifying co-location by checking that related data resides on the same workers
Testing foreign key constraints to ensure data integrity
Performing distributed JOINs that execute efficiently due to co-location

Citus transforms PostgreSQL into a horizontally scalable database while maintaining SQL compatibility and ACID guarantees. By distributing data intelligently and co-locating related tables, it achieves impressive performance even as datasets grow beyond single-server capacity.

The Elephant in the Room: Single Points of Failure

However, our current setup has a critical limitation: every node is a single point of failure.

Consider these scenarios:

Coordinator failure: If citus-01 goes down, your entire application stops. No queries can be routed, no data can be accessed, even though workers are healthy.
Worker failure: If citus-02 crashes, all data on that worker becomes unavailable. Half your users suddenly can't access their orders.
Maintenance downtime: Need to apply a security patch? You'll have to take the coordinator offline, causing application downtime.

In production environments, single points of failure are unacceptable. Your database must survive:

Hardware failures
Network issues
Planned maintenance
Software crashes
Data center outages

What's Next: High Availability with Patroni

In our next article, we'll solve these availability challenges by integrating Patroni—an open-source high availability solution for PostgreSQL. We'll transform our vulnerable single-node cluster into a highly available system:

Architecture we'll build:

Coordinator cluster: Primary + Standby (automatic failover)
Worker 1 cluster: Primary + Standby
Worker 2 cluster: Primary + Standby
etcd cluster: Distributed consensus for leader election

What you'll learn:

Setting up Patroni with etcd for distributed consensus
Configuring automatic failover for coordinators and workers
Testing failure scenarios (simulating crashes)
Monitoring cluster health and replication lag
Performing switchovers for maintenance
Understanding trade-offs between availability and consistency

By combining Citus's horizontal scalability with Patroni's high availability, you'll have a production-ready distributed database that can:

Scale to billions of rows
Handle millions of queries per second
Survive node failures automatically
Support zero-downtime maintenance
Provide strong consistency guarantees

Stay tuned for "High Availability for Citus: Implementing Automatic Failover with Patroni" where we'll make this scalable database truly resilient.

Resources

Citus Documentation: https://docs.citusdata.com
Citus GitHub: https://github.com/citusdata/citus
PostgreSQL Documentation: https://www.postgresql.org/docs/
Digital Ocean Citus Tutorial: https://docs.digitalocean.com/products/databases/postgresql/

Special thanks to the Citus team for building such an elegant distributed database solution.

Implementing Identity and Access Management (IAM) on Jenkins Using the Role-Based Strategy Plugin

William Kwabena Akoto — Sat, 01 Nov 2025 14:21:39 +0000

Introduction

In modern DevOps environments, security and governance are just as important as speed and automation. As organizations increasingly rely on Jenkins to manage continuous integration and delivery (CI/CD) pipelines, ensuring that users have the right level of access becomes crucial.

Unrestricted or poorly managed access can lead to serious issues, from accidental job deletions and credential leaks to unauthorized configuration changes that impact production systems. To prevent this, Jenkins offers a powerful mechanism for implementing Identity and Access Management (IAM) using the Role-Based Strategy Plugin.

This article explains how to design and implement a robust IAM model in Jenkins using the Role-Based Strategy Plugin, ensuring secure, efficient, and auditable control over who can view, build, or manage various Jenkins resources.

Understanding Identity and Access Management in Jenkins

Identity and Access Management (IAM) in Jenkins revolves around defining who the users are and what actions they are allowed to perform. In practice, this means:

Identity management — creating and managing user accounts (locally or through external systems like LDAP or SSO).
Access management — granting specific permissions that define what each user can see or do within Jenkins.

By combining these two concepts, administrators can enforce the principle of least privilege — giving users only the permissions they need to perform their roles.

Why Use the Role-Based Strategy Plugin?

Out of the box, Jenkins provides basic authorization modes such as “Matrix-based security” or “Logged-in users can do anything.” However, these options lack flexibility and scalability for organizations with multiple teams, roles, and environments.

The Role-Based Strategy Plugin enhances Jenkins’ native capabilities by allowing administrators to:

Define custom roles (e.g., Administrator, Developer, DevOps).
Assign granular permissions at global, project, or agent levels.
Manage access dynamically as teams grow or responsibilities shift.

In essence, the plugin provides a structured IAM framework that simplifies user management and strengthens Jenkins’ security posture.

Prerequisites

Before you begin, ensure that:

Jenkins is installed and accessible.
You have Administrator privileges on the Jenkins instance.
Jenkins uses the “Jenkins’ own user database” for managing local users (default setup).

Enable Local User Management

To set up local identity management:

Navigate to Manage Jenkins, Click on Configure Global Security.
Under Security Realm, select Jenkins’ own user database.
Enable Allow users to sign up if you want self-registration(Optional)
Click Save.

You can also create users manually via Manage Jenkins ,Click on Manage Users and then Create User.

This ensures that each identity is stored locally within Jenkins, forming the foundation for IAM.

Install the Role-Based Strategy Plugin

To enable fine-grained access control:

Go to Manage Jenkins, Click on Plugins and Choose Available Plugins.
Search for Role-based Strategy.
Select it and click Install without restart.
Restart Jenkins if prompted.

Once installed, this plugin allows you to define roles and assign permissions across the Jenkins environment.

Enable Role-Based Authorization

After installation:

Navigate to Manage Jenkins, Click on Configure Global Security.
Under Authorization, select Role-Based Strategy.
Click Save.

Your Jenkins instance will now use a role-based authorization model, allowing you to define and control permissions systematically.

Define Roles

Go to Manage Jenkins, Click on Manage and Assign Roles then choose Manage Roles.

Here, you can define three types of roles:

Global roles – apply across the entire Jenkins instance.
Project roles – apply to specific jobs or folders.
Agent roles – apply to particular build agents (nodes).

In this article, we’ll focus on global roles to define access boundaries for all users because they easy are to understand and use. Below are examples of roles to define and use:

Administrator Role

The Administrator role represents users with complete control over the Jenkins environment.
These users can manage all aspects of the system, including global configuration, plugin management, nodes, credentials, and user permissions.

Typical permissions include:

Overall/Administer — grants unrestricted access across Jenkins.
Ability to install or remove plugins.
Configuration of security, nodes, and system settings.
Management of users, credentials, and roles.

Administrators are responsible for maintaining system stability, enforcing security policies, and overseeing the overall Jenkins infrastructure.

Developer Role

The Developer role is designed for users who actively build and test software projects but should not have access to system-level configurations.
This role focuses on enabling developers to work efficiently within their pipelines while maintaining system security and consistency.

Common permissions include:

Overall/Read — allows visibility into Jenkins and its resources.
Job/Build, Job/Read, Job/Discover — enables users to trigger and monitor builds.
SCM/Read, SCM/Tag — provides access to integrated source control systems.
Run/Delete, Run/Replay — allows management of build executions.
View/Read — grants access to dashboards and views.

Developers can create, view, and execute jobs as part of their CI/CD process, but cannot alter Jenkins configurations or credentials.

DevOps Engineer Role

The DevOps Engineer role is intended for users who manage and optimize CI/CD workflows, pipelines, and build environments.
This role strikes a balance between operational control and security, granting permissions to configure pipelines and credentials without granting full administrative rights.

Typical permissions include:

Overall/Read — provides general visibility across Jenkins.
Credentials/Create, Update, Delete — allows secure management of tokens, keys, and secrets.
Job/Build, Job/Create, Job/Configure, Job/Delete, Job/Read — enables users to manage and maintain build jobs and pipelines.
SCM/Read, SCM/Tag — supports source control operations.
Metrics/View — provides access to monitoring and performance insights.

DevOps engineers are responsible for maintaining build automation, pipeline reliability, and integration with external tools,thus, ensuring continuous delivery processes run smoothly while adhering to security boundaries.

Assign Roles to Users

Once roles are defined, assign them to specific users:

Navigate to Manage Jenkins, Click on Manage and Assign Roles then Assign Roles.
Choose the Global Roles tab.
Enter each username (exactly as created under “Manage Users”).
Check the boxes corresponding to the roles you want to assign.
Click Save.

Users now have access strictly within the limits of their assigned roles — enforcing identity-based access control.

Benefits of Role-Based IAM in Jenkins

Implementing IAM using the Role-Based Strategy Plugin offers multiple benefits:

Enhanced Security — Limits exposure by granting the least privileges necessary.
Operational Governance — Ensures every action is traceable to an authorized role.
Scalability — New users can be onboarded simply by assigning predefined roles.
Accountability — Clear role definitions make auditing and troubleshooting easier.
Simplified Administration — Reduces the complexity of managing large user bases.

Conclusion

By integrating the Role-Based Strategy Plugin with Jenkins’ built-in user management, administrators can achieve a strong, flexible, and scalable Identity and Access Management (IAM) framework.

This approach not only protects critical CI/CD operations but also promotes a culture of secure collaboration. Each user operates within defined boundaries,thus,administrators maintain full control, developers focus on delivery, and DevOps engineers manage automation securely.

In essence, implementing IAM on Jenkins using role-based authorization transforms a simple CI/CD tool into a secure, compliant, and enterprise-ready automation platform. It enforces security best practices such as least privilege, transparency, and centralized control — key pillars of modern DevSecOps.

How to Install and Configure Apache Guacamole on a Linux Server

William Kwabena Akoto — Sat, 18 Oct 2025 11:58:50 +0000

This guide explains how to install and configure Apache Guacamole on a test server using Docker Compose. The steps are simple and suitable for both beginners and experienced administrators.

What You Will Need

Before you start, make sure you have:

A Linux server
Sudo or root privileges
Docker and Docker Compose

Step 1: Create the Guacamole Directory

We’ll store all files related to Guacamole in one location. Create the following directories on your server:

sudo mkdir -p /your-desired-folder/guacamole/data/mysql

The final directory structure should look like this:

/your-desired-folder/guacamole
├── data
│   └── mysql/
├── docker-compose.yml
└── initdb.sql

The data directory will store Guacamole’s configuration and data.
The data/mysql directory will hold the MySQL database files.
The initdb.sql file will be used to initialize the database.
The docker-compose.yml file will define how all the services work together.

Step 2: Create the Docker Compose File

Open a new file called /your-desired-folder/guacamole/docker-compose.yml and add the following content:

version: "3"
services:
  guacamole:
    image: guacamole/guacamole
    container_name: guacamole
    restart: always
    depends_on:
      - guacd
      - mysql
    ports:
      - "your-desired-port:8080"
    environment:
      GUACD_HOSTNAME: guacd
      MYSQL_HOSTNAME: mysql
      MYSQL_DATABASE: guacamole_db
      MYSQL_USER: guacuser
      MYSQL_PASSWORD: guacpass
    volumes:
      - /your-desired-folder/guacamole/data:/app/data

  guacd:
    image: guacamole/guacd
    container_name: guacd
    restart: always

  mysql:
    image: mysql:8.0
    container_name: mysql
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: rootpass
      MYSQL_DATABASE: guacamole_db
      MYSQL_USER: guacuser
      MYSQL_PASSWORD: guacpass
    volumes:
      - /your-desired-folder/guacamole/data/mysql:/var/lib/mysql
      - /your-desired-folder/guacamole:/script

This file defines three main services:

guacamole – The main web application.
guacd – The Guacamole proxy daemon.
mysql – The database that stores user accounts, connection settings, and history.

Step 3: Understand the Directory Mappings

Each service in the Docker Compose file uses volumes to map directories from your host machine to the containers. This keeps your data safe even if containers are stopped or recreated.

The first mapping connects the directory /your-desired-folder/guacamole/data on the host to /app/data inside the Guacamole container. This is where Guacamole stores its configuration files and runtime data. By keeping this data on the host, it remains safe even if the container is recreated or updated.

The second mapping connects /your-desired-folder/guacamole/data/mysql on the host to /var/lib/mysql inside the MySQL container. This directory is where MySQL keeps all of its database files, such as user information, connection details, and history. Storing the database on the host ensures that all your Guacamole settings and accounts are preserved even after a restart.

The third mapping links /your-desired-folder/guacamole on the host to /script inside the MySQL container. This is mainly used to share files between the host and the database container, especially during the initial setup. For example, you can place the initdb.sql file here and use it to initialize the Guacamole database schema.

Together, these mappings make the setup reliable and persistent, ensuring you don’t lose data or configuration when updating or restarting the containers.

How It Connects Visually

Host: /your-desired-folder/guacamole
│
├── data ---------------------> [guacamole:/app/data]
├── data/mysql ---------------> [mysql:/var/lib/mysql]
└── initdb.sql (via /script) -> [mysql:/script/initdb.sql]

Step 4: Start the Containers & Initialize the Database

Now you can start Guacamole with Docker Compose:

cd /your-desired-folder/guacamole
docker-compose up -d

To confirm that all containers are running, use:

docker ps

You should see three running containers: guacamole, guacd, and mysql.

Run the following command to generate the schema file:

docker run --rm guacamole/guacamole /opt/guacamole/bin/initdb.sh --mysql > /your-desired-folder/guacamole/initdb.sql

Next, import the schema into the MySQL container:

docker cp /your-desired-folder/guacamole/initdb.sql mysql:/initdb.sql
docker exec -it mysql bash -c "mysql -u root -p rootpass guacamole_db < /initdb.sql"

This creates all the necessary tables and relationships for Guacamole to work properly.

Step 5: Checking Logs and Troubleshooting

If something doesn’t work as expected, you can view the container logs:

docker logs guacamole
docker logs guacd
docker logs mysql

Step 6: Access the Web Interface

Open your web browser and go to:

http://your-server-ip:8080/guacamole

You will see the Guacamole login page.

Default credentials:

Username: guacadmin
Password: guacadmin

After logging in for the first time, you should change this password immediately.

Step 7: Configure Remote Connections

Once you are logged in:

Click Settings in the top-right corner.
Go to the Connections tab.
Click New Connection to add an SSH, RDP, or VNC connection.
Enter the details for the remote host you want to access.

Guacamole will connect through your browser, and you’ll be able to control remote systems directly without extra software.

Step 9: Secure the Deployment

For a test environment, running Guacamole on your desired port is fine.
However, in production, it’s recommended to:

Set up an Nginx reverse proxy in front of Guacamole.
Enable HTTPS using Let’s Encrypt or another SSL provider.
Limit access through your firewall (allow only necessary ports).

This ensures that your remote desktop connections remain encrypted and secure.

Conclusion

You’ve now set up and configured Apache Guacamole using Docker Compose. With this setup, you can easily access and manage remote servers through a browser without any additional client software.

By following these steps, you have a clean, organized, and reproducible deployment that can easily be moved from a test to a production environment.

How To Deploy Uptime Kuma On A Linux Server With Docker Compose

William Kwabena Akoto — Thu, 02 Oct 2025 18:27:43 +0000

Introduction

Uptime Kuma is an open-source, self-hosted monitoring tool. It helps you track the uptime, response time, and availability of your websites, APIs, servers, and other network resources.

In this tutorial, I’ll walk through deploying Uptime Kuma using Docker Compose with persistent storage, making it easy to set up and manage.

Prerequisites

Before starting, ensure you have:

A Linux server (Ubuntu, Debian, CentOS, etc.)
Docker installed
Docker Compose installed

Directory Setup

We’ll keep all Uptime Kuma files under /your-desired-folder/uptime-kuma.

sudo mkdir -p /your-desired-folder/uptime-kuma/data
cd /your-desired-folder/uptime-kuma

Directory structure:

/your-desired-folder/
└── uptime-kuma/
    ├── data/                  
    └── docker-compose.yml

Docker Compose File

Create a docker-compose.yml inside /your-desired-folder/uptime-kuma:

version: '3.8'

services:
  uptime-kuma:
    image: louislam/uptime-kuma
    container_name: uptime-kuma
    volumes:
      - /your-desired-folder/uptime-kuma/data:/app/data
    ports:
      - "your-desired-port:3001"
    restart: always

Explanation

image: louislam/uptime-kuma → Uses the official Uptime Kuma Docker image.
container_name → Assigns a fixed container name for easy management.
volumes → Maps /your-desired-folder/uptime-kuma/data (host) → /app/data (container) for persistent storage.
ports: "your-desired-port:3001" → Exposes Kuma’s web UI on port your-desired-port of the host.
- Access via: http://<your-server-ip>:your-desired-port
restart: always → Automatically restarts if the container stops or after a server reboot.

Deploy Uptime Kuma

Run:

docker-compose up -d

Check container status:

docker ps

View logs:

docker logs -f uptime-kuma

Accessing the Dashboard

Once the container is running, open a browser and visit:

http://<your-server-ip>:your-desired-port

On first launch, you’ll be prompted to create an admin account.

Managing Uptime Kuma

Start service

  docker-compose up -d

Stop service

  docker-compose down

Update to latest version

  docker-compose pull
  docker-compose up -d

Best Practices

Use an NGINX reverse proxy with Let’s Encrypt for HTTPS instead of exposing Uptime Kuma directly on port your-desired-port.
Regularly back up /your-desired-folder/uptime-kuma/data to avoid losing configs and monitoring history.
Restrict access via firewall if your server is exposed to the internet.

Conclusion

You now have Uptime Kuma running with Docker Compose. With this setup, you can monitor your infrastructure and services easily, while keeping everything self-hosted and under your control.

Forem: William Kwabena Akoto

Dual-Booting Windows 11 & Rocky Linux — A Beginner's Complete Guide

Table of Contents

1. What Is Dual-Booting and Why Rocky Linux?

2. Key Concepts You Must Understand First

UEFI, BIOS, and Secure Boot

Partitions, File Systems, and GPT

The GRUB Bootloader

3. Before You Begin — Checklist

Check 1 — CPU Compatibility

Check 2 — Disable Windows Fast Startup

Check 3 — Free Disk Space

Check 4 — A 16 GB+ USB Drive

Check 5 — Stable Power

Phase 1 — Shrink Your Windows Partition

How Much Space to Allocate?

Phase 2 — Download & Flash Rocky Linux

Step 2.1 — Download the ISO

Step 2.2 — Verify the ISO (Don't Skip This)

Step 2.3 — Flash the USB Drive with Rufus

Phase 3 — Configure the HP BIOS

Phase 4 — Boot the Rocky Linux Installer

Phase 5 — Anaconda Installer Walkthrough

Time & Date

Software Selection

Installation Destination — Partitioning (Most Critical Step)

Partitioning Scheme: Standard vs LVM

Creating the Partitions

Review & Accept Changes

Network & Hostname

Root Account & User Creation

Begin Installation

Phase 6 — First Boot & the GRUB Menu

Phase 7 — Post-Install DevOps Setup

Step 7.1 — Full System Update

Step 7.2 — Enable EPEL Repository

Step 7.3 — Understand SELinux (Don't Disable It)

Step 7.4 — Understand firewalld

Troubleshooting Common Problems

Problem: Windows Boots Directly (No GRUB Menu)

Problem: Windows Missing from GRUB Menu

Problem: Wi-Fi Doesn't Work After Install

Problem: Can't Shrink Windows Enough (Phase 1)

Problem: "No Space Left" Errors When Installing Packages

Problem: SELinux Blocking an Application

Conclusion

Horizontal Scaling PostgreSQL with Citus: A Practical Deep Dive

Introduction

What is Horizontal Scaling?

Architecture: Understanding Citus Components

1. Coordinator Node

2. Worker Nodes

3. Shards

Setting Up a Citus Cluster on Digital Ocean

Step 1: Install PostgreSQL and Citus Extension

Step 2: Configure Network Access

Step 3: Initialize the Coordinator

Step 4: Initialize Workers

Demonstration 1: Basic Data Distribution

Creating a Distributed Table

Inserting Data

Examining Distribution

Understanding Shard Assignment

Viewing Data on Individual Workers

Demonstration 2: Foreign Keys and Co-location

The Challenge

The Solution: Co-location

Creating Co-located Tables

Inserting Related Data

Verifying Co-location

Understanding Different Shard IDs

Testing Foreign Key Constraints

Performing JOINs

Key Concepts and Best Practices

1. Distribution Column Selection

2. Co-location Requirements

3. Shard Count

4. When to Use Citus

Performance Considerations

Query Routing