Home / Alt manpages / nss(5)

  • nss(5)
  • File format
  • linux

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.

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 NIS initgroups(3) backend.
  • SERVICES_AUTHORITATIVE, for the NIS getservbyname(3) and getservbyname_r(3) backends.
  • SETENT_BATCH_READ, for the NIS setpwent(3) and setgrent(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=TRUE lets the NIS initgroups backend trust netid.byname as authoritative. The administrator must ensure that map is correctly generated. This can avoid work when group.byname is large.
  • SERVICES_AUTHORITATIVE=TRUE lets the NIS services backend assume that services.byservicename exists 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=TRUE makes 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.conf still has the intended lookup order.
  • /etc/default/nss contains only deliberate, documented TRUE/FALSE assignments.
  • 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 getent checks and application workload still behave as expected.