Part I Introduction to Solaris Naming

This part provides an introduction and overview of namespaces and Solaris naming services, and using the nsswitch.conf file to coordinate naming service usage.

• Chapter 1, "Introduction to Name Services"

• Chapter 2, "The Name Service Switch"

Chapter 1 Introduction to Name Services

This chapter provides an overview describing what namespaces and naming services are and what they do. (Other names for name services are network information services and directory services.) This chapter then briefly describes the four Solaris naming services: DNS, NIS, FNS, and NIS+.

• "What Is a Name Service?"

• "Solaris Name Services"

• "DNS"

• "NIS"

• "NIS+"

• "FNS"

Directions for setting up NIS+, NIS, DNS, and FNS namespaces are contained in Solaris Naming Setup and Configuration Guide. See Glossary for definitions of terms and acronyms you don't recognize.

What Is a Name Service?

Name services store information in a central place that users, workstations, and applications must have to communicate across the network such as:

• Machine (host) names and addresses

• User names

• Passwords

• Access permissions

Without a central name service, each workstation would have to maintain its own copy of this information. Name service information may be stored in files, maps, or database tables. Centrally locating this data makes it easier to administer large networks.

Name services are fundamental to any computing network. Among other features, a name service provides functionality that:

• Associates (binds) names with objects

• Resolves names to objects

• Removes bindings

• Lists names

• Renames

A network information service enables workstations to be identified by common names instead of numerical addresses. This makes communication simpler because users don't have to remember and try to enter cumbersome numerical addresses like "129.44.3.1."

For example, take a simple network of three workstations named, pine, elm, and oak. Before pine can send a message to either elm or oak, it must know their numerical network addresses. For this reason, it keeps a file, /etc/hosts or /etc/inet/ipnodes, that stores the network address of every workstation in the network, including itself.

Likewise, in order for elm and oak to communicate with pine or with each other, they must keep similar files.

Addresses are not the only network information that workstations need to store. They also need to store security information, mail data, information about their Ethernet interfaces, network services, groups of users allowed to use the network, services offered on the network, and so on. As networks offer more services, the list grows. As a result, each workstation may need to keep an entire set of files similar to /etc/hosts or /etc/inet/ipnodes.

As this information changes, administrators must keep it current on every workstation in the network. In a small network this is simply tedious, but on a medium or large network, the job becomes not only time-consuming but nearly unmanageable.

A network information service solves this problem. It stores network information on servers and provides it to any workstation that asks for it:

The workstations are known as clients of the server. Whenever information about the network changes, instead of updating each client's local file, an administrator updates only the information stored by the network information service. This reduces errors, inconsistencies between clients, and the sheer size of the task.

This arrangement, of a server providing centralized services to clients across a network, is known as client-server computing.

Although the chief purpose of a network information service is to centralize information, another is to simplify network names. For example, assume your company has set up a network and connected it to the Internet. The Internet has assigned your network the network number of 129.44.0.0 and the domain name doc.com. Your company has two divisions, Sales and Manufacturing (Manf), so its network is divided into a main net and two subnets, one for each division. Each net has its own address:

Each division could be identified by its network address, as shown above, but descriptive names made possible by name services would be preferable:

So, instead of addressing mail or other network communications to 129.44.1.0, they could be addressed simply to doc. Instead of addressing them to 129.44.2.0 or 129.44.3.0, they could be addressed to sales.doc or manf.doc.

Names are also more flexible than physical addresses. While physical networks tend to remain stable, the organizations that use them tend to change. A network information service can act as a buffer between an organization and its physical network. This is because a network information service is mapped to the physical network, not hard-wired to it.

For example, assume that the doc.com network is supported by three servers, S1, S2, and S3, and that two of those servers, S1 and S3, support clients:

Clients C1, C2, and C3 would obtain their network information from server S1. Clients C4, C5, and C6 would obtain it from server S3. The resulting network is summarized in Table 1-1. (The table is a generalized representation of that network but does not resemble an actual network information map.)

Now assume that you create a third division, Testing, which borrowed some resources from the other two divisions, but did not create a third subnet. The physical network would then no longer parallel the corporate structure:

Traffic for the Test Division would not have its own subnet, but would instead be split between 129.44.2.0 and 129.44.3.0. However, with a network information service, the Test Division traffic could have its own dedicated network:

Thus, when an organization changes, its network information service can simply change its mapping:

Now clients C1 and C2 would obtain their information from server S2; C3 and C4 from server S4; and C5 and C6 from server S3.

