Whether you run workloads on Oracle Cloud, AWS, or a server under your desk, the operating system underneath is almost always Linux. Cloud consoles come and go, but the fundamentals below have stayed stable for decades — and they're what you fall back on at 2 a.m. when the dashboard is telling you nothing useful.
The filesystem hierarchy: everything is a file
Linux organises everything under a single root, /. Devices, sockets, and even
kernel state are exposed as files. A few directories matter far more than the rest:
| Path | What lives there |
|---|---|
/etc | System-wide configuration — services, network, users |
/var | Variable data: logs (/var/log), spools, caches |
/home | User home directories |
/opt & /usr/local | Third-party and locally built software |
/proc & /sys | Virtual filesystems exposing kernel and process state |
/tmp | Temporary files, usually cleared on reboot |
When troubleshooting, /var/log and /etc are usually where the
answers are. Get comfortable moving around with cd, ls -la, and
find, and reading files with less, tail -f, and
grep.
Users, groups, and permissions
Every file has an owner, a group, and a permission triplet for user/group/others. The classic
rwx notation maps to read (4), write (2), and execute (1):
$ ls -l /etc/ssh/sshd_config
-rw-r--r-- 1 root root 3287 May 14 09:12 /etc/ssh/sshd_config
$ chmod 640 app.conf # owner rw, group r, others none
$ chown deploy:webapps app.conf
Two habits keep environments safe: never run application processes as root, and
use sudo for administrative work so every privileged command is logged and
attributable. On hardened systems, check /etc/sudoers.d/ rather than editing
/etc/sudoers directly.
Processes and resources
A running Linux system is a tree of processes descending from PID 1 (systemd on modern distributions). Your core inspection toolkit:
ps auxorps -ef— snapshot of all processes.top/htop— live CPU and memory view.free -h— memory and swap usage.df -handdu -sh *— disk capacity and what's consuming it.ss -tulpn— which processes are listening on which ports.
A surprising number of production incidents come down to three causes: a full disk, memory exhaustion, or a service that isn't listening where the load balancer expects it. The five commands above diagnose all three in under a minute.
Text processing: the quiet superpower
Linux administration is largely text manipulation. Logs, configs, and command output are all
plain text, and the pipe (|) lets you chain small tools into powerful one-liners:
# Top 10 IPs hitting your web server
$ awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head
# All failed SSH logins today
$ grep "Failed password" /var/log/auth.log | grep "$(date '+%b %e')"
Learn grep, awk, sed, sort,
uniq, and wc to a working level. They compose into answers faster
than any GUI ever will.
Networking basics
Verify connectivity in layers, from the host outwards: ip a for interfaces and
addresses, ip route for routing, ping for reachability,
dig or resolvectl for DNS, and curl -v for the actual
application-layer conversation. When someone says "the server is down," this ladder tells
you whether the problem is the host, the network, name resolution, or the application.
Where to go from here
Fundamentals compound. Once the filesystem, permissions, processes, and text tools feel natural, everything else — containers, cloud images, configuration management — becomes far easier, because it's all built on the same foundations. A good next step is understanding how modern Linux manages services, which is exactly what the systemd post covers.
back to all posts