DevOps
Linux for DevOps
In 2017, an Amazon engineer entered the wrong command in a shell - and took down S3 for 4 hours. Half the internet stopped working. One command in a terminal. The Linux shell hands you root-level capability with no guardrails - the cost is paying close attention to what you type.
- **Docker** - every container is a Linux process with an isolated file system. Without Linux knowledge, debugging containers is not possible.
- **CI/CD runners** - GitHub Actions, GitLab CI, Jenkins - all run on Linux. Pipeline scripts are bash.
- **Production troubleshooting** - when a server is under load, ps, top, df, grep, tail -f are needed. No GUI. Terminal only.
- **Cloud servers** - AWS EC2, GCP, DigitalOcean - all managed via SSH and shell commands
Unix: 50 years that changed the world
1969, Bell Labs. Ken Thompson writes the first version of Unix in three weeks while his wife and child are on vacation. Originally a tool for a team working on the Space Travel game. The "everything is a file" principle and "small utilities connected by pipes" was articulated by Douglas McIlroy. In 1991, Linus Torvalds publishes the Linux kernel as "just a hobby" - today it runs on 96% of the world's servers, all Android devices, and most supercomputers.
Предварительные знания
Shell: the Command Line as a Superpower
2017, Amazon S3. An engineer runs a routine billing-system debug. A typo in one command argument - and the largest object storage in the world goes dark for 4 hours. Half the internet stops working. **Shell** is not just a terminal window. It is a direct interface to the OS kernel where every command can change system state irreversibly.
**bash** (Bourne Again Shell) - the standard on most servers. **zsh** - popular on macOS and for development. For DevOps, bash matters most because it ships in Docker images and CI/CD runners.
The core superpower of Shell - **pipes** and **redirection**. A pipe `|` takes the output of one command and feeds it as input to the next. Small utilities chain together - each doing one thing well.
**grep**, **awk**, **sed** - the three musketeers of text processing. grep searches, awk analyzes columns, sed replaces text. Together they handle 90% of log parsing tasks.
A shell script starts with a **shebang**: `#!/bin/bash`. This tells the OS which interpreter to use. Without a shebang, the script might run in a different shell and break.
What does the command `cat access.log | grep 404 | wc -l` do?
Processes: the Life of Programs in Linux
Production server, CPU at 100%, users see 504 Gateway Timeout. The first move for an experienced SRE: `ps aux` and `top`. Every running program in Linux is a **process** with a unique **PID** (Process ID). The kernel allocates memory, CPU time, and file descriptors to it. Diagnosis starts with understanding these primitives.
**Signals** - a way to communicate with processes. The most important: **SIGTERM** (15) - a polite request to terminate; the process can do cleanup. **SIGKILL** (9) - a forced kill; the process cannot intercept it.
**systemd** - the init system and service manager in modern Linux. Manages starting, stopping, restarting, and monitoring daemons (background processes).
**Background processes** - running tasks in the background. The `&` symbol runs a process in the background, but it will die when the terminal is closed. `nohup` protects against this.
A Node.js process is hung and not responding to SIGTERM. What to do?
The Linux File System
Disk on a production server at 95% - deploy fails, logs stop writing, the database throws errors. Where to look first? In Linux **everything is a file**: regular files, directories, devices, sockets, even process information. All in a single hierarchy rooted at `/`. Knowing this map turns panic into a plan.
**FHS** (Filesystem Hierarchy Standard) - a standard that defines where things live in Linux. All distributions follow it, so skills transfer between Ubuntu, CentOS, and Debian.
| Path | Purpose | DevOps Context |
|---|---|---|
| /etc | Configuration files | nginx.conf, sshd_config, hosts |
| /var/log | System and service logs | syslog, nginx/access.log, auth.log |
| /var/lib | Service data | docker/, postgresql/, mysql/ |
| /tmp | Temporary files (cleared on reboot) | Don't store anything important here! |
| /home | User home directories | /home/deploy/.ssh/authorized_keys |
| /opt | Third-party software | Often used to host applications |
| /usr/bin | Main programs | git, curl, node, python |
| /proc | Virtual FS (process info) | /proc/cpuinfo, /proc/meminfo |
**Inodes** - an internal structure storing file metadata (permissions, owner, size, disk location). A file name is merely a pointer to an inode. This explains why multiple names (hardlinks) can exist for the same file.
**Mount points** - in Linux there are no drive letters like Windows. Partitions and devices are mounted into the file system tree.
**A common trap:** `free` shows very little "free" memory and beginners panic. In reality, Linux actively uses free RAM for cache (buff/cache). The **"available"** column is the actually usable memory.
The server shows `df -h` with 95% used space on /var. Where is the problem most likely?
Permissions and Security
Security audit. The auditor runs the first script and immediately finds files with permissions 777. Report: critical vulnerability. The web server is compromised - configs modified, SSH keys copied. Linux is a multi-user system. Every file belongs to a **user** and a **group**, and has three sets of permissions: for the owner (**u**ser), the group (**g**roup), and everyone else (**o**thers). Permissions: **r**ead, **w**rite, e**x**ecute.
| Number | Permissions | Meaning |
|---|---|---|
| 7 | rwx | Read + write + execute |
| 6 | rw- | Read + write |
| 5 | r-x | Read + execute |
| 4 | r-- | Read only |
| 3 | -wx | Write + execute |
| 2 | -w- | Write only |
| 1 | --x | Execute only |
| 0 | --- | No permissions |
**SUID/SGID** - special bits that allow a program to run with the file owner's permissions. For example, `passwd` has the SUID bit set so a regular user can change their password (which is stored in a root-owned file).
**chmod 777 - NEVER on production!** This grants ALL users full access to the file: read, write, and execute. Any process, including a compromised web server, will be able to modify configs, scripts, and data. This is the first thing checked in a security audit.
chmod 777 fixes any file access problem - if something doesn't work, just give everyone permissions
chmod 777 is a serious security vulnerability. Permissions should be granted minimally: what the owner needs, what the group needs, and read-only or nothing for others
The Principle of Least Privilege is a cornerstone of security. chmod 777 means that ANY process on the server (including a compromised web server or exploited vulnerability) can read, modify, and execute the file. On production this leads to script replacement, secret leakage, and full system compromise.
An SSH key has permissions 644 (rw-r--r--). The SSH client refuses to connect. Why?
Key Takeaways
- **Shell** is the primary interface to servers. Pipes (`|`) and redirection (`>`, `>>`) enable powerful one-liners
- **Processes** have PIDs, are controlled by signals (SIGTERM -> SIGKILL), and managed by systemd for services
- **FHS** - standard structure: configs in /etc, logs in /var/log, /proc for system information
- **File permissions** rwx for user/group/others - chmod 600 for secrets, chmod 755 for scripts
- The S3 outage happened because of one typo in a command - understanding each command's semantics is critical
- **Principle of Least Privilege** - grant the minimum necessary permissions; never use chmod 777 on production
Related Topics
Linux is the foundation for all subsequent topics in the DevOps course:
- Networking for DevOps — Linux networking utilities: curl, netstat, ss, tcpdump, iptables
- What is DevOps — The automation from the previous lesson is built on shell scripts
Вопросы для размышления
- Connected to a production server with CPU at 100%. Which commands to run first, and why?
- Why does Linux use text-based configs (/etc/nginx/nginx.conf) instead of a GUI? What advantages does this give for DevOps?
- How would file permissions be organized on a server shared by three teams: frontend, backend, and DevOps?
Связанные уроки
- devops-01 — DevOps intro establishes automation context on Linux
- devops-03 — Linux networking tools: curl, netstat, ss, tcpdump, iptables
- devops-04 — Docker is built on Linux namespaces and cgroups
- cloud-02 — Containers and VMs live on top of Linux - shell skills are essential for debugging
- sec-01 — File permissions and Principle of Least Privilege - security foundation
- devops-08 — CI/CD pipelines are bash scripts on Linux runners
- os-01-intro
- os-21-linux-internals