Certification Objective 11.01Understanding Naming Services


Certification Objective 11.01—Understanding Naming Services

Exam Objective 5.1: Explain naming services (DNS, NIS, NIS+, and LDAP) and the naming service switch file (database sources, status codes, and actions).

As you learned in the previous chapters, we build computer networks to share resources. To do that the computers need some network information, necessary to communicate over the network and to share the resources. In principle, each machine can maintain its own information and the information about other machines and resources on the network locally. Still, this can be a cumbersome task and can lead to errors. Suppose you just installed a printer on the network; you then need to enter information about it individually on all the machines on the network. If information about one machine changes, you must update this information on all the machines individually. So it's not only a cumbersome task—the consistency is also at risk. This is where naming services come into the picture by offering centralized management of network information such as machine addresses, user names, passwords, access permissions, printer names, and so forth. Furthermore, naming services simplify machine addressing, by allowing you to refer to the machines with names that are easy to remember rather than numerical addresses such as IP address. The Solaris system supports a number of naming services.

Naming Services Supported by Solaris

In the beginning, there were files in the /etc directory that were used as a naming system for a standalone UNIX machine. This file-based naming service was also adapted for the network environment, where a machine needs to keep information not only about itself but about other machines and services on the network. Therefore, this local file-based service is not well suited for large, sophisticated networks, and only some old UNIX OSs and machines still use this as a primary choice. More suitable naming services supported by Solaris to use in today's network environment are DNS, NIS, NIS+, and LDAP.

Domain Name Service

The Domain Name Systems (DNS) naming service manages the machine names on the Internet. In Chapter 10, we talked about the data being transferred over the Internet by IP addresses. But when was the last time you had to use an IP address (such as 132.25.3.4) to send an email to your friend or to browse the web? Under normal circumstances end users always use names that are easy to remember (e.g., macgrawhill.com or cs.cornell.edu). These names are called domain names and are translated to corresponding IP addresses before the outgoing data leaves your computer. The process of translation is called domain name resolution, and the mechanism to maintain the domain names and to resolve them is called Domain Name System (DNS). The machines that participate in the resolution are called DNS servers. The collection of domain names, or the corresponding machines that use DNS, is called a DNS namespace.

As Figure 11-1 shows, DNS is a hierarchical namespace conceptually represented by an inverted tree with an unnamed root. Each node in the tree is called a domain, and you write the domain name for a domain by starting with its subname and making your way up to the tree root, separating one subname from the other with a dot. For example, the domain name for cs in Figure 11-1 is:

    cs.sjsu.edu 

image from book
Figure 11-1: Conceptual view of DNS naming hierarchy representing a very small part of the Internet

In practice, cs.sjsu.edu is the domain name for the computer science department at San Jose State University. For conceptual understanding you can assume that each domain name is maintained (hosted) by a separate DNS server, but in practice the situation may be more complex. For example, a server can host more than one domain name, and a domain name may be supported by more than one server—a primary and a secondary server.

The lines in the figure represent communication that is done over the Internet. For example, suppose a student at a machine (one that uses the DNS server hosting unex.berkeley.edu to resolve names) sends an email message to his friend at myFriend@cs.sjsu.edu. The name resolution query will travel along the DNS servers corresponding to the following domains:

 -> unex.berkeley.edu -> berkeley.edu -> .edu -> sjsu.edu -> cs.sjsu.edu 

Finally when it reaches the cs.sjsu.edu (DNS) server, that server will resolve the name, and the response will travel back to the unex.berkeley.edu address and to the machine that sent the original query. However, the name may also be resolved by any server on its path from its cache. Further note that we have assumed one-to-one correspondence between a domain name and the DNS server just to clarify the concept, but it may not represent reality, which may be more complex, as stated previously.

DNS is a client/server system. A DNS server runs the daemon in.named. On the client side, DNS is implemented through what is called a resolver, whose function is to resolve naming queries by sending requests to the DNS server. The server can return either the requested information or the name of another DNS server that can be queried by the resolver.

DNS makes Internet communication simpler by letting you use domain names instead of IP addresses, and it manages the DNS namespace at Internet level. However, as you have seen, there are some names, such as local machine names and user names, that must be managed at a network level. In other words, the configuration information spread out in several files in the /etc directory on several machines in a network needs to be managed in a more efficient, consistent, and robust fashion. This is where Network Information Service (NIS) comes into the picture.

Network Information Service

