DOC HOME SITE MAP MAN PAGES GNU INFO SEARCH PRINT BOOK
 
Configuring the Network Information Service (NIS)

Planning an NIS configuration

When planning an NIS configuration, you must gauge your network administration needs with regard to domain structure, server disposition, security concerns, and the physical structure of the network. Your configuration will also be affected if the network is heterogeneous, that is, if it includes hosts running operating systems other than SCO OpenServer systems. The following sections explain these considerations in more detail.

Selecting domains

For most NIS installations, a single domain is sufficient to satisfy users' needs. However, if your site has multiple networks, you must create separate domains for each network because NIS domains cannot cross network boundaries. A possible network division might be into accounting, marketing, and manufacturing domains.

In such an environment, it is recommended that there be one master and at least one slave server for each domain.


NOTE: Multiple networks can share a single domain if there is a single shared machine with a network interface for each network.

Selecting servers

Two factors are important in selecting master and slave servers: uptime and synchronization. The master server should be a host that is stable and available for NIS requests. This suggests that a machine be dedicated as a master server and that there be at least one slave server for each master in a domain should the master become unavailable.

The master and slave servers should have CPUs of comparable power to those of the machines to which they will propagate maps. This is particularly important in heterogeneous environments where a number of NIS clients running on other operating systems may seek to bind with the most available server. Because it is essential that current map information be uniformly available across the network, availability and equivalent speed of servers ensure that the propagation of map information is synchronized.

In an NIS environment comprised of SCO OpenServer machines exclusively, slave servers can be used as a backup to the master server and to improve the ability to service map update requests from copy-only servers. In a heterogeneous environment, slave servers should be added as needed to keep up with requests from clients running on other operating systems.

The physical structure of the network may influence the distribution of slave servers. For example, if you have a network that includes a bridge, you will probably want at least two slave servers on either side. This is because NIS requests are delayed when crossing bridges. The result is that a server on the same side of a bridge as the requesting host will satisfy a request sooner than one on the far side, even if the closer server is heavily loaded. Having two slave servers on the requesting side of the bridge removes a virtual reliance on one server that may be heavily loaded.

Security

Although NIS is designed to administer password and group authorization files, such administration is incompatible with C2 security. SCO NIS maintains C2 security in an NIS environment by enforcing the following restrictions:


NOTE: SCO NIS clients cannot be C2 Secure because they integrate password and group maps.

In a heterogeneous environment, SCO OpenServer copy-only servers under C2 protection continue to refuse password and group maps from master or slave servers running on other operating systems. However, an SCO OpenServer master or slave server (by definition in Unsecure Mode) may be able to propagate maps to C2-protected clients on other operating systems. Consult your client's documentation to address your security concerns. Refer also to ``NIS interaction with security modes''.

See also:


Next topic: Setting up an NIS server
Previous topic: Enabling an NIS server

© 2003 Caldera International, Inc. All rights reserved.
SCO OpenServer Release 5.0.7 -- 11 February 2003