DEV Community: Ubayed Bin Sufian

VirtualBox Networking and Multi-VM Labs for DevOps Beginners

Ubayed Bin Sufian — Wed, 10 Jun 2026 05:07:54 +0000

VirtualBox Networking

In this section we will discuss:

Various types of networking — NAT, Bridged, Host-Only — what they mean and when to use each
How multiple VMs connect to each other
How to troubleshoot issues where you can't reach the internet

A Computer Can Have More Than One Door to the Network

When we think about connecting a computer to the internet, we usually imagine just one connection — maybe Wi-Fi.

But a computer can actually have multiple network interfaces, and each one acts like its own separate door to the network.

Let me show you using my own laptop.

When I ran:

ip addr show

I got this:

At first glance, this looks technical. But there's a simple story here.

Meet the Three Characters

1. `lo` — The Computer Talking to Itself

The loopback interface (lo) is special.

inet 127.0.0.1/8

This is the famous localhost address. Think of it as your laptop looking into a mirror.

When an application talks to 127.0.0.1, it is not going out to the network — it is talking back to the same machine.

2. `enp1s0` — The Unused Ethernet Port

2: enp1s0
state DOWN
NO-CARRIER

This is my wired Ethernet adapter. It exists, but no cable is plugged in.

Imagine a door in your house that exists but is bolted shut — nobody can enter through it. That is why there is no IP address assigned here.

3. `wlp2s0` — The Active Wi-Fi Connection

3: wlp2s0
inet 192.168.0.105/24
state UP

This is my wireless adapter. It is connected to my home Wi-Fi, so my router assigned it an IP via DHCP:

192.168.0.105

This is the address other devices on my home network can use to reach my laptop.

What if Both Were Connected?

Now imagine I plug in an Ethernet cable while Wi-Fi is still on.

Suddenly my laptop could look like this:

enp1s0  -> 192.168.0.110
wlp2s0  -> 192.168.0.105

Same laptop. Two interfaces. Two IP addresses. Two different doors into the same machine.

Other devices could reach me using either address.

The Big Lesson

A computer is not assigned an IP address. An interface is assigned an IP address.

That is an important distinction. Your laptop may have:

one Wi-Fi adapter
one Ethernet adapter
a VPN tunnel
virtual machine adapters
docker bridges
loopback Each can have its own IP address.

So when someone says:

"What is your computer's IP?"

The more accurate question is:

"Which interface are you talking about?"

Glossary

A network interface is the part of a computer that allows it to communicate on a network.
A network adapter is the hardware (or virtual hardware) that provides that interface.

Hardware (adapter)  --->  OS sees it as  --->  Interface

The Big Idea: Every VM is Just Another Machine on a Network

Think of your laptop as a small apartment building. VirtualBox creates multiple virtual "tenants" (VMs) inside it.

Each VM:

Has its own network card (adapter)
Connects to a "network type" you choose
Can have up to 4 network adapters (usually 1 is enough)

The key question is:

"Which network is this VM plugged into?"

That choice defines everything.

1. Host-Only Network (Private Lab Inside Your Laptop)

Concept

A Host-Only network is like building a private hallway inside your apartment building — only the residents (your VMs) and the landlord (your host machine) can use it. No one from outside can get in.

Only your host machine + VMs can talk to each other
No internet access by default
Completely isolated from the outside world

Example Setup

Host machine: 192.168.5.1
VM1:          192.168.5.2
VM2:          192.168.5.3
VM3:          192.168.5.4

All machines can ping each other and share services internally — but none can reach the internet.

How It Works in VirtualBox

Go to File → Tools → Network Manager
Create a new Host-Only network
VirtualBox creates a virtual adapter (like vboxnet0)
Your host gets an IP like 192.168.5.1
Attach VMs to Host-Only Adapter

Use Case

Testing microservices locally
Simulating private networks
Database + backend interaction in isolation

2. NAT Network (Private Network + Internet Access)

Concept

A NAT Network is like that same private hallway — but now there's a shared exit door that leads outside. The tenants can talk to each other and get to the internet, but strangers still can't walk in uninvited.

VMs can talk to each other
VMs can access the internet
External systems still cannot directly access VMs

How It Works

When a VM sends a request out to the internet:

VM sends a packet with its private IP (e.g. 10.0.2.4)
VirtualBox's NAT engine replaces it with the host's IP
Request goes to the internet
Response comes back to the host
NAT engine forwards it back to the correct VM This is called Network Address Translation (NAT).

Example

VM1 → 10.0.2.4
VM2 → 10.0.2.5
VM3 → 10.0.2.6

All share internet access and can communicate internally.

Setup

Go to File → Tools → Network
Create a NAT Network
Attach VM → Network → NAT Network

Use Case

Running development environments with internet access
Package installs (apt, npm, pip)
APIs + database testing with external services

3. NAT (Default VM Mode)

Concept

This is similar to NAT Network but simpler and more isolated. Each VM gets its own mini-router — it can call out to the internet, but it cannot talk to other VMs by default.

Think of each tenant having their own private exit, but no shared hallway between them.

Key Difference vs NAT Network

Feature	NAT	NAT Network
Internet access	✅	✅
VM-to-VM communication	❌	✅
Shared network	❌	✅

Use Case

Single VM development
Safer isolation
Quick setup without networking complexity

4. Bridged Network (VM Becomes a Real Machine on Your LAN)

Concept

Bridged networking is the most open mode. Your VM stops being a hidden tenant and moves out onto the street — it becomes a fully visible member of your home network, just like your phone or any other device.

The VM behaves like a real computer plugged into your router.

Example

Router:  192.168.1.1
Laptop:  192.168.1.10
Phone:   192.168.1.20
VM:      192.168.1.30   ← your router sees this as a real device

What Happens Internally

VM gets an IP from your router via DHCP
Same subnet as your laptop
Fully visible to other devices on the network

Use Case

Hosting services (web servers, APIs)
Testing real network behavior
Accessing the VM from another machine on your LAN

Internet Connectivity Summary

Mode	Internet Access
NAT	✅ Via host as gateway
NAT Network	✅ Via host as gateway
Bridged	✅ Via router directly
Host-Only	❌ No internet by default

Screenshot taken from YouTube video

If Host-Only Needs Internet

You have two options:

Option A: Enable IP forwarding on the host — make your laptop act like a router.

Option B (simpler): Add a second adapter to each VM:

Adapter 1 → Host-Only (private network)
Adapter 2 → NAT (internet) This is the most common real-world setup for home labs.

5. Port Forwarding (Access VM Services from Outside)

Concept

Port forwarding is like setting up a concierge at the front desk of your building. When a visitor arrives and asks for a specific service, the concierge knows exactly which apartment to send them to.

"If someone knocks on port 8080, send them to the web server in VM1."

Example — Web Server

Host Port 8080 → VM Port 80

Now visiting http://localhost:8080 forwards to the web server running inside your VM.

Example — SSH

Host Port 2222 → VM Port 22

ssh user@localhost -p 2222

You can SSH into the VM without even knowing its internal IP.

Use Case

Accessing web apps inside a NAT VM
Debugging microservices
Running multiple VMs with different exposed ports

Working with Multiple VMs: Cloning and Snapshots

So far, we've explored the different networking modes in VirtualBox. Now let's look at how to efficiently create multiple VMs, connect them together, and use snapshots to experiment safely.

Creating Multiple VMs with Cloning

When building a lab, you'll often need several VMs that are nearly identical — like printing copies of the same blueprint rather than drawing each one from scratch.

The common approach:

Create and configure one base VM
Install required software and updates
Use it as a template
Clone it as many times as needed

How to Clone a VM

Shut down the VM
Right-click the VM in VirtualBox
Select Clone
Enter a name for the new VM
Choose the clone type

Note: The Clone option is only available when the VM is powered off.

Full Clone vs Linked Clone

Full Clone — A completely independent copy. Like photocopying a document: the copy stands on its own.

