Basic NIS Concepts

NIS+ is a Solaris network information service whose primary focus is the management of users, hosts , networks, services, and protocols. NIS+ does not replace DNS, however. DNS is still required for host addressing and identification. However, NIS+ namespaces can be constructed to parallel the host designations assigned through DNS, to simplify operations, and to make the integration of both services more seamless. NIS+ gives networks more than just DNS: namespaces are used as centralized repositories of shared network information that can be used to more effectively manage large networks. However, many organizations choose not to use NIS+ because it has some overlap with DNS, and because of the extra administrative burden involved in installing and configuring NIS+ primary and slave servers. However, if you use the NIS+ scripts to install and configure namespaces, instead of using NIS+ commands direct, NIS+ can be much easier to configure.

NIS revolves around the idea of maps: a map is generally a database with two columns , of which one is a primary key that is used to retrieve an associated value. This associative nature makes the storage and retrieval of group , mail, passwords, and Ethernet information fast for small networks, but can rapidly become difficult to manage (not to mention slow) for large networks. NIS+, in contrast, uses tables, of which 16 are defined by the system. Tables store information like server addresses, time zones, and networks services. In this section, we review the most commonly used types of NIS maps and NIS+ tables.

First, however, we present a conceptual overview of how NIS+ could be used to better manage an organization s network data. Let s imagine that we re setting up a Solaris network for an imaginary college called Panther College, which has a DNS domain of panther.edu . Panther has two teaching divisions: an undergraduate school ( undergrad.panther.edu ) and a graduate school ( graduate.panther.edu ). panther.edu has a Class C network (192.12.1.0), as do each of the undergraduate (192.12.2.0) and graduate schools (192.12.3.0). Each of these networks can have up to 254 hosts each, which more than adequately covers the staff members in both teaching divisions. To support DNS, there may be a campus-wide DNS server ns.panther.edu at 192.12.10, while the undergrad.panther.edu network has its own DNS server at ns.undergrad.panther.edu (192.12.2.0), and ns.graduate.panther.edu (192.12.3.0). This is a fairly standard setup for a medium- sized network like a college campus, and is demonstrated in Figure 27-1.

Figure 27-1: DNS configuration for a fictional college with two divisions: graduate and undergraduate, both of which have their own name server.

The NIS+ domains for Panther College can exactly mirror the DNS configuration, as shown in Figure 27-2. However, some differences in naming are immediately apparent: while DNS uses lowercase names by convention, which do not terminate in a period, the NIS+ convention is to name write elements in a domain beginning with capital letters , and terminating with a period.

Figure 27-2: NIS+ domains for Panther College.

In addition, the second-level domain identified in DNS as panther.edu would be the root domain in a NIS+ network, and the third-level domains undergrad.panther.edu and graduate.panther.edu would be described as nonroot domains. Each of these domains would be associated with a server, in which case the existing DNS servers would double up as NIS+ servers. In fact, in normal NIS+ usage, each of the three domains at Panther College would require two servers: a master server and at least one replica or slave server. This ensures that if the master server is disrupted or experiences hardware failure, the replica server holds copies of network service information. The expanded NIS+ domains for Panther College, with a master and slave server each (called Master and Replica), are shown in Figure 27-3.

Figure 27-3: NIS+ domains with a master and a slave server each.

In addition to domains and servers, NIS+ also caters to clients . Each client is associated with a specific server and domain. For example, a client in the chemistry lab in the graduate school ( Curie.Graduate.Panther.Edu .) would be served by Master.Graduate.Panther.Edu. , and would be part of the Graduate.Panther.Edu. domain. Alternatively, a history professor in the undergraduate school with a computer named FDR.Undergrad.Panther.Edu would be served by Master.Undergrad.Panther.Edu. , and would be part of the Undergrad.Panther.Edu. domain. Figure 27-4 shows the hierarchy of control for the FDR.Undergrad.Panther.Edu. client. When each client is installed, a directory cache is created, which enables the client to locate other hosts and services via the appropriate server.

Figure 27-4: Hierarchy of control for a specific domain client (FDR.Undergrad.Panther.Edu.).

So far, we have mentioned only one of the many kinds of namespace components: the domain. However, there are many other components that exist in the namespace, including group objects, directory objects, and table objects. We will examine these important features of the namespace in the following sections. In addition, we ll review the specific configuration of NIS maps and NIS+ tables.

