# Linux File System Hunting: 10 Discoveries That Changed How I See the OS Most Linux learning starts with commands. This exploration started with a different question: **if Linux is “everything is a file,” what does the filesystem reveal about how the system actually behaves?** I treated the machine like a live investigation target and followed configuration files, virtual filesystems, process metadata, networking artifacts, and service definitions. Here are the most meaningful findings. ### **1)** `/etc` **is the policy brain of the machine** **What it does:** `/etc` stores system-wide configuration: users, DNS, networking, host identity, services, PAM policies, and more. **Why it exists:** Linux separates **policy/configuration** from binaries. Programs live in `/usr/bin` or `/sbin`; behavior is defined in `/etc`. **What problem does it solve:** Predictable administration and automation. You can rebuild behavior by restoring config state, not by editing binaries. **Interesting insight:** I used to think `/etc` is “just config files.” It’s more than that: it is the **declarative contract** for system behavior. Change `/etc` correctly, and the machine’s personality changes. ### **2)** `/etc/resolv.conf` **taught me DNS is layered, not static** **What it does:** Defines DNS resolvers (`nameserver`), search domains, and lookup behavior. **Why it exists:** Applications need a common resolver interface, so every app doesn’t implement DNS independently. **What problem it solve:** Centralized name resolution across the OS. **Interesting insight:** On many systems, `/etc/resolv.conf` is generated (e.g., by `systemd-resolved`, NetworkManager, DHCP clients). So editing it directly may be temporary. The real source of truth can live elsewhere, and this file is often the **runtime projection** of several subsystems. ### **3)** `/etc/nsswitch.conf` **revealed that DNS is only part of “name lookup.”** **What it does:** Controls lookup order for identities and hostnames, e.g.: * `hosts: files dns` * `passwd: files systemd ldap` (varies by distro) **Why it exists:** Linux can resolve names from multiple backends: local files, DNS, LDAP, mDNS, etc. **What problem does it solve:** Flexible identity and host resolution across standalone servers, enterprise domains, and hybrid environments. **Interesting insight:** “Can’t resolve hostname” isn’t always a DNS issue. It might be a lookup order. A single line `nsswitch.conf` can explain “works on one host, fails on another.” ### **4)** `/proc` **It is a live kernel API, not a normal directory** **What it does:** `/proc` exposes the runtime kernel and process state as files (`/proc/cpuinfo`, `/proc/meminfo`, `/proc//...`). **Why it exists:** Kernel internals must be inspectable in a standard, scriptable way. **What problem does it solve:** Observability without custom tooling. Monitoring tools and admins can query the live state through file reads. **Interesting insight:** Files in `/proc` are generated on demand. So reading them is like calling an API endpoint backed by kernel memory, not opening static disk content. * * * ### **5)** `/proc/` **made process forensics surprisingly transparent** **What it does:** Per-process directories expose the command line, environment, open file descriptors, memory maps, and current working directory. **Why it exists:** Processes are first-class managed entities. Linux exposes rich metadata for debugging, tracing, and auditing. **What problem it solve:** Rapid diagnosis of “what is this process actually doing?” **Interesting insight:** `/proc//fd` It is powerful: it shows every open file/socket as symlinks. This bridges process behavior with filesystem and networking in one place—great for incident response. * * * ### **6)** `/etc/passwd`**,** `/etc/shadow`**, and** `/etc/group` **showed Unix identity design in practice** **What they do:** * `/etc/passwd`: user accounts and metadata * `/etc/shadow`: password hashes and aging policies (restricted) * `/etc/group`: group membership and privilege grouping **Why they exist:** Authentication and authorization require structured identity records. **What problem do they solve:** User management, access control, and policy enforcement. **Interesting insight:** Separation of `/etc/passwd` and `/etc/shadow` is a security boundary: world-readable identity info remains accessible, while secrets are restricted. It’s a simple but elegant least-privilege design. * * * ### **7)** `/var/log` **is the system’s memory of intent, failure, and recovery** **What it does:** Stores logs from kernel, services, authentication events, package managers, and scheduled tasks. **Why it exists:** Systems are asynchronous and failure-prone; logs provide causal history. **What problem does it solve:** Troubleshooting, auditing, compliance, and operational learning. **Interesting insight:** Logs are more than errors—they narrate **state transitions**. When correlated with service definitions and network state, they explain not just *what failed* but *why the system made certain decisions*. * * * ### **8)** `/dev` **Proved device access is normalized through file semantics** **What it does:** Represents hardware and pseudo-devices as special files (`/dev/sda`, `/dev/null`, `/dev/tty`, `/dev/random`). **Why it exists:** Uniform I/O interface. Programs can interact with devices via file operations. **What problem does it solve:** A consistent programming model across disks, terminals, and kernel-provided virtual devices. **Interesting insight:** `/dev` is dynamically managed (typically by `udev`), meaning device files appear/disappear as hardware state changes. This ties physical events (plugging hardware) directly into filesystem visibility. * * * ### **9)** `/etc/systemd` **and unit files exposed startup as dependency graph, not script sequence** **What it does:** Defines service units, targets, dependencies, restart policies, environment, and execution behavior. **Why it exists:** Modern systems need deterministic boot and service orchestration. **What problem does it solve:** Reliable startup ordering, failure handling, service supervision, and lifecycle control. **Interesting insight:** Service management in Linux is strongly **declarative** now. Instead of “run script A then B,” systemd models relationships: “start B when A is ready, restart C on failure, bind D to target X.” It feels closer to infrastructure orchestration than legacy init scripts. * * * ### **10)** `/boot` **clarified that “Linux” has multiple layers before the user space even starts** **What it does:** Stores kernel images, initramfs/initrd, and bootloader-related artifacts. **Why it exists:** Early boot needs a minimal, reliable filesystem location for kernel + initial userspace. **What problem does it solve:** Transition from firmware/bootloader to full OS initialization. **Interesting insight:** The initramfs is effectively a temporary micro-userspace that prepares the real root filesystem. Boot is not one jump into Linux; it’s a staged handoff pipeline. ## **What this exploration changed for me** Linux feels less like “a command-line OS” and more like a **transparent operating model** where: * configuration is explicit (`/etc`) * runtime state is inspectable (`/proc`, `/sys`) * identity and permissions are composable (`passwd`, groups, mode bits) * Hardware is abstracted through files (`/dev`) * services are graph-managed (`systemd`) * history is recoverable (`/var/log`) The biggest lesson: Linux is debuggable because it externalizes internals into stable filesystem interfaces. If you know where to look, the system explains itself. ## **Minimal command references used during investigation (non-tutorial)** Only where needed to validate findings: * `cat /etc/nsswitch.conf` * `cat /proc/meminfo` * `ls -l /proc//fd` * `journalctl -xe` * `systemctl cat ` These commands were just lenses; the real learning came from understanding **why those files exist** and what architecture decisions they represent.