My Linux Devlog: From WSL to the Cloud (Days 1–5)

Tyrone Tabornal — Mon, 16 Feb 2026 09:25:43 +0000

My Linux Devlog: From WSL to the Cloud (Days 1–5)

Starting a journey into Linux server administration feels like being dropped into a dark room where you only have a flashlight. You know there’s a powerful machine in there, but you’re only seeing one small circle of light at a time.

TL;DR: I’m taking the Linux Upskill Challenge to move beyond just "using" Linux and start actually managing it. I want to handle my own remote servers for my full-stack and AI projects instead of relying on magic. My setup is WSL locally, connecting to a Google Cloud Platform (GCP) Virtual Machine.

Here is everything I learned in my first week.

Day 01: The Gateway & Why SSH?

The first hurdle is getting through the "Front Door." When managing a server halfway across the world, you’re communicating over the public internet.

The Problem: The internet is fundamentally insecure. Data transmitted around the internet is pure plaintext. If a hacker is on the same network, they can easily intercept it. If you send your password over a standard connection, they can just "read" it as it passes by.

The Solution: Secure Shell (SSH). It creates an encrypted tunnel between my local machine and the remote server. Even if someone intercepts the data, it looks like gibberish.

Key-Based Authentication vs. Passwords
While you can use passwords, bots constantly try to brute-force them. Instead, I use Asymmetric Cryptography (Key Pairs):

Public Key: Stays on the server (the "lock").
Private Key: Stays on my local machine (the "physical key").

The server sends a "challenge" that only my private key can solve. No private key, no entry.

# Connecting via WSL, using the -i flag to point to my private key
ssh -i ~/.ssh/id_ed25519 gcp-tyronemt@34.9.x.x

The "First 5 Minutes" Health Check
Once inside, I run these to check the "patient's" vitals:

uptime: How long it’s been running and the load average.
free -m: Available RAM. If this is zero, apps crash.
df -h: Disk space. Making sure logs haven't filled up the hard drive.
htop (or top): Real-time view of CPU usage (the Linux Task Manager).
uname -a: Displays the kernel version and system architecture.

Key Takeaway (Day 1): SSH is non-negotiable for remote connections because the internet defaults to plaintext. Key pairs are infinitely safer than passwords, and you should always check your server's health (free, df) the moment you log in.

Day 02: RTFM and Navigation

In ops, everything starts with the manual. But reading it efficiently is a skill.
How to actually read the manual:

man [command]: The standard reference (e.g., man ls).
help [command]: Used for built-in shell commands like cd or export that lack man pages. (Run type [command] to see if a command is built-in or external).
tldr [command]: The best one. It gives practical, real-world examples instead of a massive wall of text. (sudo apt install tldr to get it).
apropos "[keyword]": Super useful when you know what you want to do, but forgot the command name.

Navigating the Tree
The Linux file system is a tree starting at the root (/).

pwd: Print Working Directory. Tells you exactly where you are.
cd /var/log: Absolute path (starts from root).
cd ~ (or just cd): Return to your Home Directory.
cd -: Jump back to the last directory you were in.
ls -ltra: The pro way to list files—long format, time-sorted, reverse, and all (including hidden files).

File Manipulation

mkdir [name]: Create a folder.
touch [filename]: Create an empty file.
rm -r [directory]: Deletes a folder and everything inside it. (Use rm -ri for interactive mode so it warns you before deleting important data!)

Key Takeaway (Day 2): Reading the manual (man, tldr) saves you from guessing, and navigating the system gets much easier once you understand that everything branches out from the root /.

Day 03: Administrative Power & User Management

This day focused on how to safely handle the power trip of being a sysadmin.
Who has the power?

root: The superuser. Has total power. A single typo here can destroy the server. Best practice: never log in directly as root.
sudoers: Regular users granted super privileges via the sudo command.
Regular Users: Limited to their own home directory (~). Cannot make global changes like installing packages.

What is sudo?
It stands for "SuperUser Do". It's a single command executed with root privileges, but it is not root itself. It acts as an audit to prevent mistakes.

I tried running cat /etc/shadow (which holds hashed passwords) and was denied. Running sudo cat /etc/shadow worked.
To become root temporarily: sudo -i launches a full root shell.
To see who logged in: last. To see failed login attempts (like bots guessing passwords): sudo lastb.

Global Administrative Tasks

Check/Change Hostname: hostnamectl -> sudo hostnamectl set-hostname [name]. (Note: on cloud providers, you often need to set preserve_hostname: true in /etc/cloud/cloud.cfg so it survives a reboot).
Check/Change Timezone: timedatectl -> sudo timedatectl set-timezone [Region/City]. Timezones are crucial because they affect scheduled tasks and log timestamps!

Key Takeaway (Day 3): sudo is a safety net. Never log in as root directly. Always make sure your timezone is set correctly so your server logs make sense when you need to debug an issue.

Day 04: Installing Software & The File Structure

This module covers the Advanced Package Tool (APT) and where things actually live in Linux.
Package Management (APT)
We get software from "Repositories" (remote servers). The list of these repos lives in /etc/apt/sources.list.d/ubuntu.sources.

Search: apt search "[keyword]"
Install: sudo apt install [package_name] (Requires sudo because installations are global).

The File System Hierarchy (man hier)

/root: The root user's home folder.
/home: Folders for standard users.
/sbin: System binaries (administrative commands restricted to root).
/etc: The central hub for all global configuration files.
/var/log: Where system and security logs live.

Configs and Logs are just Text!
In Linux, configurations are just plain text files you can edit right in the terminal.

/etc/passwd: User account info.
/etc/ssh/sshd_config: Controls how SSH behaves.
/var/log/auth.log: Records all sudo usage and logins.

(I also installed Midnight Commander (sudo apt install mc), a visual text-based file manager. You just type mc, use F3 to view files, and F10 to exit.)

Key Takeaway (Day 4): Linux is essentially just a bunch of text files. If you want to change settings, look in /etc. If you want to see what went wrong, look in /var/log.

Day 05: More, Less, and CLI Efficiency

Managing text files directly in the terminal is a mandatory skill.
Viewing & Editing

less vs more: Use less to read large files. It lets you scroll up and down and search for text, whereas more is much more limited.
Dotfiles: Hidden files starting with a dot (like .bashrc). They hold user configurations. Use ls -a to see them.
nano: A simple, built-in terminal text editor.

Working Faster in the CLI
Typing out full paths is exhausting. These tools fix that:

Tab Completion: Hit Tab to auto-complete a file or folder name. Hit it twice if there are multiple matches.
Command History (history): Shows everything you've typed.
Execution by Number: Type ![number] (like !20) to instantly rerun that exact command from your history.
Reverse Search (Ctrl + R): Start typing a past command, and the shell will auto-suggest the rest. Huge time saver.

Advanced Workspaces
You don't have to stick with the default bash shell.

Custom Prompts: You can edit your PS1 variable to change how your prompt looks.
Alternative Shells: zsh or fish offer better auto-suggestions.
Multiplexers (tmux / screen): Lets you split one terminal window into multiple panes, and keeps scripts running in the background even if your SSH connection drops.

Key Takeaway (Day 5): Stop typing everything out manually. Master Tab completion, use Ctrl+R to find old commands, and always use less to read log files.

Forem: Tyrone Tabornal

My Linux Devlog: From WSL to the Cloud (Days 1–5)