nscd.conf

title: nscd.conf(5)

text:
# nscd.conf(5)

## NAME
nscd.conf - name service cache daemon configuration file

## DESCRIPTION
The file /etc/nscd.conf is read from nscd(8) at startup. Each line specifies either an attribute and a value, or an attribute, service, and a value. Fields are separated either by SPACE or TAB characters. A '#' (number sign) indicates the beginning of a comment; following characters, up to the end of the line, are not interpreted by nscd.

Valid services are passwd, group, hosts, services, or netgroup.

logfile debug-file-name

Specifies name of the file to which debug info should be written.

debug-level value

Sets the desired debug level. 0 hides debug info. 1 shows general debug info. 2 additionally shows data in cache dumps. 3 (and above) shows all debug info. The default is 0.

threads number

This is the initial number of threads that are started to wait for requests. At least five threads will always be created. The number of threads may increase dynamically up to max-threads in response to demand from clients, but never decreases.

max-threads number

Specifies the maximum number of threads. The default is 32.

server-user user

If this option is set, nscd will run as this user and not as root. If a separate cache for every user is used (-S parameter), this option is ignored.

stat-user user

Specifies the user who is allowed to request statistics.

reload-count unlimited | number

Sets a limit on the number of times a cached entry gets reloaded without being used before it gets removed. The limit can take values ranging from 0 to 254; values 255 or higher behave the same as unlimited. Limit values can be specified in either decimal or hexadecimal with a "0x" prefix. The special value unlimited is case-insensitive. The default limit is 5. A limit of 0 turns off the reloading feature. See NOTES below for further discussion of reloading.

paranoia <yes|no>

Enabling paranoia mode causes nscd to restart itself periodically. The default is no.

restart-interval time

Sets the restart interval to time seconds if periodic restart is enabled by enabling paranoia mode. The default is 3600.

enable-cache service <yes|no>

Enables or disables the specified service cache. The default is no.

positive-time-to-live service value

Sets the TTL (time-to-live) for positive entries (successful queries) in the specified cache for service. Value is in seconds. Larger values increase cache hit rates and reduce mean response times, but increase problems with cache coherence. Note that for some name services (including specifically DNS) the TTL returned from the name service is used and this attribute is ignored.

negative-time-to-live service value

Sets the TTL (time-to-live) for negative entries (unsuccessful queries) in the specified cache for service. Value is in seconds. Can result in significant performance improvements if there are several files owned by UIDs (user IDs) not in system databases (for example untarring the Linux kernel sources as root); should be kept small to reduce cache coherency problems.

suggested-size service value

This is the internal hash table size, value should remain a prime number for optimum efficiency. The default is 211.

check-files service <yes|no>

Enables or disables checking the file belonging to the specified service for changes. The files are /etc/passwd, /etc/group, /etc/hosts, /etc/resolv.conf, /etc/services, and /etc/netgroup. The default is yes.

persistent service <yes|no>

Keep the content of the cache for service over server restarts; useful when paranoia mode is set. The default is no.

shared service <yes|no>

The memory mapping of the nscd databases for service is shared with the clients so that they can directly search in them instead of having to ask the daemon over the socket each time a lookup is performed. The default is no. Note that a cache miss will still result in asking the daemon over the socket.

max-db-size service bytes

The maximum allowable size, in bytes, of the database files for the service. The default is 33554432.

auto-propagate service <yes|no>

When set to no for passwd or group service, then the .byname requests are not added to passwd.byuid or group.bygid cache. This can help with tables containing multiple records for the same ID. The default is yes. This option is valid only for services passwd and group.

## NOTES
The default values stated in this manual page originate from the source code of nscd(8) and are used if not overridden in the configuration file. The default values used in the configuration file of your distribution might differ.

### Reloading
nscd(8) has a feature called reloading, whose behavior can be surprising.

Reloading is enabled when the reload-count attribute has a non-zero value. The default value in the source code enables reloading, although your distribution may differ.

When reloading is enabled, positive cached entries (the results of successful queries) do not simply expire when their TTL is up. Instead, at the expiry time, nscd will "reload", i.e., re-issue to the name service the same query that created the cached entry, to get a new value to cache. Depending on /etc/nsswitch.conf this may mean that a DNS, LDAP, or NIS request is made. If the new query is successful, reloading will repeat when the new value would expire, until reload-count reloads have happened for the entry, and only then will it actually be removed from the cache. A request from a client which hits the entry will reset the reload counter on the entry. Purging the cache using nscd -i overrides the reload logic and removes the entry.

