In Part 1, I shared how I started my DevOps journey with Linux basics and simple file operations (CRUD). One thing quickly became clear: commands like cd and ls are useful, but they don’t mean much if you don’t understand where you are in the Linux file system.
In the real IT world, knowing where configs live, where logs are stored, and where user files belong is critical. That’s where the Linux File System Hierarchy comes in — it’s basically the map of the entire operating system.
💡 Why the File System Hierarchy Matters in DevOps
Think of it like this:
A developer pushes code → it runs on a server.
If the app crashes, you need to check logs.
If you want to tweak behavior, you need to edit configs.
If permissions break, you need to manage users.
All of this happens inside the Linux file system hierarchy. Without knowing the map, you’re just wandering around blindly.
📂 Key Directories (with Real-World Use Cases)
Here’s what I learned while exploring:
/ — The Root
The starting point of everything in Linux.
Every file and directory originates here.
👉 Like the “C:\” drive in Windows.
/home — User Workspaces
Contains personal directories for each user.
Example: /home/sheersh would be my workspace.
👉 In DevOps teams, developers often store project files here during testing.
/etc — Configuration Files
Stores system-wide config files.
Example: /etc/ssh/sshd_config controls SSH access.
Example: /etc/nginx/nginx.conf holds Nginx server configs.
👉 This is where IT engineers spend a lot of time fine-tuning deployments.
/var/log — Logs
Contains log files for the system and apps.
Example: /var/log/syslog, /var/log/nginx/error.log.
👉 In real DevOps, if an app crashes, this is the first place you look.
/usr — User Programs and Libraries
Stores installed software and libraries.
Example: /usr/bin has common commands like python3.
👉 When deploying, you’ll often check here to verify if required packages are installed.
/bin & /sbin — Essential Commands
/bin → essential user commands (e.g., ls, cp, mv).
/sbin → system admin commands (e.g., reboot, shutdown).
👉 Think of these as the toolbox for admins and users.
/opt — Optional Software
Holds third-party or custom software.
👉 If you install a monitoring tool or DevOps agent, you may find it here.
🚧 Challenges I Faced (and How I Solved Them)
1️⃣ Where Are the Configs?
At first, I couldn’t figure out where servers like Nginx or SSH stored their configs.
Problem: Kept searching randomly.
Solution: Learned that almost all configs live under /etc.
👉 Lesson: /etc is the control center.
2️⃣ Where Are the Logs?
When my system behaved oddly, I didn’t know where to check.
Problem: Googling errors instead of finding logs.
Solution: Discovered /var/log and learned journalctl on systemd systems.
👉 Lesson: /var/log and journalctl together tell the system’s story.
3️⃣ Permissions Confusion
I edited files in /etc and kept seeing “Permission denied.”
Problem: Tried using normal user privileges.
Solution: Learned to use sudo for admin-level changes.
👉 Lesson: In real DevOps teams, not everyone is root — permissions protect systems.
🔍 How to See System Logs (Old vs Modern Way)
On Linux, there are multiple ways to view system logs depending on what you want to check. Over time, this has evolved — earlier systems relied mainly on plain text files like /var/log/syslog, while modern Linux distributions use systemd with journalctl. Knowing both is important, because in real IT environments, you’ll come across both setups.
1) journalctl — Modern Way (systemd-based systems like Ubuntu, Fedora, CentOS 7+)
systemd manages logs in a binary journal format, and you use journalctl to read them:
journalctl # Shows all logs managed by systemd-journald
journalctl -xe # Shows recent logs with details (errors/warnings)
journalctl -u sshd # Logs for a specific service (e.g., sshd)
journalctl -f # Follow logs in real-time (like tail -f)
👉 On most modern distros, this is the go-to tool for system logs.
2) /var/log/ — Traditional Way (used earlier, still relevant)
Before systemd, logs were written directly into plain text files under /var/log/. Many apps still log here, so it’s essential to know:
ls /var/log/
Common files:
/var/log/syslog -> General system messages (Ubuntu/Debian)
/var/log/messages -> General system messages (RHEL/CentOS)
/var/log/auth.log -> Authentication (logins, sudo)
/var/log/kern.log -> Kernel messages
/var/log/dmesg -> Boot & hardware messages
Example commands:
cat /var/log/syslog
tail -f /var/log/syslog # See logs live
👉 Note: On older guides/tutorials, you’ll see a lot of /var/log/syslog. On modern systems, that role is now mostly handled by journalctl, but /var/log is still widely used for app-specific logs.
3) dmesg for Kernel/Boot Messages
dmesg prints messages from the kernel ring buffer — useful for drivers, boot, and hardware troubleshooting:
dmesg | less
⚠️ A Real Mistake I Made
I once tried to open system.journal directly with cat:
cat /var/log/journal/<machine-id>/system.journal
The output was pure gibberish 😅 — because system.journal is a binary file.
👉 The correct way is always:
journalctl
That lesson taught me something crucial: syslog was used earlier, journalctl is used now — and knowing both makes you flexible across systems.
🛠 Hands-On Mini Demo (Logs + Navigation)
Here’s a small sequence that ties the file-system map to log-checking — exactly what I do when I SSH into a server:
# Navigate to configs
cd /etc
ls
cat ssh/sshd_config # view SSH config
# Check system logs (systemd)
journalctl -xe
# Kernel boot messages
dmesg | less
🌟 Key Takeaways from Part 2
The Linux file system is a map — /etc for configs, /var/log (and journalctl) for logs, /home for user work.
Syslog was used earlier; journalctl is now the standard, but /var/log is still very relevant.
Small mistakes (like cat-ing a binary journal file) teach you tools and patterns that matter in production.
Practicing navigation + log checks is the closest thing to real server troubleshooting.
🚀 What’s Next (Part 3)
In Part 3, I’ll dive into Linux Users and Permissions — because in real teams, managing who can do what on a server is just as important as knowing where files live.
🤝 Over to You
Have you ever tried to cat a binary log or been surprised by journalctl output? Share your “oops” and “aha” moments — I learn best from others’ mistakes too. 👇
Top comments (0)