Introducing Naming Service Concepts
When you installed your Solaris computer, you provided information such as the computer's name and network address (if networked). After you logged in as root, you probably also created user accounts and groups, and associated users with those groups. Perhaps you added a printer and configured the appropriate permissions to use the printer, as well as the permissions needed for users to access certain files and folders. Where is all of this configuration information stored?
If yours is the only Solaris computer around, this information is stored in local files, most of which are located in the /etc directory (/etc/passwd, /etc/group, /etc/printers.conf, and /etc/netmasks to name a few). However, the more computers you have (in a network setting, for example), the more local configuration files you will need to update. On small networks this is a tedious job, and on large networks it's impossible to keep up with all of the required changes.
For example, imagine that you are using the hosts file to locate other computers on the network and that you have 50 computers total. Changing the IP address of one computer will require you to manually edit the hosts file on each of the other computers. That doesn't sound like a fun task. Now imagine the task with 500 computers.
Directory and naming services are used to ease this administrative burden by providing a centralized location that stores configuration information. So, in the earlier hosts example, instead of editing 50 or 500 local hosts files, you could use the Domain Name Service (DNS) installed on a server and edit one file on the DNS server to make the change known to all clients.
In general, naming services can provide a centralized location to store computer names and addresses, usernames and passwords, security permissions, group memberships, printer information, and so forth. Properly used, they can ease your daily network administration work-load, and they are flexible enough to accommodate growth and change within your organization.
Overview of Naming and Directory Services
Currently, the Solaris environment supports six naming and directory services: local files, Domain Name Service (DNS), Network Information Service (NIS), Network Information Service Plus (NIS+), Federated Naming Service (FNS), and Lightweight Directory Access Protocol (LDAP). You can choose to use any combination of one or more of these services. It's common practice to use two or more services concurrently, such as local files, DNS, and NIS together.
| Note | NIS+ and FNS are not test objectives for the Sun Certified Systems Administrator exams and therefore are not covered in detail in this book. |
| Note | Technically, naming services are those that simply resolve names, whereas directory services have much broader object definition and location responsibilities. However, the two are lumped together (due to their similar function) as naming and directory services. |
The original UNIX naming system was the /etc files. For stand-alone computers, local files are entirely sufficient. When you start moving into larger networks, though, using local files is difficult-if not impossible-to manage.
DNS is the naming service designed to work with the TCP/IP protocol suite and is the name resolution method used on the Internet. So, although you might not have realized it, you've probably used DNS a lot more than you have any other naming service.
DNS is designed to resolve computer (host) names to IP addresses. People like to use names for ease (such as www.sun.com, which is easy to remember), whereas computers need to use IP addresses (such as 64.124.140.181, which is harder to remember) to initialize communications. Although DNS is most noted for providing this valuable resolution service on the Internet, it can also function well on local networks.
| Note | Throughout this chapter (and in the real world), the terms computer name and host name are often used synonymously. |
NIS makes local network administration easier by centrally storing network information, such as computer names and addresses, usernames and passwords, printers, and other network services. NIS is very commonly used in Solaris environments.
Most people think that NIS+ is merely an extension or upgrade of the NIS service, but it's not. NIS+ is a completely separate service. It's true, though, that NIS and NIS+ provide the same types of services. NIS+ is a more advanced service: it can store more information, is more efficient, and is generally faster than NIS.
FNS does not replace any of the other naming services. Rather, it sits on top of the existing naming services and provides a common interface between them. This enables you to use one common naming schema to identify all objects in your network. FNS is defined by the X/Open Federated Naming (XFN) standard.
LDAP is a newer industry-standard directory and naming service. It provides many of the same features as NIS+ and can be used as a replacement for NIS+. More detail on LDAP is provided in the "Understanding LDAP" section later in this chapter.
One of the similarities you will find among all of these services is that each one (with the exception of local files) is a client-server service. This means that you need to configure at least one computer as a server (a DNS or NIS+ server, for example), and then all other computers will function as clients to that server. The clients that use that server will be part of the server's namespace. For example, all clients using DNS are part of the DNS namespace.
In a client-server environment, you have two ways of getting the clients and servers to recognize each other in their appropriate roles. The first way is to configure the server with each client's information. This type of configuration has traditionally been shunned because it's difficult to maintain. Instead, most clients are configured to locate the servers. Using this configuration method, the client knows how to contact the server (or multiple servers, if necessary), and each server simply responds to each client request.
In Solaris, the client configuration is controlled by the name service switch file, /etc/ nsswitch.conf. Each client has its own name service switch file, which tells it the naming service to use, based on the type of information the client is seeking.
Using the nsswitch.conf File
The nsswitch.conf file controls how a client computer or an application on the client computer responds when it needs network information. Every computer on the network must have its own nsswitch.conf file. Each entry in the nsswitch.conf file identifies a type of information, such as a host, netmask, group, or service, as well as one or more sources from which the client can obtain the information, such as local files or a NIS server.
Client computers can use practically any combination of sources for information. For example, a client could use its local /etc files for user and password information, but use a DNS server to locate host names. Alternatively, a client could be configured to use NIS for all information first, and then use the local /etc files only when or if the NIS server doesn't have the requested information.
When you install Solaris, a default nsswitch.conf file is selected from one of five default template files, depending on your installation choices. The five template files are nsswitch.dns, nsswitch.ldap, nsswitch.nis, nsswitch.nisplus, and nsswitch.files. If, for example, you have chosen to use NIS+, the nsswitch.nisplus file will be copied to nsswitch.conf automatically. If you're not on a network, the nsswitch.files file will be copied to nsswitch.conf.
Reading the nsswitch.conf File
The nsswitch.conf file is a list of approximately 20 types of information that clients can request. Listed alphabetically here (but not necessarily in the file itself), these keywords include aliases, automount, bootparams, ethers, group, hosts, ipnodes, netgroup, netmasks, networks, passwd (which also refers to shadow information), protocols, publickey, rpc, services, and sendmailvars.
Each of the searches for different types of information is configured independently and can be supplied with any of the six information sources listed in Table 15.1.
| Source | Description |
|---|---|
| compat | Password or group information. Used to support the old-style (Sun OE 4.x) + or - syntax in the /etc/passwd, /etc/shadow, and /etc/group files. |
| dns | DNS server. |
| files | Local /etc files. |
| ldap | LDAP server. |
| nis | NIS server (NIS servers use maps). |
| nisplus | NIS+ server (NIS+ servers use tables). |
If a single source is supplied, then the client computer will consult only that source when seeking the requested information. If the source can supply the information, a success message is returned. If the source does not have the information, then a failure message is returned.
Consider the following nsswitch.conf file, which is the default file from a non-networked Solaris computer (the nsswitch.files 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 ipnodes: 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 printers: user files auth_attr: files prof_attr: files project: files
As is the case in all other Solaris files, lines that begin with a pound sign (#) are comments and are not processed. Looking at the file, you can see that each of these lines has one source: files. (The printers keyword is an exception, as it points to the user's configuration files.)
Multiple sources can also be supplied. If multiple sources are supplied, the sources will be checked in consecutive order. The number of sources checked depends on the result of the prior source search. Here's an example, taken from the nsswitch.nis file, of configuring the system to use multiple sources:
# /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 ipnodes: files # Uncomment the following line and comment out the above to resolve # both IPv4 and IPv6 addresses from the ipnodes databases. Note that # IPv4 addresses are searched in all of the ipnodes databases before # searching the hosts databases. Before turning this option on, consult # the Network Administration Guide for more details on using IPv6. #ipnodes: 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 printers: user files nis auth_attr: files nis prof_attr: files nis project: files nis
In this file, many of the network-specific options, such as networks, rpc, and netmasks, refer the client to the NIS server first, and then local files. However, other information, such as role-based access control (RBAC) information (auth_attr and prof_attr), is pulled from local files first.
When searching for information, the requesting client (or application on the client) can return one of four status messages. There is one message for a successful information retrieval, and three messages for failures. Each of the four status messages is shown in Table 15.2.
| Message | Description |
|---|---|
| SUCCESS | The requested information was returned by the specified source. |
| NOTFOUND | The source responded with No such entry. The file, map, or table was accessed but did not contain the requested information. |
| TRYAGAIN | The source was busy. Try again later. |
| UNAVAIL | The source did not respond or was not available. The file, map, or table could not be accessed. |
Based on the status message returned, your computer can continue in one of two ways. It can either stop looking for the requested information, or try the next source, if available. These actions are defined by the keywords return (stop looking) and continue (keep looking).
Each status message has a default action. They are:
SUCCESS=return Stop looking for the information, because you already found it.
NOTFOUND=continue Use the next source to attempt to locate the requested information. If this is the last or only source, return with a NOTFOUND status.
TRYAGAIN=continue Use the next source to attempt to locate the requested information. If this is the last or only source, return with a NOTFOUND status.
UNAVAIL=continue Use the next source to attempt to locate the requested information. If this is the last or only source, return with a NOTFOUND status.
In other words, if you've found what you're looking for, stop looking. There's no sense in continuing (humans have to explain these obvious concepts to computers). If you haven't located the information, keep trying if you have another place to look.
Because these actions are default criteria, they do not need to be explicitly defined in the nsswitch.conf file. However, if you want to use a different search criteria, such as NOTFOUND=return, you can do so by editing the nsswitch.conf file. In the sample nsswitch.nis file shown previously, several lines used this syntax. For example:
hosts: nis [NOTFOUND=return] files
This line tells the computer that if the hosts information is found in the NIS map, return a SUCCESS message and stop searching. If either an UNAVAIL or a TRYAGAIN message is returned, then consult the local /etc files for hosts information. If the NOTFOUND message is returned from the NIS server, then the search will cease, even though the correct information was not located.
Modifying the nsswitch.conf File
Assume for a moment that when you originally installed your Solaris computer, you were not a member of a network. However, now you are joining a network that uses the NIS service. Your nsswitch.conf file is configured to look at local files only. What should you do?
There are two ways you could make your computer look for the NIS server. One is to manually edit your existing nsswitch.conf file. Doing so might take a while, but you have another choice. The other way is to use the existing template files to your advantage. Copy the nsswitch.nis file to nsswitch.conf, and other than any custom modifications you might need to make, you're pretty much done. All you need to do is reboot your computer to make the changes take effect. Whenever you're making modifications to files, and in this case you're changing the nsswitch.conf file, it's a good idea to save the original file as an alternate filename or in a different location. That way, if something gets messed up in the configuration, you can just restore the original file.
| Note | If you are installing NIS+ by using the NIS+ installation scripts, the scripts will automatically copy the nsswitch.nisplus file to nsswitch.conf for you. |
| Note | LDAP clients require additional configuration beyond copying the template file. These configuration requirements will be described later in this chapter, in the "Configuring DNS and LDAP Clients" section. |
| Warning | For security reasons, files should be the first search option for password information (passwd), even if your network is using NIS, NIS+, or LDAP. |
Understanding the Name Service Cache Daemon
When you need to use one of the name resolution services, the Name Service Cache Daemon (NSCD) automatically caches information it finds in the nsswitch.conf file. Because some programs do not recheck the nsswitch.conf file directly (they rely on the NSCD), you need to restart the NSCD service after changes are made to nsswitch.conf to ensure that all applications will have current information. To do this, you can use the /etc/init.d/nscd stop and /etc/init.d/nscd start commands, or reboot the computer.
|
|
EAN: 2147483647
Pages: 194