Reloading has the effect of extending cache entry TTLs without compromising on cache coherency, at the cost of additional load on the backing name service. Whether this is a good idea on your system depends on details of your applications' behavior, your name service, and the effective TTL values of your cache entries. Note that for some name services (for example, DNS), the effective TTL is the value returned from the name service and not the value of the positive-time-to-live attribute.

Please consider the following advice carefully:

•

If your application will make a second request for the same name, after more than 1 TTL but before reload-count TTLs, and is sensitive to the latency of a cache miss, then reloading may be a good idea for you.

•

If your name service is configured to return very short TTLs, and your applications only make requests rarely under normal circumstances, then reloading may result in additional load on your backing name service without any benefit to applications, which is probably a bad idea for you.

•

If your name service capacity is limited, reloading may have the surprising effect of increasing load on your name service instead of reducing it, and may be a bad idea for you.

•

Setting reload-count to unlimited is almost never a good idea, as it will result in a cache that never expires entries and puts never-ending additional load on the backing name service.

Some distributions have an init script for nscd(8) with a reload command which uses nscd -i to purge the cache. That use of the word "reload" is entirely different from the "reloading" described here.

## SEE ALSO
nscd(8)


nss

package: man-pages

title: nss(5)

summary: Name Service Switch configuration file

text:
# nss(5)

## NAME
nss - Name Service Switch configuration file

## DESCRIPTION
Each call to a function which retrieves data from a system database like the password or group database is handled by the Name Service Switch implementation in the GNU C library. The various services provided are implemented by independent modules, each of which naturally varies widely from the other.

The default implementations coming with the GNU C library are by default conservative and do not use unsafe data. This might be very costly in some situations, especially when the databases are large. Some modules allow the system administrator to request taking shortcuts if these are known to be safe. It is then the system administrator's responsibility to ensure the assumption is correct.

There are other modules where the implementation changed over time. If an implementation used to sacrifice speed for memory consumption, it might create problems if the preference is switched.

The /etc/default/nss file contains a number of variable assignments. Each variable controls the behavior of one or more NSS modules. White spaces are ignored. Lines beginning with '#' are treated as comments.

The variables currently recognized are:

NETID_AUTHORITATIVE = TRUE|FALSE

If set to TRUE, the NIS backend for the initgroups(3) function will accept the information from the netid.byname NIS map as authoritative. This can speed up the function significantly if the group.byname map is large. The content of the netid.byname map is used as is. The system administrator has to make sure it is correctly generated.

SERVICES_AUTHORITATIVE = TRUE|FALSE

If set to TRUE, the NIS backend for the getservbyname(3) and getservbyname_r(3) functions will assume that the services.byservicename NIS map exists and is authoritative, particularly that it contains both keys with /proto and without /proto for both primary service names and service aliases. The system administrator has to make sure it is correctly generated.

SETENT_BATCH_READ = TRUE|FALSE

If set to TRUE, the NIS backend for the setpwent(3) and setgrent(3) functions will read the entire database at once and then hand out the requests one by one from memory with every corresponding getpwent(3) or getgrent(3) call respectively. Otherwise, each getpwent(3) or getgrent(3) call might result in a network communication with the server to get the next entry.

## FILES
/etc/default/nss

## EXAMPLES
The default configuration corresponds to the following configuration file:

```
NETID_AUTHORITATIVE=FALSE
SERVICES_AUTHORITATIVE=FALSE
SETENT_BATCH_READ=FALSE
```

## SEE ALSO
nsswitch.conf

branch: sisyphus


nsswitch.conf

title: nsswitch.conf(5)

summary: Name Service Switch configuration file

text:
# nsswitch.conf(5)

## NAME
nsswitch.conf - Name Service Switch configuration file

## DESCRIPTION
The Name Service Switch (NSS) configuration file, /etc/nsswitch.conf, is used by the GNU C Library and certain other applications to determine the sources from which to obtain name-service information in a range of categories, and in what order. Each category of information is identified by a database name.

The file is plain ASCII text, with columns separated by spaces or tab characters. The first column specifies the database name. The remaining columns describe the order of sources to query and a limited set of actions that can be performed by lookup result.

The following databases are understood by the GNU C Library:

aliases

Mail aliases, used by getaliasent(3) and related functions.

ethers

Ethernet numbers.

group

Groups of users, used by getgrent(3) and related functions.

hosts

Host names and numbers, used by gethostbyname(3) and related functions.

initgroups

Supplementary group access list, used by getgrouplist(3) function.

netgroup

Network-wide list of hosts and users, used for access rules. C libraries before glibc 2.1 supported netgroups only over NIS.

networks

Network names and numbers, used by getnetent(3) and related functions.

