From 58edbf5f5305e1a1afdc2357457146623c4e22a3 Mon Sep 17 00:00:00 2001 From: Jules Date: Thu, 14 May 2026 18:02:43 -0400 Subject: [PATCH] Improve Chapter 01 reading path --- .../1.13_recommended_reading.md | 251 ++++++++++++++++-- 1 file changed, 224 insertions(+), 27 deletions(-) diff --git a/docs/lessons/01_where_to_start/1.13_recommended_reading.md b/docs/lessons/01_where_to_start/1.13_recommended_reading.md index a8f2385..f0c1043 100644 --- a/docs/lessons/01_where_to_start/1.13_recommended_reading.md +++ b/docs/lessons/01_where_to_start/1.13_recommended_reading.md @@ -1,48 +1,245 @@ ## 1.13 Recommended Reading - +Recommended reading is not just a list of books and websites. For a Linux +operator, reading is part of the work: you use references to understand a +system, reduce risk, explain choices, and avoid repeating fragile folklore. +This section gives you a practical reading path for the rest of the book. !!! abstract "What you will learn" - - Explain where **1.13 Recommended Reading** fits in day-to-day Linux operations. - - Use current Linux tooling to inspect, change, and verify the relevant system behavior. - - Connect the concept to a real operational scenario: a first-week junior admin onboarding into a small cloud team. - -!!! example "Field story" - Imagine a first-week junior admin onboarding into a small cloud team. Your job is not to memorize a command; it is to build a short evidence trail, choose a low-risk change, and prove whether the system improved. + - Choose references that match your current Linux level and task. + - Separate conceptual reading from operational documentation. + - Build a habit of reading with a lab machine nearby. + - Keep a short reading note that can help during future incidents. !!! success "Operator principle" - Identify the OS, distribution, support window, and package source before changing anything. + Read with a question in mind. A useful source should help you inspect, + explain, change, or verify something on a real system. -## Hands-on practice +## How to use this reading list -Run these on a disposable VM, container, or lab machine unless the lesson explicitly says otherwise. +Do not try to read every source from front to back before touching Linux. That +usually turns into procrastination. -1. Inspect the current state with a read-only command related to this topic. -2. Save the command and output in a short lab note. -3. Make one reversible change or simulate the change in a sandbox. -4. Re-run the inspection and explain what changed. +Use three reading modes: -## Check your understanding +- Orientation: learn the shape of a topic before you need it urgently. +- Task support: read the exact documentation for the tool, version, or system + in front of you. +- Incident support: read narrowly, preserve evidence, and avoid risky changes + until you understand the blast radius. + +Pair reading with a lab whenever possible. A command that makes sense on the +page becomes much clearer after you run it on a disposable system. + +## Start with local documentation + +Local documentation is the best first habit because it matches the installed +system more often than a random web result. + +Use: + +```bash +man systemctl +man ssh_config +man 5 crontab +apropos password +whatis journalctl +ls /usr/share/doc +``` + +Practice reading manual pages for: + +- Command purpose. +- Common options. +- Examples. +- File locations. +- Exit status. +- Related manual pages in the "SEE ALSO" section. + +The "SEE ALSO" section is often the fastest path from one useful page to the +next. + +## Distribution documentation + +Distribution documentation explains how Linux is packaged and configured for a +specific operating system. + +Useful starting points: + +- Debian Administrator's Handbook. +- Ubuntu Server documentation. +- Red Hat Enterprise Linux documentation. +- Fedora documentation. +- Arch Wiki. +- FreeBSD Handbook, when working with FreeBSD systems. + +Before following a distribution guide, compare it with the host: + +```bash +cat /etc/os-release +uname -r +``` + +Arch Wiki pages are often excellent for concepts and troubleshooting, but Arch +commands and file paths may not apply directly to Debian, Ubuntu, RHEL, Fedora, +or SUSE systems. + +## Core books + +Books are best for concepts, mental models, and full workflows. + +Useful classics and practical references: + +- *UNIX and Linux System Administration Handbook* by Evi Nemeth, Garth Snyder, + Trent R. Hein, Ben Whaley, and Dan Mackin. +- *How Linux Works* by Brian Ward. +- *The Linux Command Line* by William Shotts. +- *Linux Command Line and Shell Scripting Bible* by Richard Blum and Christine + Bresnahan. +- *The Linux Programming Interface* by Michael Kerrisk, for deeper system + programming and kernel-interface topics. + +Use books to understand why a subsystem behaves the way it does. Use local and +distribution documentation for the exact command syntax on a current host. + +## Upstream project documentation + +Upstream documentation is important for tools that have their own release +cadence and behavior. + +Examples: + +- OpenSSH manual pages and release notes. +- systemd documentation. +- Nginx and Apache HTTP Server documentation. +- PostgreSQL documentation. +- Kubernetes documentation. +- Docker documentation. +- Ansible documentation. -- What evidence would tell you that this system is healthy? -- What is the riskiest command in this lesson, and how would you make it safer? -- How would you explain section 1.13 to a teammate during an incident handoff? +Always check the installed version: +```bash +ssh -V +systemctl --version +nginx -v +psql --version +ansible --version +``` -The ocean of Linux is vast and deep. This subchapter aims to point you to the islands of knowledge in this ocean that we think will enhance your comprehension of Linux and its abundant facets. These references are carefully cherry-picked to provide context, augment the topics discussed in the book, and expand your horizon of understanding. Feel free to explore the titles at your own pace, in any order that speaks to you. +If the upstream guide is for a newer major version, treat it as a lead rather +than a final answer. -1. **"Linux Command Line and Shell Scripting Bible" by Richard Blum & Christine Bresnahan**: This book, filled with numerous examples, guides you skillfully through the Linux command line and shell scripts—concepts that form the backbone of any Linux system. +## Vendor and cloud-provider documentation -2. **"The Linux Programming Interface" by Michael Kerrisk**: Considered by many as the definitive guide to Linux and UNIX, it's a must-read for those aiming to dive into system programming. +Vendor documentation matters when the environment adds behavior that local +Linux tools cannot fully explain. -3. **"UNIX and Linux System Administration Handbook" by Evi Nemeth, Garth Snyder, Trent R. Hein, Ben Whaley & Dan Mackin**: Packed with practical advice, this book remains relevant through each new release of the Linux distributions and is designed to help you administer a wide range of contemporary systems. +Read provider docs for: -4. **Online Resources**: Numerous online platforms like [Linux Documentation Project](https://www.tldp.org/), [Stack Overflow](https://stackoverflow.com/questions/tagged/linux), and [LinuxQuestions.org](https://www.linuxquestions.org/) etc., offer generous, community-authored content which can address most of your queries about Linux. +- AWS EC2, IAM, VPC, EBS, CloudWatch, and load balancers. +- Google Cloud Compute Engine, IAM, VPC, Cloud Logging, and Cloud Monitoring. +- Azure virtual machines, managed identities, networking, and Monitor. +- Hardware vendor firmware, storage-controller, and out-of-band management + guidance. -5. **"How Linux Works, 2nd Edition" by Brian Ward**: From booting to package management, you will understand the nitty gritty of the operating system and the hardware. +Local logs may show the symptom. Provider documentation often explains the +control plane. -In your journey to conquer Linux, seeking wisdom from these sources will be an incredible asset. Dealing with processes, signals, or racing through commands, you'll find allies in these pages. Each chosen resource immerses you deeply into the world of Linux, demystifying the complexities and equipping you with skills you need to navigate this new world. +## Community sources -Consider this list as part of your navigation map on your voyage of discovery. As you dig deeper, you'll uncover insights, solutions, and best practices that will make your Linux journey more productive and enjoyable. +Community sources are useful, but they need verification. + +Examples: + +- Stack Overflow and Server Fault. +- LinuxQuestions.org. +- Distribution forums. +- Project GitHub issues. +- Mailing-list archives. +- Blog posts and conference talks. + +Before copying a command, ask: + +- Is the source current? +- Does it match my distribution and version? +- Is the command read-only or changing state? +- Does it require root? +- Is there an official source that confirms it? +- Can I test it in a lab first? + +Community answers often reveal the right search terms even when the final fix +comes from official documentation. + +## Standards and references + +Some topics are easier to understand with standards or reference material: + +- Filesystem Hierarchy Standard for directory layout. +- POSIX documentation for shell and Unix interfaces. +- RFCs for network protocols. +- Vendor security advisories. +- CVE records and distribution security trackers. + +These sources can be dense. Use them when exact behavior, compatibility, or +security impact matters. + +## Build a reading note + +Keep a short note when a source changes your understanding: + +```text +Question: + Why does this service restart repeatedly? + +System: + Ubuntu 24.04, systemd 255 + +Sources: + - man systemd.service + - man systemd.unit + - Ubuntu systemd package notes + +What I learned: + Restart= controls restart behavior, while StartLimitIntervalSec and + StartLimitBurst can stop repeated restart attempts. + +Next lab check: + Create a disposable unit and observe restart-limit behavior with journalctl. +``` + +The note should be short enough that you will actually write it. + +## Suggested first reading sequence + +If you are new to Linux operations, use this order: + +1. Local manual pages for commands you run every week. +2. Your distribution's administrator or server guide. +3. *The Linux Command Line* or equivalent shell-focused introduction. +4. *How Linux Works* for operating-system concepts. +5. The relevant chapters of this book as you encounter real tasks. +6. Upstream project documentation for services you operate. +7. Community sources only after you can evaluate the risk. + +This sequence builds both confidence and caution. + +## Lab: turn reading into action + +Pick one topic from this chapter, such as package installation, hosting choices, +or documentation sources. + +1. Find one local source, such as a manual page or `/usr/share/doc` file. +2. Find one distribution or upstream source. +3. Find one community source. +4. Write a reading note that compares all three. +5. Run one read-only command from the safest source in a lab environment. +6. Record what the command proved and what it did not prove. + +## Check your understanding -Remember, each line of code you read and each command you write gets you one step closer to mastering Linux. Happy reading, fellow explorer! 📚🐧💡 +- Why should local documentation usually be checked before a web search? +- When is a book better than a manual page? +- Why can community sources be useful and risky at the same time? +- What should you verify before following upstream documentation? +- What belongs in a good reading note?