✅ Fully self-contained, easy to move between computers
❌ Uses the same disk space as the original

Linked Clone — Shares the original's virtual disk and only stores changes. Like a shortcut that points back to the original.

✅ Much smaller, faster to create
❌ Depends on the parent VM; can't be moved easily

When to Use Each

Scenario	Recommended
Learning labs	Linked Clone
Temporary testing	Linked Clone
Long-term VM	Full Clone
Moving VMs between computers	Full Clone

For most home labs, Linked Clones are sufficient.

Connecting Multiple VMs Together

Say we've cloned our base VM and now have VM1 and VM2. We want:

VM1 ↔ VM2 communication
Internet access for both The cleanest solution: two network adapters per VM.

Adapter 1: NAT

Gives each VM internet access — for downloading packages, updates, and calling external services.

Adapter 2: Host-Only Network

Creates a private channel between all VMs and the host.

Host Machine  → 192.168.57.1
VM1           → 192.168.57.3
VM2           → 192.168.57.4

Setting Up the Host-Only Network

Open File → Host Network Manager
Click Create
Enable DHCP if desired
Save the network VirtualBox creates a virtual network (vboxnet1) with an address range like 192.168.57.0/24.

Attaching VMs to the Host-Only Network

For each VM:

Open VM Settings → Network
Enable Adapter 2
Select Host-Only Adapter
Choose the newly created network

Verifying Connectivity

Once both VMs are running:

Check IP addresses:

ip addr

You should see a second interface with an IP like 192.168.57.3 or 192.168.57.4.

Test VM-to-VM communication:

# From VM1
ping 192.168.57.4

# From VM2
ping 192.168.57.3

Test internet access:

ping google.com

All three should work.

Choosing the Right Networking Mode

A quick reference:

Requirement	Recommended Mode
Internet only	NAT
VM-to-VM + Internet	NAT Network
VM-to-VM only	Host-Only
VM visible on LAN	Bridged
Private network + Internet	Host-Only + NAT

Using Snapshots

Think of snapshots as save points in a video game. Before you attempt a risky boss fight (a major system change), you save. If things go wrong, you reload and try again.

Why Snapshots Are Useful

Before you:

Upgrade software
Install packages
Modify configurations
Experiment with new tools Take a snapshot. If something breaks, restore it in seconds.

Creating a Snapshot

Select the VM → open the Snapshots view
Click Take Snapshot
Give it a meaningful name (e.g. Good State)

Example

mkdir -p /opt/app
echo "Example File" > /opt/app/example.txt

Everything works. Take a snapshot named Good State.

Now simulate an accident:

echo "corrupted data" > /opt/app/example.txt

Restoring a Snapshot

Power off the VM
Open Snapshots
Right-click the snapshot → Restore After booting, the VM returns exactly to where it was. The original file is back.

Cloning from a Snapshot

You can also clone directly from a snapshot — useful for:

Testing multiple software versions side by side
Comparing configurations
Building temporary environments from a known-good state

Best Practices

Use clones for reusability — configure one solid base VM, clone it whenever you need a fresh machine.

Use Linked Clones for labs — they save significant disk space.

Take snapshots before major changes — OS upgrades, kernel updates, database migrations, large installs.

Use NAT + Host-Only together — this combination gives you internet access and VM-to-VM communication, which covers most lab scenarios.

Final Thoughts

VirtualBox becomes significantly more powerful once you combine cloning, multiple network adapters, and snapshots. Together, they let you build realistic multi-machine environments on a single laptop — and experiment freely, knowing you can always recover.

This is part of my DevOps Prerequisite series:

DevOps Prerequisite #1: Linux Basics You Actually Need
Build Your Own Lab: Virtualization for DevOps Beginners
VirtualBox Networking and Multi-VM Labs for DevOps Beginners (this post)
Why Vagrant Still Matters (and When It Doesn't) (next)
Networking for DevOps: The Only Concepts You Need
YAML Explained for Future DevOps Engineers

Disclaimer: I have used GPT 5.5 & Claude Sonnet 4.6 (Low) for writing the topics, GPT 5.5 & Gemini Nano for content and cover image generation respectively.

Reference:
💡 Want a visual walkthrough? This video does a great job explaining the basics covered here. Use it as a supplement — not a replacement:

From Prototype to Production-Ready: Finishing an Open Source WordPress Event Management Plugin

Ubayed Bin Sufian — Sun, 07 Jun 2026 21:06:30 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

Every open-source conference needs a home on the web. An open-source community runs an existing ticketing platform handles event ticketing. But there was a gap: it was doing too much. It was managing ticketing and trying to be a full event website at the same time. That's not a great separation of concerns.

The idea was straightforward: build a dedicated WordPress Event Management Plugin that handles the public-facing side of events — the landing pages, speaker grids, session listings, schedules, and code of conduct pages — while the ticketing platform stays focused on what it does best.

A community contributor started this plugin. They got the foundation in place, but the code was procedural, hardcoded in places, and not following WordPress coding standards. It was a solid proof of concept, but not something you'd ship to a production site.

This challenge gave me the push to finally finish it.

Demo

Animated GIF or short screen recording of the plugin in action — switching between event pages in WordPress admin

Live repository: https://github.com/fossasia/WPFAevent

Plugin pages completed so far:

Template	Status
`events-template.php`	✅ Complete
`past-events-template.php`	✅ Complete
`speakers-template.php`	✅ Complete
`code-of-conduct-template.php`	✅ Complete
`landing-template.php`	✅ Finished during this challenge
`schedule-template.php`	🔄 In progress

The Landing Page — Before

The Landing Page — After

After — the finished landing template with header navigation, featured sections

The Comeback Story

Where It Started

The original prototype gave us a working skeleton. You could register the plugin, activate it, and assign pages to templates. That was genuinely useful groundwork. But when you looked under the hood:

Template files were full of hardcoded values — event names, speaker names, and section titles were written directly into PHP strings
Logic was scattered across procedural scripts with no class structure
There was no consistent use of WordPress hooks (add_action, add_filter), sanitization helpers (sanitize_text_field, esc_html), or nonce verification
The landing template existed as a file but rendered almost nothing dynamically

It wasn't broken — it just wasn't finished, and it wasn't ready for anyone to actually use on a real site.

Side-by-side of old procedural code vs. new OOP class structure in VS Code

The Refactor

The first big task was structural. I rewrote the plugin to follow WordPress Coding Standards and proper Object-Oriented PHP:

Each template is now handled by its own PHP class
WordPress hooks are registered cleanly in a central bootstrap file
All output is properly escaped using esc_html(), esc_url(), and wp_kses_post()
Data is pulled via custom post types and post meta — no hardcoded values anywhere

The three earlier templates (events, speakers, code of conduct) had already been refactored before this challenge. The landing template was the next one on the list — and the most complex.

Finishing the Landing Template

The landing page is the hub for an individual event. When a visitor navigates to a specific event, this is what they see first. It needed to:

Display a header with navigation links — Schedule, Speakers, Register — that are relevant to that specific event
Pull in featured content sections dynamically based on event metadata
Render a Speakers grid showing featured speakers for the event, sourced from the custom post type relationships — no hardcoded names or photos
Stay modular — each section is its own component so future contributors can add or swap sections without touching the core template

WordPress admin — assigning the landing-template.php to a page via the Page Attributes dropdown

Frontend output of the landing page showing the header nav, featured sections

My Experience with GitHub Copilot

I'll be honest — I was skeptical at first. I've used AI autocomplete tools before and found them useful for boilerplate but frustrating for anything that required understanding a project's specific conventions.

GitHub Copilot surprised me.

Where It Helped Most

WordPress-specific patterns. The WordPress API has a lot of functions you need to remember — the right sanitization function for the right context, the correct way to register a custom post type, how to structure a WP_Query call with the right arguments. Copilot was genuinely good at filling these in accurately, and it mostly respected the OOP structure I had already established when suggesting completions.

Copilot suggestion in VS Code — showing it autocompleting a register_post_type() call with correct arguments

Repetitive structure. The speakers grid component follows a pattern: query posts, loop through results, output HTML with escaped values. Once I wrote the first version, Copilot helped me apply the same pattern to featured sections quickly, and it kept the escaping consistent — which matters a lot in WordPress.

Docblock comments. Writing PHPDoc comments for every method is tedious but important for an open-source plugin that other contributors will maintain. Copilot generated accurate docblocks based on the method signatures and logic, saving real time.

Copilot generating a PHPDoc comment for a class method in the landing template file

Where I Steered It

Copilot sometimes suggested patterns that were technically valid PHP but not the WordPress way. For example, it would occasionally reach for plain mysqli or PDO for data queries rather than WP_Query or get_post_meta(). I learned to prompt it with more context — mentioning WordPress hooks or the class it was working inside — and that helped a lot.

It also couldn't know our plugin's specific data model (how speakers relate to events, how featured sections are stored in post meta) without me giving it context. Once I pasted in the relevant schema or pointed it at an existing similar method, the suggestions got much more useful.

The workflow that worked best: write the method signature and a comment describing intent → let Copilot fill in the body → review and adjust. It's a genuine collaboration, not a vending machine.

What's Next

The landing template is done, but the plugin isn't finished. Sessions and schedule templates are next. The goal is to have a complete, standards-compliant plugin that any community member can drop into a WordPress site and use for their event.

If you're interested in contributing, the repo is open. Issues are tagged and the architecture is documented.

Tooling Disclosure

AI tools used in this project:

GitHub Copilot — used for code generation, autocompletion, and docblock writing throughout the plugin development, as described in the "My Experience with GitHub Copilot" section above
Claude Code — used to assist with drafting and structuring this article

Both tools were used as assistants, not as authors. All architectural decisions, code review, and final judgement calls were made by the human contributor.

How I Use Antigravity 2.0 to Navigate Open-Source Codebases and Make Better Technical Decisions

Ubayed Bin Sufian — Mon, 25 May 2026 07:43:09 +0000

This is a submission for the Google I/O Writing Challenge

Hook: The Tool That Changed How I Contribute to Open Source

I'll be honest — for the past two years, whenever someone asked me what AI coding tool to use, my answer was automatic: Claude Code or Codex, pick your poison. Google? Not even in the conversation.

Then Google I/O 2026 happened.

In roughly 24 hours, Google dropped over 20 tools — and one of them stopped me mid-scroll. Antigravity 2.0: a standalone desktop agent orchestration platform, free to start, built on Gemini 3.5 Flash, and designed to spin up parallel AI sub-agents the way a senior engineer delegates work to a team.

I didn't want to just read about it. I wanted to put it to work on something real. So I pointed it at a problem I run into constantly as an open-source contributor: walking into an unfamiliar codebase and trying to figure out what's already there before you touch anything.

Right now I'm using it to review WPFAevent, a WordPress plugin by FOSSASIA that integrates with the Eventyay event platform. It's a real repo — 14 open issues, 17 pull requests, PHP + JavaScript + CSS — and it gave me a good surface for testing how well Antigravity handles the kind of context-gathering work that usually eats the first hour of any contribution session.

This is the full walkthrough of how I use it, what genuinely impressed me, where I hit friction, and what every developer contributing to open source should know before they dive in.

What Is Antigravity 2.0?

Antigravity 2.0 is Google's new standalone desktop app for AI agent orchestration. Less than a year ago, Google shipped the Antigravity IDE — a full code editor with an Agent Manager baked in. It was powerful but intimidating. Antigravity 2.0 strips that away entirely. What remains is a clean chat interface that anyone can open and immediately use, backed by agents that coordinate complex work automatically.

The key word is agents — plural, parallel, autonomous.

Where a tool like Claude Code (as of this writing) requires developers to manually configure sub-agent workflows, Antigravity 2.0 is designed from the ground up around the idea that one task can, and often should, spawn multiple specialized agents working simultaneously. A code analysis agent. A research agent cross-referencing docs. A QA agent running browser tests. All at once, reporting back to you, asking for approval only when needed.

At Google I/O, the team ran Antigravity 2.0 for 12 hours straight on stage — 93 sub-agents running in parallel — and produced a working operating system. That's the scale this thing is designed to operate at.

Where it fits in Google's ecosystem: Antigravity connects directly to Google products via installable skills and plugins — Chrome DevTools, modern web guidance, and more — and the whole stack runs on Gemini 3.5 Flash, which is reportedly capable of generating code at close to 800 tokens per second. That raw speed changes how iteration feels in practice.

My Hands-On Experiment: Reviewing WPFAevent

Environment & Prerequisites

OS: Linux Mint 22.3 - Cinnamon 64-bit
Antigravity version: 2.0.6 (Manual Tarball Release)
Google account: Required for sign-in
Repo: fossasia/WPFAevent — cloned locally
Prior Antigravity IDE experience: None needed (though existing IDE users get a smooth migration path)

Step 1: Installation and Onboarding

Head to antigravity.google and grab the installer for your platform — Apple Silicon, Intel Mac, Windows (two installer options), or Linux.

# macOS: Drag to Applications, open from Spotlight
# Windows: Run the installer directly
# Linux: Build available from the site

For Linux Mint, instead of using the standard apt package manager (which still defaults to the older 1.x stable branch), you manually download the compressed package and extract it directly into the system's optional application directory.

# Extract package to system application directory
sudo tar -xzf Antigravity.tar.gz -C /opt/

Troubleshooting the Linux Desktop Shortcut

Initially, I attempted to create a standard terminal-based desktop entry using a .desktop file configuration pointing to internal package assets:

# NOTE: This automated script method did NOT work natively for pinning the icon/shortcut
cat << 'EOF' > ~/.local/share/applications/antigravity-ide.desktop
[Desktop Entry]
Name=Antigravity IDE
Comment=Antigravity IDE v2.0 - Experience liftoff
GenericName=IDE
Exec=/opt/Antigravity/antigravity %F
Icon=/opt/Antigravity/resources/app/resources/icon.png
Type=Application
Categories=Development;IDE;
Terminal=false
StartupWMClass=antigravity
EOF

update-desktop-database ~/.local/share/applications

Because the build structure handles asset routing differently (resulting in a generic gear icon or the shortcut missing from the Mint menu entirely), I verified the core application manually by calling the binary file directly from the terminal:

/opt/Antigravity/antigravity

Final Visual Icon Solution

To successfully map the IDE to the Linux Mint application menu with its real branding, I bypass text configurations entirely and configured it manually using the Cinnamon Desktop environment tools:

Download the official brand logo directly from the Antigravity Press Asset Kit.
Right-click the Linux Mint Menu button (bottom-left corner) -> Click Configure.
Navigate to the Menu tab and click Open the menu editor.
Locate the Antigravity IDE entry under your designated development categories, click it, and open Properties.
Click on the icon tile on the left side of the properties window, browse to your downloaded press asset image, and hit Save.

A screenshot of the Linux Mint Menu Editor properties dialog box showing the Antigravity desktop entry, with the custom branded press-asset icon selected and successfully mapped.

Open the app, sign in with your Google account, and you'll land in a short onboarding flow.

During onboarding, you hit the "Build with Google" page. This is where you install skills and plugins — essentially integrations that give your agents context about specific tools.

I installed:

Modern Web Guidance — helps the agent reason about web development patterns and best practices
Chrome DevTools — gives the agent the ability to interact with and inspect the browser

If you're migrating from the Antigravity IDE, keep the "Keep Antigravity IDE" checkbox selected — your old setup carries over cleanly.

Step 2: Creating a Project

Antigravity 2.0 is project-centric. A project is simply a folder on your local machine that the AI reads from and writes to directly.

Click the + icon next to Projects
→ New Project
→ Select your cloned repo folder
→ All agent context and output is scoped to this folder

I pointed it at my local clone of WPFAevent. From this point forward, every question I ask is answered with reference to the actual source files in that directory — not generic knowledge about WordPress plugins, but this specific codebase.

Step 3: Orienting to the Codebase

Before jumping to any specific issue, I sent an orientation prompt to get a high-level map of the project:

"Give me an overview of this codebase. What does it do, how is it structured, and what are the main entry points I should know about?"

Antigravity compares the actual plugin structure (includes/cpt/, includes/cache/) with the outdated README and correctly uses the live codebase as the source of truth.

This is where the first surprise hit. The project's README.md outlined a file structure containing API shortcodes like class-event-api.php and class-event-speakers.php. But the agent read through the directory, ignored the outdated documentation, and mapped the actual codebase structure:

wpfaevent.php — Core plugin bootstrap file, registering CLI commands and calling run_wpfaevent().
includes/class-wpfaevent.php — The main orchestrator that registers Custom Post Types, taxonomies, metadata, and admin/public hooks.
includes/cpt/ — Declares custom post types wpfa_event and wpfa_speaker.
includes/meta/ & includes/taxonomies/ — Defines fields like start/end dates, locations, speaker bio details, and categories.
includes/cache/class-wpfaevent-cache.php — Implements transient-like caching for page lookups (specifically the Code of Conduct page ID).
public/templates/ — Contains custom WordPress page templates (page-speakers.php, page-schedule.php, page-past-events.php) which are dynamically loaded by class-wpfaevent-landing.php on activation. What would have taken me 15 minutes of head-scratching over why files mentioned in the README didn't exist took the agent 15 seconds to clarify. It immediately pointed out: "The codebase is currently a robust skeleton relying on Custom Post Types and page templates rather than active external API endpoints."

Step 4: Digging Into Real Codebase Quirks

With the true architecture in hand, I opened up some of the file templates and started pressure-testing how Antigravity handles logical constraints.

Issue 1: Transients and Page Caching

Because the setting page is a skeletal placeholder (admin/class-wpfaevent-admin.php literally outputs a "Plugin Skeleton Active" warning notice), there isn't a remote JSON API transient cache yet. However, the plugin implements a custom caching class for page routing. I prompted:

Walk me through how `class-wpfaevent-cache.php` handles transients. 
Are there any risks of stale pages serving incorrect data to users?

The agent analyzed get_coc_page_id() and pointed out that it uses the WordPress Object Cache (wp_cache_get and wp_cache_set under the wpfaevent group) for 1 hour. It then highlighted clear_page_cache(), noting that it hooks into save_post and delete_post to actively invalidate the cache if a page is updated—meaning there is no risk of stale routing, though it noted that as more templates are implemented, we will need to extend this invalidation wrapper.

Issue 2: Enqueuing Styles for New Templates

Instead of standard shortcodes, the plugin enqueues styles conditionally based on active templates to keep the footprint light. I asked:

If I want to add a custom template for event sponsors, what is the pattern for enqueuing stylesheet assets to make sure we don't load unnecessary CSS on other pages?

The agent navigated to public/class-wpfaevent-public.php and mapped the exact modular extension pattern:

Create public/css/templates/sponsors.css.
Add a conditional block using is_page_template('page-sponsors.php') inside enqueue_styles().
Chain the base stylesheet ($this->plugin_name) and navigation stylesheet as dependencies in the array parameter of wp_enqueue_style().

Issue 3: Multi-Day Events Sorting in page-schedule.php

In public/templates/page-schedule.php, events are chronologically sorted and grouped by date. I asked:

How does `page-schedule.php` sort events, and what happens 
if an event has a missing or invalid start date?

The agent walked through the DateTimeImmutable::createFromFormat check, showing how it loops through expected date formats, converts them to a Unix timestamp sort_key, and defaults invalid or missing dates to PHP_INT_MAX (grouping them under a localized "TBD" header at the very end of the schedule).

The explanation also made the current behavior easy to reason about: events are grouped entirely by their parsed start date, while invalid or missing dates fall back to a PHP_INT_MAX sort key and appear under a localized "TBD" section at the end of the schedule. This gave me enough context to evaluate edge cases and potential future improvements without manually tracing the entire sorting workflow.

Step 5: Inline Comments on Artifacts

One feature that surprised me was how naturally Antigravity handles iterative refinement. When the agent produces an analysis artifact — say, a breakdown of what changes are needed for a fix — I can leave comments directly on that artifact, the same way you'd annotate a Google Doc.

I used this to push back on one of its suggestions:

[Comment on artifact]: "This approach modifies the API response parsing — but can we keep the change isolated to the display layer instead? I don't want to touch class-event-api.php for this."

The agent re-read the constraint, updated its recommendation, and produced a revised approach scoped entirely to the template file. No need to rephrase the whole context in a new message.

Step 6: Parallel Agents for Broader Analysis

When I had several open issues I wanted to evaluate at once, I used parallel conversations with work trees — Antigravity's mechanism for running multiple agent threads against separate copies of the codebase simultaneously.

Work Tree = a new folder containing a copy of the project, so agents can explore different issues or approaches in parallel without interfering with each other.

I kicked off three parallel threads:

Thread 1 — Dependency audit:

Check composer.json and the includes/ directory.
Are there any outdated dependencies or missing requirements
relative to the WordPress 5.8+ target stated in the README?
→ New Work Tree

Thread 2 — i18n coverage:

Review the codebase for any user-facing strings that are
not wrapped in __() or _e(). List them by file.
→ New Work Tree

Thread 3 (main thread) — PR review:

There are 17 open pull requests. Based on the current codebase,
which open issues do you think represent the highest-impact
and lowest-risk changes for a new contributor to start with?

All three running simultaneously. While I reviewed the PR analysis coming back on the main thread, the dependency audit and i18n coverage checks were still running. The i18n thread came back with a list of specific files and line numbers — exactly the kind of output that's tedious to produce manually but trivial to act on.

Step 7: Scheduled Tasks for Ongoing Contribution

The final feature I explored was Scheduled Tasks — brand new to Antigravity 2.0.

Scheduled tasks let you run any prompt on a recurring schedule, with the app running silently in the background even when all windows are closed. A menu bar icon shows how many agents are active.

For ongoing open-source contribution, this opens up a genuinely useful workflow. I set up a task called "WPFAevent Issue Digest":

Name: WPFAevent Issue Digest
Schedule: Every Monday, 8:00 AM

Prompt:
Review the current state of the WPFAevent codebase in this project folder.
Check if there are any new patterns or inconsistencies introduced since last week.
Summarize which open issues now have enough context in the codebase to act on,
and flag anything that looks like it might conflict with work already in progress.

Every Monday morning, a brief lands in the app summarising where things stand — without me having to re-orient from scratch each time I come back to the project. For anyone juggling multiple open-source repos alongside their main work, this kind of ambient awareness is genuinely valuable.

The same pattern applies beyond open source: PR status checks, dependency monitoring, documentation drift alerts — any recurring check you'd otherwise do manually.

What Worked Well

Speed changes the cost of asking questions. Gemini 3.5 Flash at close to 800 tokens/second means there's no friction to firing off a quick question about a file you're not sure about. The low latency makes exploratory questioning feel natural rather than effortful.

Parallel agents change the math on codebase analysis. Running a dependency audit, an i18n coverage check, and a PR review simultaneously — each scoped to its own work tree — compressed what would have been a multi-hour orientation into a single focused session.

Inline artifact comments are intuitive. Instead of rephrasing context in a new message, I could annotate the agent's analysis directly, redirect its approach, and get an updated response — exactly like commenting on a Google Doc. This interaction model clicked immediately.

Voice input is underrated. For longer, more nuanced questions about a codebase, speaking is faster and more natural than typing. The agent handled complex multi-part prompts accurately.

Command approval flow builds trust. Knowing exactly what terminal commands the agent wants to run — and having the ability to approve, reject, or whitelist them — means you never feel like you've lost control of your machine.

Self-testing via /browser is a big deal. For issues that involve frontend behavior, being able to ask the agent to verify its own proposed fix in a real browser — and watch it catch its own mistakes — is meaningfully more reliable than code review alone.

Free model access is exceptional value. Gemini 3.5 Flash, Claude Sonnet, Claude Opus, and GPT models are all accessible from the model picker in the free tier. Limited usage, but the breadth is remarkable for zero cost.

What Was Challenging

Model switching restrictions are a regression. In the original Antigravity IDE, you could mix and match — Claude for one task, Codex for another, choosing the best model for the specific job. That flexibility is currently gone. You work with what Google gives you out of the box. For developers who've built workflows around model-specific strengths, this is a real limitation worth acknowledging upfront.

Early rate limits were brutal — though largely fixed. In the first few days post-launch, users were hitting weekly caps after just a couple of work sessions. The backlash was significant. Google responded by tripling rate limits across paid plans, resetting quotas, and then tripling again. Paid users now have roughly 9x the original launch runway. If you tried it early and walked away frustrated, it's worth revisiting. Free tier limits remain tighter.

Browser setup requires a manual step. Connecting the /browser agent to Chrome requires enabling Remote Debugging in Chrome — it's a two-click process, but it's not automatic. First-timers will need to follow the setup prompt before browser testing works.

Sub-agent oversight can feel like a second job at scale. When you have 5–10 sub-agents running simultaneously, monitoring the overview panel and approving occasional blocked actions requires attention. The UI handles this reasonably well, but it's worth being mentally prepared for — this isn't a "fire and forget" tool for complex tasks.

Key Takeaways

Antigravity 2.0 is genuinely designed for agents, not retrofitted for them. The parallel sub-agent architecture, work trees, and /browser command make this feel purpose-built in a way that competing tools don't.
Codebase orientation is a first-class use case. Dropping a repo into a project and asking targeted questions about architecture, issue context, and implementation gaps is one of the most practical things you can do with the tool — and one of the least talked about.
Scheduled tasks turn it into an autonomous employee. The ability to set recurring prompts that run in the background — even with the window closed — opens a class of use cases most AI coding tools don't address.
The free tier is a genuine on-ramp. There's enough free usage to complete a real contribution session, evaluate the tool properly, and decide whether a paid plan makes sense. You don't need a credit card to form a real opinion.
Speed changes behavior. When a tool responds this fast, you ask questions you'd have otherwise skipped. You explore tangents. You pressure-test assumptions before committing to an approach. The raw throughput of Gemini 3.5 Flash has real downstream effects on how you think through a problem.

Who should try it:

Open-source contributors who need to understand existing codebases before diving into issues
Developers onboarding onto new projects at work who want to compress the orientation phase
Developers who want faster iteration cycles on complex multi-part features
Developers running background research, audit, or monitoring workflows
Anyone who has been waiting for a free, capable alternative to Claude Code or Codex

Final Verdict

Would I recommend it? Yes, with awareness of the current limitations.

Is it production-ready? For codebase analysis, contribution workflows, and sophisticated side projects — absolutely. For mission-critical production pipelines where model flexibility and guaranteed uptime matter more than cost, the rate limits and model restrictions are worth factoring in. Google has shown it responds fast to user feedback, so this calculus may shift.

What excites me most? Not any single feature — it's the direction. Antigravity 2.0 is a bet that the future of software development is orchestration: you describe intent, agents coordinate execution, and you stay in the loop as a reviewer and decision-maker rather than a line-by-line author. That model of working is going to win. The question is which platform it wins on.

After this session, Google has a serious claim to that platform.

Check it out at antigravity.google.

Tooling note

In the spirit of transparency, here’s how I used AI while creating this post:

Antigravity 2.0.6 — used directly for codebase review and issue analysis on the WPFAevent repository.
Claude Sonnet 4.6 — used to help structure and refine the written draft of this article.
GPT-5.5 — used to generate the cover image concept and visuals.

All hands-on testing, observations, and conclusions in this post are based on my own experience using Antigravity during this review workflow.

References

Build Your Own Lab: Virtualization for DevOps Beginners

Ubayed Bin Sufian — Sun, 10 May 2026 02:04:52 +0000

What We'll cover?

Setting up your lab (laptop vs cloud)
Virtual Box
- Deploying VMs

Setting Up a Lab on Your Laptop

There are two main options for practicing DevOps: set up a lab on your local machine, or spin up cloud VMs on AWS, Azure, or GCP.

We will focus on the home lab — using a laptop or desktop you already own. It gives you full control, costs nothing extra, and you can use virtualization software like VirtualBox to create and manage virtual machines right on your hardware.

What Is a Home Lab, and What Can You Do in It?

Imagine your laptop is a studio apartment. Now imagine you're trying to run a full restaurant kitchen, a woodworking shop, and a recording studio — all in that same apartment. Things are going to get messy.

That's what happens when you install every DevOps tool directly on your machine: Git, Jenkins, Docker, Kubernetes, Ansible, Python, Java, Node.js, Apache, Nginx, MySQL, MongoDB, AWS CLI, Ubuntu, CentOS... they all start stepping on each other. Different versions conflict. Something breaks. You don't know what you did. You're afraid to change anything.

Virtual machines are the solution. Think of each VM as a separate apartment in the same building. Same physical hardware underneath, but completely isolated from each other. If one apartment burns down (a VM breaks), the others are fine. You just rebuild that one.

With VMs you can:

Run different OS versions (Ubuntu, CentOS, Red Hat) side by side
Isolate tools and projects so they never interfere
Snapshot a working state and roll back if something goes wrong
Delete and recreate freely — no fear

Virtualization software

Virtualization software (also called a hypervisor) sits between your physical hardware and your virtual machines, letting multiple operating systems run on the same machine simultaneously.

There are two types:

Type 1 — Bare-metal Hypervisor: This runs directly on the hardware, with no host OS underneath. Think of it as the hypervisor being the operating system. Examples: VMware ESXi, Microsoft Hyper-V, Xen. These are used in enterprise environments where you need high performance and dozens (or hundreds) of VMs. They're powerful, but expensive and complex.

Type 2 — Hosted Hypervisor: This runs on top of your regular OS (host) — like any other application you install. Examples: Oracle VirtualBox, VMware Workstation, Parallels Desktop. These are perfect for home labs and development environments. Easier to set up, free or cheap, and more than capable for learning. However, they may have performance overhead due to running on top of a host operating system.

Reference: https://www.facebook.com/photo/?fbid=122115084969253388&set=gm.1847442505941341&idorvanity=192962784722663

We will be using Type 2 hypervisor, specifically Oracle VirtualBox, for our home lab environment.

Here's a quick comparison if you're choosing between the two popular options:

Feature	Oracle VirtualBox	VMware Workstation
Cost	Free and open-source	Paid (free trial available)
Platform Support	Windows, macOS, Linux	Windows, Linux
Performance	Good for most use cases	Better for resource-intensive tasks
User Interface	Simple and intuitive	More advanced features
Snapshot & Cloning	Yes	Yes
Resource Management	Good	Advanced

Installing VirtualBox on Linux Mint 22.3 (Zena)

For Windows and macOS installation, refer to the YouTube video in the Reference section below.

I use Linux Mint, so I'll walk through that. You can check your OS details with:

cat /etc/os-release

Linux Mint 22.3 is based on Ubuntu 24.04 LTS (noble), so we use the noble VirtualBox repository.

Step 1 — Add the Oracle VirtualBox repository key:

wget -O- https://www.virtualbox.org/download/oracle_vbox_2016.asc | \
sudo gpg --yes --output /usr/share/keyrings/oracle-virtualbox-2016.gpg --dearmor

Step 2 — Add the repository:

echo "deb [arch=amd64 signed-by=/usr/share/keyrings/oracle-virtualbox-2016.gpg] https://download.virtualbox.org/virtualbox/debian noble contrib" | \
sudo tee /etc/apt/sources.list.d/virtualbox.list

Step 3 — Install VirtualBox:

sudo apt-get update
sudo apt-get install virtualbox-7.1

Step 4 — Verify the installation:

virtualbox --help

For the latest version and other Linux distributions, check the official site: https://www.virtualbox.org/wiki/Linux_Downloads

Setting Up Your First VM in VirtualBox

Open VirtualBox from your applications menu.
Click New to create a virtual machine.
Follow the prompts — choose your OS, allocate memory (at least 2GB recommended for Linux, though 1GB works for lightweight setups), and set up a virtual hard disk.

You have two options here: install the OS manually via an ISO (like inserting a CD), or use a pre-configured VM image that already has the OS installed. I prefer the second approach — it saves time. You can find pre-built images at osboxes.org.
Download the .7z file from osboxes.org, extract it, and you'll get a .vmdk file — that's the virtual hard disk.
When the wizard asks for a hard disk, select "Use an existing virtual hard disk file" and point it to the .vmdk file you extracted.
Before starting the VM, right-click it → Settings → Network → set the adapter to Bridged Adapter. This allows the VM to connect to the same network as your host machine and enable the VM to have its own IP address and access the internet.
Once the virtual machine is created, start in Normal Start.
Log in with the default credentials from osboxes.org (username: osboxes, password: osboxes.org).

Connecting to Your VM

Now your VM is running. But how do you actually talk to it?

Think of VMs like tenants in a building. Just because they share the same physical building (your laptop) doesn't mean they can walk into each other's apartments freely. They need proper addresses and open doors.

Three Ways to Start a VM

Normal Start — Opens a console window with the VM's UI. Closing the window shuts down the VM. Good for initial setup.
Headless Start — VM runs in the background with no window. You access it only via SSH or remote desktop. This is the DevOps way.
Detachable Start — Like Normal Start, but closing the console window doesn't shut down the VM. It keeps running in the background.

SSH Into a Linux VM

For Linux guest VMs, SSH is your main tool. For Windows guests, you'd use Remote Desktop (RDP).

The VM needs:

An IP address assigned
SSH service running Use the console window to do your initial configuration first — get the IP set, start SSH. After that, you can switch to your host terminal for everything else.

Even the vms are within our laptop (host) think of them as separate machines connected to the same network so whatever you need for one system to connect to another system you would need these vms configured with ip addresses and the relevant services must be configured and running on. On windows, the remote desktop service needs to be running and on linux the ssh service needs to be running so make sure ssh server is installed and is in a running state in the vm (guest system). If configured you can ssh into the vm from the host system using the terminal on the host and the ip address of the remote vm.

# Check SSH status on the VM
service sshd status

# Start SSH if it's not running
service sshd start

To SSH in from your host machine:

ssh username@ip_address

If you can't connect, check these first:

Does the VM have an IP address?
Are you using the correct IP?
Is the SSH service running on the VM?

Networking: Bridged vs NAT

This is where a lot of beginners get confused. Let's use an analogy.

Bridged Adapter is like giving your VM its own room in the house with its own doorbell. It gets a real IP address on your network. Anyone on your local network can reach it. SSH is straightforward:

ssh username@vm_ip_address

NAT (Network Address Translation) is like the VM living in a back room with no direct doorbell — it can call out (access the internet), but nobody outside can call in directly. If you have multiple NAT VMs, they're also isolated from each other (they all get the same internal IP and can't see each other).

