2 04 Troubleshooting
Stefan Tanta edited this page 2026-10-09 18:43:43 +02:00

Guided troubleshooting

Goal

Investigate one fault using evidence. Explain your reasoning before changing the system.

Method

  1. Describe the symptom, affected users, start time, and recent changes.
  2. Reproduce it with a bounded test.
  3. Compare the result with the healthy baseline.
  4. Choose one hypothesis and a test that distinguishes it from alternatives.
  5. Record the evidence before changing anything.
  6. Make one justified change in the disposable lab.
  7. Repeat the original failing test from the original client.
  8. Record the cause, fix, and remaining uncertainty.

Avoid restarting everything. That can remove useful evidence without explaining the fault.

Worked reasoning

Symptom: a client cannot open the lab web page.

First confirm the address and port being requested. Test with a timeout:

curl -v --connect-timeout 3 --max-time 10 "http://$server_ip/"

Set server_ip to your lab server's address first. Verbose output may contain sensitive headers in real systems; use it only on this lab request.

For this lab, use server_ip=192.168.20.50. Commands in an SSH session run on the VM, not on your PC.

Observation Useful next investigation
Name cannot resolve Resolver configuration and DNS response
Connection refused Correct destination, listener, service status, or active rejection
Connection times out Address, route, filtering, and server availability
HTTP 404 Requested path and web configuration
Local request works; remote request fails Listen address, network path, and filtering

These are clues, not proofs of one cause. A refused connection does not establish that a firewall is responsible.

Guided practice

Start with DNS, ports, HTTP, and access-log exercises. These require no service or network configuration changes.

Ask your mentor to introduce one fault in the disposable web service after recording its healthy state.

Begin with service status, sockets, logs, and a local request. Compare with the client's failure. Explain your proposed fix before applying it.

Do not change SSH or network settings during the first exercise. Keep console access available for later network exercises.

Independent exercise

Investigate a second single-fault scenario without being told the cause. You may consult notes. Request a hint when evidence stops making sense.

Write a brief report:

Symptom and scope:
Expected behavior:
Tests and observations:
Hypothesis:
Change and reason:
Verification from the client:
Remaining questions:

Completion check

Explain why you chose each test. Demonstrate that the original client request works after the fix.

Next: Bash and support practices