The Network Information Service (NIS) manages, as the name suggests, the information specific to a network, such as information about machine names, user names, network services, and so forth. The focus of NIS is to make network administration easier by providing central management for distributed information. This is accomplished by providing a client/server environment. The principal terms in NIS are explained here:

  • NIS namespace. The collection of network information managed by NIS.

  • NIS domain. A set of NIS maps with some rules—for example, that a domain can contain one and only one master server. You can look at it as a well-defined subset of NIS namespace.

  • NIS maps. The databases used to store the NIS namespace information. These maps were designed to replace the /etc files and other configuration files.

  • Master server. The machines where you, the system administrator, originally create the NIS maps and then make any needed updates to them. The master server is also referred to as the primary server.

  • Slave servers. These are the replications (or backups) of the master servers to provide fault tolerance and load balancing. Any NIS updates to a master server propagate to the corresponding slave servers. The slave servers are also referred to as secondary servers.

  • NIS clients. Any host on the network that makes a request to an NIS server for NIS information is called an NIS client. The processes running on NIS clients make requests to the NIS servers for data from the maps. Note that a client does not make a distinction between a master server and a slave server. This applies to load balancing. Unlike DNS, the NIS namespace is flat, not hierarchical. Another naming service offered by Solaris is NIS+, which does offer a hierarchical namespace like DNS.

Network Information Service Plus

Network Information Service Plus (NIS+) is used to manage network information about machine addresses, mail, network interfaces, network service, and security. It is similar to NIS as to what and how it manages, such as central management for distributed information. However, it is not an extension to NIS. Unlike NIS, it is hierarchical and more dynamic (it can conform to the requirements of an organization), and it offers additional features such as security.

The fact that NIS namespace is hierarchical makes NIS more dynamic, because you can configure it to conform to the logical hierarchy of your organization. You can divide the namespace into multiple domains (corresponding to the organizational structure), which can be administered autonomously. Furthermore, you can control access to these domains in the hierarchy tree. NIS+ has primary servers and secondary servers just like NIS.

NIS and NIS+ store information in proprietary formats. To make the storage and retrieval of information system independent, the dc facto Internet standard is called LDAP.

LDAP Service

The Light Weight Directory Access Protocol (LDAP) is an Internet protocol on which the LDAP service is based. The naming service NIS was originally called yellow pages. The idea behind the directory is the same as in the telephone directory, meaning that you can easily and quickly retrieve simple information such as a name, email address, phone number, and so forth. LDAP is a lighter version of the original directory protocol called X.500, which is a very complex protocol; its closest implementation is the original Novell Directory Service (NDS) which offers more features than LDAP and was made LDAP compatible because of the popularity of LDAP. A directory service is designed to be read intensive rather than write intensive, because fewer updates are expected to be made. You can store in LDAP all the information that you store in NIS or NIS+. Its namespace is hierarchical, and it does offer security.

You can use LDAP along with NIS or NIS+, because it allows data to be shared by different naming services. However, because of its wide acceptance, it will eventually replace NIS and NIS+.

On the Job 

Unlike an NIS server, an LDAP server cannot be its own client. In other words, a machine that is running as an LDAP server cannot be configured as an LDAP client.

The naming services are summarized in Table 11-1, and you will learn more about them in the remainder of this chapter.

Table 11-1: Comparison of various naming services

Characteristic

DNS

NIS

NIS+

LDAP

Namespace structure

Hierarchical

Flat

Hierarchical

Hierarchical

Data storage

Files resource records

Two-column maps

Multicolumn tables

Directories

Server kinds

Master/slave

Master/slave

Root master/non-root master Primary/secondary cache/stub

Master/replica

Transport

TCP or UDP

RPC

RPC

TCP/IP

Scale

Global

LAN

LAN

Global

Security

Solaris 10 uses BIND 9.2, which offers some security features such as authenticated zone updates.

None (root or nothing)

Secure RPC

SSL

In selecting a naming service for your network, you have a number of options to choose from. You can even use more than one naming service for different types of information. The question is How does the naming service client (or an application that needs naming information) on your machine know which naming service is available to retrieve a specific piece of information? It looks into the naming service switch file, also known as name service switch, or simply switch.

Coordinating the Use of Naming Services

Because Solaris supports more than one naming service, you can use one or more than one naming service. You may find one naming service to be appropriate for one kind of information and another to be more appropriate for another kind of information. To enable the client to get specific network information from the correct naming service, you, the system administrator, maintain the name service switch file, which has the following name:

    /etc/nsswitch.conf 

Each entry (line) of this file lists a specific type of available information, such as host, password, or group, and identifies the source from which this information can be obtained. By looking into this file, a client can retrieve different pieces of the needed information from one or more sources (identified by one or more entries in the file)—for example, host name from the NIS table and password from a local file in the /etc directory, and so forth.

