Tune GNU NSS with /etc/default/nss Without Touching Lookup Order
This guide configures the three GNU Name Service Switch tuning variables in /etc/default/nss, then checks that the file contains what you intended. It does not change which databases NSS consults. That job belongs to /etc/nsswitch.conf.
The route
Jump straight to the step you need, or tick off Done means at the end.
Allow about 10 minutes. You need a shell account with sudo access if the file does not already exist, and you should know whether this machine actually uses NIS. The examples use the manpages package version 6.7-2, whose installed page is Linux man-pages 6.7.
Checkpoint: identify the two different NSS files
First inspect the lookup order as an ordinary user:
sed -n '1,120p' /etc/nsswitch.conf
Lines such as passwd: files systemd select NSS services and their order. The settings covered here are separate. GNU libc reads variable assignments from /etc/default/nss; the installed nss(5) page documents only three variables:
NETID_AUTHORITATIVE, for the NISinitgroups(3)backend.SERVICES_AUTHORITATIVE, for the NISgetservbyname(3)andgetservbyname_r(3)backends.SETENT_BATCH_READ, for the NISsetpwent(3)andsetgrent(3)backends.
If your NSS configuration has no NIS service involved, these switches are unlikely to change the lookups you care about. Do not add nis to nsswitch.conf merely to make this file useful.
Checkpoint: record the current state
Check whether the optional file exists. This command reads it without requiring elevated privileges:
if test -e /etc/default/nss; then
sed -n '1,120p' /etc/default/nss
else
echo '/etc/default/nss is absent'
fi
An absent file is not an error. The manpage's default behaviour corresponds to all three variables being FALSE. Before changing an existing file, make a root-owned backup with a precise name:
sudo cp --preserve=mode,ownership,timestamps /etc/default/nss /etc/default/nss.before-tuning
That command is elevated and changes the machine. If the file is absent, skip it. The backup name is deliberately outside the configuration name that the NSS modules read.
Set only the switch you need
Use a text editor as root and preserve unrelated settings:
sudoedit /etc/default/nss
Assignments may contain whitespace, and lines beginning with # are comments. Use the exact uppercase variable names and the literal values TRUE or FALSE. For example:
# /etc/default/nss
NETID_AUTHORITATIVE=FALSE
SERVICES_AUTHORITATIVE=FALSE
SETENT_BATCH_READ=TRUE
Each setting has a narrow trade-off:
NETID_AUTHORITATIVE=TRUElets the NISinitgroupsbackend trustnetid.bynameas authoritative. The administrator must ensure that map is correctly generated. This can avoid work whengroup.bynameis large.SERVICES_AUTHORITATIVE=TRUElets the NIS services backend assume thatservices.byservicenameexists and includes the required keys for primary names and aliases, with and without/proto. Use it only when that map is maintained correctly.SETENT_BATCH_READ=TRUEmakes the NIS password or group enumeration functions read the whole database into memory, then serve individual requests from that copy. It can reduce network requests, but memory use grows with the database.
Do not enable an authoritative option as a guess. A stale or incomplete NIS map can make the result wrong, not merely slower. This is a configuration change, but it does not restart a service. Programs may cache NSS results, so test the applications that matter after changing it.
Checkpoint: validate the syntax and preserve an undo path
There is no separate nss command that validates this file. Review the assignments directly:
sudo sed -n '1,120p' /etc/default/nss
sudo awk -F= '/^[[:space:]]*[A-Z_]+[[:space:]]*=/{print NR ": " $0}' /etc/default/nss
The output should show the intended names and values. The second command is only a review aid, not a complete semantic validator. Check that every active assignment is one of the three documented names and that its value is exactly TRUE or FALSE.
If a test exposes a problem, restore the backup made earlier:
sudo cp --preserve=mode,ownership,timestamps /etc/default/nss.before-tuning /etc/default/nss
If you created a new file rather than backing up an old one, remove it with care only after confirming that it is the file you created. Never use a broad wildcard under /etc/default for cleanup.
Verify the surrounding NSS path
These lookups are safe and confirm that ordinary NSS resolution still works:
getent passwd root
getent group root
getent services ssh tcp
Typical output includes a root passwd entry, a root group entry, and an ssh service line containing 22/tcp. Exact formatting and the source of each result depend on /etc/nsswitch.conf. A successful getent call does not prove that a NIS authoritative map is complete; it only shows that the requested lookup returned data.
For an operational performance change, compare the application or enumeration workload that motivated the setting before and after the edit, and watch memory use when SETENT_BATCH_READ is enabled. If the workload does not use the affected NIS function, revert the setting rather than keeping an unexplained machine-wide option.
Done means
/etc/nsswitch.confstill has the intended lookup order./etc/default/nsscontains only deliberate, documentedTRUE/FALSEassignments.- Any authoritative setting is backed by a correctly maintained NIS map.
- You have a tested backup or a clear way to remove the new file.
- The relevant
getentchecks and application workload still behave as expected.