The POSIX API/NSS/NSCD

Https://code.google.com/p/nsscache/wiki/BackgroundOnNameServiceSwitch the POSIX API

POSIX is a standard that defines an operating system interface and its environment; Describing available library calls, utilities, environment vars, escape sequences, Regexps, when to take coffee breaks (AK A how long your code takes to compile), etc.

Gnu/linux is (generally) POSIX compliant.

The relevant component of POSIX is the definition of a function calls to access directory information--databases of people /groups/hosts/etc.

Here is some examples of the POSIX API functions, the method in which applications access information in the system D Atabases.

• Get*nam (), get a database entry by its human readable name
• Get*id (), get a database entry by its computer readable name
• get*ent (), get the next entry in a database; A mechanism for iterating over the entire database

(The asterisk replaces the short name of the database being accessed.)

These functions get called all the time, for example:

• At login (to find out who is and what your groups is)
• ls-l (Mapping uid/gid of a file to Username/group)
• Resolving hostnames to IP addresses
• Many Others:nis netgroups, automount locations, RPC names, TCP and UDP protocol names

It doesn ' t matter for the most part of the these API calls is made all the time, because when the API is designed, the DAT Abase that stored this information are a plain text file on the local machine, and accessing that is both fast and 100% rel Iable (ignoring of course hardware issues on the local machine, at which point you have bigger problems:-)

As we got bigger networks and lots of GKFX computing infrastructure, we moved to directory services. /etc/hosts stopped scaling, so we got DNS, and it all went downhill from there.

System administrators wanted to get the system databases from and sources like NIS, nis+, LDAP, Hesiod (gag), DNS, etc. To facilitate this, you want the easy runtime configuration changes, i.e. different types of the data may need to be stor Ed in different places--the users in/etc/passwd versus the hosts in DNS.

First implemented by Sun, this is dubbed the name Service switch, or NSS for short.

The Name Service Switch

Perhaps you ' re familiar with the Name Service Switch configuration file, /etc/nsswitch.conf:

passwd: compat files
Group: compat files
Shadow: compat files
Hosts: files DNS 

On the hand side of the colon is the data sources, where NSS would go to retrieve the system database. It progresses left-to-right, checking all source in turn until the data is found.

On the left hand side of the colon, the groupings of data, the database itself, which we is calling "maps"-In this Exa Mple, the passwd database API functions is mapped to the "Compat" and "files" data sources.

For we own convenience, this document would refer to both the POSIX API described above, and the GNU libc implementation O f the Name Service Switch as both "NSS".

#/etc/nsswitch.conf
passwd: files 

When a NSS function is called, the NSS implementation reads its configuration file /etc/nsswitch.conf, which Nam Es the library that implements the data retrieval. NSS dynamically loads this library, in this example, libnss_files.so. The correct function within this library are then called, for example _nss_files_getpwuid ().

libnss_files then opens and parses /etc/passwd, and returns (typically a struct).

NSS + RFC 2307 LDAP

#/etc/nsswitch.conf
passwd: files LDAP 

ADD in a directory service, and you get a situation familiar to many sysadmins. /etc/nsswitch.conf would now also list LDAP In addition to filesin this example.

If NSS were to the load libnss_files.so, and find nothing, it would then load libnss_ldap.so. libnss_ldap.so would make a network connection to the LDAP server, perform a query, and convert the LDAP result s into the right return structure.

This means, every query would translate into a TCP connection with handshake overhead, possibly over SSL with its crypt o overhead, and then do various ASN.1 and BER En-and decodings within the LDAP protocol itself ...

Name Service Cache Daemon

So we also typically run a caching daemon, provided by GNU libc, called nscd.

It ' s accessed via a UNIX socket, and though poorly demonstrated by this diagram, loads the NSS modules itself in order to Act as a hit-and-miss cache.

It has several threads to that it can respond to several requests at the same time.

If the cache has the response, it returns it straight away. If not, it dlopens the NSS module, e.g libnss_ldap.so, waits for the reply, caches it, and then returns it.

The POSIX API/NSS/NSCD