- 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
NIS and Files Coexistence
To solve the problem of providing a centrally administered naming service while maintaining some local control, Sun's first implementation of NIS searched the local files before the NIS naming service was consulted. A special character was inserted into the text files to tell the operating system when to start searching the NIS maps. Any line beginning with a "+" character was the signal to contact NIS. For example, the /etc/host file would look like this:
127.0.0.1 localhost 129.148.181.130 tiger 129.154.86.22 galaxy +
In this example, the /etc/hosts file would be searched for the specified host. If the host specified is not tiger or galaxy, then the NIS host map is searched. If the host name does not appear in the NIS map either, an error is returned.
NOTE
The "+" character only has an effect when the Solaris 1 operating environment is running. It will have no effect if the Solaris 2 or later operating environment is running except when run in the Solaris 1 compatibility mode.