passwd

User passwords, used by getpwent(3) and related functions.

protocols

Network protocols, used by getprotoent(3) and related functions.

publickey

Public and secret keys for Secure_RPC used by NFS and NIS+.

rpc

Remote procedure call names and numbers, used by getrpcbyname(3) and related functions.

services

Network services, used by getservent(3) and related functions.

shadow

Shadow user passwords, used by getspnam(3) and related functions.

The GNU C Library ignores databases with unknown names. Some applications use this to implement special handling for their own databases. For example, sudo(8) consults the sudoers database. Delegation of subordinate user/group IDs can be configured using the subid database. Refer to subuid(5) and subgid(5) for more details.

Here is an example /etc/nsswitch.conf file:

```
passwd:         compat
group:          compat
shadow:         compat
hosts:          dns [!UNAVAIL=return] files
networks:       nis [NOTFOUND=return] files
ethers:         nis [NOTFOUND=return] files
protocols:      nis [NOTFOUND=return] files
rpc:            nis [NOTFOUND=return] files
services:       nis [NOTFOUND=return] files
```

The first column is the database name. The remaining columns specify:

•

One or more service specifications, for example, "files", "db", or "nis". The order of the services on the line determines the order in which those services will be queried, in turn, until a result is found.

•

Optional actions to perform if a particular result is obtained from the preceding service, for example, "[NOTFOUND=return]".

The service specifications supported on your system depend on the presence of shared libraries, and are therefore extensible. Libraries called /lib/libnss_SERVICE.so.X will provide the named SERVICE. On a standard installation, you can use "files", "db", "nis", and "nisplus". For the hosts database, you can additionally specify "dns". For the passwd, group, and shadow databases, you can additionally specify "compat" (see Compatibility mode below). The version number X may be 1 for glibc 2.0, or 2 for glibc 2.1 and later. On systems with additional libraries installed, you may have access to further services such as "hesiod", "ldap", "winbind", and "wins".

An action may also be specified following a service specification. The action modifies the behavior following a result obtained from the preceding data source. Action items take the general form:

[STATUS=ACTION]

[!STATUS=ACTION]

where

STATUS => success | notfound | unavail | tryagain

ACTION => return | continue | merge

The ! negates the test, matching all possible results except the one specified. The case of the keywords is not significant.

The STATUS value is matched against the result of the lookup function called by the preceding service specification, and can be one of:

success

No error occurred and the requested entry is returned. The default action for this condition is "return".

notfound

The lookup succeeded, but the requested entry was not found. The default action for this condition is "continue".

unavail

The service is permanently unavailable. This can mean either that the required file cannot be read, or, for network services, that the server is not available or does not allow queries. The default action for this condition is "continue".

tryagain

The service is temporarily unavailable. This could mean a file is locked or a server currently cannot accept more connections. The default action for this condition is "continue".

The ACTION value can be one of:

return

Return a result now. Do not call any further lookup functions. However, for compatibility reasons, if this is the selected action for the group database and the notfound status, and the configuration file does not contain the initgroups line, the next lookup function is always called, without affecting the search result.

continue

Call the next lookup function.

merge

[SUCCESS=merge] is used between two database entries. When a group is located in the first of the two group entries, processing will continue on to the next one. If the group is also found in the next entry (and the group name and GID are an exact match), the member list of the second entry will be added to the group object to be returned. Available since glibc 2.24. Note that merging will not be done for getgrent(3) nor will duplicate members be pruned when they occur in both entries being merged.

### Compatibility mode (compat)
The NSS "compat" service is similar to "files" except that it additionally permits special entries in corresponding files for granting users or members of netgroups access to the system. The following entries are valid in this mode:

For passwd and shadow databases:

+user

Include the specified user from the NIS passwd/shadow map.

+@netgroup

Include all users in the given netgroup.

-user

Exclude the specified user from the NIS passwd/shadow map.

-@netgroup

Exclude all users in the given netgroup.

+

Include every user, except previously excluded ones, from the NIS passwd/shadow map.

For group database:

+group

Include the specified group from the NIS group map.

-group

Exclude the specified group from the NIS group map.

+

Include every group, except previously excluded ones, from the NIS group map.

By default, the source is "nis", but this may be overridden by specifying any NSS service except "compat" itself as the source for the pseudo-databases passwd_compat, group_compat, and shadow_compat.

## FILES
A service named SERVICE is implemented by a shared object library named libnss_SERVICE.so.X that resides in /lib.

/etc/nsswitch.conf

NSS configuration file.

/lib/libnss_compat.so.X

implements "compat" source.

/lib/libnss_db.so.X