Subsequent changes in your organization would continue to be accommodated by changes to the "soft" network information structure without reorganizing the "hard" network structure.

Solaris Name Services

The Solaris operating environment provides the following name services:

• DNS, the Domain Name System (see "DNS").

• /etc files, the original UNIX naming system (see "/etc Files").

• NIS, the Network Information Service (see "NIS").

• NIS+, the Network Information Service Plus (see "NIS+").

• FNS, the Federated Naming Service, supports the use of different autonomous naming systems in a single Solaris environment (see "FNS").

Most modern networks use two or more of these services in combination. When more than one service is used, they are coordinated by the nsswitch.conf file which is discussed in Chapter 2, The Name Service Switch.

DNS

DNS, the Domain Name System, is the name service provided by the Internet for TCP/IP networks. It was developed so that workstations on the network could be identified with common names instead of Internet addresses. DNS performs naming between hosts within your local administrative domain and across domain boundaries.

The collection of networked workstations that use DNS are referred to as the DNS namespace. The DNS namespace can be divided into a hierarchy of domains. A DNS domain is simply a group of workstations. Each domain is supported by two or more name servers: a principal server and one or more secondary servers. Each server implements DNS by running a daemon called in.named. On the client's side, DNS is implemented through the "resolver." The resolver's function is to resolve users' queries; to do that, it queries a name server, which then returns either the requested information or a referral to another server.

/etc Files

The original host-based UNIX naming system was developed for stand-alone UNIX machines and then adapted for network use. Many old UNIX operating systems and machines still use this system, but it is not well suited for large complex networks.

NIS

The Network Information Service (NIS) was developed independently of DNS and has a slightly different focus. Whereas DNS focuses on making communication simpler by using workstation names instead of numerical IP addresses, NIS focuses on making network administration more manageable by providing centralized control over a variety of network information. NIS stores information about workstation names and addresses, users, the network itself, and network services. This collection of network information is referred to as the NIS namespace.

NIS namespace information is stored in NIS maps. NIS maps were designed to replace UNIX /etc files, as well as other configuration files, so they store much more than names and addresses. As a result, the NIS namespace has a large set of maps (see "NIS Maps").

NIS uses a client-server arrangement similar to DNS. Replicated NIS servers provide services to NIS clients. The principal servers are called master servers, and for reliability, they have backup, or slave servers. Both master and slave servers use the NIS information retrieval software and both store NIS maps. For more information on NIS Architecture, see "NIS Architecture".

See Part IVAdministering NIS for more information about NIS and how to administer it.

NIS+

The Network Information Service Plus (NIS+) is similar to NIS but with many more features. NIS+ is not an extension of NIS. It is a new software program.

The NIS+ name service is designed to conform to the shape of the organization that installs it, wrapping itself around the bulges and corners of almost any network configuration. Unlike NIS, the NIS+ name space is dynamic because updates can occur and be put into effect at any time by any authorized user.

NIS+ enables you to store information about workstation addresses, security information, mail information, Ethernet interfaces, and network services in central locations where all workstations on a network can have access to it. This configuration of network information is referred to as the NIS+ namespace.

The NIS+ namespace is hierarchical, and is similar in structure to the UNIX directory file system. The hierarchical structure allows an NIS+ namespace to be configured to conform to the logical hierarchy of an organization. The namespace's layout of information is unrelated to its physical arrangement. Thus, an NIS+ namespace can be divided into multiple domains that can be administered autonomously. Clients may have access to information in other domains in addition to their own if they have the appropriate permissions.

NIS+ uses a client-server model to store and have access to the information contained in an NIS+ namespace. Each domain is supported by a set of servers. The principal server is called the master server and the backup servers are called replicas. The network information is stored in 16 standard NIS+ tables in an internal NIS+ database. Both master and replica servers run NIS+ server software and both maintain copies of NIS+ tables. Changes made to the NIS+ data on the master server are incrementally propagated automatically to the replicas.

NIS+ includes a sophisticated security system to protect the structure of the namespace and its information. It uses authentication and authorization to verify whether a client's request for information should be fulfilled. Authentication determines whether the information requester is a valid user on the network. Authorization determines whether a particular user is allowed to have or modify the information requested. See Chapter 6, Security Overview for a more detailed description of NIS+ security, and Chapter 8, Administering NIS+ Keys for information on administering NIS+ security.

FNS

FNS, the Federated Naming Service, supports the use of different autonomous naming systems in a single Solaris environment. FNS allows you to use a single, simple naming system interface for all of the different name services on your network. FNS conforms to the X/Open federated naming (XFN) specification.

