DEV Community: Morodolu Oluwafikunayomi

I recently completed a hands-on project with Veeam Backup & Replication, taking it from initial installation and configuration to automated, monitored backups. I'd appreciate any feedback from fellow SysAdmins, Infrastructure Engineers, and DevOps

Morodolu Oluwafikunayomi — Tue, 15 Sep 2026 11:41:32 +0000

Morodolu Oluwafikunayomi

Sep 8

My Veeam Backup & Replication Project — From Trial Download to Monitored Backups (and an ESXi Bonus Round)

#veeam #backup #sysadmin #infrastructure

20 min read

My Veeam Backup & Replication Project — From Trial Download to Monitored Backups (and an ESXi Bonus Round)

Morodolu Oluwafikunayomi — Tue, 08 Sep 2026 18:01:44 +0000

A beginner-friendly, hands-on walkthrough of standing up Veeam Backup & Replication end to end on a single lab server — concepts, trial setup, agent vs agentless, protection groups, the LVM snapshot error that broke my first job, firewall gotchas, restore testing, Veeam ONE monitoring and alarms, and a bonus ESXi VM-backup phase.

My Veeam Backup & Replication Project — From Trial Download to Monitored Backups

As part of my infrastructure showcase , I was given a fairly open-ended task: stand up Veeam Backup & Replication (VBR) from scratch and get a working, monitored backup environment running. No prior Veeam experience, no existing lab — just a blank slate and the trial edition.

The lab ended up looking like this:

1 Windows Server doing triple duty as the Veeam Backup Server, the Backup Repository, and the Veeam ONE monitoring host — all on one ~700GB box
4 Linux clients (RHEL/Rocky/AlmaLinux) backed up with the Veeam Agent for Linux
Later, a VMware ESXi host added on top, to get hands-on with agentless VM-level backup too

This post documents the whole journey: what backup actually means and why it matters, how I got Veeam onto a test box, the agent vs. agentless decision, setting up protection groups (including the firewall issue that broke it), the LVM snapshot error that forced a change of backup mode, restore testing, reporting, Veeam ONE monitoring with alarms, and finally a bonus phase connecting a licensed ESXi host for VM backup and restore.

Why backup even matters

Before touching any software, it's worth being clear on why this whole exercise exists.

A backup is simply a copy of your data (and sometimes your entire system) stored somewhere separate from the original, so that if something goes wrong — hardware failure, accidental deletion, ransomware, a bad update, a full server dying — you can restore and keep operating instead of losing everything.

The classic argument for backup boils down to a few failure scenarios that happen to everyone eventually:

Hardware failure — disks die, servers crash, and RAID isn't a backup strategy on its own.
Human error — someone deletes the wrong folder, overwrites the wrong file, or fat-fingers a config change.
Ransomware/malware — increasingly the #1 reason organizations lose data they can't get back, especially if backups themselves aren't protected.
Software or update failures — a bad patch or corrupted database that isn't caught immediately.

Without backups, any one of these can mean permanent data loss. With backups — and, just as importantly, tested backups — the same event becomes a recovery task measured in minutes or hours instead of a catastrophe.

Veeam is one of the major players in this space, offering both backup and replication (keeping a warm standby copy of a VM ready to fail over to) for physical machines, virtual machines, and cloud workloads.

Getting Veeam: creating an account and downloading the trial

Veeam doesn't let you just grab an installer anonymously — you need an account first:

Head to veeam.com and register for a free account (this doubles as your Veeam ID, used for licensing and support).
Once registered, I could access the download center and grab the Veeam Backup & Replication installer. Community Edition is free and fine for a basic/proof-of-concept setup — it supports up to 10 workloads free — but registering also auto-activates a 30-day trial license, which unlocks the full enterprise feature set so you can evaluate everything before deciding what to license.

This trial license is also why, near the end of this project, I started seeing expiry warnings pop up in the console — more on that later.

Prerequisites checklist (worth confirming before you start)

