Naming and Directory Services (DNS, NIS, and LDAP)

nisplusLDAPdatabaseIdMappingnisplusLDAPdatabaseIdMappingrpc_table:rpc.org_dirrpc:rpc.org_dirdefines the database ids rpc_table and rpc as aliases for the rpc.org_dir table.Later definitions will make it clear that rpc_table is used for the rpc.org_dirtable object, and rpc for the entries in that table.nisplusLDAPentryTtl AttributeSince the rpc.nisd daemon’s local database (in memory and on disk) functions as acache for LDAP data, the nisplusLDAPentryTtl attribute allows you to set thetime-to-live (TTL) values of entries in that cache. There are three TTLs for eachdatabase ID. The first two control the initial TTL when the rpc.nisd first loads thecorresponding NIS+ object data from disk, and the third TTL is assigned to an objectwhen it is read or refreshed from LDAP.For example the following results in the rpc.org_dir table object getting an initialTTL randomly selected in the range 21600 to 43200 seconds.nisplusLDAPentryTtlrpc_table:21600:43200:43200When that initial TTL expires and the table object is refreshed from LDAP, the TTL willbe set to 43200 seconds.Similarly the following will assign an initial TTL between 1800 and 3600 seconds tothe entries in the rpc.org_dir table when it is first loaded.nisplusLDAPentryTtlrpc:1800:3600:3600Each entry gets its own randomly selected TTL in the range specified. When a tableentry expires and is refreshed, the TTL is set to 3600 seconds.When selecting TTL values, consider the trade-off between performance andconsistency. If the TTLs used for LDAP data cached by the rpc.nisd are very long,performance is the same as if rpc.nisd was not mapping data from LDAP at all.However, if the LDAP data is changed (by some entity other than rpc.nisd), it canalso take a very long time before that change is visible in NIS+.Conversely, selecting a very short (or even zero) TTL means that changes to LDAPdata are quickly visible in NIS+, but can also impose a significant performancepenalty. Typically, an NIS+ operation that also reads data from or writes data to LDAPwill take at least two to three times longer (plus the LDAP lookup overhead) than thesame operation without LDAP communication. Although performance can varygreatly depending on the hardware resources, scanning a large (tens of thousands orhundreds of thousands of entries) LDAP container to identify NIS+ entries that shouldbe refreshed can take a long time. The rpc.nisddaemon performs this scan in thebackground, continuing to serve possibly stale data while it is running, but thebackground scan still consumes CPU and memory on the NIS+ server.260 System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) • January 2005