FNS is not a replacement for NIS+, NIS, DNS, or /etc files. Rather, FNS is implemented on top of these services and allows you to use a set of common names with desktop applications.

See Part VAdministering FNS for more information about FNS and how to administer it.

Chapter 2 The Name Service Switch

This chapter describes the name service switch, what it does, and how clients use it to obtain naming information from one or more sources. You use the name service switch to coordinate usage of different naming services.

• "About the Name Service Switch"

• "The nsswitch.conf Template Files"

• "DNS and Internet Access"

• "Adding Compatibility With +/- Syntax"

• "The Switch File and Password Information"

• "FNS and the Name Service Switch"

About the Name Service Switch

The name service switch is a file named nsswitch.conf. It controls how a client workstation or application obtains network information. It is used by client applications that call any of the getXbyY() interfaces such as:

• gethostbyname()

• getpwuid()

• getpwnam()

• getipnodebyname()

The name service switch is often referred to as simply the switch or the switch file. Each workstation has a switch file in its /etc directory. Each line of that file identifies a particular type of network information, such as host, password, and group, followed by one or more sources where the client is to look for that information.

A client can obtain naming information from one or more of the switch's sources. For example, an NIS+ client could obtain its hosts information from an NIS+ table and its password information from a local /etc file. In addition, it could specify the conditions under which the switch must use each source (see"Search Criteria").

The Solaris operating environment software automatically loads an nsswitch.conf file into every workstation's /etc directory as part of the installation process. Four alternate (template) versions of the switch file are also loaded into /etc:

• /etc/nsswitch.files

• /etc/nsswitch.nis

• /etc/nsswitch.nisplus

• /etc/nsswitch.ldap

These four files are alternate default switch files. Each one is designed for a different primary naming service: /etc files, NIS, NIS+, or LDAP. When the Solaris release software is first installed on a workstation, the installer selects the workstation's default name service: NIS+, NIS, local files, or LDAP. During installation, the corresponding template file is copied to nsswitch.conf. For example, for a workstation client using NIS+, the installation process copies nsswitch.nisplus to nsswitch.conf. Unless you have an unusual namespace, the default template file as copied to nsswitch.conf should be sufficient for normal operation.

No default file is provided for DNSor IPv6, but you can edit any of these files to use DNS or IPv6 (see "DNS and Internet Access" or "IPv6 and Internet Access").

If you later change a workstation's primary name service, you simply copy the appropriate alternate switch file to nsswitch.conf. (See "The nsswitch.conf Template Files".) You can also change the sources of particular types of network information used by the client by editing the appropriate lines of the /etc/nsswitch.conf file. The syntax for doing this is described below, and additional instructions are provided in Solaris Naming Setup and Configuration Guide.

Format of the nsswitch.conf File

The nsswitch.conf file is essentially a list of 16 types of information and the sources that getXXbyYY() routines search for that information. The 16 types of information, not necessarily in this order, are:

• aliases

• bootparams

• ethers

• group

• hosts

• ipnodes

• netgroup

• netmasks

• networks

• passwd (includes shadow information)

• protocols

• publickey

• rpc

• services

• automount

• sendmailvars

Table 2-1 provides a description of the kind of sources that can be listed in the switch file for the information types above.

Search Criteria

Single Source. If an information type has only one source, such as nisplus a routine using the switch searches for the information in that source only. If it finds the information, it returns a success status message. If it does not find the information, it stops searching and returns a different status message. What the routine does with the status message varies from routine to routine.

Multiple Sources. If a table has more than one source for a given information type, the switch directs the routine to start searching for the information in the first source that is listed. If it finds the information, it returns a success status message. If it does not find the information in the first source, it tries the next source. The routine will search through all of the sources until it has found the information it needs, or it is halted by encountering a return specification. If all of the listed sources are searched without finding the information, the routine stops searching and returns a non-success status message.

Switch Status Messages

If a routine finds the information, it returns a success status message; if it does not find the information it is looking for, it returns one of three unsuccessful status messages, depending on the reason for not finding the information. Possible status messages are listed in Table 2-2.

Switch Action Options

You can instruct the switch to respond to status messages with either of these two actions shown in Table 2-3.

Default Search Criteria

The combination of nsswitch.conf file status message and action option determine what the routine does at each step. This combination of status and action is called the search criteria.

The switch's default search criteria are the same for every source. Described in terms of the status messages listed above, they are:

• SUCCESS=return. Stop looking for the information and proceed using the information that has been found.

• UNAVAIL=continue. Go to the next nsswitch.conf file source and continue searching. If this is the last (or only) source, return with a NOTFOUND status.

• NOTFOUND=continue. Go to the next nsswitch.conf file source and continue searching. If this is the last (or only) source, return with a NOTFOUND status.

• TRYAGAIN=continue. Go to the next nsswitch.conf file source and continue searching. If this is the last (or only) source, return with a NOTFOUND status.

Because these are the default search criteria, they are assumed. That is, you do not have to explicitly specify them in the switch file. You can change these default search criteria by explicitly specifying some other criteria using the STATUS=action syntax show above. For example, the default action for a NOTFOUND condition is to continue the search to the next source. To specify that for a particular type of information, such as networks, the search is to halt on a NOTFOUND condition, you would edit the networks line of the switch file to read:

networks: nis [NOTFOUND=return] files

The networks: nis [NOTFOUND=return] files line specifies a nondefault criterion for the NOTFOUND status. (Nondefault criteria are delimited by square brackets.)

In this example, the search routine behaves as follows:

• If the networks map is available and contains the needed information, the routine returns with a SUCCESS status message.

• If the networks map is not available, the routine returns with an UNAVAIL status message and by default continues on to search the appropriate /etc file.

• If the networks map is available and found, but it does not contain the needed information, the routine returns with a NOTFOUND message. But instead of continuing on to search the appropriate /etc file (the default behavior), the routine stops searching.

• If the networks map is busy, the routine returns with an TRYAGAIN status message and by default continues on to search the appropriate /etc file.

What if the Syntax is Wrong?

Client library routines contain compiled-in default entries that are used if an entry in the nsswitch.conf file is either missing or syntactically incorrect. These entries are the same as the switch file's defaults.

The name service switch assumes that the spelling of table and source names is correct. If you misspell a table or source name, the switch uses default values.

Auto_home and Auto_master

The switch search criteria for the auto_home and auto_master tables and maps is combined into one category called automount.

Timezone and the Switch File

The timezone table does not use the switch, so it is not included in the switch file's list.

Comments in nsswitch.conf Files