Local administrator credentials on the Windows server; root or a sudo-capable account (with SSH access) on the Linux clients
.NET Framework and Windows updates current on the server (both the VBR and Veeam ONE installers will flag anything missing)
The Windows server should comfortably clear Veeam ONE's minimums on top of running VBR: 4 CPU cores, 8GB RAM, 5GB free disk, in addition to whatever VBR itself needs
Enough free disk space confirmed on the storage volume (leave some headroom, don't plan to fill it to 100%)
SSH enabled and reachable on each Linux client — VBR connects to Linux machines over SSH, not WinRM
Each client's OS major version checked ahead of time (cat /etc/os-release) — the offline install package is version-specific (el7/el8/el9/el10)
A machine with internet access to download the veeam-libs and veeam-nosnap offline install packages, since the clients themselves have no direct internet access
Network connectivity confirmed between the server and each client
Veeam ONE installer downloaded, matching the VBR version

A resource constraint worth mentioning: no separate storage

In a "proper" production Veeam deployment, you'd typically keep the backup server (the brains — job scheduling, configuration database, console) separate from the backup repository (the actual storage where backup files live), and often separate again from backup proxies that handle the data movement, and from the monitoring host. This separation is best practice because it avoids a single point of failure — if your backup server dies, your backup data is still intact elsewhere.

I didn't have that luxury for this project. With limited lab resources, I installed VBR, the backup repository, and Veeam ONE all on the same box. It's a deliberate single-point-of-failure design: if that Windows server goes down, backups and monitoring both stop at the same time. It's not how you'd want to run this in production, but it was enough to prove out the workflow — and it's worth flagging clearly here rather than glossing over it.

Agent-based vs. agentless backup

One of the first real decisions in Veeam is how it's going to reach into a machine to actually back it up. There are two fundamentally different approaches:

Agentless backup

Veeam talks directly to the hypervisor (VMware vSphere, Microsoft Hyper-V, Nutanix AHV, etc.) and uses its snapshot APIs to capture a consistent image of the VM — no software needs to be installed inside the guest OS at all. This is generally the preferred approach for virtualized workloads because it's less invasive, easier to manage at scale, and doesn't add any agent overhead inside the VM.

Agent-based backup

Veeam installs a small backup agent directly inside the machine's operating system (Windows or Linux). The agent talks to the guest OS at the file-system/volume level to do the backup. This is the only real option for:

Physical (bare-metal) servers and workstations that aren't virtualized at all
Machines running on hypervisors Veeam doesn't have agentless integration with
Machines that are often offline or unreachable (laptops, remote/branch office servers) — agent-based jobs are typically managed as policies that run locally rather than being triggered by a central server
Cases where you need guest-level granularity the hypervisor snapshot alone can't give you

For my project, I started with the agent-based side — 4 Linux servers — and later added a licensed VMware ESXi host to get hands-on with agentless, hypervisor-level backup too.

Step 1 — Install Veeam Backup & Replication on the server

Log into the server with a local administrator account.
Run the VBR installer.
When prompted for the configuration database, accept the default — the installer sets up a local PostgreSQL instance automatically. You don't need a separate SQL Server for a basic setup like this.
Let the installer also set up the local components it installs by default: the Backup Server service, the local Data Mover, and the console.
Once installation finishes, open the Veeam Backup & Replication Console and confirm it connects without errors. This is your central control point for everything from here on.

Step 2 — Add the local storage as a Backup Repository

In the console, go to Backup Infrastructure → Repositories.
Right-click → Add Repository.
Choose Direct attached storage → Microsoft Windows server (since the repository is the same local server).
Select the server itself as the location, and point it to the volume/folder where backup files should be stored.
Finish the wizard, and confirm the repository shows up with its available capacity matching what you expect.

Step 3 — Install Veeam Agent for Linux (offline/nosnap method) on each client

The clients don't have direct internet access, so this uses Veeam's offline (nosnap) install — download the packages on a machine that does have internet, copy them over via SCP, then install locally. Since the clients are RHEL/Rocky/AlmaLinux, this uses .rpm packages, and there are two of them — order matters: veeam-libs (shared dependencies) has to go in before veeam-nosnap (the actual agent).

Check each client's OS version first, since the package is version-specific (el7/el8/el9/el10):

   cat /etc/os-release

Note the version for each client — they may not all match.

On a machine with internet access, download both files for the matching version from Veeam's software repository. For version 9 clients, for example:
- veeam-libs-13.1.0.252-1.x86_64.rpm
- veeam-nosnap-13.1.0.252-1.el9.x86_64.rpm

(the el9/el8/el7/el10 in the filename must match each client's actual version — using the wrong one is the most common failure here)

Copy both files onto each client using SCP:

   scp "<local-file-path>" <username>@<client-ip>:<destination-folder>

Note the colon after the IP — it tells SCP where on the remote machine to put the file. You'll be prompted to accept the SSH fingerprint the first time (yes), then enter the account password. Repeat for each client, swapping the IP.

On each client, install the libs package first, then the agent package, matching the version confirmed in step 1:

   sudo rpm -i /tmp/veeam-libs-13.1.0.252-1.x86_64.rpm
   sudo rpm -i /tmp/veeam-nosnap-13.1.0.252-1.el9.x86_64.rpm

Confirm the agent installed and is running:

   sudo systemctl status veeamservice

No local job needs to be configured on the client itself — like the Windows flow, this gets added and managed centrally from the backup server in the next step, as long as it's set up in "managed by backup server" mode.

What is a Protection Group, and why do you need one?

For the agent-based side of things, Veeam organizes target machines using Protection Groups.

A protection group is essentially a dynamic (or static) list of computers that should be protected with agent-based backups. Instead of manually adding machines to a backup job one by one — and having to remember to add every new server that shows up — a protection group defines the scope (individual computers, an Active Directory OU, a CSV import, cloud instances, etc.) and Veeam periodically rescans that scope to catch new or removed machines automatically.

The real value shows up at scale: if you're managing dozens or hundreds of Linux/Windows machines, you don't want backup coverage to depend on someone remembering to manually register every new server. A protection group can also handle agent deployment for you — though since I'd already installed the agents manually in Step 3, I made sure to leave that option unchecked (more below).

Veeam gives you several ways to populate a group:

Since I was working with a small, fixed set of Linux servers with no Active Directory in the mix, I used Individual computers — right-click Physical & Cloud Infrastructure → Create protection group, choose Individual computers, name it (e.g. Linux-Backup-Clients), and add each client's hostname or IP one at a time.

On the Options screen of the wizard (deployment settings), since the agents were already installed manually:

Install backup agent — leave unchecked (already done manually; checking it risks a conflicting reinstall)
Install nosnap agent (Linux only) — leave unchecked, same reason
Install application plug-ins — leave unchecked, not needed for a basic setup
Install CDP agent (enables replication) — checked by default, uncheck it — continuous replication is out of scope here
Enable auto-update for installed components — leave unchecked, so nothing changes unexpectedly mid-setup
Perform reboot automatically if required — leave unchecked, don't let a client reboot itself unattended
The default daily rescan schedule is fine to leave as-is — it only controls how often Veeam re-checks for new/changed machines, not the actual backup schedule

Setting up credentials

For Veeam to reach the Linux boxes, it needs credentials it can use to SSH in and elevate privileges. I set this up with a non-root account, using automatic privilege elevation via sudo (with a fallback to su if sudo isn't available).

Testing connectivity — and the firewall gotcha

Before trusting the deployment to actually run, Veeam lets you test the connection to every target first. My first attempt showed the hosts mid-test:

Known issue hit during this deployment: all four clients failed the Test Connection step with a generic "Failed" status and no detail beyond "Credentials test has been completed." The root cause was firewalld blocking port 22 (SSH) on the clients — despite SSH itself running fine. Fix, run on each client:

sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload

Confirm with sudo firewall-cmd --list-all — you should see ssh listed under services:. Since this was a default firewalld config issue, it hit all four clients identically, so it was worth applying to all of them at once rather than fixing and retesting one at a time.

Once that was sorted, all four hosts came back green:

Once applied, Veeam ran through discovery, package installation, and database record creation automatically:

If a client fails to add: the most common causes are SSH not running or blocked by a firewall on the client, or the account lacking sudo rights — check both before troubleshooting further.

Building the Agent Backup Job

With the protection group live, it was time to create the actual backup job. Veeam gives you three backup modes to choose from:

Entire computer — full image-level backup, best for fast, any-level recovery
Volume level backup — back up specific volumes only, reducing backup size
File level backup — slower, but only backs up selected files/folders instead of a full image

I pointed the job at the protection group I'd just created, and set Mode: Managed by backup server (not "Managed by agent"/standalone) — this keeps scheduling, jobs, and monitoring centralized in the VBR console rather than each client managing its own local job.

The LVM snapshot error — and why I switched to file-level

My first instinct was Entire computer mode. All four clients promptly failed with:

"Insufficient free space for a snapshot in a volume group"

Entire machine and Volume level backup both rely on LVM snapshots to run, and in this deployment none of the clients' volume groups had free/unallocated space for LVM to create one in. The fix: switch to File level backup, and check "Backup directly from live file system" (the snapshot-less option, only available in file-level mode). This skips the snapshot mechanism entirely and reads files straight off the live filesystem instead. The trade-off is no point-in-time consistency guarantee if a file changes mid-backup — a non-issue for a basic setup backing up static test data.

For file-level backups, you scope the job down to specific objects/folders instead of the whole filesystem:

sudo mkdir -p /veeam-test-data
echo "test file for backup verification" | sudo tee /veeam-test-data/testfile.txt

Deliberately using a small, known test folder (rather than /, which would drag in /proc, /sys, /dev and other virtual filesystems) also makes the restore test later completely unambiguous — you know exactly what should come back.

Storage and retention

Next up was picking a backup repository and setting a retention policy — in my case, keeping 14 days of restore points. Because the repository lived on the same machine as VBR itself (see the resource constraint above), this step was also a reminder of why production environments separate the two.

Setting a basic schedule

Under the job's Schedule properties, I set it to run daily at a time when the clients are least busy (e.g. overnight), and saved.

Watching the job run

Once the job kicked off, I could watch it process each host in real time from the Home → Jobs view — including throughput, processing rate, and per-object status.

Right-click the job → Start triggers it manually rather than waiting for the schedule. All four clients should finish with a green "Success" status — yellow ("Warning") is worth reading into, red ("Failed") needs troubleshooting before moving on. Checking the repository's used space afterward confirms data actually landed there.

Testing a restore (don't skip this)

A backup that has never been restored isn't a verified backup. Since the job used file-level backup, I went to Home → Backups, right-clicked the job, and chose the File level (a.k.a. Guest OS files) restore option:

Pick the client and the most recent successful restore point.
This opens a file browser showing the backed-up filesystem as it looked at that point in time — navigate to /veeam-test-data and confirm testfile.txt actually shows up.
Right-click testfile.txt → Restore → "Restore to the following location" (rather than overwriting the original) → point it at a temporary folder like /tmp/restore-test/. Restoring somewhere new lets you compare the two side by side rather than just trusting the process worked.
On the client, confirm the file landed:

   ls -l /tmp/restore-test/

Open it and confirm the content matches exactly:

   cat /tmp/restore-test/testfile.txt

It should print exactly test file for backup verification.

Matching content — not just a file existing — is what actually proves the setup works end to end, not just that a backup file exists in the repository.

Getting reports on the backups

A backup job that runs is only useful if you can actually verify it worked — so part of this project was pulling reports out of Veeam to confirm job success/failure history, data transferred, and job duration over time, rather than just eyeballing the console. This is also what you'd hand to a manager or auditor as proof backups are actually happening on schedule.

Connecting Veeam ONE for monitoring

Backups are only half the story — you also want ongoing visibility into whether they're staying healthy over time, not just at the moment a job finishes. That's where Veeam ONE comes in: it's Veeam's monitoring, reporting, and capacity-planning layer that sits on top of VBR.

Only do this once the backup job above is working and verified — Veeam ONE monitors an existing, functioning backup setup, it isn't part of getting backups running in the first place.

Confirm the server still has enough free CPU/RAM/disk headroom on top of what VBR is already using — Veeam ONE's minimums (4 CPU cores, 8GB RAM, 5GB free disk) apply on top of, not instead of, VBR's requirements.
Run the Veeam ONE installer, matching the version to the installed VBR version, and accept the default local configuration database — it uses its own separate database instance from VBR's, even though both run on the same machine.
Let the installer set up its three components: the Veeam ONE Server (core monitoring engine), Veeam ONE Reporter (web-based reporting), and the Veeam ONE Client (console for real-time monitoring).
Confirm the account you'll use has the right permissions. Veeam ONE needs a Windows account that's a member of the local Performance Monitor Users and Event Log Readers security groups, plus general access to VBR itself.
Open the Veeam ONE Client, expand the Veeam Backup & Replication view in the left inventory pane, right-click the top-level node → Add Server (or Ctrl+I):

Choose server type Veeam Backup & Replication server, enter the server's hostname/IP (more reliable than localhost, since some components resolve names rather than loopback addresses), and enter the credentials confirmed above — this is a standard Windows login, not a Veeam-specific account.

I added the VBR server as a data source, reusing the same service account credentials:

The Data Collection Overview page, before the server was registered:

Rounding out the wizard, the deployment reuses the same credentials for connection, analytics service deployment, and backup monitoring:

And here's the summary screen before finishing setup:

The first sync can take a few minutes, since it pulls in everything VBR already knows: the repository, the backup job, the protection group, and all the clients within it — without you manually entering any of it into Veeam ONE.

Setting up and testing alarms

Configuration alone doesn't prove monitoring works — you have to actually trigger a failure and watch it get caught.

In the Veeam ONE Web Client, open Alarm Management (configuration) — different from Alarms Overview (where triggered alarms actually show up).
Expand the Veeam Backup & Replication branch, and find the job failure/warning alarm. Predefined alarms ship enabled by default, so this is mainly a confirmation check.
Find the repository free-space alarm (default threshold is often 90–95%). With a tight storage budget across several clients, it's worth lowering that to around 80% so there's room to react before the repository actually fills.
Confirm both alarms are scoped to include the VBR server — predefined alarms usually auto-apply to all connected data sources, but it's worth a quick visual check.
Trigger a real test failure. On one Linux client, stop the Veeam Agent service so its next backup attempt fails cleanly:

   sudo systemctl stop veeamservice

Back in the VBR console, right-click the job → Start. With one client's agent stopped, that client should fail while the others succeed — a partial failure, closer to a real-world scenario than a total outage.
Go to Alarms Overview in Veeam ONE. Within a few minutes, a new triggered alarm should appear showing the affected job/client, severity, and timestamp. This — not the configuration steps above — is the actual proof the monitoring layer is watching your environment, not just installed.
Clean up: restart the agent (sudo systemctl start veeamservice), re-run the job, confirm it now succeeds cleanly, and mark the alarm resolved/acknowledged.

The Veeam ONE dashboard

Once data started flowing in, the Veeam Backup and Replication dashboard in Veeam ONE gave a much richer overview than the VBR console alone — backup infrastructure inventory, backup window trends, job status history, protected workload percentage, job duration, and repository usage, all in one place.

Checking the Threat Center

Veeam also ships a Threat Center that scores your environment's overall data protection posture and flags any malware detected in restore points. My lab environment scored 59.7% ("Vulnerable Zone") — mostly because things like immutability and MFA weren't fully configured, which is a good reminder that a working backup job isn't the same as a secure backup setup.

Bonus phase: adding a licensed ESXi host for VM backup

Once the Linux-agent side was solid, the project added a second phase: connecting a VMware ESXi host to get hands-on with agentless, hypervisor-level backup too — dropping one Linux client from scope to make room.

Licensing note confirmed for this phase: the fully free VMware ESXi hypervisor lacks the vStorage APIs Veeam needs for VM backup and is not supported, regardless of VBR edition. A licensed ESXi host (Essentials tier or higher) is fully supported for direct VM backup with VBR Community Edition, with no vCenter required.

Remove one Linux client from the existing job and protection group (which one doesn't matter functionally — just document the choice).
Add the ESXi host as a new infrastructure connection. In the VBR console: Inventory → Virtual Infrastructure (a separate section from Physical & Cloud Infrastructure, where the Linux clients live) → right-click → Add Server → VMware vSphere → choose ESXi host specifically (not vCenter Server, since this connects directly to a single licensed host).
Enter the ESXi host's IP and its root/admin credentials — a different credential type from the Windows or SSH accounts used elsewhere. VBR connects over the vSphere API, typically port 443.
Finish the wizard — VBR discovers the host's VMs, datastores, and networks. Confirm the host appears under Virtual Infrastructure with its VMs listed underneath.

Backing up a VM from the ESXi host

Home → Backup Job → Virtual machine (a different job type from the Linux Computer job — this is hypervisor-level, not agent-based).
Name it clearly (e.g. ESXi-VM-Backup), add the specific VM as the source, and set the destination to the same repository used throughout.
Leave retention at defaults, same approach as the rest of the basic setup.
Right-click the job → Start, and confirm it completes successfully. This uses a native VMware snapshot mechanism rather than the LVM-based one that caused the earlier Linux client failure, so that specific issue shouldn't recur here.

Restoring the VM and verifying it

Once the backup completes: Home → Restore → choose a VM-level restore option (Entire VM restore or Instant VM Recovery).
Select the VM and the restore point just created.
Choose restore location — original location (overwrite) or a new location on the same host. Overwriting is more disruptive if the VM is actually in use, so this is worth confirming with a supervisor before doing it live.
Confirm the VM is present and boots/runs correctly on the ESXi host — the same principle as the file-content check used for the Linux client restore: proof the restore produced a working result, not just that the wizard finished without error.

Quick troubleshooting checklist

Symptom	Likely cause
Client won't add to inventory	SSH not running/blocked by `ufw`/`firewalld` on the client, or the account lacks sudo rights
Job fails immediately	Repository out of space, or client agent (`veeamservice`) not running — check with `systemctl status veeamservice`
Job fails with "Insufficient free space for a snapshot in a volume group"	LVM has no free space to create a snapshot. Fix: switch to File level backup mode and check "Backup directly from live file system"
Test Connection fails with no detail beyond "Credentials test has been completed"	Likely `firewalld` blocking port 22, even though SSH itself is running. Run `sudo firewall-cmd --permanent --add-service=ssh && sudo firewall-cmd --reload` and retest
`rpm -i` install fails on a client	Wrong version package used (el7/el8/el9/el10 mismatch), or `veeam-libs` wasn't installed first
SCP command fails or hangs	Missing colon before the destination path, wrong username/IP, or SSH not reachable
Job is very slow	Network throughput between client and server, or too much data selected in "Entire computer" mode
Restore fails	Backup file corrupted/incomplete — check the original job's log for warnings
Veeam ONE can't add VBR as a source	Credentials lack access to VBR server, or version mismatch between Veeam ONE and VBR
Veeam ONE shows no alarms firing	Confirm the VBR data source connection is active, not just added

What's intentionally left out of this basic pass

Retention policy tuning
Offsite/second-copy design (currently a single point of failure by design — one server carries backup, storage, and monitoring together)
Advanced Veeam ONE reporting/dashboards beyond basic failure and free-space alarms
Immutability / ransomware protection
Application-aware processing for anything running databases
Replication or Continuous Data Protection (CDP) for the ESXi VM — this phase covers standard backup/restore only, not near-continuous replication

Wrapping up

By the end of this project, I had:

Registered for a Veeam account and installed the 30-day trial edition
Understood the trade-offs between agentless (hypervisor-based) and agent-based backup, and used both
Built a protection group and deployed backup agents to a set of Linux servers, working through a firewalld connectivity issue along the way
Hit and fixed an LVM snapshot error by switching to file-level, snapshot-less backup
Created an agent-based backup job with a defined retention policy, and actually restored a file to verify it worked
Pulled reports to verify backup success over time
Wired up Veeam ONE for ongoing monitoring, dashboards, and alarms — and proved the alarms actually fire on a real failure
Gotten a first look at the Threat Center and what a "healthy" score actually requires
Connected a licensed ESXi host and backed up/restored a VM agentlessly

A few things worth calling out for anyone doing this for the first time:

Separate your backup server, repository, and monitoring host if you can. I couldn't, due to lab constraints, but it's a real single-point-of-failure risk worth understanding, not just a nice-to-have.
Agent vs. agentless isn't a style choice — it's dictated by your environment. Physical servers, offline machines, and unsupported hypervisors need agents; supported virtualization platforms are almost always better served agentlessly.
Firewall rules are easy to forget and will silently break agent deployment or job connectivity — always the first thing to check when something won't connect.
LVM snapshot space isn't guaranteed — if entire-computer or volume-level backup fails with a snapshot error, file-level with "backup directly from live file system" is the pragmatic fallback.
A "Success" backup job doesn't mean a "secure" environment. The Threat Center score was a good wake-up call that immutability and repository hardening are a separate step from just getting jobs to run.
A backup that's never been restored isn't verified — and reports matter as much as the jobs themselves, since a backup nobody checks on is a backup you can't fully trust.

And, right on schedule, the trial reminded me it wasn't going to stick around forever:

Zabbix Triggers, Dashboards, Graphs, Notifications, and Alerting.

Morodolu Oluwafikunayomi — Mon, 13 Jul 2026 18:53:05 +0000

Part 3 will focus on turning Zabbix from a monitoring dashboard into an active alerting system.
So far, we have successfully connected our monitored server to Zabbix. The Zabbix server can now collect metrics from our agent, such as CPU usage, memory utilization, disk space, and system information.

However, monitoring data alone is not enough.

Imagine a production server running out of disk space. Zabbix can collect the disk usage percentage every minute, but unless someone checks the dashboard manually, nobody knows there is a problem.

Understanding Zabbix Items

Before creating triggers, we need to understand items.

An item is a metric that Zabbix collects from a monitored host.

Examples:

Item ------> Purpose
CPU utilization------> Monitor processor usage
Memory utilization-----> Monitor RAM usage
Disk space-----> Monitor storage capacity
Network traffic -----> Monitor bandwidth
System uptime------> Monitor availability
example:

Host:
rhcsa

Item:
CPU utilization

Value:
35%

Creating a Trigger

A trigger defines when a normal metric becomes a problem.

Think of it like this:

Item:

CPU usage = 95%

Trigger:

If CPU usage is above 90% for 5 minutes,
create a problem.

The trigger is the logic that converts data into an event.

*Create a CPU Trigger
*
Go to:

Monitoring
    |
  Host
   |
specific Hosts(rhcsa)
   |
 Triggers
   |
   Create trigger

Fill in:

Name:

High CPU Usage on {HOST.NAME} in this case ours is {rhcsa}

Severity:

Warning

Expression:

Click:

Add

Select:

Item:
CPU utilization

Condition:

Last value > 20

Example expression:

last(/rhcsa/system.cpu.util)>90

Click:

Add

Now Zabbix will monitor CPU usage.

last(/rhcsa/system.cpu.util,#20)>20 isnt the same last(/rhcsa/system.cpu.util)>20 do take note as the latter
Take the most recent value of system.cpu.util and check if it is greater than 20.

on the rhcsa where the agent is we would trigger a high cpu usage using:

yes > /dev/null

or in the zabbix server :
zabbix_get -s 192.168.120.130(ip of the agent) -k system.cpu.util
43.189230

Creating Dashboards

Dashboards provide a visual overview of your infrastructure.
zabbix 7.0 already provides a nice visual dashboard all we need to do is edit as we see fit, such as editing and showing us which host/server/system is using the most cpu and adding more host to view
and change the parameters we see as well

I had edited what i wish to see which is all the host/system/server, their cpu usage, memory not in use and how many user are logged in, feel free to play around as long it not a live or a production server. :D

Configuring Notifications

A trigger detects a problem.

A notification tells someone about it.

The flow:

in order to achieve this we must create a user or users that will be assigned to receive such triggers:
Go to:
alert-->media

Select your user.

`Go to:

Media

Add:

Type:

Example:

admin@example.com`

Configure Zabbix Email Alert Notifications (Complete Step-by-Step Guide)

After creating triggers in Zabbix, the next step is to configure alert actions so that Zabbix can automatically notify administrators when a problem occurs.

In this guide, we will configure Zabbix to send an email notification when CPU usage becomes high.

The process involves:

Creating the trigger
Creating an email media type
Configuring Gmail SMTP
Creating a Google App Password
Assigning the media to a Zabbix user
Creating an alert action
Testing the notification

Step 1: Create an Email Media Type

First, we need to tell Zabbix how it should send emails.

Navigate to:

Alerts
   |
Media types

Click:

Create media type

Configure the following:

Name

trigger or problem

Type

Email

Email provider

Select:

Generic SMTP

Configure the SMTP settings:

SMTP server:
smtp.gmail.com

SMTP server port:
465

For Gmail, use SSL/TLS:

Connection security:
SSL/TLS

Do not use port 587 with STARTTLS if your network blocks it.

Step 2: Configure Gmail Authentication

At first, we tried sending email without authentication, but Gmail rejected the request.

The error received was:

530 Authentication required

Gmail does not allow applications to send email using only the email address.

You must use a Google App Password.

Step 3: Create a Google App Password

Open your Google Account:

https://myaccount.google.com

Go to:

Security

Enable:

2-Step Verification

After enabling it, go back to:

Security

Find:

App passwords

Create a new app password.

Select:

Other (Custom name)

Enter:

Zabbix

Google will generate a 16-character password.

Example:

xxxx xxxx xxxx xxxx

Copy this password.

Important:

Do not use your normal Gmail password.

The Google App Password is the password Zabbix uses to authenticate with Gmail SMTP.

Step 4: Complete the Zabbix Email Configuration

Return to:

Alerts
   |
Media types
   |
trigger or problem

Configure:

Email

morodoluoluwafikunayomo@gmail.com

Authentication

Change:

None

to:

Username and password

Enter:

Username:

morodoluoluwafikunayomo@gmail.com

Password:

Google App Password generated earlier

Step 5: Add Message Templates

Without a message template, Zabbix will create the alert but fail to send it.

The error will look like:

No message defined for media type

Go to:

Alerts
   |
Media types
   |
trigger or problem
   |
Message templates

Click:

Add

Create a Problem template.

Message type:

Problem

Template:

Problem started at {EVENT.TIME} on {EVENT.DATE}

Problem name:
{EVENT.NAME}

Host:
{HOST.NAME}

Severity:
{EVENT.SEVERITY}

Operational data:
{EVENT.OPDATA}

Event ID:
{EVENT.ID}

Save.

Step 6: Assign the Media Type to the Admin User

Creating a media type is not enough.

Zabbix users need to have a notification method assigned.

If this step is skipped, you will get:

No media defined for user

Go to:

Users
   |
Admin

Open the:

Media

tab.

Click:

Add

Configure:

Type:

trigger or problem

Send to:

morodoluoluwafikunayomo@gmail.com

When active:

1-7,00:00-24:00

Select severities:

Warning
Average
High
Disaster

Save the user.

Step 7: Create the Alert Action

Now we tell Zabbix what to do when a problem occurs.

Navigate to:

Alerts
   |
Actions
   |
Trigger actions

Click:

Create action

Action Name

Enter:

Send CPU Alerts

Conditions

Click:

Add condition

Select:

Trigger severity

Set:

is greater than or equals

Choose:

High

The condition becomes:

Trigger severity >= High

This means only High and Disaster problems will send notifications.

Operations

Go to:

Operations

Click:

Add

Select:

Send message

Choose:

Send to users

Select:

Admin (Zabbix Administrator)

Select media type:

trigger or problem

Save the action.

Make sure the action status is:

Enabled

Step 8: Test the Alert

Generate a CPU problem on the monitored host:

Install stress if needed:

sudo apt install stress

Run:

stress --cpu 4 --timeout 300

Wait for the trigger to fire.

Check:

Alerts
   |
Action log

A successful notification should show:

Status:
Sent

The email should arrive in your Gmail inbox.

Common Problems and Fixes

Problem 1: Host availability is red

Error:

Get value from agent failed

Check:

Agent configuration
Network connectivity
Port 10050

Problem 2: No media defined for user

Cause:

The media type exists but is not attached to the user.

Fix:

Users
 |
Admin
 |
Media
 |
Add

Problem 3: No message defined for media type

Cause:

The media type has no message template.

Fix:

Add:

Problem

message template.

Problem 4: SMTP timeout

Example:

Failed to connect to smtp.gmail.com port 587

Cause:

Network blocking SMTP port 587.

Fix:

Use:

Port:
465

Security:
SSL/TLS

Problem 5: Gmail authentication error

Example:

530 Authentication required

Cause:

Using Gmail password instead of App Password.

Fix:

Create a Google App Password and use it in Zabbix.

After completing these steps, Zabbix can automatically detect problems and send email notifications without requiring manual checking.

Monitoring Ubuntu, Windows, and RHEL Servers with Zabbix (Part 2)

Morodolu Oluwafikunayomi — Fri, 10 Jul 2026 15:21:13 +0000

In Part 1, we installed the Zabbix Server on Ubuntu 22.04, configured the MySQL database, and started the required services.

At this point, the server is running, but it isn't monitoring anything yet.

In this article, we'll:

Complete the Zabbix web setup wizard
Install the Zabbix Agent on Windows Server
Install the Zabbix Agent on RHEL 10
Add both systems to Zabbix
Verify that data is being collected

By the end of this guide, you'll have a centralized monitoring platform collecting metrics from multiple operating systems.
Understanding Zabbix Agents

The Zabbix Server collects information from monitored systems using agents.

These agents gather metrics such as:

CPU utilization
Memory consumption
Disk usage
Network traffic
Running services
System uptime

The collected data is then displayed on the Zabbix dashboard and can be used to generate alerts.

For this lab, we'll install agents on:

Windows Server
Red Hat Enterprise Linux 10
Installing the Zabbix Agent on Windows Server

Download Zabbix Agent 2 from the official Zabbix website.

After launching the installer, provide:

Server=
Hostname=

Configuring the Windows Firewall

The Zabbix Server communicates with the agent using TCP port 10050.

Open PowerShell as Administrator and run:

netsh advfirewall firewall add rule name="Allow TCP 10050" dir=in action=allow protocol=TCP localport=10050

Verify the Zabbix service is running:

Get-Service "Zabbix Agent 2"

Expected output:

Status   Name
------   ----
Running  Zabbix Agent 2

Installing the Zabbix Agent on RHEL 10
Next, let's onboard our Red Hat server.

Add the Zabbix repository:

sudo rpm -Uvh https://repo.zabbix.com/zabbix/7.0/rhel/10/x86_64/zabbix-release-latest-7.0.el10.noarch.rpm

Install the agent:

sudo dnf install zabbix-agent2 -y

Configuring the Agent

Edit the configuration file:

sudo nano /etc/zabbix/zabbix_agent2.conf

Update the following parameters:

Server=192.168.1.100
ServerActive=192.168.1.100
Hostname=RHEL10-SRV01

Where:

Server = Zabbix Server IP
ServerActive = Zabbix Server IP
Hostname = Host name displayed inside Zabbix

Save the file.
Starting the Agent Service

Enable and start the service:

sudo systemctl enable --now zabbix-agent2

Verify:

sudo systemctl status zabbix-agent2

You should see:

active (running)
Configuring the Firewall

Allow inbound traffic on TCP port 10050:


sudo firewall-cmd --permanent --add-port=10050/tcp
sudo firewall-cmd --reload

Verify the port is listening:


ss -tlnp | grep 10050

Adding Windows Server to Zabbix

Navigate to:

Data Collection → Hosts

Click:

Create Host

Enter:

Host Name:
Visible Name: Windows Server

Add the Agent interface:

IP Address:
Port: 10050
Under Templates, select:

Windows by Zabbix agent

Save the host.

Adding RHEL 10 to Zabbix

Repeat the same process.

At this stage, we now have a fully functional monitoring environment.

Our Ubuntu server is running Zabbix, while both Windows Server and RHEL 10 are sending performance metrics back to a centralized dashboard.

The ability to monitor different operating systems from a single platform is one of the reasons Zabbix remains a popular choice in enterprise environments.

In Part 3, we'll explore triggers, dashboards, graphs, notifications, and alerting so that Zabbix can automatically notify us when something goes wrong instead of waiting for users to report issues.

Monitoring Hybrid Infrastructure with Zabbix: Ubuntu, Windows, and Red Hat

Morodolu Oluwafikunayomi — Fri, 10 Jul 2026 10:40:14 +0000

It's been a while since I last wrote a technical article. Recently, one of my routine tasks at work involved onboarding servers into our monitoring platform, and it got me thinking: why not document the process?

This article is the first part of a three-part series where I'll walk through setting up a complete Zabbix monitoring environment from scratch. We'll install the Zabbix server, configure its database, and prepare it to monitor both Windows and Linux systems.

A basic understanding of Linux commands will be helpful, but I'll explain the important steps along the way.

Why Monitoring Matters

As infrastructure grows, so does the challenge of keeping track of system health.

Whether you're managing physical servers, virtual machines, cloud workloads, or a mixture of all three, you need visibility into what's happening behind the scenes. Without monitoring, you often discover problems only after users start complaining.

This is where Zabbix comes in.

What is Zabbix?

Zabbix is an open-source enterprise monitoring platform that helps administrators monitor:

Servers
Applications
Databases
Network devices
Virtual machines
Cloud resources

It collects performance metrics, generates alerts when thresholds are exceeded, and provides dashboards that make it easier to understand the health of your infrastructure.

A typical Zabbix deployment consists of four major components:

Zabbix Server – The central monitoring engine
Database – Stores collected metrics and historical data
Web Frontend – The web interface used for administration and reporting
Zabbix Agent – Installed on monitored systems to collect metrics
Lab Environment

To demonstrate that Zabbix is not tied to a single operating system, I built a small lab consisting of:

System Purpose
Ubuntu 22.04 Zabbix Server
Windows Server Monitored Host
RHEL 10 Monitored Host

This setup reflects what many organizations use today: a mixture of Windows and Linux servers performing different business functions.

The architecture looks like this:

+-------------------+
| Zabbix Server |
| Ubuntu 22.04 |
+---------+---------+
|

| |
| |
+------+ +---------+
| RHEL | | Windows |
| 10 | | Server |
+------+ +---------+

The Zabbix server will collect performance data from both systems and display it through a centralized dashboard.

Installing the Zabbix Server on Ubuntu 22.04

The first step is to add the official Zabbix repository.

Download the repository package from the Zabbix website and install it:

sudo dpkg -i zabbix-release_latest_7.0+ubuntu22.04_all.deb
sudo apt update

Once the repository has been added, install the required Zabbix packages:

sudo apt install zabbix-server-mysql \
zabbix-frontend-php \
zabbix-apache-conf \
zabbix-sql-scripts \
zabbix-agent

*These packages provide:
*

The Zabbix Server
PHP frontend components
Apache configuration
Database schema files
A local Zabbix agent

At this stage, the software is installed but Zabbix still needs a database to store monitoring information.

Configuring MySQL for Zabbix

Zabbix stores all collected metrics inside a database. Without one, the server cannot start.

For this lab, I used MySQL.

Access the MySQL shell:

sudo mysql

Create a dedicated database and user:

CREATE DATABASE zabbix CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;

CREATE USER 'zabbix'@'localhost' IDENTIFIED BY 'StrongPassword';

GRANT ALL PRIVILEGES ON zabbix.* TO 'zabbix'@'localhost';

FLUSH PRIVILEGES;

Next, import the Zabbix database schema:

zcat /usr/share/zabbix-sql-scripts/mysql/server.sql.gz | mysql -uzabbix -p zabbix

i am receiving a message indicating that the database already exists, that's expected as I previously configured Zabbix on the system.

This command creates the tables that Zabbix requires to store monitoring data.

Connecting Zabbix to MySQL

Now we need to tell the Zabbix server how to connect to the database.

Open the Zabbix server configuration file:

sudo nano /etc/zabbix/zabbix_server.conf

Locate and modify the following parameters:

DBName

DBUser

DBPassword

and uncomment them and modify to
DBName=zabbix
DBUser=zabbix
DBPassword=StrongPassword
or type them at the top of the config file

Save the file and exit.
Starting the Services

Once the database configuration is complete, restart the required services:

sudo systemctl restart zabbix-server zabbix-agent apache2

Enable them to start automatically after reboot:

sudo systemctl enable zabbix-server zabbix-agent apache2

Now we installed the Zabbix Server on Ubuntu 22.04, configured the MySQL database, and started the required services.
At this point, the server is running, but it isn't monitoring anything yet.

we'll:

Complete the Zabbix web setup wizard

Accessing the Zabbix Web Interface

Open a browser and navigate to:

http:///zabbix
your zabbix-server-ip is the ip of the os which can be gotten with

ip -a

You should be greeted with the Zabbix setup wizard.

Click Next Step.
Configuring the Database Connection

Enter the database information created during the server installation:

Database type: MySQL
Database host: localhost
Database name: zabbix
User: zabbix
Password: StrongPassword

Configuring Zabbix Server Details

Specify:

Host: localhost
Port: 10051
Name: Zabbix Monitoring Server

The name field is optional, but it helps identify your monitoring environment.

Click Next Step.

Completing the Installation

Review the summary page and click Finish.

You should now see the Zabbix login page.

Default credentials:

Username: Admin
Password: zabbix

For security reasons, change the default password immediately after your first login.

The Fastest Way to Deploy Any Website Template on CentOS (After SSH)

Morodolu Oluwafikunayomi — Wed, 12 Nov 2025 08:53:21 +0000

This is part 2 to my previous post, you know that feeling when you finally SSH into your VirtualBox or Vagrant box, and now you have to set up a whole website manually?
Install this, unzip that, copy files, restart Apache, fix permissions… rinse and repeat.
Yeah, we’re not doing that today.
Instead, I’ll show you how to automate the entire process

What You’ll Need

Before we dive in, make sure you’ve got the basics ready:

You’ve already SSH’d into your CentOS box, for example:

 vagrant ssh

You’re inside your working directory (I’ll use /home/vagrant/server for this tutorial).
Apache is installed and running. If not, quickly do:

sudo yum install httpd -y
 sudo systemctl enable httpd
sudo systemctl start httpd

That’s it let’s automate the rest.
Step 1: Create the Script
Once you’re inside your SSH terminal, move into your server folder and create a script file:

cd ~/server
touch scripting.sh
chmod +x scripting.sh
vi scripting.sh

If vi doesn’t work, you can use nano or even cat > scripting.sh.

Step 2: The Automation Script

#!/bin/bash

echo "Installing wget and unzip..."
sudo yum install wget unzip -y

# Ask the user for a template URL
read -p "Enter the URL of your website template (.zip): " TEMPLATE_URL

echo "Downloading your template..."
wget $TEMPLATE_URL -O website_template.zip

echo "Extracting website files..."
unzip -o website_template.zip -d ~/server/

# Automatically detect extracted folder
EXTRACTED_DIR=$(find ~/server -maxdepth 1 -type d -name "templatemo*" -o -name "html*" | head -n 1)

if [ -z "$EXTRACTED_DIR" ]; then
  echo "❌ Could not find extracted folder. Please check manually."
  exit 1
fi

echo "Deploying files to /var/www/html..."
sudo cp -r $EXTRACTED_DIR/* /var/www/html/

echo "Restarting Apache..."
sudo systemctl restart httpd
sudo systemctl enable httpd

IP=$(hostname -I | awk '{print $1}')
echo "✅ Done! Visit your site at: http://$IP/"

Save and exit (in vi, that’s ESC + :wq).

Step 3: Run It
Now run your shiny new automation script:

./scripting.sh

It’ll ask you for a template URL — just paste in one of these:

Example Template URLs

Templatemo 3D Coverflow
BootstrapMade Arsha Template
HTML5UP Phantom Template
Or grab any .zip link from your favorite site:
https://templatemo.com
https://bootstrapmade.com
https://html5up.net
Once the script runs, it’ll:
Install missing tools
Download your zip file
Unzip it into your server folder
Copy everything into /var/www/html/
Restart Apache
And show your local IP

In short — it does all the boring stuff for you.

After it finishes, you’ll see something like this:
Done! Visit your site at: http://192.168.33.10/

From ThemeWagon to Live Site: Hosting a Free HTML Template on Your Local Apache Server Using Vagrant + Git Bash

Morodolu Oluwafikunayomi — Tue, 04 Nov 2025 15:16:37 +0000

Ever downloaded a beautiful free template from ThemeWagon
and thought,
“Okay... now how do I actually host this like a real website?”

That’s where this guide comes in.

In this post, I’ll walk you through hosting a free HTML template on your own local Apache server, running inside a Vagrant virtual machine — all from your Git Bash terminal.

What You’ll Need

Before we start, make sure you’ve got these installed:

🧱 VirtualBox(for running the VM)
📦 Vagrant
💻 Git Bash(Windows users)
🧾 Any HTML template (download from ThemeWagon)

No coding required

Step 1 — Create a Project Folder and Initialize Vagrant

Open Git Bash and run:

pwd(this is to know what directory you are on)
cd "directory, either downloads or documents or desktop"
mkdir ~/myserver
cd ~/myserver

Now initialize your Ubuntu box:

vagrant init ubuntu/jammy64

but if you wish for any other OS check out:
https://portal.cloud.hashicorp.com/vagrant/discover

This creates a Vagrantfile in your folder. It’s basically your VM’s configuration file — where you’ll define memory, CPU, and network settings.

Step 2 — Edit Your Vagrantfile Using Vim
Inside Git Bash, while you are in the same directory open the Vagrantfile:

vim Vagrantfile

This will open the file in Vim editor.
Press i to enter insert mode now you can start typing or editing.
thereafter to Enable Private or Public Network Access, Scroll down to find these lines:

config.vm.network "private_network", ip: "192.168.33.10"

config.vm.network "public_network"

Uncomment one of them depending on what you want:
Use private network if you just want to access your site locally:

config.vm.network "private_network", ip: "192.168.33.10"

do note kindly keep the ip address here somewhere or be written down as it is useful later on, you can also change the numbers maybe like 192.168.40.15
Or use forwarded port (recommended for beginners):

config.vm.network "forwarded_port", guest: 80, host: 8080

This means anything on port 80 (inside the VM) will be visible on your local machine at http://localhost:8080.
lastly to Allocate More RAM and CPUs
Find and uncomment this section:

config.vm.provider "virtualbox" do |vb|

vb.memory = "1024"

end

Now edit it to give your VM more resources:

config.vm.provider "virtualbox" do |vb|
  vb.memory = "2048"     # 2GB RAM
  vb.cpus = 2            # 2 CPU cores
end

unless you want graphical user interface i don't recommend uncomment the
GUI line of syntax, and any line with double # is an actual comment.

Once done, press:
Esc
Type

:wq
Hit Enter
That saves and exits Vim.

Step 3 — Boot Up the Virtual Machine
Now it’s time to start your virtual server:
type in

vagrant up

Vagrant will download the Ubuntu image, set up the VM, and start it automatically.
The first run takes a few minutes — but once complete, you’ll see your box running.
Then, log in to it:

vagrant ssh

You’re now inside your Ubuntu server as the vagrant user
to test you can type in:

whoami

this should return vagrant
Step 4 — Install Apache Web Server
while having different types os linux OS it is important to know the name of the apache server and which ubuntu supports it


sudo apt update

Install Apache:

sudo apt install apache2 -y

Start and enable it:

sudo systemctl start apache2
sudo systemctl enable apache2

Test it!
On your browser, go to the ip address you have in the private ip address in the vagrant file.
You should see “Apache2 Ubuntu Default Page”.
Congrats — your web server works

Step 5 — Upload and Unzip Your ThemeWagon Template

Inside your server, make a folder to hold your website:

mkdir ~/server
cd ~/server
Now using wget (the themewagon download link)

_the way i usually get is by going to themewagon, inspecting the page, going to network and clicking on the template download buttonwe should see the template name, it should be :http://..... _

so by doing the same you should arrive where i am, copy the link

Then unzip it:

unzip (the foldername)

incase you have an error code about unzip not been part of the OS package use

sudo apt install unzip -y
unzip foldername

Step 6 — Move Files to Apache’s Web Root
Copy everything from your extracted folder into Apache’s serving directory:

sudo cp -r ~/server/neural_glass/templatemo_597_neural_glass/* /var/www/html/

Restart Apache so changes apply:

sudo systemctl restart apache2

Step 7 — Visit Your Website!

Now, open your browser and head to:
your private ip address
incase your forgotten your ip address:
Check your server’s IP:

If you used a private network instead of port forwarding:

ip addr show

Look for something like:

inet 192.168.33.10/24

Reboot or Halt Your Server

To stop:

vagrant halt

To start again:

vagrant up

To destroy and rebuild (when experimenting):


vagrant destroy -f && vagrant up

If this guide helped you, drop a ❤️ on DEV.to and comment how your first hosted template went or what how i can improve on deploying faster

Spin Up, Explore, and Destroy: A Complete Beginner’s Guide to Using Vagrant with Ubuntu (Visual Walkthrough)

Morodolu Oluwafikunayomi — Sat, 11 Oct 2025 15:27:46 +0000

Prerequisites
Before we begin, make sure you have:

Vagrant installed → Download here
VirtualBox (or any supported provider)
A terminal or command prompt
Basic command-line familiarity That’s it! Let’s get started.

Step 1: Create a New Vagrant Project

First, create a folder for your new virtual machine setup and initialize it with the Ubuntu box:

mkdir vagrant-ubuntu
cd vagrant-ubuntu
vagrant init ubuntu/jammy64
vi vagrant #this is to edit the file,

once you opened the file make sure to uncomment the private network line which contains the public address of the os and the public address line

This creates a file called Vagrantfile — the heart of your configuration

Step 2: Configure the Vagrantfile

Open the Vagrantfile with your favorite editor and tweak the settings.
You can adjust CPU, memory, and network configurations easily.

Example configuration:

Vagrant.configure("2") do |config|
  config.vm.box = "ubuntu/jammy64"

  # Optional: forward host port 8080 to guest port 80
  # config.vm.network "forwarded_port", guest: 80, host: 8080

  # Provider-specific settings
  config.vm.provider "virtualbox" do |vb|
    vb.memory = "2048"
    vb.cpus = 2
  end

Step 3: Start the Virtual Machine

Once your configuration is ready, start the VM using:

vagrant up

This command downloads the Ubuntu box (if it’s your first time) and boots it up.
You’ll see messages as Vagrant connects to VirtualBox and starts provisioning the machine.

Step 4: Connect to Your Virtual Machine

Once it’s running, you can log into your Ubuntu VM:

vagrant ssh

If everything went well, you’ll see the Ubuntu welcome message, along with system stats and login info.

Step 5: Run Basic Commands Inside the VM

Now that you’re inside, you can explore and test basic commands:

whoami           # should print 'vagrant'
mkdir testfile
touch textfile.txt
ls
rm textfile.txt
rmdir testfile

You can also install packages, configure software, or run a web app — it’s your sandboxed Linux environment!

Step 6: Stop and Destroy the VM

When you’re done experimenting, you can safely shut down or completely remove the VM:

vagrant halt       # stops the virtual machine
vagrant destroy    # permanently deletes the VM

This frees up your system resources and ensures a clean slate for next time.

This workflow is especially powerful for testing backend apps, DevOps scripts, or server configurations safely. Once you’re comfortable, try automating it with provisioning tools like Ansible or deploying pre-configured images.

AWS Networking Fundamentals: Building a Secure Cloud Architecture

Morodolu Oluwafikunayomi — Sun, 31 Aug 2025 18:23:59 +0000

AWS Networking Explained Like Building a Neighborhood 🏡

If you’re new to AWS networking, it can feel like alphabet soup: VPCs, Subnets, IGWs, NATs, Route Tables, SGs, NACLs

But here’s the good news: it’s easier to understand if you think of it like building a secure neighborhood.

By the end of this post, you’ll:

Understand AWS networking through real-world analogies

Know the difference between gateways, firewalls, and route tables

Build your own secure cloud community step by step

1. VPC → Your Gated Community

A VPC (Virtual Private Cloud) is your private section of AWS.

Imagine buying land inside a gated estate. You decide how big it is, where the streets go, and who’s allowed in.

Isolated from other customers.
You choose the boundaries (IP ranges).
You control traffic in and out.

2. Subnets → Streets in Your Community

Inside your VPC, you divide land into subnets (streets).

Public Subnet → open for visitors (shops, restaurants, web servers).
Private Subnet → hidden residential area (databases, backend).

Pro tip: Always spread them across different availability zones so your app stays online even if one zone fails.

![Insert subnet diagram here]

3. Internet Gateway → The Main Gate

The Internet Gateway (IGW) is the guarded entrance/exit of your estate.

Lets outsiders visit your public servers.
Lets your public servers reach the internet.
Scales automatically (AWS manages it).

4. NAT Gateway → The Secure Mail Slot

Private residents (databases, backend servers) need the internet too—like downloading security updates. But you don’t want strangers knocking on their doors.

That’s what the NAT Gateway is for:

It allows private instances to send requests out.
Outsiders can’t start conversations with them.

Analogy: a one-way mail slot.

5. Route Tables → The Traffic GPS

How does data know where to go?

Public Subnet → IGW (for internet access).
Private Subnet → NAT Gateway (outbound only).

Think of it like street signs and GPS guiding cars to the right road.

6. Elastic IP → think of it as your Fixed house Address

An Elastic IP (EIP) is a permanent public address.

Doesn’t change if you restart your server.
Useful for NAT Gateways and critical servers.

7. Security Groups → Your Bodyguards

Every house/server gets its own bodyguard (SG).

Deny everything by default.
Example: “Allow web visitors (port 80, 443) but only let me in via SSH.”
Stateful: Replies are automatically allowed.

🚔 8. Network ACLs → The Street Patrol

A NACL is the patrol car for the whole street.

Controls traffic before it reaches houses.
Stateless: you must define both inbound & outbound rules.
Can allow and deny traffic (SGs can only allow).

Putting It All Together

So when you launch a simple website with a database:

VPC = your gated community.
Subnets = public (web server) + private (database).
IGW = main entrance gate.
NAT Gateway = one-way mail slot.
Route Tables = GPS for data traffic.
Elastic IP = permanent address.
Security Groups = bodyguards at each house.
NACLs = patrol cars on each street.

Result: Visitors can access your web server.

The web server talks to the database.

The database can fetch updates from the internet—but no hacker can reach it directly.

Hands-On Lab: Build Your Own AWS Neighborhood

Now that you’ve got the concepts, let’s build it step by step.

🔹 Phase 1: Foundation – Setting Up Your Land

Create a VPC (Your Gated Community)
- Go to: AWS Console → VPC → Your VPCs → Create VPC
- Name: My-Secure-VPC
- IPv4 CIDR: 10.0.0.0/16

Create Subnets (Your Streets)
- Public Subnet: public-subnet-1 → 10.0.1.0/24
- Private Subnet: private-subnet-1 → 10.0.2.0/24

Create an Internet Gateway (Main Gate)
- Name: My-IGW
- Attach to My-Secure-VPC

Phase 2: Routing & Security

Public Route Table (Signs for Public Street)
- Destination: 0.0.0.0/0 → Target: Internet Gateway
- Associate with: public-subnet-1

Security Group (Web Server’s Bodyguard)
- Inbound rules:
  - HTTP (80) → Anywhere
  - HTTPS (443) → Anywhere
  - SSH (22) → My IP only

🔹 Phase 3: NAT Gateway – Secure Mail Slot

Allocate an Elastic IP

Create NAT Gateway
- Name: My-NAT-Gateway
- Subnet: public-subnet-1
- Elastic IP: (select the one created)

Remember to create a route table for private route table

it the same process we used for public route table

Private Route Table (Signs for Private Street)
- Destination: 0.0.0.0/0 → Target: My-NAT-Gateway
- Associate with: private-subnet-1

🔹 Phase 4: Deploy Your Residents

Launch Web Server (Public Street)
- Name: Web-Server
- Type: t2.micro (Free Tier)
- Subnet: public-subnet-1
- Public IP: ✅ Enabled
- Security Group: Web-Server-SG
- User Data (auto install web server):

 ```bash
 #!/bin/bash
 sudo dnf update -y
 sudo dnf install -y httpd
 sudo systemctl start httpd
 sudo systemctl enable httpd
 echo "<h1>Hello World from my $(hostname -f)</h1>" > /var/www/html/index.html
 ```

Launch Database Server (Private Street)
- Name: DB-Server
- Type: t2.micro (Free Tier)
- Subnet: private-subnet-1
- Public IP: ❌ Disabled

Phase 5: Validation – Test Your Community

Test Web Server
- Open Web Server’s public IP in a browser → should show “Hello World”.
Test Private Database Internet Access
- SSH into Web Server → then into DB Server (using private IP).
- Run:
```
  curl https://checkip.amazonaws.com
```

- Output should be the NAT Gateway’s Elastic IP → proving secure outbound-only internet.

Final Result

Web Server: Accessible publicly.

Database: Hidden in private subnet, still can update.

Architecture: Secure, scalable, cloud-ready.

You’ve officially built a secure neighborhood in the cloud 🏡🌐

Building a Django Booking Management App with a Theme Wagon Template

Morodolu Oluwafikunayomi — Mon, 11 Aug 2025 16:00:29 +0000

I recently built a booking management system using Django for the backend and two different dashboard templates for the frontend:

Kopee Dashboard → Used for the booking form page.
Venus Dashboard → Used as inspiration for the table page that displays booking records.

This project allows users to:

Submit bookings with Name, Email, Date, Time, Person
Store bookings in a Django database
View, edit, and delete bookings from a clean dashboard table
Use custom HTML/CSS dashboards to save frontend development time

Purpose of the Project

The goal was to create a professional booking management system that:

Lets users submit booking details easily
Stores all bookings in a structured database model
Displays them in a styled and organized table
Uses existing dashboard themes to make the UI look polished without starting from scratch

Frontend Templates

1. Kopee Dashboard (Booking Form Page)

The booking form in my project comes directly from the Kopee Dashboard template. I customized it slightly to match the project’s colors and form structure.

2. Venus Dashboard Inspiration (Table View Page)

For the table that lists all bookings, I took inspiration from the Venus Dashboard by ThemeWagon. I kept only the sidebar and table layout, removed other widgets, and gave the table space, borders, and a readable font.

Project Structure

booking_project/
│── booking_app/
│   ├── templates/
│   │   ├── index.html        # Kopee-based booking form
│   │   ├── showdb.html       # Venus-inspired booking table
│   │   ├── booking_success.html
│   │   ├── correction.html
│   │   ├── delete_confirmation.html
│   ├── models.py
│   ├── views.py
│   ├── urls.py
│── booking_project/
│   ├── settings.py
│   ├── urls.py
│── manage.py

Database Model

booking_app/models.py

from django.db import models

class Booking(models.Model):
    PERSON_CHOICES = [
        ('1', 'Person 1'),
        ('2', 'Person 2'),
        ('3', 'Person 3'),
        ('4', 'Person 4'),
    ]
    name = models.CharField(max_length=100)
    email = models.EmailField()
    date = models.DateField()
    time = models.TimeField()
    person = models.CharField(max_length=1, choices=PERSON_CHOICES)

    def __str__(self):
        return f"Booking by {self.name} on {self.date} at {self.time}"

Views (Core Logic)

booking_app/views.py

from django.shortcuts import render, redirect, get_object_or_404
from .models import Booking

def index(request):
    if request.method == 'POST':
        Booking.objects.create(
            name=request.POST.get('name'),
            email=request.POST.get('email'),
            date=request.POST.get('Date'),
            time=request.POST.get('Time'),
            person=request.POST.get('person')
        )
        return redirect('success')
    return render(request, 'index.html')

def booking_success(request):
    return render(request, 'booking_success.html')

def showdb(request):
    individualbooking = Booking.objects.all()
    return render(request, 'showdb.html', {'individualbooking': individualbooking})

def update(request, id):
    updateInfo = get_object_or_404(Booking, id=id)
    if request.method == 'POST':
        updateInfo.name = request.POST.get('name')
        updateInfo.email = request.POST.get('email')
        updateInfo.date = request.POST.get('date')
        updateInfo.time = request.POST.get('time')
        updateInfo.person = request.POST.get('person')
        updateInfo.save()
        return redirect('showdb')
    return render(request, 'correction.html', {'updateInfo': updateInfo})

def delete_contact(request, id):
    booking = get_object_or_404(Booking, id=id)
    if request.method == 'POST':
        booking.delete()
        return redirect('showdb')
    return render(request, 'delete_confirmation.html', {'booking': booking})

URLs

booking_app/urls.py

from django.urls import path
from . import views

urlpatterns = [
    path('', views.index, name='index'),
    path('success/', views.booking_success, name='success'),
    path('showdb', views.showdb, name='showdb'),
    path('update/<int:id>', views.update, name='update'),
    path('delete_contact/<int:id>', views.delete_contact, name='delete_contact'),
]

Booking Table Template

showdb.html

{% raw %}
<tbody>
{% for booking in individualbooking %}
<tr>
    <td>{{ booking.name }}</td>
    <td>{{ booking.email }}</td>
    <td>{{ booking.date }}</td>
    <td>{{ booking.time }}</td>
    <td>{{ booking.person }}</td>
    <td>
        <a href="{% url 'update' booking.id %}">
            <i class="fa-regular fa-pen-to-square"></i>
        </a>
    </td>
    <td>
        <a href="{% url 'delete_contact' booking.id %}">
            <i class="fa-regular fa-trash-can"></i>
        </a>
    </td>
</tr>
{% empty %}
<tr>
    <td colspan="7" style="text-align:center;">No bookings yet</td>
</tr>
{% endfor %}
{% endraw %}

How to Run

Install Django:

pip install django

Create and configure your Django project and app.
Run migrations:

python manage.py makemigrations
python manage.py migrate

Start the server:

python manage.py runserver

Visit http://127.0.0.1:8000/

Final Thoughts

By combining the Kopee Dashboard for the form and a Venus Dashboard-inspired layout for the table, I built a booking management system that looks professional and works efficiently—without reinventing the wheel for UI design. Django handled the backend logic perfectly, while these templates gave the project a polished frontend.

Full Source Code: https://github.com/Fikalz/A-functioning-booking-form-with-django/tree/main

Here are some of the images of the site

Your First Django Database Write: A Step-by-Step Walkthrough

Morodolu Oluwafikunayomi — Sun, 03 Aug 2025 11:14:48 +0000

When learning Django, one of the most powerful things you'll discover is how effortlessly it lets you interact with databases using models. In this guide, I’ll walk you through how to write to a database in Django using real examples, no steps skipped!

Whether you're just starting or you’re working on a mini project, this article will help you:

Set up your virtual environment
Install Django
Start a project and app
Create and configure a model
Run the server and interact with the database Step 1: Set Up Your Environment: On my previous post on python i showed the walkthrough on the creation and interacting with django, but first, create a new folder for your project, then open your terminal or command prompt inside that folder.

python -m venv venvname
cd venvname\Scripts
activate.bat
cd ../..

💡 Note: venvname can be any name for your virtual environment.
Once activated, install Django:

python -m pip install django

You should see Django and its dependencies installing without issues.

Step 2: Create Your Django Project and App
Next, use the Django CLI to set up your project and an app inside it.

django-admin startproject connectdb .
django-admin startapp dbapp

Make sure your structure looks like this
djangopractice/
├── connectdb/
├── dbapp/
├── venvname/
├── manage.py
in the root folder in your file explorer

Step 3: Create Your Model
Now open dbapp/models.py and define your model class. For this example, `I created a Contacts model:
from django.db import models

class Contacts(models.Model):
firstname = models.CharField(max_length=100)
lastname = models.CharField(max_length=100)
age = models.IntegerField()

def __str__(self):
    return self.firstname`

This will let Django know you want a table in the database called Contacts, with firstname, lastname, and age fields.

Step 4: Connect to the Database Using Django Shell
you can use the django shell but i use the command prompt for this, open a new command prompt and type in one line after the other.

cd downloads\djangopractice\venvname\Scripts
activate.bat
cd ../..
python manage.py makemigrations
python manage.py migrate
python manage.py shell

Step 5: Write to the Database
Inside the shell, you can import your model and start creating records. Here's how:

# First, import the model
from dbapp.models import Contacts

# Then, create a new instance
contact = Contacts(firstname='John', lastname='Doe', age=28)

# Save it to the database
contact.save()

That’s it! 🎉 You've just written to your database.
You can verify it by retrieving all records by

Contacts.objects.all()

In my next article, I’ll show you how to:

Register your models with the Django admin
Create a superuser
Use Django’s powerful built-in admin interface to manage data visually if you have any question or contribution ask in the comment i will always respond

Load Balancing in AWS: Deliver High Availability with Smart Traffic Distribution

Morodolu Oluwafikunayomi — Tue, 29 Jul 2025 07:13:55 +0000

In today's cloud-native world, users expect applications to be fast, reliable, and always available. Whether it's a web app, an API, or a containerized service, your infrastructure needs to be able to handle changing traffic loads without breaking under pressure.
That’s where load balancing comes in — and in AWS, Amazon Web Services (AWS), Elastic Load Balancing (ELB) is a fully managed service designed to automatically distribute incoming traffic across multiple targets such as EC2 instances, containers, and IP addresses.

What is Load Balancing?
Load balancing is the process of distributing incoming network traffic across multiple backend resources. This prevents any single resource from becoming a bottleneck, thereby improving:

Availability
Scalability
Fault tolerance
Performance
Types of Load Balancers in AWS
AWS offers four types of load balancers under the Elastic Load Balancing (ELB) service:
But before that there is something called OSI model( Open Systems Interconnection model), it is a conceptual framework that standardizes how computer systems communicate over a network, it operates at a seven layer framework, which are
physical
datalink
network
transport
session
presentation
application
Depending on what your app needs, AWS offers four types of load balancers. Here's a quick overview and which layer they operate at:
Application Load Balancer (ALB)
Operates at Layer 7 (Application)(HTTP/HTTPS).
Great for routing based on content (like path or hostname).
Perfect for modern web apps and microservices.
Network Load Balancer (NLB)
Works at Layer 4(transport)(TCP/UDP).
Designed for ultra-low latency and high throughput.
Ideal for high-performance, real-time applications.
Gateway Load Balancer (GWLB)
Best suited for integrating third-party security appliances like firewalls or intrusion detection systems.
Routes traffic transparently while scaling with demand.
Classic Load Balancer (CLB)
Older generation, supports both Layer 4 and Layer 7.
Mostly used in legacy systems, not recommended for new projects.

How Load Balancing Works in AWS
Here’s a simplified view of what happens when someone accesses your app through a load balancer:

A user makes a request to your application (e.g., opens your website).
The request is sent to your load balancer via a DNS name.
The load balancer checks which backend servers (targets) are healthy.
It forwards the request to one of those healthy servers based on a routing algorithm (like round-robin).
The chosen server processes the request and sends the response back through the load balancer to the user.

Simple, seamless, and scalable.

_in simpler terms _
When one server is receiving too much traffic, instead of letting it get overwhelmed, the load balancer steps in and says:

“Hey, this server is getting busy — let me send the next request to another server that’s less busy or idle.”

it distributes incoming traffic across multiple servers, which:
Prevents any one server from crashing or slowing down
Keeps your app fast and available
Helps scale your infrastructure without users even noticing

Step-by-Step: Setting Up an Application Load Balancer (ALB)
Step 1: Launch Your EC2 Instances:
Start by launching at least two EC2 instances (in different Availability Zones if possible). These will serve your application and install Apache or NGINX, app on each. If you don't know how to create instance check out my previous post on creation of instances and installation of webserver such as apache or nginx as i will skipping a lot of steps

Step 2: Create a Target Group

Go to EC2 > Target Groups.
Click Create target group, choose “Instances” as the target type.

leave the VPC as default or if you have specific configuration
Set the protocol and port (e.g., HTTP, port 80).

then click on next
Register your EC2 instances to the target group.

then click on create target group

Step 3: Create the Load Balancer
Go to EC2 > Load Balancers, then click Create Load Balancer.

Choose Application Load Balancer.

leave the VPC as default and select the the availability zone based on the instance you created

Set the name, select internet-facing or internal, and assign at least two Availability Zones for high availability.

from the above picture click on default action and select the previous target group we created then click on add listener tag, then leave the remaining checks as is, then click on create load balancer.

Step 4: Test Your Setup

Grab the DNS name of your ALB from the console.
Paste it in your browser — you should see one of your app instances respond.
Refresh a few times to see how it balances across servers.