DEV Community: alok-38

Host a Simple Python App on a Virtual Machine (Step-by-Step)

alok-38 — Tue, 31 Mar 2026 10:33:13 +0000

Serve a Python App from a VM: From Local Server to Public Access

In this guide, we’ll deploy a simple Python HTTP server on an AlmaLinux virtual machine and explore how network traffic flows from the VM to the host machine and beyond. By the end, you’ll be able to access your app from your local network and from external devices using a public tunnel.

Let's learn how to:

Set up a Python HTTP server on a VM
Access the server from the host machine
Expose the VM to external devices via Localtunnel
Understand the traffic flow from client to VM

In this setup, the AlmaLinux VM runs a Python HTTP server, the Fedora host acts as a KVM/QEMU host and NAT gateway, and the smartphone simulates an external client. We’ll show how to make the server accessible locally and over the internet using a tunnel.

1️⃣ Environment Setup

AlmaLinux 10 VM (Guest)
- IP: 192.168.122.88
- Runs the Python HTTP server
Fedora Host
- IP: 192.168.0.136
- Acts as KVM/QEMU host and NAT gateway
Smartphone / External Device
- Connected via mobile network (e.g., Airtel)
- Accesses the server through a public tunnel

          ┌─────────────┐
          │ Smartphone  │
          │ (Mobile Data)│
          └─────┬───────┘
                │
                ▼
       ┌─────────────────┐
       │ Public Tunnel   │
       │ (Localtunnel)   │
       └─────┬───────────┘
             │
             ▼
       ┌─────────────┐
       │ Fedora Host │
       │ 192.168.0.136 │
       │ KVM/QEMU + NAT│
       └─────┬───────┘
             │
             ▼
       ┌───────────────┐
       │ AlmaLinux VM  │
       │ 192.168.122.88│
       │ Python HTTP    │
       │ Server :8000   │
       └───────────────┘

2️⃣ Start the Python HTTP Server on the VM

# Start Python HTTP server on all interfaces, port 8000
python3 -m http.server 8000 --bind 0.0.0.0

Explaination:

The server serves the current directory as a simple web app.
You can test locally inside the VM:

curl http://127.0.0.1:8000

Access from the Host Machine

The host machine can reach the VM directly using its private IP. This is useful for testing that the Python HTTP server is running before exposing it externally.

# Test access from Fedora host
curl http://192.168.122.88:8000

✅ Expected output:

A directory listing of the files served by the Python HTTP server
Or the contents of an index.html file if present

💡 Tip: If you see a connection refused error, make sure the Python server is running and bound to 0.0.0.0.

Access from External Devices / Smartphone

Smartphones or external devices on a different network cannot reach the VM’s private IP directly. To solve this, we use Localtunnel to create a public HTTPS URL that forwards traffic to the VM.

Install Node.js and Localtunnel on the VM

# Install Node.js and npm (if not already installed)
sudo dnf install -y nodejs npm

# Install Localtunnel globally
sudo npm install -g localtunnel

Start the tunnel

# Forward port 8000 to a public URL
lt --port 8000

-Localtunnel will generate a public URL, e.g., https://hot-deer-send.loca.lt

Open this URL in your smartphone browser → you should see the Python app content.

💡 Tip: Each time you start Localtunnel, the URL changes unless you specify a custom subdomain.

Content Served by Python Server

By default, the Python HTTP server serves the current directory as a simple web app. Example directory structure:

/home/alok/systems-thinking
├── server.py
├── venv/
└── README.md

Accessing the server URL lists these files automatically in HTML
You can place an index.html file to serve a custom homepage

Traffic Flow Diagram

[Smartphone / Mobile Data]
            │
            ▼
    [Public Tunnel via Localtunnel]
            │
            ▼
       [Fedora Host 192.168.0.136]
        (KVM/QEMU + NAT)
            │
            ▼
      [AlmaLinux VM 192.168.122.88]
         Python HTTP Server :8000

Smartphone requests → public tunnel → host → VM → Python server → response flows back the same way.

This completes the core tutorial flow: from environment setup → VM server → host access → external access → traffic understanding.

Rocky Linux VirtualBox VM Networking Setup & SSH Access Using Windows 11 with Smartphone Hotspot

alok-38 — Wed, 11 Mar 2026 10:32:15 +0000

SSH into Rocky Linux VM on VirtualBox (Windows 11 + Mobile Hotspot Setup)

When experimenting with Linux in a virtual machine, one of the most useful skills to learn is how to access the system remotely using SSH. If you're running a Rocky Linux VM inside VirtualBox on a Windows 11 host, things can feel a bit confusing—especially when your computer is connected to the internet through a smartphone hotspot instead of a traditional router. In this guide, I’ll walk through a simple and practical setup that allows you to configure networking for your Rocky Linux virtual machine and successfully SSH into it from your Windows 11 host. By the end, you’ll have a working setup that’s perfect for learning, testing, and managing your VM just like a real remote Linux server.

Set up

Host: Windows 11
Internet Source: Smartphone Hotspot
Guest: Rocky Linux (Headless – No GUI)
Virtualization: VirtualBox

Initial Objective

The goal was to:

Create a headless Rocky Linux VM
Ensure the VM has Internet access
Allow SSH access from Windows PowerShell
Verify networking using systematic diagnostic tests

VirtualBox Network Architecture

I configured two network adapters for this setup. At the time, I didn’t fully understand the reasoning behind it, but since the configuration worked, I proceeded with it. I plan to revisit this later and spend some time understanding the finer details of how the networking works.

Adapter 1 — NAT (Internet access)

Purpose:

Allows the VM to share the host's Internet connection.

Configuration:

Adapter 1 → NAT

Inside the Rocky Linux VM, the network interface typically receives an address similar to:

10.0.2.15

VirtualBox also provides a default gateway for this internal network:

10.0.2.2

This setup ensures that the VM can download packages, update the system, and access the internet without needing any additional network configuration.

Adapter 2 — Host-Only Adapter (VM ↔ Host communication)

While the NAT adapter provides internet connectivity to the virtual machine, it does not allow the host system to directly initiate connections to the VM. This is where the Host-Only Adapter becomes useful.

The Host-Only Adapter creates a private network between the Windows host and the virtual machine. This network exists only within VirtualBox and does not depend on the external network or internet connection. In my setup, this private network is what enables me to SSH from the Windows host into the Rocky Linux VM.

Purpose:

Direct communication between Windows host and VM
Enables SSH access

Configuration:

Adapter 2 → Host-Only Adapter

When this adapter is enabled, VirtualBox automatically creates a host-only network. The default network typically looks like this:

192.168.56.0/24

Both the Windows host and the VM receive IP addresses within this network range. For example:

Windows host: 192.168.56.1
VM:           192.168.56.102

This means the host machine can directly reach the VM using the assigned address, which makes SSH access simple and reliable.

Architecture Diagram

The following diagram illustrates how the different components in this setup are connected. The Windows host receives internet access through a smartphone hotspot, while the virtual machine uses two adapters — one for internet access and another for direct communication with the host.

                Internet
                    │
            Smartphone Hotspot
                    │
               Windows Host
            WiFi: 10.139.205.51
                    │
        ┌───────────┴───────────┐
        │                       │
    VirtualBox NAT        Host-Only Adapter
     (Internet)            (Local Access)
      10.0.2.x              192.168.56.x
        │                       │
        └────── Rocky Linux VM ──────┘
                 10.0.2.15
               192.168.56.102

In simple terms:

Adapter 1 (NAT) allows the VM to access the internet.
Adapter 2 (Host-only) allows the Windows host to directly connect to the VM.

This dual-adapter setup is commonly used when you want a VM to behave like a real server that is both internet-enabled and locally accessible.

Network Verification Commands

Once the VM is running, it's useful to verify that both network adapters are active and correctly assigned IP addresses.

Check interfaces

Command:

ip a

Purpose:

Lists all network interfaces
Shows assigned IP addresses

Result (truncated):

lo
enp0s3 → 10.0.2.15
enp0s8 → 192.168.56.102

Meaning:

Interface	Purpose
lo	loopback
enp0s3	NAT adapter
enp0s8	Host-only adapter

From this output, we can confirm that both network adapters are active:

enp0s3 is connected to the NAT network, providing internet access.
enp0s8 is connected to the Host-only network, enabling communication with the Windows host.

This host-only IP address is the one that will be used when connecting to the VM via SSH.

Verify Routing Table

After confirming that both network interfaces are active, the next step is to verify how the system routes network traffic. In Linux, the routing table determines where outgoing network packets should be sent depending on their destination.

To view the routing table, run the following command inside the Rocky Linux VM:

ip route

Truncated result:

default via 10.0.2.2 dev enp0s3
192.168.56.0/24 dev enp0s8

This output shows the key routing rules that the system uses to decide how traffic should flow.

Route	Purpose
default via 10.0.2.2	Internet gateway
192.168.56.0	host-only network

Connectivity Tests (Layer-by-layer)

Once the network interfaces and routing table are confirmed, the next step is to verify connectivity step by step. A good troubleshooting approach is to test the network layer by layer, starting from the closest network component and gradually moving outward.

The first component to test is the VirtualBox NAT gateway, which acts as the router that connects the VM to the outside network.

Test NAT Gateway

ping -c 3 10.0.2.2

Purpose:

Verify connection to VirtualBox NAT router

This command sends three ICMP packets to the NAT gateway. If the gateway responds, it confirms that the VM can successfully communicate with the VirtualBox networking layer.

A successful response indicates that the NAT adapter is functioning correctly and that the VM can reach its default gateway. This is an important first step because all external network traffic from the VM must pass through this gateway.

Test Host-only Network

After confirming that the NAT network is functioning correctly, the next step is to test connectivity between the Rocky Linux VM and the Windows host. This communication happens through the Host-only Adapter, which is responsible for enabling direct interaction between the host and the virtual machine.

Command:

ping -c 3 192.168.56.1

Purpose:

Verify VM ↔ Windows host connectivity

This command attempts to send three ICMP packets to the host-only interface on the Windows machine (192.168.56.1). If the network is configured correctly, the host should respond to these requests.

Result:

100% packet loss

This result indicates that the VM is unable to reach the Windows host over the host-only network.

At this point, we know that while the VM has internet connectivity through the NAT adapter, communication with the host system is not yet functioning as expected. This is an important discovery because SSH access relies on this host-only network, so resolving this connectivity issue will be necessary before proceeding further.

Diagnosing the Issue

Checking the interface state

Since the host-only ping test failed, the next step is to verify whether the corresponding network interface inside the VM is actually active. In this setup, the host-only adapter is mapped to the interface enp0s8.

To check the status of the interface, run:

ip link show enp0s8

Result:

state UP

Meaning:

The interface is active.

This confirms that the network interface itself is enabled and operational inside the VM. In other words, the failure of the previous ping test is not caused by the interface being down, which means the issue likely lies elsewhere in the network path—possibly at the host side or within the host-only network configuration.

Checking the Host-Side Network Configuration

Since the VM interface was confirmed to be active, the next step was to verify whether the Windows host actually had the host-only network adapter configured. If the host-side adapter was missing or misconfigured, the VM would have no endpoint to communicate with.

To check this on Windows, I opened the command prompt and ran:

ipconfig

Found:

Ethernet adapter Ethernet 4
IPv4 Address: 192.168.56.1

This output confirms that Windows has a VirtualBox Host-Only Ethernet Adapter configured and assigned the expected IP address within the host-only network range.

At this point, both sides of the network appeared to be configured properly:

The VM interface (enp0s8) was active
The Windows host adapter had the correct IP address

However, the earlier ping test still failed. This suggested that the problem was not with the network configuration itself, but likely related to something else — such as Windows firewall rules blocking ICMP traffic.

Real Connectivity Test — SSH

While the earlier ping test suggested that host-only connectivity might not be working, the real objective of this setup was SSH access. Therefore, the most reliable way to verify the network was to attempt an actual SSH connection from the Windows host to the Rocky Linux VM.

From Windows PowerShell, I executed the following command:

ssh alok@192.168.56.102`

If the network and SSH service were functioning correctly, this command should establish a remote shell session with the virtual machine.

[alok@localhost ~]$

This prompt indicates that the SSH connection was successfully established and that the terminal session is now running on the Rocky Linux virtual machine.

Meaning:

✅ SSH server running
✅ Host-only network working
✅ Authentication successful

Despite the earlier ICMP ping failure, the SSH test confirms that the host-only network is functioning correctly for actual application traffic. This means the VM can now be accessed just like any other remote Linux server.

The system behaves like a real remote Linux server.

Real Connectivity Test — SSH

Although earlier ping tests suggested a possible issue with host-only connectivity, the ultimate goal of this setup was to access the VM via SSH. The most practical way to verify that everything is working is therefore to attempt an actual SSH login from the Windows host.

From Windows PowerShell, the following command was executed to connect to the Rocky Linux virtual machine:

Command executed from Windows PowerShell:

ssh alok@192.168.56.102

If the network configuration and SSH service are functioning correctly, this command should establish a remote shell session with the VM.

[alok@localhost ~]$

This prompt confirms that the SSH connection was successfully established and that the session is now running on the Rocky Linux system inside the VirtualBox VM.

Meaning:

✅ SSH server running
✅ Host-only network working
✅ Authentication successful

Even though the earlier ICMP ping test failed, the successful SSH connection demonstrates that the host-only network is operational for real application traffic.

The system behaves like a real remote Linux server.

Final Working Network State

Component	Status
VirtualBox NAT	✅ Working
Host-only adapter	✅ Working
VM networking	✅ Correct
Routing	✅ Correct
SSH access	✅ Working
Internet access	✅ Available

Lessons Learned

NAT vs Bridged vs Host-only

Mode	Purpose
NAT	Internet access
Host-only	VM ↔ host communication
Bridged	VM appears as separate device on LAN

For hotspot connections, NAT is the most reliable.

Key Commands Used

Linux

ip a
ip route
ip link show enp0s8
ping -c 3 <ip>
systemctl status sshd

Windows

ipconfig
ssh user@vm-ip`

Recommended next steps

Connecting three VM's together and practice:

SSH key authentication
Linux networking
Ansible automation
Docker
Kubernetes clusters

When ready!

Getting acquainted with basic Linux commands commonly used for debugging slow servers

alok-38 — Sat, 07 Mar 2026 05:57:15 +0000

Getting Started with Linux for DevOps: Monitoring CPU, Memory, and More

I keep hearing that Linux remains the dominant operating system for servers, containers, cloud instances, Kubernetes nodes, CI/CD runners, monitoring agents, and virtually every production environment that DevOps engineers touch in 2026 and beyond. Because of this, strong practical Linux skills are expected in almost every serious DevOps, SRE, or Platform Engineering role.

In this post, we won’t tackle complex production issues—like a containerized application not responding or nginx underperforming—just yet. Instead, we’ll focus on preliminary checks such as CPU uptime, memory usage, and more which includes realistic troubleshooting scenarios.

Prerequisites

A Linux distribution (examples here use Rocky Linux on VirtualBox)
SSH access to the virtual machine

1. Installing the required tools

sudo dnf install -y sysstat strace perf iotop

sysstat -> provides sar (system activity reporter), a tool used to collect, report, and save system performance metrics over time.

Live example of sar in action CPU usage in 1-second intervals, 5 times

Let's break it down

%user → CPU used by user processes (your applications) → very low (0%)
%nice → CPU used by nice/low-priority processes → 0%
%system → CPU used by kernel/system processes → small (0.5–5%)
%iowait → CPU waiting for disk I/O → 0% → disk is not a bottleneck
%steal → CPU time taken by hypervisor for other VMs → 0%
%idle → CPU idle → very high (94–99%) → CPU is mostly free

2. Check System Load Safely

uptime
top -b -n 1
vmstat 1 5
iostat -xz 1 5

top -b -n 1 → batch mode prevents cluttering the terminal.
vmstat and iostat give quick snapshots.

Let's view the output of two commands at a time

Let's carefully decode my uptime output

10:26:36 up 57 min,  2 users,  load average: 0.08, 0.02, 0.01

