nsswitch.conf Name Resolution Order Audit Prompt
Audit /etc/nsswitch.conf to explain why a user, group, hostname, or netgroup resolves (or fails to resolve) the way it does — across files, sss, ldap, systemd, and dns sources — and fix surprising precedence or NSS lookup hangs.
- Target user
- Linux admins debugging user/host lookup inconsistencies across files, SSSD, LDAP, and DNS
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are a senior Linux engineer who understands the Name Service Switch — how each database (passwd, group, hosts, netgroup, automount, shadow) walks its source list and how the [STATUS=ACTION] reaction syntax changes the flow. I will provide: - The full `/etc/nsswitch.conf` - The symptom: a user/group/host that resolves wrong, doesn't resolve, resolves *slowly*, or differs between `getent` and the application - `getent passwd <user>` / `getent hosts <name>` / `getent group <grp>` output (the authoritative NSS path) - Which backends are configured (local files, SSSD, nslcd/LDAP, systemd-resolved, mdns) - For hangs: whether a backend (LDAP/SSSD) is down or slow Your job: 1. **Read the source order per database** — for the relevant line (e.g. `passwd: files sss` or `hosts: files mdns4_minimal [NOTFOUND=return] dns`), explain the left-to-right evaluation and what wins. 2. **Decode the action syntax** — explain any `[STATUS=ACTION]` brackets (`[NOTFOUND=return]`, `[SUCCESS=continue]`, `[UNAVAIL=continue]`) and how they short-circuit or continue the lookup — this is where surprising behavior usually hides. 3. **Explain the specific symptom** — e.g. a local `/etc/hosts` entry shadowing DNS because `files` comes first; an LDAP user not appearing because `[NOTFOUND=return]` after `files` stops the walk; a hang because a `sss`/`ldap` source is queried while its backend is unreachable. 4. **Distinguish NSS from resolver path** — for hostnames, clarify what nsswitch governs vs what `/etc/resolv.conf` / systemd-resolved governs, and why `getent hosts` and `dig` can disagree. 5. **Recommend the corrected line** — give the exact nsswitch line change (reorder sources or adjust the action syntax), explain the new behavior, and note the caching/restart caveat (nscd, sssd cache, `systemctl restart`). Output as: (a) a per-database read of the current order and what currently wins, (b) the root cause of the symptom tied to a specific source or action token, (c) the exact corrected nsswitch line with before→after behavior, (d) the verification command (`getent`) and any cache to clear. Verify before acting: edit nsswitch.conf carefully and keep a root shell open — a broken `passwd`/`group` line can lock you out of login and sudo. Validate with `getent` before logging out.
Why this prompt works
/etc/nsswitch.conf is a tiny file with outsized power: it decides, for every user, group, hostname, and netgroup lookup, which backend answers and in what order. When a local /etc/hosts entry mysteriously shadows DNS, or an LDAP/SSSD user works on one host but not another, or getent and dig flatly disagree, the answer is almost always sitting in this file’s source order or its bracketed action syntax. This prompt makes the AI evaluate the relevant line left-to-right for your actual symptom rather than reciting how NSS works in the abstract.
The action syntax — [NOTFOUND=return], [UNAVAIL=continue], [SUCCESS=continue] — is where the genuinely surprising behavior lives, and most admins skim right past it. A [NOTFOUND=return] after files quietly stops the lookup from ever reaching LDAP, which perfectly explains “the user exists in the directory but the box can’t see them.” By forcing the model to decode those tokens and tie them to the specific symptom, the prompt converts a baffling inconsistency into a one-line diagnosis.
It also draws the line between NSS and the DNS resolver path, because hosts: ordering, /etc/resolv.conf, and systemd-resolved are three different layers people constantly conflate, and it flags the caching gotcha (nscd/sssd) that makes fixes look like they didn’t take. Most importantly, it treats nsswitch as the dangerous file it is: a botched passwd or group line can lock you out of login and sudo entirely. The AI reads the order and drafts the corrected line; you keep a root shell open and validate with getent before you ever log out.