To SSH into a NAT VM, you need port forwarding — you tell VirtualBox: "whenever someone knocks on my host machine's port 2222, forward that knock to port 22 on the VM."

Set it up in VirtualBox:
Settings → Network → Advanced → Port Forwarding → Add Rule

Name	Protocol	Host Port	Guest Port
ssh	TCP	2222	22

(We use port 2222 on the host because port 22 is already used by the host's own SSH service.)

Then SSH in using:

ssh username@127.0.0.1 -p 2222

This is part of my DevOps Prerequisite series:

DevOps Prerequisite #1: Linux Basics You Actually Need
Build Your Own Lab: Virtualization for DevOps Beginners (this post)
Why Vagrant Still Matters (and When It Doesn’t) (next)
Networking for DevOps: The Only Concepts You Need
YAML Explained for Future DevOps Engineers

Disclaimer: I have used GH copilot for writing the topics, Gemini Nano Banana for image generation, ChatGPT for the html snippet & other concepts and Claude for fine tuning the entire blog.

Reference:
💡 Want a visual walkthrough?
This video does a great job explaining the basics covered here. Use it as a supplement—not a replacement:

Linux Services Made Simple: Create, Control, and Remove Your First systemd Service

Ubayed Bin Sufian — Tue, 05 May 2026 18:45:21 +0000

Linux as a service (The simplest Way to Understand It)

A service is just a program that runs in the background
systemctl is the tool to control it
systemd is the system that manages services

Simple analogy

Think of a service like a car 🚗:

You can start it
You can stop it
You can check if it’s running

The systemd is like the engine that keeps the car running smoothly behind the scenes.

What you'll learn

By the end of this, you’ll be able to:

Create your own service
Start / stop it using systemctl
Enable / disable it at boot
Delete it cleanly (no leftover mess)

Step 1: Create a simple script

Create a file:

sudo nano ~/my_simple_service.sh

Paste this content:

#!/bin/bash

while true
do
  echo "Hello! Service is running..."
  sleep 5
done

Save and exit.

Ctrl + O --> Enter
Ctrl + X

Make it executable:

chmod +x ~/my_simple_service.sh

Step 2: Create a systemd service

Now we tell systemd how to run our script.

sudo nano /etc/systemd/system/my-simple.service

Paste this:

[Unit]
Description=My Simple Demo Service

[Service]
ExecStart=/home/$USER/my-simple-service.sh
Restart=always

[Install]
WantedBy=multi-user.target

👉 Replace /home/your-username with your actual username
(Don’t use $USER here — systemd won’t expand it properly)

Step 3: Reload systemd and start the service

sudo systemctl daemon-reload
sudo systemctl start my-simple.service

Step 4: Check status

sudo systemctl status my-simple.service

You should see the service running.

Step 5: Stop the service

sudo systemctl stop my-simple.service

Step 6: Enable / Disable (auto-start on boot)

Enable:

sudo systemctl enable my-simple.service

Disable:

sudo systemctl disable my-simple.service

Step 7: View logs (while service is running)

sudo journalctl -u my-simple.service -f

-f - follow (like tail -f)

You should see:

"Hello! Service is running..."

…repeating every 5 seconds.

Stop the service: sudo systemctl stop my-simple.service

View logs again: sudo journalctl -u my-simple.service

You will only see past logs (no new updates).

Step 8: Clean up (Delete everything properly)

[CAUTION: PLEASE BE CAREFUL WHEN DELETING THE SERVICE FILES SO WE DO NOT DELETE ANY SYSTEM FILES]

sudo systemctl stop my-simple.service
sudo systemctl disable my-simple.service
sudo rm /etc/systemd/system/my-simple.service
sudo systemctl daemon-reload
sudo rm ~/my_simple_service.sh

Now your system is back to a clean state—no leftover services, no hidden issues.

You just created and managed your first Linux service from scratch 🎉

This is a small step—but it’s exactly how real-world services (like web servers and databases) are managed in production.

Flow Diagram

Disclaimer: I have used GH copilot for writing the topics, Gemini Nano Banana for image generation and ChatGPT for the flow diagram and other concepts.

DevOps Prerequisite: Linux Basics You Actually Need

Ubayed Bin Sufian — Fri, 01 May 2026 01:24:51 +0000

Most DevOps roadmaps look like a never-ending checklist—tools, technologies, and concepts thrown at you all at once.

If you're from a non-IT background or just starting out, it is easy to feel stuck thinking: “Where do I even begin?”

I’ve been there.

That’s why I’m starting this DevOps Prerequisite series to break things down into simple, practical steps that actually matter.

In this first part, we will focus on the one skill that quietly powers almost everything in DevOps: Linux and Vi editor.

Not everything, just the Linux basics you actually need to get started and build confidence.

Basic Linux Commands

According to the Stack Overflow Developer Survey 2024, Linux is the most commonly used operating system among developers, and it's also one of the most loved. Most of the industry tools and platforms are built on Linux, making it essential for DevOps professionals to have a good understanding of Linux commands and operations.

Shell Types

Bourne Shell (sh): The original Unix shell, which is still widely used for scripting.
C Shell (csh/tcsh): Known for its C-like syntax, often used in interactive use.
Z Shell (zsh): An extended version of the Bourne Shell with many improvements, popular among developers for its features and customization options.
Bourne Again Shell (bash): The most widely used shell, which is an enhanced version of the Bourne Shell, offering features like command history and job control.

echo $SHELL - This command will display the current shell being used.

Basic Commands

echo <message>: Prints the message to the terminal. Also used to display the value of environment variables. In scripts and configuration files, it can be used to print information or debug messages.
ls: Lists files and directories.
cd: Change directory.
pwd: Print working directory.
mkdir: Create a new directory.
cd new_dir; mkdir sub_dir; pwd: Multiple commands in one line. ; is used to separate commands, allowing you to execute them sequentially.

Directory Management

To create a dir hierarchy asia/bangladesh/dhaka:
- mkdir asia
- mkdir asia/bangladesh
- mkdir asia/bangladesh/dhaka

[To create the dir hierarchy in one line]

mkdir -p asia/bangladesh/dhaka (using -p flag to create parent directories if they don't exist)
rm -r asia: Remove a directory and its contents recursively.
cp -r my_dir /tmp/my_dir_copy: Copy a directory and its contents recursively.

File Management

touch file1.txt: Create an empty file or update the timestamp of an existing file.
cat > file2.txt: After running this command, the prompt will appear and you can type the content. Hit the Enter key for a new line and press Ctrl + D to save and exit.
cat file2.txt: Display the content of the file.
cp file2.txt dir: Copy a file to a new location.
mv dir/file2.txt dir/sub_dir: Move or rename a file. To rename a file, you can use the same command with the new name in the same directory, e.g., mv file.txt new_file.txt.
rm my_dir.txt: Remove a file.

User Management

whoami: Display the current user.
id: Display user ID and group information.
su username: Switch to another user account. You will be prompted to enter the password for the specified user. Same machine, different user.
ssh username@hostname: Connect to a remote server using SSH. You will be prompted to enter the password for the specified user on the remote server. Different machine, login remotely.
Every linux system has a super user called the root user. The root user has full administrative privileges and can perform any action on the system. In production or enterprise environments, acces to root user is often restricted for security reasons, and users are given specific permissions to perform their tasks.
If a normal user needs to perform administrative tasks, they can use the sudo command to execute commands with elevated privileges such as installing software, modifying system configurations, or managing user accounts. The root user can grant them sudo privileges by adding their username into the /etc/sudoers file or by adding them to a group that has sudo privileges (e.g., the "sudo" group on Debian-based systems). Now, the user can run commands with sudo to perform administrative tasks without needing to log in as the root user. The user needs to enter their own password to confirm the action, and the system will log the command for auditing purposes.

Download files

curl -O https://www.digitalocean.com/robots.txt: Download a file from the specified URL and save it with the custom name. Without the -o flag, the content will be displayed in the terminal instead of being saved to a file. curl; "Client URL".
wget https://example.com/file.txt -O file.txt: Download a file from the specified URL and save it with a custom name. wget; "World Wide Web get".

Check OS version

ls /etc/*release*: This command lists the contents of the /etc directory that match the pattern release, which typically includes files that contain information about the operating system version and distribution. The output may vary depending on the Linux distribution being used, but it often includes files like os-release, lsb-release, or redhat-release that provide details about the OS version, name, and other relevant information.
cat /etc/*release*: This command displays the contents of the files in the /etc directory that match the pattern release. These files usually contain information about the operating system version and distribution. By running this command, you can see details such as the OS name, version number, and other relevant information about the Linux distribution you are using.

Package Managers

Package managers are tools that automate the process of installing, updating, configuring, and removing software packages on a computer. They help manage dependencies and ensure that the correct versions of software are installed. Different Linux distributions use different package managers. For example:

Debian-based distributions (like Ubuntu) use apt (Advanced Package Tool).
Red Hat-based distributions (like CentOS, Fedora) use yum or dnf.
Arch Linux uses pacman.

apt (Advanced Package Tool)

apt is a package manager used in Debian-based Linux distributions that provides a high-level interface for managing software packages. It automatically resolves dependencies and allows you to easily install, update, and remove software packages. For example:

apt install package_name: Install a package along with its dependencies.
apt remove package_name: Remove a package.
apt update: Update the package index to get the latest information about available packages.
apt upgrade: Upgrade all installed packages to their latest versions.

Red Hat Package Manager (RPM)

A software is bundled into a package file with the .rpm extension. The rpm command is used to manage these packages, allowing you to install, update, remove, and query software on your system. For example:

rpm -i package.rpm: Install a package.
rpm -e package_name: Remove a package.
rpm -q package_name: Query if a package is installed.

It does not resolve dependencies automatically, so you may need to manually install any required packages before installing the main package. For example, if you try to install ansible using rpm -i ansible.rpm and it has dependencies like python3 and python3-pip, you would need to install those dependencies first before installing ansible.

yum (Yellowdog Updater, Modified)

yum is a high level package manager used in Red Hat-based Linux distributions that uses RPM under the hood. It automatically resolves dependencies and allows you to easily install, update, and remove software packages. It searches software repositories that act as warehouses containing rpm packages. For example:

yum install package_name: Install a package along with its dependencies.
yum remove package_name: Remove a package.
yum update package_name: Update a package to the latest version.

How does yum find where a particular is located? It looks into the repository configuration files located in /etc/yum.repos.d/ directory. These files contain information about the repositories, including their URLs and the packages they contain. When you run a yum command, it checks these repositories for the requested package and its dependencies, and then downloads and installs them as needed. At times, the default set of repos may not have the software you need or may not have the latest version. So you need to configure additional repositories so yum can find those packages. Instructions to configure additional repositories are usually provided on the software vendor's website.

yum repolist: List all configured repositories and their status (enabled/disabled).
ls /etc/yum.repos.d/: List the repository configuration files in the yum.repos.d directory. Each file corresponds to a repository and contains information about its name, base URL, and other settings. By checking these files, you can see which repositories are configured on your system and where yum will look for packages when you run installation or update commands.
cat /etc/yum.repos.d/<repo_file>.repo: Display the contents of a specific repository configuration file. This file contains details about the repository, such as its name, base URL, and whether it is enabled or disabled. By examining this file, you can understand where yum will look for packages when you run installation or update commands, and you can also modify the repository settings if needed.
yum list <package_name>: Check if a specific package is available in the configured repositories.
yum --showduplicates list <package_name>: Check for all available versions of a specific package in the configured repositories. This command will show you all the versions of the package that are available for installation, allowing you to choose which version you want to install or update to.

Services

Services are background processes that run on a server to provide specific functionality, such as web hosting, database management, or file sharing.

Once software that runs in the background (e.g., web servers, databases) is installed, it needs to keep running reliably even after a reboot. Services ensure that these programs start automatically and in the correct order. For example, a database service should start before a web server that depends on it. Most background software is configured as a service during installation.

service <service_name> start : Start a service. (old command, still works in some distros)
systemctl start <service_name> : Start a service. (new command, used in most modern distros)
systemctl stop <service_name> : Stop a service.
systemctl status <service_name> : Check the status of a service (whether it's running or not).
systemctl enable <service_name> : Enable a service to start automatically at boot time.
systemctl disable <service_name>: Disable a service from starting automatically at boot time.

How to configure a software/program as a service?

Most modern Linux distributions use systemd to manage services. Each service is defined using a unit file, which is a configuration file (with a .service extension) typically located in /etc/systemd/system/.

Steps to configure a software as a systemd service:

Create a unit file for the service. For example, if you want to create a service for a web application called "myapp", you would create a file named myapp.service in the /etc/systemd/system/ directory.
To add additional metadata about the service, such as a description or dependencies, you can include a [Unit] section in the unit file.
Define a section caled [Service] in the unit file, where you specify the command to start the service and directive named ExecStart to specify the command that will be executed to start the service. If the application has other dependencies, commands or scripts to run before or after starting the main application, you can specify them using directives like ExecStartPre or ExecStartPost. If the app needs to be restarted if it crashes, you can use the Restart directive.
To configure the service to start automatically at boot time, define a section called [Install] in the unit file. In this section, you can specify the target that the service should be associated with using the WantedBy directive. For example, if you want the service to start when the system reaches the multi-user target (which is a common target for services), you would add the following lines to the unit file.
After defining the [Install] section, you can enable the service to start at boot time using the systemctl command: sudo systemctl enable myapp.service
Save the unit file and reload the systemd manager configuration to recognize the new service: sudo systemctl daemon-reload
Start the service using the systemctl command: sudo systemctl start myapp.service
Stop the service using the systemctl command: sudo systemctl stop myapp.service
Check the status of the service: sudo systemctl status myapp.service

Unit file contents:

[Unit]
Description=My Web Application Service

[Service]
ExecStart=/usr/bin/python3 /path/to/myapp.py
ExecStartPre=/usr/bin/echo "Starting myapp service..."
ExecStartPost=/usr/bin/echo "myapp service started successfully!"
Restart=always

[Install]
WantedBy=multi-user.target

I have written an example blog on configuring a linux service:

Ubayed Bin Sufian

Linux Services Made Simple: Create, Control, and Remove Your First systemd Service

#linux #devops #systemdesign #beginners

2 min read

Vi Editor

vi is a powerful text editor that is commonly used in Linux environments. In devops and cloud environments, you will often need to edit configuration files, write scripts, or manage code directly on the server. Knowing how to use vi allows you to efficiently make changes to files without needing a graphical interface, which is especially important when working on remote servers via SSH. vi editor comes by default in most Linux distributions. Types of vi editors:

vi: The original version of the editor.
vim (Vi IMproved): An enhanced version of vi with additional features and improvements. It is widely used and often the default vi editor in many Linux distributions.
nvim (Neovim): A modern fork of vim that aims to improve performance and add new features while maintaining compatibility with vim. It is gaining popularity among developers for its extensibility and improved user experience.
nano: A simpler text editor that is easier for beginners to use. It provides a more user-friendly interface compared to vi and vim, making it a good choice for those who are new to command-line text editing.

Basic vi Commands

Vi editor has two main modes: command mode and insert mode. When you open a file in vi, you start in command mode, where you can navigate through the file and execute commands. To edit the file, you need to switch to insert mode. Here are some basic commands to get started with vi editor:

vi filename: Open a file in vi editor. This will open the specified file in command mode.
i: Switch to insert mode to start editing the file. In insert mode, you can type and make changes to the file. To return to command mode from insert mode, press the Esc key.
Use the arrow keys to navigate through the file in command mode. You can also use h, j, k, and l keys for left, down, up, and right navigation respectively.
x: Delete the character under the cursor in command mode.
dd: Delete the entire line where the cursor is located in command mode.
yy: Copy the entire line where the cursor is located in command mode.
p: Paste the copied line below the current line in command mode.
Ctrl + u: Scroll up half a page in command mode.
Ctrl + d: Scroll down half a page in command mode.
:: Enter command-line mode in vi editor. In this mode, you can execute various commands to save, quit, or perform other actions on the file.
:w: Save the changes made to the file in command-line mode.
:q: Quit the vi editor in command-line mode. If you have unsaved changes, it will prompt you to save before quitting.
:wq: Save the changes and quit the vi editor in command-line mode.
/search_term: Search for a specific term in the file in command mode. This will highlight the occurrences of the search term in the file. You can navigate through the search results using n (next) and N (previous) commands in command mode.

This wasn’t about memorizing commands, it was about getting comfortable with the environment where DevOps actually happens.

If you understand these Linux basics, you’ve already taken a solid first step that many beginners skip.

In the next part of this series, we’ll move from commands to hands-on practice, you’ll learn how to build your own lab using VirtualBox, so you can experiment, break things, and learn by doing.

Because DevOps isn’t learned by reading, it’s learned by doing.

This is part of my DevOps Prerequisite series:

DevOps Prerequisite #1: Linux Basics You Actually Need (this post)
Build Your Own Lab: Virtualization for DevOps Beginners (next)
Why Vagrant Still Matters (and When It Doesn’t)
Networking for DevOps: The Only Concepts You Need
YAML Explained for Future DevOps Engineers

Disclaimer: I have used GH copilot for writing the topics, Gemini Nano Banana for image generation and ChatGPT for the html snippet and other concepts.

Reference:
💡 Want a visual walkthrough?
This video does a great job explaining the basics covered here. Use it as a supplement—not a replacement:

DEV Community: Ubayed Bin Sufian

VirtualBox Networking and Multi-VM Labs for DevOps Beginners

VirtualBox Networking

A Computer Can Have More Than One Door to the Network

Meet the Three Characters

1. lo — The Computer Talking to Itself

2. enp1s0 — The Unused Ethernet Port

3. wlp2s0 — The Active Wi-Fi Connection

What if Both Were Connected?

The Big Lesson

Glossary

The Big Idea: Every VM is Just Another Machine on a Network

1. Host-Only Network (Private Lab Inside Your Laptop)

Concept

Example Setup

How It Works in VirtualBox

Use Case

2. NAT Network (Private Network + Internet Access)

Concept

How It Works

Example

Setup

Use Case

3. NAT (Default VM Mode)

Concept

Key Difference vs NAT Network

Use Case

4. Bridged Network (VM Becomes a Real Machine on Your LAN)

Concept

Example

What Happens Internally

Use Case

Internet Connectivity Summary

If Host-Only Needs Internet

5. Port Forwarding (Access VM Services from Outside)

Concept

Example — Web Server

Example — SSH

Use Case

Working with Multiple VMs: Cloning and Snapshots

Creating Multiple VMs with Cloning

How to Clone a VM

Full Clone vs Linked Clone

When to Use Each

Connecting Multiple VMs Together

Adapter 1: NAT

Adapter 2: Host-Only Network

Setting Up the Host-Only Network

Attaching VMs to the Host-Only Network

Verifying Connectivity

Choosing the Right Networking Mode

Using Snapshots

Why Snapshots Are Useful

Creating a Snapshot

Example

Restoring a Snapshot

Cloning from a Snapshot

Best Practices

Final Thoughts

From Prototype to Production-Ready: Finishing an Open Source WordPress Event Management Plugin

What I Built

Demo

The Landing Page — Before

The Landing Page — After

The Comeback Story

Where It Started

The Refactor

Finishing the Landing Template

My Experience with GitHub Copilot

Where It Helped Most

Where I Steered It

What's Next

Tooling Disclosure

How I Use Antigravity 2.0 to Navigate Open-Source Codebases and Make Better Technical Decisions

Hook: The Tool That Changed How I Contribute to Open Source

What Is Antigravity 2.0?

My Hands-On Experiment: Reviewing WPFAevent

Environment & Prerequisites

Step 1: Installation and Onboarding

Troubleshooting the Linux Desktop Shortcut

1. `lo` — The Computer Talking to Itself

2. `enp1s0` — The Unused Ethernet Port

3. `wlp2s0` — The Active Wi-Fi Connection