Linux, Operations
Linux Knowledge Sharing
A practical tour of Linux for people who build, deploy, and operate services across teams and environments.
This post is a written guide to my Linux Knowledge Sharing session. The original slide deck is available as a PDF.
The deck is arranged as three parts. It starts with the Linux mental model, moves into the services and processes that run on a host, and finishes with the filesystem, users, packages, logs, and commands used to investigate real problems.
Part 1: The Linux mental model
The opening part establishes the questions an operator should ask when arriving on a machine: who am I, which kernel is running, how long has the host been up, and is the system healthy? Commands such as whoami, uname -a, uptime, and systemctl is-system-running make the environment visible before any change is made.
It then connects the layers that are easy to confuse: hardware, the Linux kernel, core userspace tools, language runtimes, and application services. The same command may exist across environments while the distribution, package manager, container image, user, or filesystem differs. That is why the deck compares Ubuntu, Debian, and Alpine, and why a container should be treated as a complete execution environment rather than just a smaller virtual machine.
The final idea in this part is that Linux is a stack. Your service sits on a runtime, userspace, and system services; those depend on the kernel and, ultimately, CPU, memory, storage, and network devices. Knowing which layer owns a symptom is the beginning of useful debugging.
Part 2: Services, processes, and permissions
Part 2 focuses on what keeps a Linux host running. systemd-analyze shows boot timing, while units and targets explain how services such as SSH, Nginx, Docker, and an application are started and ordered. The example unit file makes the contract explicit: what to execute, what it should wait for, how it should restart, and which target enables it.
The deck then turns that model into an operating workflow: use systemctl status to see the current state, journalctl to read the service history, and the service logs to find the root cause. A failed application is not a mystery when its journal says a dependency is missing.
Permissions are part of the same story. The examples use whoami, id, sudo -l, ownership, and executable bits to show what a login can do and what it cannot. The recommended pattern is scoped privilege: give an operator the one restart permission they need, and run an application as its own unprivileged user instead of as root.
The last section of Part 2 covers processes and ports. ps, top, htop, kill, nice, and lsof reveal process ownership, signals, resource use, and which process is holding a port. The EADDRINUSE example demonstrates a repeatable path from an application error to the process that must be stopped.
Part 3: Filesystem, users, packages, and logs
Part 3 is a map of the host. It introduces the major filesystem paths - /etc for configuration, /var for changing state and logs, /home for user data, /usr for installed software, /tmp for temporary files, and /proc, /sys, and /dev for kernel and device views. The chapter titles ask "What's in /etc?" and "What's in /var?" because knowing where to look is often faster than reaching for another tool.
The practical examples show configuration in files such as /etc/sudoers, /etc/systemd, /etc/fstab, SSH configuration, and log rotation. Package management is compared across apt, dnf or yum, pacman, and apk, followed by the same install, inspect, and remove workflow.
Users and groups explain the boundary around a service. Commands such as useradd, usermod, groups, id, chown, and sudo -u make it possible to create a dedicated service identity and verify its effective permissions.
The final chapter is about evidence. journalctl, /var/log/syslog, Nginx and authentication logs, tail, grep, df, du, and find are used to narrow a failure. In the database timeout example, checking DNS with ping shows that the root cause is name resolution rather than the application or database. The closing command list is deliberately compact: a small set of commands that covers service state, processes, ports, permissions, disk space, packages, identity, and system health.
The takeaway
The session is less about memorizing Linux commands and more about building a dependable investigation loop: identify the host and its layers, locate the service or process, inspect permissions and configuration, read the right logs, and verify the result. When the path from symptom to evidence is familiar, Linux becomes much easier to operate.