RSS

Monthly Archives: February 2014

Continuation: A overall view of NSS

Last time we took code snippets and had code specific understanding about NSS. This time lets sum up NSS responder as a whole.

NSS: The Name Service Switch (NSS) is a facility in Unix-like operating systems that provides a variety of sources for common configuration databases and name resolution mechanisms. These sources include local operating system files (such as /etc/passwd, /etc/group, and /etc/hosts), the Domain Name System (DNS), the Network Information Service (NIS), and LDAP.

NSS Data flow:

This diagram shows the data flow generated by an SSS Client Application making an NSS request to SSSD.

nss_ctx

The NSS Responder’s context (nss_ctx) is created at startup by nss_process_init(), which takes several actions, including:

  • calling sss_process_init() with Responder-specific arguments, including supported commands and supported SBus methods
  • initializing idmap_ctx
  • initializing Responder-specific optimizations (see NSS Optimizations section)
  • retrieving Responder-specific config information from the confdb

Client-Facing Interactions:

The commands supported by the NSS Responder are defined in nsssrv_cmd.c. These commands (and their inputs) are extracted from the packet sent to the Responder by the SSS Client. After processing the command, the NSS Responder returns a packet to the SSS Client containing command output and/or an error message.

Backend-Facing Interactions:

The NSS Responder communicates with the Backend using a single SBus method named getAccountInfo. For getAccountInfo, the outgoing SBus request message is constructed by sss_dp_get_account_msg and “sent” by sbus_conn_send. The incoming SBus reply message is “received” by sss_dp_get_reply.

Complete Data Flow as such:

NSS Responder reads a packet from the client socket, processes it and  writes an SBus message to the backend socket. Later NSS Responder reads the SBus message reply from the backend socket, processes the reply and writes a reply packet to the client socket. To conclude the complete working, it goes as following:-

1. SSS Client Application’s request is handled by our dynamically loaded NSS Client Library, which consults the fast cache. If valid cache entry exists, NSS Client Library immediately returns cached result to SSS Client Application.

2. If no valid cache entry exists in fast cache, NSS Client Library sends client’s NSS request to matching NSS Responder.

3. NSS Responder consults Cache. If valid cache entry exists (unexpired), NSS Responder immediately returns cached result to SSS Client Application (this step not shown above)

4. If no valid cache entry exists, NSS Responder sends getAccountInfo request message to Backend, asking Backend to update Cache with data corresponding to client’s NSS request.

5.Backend uses AD Provider Plugin to make LDAP call to remote AD Server and to retrieve response from AD Server.

6. Backend updates Cache, and also sends getAccountInfo response message (containing status) to NSS Responder; this also serves as indication that Cache has been updated.

7. NSS Responder reads updated result from Cache.

8. NSS Responder returns updated result to NSS Client Library, which passes it to SSS Client Application.

Next thing will be to talk about PAM responder, bit complex than NSS but interesting 🙂

Reference: http://en.wikipedia.org/wiki/Name_Service_Switch

https://fedorahosted.org/sssd/wiki/InternalsDocs

 

 
Leave a comment

Posted by on February 16, 2014 in Uncategorized