Where Did the Logs Go?
Security wants the worst offending IP from yesterday's failed logins. The report says there were none. Should you believe it?
Your goal is not simply to make login-report print some number without crashing. Your goal is to understand how a pipeline moves text from one small command to the next, find the one stage that's actually broken instead of rewriting the whole script, keep error messages out of report data, and prove the fix works on log data you haven't already looked at — not just the one file sitting in front of you.
You already know how to find files. Now you need to pull useful information out of one — by chaining several small Linux commands together, each passing text to the next, until raw log lines become a ranked report.
Before writing a single command, look at the real data
Security's question is simple: which IP addresses have the most failed logins? Before touching any command, look at what the actual log contains.
2026-08-21T14:00:07Z auth portal ip=203.0.113.42 event=LOGIN_FAILED user=user0001
2026-08-21T14:00:14Z auth portal ip=198.51.100.63 event=LOGIN_OK user=user0002
2026-08-21T14:00:21Z auth portal ip=203.0.113.42 event=LOGIN_FAILED user=user0003
2026-08-21T14:00:28Z auth portal ip=198.51.100.17 event=LOGIN_FAILED user=user0004Each line is space-separated, and each field is self-labeled:
- A timestamp
auth portal— where the event came from- `ip=203.0.113.42` — the field we actually care about
- `event=LOGIN_FAILED` or
event=LOGIN_OK— what happened user=...— who attempted it
We need to turn this raw text into: one ranked list of IPs, counted by how many LOGIN_FAILED lines they appear in.
The existing login-report script runs without crashing, but always reports zero failed logins.
Before changing or fixing any command, what should you do first?