Solaris Naming Services Architecture
- Dec 6, 2001
- Sample Chapter is provided courtesy of Prentice Hall
- Evolution of Solaris Naming Services
- NIS and Files Coexistence
- NIS and DNS Coexistence
- Solaris Naming Service Switch
- Solaris Naming Service Switch Architecture
- NIS Architecture Overview
- NIS Client Server Architecture
- How NIS Clients Bind to the NIS Server
- NIS Maps
- NIS High Availability Architecture Features
- NIS+ Architecture Overview
- NIS+ Client Server Architecture
- How NIS+ Clients Bind to the NIS+ Server
- NIS+ Tables
- NIS+ Interaction with DNS
- NIS+ High Availability Architecture Features
- Solaris DNS Architecture Overview
- DNS Client Architecture
- DNS Server Architecture
- DNS High Availability Features
- LDAP Architecture Overview
- LDAP Information Model
- LDAP Naming Model
- LDAP Functional Model
- LDAP Security Model
- LDAP Replication
- Comparison with Legacy Naming Services
This chapter is from the book
Solaris and LDAP Naming Services: Deploying LDAP in the Enterprise
NIS Client Server Architecture
Deployment of NIS consists of one or more servers and clients that access the servers. Clients and servers communicate with each other by the Remote Procedure Call (RPC) mechanism. NIS client and server implementations are available on many different platforms and can interoperate with one another.
FIGURE 2-2 shows the major components of NIS.
FIGURE 2-2 Major NIS Components
NIS uses a master-slave model by which all updates to NIS maps are performed on the master, then propagated to the slave servers. The propagation can be performed in either a push or pull manner, that is, either initiated by the master or by the client.
The map transfer protocol was not designed to accommodate large maps. Instead of only propagating incremental changes, entire maps are transferred. Careful planning of scheduling policies for map transfers is advisable to prevent overloading of a network during peak time.
Account Sign In
View your cart
){kind=link}