Solaris Naming Services Architecture
- 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
Reading this chapter is not an absolute requirement for deployment of LDAP, but if you become familiar with some of the architectural nuances, you can better understand broader deployment strategies. Each naming service has its own unique characteristics which may dictate how you deploy them. Although the focus of this BluePrint is LDAP, it is helpful to understand the feature set of legacy Solaris naming services to see how this new technology compares.
This is a sample chapter from Solaris and LDAP Naming Services: Deploying LDAP in the Enterprise.
This chapter is from the book
This chapter is from the book
This chapter is from the book
The Solaris operating environment provides a sophisticated infrastructure that supports a variety of naming services. The architecture on which it is based is extensible and able to accommodate new naming services without the need for a rewrite of important operating system utilities that access naming services. The Solaris 8 LDAP naming service plugs into this architecture and is thus accessible to system utilities that formerly had only NIS, NIS+, and DNS available.
Evolution of Solaris Naming Services
The UNIX operating system was developed to operate in a timesharing environment where users access the server via physically attached ASCII terminals. Users typically accessed only one server, so information about user accounts, group memberships, and so on, only needed to be maintained on that server. Storing that information in a text file worked quite well.
The Berkeley version of UNIX introduced the notion of distributed computing built on top of the TCP/IP protocol. Computers running the UNIX operating system could now easily communicate with one another. However, for things to work smoothly, information about users and other systems in the network needed to be maintained on each server. Storing this data in text files meant that any time something changed, the text files on every server needed to be updated.
In 1985, Sun Microsystems produced NIS (Network Information Service), one of the first UNIX-based distributed naming service as a replacement for storing information in text files. The text files would be converted to binary maps that would only be stored on selected computers, called NIS servers, in the network. The other computers in the network would contact the NIS servers when they needed access to the information.
However, some text files still needed to be maintained for two reasons: 1) some data was required during the booting process before access to the network was established and 2) there had to be a way to log in if the computer was disconnected from the network. Moreover, some mechanism was required so that the operating system utilities could search both text files and NIS, since NIS could not completely replace the text files.
The introduction of NIS presented a new system administration model, by which information was administered from a central repository and not all administrators were granted permission to update it. Since some users still wanted to be able to manage local accounts and system information, they needed some way to do this without administering of NIS maps.