Skip Navigation Links | |
Exit Print View | |
Working With Naming and Directory Services in Oracle Solaris 11.1 Oracle Solaris 11.1 Information Library |
Part I About Naming and Directory Services
1. Naming and Directory Services (Overview)
2. Name Service Switch (Overview)
4. Setting Up Oracle Solaris Active Directory Clients (Tasks)
Part II NIS Setup and Administration
5. Network Information Service (Overview)
6. Setting Up and Configuring NIS (Tasks)
9. Introduction to LDAP Naming Services (Overview)
10. Planning Requirements for LDAP Naming Services (Tasks)
11. Setting Up Oracle Directory Server Enterprise Edition With LDAP Clients (Tasks)
12. Setting Up LDAP Clients (Tasks)
13. LDAP Troubleshooting (Reference)
14. LDAP Naming Service (Reference)
NIS clients are connected to an NIS server through the binding process. This process is supported by the svc:/network/nis/client and svc:/network/nis/domain services. These services must be enabled for any NIS service to operate. The svc:/network/nis/client service can work in one of two modes: server-list or broadcast.
Server-list — In the server-list mode, the ypbind process queries the svc:/network/nis/domain service for the names of all NIS servers in the domain. The ypbind process binds only to servers in this file.
NIS servers can be added by using the svccfg command. They are added to the config/ypservers property in the svc:/network/nis/domain service. Each property value represents a specific NIS server.
Additionally, any server name that is specified in the svc:/network/nis/domain service must contain an entry in the /etc/inet/hosts file for NIS binding to function.
Broadcast — The ypbind process can also use an RPC broadcast to initiate a binding. Because broadcasts are only local subnet events that are not routed further, there must be at least one server (master or slave) on the same subnet as the client. The servers themselves might exist throughout different subnetworks because map propagation works across subnet boundaries. In a subnet environment, one common method is to make the subnet router an NIS server. This allows the domain server to serve clients on either subnet interface.
Broadcast mode is generally the recommended mode of operation. Broadcast mode does not require additional host entries to be specified (or changes to be made to /etc/inet/hosts).
Normally, after a client is bound to a server, it stays bound to that server until something causes the binding to change. For example, if a server goes out of service, the clients it served will then bind to new servers.
To determine which NIS server is currently providing service to a specific client, use the following command.
% ypwhich machinename
where machinename is the name of the client. If no machine name is mentioned, the ypwhich command defaults to the local machine (that is, the machine on which the command is run).
The binding process in server-list mode works as follows:
Any program, running on the NIS client machine that needs information provided by an NIS map, asks ypbind for the name of a server.
The ypbind daemon looks in the /var/yp/binding/domainname/ypservers file for a list of NIS servers for the domain.
The ypbind daemon initiates binding to the first server in the list. If the server does not respond, ypbind tries the second, and so on, until it finds a server or exhausts the list.
The ypbind daemon tells the client process which server to talk to. The client then sends the request directly to the server.
The ypserv daemon on the NIS server handles the request by consulting the appropriate map.
The ypserv daemon sends the requested information back to the client.
The broadcast mode binding process works as follows:
The ypbind daemon must be started with the broadcast option set (broadcast).
The ypbind daemon issues an RPC broadcast in search of an NIS server.
Note - In order to support such clients, it is necessary to have an NIS server on each subnet requiring NIS service.
The ypbind daemon initiates binding to the first server that responds to the broadcast.
The ypbind daemon tells the client process which server to talk to. The client then sends the request directly to the server.
The ypserv daemon on the NIS server handles the request by consulting the appropriate map.
The ypserv daemon sends the requested information back to the client.