The brain of the system: /etc

DNS and name resolution: /etc/resolv.conf and /etc/hosts

Routing tables on disk: /proc/net/route and /etc/iproute2

Networking interface configuration

Logs and digital breadcrumbs: /var/log

Users and accounts: /etc/passwd, /etc/shadow, /etc/group

Permissions and the role of /etc/sudoers

Processes as files: /proc

Device files and /dev

Boot‑time configuration under /boot and /etc/grub

Environment and system‑wide configuration

Wrapping up: thinking like a system investigator In Linux, everything is a file—not just text documents or executables, but also devices, network sockets, and even running processes. This idea turns the whole operating system into a giant, interconnected file‑system tree that you can “hunt” through like a detective. In this blog I’ll walk you through 10 meaningful discoveries I made while exploring the Linux file system, focusing on what those files and directories actually do, why they exist, and what interesting insights they reveal. The /etc directory acts as Linux’s configuration brain. It stores almost all system‑wide configuration files, from user accounts (/etc/passwd, /etc/shadow) to service settings, network parameters, and shell preferences. Why does it exist?

Linux is designed to be modular and customizable. Instead of baking settings into the kernel, the system keeps them in human‑readable files under /etc, so administrators can tweak behavior without recompiling the OS. What problem it solves: Interesting insight:Opening /etc/environment shows where global environment variables are defined; every user and many system services inherit these values. This means a single file can subtly shape how every process behaves across the system. When you type google.com into a browser, Linux must translate that into an IP address. The main files that drive this are /etc/resolv.conf and /etc/hosts. Why they exist:Without DNS, you’d have to memorise IP addresses for every service. These files let the system know where to ask for DNS answers and allow quick local overrides for testing or debugging. What problem it solves: Interesting insight:On some systems /etc/resolv.conf is just a symlink to /run/systemd/resolve/resolv.conf because systemd-resolved manages DNS and caches queries. This reveals how multiple layers of abstraction (service ↔ config ↔ resolver) all converge into a single file that applications read. Routing is the process of deciding which network interface and gateway to use for each packet. Linux exposes its routing table through virtual files under /proc and configures higher‑level rules via /etc/iproute2. What /proc/net/route does:It’s a text representation of the kernel’s routing table, showing destination networks, gateways, and interfaces in hexadecimal. Why /proc/net/route exists:The kernel maintains routing data in memory, but users‑pace tools need access. /proc exposes this as a file‑like interface so commands like ip route and netstat -r can read and display it. What problem it solves: Interesting insight:Seeing the table in hexadecimal initially looks cryptic, but once you decode the destination and gateway fields (e.g., 0200A8C0 ↔ 192.168.0.2), you realise it’s literally the kernel’s raw routing logic laid bare as a text file. Network interfaces are controlled by config files and runtime data exposed under the file system. The exact paths differ by distro and network manager, but the idea is the same: configuration files live under /etc and running‑state info lives under /sys or /proc. On many modern systems, NetworkManager writes connection‑specific files such as: Why these files exist:They persist the settings (SSID, IP mode, gateway, DNS) for each interface so the system doesn’t need to re‑ask for configuration every reboot. What problem they solve: Interesting insight:Exploring /sys/class/net/eth0 shows symbolic links and device‑specific files that expose the interface’s driver, speed, and MAC address. This reveals how even hardware is modelled as a file‑system tree, making low‑level inspection surprisingly scriptable. System logs are one of the most powerful “forensic” tools in Linux. The /var/log directory houses logs from the kernel, services, and applications, each stored as ordinary text files. Why they exist:Logs answer the “what happened and when?” question. They help debug crashes, track performance issues, and detect security incidents. What problem they solves: Interesting insight:Reading /var/log/kern.log can show exact timestamps of hardware events, such as when a USB device was plugged in or when a disk driver threw an error. This makes /var/log feel like a chronological diary of the machine’s entire life. User management is surprisingly file‑based. The main files are: Why they exist:Linux follows the principle of “everything is a file.” Instead of a hidden database, user and group data live in plain(ish) text files with strict permissions. What problem they solve: Interesting insight:Noticing the x in /etc/passwd’s password field and then finding the actual hash in /etc/shadow reveals a clever separation of concerns: one file for public info, another for secret data, all still under /etc. File permissions already give Linux a rich security model, but /etc/sudoers adds another layer on top. It defines which users can run which commands as root or other users. What it does:Each line in /etc/sudoers grants a user (or group) permission to run specific commands on specific hosts, sometimes without a password. Why it exists:Direct root logins are risky; sudo allows fine‑grained privilege delegation. An admin can give a developer temporary root‑like access to a web server without handing over the root password. What problem it solves: Interesting insight:Hunting through /etc/sudoers and its included snippets (often under /etc/sudoers.d/) reveals that even privilege‑escalation logic is ultimately driven by human‑editable text files, not a hidden binary policy engine. The /proc filesystem is one of the most fascinating parts of the Linux file system. Each running process gets a directory under /proc/<PID>, containing status files, memory maps, and environment variables. Why /proc exists:The kernel exposes process‑level information in a file‑like interface so tools like ps, top, and lsof can read it without needing special syscalls for every piece of data. What problem it solves: Interesting insight:Looking at /proc/self (a symlink to the current process’s own directory) makes it feel like each process “lives” in the file system, reading and writing information about itself as if it were any other service talking to a config file. In Linux, even hardware devices are represented as files under /dev. These “device files” let you read from or write to physical devices using the same file‑I/O operations a text program would use. Why they exist:The kernel abstracts hardware into a file‑like interface so applications can treat storage, terminals, and other devices uniformly. What problem it solves: Interesting insight:Running ls -l /dev and seeing that /dev/sda is a “block special” file (brw-rw----) shows that even raw disk access is just another file, governed by the same permission model used for regular files and directories. Booting is orchestrated by files under /boot and configuration under /etc/grub. These files define which kernel to load, which initramfs to use, and what kernel parameters to pass. Why they exist:The bootloader needs to know which kernel and initramfs to load, and the admin needs a way to tweak kernel parameters (e.g., nomodeset, console=ttyS0). What problem it solves: Interesting insight:Opening /boot/grub/grub.cfg and seeing kernel‑parameter lines like linux /boot/vmlinuz-6.8.0-10-generic root=UUID=... ro makes it clear that booting is just another script‑like configuration, defined by plain text that you can read and edit. Beyond /etc/environment, many environment variables and shell settings are defined in files such as /etc/profile, /etc/profile.d/*.sh, /etc/bash.bashrc, and user‑specific ~/.bashrc, ~/.profile. What they do:These scripts set environment variables and shell aliases that are inherited by every interactive shell session. Why they exist:To avoid hard‑coding paths and settings into each user’s shell config, distribution maintainers centralize them in /etc. What problem it solves: Interesting insight:

Hunting through /etc/profile.d/*.sh and comparing them with your own ~/.bashrc reveals that Linux effectively “assembles” your environment from multiple layers of configuration files, like a stack of configuration cards. Exploring the Linux file system beyond basic commands turns you into a kind of system detective. Instead of seeing /etc, /proc, /dev, and /var/log as abstract directories, you begin to recognise them as the living, file‑based control plane of the entire OS. Each meaningful discovery—whether it’s decoding a routing table from /proc/net/route, reading environment variables from /etc/environment, or tracing a suspicious process via /proc/$PID—tells you why Linux behaves the way it does and how you can safely change or debug that behaviour. This “hunting” mindset doesn’t just help with assignments; it trains you to think like the OS itself, which is exactly what you want when you step into roles as a developer, DevOps engineer, or security analyst. Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to ? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse