| Skip Navigation Links | |
| Exit Print View | |
|
man pages section 1M: System Administration Commands Oracle Solaris 11.1 Information Library |
| Skip Navigation Links | |
| Exit Print View | |
|
|
man pages section 1M: System Administration Commands Oracle Solaris 11.1 Information Library |
System Administration Commands - Part 1
System Administration Commands - Part 2
- NIS binder process
/usr/lib/netsvc/yp/ypbind [-broadcast | -ypset | -ypsetme]
NIS provides a simple network lookup service consisting of databases and processes. The databases are stored at the machine that runs an NIS server process. The programmatic interface to NIS is described in ypclnt(3NSL). Administrative tools are described in ypinit(1M), ypwhich(1), and ypset(1M). Tools to see the contents of NIS maps are described in ypcat(1), and ypmatch(1).
ypbind is a daemon process that is activated at system startup time from the svc:/network/nis/client:default service. By default, it is invoked as ypbind -broadcast. ypbind runs on all client machines that are set up to use NIS. The function of ypbind is to remember information that lets all NIS client processes on a node communicate with some NIS server process. ypbind must run on every machine which has NIS client processes. The NIS server may or may not be running on the same node, but must be running somewhere on the network.
The SMF service svc:/network/nis/client has the following properties in the config property group:
config.use_broadcast config.use_ypsetme
The information ypbind remembers is called a binding — the association of a domain name with a NIS server. The process of binding is driven by client requests. As a request for an unbound domain comes in, if started with the -broadcast option, the ypbind process broadcasts on the net trying to find an NIS server, that is, a ypserv process serving the domain with a name the same as (case sensitive) the name of the domain in the client request. Since the binding is established by broadcasting, there must be at least one NIS server on the net. If started without the -broadcast option, ypbind process steps through the list of NIS servers that was created by ypinit -c for the requested domain. There must be an NIS server process on at least one of the hosts in the NIS servers file. It is recommended that you list each of these NIS servers by name and numeric IP address in /etc/hosts. Though the practice is not recommended, NIS allows you to list servers by numeric address only, bypassing /etc/hosts. In such a configuration, ypwhich(1) returns a numeric address instead of a name.
Once a domain is bound by ypbind, that same binding is given to every client process on the node. The ypbind process on the local node or a remote node may be queried for the binding of a particular domain by using the ypwhich(1) command.
If ypbind is unable to speak to the NIS server process it is bound to, it marks the domain as unbound, tells the client process that the domain is unbound, and tries to bind the domain once again. Requests received for an unbound domain will wait until the requested domain is bound. In general, a bound domain is marked as unbound when the node running the NIS server crashes or gets overloaded. In such a case, ypbind will try to bind to another NIS server using the process described above.ypbind also accepts requests to set its binding for a particular domain. The request is usually generated by the ypset(1M) command. In order for ypset to work, ypbind must have been invoked with flags -ypset or -ypsetme.
NIS configuration and activation is managed in Location profiles (refer to netcfg(1M) for more information about location profiles). These profiles are either fixed, meaning the network configuration is being managed in the traditional way, or reactive, meaning the network configuration is being managed automatically, reacting to changes in the network environment according to policy rules specified in the profiles.
When a fixed location (there can currently be only one, the DefaultFixed location) is active, changes made to the SMF repository will be applied to the location when it is disabled, and thus will be restored if that location is later re-enabled.
When a reactive location is active, changes should not be applied directly to the SMF repository; these changes will not be preserved in the location profile, and will thus be lost if the location is disabled, or if the system's network configuration, as managed by svc:/network/physical:default and svc:/network/location:default, is refreshed or restarted. Changes should instead be applied to the location itself, using the netcfg(1M) command; this will save the change to the location profile repository, and will also apply it to the SMF repository (if the change is made to the currently active location).
The presence or absence of nis in the nameservices property of a location profile will determine whether or not svc:/network/nis/client:default is enabled. The nis-nameservice-servers property may be empty, indicating that -broadcast should be enabled, or it may contain the list of servers to which the client may bind.
Send a broadcast datagram using UDP/IP that requests the information needed to bind to a specific NIS server. This option is analogous to ypbind with no options in earlier Sun releases and is recommended for ease of use.
Enabling the SMF property config.use_broadcast enables -broadcast.
Allow users from any remote machine to change the binding by means of the ypset command. By default, no one can change the binding. This option is insecure.
Only allow root on the local machine to change the binding to a desired server by means of the ypset command. ypbind can verify the caller is indeed a root user by accepting such requests only on the loopback transport. By default, no external process can change the binding.
Enabling the SMF property config.use_ypsetme enables -ypsetme.
Lists the servers to which the NIS client is allowed to bind.
File in which it is recommended that NIS servers be listed.
See attributes(5) for descriptions of the following attributes:
|
svcs(1), ypcat(1), ypmatch(1), ypwhich(1), ifconfig(1M), netcfg(1M), svcadm(1M), ypinit(1M), ypset(1M), ypclnt(3NSL), hosts(4), ypfiles(4), attributes(5), smf(5)
ypbind supports multiple domains. The ypbind process can maintain bindings to several domains and their servers, the default domain is the one specified by the domainname(1M) command at startup time.
The -broadcast option works only on the UDP transport. It is insecure since it trusts “any” machine on the net that responds to the broadcast request and poses itself as an NIS server.
The ypbind service is managed by the service management facility, smf(5), under the service identifier:
svc:/network/nis/client:default
Administrative actions on this service, such as enabling, disabling, or requesting restart, can be performed using svcadm(1M). The service's status can be queried using the svcs(1) command.
|