Creation of the nsswitch.conf File

Where docs this nsswitch.conf file come from? It appears on your system during installation, as explained here:

  1. During Solaris installation, the following four versions of the switch file (also called templates) corresponding to different naming services are loaded into the /etc directory:

    • nsswitch.ldap

    • nsswitch.nis

    • nsswitch.nisplus

    • nsswitch.files

  2. The installer—that is, you—selects the machine's default naming service.

  3. The template corresponding to your selection is copied to nsswitch.conf. For example, if you selected LDAP, the nsswitch.ldap file will be copied to nsswitch.conf.

  4. You can edit and update the nsswitch.conf file, if needed.

The templates contain the default switch configuration for the LDAP, NIS, NIS+, and local files. The default template file copied to the nsswitch.conf file should be sufficient for normal operation in a typical environment. No template is provided for the DNS, but you can always edit the nsswitch.conf file and add the DNS information if you want to.

So, what is in the nsswitch.conf file?

Content of the Switch File

An entry in the nsswitch.conf file can have the following fields:

  • The network information type.

  • One or more sources from which the information can be obtained

Sixteen types of information are supported: aliases, bootparam, ethers, groups, hosts, ipnodes, netgroups, netmasks, networks, passwords, protocols, publickey, rpc, services, automount, and sendmailvars. The supported sources, also called information sources or database sources, are listed in Table 11-2.

Table 11-2: Database sources supported by the switch file

Database Source

Description

compat

Used for password and group information to support old-style + or - syntax in /etc/group, /etc/passwd, /etc/shadow files.

dns

Used to specify that the. host information can be obtained from DNS.

files

Used to specify that the information can be obtained from files in the client's /etc directory, such as /etc/passwd.

ldap

Used to specify that the information can be obtained from the LDAP directory.

nis

Used to specify that the information can be obtained from an NIS map, such as a hosts map.

nisplus

Used to specify that the information can be obtained from an NIS+ table such as a hosts table.

On the Job 

An entry in the switch file may have more than one source; if it does, the information will be searched from sources in the order they are listed. Once the information is obtained, the search will be terminated—that is, the remaining sources will not be searched. This is the default that you can change by specifying the action options in the switch file.

When the information is searched in a source, the search may return any of the following status codes:

  • SUCCESS. The requested information was found in the specified source.

  • NOTFOUND. The requested information was not found in the specified source.

  • UNAVAIL. The source either did not respond or was unavailable.

  • TRYAGAIN. The information was not returned because the source was busy.

You can instruct the switch how to respond to any of these status codes (messages) by using what are called switch action options, which are listed here:

  • continue. Try the next listed source. This is the default for NOTFOUND, UNAVAIL, and TRYAGAIN.

  • return. Stop looking for the information. This is the default for SUCCESS.

You can change a default action value by specifying the action in an entry of the switch file. For example, consider the following entry in the switch file:

    netmasks nis [NOTFOUND=return] files 

If a client looking for netmasks information does not find it in NIS, it will not look in the files in the /etc directory. If the [NOTFOUND=return] was not in this entry, the client would look into files after failing to find netmask information in NIS.

As an example, the default switch file for NIS—that is, the template /etc/nsswitch.nis, looks like this:

    passwd: files nis    group: files nis    # consult /etc "files" only if nis is down.    hosts: nis [NOTFOUND=return] files    networks: nis [NOTFOUND=return] files    protocols: nis [NOTFOUND=return] files    rpc: nis [NOTFOUND=return] files    ethers: nis [NOTFOUND=return] files    netmasks: nis [NOTFOUND=return] files    bootparams: nis [NOTFOUND=return] files    publickey: nis [NOTFOUND=return] files    netgroup: nis    automount: files nis    aliases: files nis    # for efficient getservbyname() avoid nis    services: files nis    sendmailvars: files 

In summary, some of the functionalities of the naming services offer are listed here:

  • Manage network information at a central place.

  • Assign (bind) names to addresses of network entities, such as a computer.

  • Resolve names to addresses.

  • Delete bindings.

  • Change the bindings.

Because from the user's perspective the Internet is also just a big network, in today's networks you need naming information related to your local network and the Internet. The information about your local network, such as machine names and users, can be managed by using NIS.




Sun Certified System Administrator for Solaris 10 Study Guide Exams 310-XXX & 310-XXX
Sun Certified System Administrator for Solaris 10 Study Guide Exams 310-XXX & 310-XXX
ISBN: N/A
EAN: N/A
Year: 2005
Pages: 168

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net