It is worth mentioning at this point that one of the main reasons that organizations choose to implement NIS+ is the improved security that accompanies the system. For example, NIS+ tables are not directly editable, unlike their normal Solaris counterparts in the /etc directory. Requests to change or even access information in the namespace can only take place once a user has been authenticated. In addition to authentication, each user must be authorized to access a particular resource. This doubly protects sensitive and organizational data in a networked environment. The main authentication exchange takes place when either a user presents their credentials or a host presents its credentials, in an unencrypted LOCAL form or a more secure DES-encrypted exchange. The former is used for testing, while the latter is always used for deployment. After authentication, authorization for the requested resource is checked.

Tip  

Access rights can always be examined by using the niscat command, which is discussed later in this chapter in the section "niscat".

NIS Maps

As we mentioned previously, NIS used a series of maps to encode data about the network structure. Many of these are in a form that can be accessed through an address key (having a byaddr suffix), or through a name (with a byname suffix). Whenever a client needs to find information about a particular host, service, group, network, or netgroup , it can be retrieved by consulting the appropriate map as defined in the namespace. The main system maps are

• bootparams Contains a list of diskless clients for a domain.

• ethers.byaddr Contains a list of the Ethernet addresses of all hosts in the domain, and their hostnames.

• ethers.byname Contains a list of the hostnames of all hosts in the domain, and their Ethernet addresses.

• group.bygid Contains a list of groups that are indexed by group ID (gid).

• group.byname Contains a list of groups that are indexed by group name.

• hosts.byaddr Contains a list of the addresses of all hosts in the domain, and their hostnames.

• hosts.byname Contains a list of the hostnames of all hosts in the domain, and their addresses.

• mail.aliases Contains a list of mail aliases within the namespace, indexed by name.

• mail.byaddr Contains a list of mail aliases within the namespace, indexed by address.

• netgroup Contains netgroup information, indexed by group name.

• netgroup.byhost Contains netgroup information, indexed by hostname.

• netgroup.byuser Contains netgroup information, indexed by username.

• netid.byname Contains the netname of hosts and users.

• netmasks .byaddr Defines the netmasks defined in the domain namespace.

• networks.byaddr Defines the networks in the domain namespace, sorted by address.

• networks:byname Defines the networks in the domain namespace, sorted by name.

• passwd.byname Defines the password database, sorted by username.

• passwd.byuid Defines the password database, sorted by user ID.

• protocols.byname Defines the network protocols used in the domain, sorted by name.

• protocols.bynumber Defines the network protocols used in the domain, sorted by number.

• publickey .byname Contains public keys for RPC.

• rpc.bynumber Contains RPC details indexed by number.

• services.byname Defines all available Internet services by name.

• ypservers Contains a list of all NIS servers available.

As we can see, there are many similarities in name and function between the NIS maps and the /etc system files they are intended to replace. However, both the /etc files and NIS maps perform poorly under heavy loads when the number of hosts defined in a specific namespace exceeds the hundreds. In this case, it is much more appropriate to bypass NIS and /etc , and move directly to an NIS+ installation where a single table (such as Ethers) replaces the dual lookup system used by NIS (such as ethers.byname and ethers.byaddr).

NIS+ Tables

Namespace information in NIS+ is stored in tables that are based around a centralized administration model, even though particular functions can be delegated to specific servers. NIS+ is similar to DNS because it arranges hosts and resources hierarchically into domains, it has built-in redundancy with master and slave servers, and it can store much more information about a network than just its hosts. However, since each host in a domain has many different characteristics and user details that must be recorded and stored centrally , updating these details can be time-consuming . In addition, issues like contention in the recording of user and host data often arise. However, NIS+ namespaces can be updated incrementally as changes occur, so that the entire database does not need to be updated immediately. Changes are entered into a master domain server and are then propagated through time to the rest of the domain. This process is governed by a time-to-live setting similar to that used for DNS. Commonly used tables include:

• Hosts The Hosts table lists all of the hosts in a particular domain, matching their IP address with a hostname and an optional nickname. For example, if the host maria had an alias called bruny and had the IP address 192.34.54.3, the entry in the Hosts table would look like this: 192.34.54.3 maria bruny