implements "db" source.

/lib/libnss_dns.so.X

implements "dns" source.

/lib/libnss_files.so.X

implements "files" source.

/lib/libnss_hesiod.so.X

implements "hesiod" source.

/lib/libnss_nis.so.X

implements "nis" source.

/lib/libnss_nisplus.so.X

implements "nisplus" source.

The following files are read when "files" source is specified for respective databases:

aliases

/etc/aliases

ethers

/etc/ethers

group

/etc/group

hosts

/etc/hosts

initgroups

/etc/group

netgroup

/etc/netgroup

networks

/etc/networks

passwd

/etc/passwd

protocols

/etc/protocols

publickey

/etc/publickey

rpc

/etc/rpc

services

/etc/services

shadow

/etc/shadow

## NOTES
Starting with glibc 2.33, nsswitch.conf is automatically reloaded if the file is changed. In earlier versions, the entire file was read only once within each process. If the file was later changed, the process would continue using the old configuration.

Traditionally, there was only a single source for service information, often in the form of a single configuration file (e.g., /etc/passwd). However, as other name services, such as the Network Information Service (NIS) and the Domain Name Service (DNS), became popular, a method was needed that would be more flexible than fixed search orders coded into the C library. The Name Service Switch mechanism, which was based on the mechanism used by Sun Microsystems in the Solaris 2 C library, introduced a cleaner solution to the problem.

## SEE ALSO
getent(1), nss(5)


passwd

title: passwd(5)

summary: password file

text:
# passwd(5)

## NAME
passwd - password file

## DESCRIPTION
The /etc/passwd file is a text file that describes user login accounts for the system. It should have read permission allowed for all users (many utilities, like ls(1) use it to map user IDs to usernames), but write access only for the superuser.

In the good old days there was no great problem with this general read permission. Everybody could read the encrypted passwords, but the hardware was too slow to crack a well-chosen password, and moreover the basic assumption used to be that of a friendly user-community. These days many people run some version of the shadow password suite, where /etc/passwd has an 'x' character in the password field, and the encrypted passwords are in /etc/shadow, which is readable by the superuser only.

If the encrypted password, whether in /etc/passwd or in /etc/shadow, is an empty string, login is allowed without even asking for a password. Note that this functionality may be intentionally disabled in applications, or configurable (for example using the "nullok" or "nonull" arguments to pam_unix(8)).

If the encrypted password in /etc/passwd is "*NP*" (without the quotes), the shadow record should be obtained from an NIS+ server.

Regardless of whether shadow passwords are used, many system administrators use an asterisk (*) in the encrypted password field to make sure that this user can not authenticate themself using a password. (But see NOTES below.)

If you create a new login, first put an asterisk (*) in the password field, then use passwd(1) to set it.

Each line of the file describes a single user, and contains seven colon-separated fields:

```
name:password:UID:GID:GECOS:directory:shell
```

The field are as follows:

name

This is the user's login name. It should not contain capital letters.

password

This is either the encrypted user password, an asterisk (*), or the letter 'x'. (See pwconv(8) for an explanation of 'x'.)

UID

The privileged root login account (superuser) has the user ID 0.

GID

This is the numeric primary group ID for this user. (Additional groups for the user are defined in the system group file; see group(5)).

GECOS

This field (sometimes called the "comment field") is optional and used only for informational purposes. Usually, it contains the full username. Some programs (for example, finger(1)) display information from this field.

GECOS stands for "General Electric Comprehensive Operating System", which was renamed to GCOS when GE's large systems division was sold to Honeywell. Dennis Ritchie has reported: "Sometimes we sent printer output or batch jobs to the GCOS machine. The gcos field in the password file was a place to stash the information for the $IDENTcard. Not elegant."

directory

This is the user's home directory: the initial directory where the user is placed after logging in. The value in this field is used to set the HOME environment variable.

shell

This is the program to run at login (if empty, use /bin/sh). If set to a nonexistent executable, the user will be unable to login through login(1). The value in this field is used to set the SHELL environment variable.

## FILES
/etc/passwd

## NOTES
If you want to create user groups, there must be an entry in /etc/group, or no group will exist.

If the encrypted password is set to an asterisk (*), the user will be unable to login using login(1), but may still login using rlogin(1), run existing processes and initiate new ones through rsh(1), cron(8), at(1), or mail filters, etc. Trying to lock an account by simply changing the shell field yields the same result and additionally allows the use of su(1).

## SEE ALSO
chfn(1), chsh(1), login(1), passwd(1), su(1), crypt(3), getpwent(3), getpwnam(3), group(5), shadow(5), vipw(8)