Lab briefing · Map a running instance

Produce a ONE-PAGE MAP of an instance you did not build: tiers, processes, ports, file systems and logs. EVERY LATER LAB USES IT. "Every later lab uses it" is literal. Starting and stopping needs the process list; patching needs the file systems; cloning needs both plus the ports; every incident needs the logs. Building it once is the cheapest hour in the course, and skipping it means re-deriving the same facts under time pressure eighteen times. WORK FROM THE SYSTEM, NOT FROM THE DOCUMENTATION. The documentation describes what somebody built or intended; Lesson 9's three surprises are all cases where the two disagree. Anything on your map that came from a document rather than a command is a claim rather than a fact, and marking which is which is part of the deliverable. THE PAGE HAS FIVE SECTIONS AND EACH IS SHORT. TIERS: which hosts, which tier on each, and…

In this module: Module 2 · The stack you are responsible for

1. 1The two tiers, and why the split matters
2. 2What is running right now
3. 3The file system layout
4. 4Environment files, and sourcing the right one
5. 5The context file
6. 6AutoConfig, and what it overwrites
7. 7Ports, and the ones you will be asked about
8. 8Logs: where they are and which one to open first
9. 9What breaks: three architecture surprises
10. 10Lab briefing · Map a running instance