• Bootparams The Bootparams tables contains the necessary information to boot and configure any diskless clients in the domain, or provide JumpStart services. In addition to installation information, it can also contain entries for server-based dump and swap, as well as a root directory, for each client. For example, if there is a diskless client called pembroke and it is configured by the server downing, the Bootparams table would contain the following entry: pembroke root=downing:/export/root/pembroke \ swap=downing:/export/swap/pembroke \ dump=downing:/export/dump/Pembroke Thus, each diskless client will have its own Bootparams entry and resources available on the server.

• Passwd The passwd table stores all the standard user information expected on Solaris hosts, including username, encrypted password, user ID, group ID, user s real name, their home directory, and their login shell. A typical entry may look like this: pwatters:8dfjh4h.rj:101:10:Paul A. Watters:/home/pwatters:/bin/tcsh:10905:-1:-1:-1:-1::0 In addition to the standard details, there is extra information that specifies how often a password must be changed, or how many days until it must next be changed. This significantly increases the functionality of NIS+ over standard Solaris password authorization.

• Group The Group table consists of a group name, group password, group ID number, and member list, and stores information about the three kinds of groups accessible by NIS+ clients: Solaris groups (such as staff ), NIS+ groups, and netgroups .

• Netgroups The Netgroup table defines a group of hosts and users that are authorized to perform specific operations on one or more other hosts within a group. The table format contains entries that identify the name of the group as well as its members. For small organizations, everyone belongs to a single group, perhaps called everyone: everyone paulwatters.com

• Mail Aliases The Mail Aliases table replicates the functionality of the old /etc/aliases file for the local mail transport agent (MTA), which is typically sendmail. An aliases table can store an alias for a specific user, or it can be used to construct a mailing list. For example, if the user bounty wanted to receive mail as endeavour, the Mail Aliases entry would look like this: endeavour:bounty However, if an advertising company had a local mailing list for newclients, these messages could be distributed nationally to local offices by using an alias like this: newclients: layton ,miami,oakton,sanfran

• Timezone Defines the local time zone, which will affect all system settings and applications, such as sendmail. For example, the entry, hartog Australia/NSW allows the host hartog to be identified as belonging to the New South Wales time zone in Australia. In addition, time zones can be specified on a host-by-host basis. This allows systems that exist in different time zones to belong to the same domain. For example, a SPARC 20 system in Sydney can belong to the same domain as an Ultra 5 in San Francisco. The Timezone table consists of entries that relate a time zone to a specific host.

• Networks Contains details of the local networks and their IP addresses. For example, if a Class B network 192.12.0.0 was known on the Internet as brunswick but had an alias essendon, it would be entered into the Networks table as brunswick 192.12.0.0 essendon

• Netmasks The Netmasks table specifies the netmasks for all local Class A, Class B, and Class C networks. For example, if the network 192.12.34.0 has a netmask of 255.255.255.0, the entry would look like this: 192.12.34.0 255.255.255.0

• Ethers The ethers table contains entries that associate a hostname with a specific hardware address. For example, if the host freycinet has an Ethernet address of 00:ff:a1:b3:c4:6c, the ethers table entry would look like this: 00:ff:a1:b3:c4:6c freycinet

• Services Contains a list of the IP services that are available, through both TCP and UDP. For example, the HTTP service provided by many web servers, such as Apache, is usually available through TCP port 80. This would be defined in the services table as http 80/tcp

• Protocols Defines the protocols available to the network. A necessary entry for Internet use would be the internet protocol (IP), ip IP which identifies ip as protocol number zero, which also has the alias IP.

• RPC Defines the RPC programs available to the network. An entry consists of a name, a program number, and an alias. For example, rpcbind is also known as portmap, sunrpc, and the portmapper . The entry for rpcbind looks like this: rpcbind 100000 portmap sunrpc portmapper

• Auto_Home This table is an automounter map that facilitates the mounting of a home directory for any user in the local domain. It is typically used to share a common home directory for a user who has accounts on multiple machines. It is also the cause of some consternation among administrators who attempt to create their user s home directories under /home , but who don t use the automounter! The Auto_Home table has two columns: a common username that is consistent across all machines in a domain, and a physical location for the user s shared home directory. For example, the home directory of user pwatters might be located physically on the server winston, in the directory /u1/export/pwatters . In this case, the entry in Auto_Home would be pwatters winston:/u1/export/pwatters

• Auto_Master The auto_master maps the physical mount points of all of the NFS automounter maps in a particular domain to a name. For example, it can be used to map user home directories to /home or /staff using auto_home, with either of the following mount points, respectively: /home auto_home/staff auto_home