10:26:36 → the current system time when the command was run.
up 57 min → the system has been running continuously for 57 minutes.
2 users → there are 2 active sessions currently logged into the system.
load average: 0.08, 0.02, 0.01 → three numbers representing average system load over (I'm ignoring this part for now)

Decoding the top command `top -b -n 1`

The top command shows a live, interactive view of system processes, CPU, memory, swap, and load averages. I won't try to learn the entire output. I will ignore the table for now.

Here we are executing the top command in batch mode with just one iteration as indicated by this switch -n 1

Let's start with the header line

top - 10:27:26 up 58 min,  2 users,  load average: 0.03, 0.01, 0.00

10:27:26 → current system time.
up 58 min → the system has been running continuously for 58 minutes.
2 users → 2 logged-in users/sessions.
load average: 0.03, 0.01, 0.00 → the system load averages over 1, 5, and 15 minutes.
- Very low numbers → CPU is mostly idle.
- For 2 CPUs, load ≤ 2 is normal. Here, 0.03 is negligible.

2. Tasks

Tasks: 123 total,   1 running, 122 sleeping,   0 stopped,   0 zombie

System is healthy; almost all processes are idle.

3. CPU Usage

%Cpu(s):  0.0 us,  0.0 sy,  0.0 ni, 95.2 id,  0.0 wa,  4.8 hi,  0.0 si,  0.0 st

CPU is almost completely idle; no performance pressure.

4. Memory Usage

MiB Mem :   3653.4 total,   2960.2 free,    439.7 used,    470.5 buff/cache

Memory is abundant; system is far from pressure!

5. Swap Usage

I’m still clarifying my understanding of swap and will write a follow-up post once I’ve learned more.

That wraps things up for now—more to come soon.

VirtualBox Automation Made Easy: Frequently Used VBoxManage Commands

alok-38 — Fri, 06 Mar 2026 08:52:19 +0000

Automate Your VMs Like a Pro with VBoxManage

Ever wanted to automate your VirtualBox VMs without opening the GUI?

Manually starting, stopping, and configuring multiple VMs can be tedious. With VBoxManage and PowerShell, you can automate all of it—modifying resources, managing snapshots, and controlling your VMs from the command line. By the end of this guide, you'll be able to fully automate your VirtualBox workflow for already installed VMs.

Prerequisites

VirtualBox installed (latest version)
PowerShell access
Basic knowledge of the command line
Admin privileges (for some commands)

The examples below use Rocky Linux, but they apply to any Linux distribution with a pre-existing VM.

Configure VM Resources

If you want to adjust RAM, CPUs, or network settings for your existing VM:

# Adjust memory, CPUs, and NIC
VBoxManage modifyvm "RockyLinux" --memory 4096 --cpus 2 --nic1 nat

Change --memory and --cpus to suit your needs.
--nic1 nat provides internet access through NAT.

Manage Storage (Optional)

If you want to add new virtual disks or controllers:

# Add a new SATA storage controller (if needed)
VBoxManage storagectl "RockyLinux" --name "SATA Controller" --add sata

# Create and attach a 50GB virtual disk
VBoxManage createhd --filename "C:\Users\alok\VirtualBox VMs\RockyLinux\ExtraDisk.vdi" --size 50000
VBoxManage storageattach "RockyLinux" --storagectl "SATA Controller" --port 1 --device 0 --type hdd --medium "C:\Users\alok\VirtualBox VMs\RockyLinux\ExtraDisk.vdi"

Start, Pause, and Stop the VM

Control your VM without opening the GUI:

# Start VM (headless mode)
VBoxManage startvm "RockyLinux" --type headless

# Pause the VM
VBoxManage controlvm "RockyLinux" pause

# Resume the VM
VBoxManage controlvm "RockyLinux" resume

# Power off the VM
VBoxManage controlvm "RockyLinux" poweroff

Snapshots

Take and restore snapshots to save or revert VM states:

# Take a snapshot
VBoxManage snapshot "RockyLinux" take "BeforeUpdate"

# Restore a snapshot
VBoxManage snapshot "RockyLinux" restore "BeforeUpdate"

Verify VM Settings

Always check that your changes have applied correctly:

VBoxManage showvminfo "RockyLinux"

Look for updated memory, CPU, NIC, and disk information.

Final Notes

Use consistent VM names (RockyLinux) to avoid errors.
All commands are idempotent, meaning you can run them repeatedly without breaking the VM.
Snapshots are great for testing updates or configuration changes safely.

Backend Foundations Lab — Full Walkthrough

alok-38 — Fri, 27 Feb 2026 09:08:38 +0000

How I Finally gained a surface level intuition of how the web works (By Building a primitive Backend)

When people say “learn how the web works,” it usually sounds abstract — DNS, client–server model, HTTP requests, ports — a bunch of terms that don’t really click until something breaks. Instead of just reading about it, I decided to set up a real Ubuntu virtual machine, run a backend server on it, and connect to it from my own computer. Along the way, I hit firewall issues, port forwarding problems, and confusing network errors — and that’s exactly when everything started to make sense. This post is a hands-on walkthrough of how I finally understood how the web actually works by building and debugging a real client–server setup.

Setup Overview

To understand how the web actually works in practice, I created a small, local client–server environment that mirrors how real backend systems operate in production — just on my own machine. The setup looked like this:

Host machine (Client):
My Windows laptop, acting as the client making HTTP requests using curl and SSH.
Virtual machine (Server):
An Ubuntu VM running inside VirtualBox, acting as the backend server.
Networking:
The VM was configured using NAT with port forwarding, so requests from my Windows machine could reach services running inside the VM (similar to how traffic reaches servers behind NAT or load balancers in the cloud).
Backend service:
A simple Python HTTP server running on the VM to simulate a backend API/server.
Access method:
- SSH into the VM to manage the server
- HTTP requests from Windows to the VM to simulate real client–server communication

Client (Windows)
      |
      |  HTTP request (curl / browser)
      v
VirtualBox NAT (port forwarding)
      |
      v
Ubuntu VM (Python backend server)
      |
      v
HTTP response back to client

🎯 Goal

Understand How the web works (DNS + client–server model) by:

running a server on a Ubuntu VM
connecting to it from Windows

- debugging real network + firewall issues

Connected to Ubuntu VM over SSH (Client → Server)

Command (from Windows)

ssh alok@localhost -p 2222

📌 What this means

Windows = client
Ubuntu VM = server
Port forwarding:

Windows:2222 → VM:22

🧠 New thing I noticed

Last login: ... from 10.0.2.2

✅ Why that happened

VirtualBox NAT hides your real IP
VM sees the NAT gateway (10.0.2.2)
This is how real servers behave behind NAT/load balancers (like on AWS)

2️⃣ Started a web server on the VM (Become the Server)

✅ Command (on VM)

python3 -m http.server 8000 --bind 0.0.0.0

🧠 What this did

Started an HTTP server
Listening on:

0.0.0.0:8000

- `0.0.0.0` = accept connections from outside the VM

3️⃣ First attempt to access from Windows failed

❌ Command (on Windows)

curl http://localhost:8000

❌ Error

Unable to connect to the remote server

🧠 Root cause

Even though:

Server was running ✅
Port forwarding was set ✅

The VM firewall (ufw) was blocking port 8000

4️⃣ Checked firewall (Found the real problem)

✅ Command (on VM)

sudo ufw status

📌 Output (important part)

Status: active
OpenSSH ALLOW
22 ALLOW
3999 ALLOW

🧠 What this means

Port 8000 was NOT allowed

- So Windows → VM:8000 was blocked

5️⃣ Fixed firewall (Opened port 8000)

✅ Commands (on VM)

sudo ufw allow 8000/tcp
sudo ufw reload

✅ Verified

sudo ufw status

Now shows:

8000/tcp ALLOW Anywhere

6️⃣Verified server was running (Correct diagnosis)

✅ Command

sudo ss -tulnp | grep 8000

Output

tcp LISTEN 0.0.0.0:8000 users:(("python3",pid=1989))

Meaning

Python server is alive
Listening on port 8000
Accepting external connections

- No need to restart it

7️⃣Final success: Windows → VM HTTP request worked 🎉

✅ Command (on Windows)

curl.exe http://localhost:8000

✅ Output

<h1>Hello from my backend server 👋</h1>
<p>This response came from my Ubuntu VM.</p>

🗺 Final working network flow

Windows (Client)
   ↓ curl http://localhost:8000
VirtualBox NAT (port forwarding)
   ↓
Ubuntu VM (Server)
   ↓
Python HTTP Server
   ↓
HTML response back to Windows

🧠 Core Concepts I Actually Learned (not just memorized)

Concept	I experienced it
Client	Windows using `curl`
Server	Ubuntu VM running Python
HTTP	Requests + responses
Ports	22 (SSH), 8000 (web server)
DNS	Earlier with `dig google.com`
NAT	`10.0.2.2` hiding your real IP
Firewall	`ufw` blocking then allowing 8000
Binding	`0.0.0.0` vs `localhost`
Infra debugging	App was fine, network blocked
Real-world behavior	Same as cloud servers on AWS

🏁 Big takeaway

I didn’t just “learn how the web works.”
I debugged real backend infrastructure problems:

Server running but unreachable
Firewall blocking traffic
NAT hiding client IP
Port already in use
Binding to correct network interface

Fixing “VBoxManage Is Not Recognized” in PowerShell (Windows + VirtualBox)

alok-38 — Fri, 27 Feb 2026 05:58:39 +0000

Fixing “VBoxManage Is Not Recognized” in PowerShell on Windows

If you’ve tried running VBoxManage in PowerShell and hit the error “VBoxManage is not recognized as the name of a cmdlet,” it usually means Windows can’t find the VirtualBox executable on your PATH. In this post, I’ll show you why this happens and the exact steps to fix it on Windows so you can get back to managing your virtual machines from the command line.

🔍 What does this mean?

PowerShell couldn’t find VBoxManage.exe because the VirtualBox install directory was not in your PATH environment variable.

✅ How We Fixed It (Verified VBoxManage Works)

We ran VBoxManage using its full path:

& "C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" --version

✅ Result (Success Output)

7.2.6r172322

🎯 What this confirmed

VirtualBox is installed correctly
VBoxManage.exe exists and works
The only issue was that PowerShell didn’t know where to find it automatically

This is pretty cumbersome, right?

Let’s add this utility to the PATH so it’s easier to use going forward.

Open the start menu and type the word "edit" (without the quotes) and click Edit the system environment variables
Click Environment variables at the bottom

Make sure the Path variable is already selected under user

Click Edit and then click New and add C:\Program Files\Oracle\VirtualBox if this is the location of the binary.

Going forward, you can start using the VBoxManage utility to manage your Virtual machines.

How to Access SSH and HTTP from Windows on a VMware Ubuntu VM

alok-38 — Fri, 13 Feb 2026 05:06:54 +0000

Commands to execute and test both SSH and HTTP after you set up a Ubuntu VM on VMware workstation pro

# Bring interface up
sudo ip link set ens33 up
sudo dhclient -v ens33

# Check IP & routes
ip a
ip route

# Test Internet & DNS
ping -c 3 8.8.8.8
ping -c 3 google.com

# Set temporary DNS
sudo nano /etc/resolv.conf
# nameserver 8.8.8.8
# nameserver 8.8.4.4

# Install SSH and HTTP servers
sudo apt update
sudo apt install openssh-server apache2 nginx -y
sudo systemctl enable --now ssh
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp

# Resolve Apache/nginx port conflict
sudo nano /etc/apache2/ports.conf       # Listen 8080
sudo nano /etc/apache2/sites-available/000-default.conf  # <VirtualHost *:8080>
sudo systemctl restart apache2
sudo systemctl enable apache2

# Check running services & listening ports
sudo systemctl status apache2
sudo systemctl status nginx
sudo lsof -i :80
sudo lsof -i :8080

# VMware NAT port forwarding
# Host → VM mapping:
# 2222 → 22 (SSH)
# 8080 → 8080 (Apache)
# 80 → 80 (nginx)

# Restart VMware NAT services (Windows)
# VMware NAT Service
# VMnetDHCP Service

# Test TCP connectivity from Windows
Test-NetConnection -ComputerName 127.0.0.1 -Port 2222

# SSH from Windows
ssh alok@127.0.0.1 -p 2222

# HTTP from Windows
# nginx → http://127.0.0.1
# Apache → http://127.0.0.1:8080

Reliable SSH to Ubuntu VMs on VMware Workstation: Bypassing Bridged Wi-Fi Issues

alok-38 — Thu, 12 Feb 2026 05:24:14 +0000

How to SSH into Ubuntu VMs on VMware Workstation Using NAT and Port Forwarding

Connecting to Ubuntu virtual machines from a Windows host can be tricky, especially when using Bridged networking over Wi-Fi adapters like Killer Wi-Fi, which often block VM traffic. In this guide, we show a simple, reliable method using NAT networking and port forwarding, allowing you to SSH into your VM safely and consistently without dealing with network or firewall headaches.

1️⃣ The Problem

I wanted to SSH from my Windows host into a Ubuntu VM on VMware Workstation Pro.

My first attempt used Bridged networking, like my EC2 setup:

Windows Host ↔ VM via bridged IP (192.168.45.100)

SSH timed out, and ping failed.
Firewall on Windows wasn’t the cause — disabling it changed nothing.

Why Bridged failed:

I'm using a Killer Wi-Fi adapter. Many modern Wi-Fi cards don’t handle Bridged VM traffic reliably.
Even though the VM and host were “on the same subnet” and the VMware Bridge Protocol was enabled, packets from Windows could not reach the VM.
Bottom line: Bridged looked right but couldn’t communicate over Wi-Fi.

2️⃣ First Attempts / Misleads

Tried to SSH using the old Bridged IP (192.168.45.100) — failed.
Tried ssh 127.0.0.1 locally inside the VM — worked, but only from inside the VM itself.
Firewall checks confirmed it wasn’t blocking the traffic.
VMware settings (VMnet0, VMnet1) were correct for Bridged / Host-only, but Bridged Wi-Fi still didn’t work.

➡ At this point, I realized Bridged over Wi-Fi is unreliable, and we needed a NAT + port forwarding solution.

3️⃣ Switching to NAT

Windows Host ↔ NAT (VMnet8) ↔ VM

4️⃣ SSH Works via NAT

ssh -p 2222 alok@127.0.0.1

Worked immediately — host connected to VM via NAT + port forwarding.
Ping and firewall issues no longer mattered.
Bridged issues were completely bypassed.

5️⃣ Optional SSH Config Shortcut

Added to C:\Users\alok\.ssh\config:

Host vm
  HostName 127.0.0.1
  User alok
  Port 2222

Now you can simply run:

ssh vm

6️⃣ Key Takeaways

Step/Problem	How We Solved It
Bridged networking fails over Wi-Fi	Use NAT instead; Wi-Fi cards often block Bridged
Old IP still assigned to VM	Release old IP (`sudo dhclient -r`) & request new
Host cannot reach VM NAT IP	Set up VMware NAT port forwarding (host:2222 → VM:22)
Long SSH commands	Use SSH config shortcut (`ssh vm`)
Reliable Wi-Fi-safe connection	NAT + port forwarding works even on Wi-Fi adapters

What Actually Happens When You SSH into an EC2 Instance

alok-38 — Wed, 11 Feb 2026 11:46:54 +0000

From `ssh ec2` to TCP SYN: Tracing a Connection End-to-End

When an SSH connection to my EC2 instance timed out, I could’ve stopped at “fix the security group and move on.”
Instead, I decided to trace what actually happens when you run ssh ec2 — from the packet leaving my laptop,
through the Windows kernel and AWS firewalls, all the way to the SSH daemon on the server.
This post is a hands-on walk through the real software stack beneath the abstractions: TCP handshakes, cloud networking,
kernel drivers, and cryptographic key exchange — observed live on the wire.

The Original Problem

I ran:

ssh ec2

I got:

Connection timed out

But when I changed AWS Security Group from:

❌ Custom
to
✅ My IP

SSH started working.

Root cause (cloud side)

My EC2 Security Group firewall was blocking port 22 from your IP.

I got curious and I decided to understand what goes on under the hood.

Step 1 – Try to capture packets with Wireshark

I installed Wireshark and tried capturing traffic.

But:

❌ No packets were captured

This told us something important:
Wireshark GUI was running, but Windows kernel was not giving it packets.

Step 2 – Diagnose Npcap (kernel capture driver)

Wireshark relies on Npcap to hook into the network stack.

But when I executed this command on the power shell,

sc query npcap

Returned nothing.

Meaning:

The packet capture driver was not installed / bound correctly.

Step 3 – Discover Npcap was installed but not activated

I found:

Get-ChildItem "C:\Program Files\Npcap"

Npcap files existed, including:

npcap.sys
NPFInstall.exe

So the driver was present on disk — but not attached to my network interface.

Step 4 – Manually bind the kernel driver (real infra work)

cd "C:\Program Files\Npcap"
.\NPFInstall.exe -i2

Output:

Npcap Packet Driver (NPCAP) (WiFi version) has been successfully installed!

This did the critical thing:

✅ Attached Npcap to your Wi-Fi network adapter
✅ Inserted itself into the Windows networking pipeline

then:

.\NPFInstall.exe -r2

Then rebooted.

Step 5 – Verify kernel drivers are actually loaded

After reboot:

driverquery | findstr /i npcap

Output:

npcap        Npcap Packet Driver
npcap_wifi   Npcap Packet Driver

My OS is now capable of exposing raw packets to userland tools.

Step 6 – Launch Wireshark correctly

Start-Process "C:\Program Files\Wireshark\Wireshark.exe" -Verb RunAs

Step 7 – Observe the TCP handshake (what I originally wanted)

Now when I run:

ssh ec2

And filter in Wireshark:

tcp.port == 22

I can see:

68  4.469707    172.22.55.51    54.90.199.89    TCP 66  56959 → 22 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=256 SACK_PERM
70  4.890446    54.90.199.89    172.22.55.51    TCP 66  22 → 56959 [SYN, ACK] Seq=0 Ack=1 Win=62727 Len=0 MSS=1318 SACK_PERM WS=128
71  4.890701    172.22.55.51    54.90.199.89    TCP 54  56959 → 22 [ACK] Seq=1 Ack=1 Win=65280 Len=0
72  4.909598    172.22.55.51    54.90.199.89    SSHv2   87  Client: Protocol (SSH-2.0-OpenSSH_for_Windows_9.5)
76  5.362436    54.90.199.89    172.22.55.51    SSHv2   75  Server: Protocol (SSH-2.0-OpenSSH_8.7)
77  5.362436    54.90.199.89    172.22.55.51    TCP 54  22 → 56959 [ACK] Seq=22 Ack=34 Win=62848 Len=0
78  5.385712    172.22.55.51    54.90.199.89    TCP 1372    56959 → 22 [ACK] Seq=34 Ack=22 Win=65280 Len=1318 [TCP PDU reassembled in 79]
79  5.385712    172.22.55.51    54.90.199.89    SSHv2   168 Client: Key Exchange Init
88  5.790794    54.90.199.89    172.22.55.51    SSHv2   990 Server: Key Exchange Init
90  5.799032    172.22.55.51    54.90.199.89    SSHv2   102 Client: Elliptic Curve Diffie-Hellman Key Exchange Init

I didn’t just learn “SSH uses TCP”.

I proved it with your own packets.

The Real Lessons

1️⃣ Cloud firewalls aren’t “abstract”

They literally drop packets on the wire.

2️⃣ Observability requires kernel hooks

You can’t “see networking” without drivers.

3️⃣ Infra debugging is layered

App (ssh)
↓
OS networking stack
↓
Kernel drivers
↓
Network interface
↓
Cloud firewall
↓
Remote kernel

Full Lab: Accessing and Editing Nginx on Ubuntu VM via VS Code

alok-38 — Sun, 08 Feb 2026 09:44:46 +0000

1️⃣ Accessing the VM via SSH in VS Code

Goal: Edit Nginx files (/var/www/html/index.nginx-debian.html) directly from Windows using VS Code.
Setup steps:
1. Installed VS Code and Remote – SSH extension.
2. Created/edit SSH config (~/.ssh/config) with:

Host ubuntu-vm
    HostName 192.168.0.169
    User alok
    Port 22

Connected via Remote-SSH: Connect to Host → ubuntu-vm.

Outcome: Successfully opened the VM’s filesystem and terminal in VS Code.

2️⃣ First Issue: Permission denied in VS Code

Error:

Failed to save 'index.nginx-debian.html': Unable to write file vscode-remote://ssh-remote+ubuntu-vm/var/www/html/index.nginx-debian.html (NoPermissions)

Cause:
- /var/www/html and index.nginx-debian.html are owned by root:
```
 -rw-r--r-- 1 root root index.nginx-debian.html
```
- VS Code SSH session runs as alok, so it cannot write to root-owned files.
Why this happens:
- Nginx web root is restricted to prevent accidental edits by non-root users.

3️⃣ Troubleshooting and Solution

Option A: Edit with sudo in terminal (quick fix)

sudo vim /var/www/html/index.nginx-debian.html

Option B: Change ownership for lab use (I prefer this)

sudo chown -R alok:alok /var/www/html

Explanation:
- chown = change ownership
- -R = recursively for all files/folders in /var/www/html
- alok:alok = user alok and group alok
Effect: Your VS Code SSH session now has write access, solving EACCES errors.

✅ Important: Safe for lab/development. Not recommended on production servers.

4️⃣ Editing the Nginx default page

Opened /var/www/html/index.nginx-debian.html in VS Code.
Replaced default HTML with:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>NginX Demo Page</title>
</head>
<body>
    <h1>NginX demo page from Ubuntu VM</h1>
</body>
</html>

Saved file successfully after fixing ownership.

Result: Accessing http://192.168.0.169/ from Windows Chrome or other LAN devices showed the updated page.

5️⃣ Exploring the default Nginx setup

Web root: /var/www/html → place static HTML, CSS, JS files here.
Configuration files: /etc/nginx/sites-available/default

Key parts of default Nginx server block:

server {
    listen 80 default_server;
    listen [::]:80 default_server;

    root /var/www/html;
    index index.html index.htm index.nginx-debian.html;

    server_name _;

    location / {
        try_files $uri $uri/ =404;
    }
}

root /var/www/html → serves files from web root
index ... → default file names
location / → maps URL paths to file system

Learning points:

Nginx serves files based on server blocks and root.
Changes in /var/www/html are immediately visible after reload.

6️⃣ Testing and verification

Edited index.html → refreshed in browser → confirmed changes appear.
Checked logs for troubleshooting:

sudo tail -f /var/log/nginx/access.log
sudo tail -f /var/log/nginx/error.log

Logs confirmed requests hitting the server and showed no errors.

7️⃣ Key Lessons Learned

SSH with VS Code:

Configuring ~/.ssh/config makes connecting to VM fast and repeatable.

Permissions are critical:

Web root files are root-owned → editing as normal user fails.
chown -R alok:alok /var/www/html fixes permissions in a safe lab environment.

Default Nginx setup:

/var/www/html = default web root
/etc/nginx/sites-available/default = default server config
Editing files here immediately updates the served page

Testing workflow:

Always check LAN access using browser
Monitor logs for access/errors
Use VS Code Remote-SSH for easy editing

✅ Outcome

VM is fully reachable from Windows host and LAN devices.
Nginx serves my custom HTML correctly.
VS Code edits work without errors thanks to ownership fix.
Foundation is ready for next steps: multiple sites, reverse proxy, web apps, firewall, and security configuration.

How to Access Nginx Homepage on Your Smartphone from an Ubuntu VM

alok-38 — Sun, 08 Feb 2026 08:46:34 +0000

🧪 Accessing Nginx from Mobile: Full Journey

Accessing your Nginx web server from a smartphone might seem tricky at first, especially when it’s running inside an Ubuntu VM on VMware. Whether you’re experimenting with web development, learning DevOps, or just testing your local projects, being able to view your Nginx homepage on any device is a crucial skill. In this guide, we’ll walk you through every step — from setting up the VM’s network correctly, configuring Nginx, and troubleshooting connectivity issues, to finally accessing your server from a phone or other devices on the same network. By the end, you’ll understand how LAN networking, private IPs, and bridging work in practice, and you’ll be confidently serving your Nginx pages across multiple devices.

💻 Tech Stack

Virtualization: VMware Workstation
Guest OS: Ubuntu (any recent LTS, e.g., 22.04)
Web Server: Nginx (latest stable)
Networking:
- Bridged networking (VMnet0)
- Host firewall: UFW (Ubuntu)
- LAN access for devices on same Wi-Fi
Host OS: Windows 10/11 (used to SSH and browser test)
Client Devices:
Windows browser (Chrome/Edge)
Smartphone (iOS/Android) on same Wi-Fi
Optional Tools:
SSH (PowerShell or terminal)
curl (for local testing)
ngrok / localtunnel (if exposing Nginx outside LAN)

1️⃣ Initial Attempt

Situation: VM is running Ubuntu with Nginx. IP on VM: 192.168.45.100 (NAT network).
From Windows host: http://192.168.45.100 works ✅
From phone: http://192.168.45.100 times out ❌

Observation: Windows can access VM (same host), phone cannot.

2️⃣ Diagnosing the problem

ping 192.168.45.100 from Windows host → timed out at first when NAT IP was used with earlier network misconfiguration.
ssh alok@192.168.45.100 → connection timed out
hostname -I on Ubuntu VM showed both NAT and Bridged IPs after some bridging attempts:

192.168.45.100 192.168.0.169

ip route showed default via NAT: 192.168.45.2

Conclusion:

The VM had two IPs and the default route pointed to NAT, so devices outside Windows host could not reach the VM.
Network was inconsistent due to VMware NAT + Bridged mix.

3️⃣ Switching to Bridged networking

In VMware Workstation:
- Network adapter set to Bridged (explicit Wi-Fi adapter selected)
- ✅ “Replicate physical network connection state” checked
Virtual Network Editor checked:
- VMnet0 → Bridged → Wi-Fi adapter
- VMnet1 → Host-only → ok
- VMnet8 → NAT → not used

Observation:

Ubuntu still had old NAT IP (192.168.45.100)
Default route still pointed to NAT
Windows host could reach Bridged IP (192.168.0.169), but the phone could not because it was on mobile data.

4️⃣ Cleaning up Ubuntu network

Removed NAT IP:

sudo ip addr del 192.168.45.100/24 dev ens33

Deleted old default route (if present):

sudo ip route del default via 192.168.45.2

Renewed DHCP to get proper LAN IP:

sudo dhclient -v -r ens33
sudo dhclient -v ens33

Verified with:

hostname -I
ip route

Result:

192.168.0.169
default via 192.168.0.1 dev ens33

Clean, single IP on LAN → default route correct.

5️⃣ Testing Nginx from Windows

http://192.168.0.169 → Nginx default page loads ✅

Observation: Works on Windows because host and VM are on same LAN/subnet.

7️⃣ Solution: phone must be on same LAN

Connected phone to same public Wi-Fi as laptop/VM
http://192.168.0.169 on phone → works ✅

Explanation:

Both phone and VM are now on same subnet
Phone can send packets directly to VM
Nginx responds → page loads

8️⃣ Key Networking Lessons

Symptom	Cause	Fix / Concept
Page loads on Windows, not phone	Phone on different network (carrier)	Connect phone to same Wi-Fi
VM has two IPs (`192.168.45.x` + `192.168.0.x`)	NAT + Bridged overlap	Remove NAT IP and renew DHCP
SSH/ping fail	Wrong default route	Reset default route to LAN gateway
Page loads on LAN only	Nginx listens on all interfaces	Ensure `0.0.0.0:80` in Nginx

Important Concepts:

NAT vs Bridged
- NAT → VM hidden behind host → only host can reach VM
- Bridged → VM is like a real LAN computer → any device on LAN can reach
Private IPs are local
- 192.168.x.x not routable over internet → devices outside LAN cannot reach
Default route matters
- All traffic leaves via default gateway → stale NAT route breaks connectivity

✅ Optional: Access VM outside LAN

Use a tunneling tool like ngrok or localtunnel
Port-forward on your router to make VM public (not recommended for public Wi-Fi)

Nginx worked from Windows because host and VM shared the LAN; it failed on the phone because the phone was on a different network. Connecting the phone to the same Wi-Fi brought it into the same subnet, making the VM reachable.

How to Host a Website on an Ubuntu VM Using VMware and Nginx and get unstuck if it doesn't load (Step-by-Step Guide)

alok-38 — Sun, 08 Feb 2026 06:08:20 +0000

🧪 Ubuntu VM Web Server Lab (VMware + SSH + Nginx)

A hands-on lab to learn Linux web servers, networking, firewall rules, and real-world troubleshooting (plus how these skills transfer to AWS EC2 and DevOps).

🧰 Tech Stack

Windows 10/11 (Host OS)
Ubuntu Linux (Guest VM)
VMware Workstation
Nginx Web Server
SSH (from PowerShell)

🎯 Why I installed Nginx

I installed Nginx to:

Practice hosting a web service on a Linux server
Test networking between Windows (host) and Ubuntu VM (guest)
Learn real-world troubleshooting: firewall, ports, VM networking
Build skills that directly transfer to AWS EC2 and DevOps work

🛠 Setup Overview

Host OS: Windows
VM: Ubuntu on VMware Workstation
Access method: SSH from PowerShell
Goal: Access a web page on the VM from Windows browser

1️⃣ Connect to Ubuntu VM via SSH (from PowerShell)

ssh alok@<VM_IP>

2️⃣ Install and start Nginx on Ubuntu

sudo apt update
sudo apt install nginx -y
sudo systemctl start nginx
sudo systemctl enable nginx

Verify Nginx is running:

sudo systemctl status nginx

Test locally on the VM:

curl http://localhost

✅ This confirmed Nginx was working inside the VM.

3️⃣ Find the VM’s IP address

hostname -I

Example:

192.168.80.129

4️⃣ Try accessing from Windows browser

http://192.168.80.129

❌ Issue: Page kept loading / timed out
Error:

ERR_CONNECTION_TIMED_OUT

5️⃣ Check Ubuntu firewall (UFW)

sudo ufw status

Output showed:

Port 22 (SSH) allowed
Ports 3000, 5000, 8000 allowed
❌ Port 80 NOT allowed

🔧 Fix: Allow HTTP (port 80)

sudo ufw allow 80/tcp
sudo ufw reload

Tried browser again ❌
Still timing out → meaning firewall wasn’t the only issue.

6️⃣ Confirm Nginx was not the problem

sudo systemctl status nginx
curl http://localhost

Result:

Nginx: ✅ running
curl localhost: ✅ works

👉 Conclusion:

App layer is fine. Problem is networking between Windows ↔ VM.

7️⃣ Verify VMware network mode

Checked:

VMware → VM Settings → Network Adapter
Mode: ✅ NAT (already selected)

So NAT wasn’t misconfigured, but NAT services might be broken.

8️⃣ Fix VMware NAT networking (host-side issue)

On Windows:

Press Win + R
Run:

services.msc

Restart:

✅ VMware NAT Service
✅ VMware DHCP Service

This fixed the broken network path between Windows and the VM.

9️⃣ Test again from Windows

In Chrome:

http://192.168.80.129

✅ Nginx page loaded successfully
Problem solved 🎉

🧠 Root Cause Summary

Layer	Status
App (Nginx)	✅ Working
Local access	✅ `curl localhost` works
Ubuntu firewall	❌ Port 80 blocked (fixed)
VMware NAT service	❌ Broken on Windows (fixed by restarting services)
Browser access	❌ Timeout → ✅ Works after fixes

🔍 Troubleshooting Commands Used

On Ubuntu VM

sudo apt update
sudo apt install nginx -y
sudo systemctl start nginx
sudo systemctl enable nginx
sudo systemctl status nginx
curl http://localhost
hostname -I
sudo ufw status
sudo ufw allow 80/tcp
sudo ufw reload

On Windows

ssh alok@<VM_IP>
ping <VM_IP>

Windows UI:

services.msc
- Restart VMware NAT Service
- Restart VMware DHCP Service

💡 What this taught me (real-world skills)

How web servers work on Linux
How ports and firewalls affect access
How VM networking (NAT) works
How to isolate problems by layer:
- App
- Firewall
- Network
- Host services

This is exactly the same thinking I'll use when:

An EC2 instance won’t load
A Docker container isn’t reachable
A service times out in production

DEV Community: alok-38

Host a Simple Python App on a Virtual Machine (Step-by-Step)

Serve a Python App from a VM: From Local Server to Public Access

Let's learn how to:

1️⃣ Environment Setup

2️⃣ Start the Python HTTP Server on the VM

Access from the Host Machine

✅ Expected output:

Access from External Devices / Smartphone

Content Served by Python Server

Traffic Flow Diagram

Rocky Linux VirtualBox VM Networking Setup & SSH Access Using Windows 11 with Smartphone Hotspot

SSH into Rocky Linux VM on VirtualBox (Windows 11 + Mobile Hotspot Setup)

Set up

Initial Objective

VirtualBox Network Architecture

Adapter 1 — NAT (Internet access)

Adapter 2 — Host-Only Adapter (VM ↔ Host communication)

Architecture Diagram

Network Verification Commands

Check interfaces

Verify Routing Table

Connectivity Tests (Layer-by-layer)

Test NAT Gateway

Test Host-only Network

Diagnosing the Issue

Checking the Host-Side Network Configuration

Real Connectivity Test — SSH

Real Connectivity Test — SSH

Final Working Network State

Lessons Learned

Key Commands Used

Recommended next steps

Getting acquainted with basic Linux commands commonly used for debugging slow servers

Getting Started with Linux for DevOps: Monitoring CPU, Memory, and More

Prerequisites

1. Installing the required tools

Let's break it down

2. Check System Load Safely

Let's view the output of two commands at a time

Decoding the top command top -b -n 1

Let's start with the header line

2. Tasks

3. CPU Usage

4. Memory Usage

5. Swap Usage

VirtualBox Automation Made Easy: Frequently Used VBoxManage Commands

Automate Your VMs Like a Pro with VBoxManage

Prerequisites

Configure VM Resources

Manage Storage (Optional)

Start, Pause, and Stop the VM

Snapshots

Verify VM Settings

Final Notes

Backend Foundations Lab — Full Walkthrough

How I Finally gained a surface level intuition of how the web works (By Building a primitive Backend)

Setup Overview

🎯 Goal

- debugging real network + firewall issues

Connected to Ubuntu VM over SSH (Client → Server)

Command (from Windows)

📌 What this means

🧠 New thing I noticed

✅ Why that happened

2️⃣ Started a web server on the VM (Become the Server)

✅ Command (on VM)

🧠 What this did

- 0.0.0.0 = accept connections from outside the VM

3️⃣ First attempt to access from Windows failed

❌ Command (on Windows)

❌ Error

🧠 Root cause

The VM firewall (ufw) was blocking port 8000

4️⃣ Checked firewall (Found the real problem)

✅ Command (on VM)

📌 Output (important part)

🧠 What this means

- So Windows → VM:8000 was blocked

5️⃣ Fixed firewall (Opened port 8000)

Decoding the top command `top -b -n 1`

- `0.0.0.0` = accept connections from outside the VM

From `ssh ec2` to TCP SYN: Tracing a Connection End-to-End