LDAP-UX Integration Performance and Tuning Guidelines

LDAP-UX Integration Performance and Tuning Guidelines
Name Service Configuration
Aside from the common example above of programs that call the getpwxxx() procedures, there are obviously other
programs that call various other name service APIs, such as getservbynam(). The /etc/nsswitch.conf (man 4 switch)
defines which subsystems will serve those API calls. The load on the LDAP directory server will increase for every
service defined to use “ldap” in the /etc/nsswitch.conf file.
When NIS is deployed in an environment, typically the NIS server serves all the name service subsystems. The
following is an example default nsswitch.conf file for NIS:
# An example file that could be copied over to /etc/nsswitch.conf; it
# uses NIS (YP) in conjunction with files.
#
passwd: files nis
group: files nis
hosts: nis [NOTFOUND=return] files
networks: nis [NOTFOUND=return] files
protocols: nis [NOTFOUND=return] files
rpc: nis [NOTFOUND=return] files
publickey: nis [NOTFOUND=return] files
netgroup: nis [NOTFOUND=return] files
automount: files nis
aliases: files nis
services: files nis
In the above file, the /etc/passwd, /etc/group, /etc/automount, /etc/mail/aliases and /etc/services files are first queried
to resolve requests for those services. Typically in a fully deployed NIS environment, these files contain minimal
information (except /etc/services.) So often, the NIS server is queried for requests on those services (getpwnam()
first scans the /etc/passwd file, and if the requested data is not found, then the NIS server is queried.) For the other
services in this example, the NIS server will always be queried.
This configuration file places a heavy demand from the NIS client on the NIS server. Thus, replacing “nis” with
“ldap” in the configuration file will place significant load on the LDAP directory server. Today, most LDAP
directory servers achieve their greatest value by integrating people and group related information. While, with many
exceptions, storing other information, such as network routing information (which can often be discovered
dynamically, without the aid of the network name service) or similar information may be of lesser value to store in
the LDAP directory. It’s a good idea to determine which services truly need to be shared on the LDAP server, while
other services could be either stored locally in files or in other repositories (such as DNS.) Often, many services,
such as rpc or networks, do not need to be shared through LDAP, since a typical deployment does not often modify
the default values for those subsystems. And often, other networked based repositories are better sources for certain
name services (for example DNS is often the best name service repository for the hosts database.)
Before switching all services to LDAP, it’s important to determine which are best shared through LDAP, and which
can be better stored in local files, or other network based repositories.
Knowing that an LDAP directory server gains its greatest value when used as a repository for the integration and
centralization of people management , here is what a nsswitch.conf file for LDAP-UX might look like:
passwd: files ldap
group: files ldap
hosts: files
networks: files
protocols: files
rpc: files
publickey: files (not supported by LDAP-UX)
netgroup: files ldap
automount: files (not supported by LDAP-UX)
aliases: ldap
services: files
Page 7