Any nsswitch.conf file line beginning with a hash character (#) is interpreted as a comment line and is ignored by routines that search the file.

When a hash character (#) is included in the middle of the line, characters to the left of the hash mark (before the hash mark) are interpreted by routines that search the nsswitch.conf file; characters to the right of the hash mark (after the hash mark) are interpreted as comments and not acted upon.

Keyserver and publickey Entry in the Switch File

The keyserver reads the publickey entry in the name service switch configuration file only when the keyserver is started. As a result, if you change the switch configuration file, the keyserver does not become aware of changes to the publickey entry until it is restarted.

The nsswitch.conf Template Files

Three nsswitch.conf template files are provided with the Solaris operating environment. Each of them provides a different default set of primary and subsequent information sources.

The three template files are:

• NIS+ template file. The nsswitch.nisplus configuration file specifies NIS+ as the primary source for all information except passwd, group, automount, and aliases. For those four files, the primary source is local /etc files and the secondary source is an NIS+ table. The [NOTFOUND=return] search criterion instructs the switch to stop searching the NIS+ tables if it receives a "No such entry" message from them. It searches through local files only if the NIS+ server is unavailable.

• NIS template file. The nsswitch.nis configuration file is almost identical to the NIS+ configuration file, except that it specifies NIS maps in place of NIS+ tables. Because the search order for passwd and group is files nis, you don't need to place the + entry in the /etc/passwd and /etc/group files.

• Files template file. The nsswitch.files configuration file specifies local /etc files as the only source of information for the workstation. There is no "files" source for netgroup, so the client simply won't use that entry in the switch file.

• LDAP template file. The nsswitch.ldap configuration file specifies the LDAP directory as the primary source of information for the workstation.

Copy the template file that most closely meets your requirements to thensswitch.conf configuration file and then modify nsswitch.conf as needed. (See the switch chapter of Solaris Naming Setup and Configuration Guide for a detailed description of this process.)

For example, to use the NIS+ template file, you would type the following command:

mymachine# cp nsswitch.nisplus nsswitch.conf

The Default Switch Template Files

Here are the three switch files supplied with Solaris operating environment:

Example 2-1 NIS+ Switch File Template (nsswitch.nisplus)

#
#
# /etc/nsswitch.nisplus:
#
#
# An example file that could be copied over to /etc/nsswitch.conf;
# it uses NIS+ (NIS Version 3) in conjunction with files.
#
# "hosts:" and "services:" in this file are used only if the
# /etc/netconfig file has a "-" for nametoaddr_libs of "inet"
# transports.
 
# the following two lines obviate the "+" entry in /etc/passwd 
# and /etc/group.
passwd: files nisplus
group: files nisplus
# consult /etc "files" only if nisplus is down. 
hosts: nisplus [NOTFOUND=return] files
# Uncomment the following line, and comment out the above, to use 
# both DNS and NIS+. You must also set up the /etc/resolv.conf 
# file for DNS name server lookup. See resolv.conf(4).
# hosts: nisplus dns [NOTFOUND=return] files
services: nisplus [NOTFOUND=return] files
networks: nisplus [NOTFOUND=return] files
protocols: nisplus [NOTFOUND=return] files
rpc: nisplus [NOTFOUND=return] files
ethers: nisplus [NOTFOUND=return] files
netmasks: nisplus [NOTFOUND=return] files	
bootparams: nisplus [NOTFOUND=return] files
publickey: nisplus
netgroup: nisplus
automount: files nisplus
aliases: files nisplus
sendmailvars: files nisplus

Example 2-2 NIS Switch File Template

#
# /etc/nsswitch.nis:
#
# An example file that could be copied over to /etc/nsswitch.conf;
# it uses NIS (YP) in conjunction with files.
#
# "hosts:" and "services:" in this file are used only if the
# /etc/netconfig file has a "-" for nametoaddr_libs of "inet"
# transports.
#
# the following two lines obviate the "+" entry in /etc/passwd
# and /etc/group.
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

Example 2-3 Files Switch File Template

#
# /etc/nsswitch.files:
#
# An example file that could be copied over to /etc/nsswitch.conf;
# it does not use any naming service.
#
# "hosts:" and "services:" in this file are used only if the
# /etc/netconfig file has a "-" for nametoaddr_libs of "inet"
# transports.
passwd: files
group: files
hosts: files
networks: files
protocols: files
rpc: files
ethers: files
netmasks: files	
bootparams: files
publickey: files
# At present there isn't a 'files' backend for netgroup;
# the system will figure it out pretty quickly, and won't use
# netgroups at all.
netgroup: files
automount: files
aliases: files
services: files
sendmailvars: files

Example 2-4 LDAP Switch File Template

 #
# /etc/nsswitch.ldap:
#
# An example file that could be copied over to /etc/nsswitch.conf; it
# uses LDAP in conjunction with files.
#
# "hosts:" and "services:" in this file are used only if the
# /etc/netconfig file has a "-" for nametoaddr_libs of "inet" transports.

# the following two lines obviate the "+" entry in /etc/passwd and /etc/group.
passwd:     files ldap
group:      files ldap

hosts:      ldap [NOTFOUND=return] files

networks:   ldap [NOTFOUND=return] files
protocols:  ldap [NOTFOUND=return] files
rpc:        ldap [NOTFOUND=return] files
ethers:     ldap [NOTFOUND=return] files
netmasks:   ldap [NOTFOUND=return] files
bootparams: ldap [NOTFOUND=return] files
publickey:  ldap [NOTFOUND=return] files

netgroup:   ldap

automount:  files ldap
aliases:    files ldap

# for efficient getservbyname() avoid ldap
services:   files ldap
sendmailvars:   files

Default nsswitch.conf File

The default nsswitch.conf file that is installed when you install the Solaris operating environment for the first time is determined by which name service you select during the Solaris software installation process. When you chose a name service, the switch template file for that service is copied to create the new nsswitch.conf file. For example, if you choose NIS+, the nsswitch.nisplus file is copied to create a new nsswitch.conf file.

DNS and Internet Access

The nsswitch.conf file also controls DNS forwarding for clients as described in the following subsections. DNS forwarding grants Internet access to clients.

The NIS+ client must have a properly configured /etc/resolv.conf file (as described in "DNS Clients and the Resolver").

See the switch file chapter of Solaris Naming Setup and Configuration Guide for step-by-step instructions on enabling DNS forwarding for NIS+ and NIS clients.

DNS Forwarding for NIS+ Clients

NIS+ clients do not have implicit DNS forwarding capabilities like NIS clients do. Instead, they take advantage of the switch. To provide DNS forwarding capabilities to an NIS+ client, change its hosts entry to:

hosts: nisplus dns [NOTFOUND=return] files

DNS Forwarding for NIS Clients

DNS forwarding is inherent in the NIS name service. The proper format for the hosts line in a NIS-primary switch file to enable DNS forwarding is:

hosts: nis [NOTFOUND=return] files

If an NIS client is using the DNS forwarding capability of a NIS-compatible NIS+ server, its nsswitch.conf file should not have hosts: nis dns files as the syntax for the hosts file. This is because DNS forwarding automatically forwards host requests to DNS and this syntax would cause the NIS+ server to forward unsuccessful requests to the DNS servers twice, which would reduce performance. To take best advantage of DNS forwarding, use the default syntax for the nsswitch.nis file.

IPv6 and Internet Access

The nsswitch.conf file controls search criteria for IPv6 addresses. IPv6 increases the IP address size from 32 bits to 128 bits to support more levels of addressing hierarchy and provide a greater number of addressable nodes. For more information about IPv6, its configuration and implementation, see "Overview of IPv6" in System Administration Guide, Volume 3 and "Transitioning From IPv4 to IPv6" in System Administration Guide, Volume 3.

Use the new ipnodes source for IPv6 addresses. The /etc/inet/ipnodes file stores both IPv4 and IPv6 addresses. The /etc/inet/ipnodes file uses the same format convention as the /etc/hosts file.

IPv6 aware name services use the new ipnodes source for its search forwarding. For instance, if LDAP is aware of IPv6 addresses specify:

ipnodes: ldap [NOTFOUND=return] files

ipnodes defaults to files. During the transition from IPv4 to IPv6, where all name services are not aware of IPv6 addresses, accept the files default. Otherwise, unnecessary delays (such as boot timing delays) might result during the resolution of addresses.

An application searches all ipnodes databases for IPv4 addresses before searching for IPv4 addresses in the hosts databases. Before specifying ipnodes, consider the inherent delay of searching both databases for IPv4 addresses.

Adding Compatibility With +/- Syntax

You can add to your nsswitch.conf file compatibility with the +/- syntax sometimes used in /etc/passwd, /etc/shadow, and /etc/group files.

• NIS+. To provide +/- semantics with NIS+, change the passwd and groups sources to compat and add a passwd_compat: nisplus entry to the nsswitch.conf file after the passwd or group entry as shown below:

  passwd: compat passwd_compat: nisplus group: compat group_compat: nisplus

  This specifies that client routines obtain their network information from /etc files and NIS+ tables as indicated by the +/- entries in the files.

• NIS. To provide the same syntax as in the Sun Operating Environment 4.x release, change the passwd and groups sources to compat.

  passwd: compat group: compat

  This specifies that /etc files and NIS maps as indicated by the +/- entries in the files.

Users working on a client machine being served by an NIS+ server running in NIS compatibility mode cannot run ypcat on the netgroup table. Doing so will give you results as if the table were empty even if it has entries.

See the switch file chapter of Solaris Naming Setup and Configuration Guide for step by step instructions on adding +/- semantics to an nsswitch.conf file.

The Switch File and Password Information

For passwd information, files should always be the first source searched.

For example, in an NIS+ environment, the passwd line of the nsswitch.conf file should look like this:

passwd: files nisplus

In a NIS environment, the passwd line of the nsswitch.conf file should look like this:

passwd: files nis

files should be the first source in the nsswitch.conf file for passwd information. If files is not the first source, network security could be weakened and users could encounter log in difficulty.

FNS and the Name Service Switch

See Chapter 20, FNS Quickstart and Chapter 21, Federated Naming Overview for introductory information about the Federated Naming Service.

FNS, the Solaris implementation of the XFN API, can also be used to specify which name service a client is to query for naming information. The XFN API is more general in both the X and Y dimensions than the update getXbyY() interfaces that use the switch file. For example, it can be used to look up information on both hosts and users, from both NIS+ and NIS. An application can be a client of either getXbyY(), or XFN, or both.

Maintaining Consistency Between FNS and the Switch File

In order to ensure that changes made to namespace data through FNS are always available to clients obtaining namespace information through the switch file, always configure both the switch and FNS to use the same name service.

Namespace Updates

The support for data updates provided by the XFN API is superior to that of the getXbyY() interfaces. Most namespaces are composed of data from multiple sources. A groups namespace, for example, might contain information from both the /etc/group file and the NIS+ group.org_dir object. But the switch file does not provide enough information for an application update routine to identify the source of some particular piece of group data or the source to update.

Because each FNS subordinate namespace comes entirely from a single name service, updates are simple and straightforward because there is no confusion over which name service the update applies to.