Solaris Enterprise-Level Naming Services

An enterprise-level naming service identifies (names) machines (hosts), users and files within an enterprise-level network. FNS also allows naming of organizational units, geographic sites, and application services. An "enterprise-level" network can be a single Local Area Network (LAN) communicating over cables, infra-red beams, or radio broadcast; or a cluster of two or more LANs linked together by cable or direct phone connections. Within an enterprise-level network, every machine is able to communicate with every other machine without reference to a global naming service such as DNS or X.500/LDAP.

FNS currently supports three enterprise-level naming services:

• NIS+. See "FNS and NIS+ Naming", below, "How FNS Policies Relate to NIS+", and "Advanced FNS and NIS+ Issues".

• NIS. See "FNS and NIS Naming", "How FNS Policies Relate to NIS", and "Advanced FNS and NIS Issues".

• Files. See "FNS and Files-Based Naming", "How FNS Policies Relate to Files-Based Naming", and "Advanced FNS and File-Based Naming Issues ".

See Chapter 23, FNS and Enterprise Name Services, for administration information regarding FNS and enterprise-level naming services.

FNS and NIS+ Naming

If you are not familiar with NIS+ and its terminology, refer to Part 1 and Glossary of this guide. You will find it helpful to be familiar with the structure of a typical NIS+ environment.

NIS+ is the preferred enterprise-wide information service in the Solaris environment. Both NIS and local files can be used along with NIS+. NIS+ allows an enterprise to be divided into hierarchical organizational levels composed of domains and subdomains.

FNS organization units correspond to NIS+ domains and subdomains. There is one orgunit context for each domain and subdomain.

FNS federates NIS+, NIS, and local files to support naming policies in the Solaris environment. To do this, FNS provides the XFN interface for performing naming operations on organization, site, user, and host objects. It implements these operations using the appropriate programming interface for accessing files, directories, and tables.

Under NIS+, FNS context and attribute data is stored in NIS+ type tables. These tables are stored in NIS+ type directory objects named ctx_dir. There is an ctx_dir directory object for each NIS+ domain and subdomain, residing at the same level as the domain's groups_dir and org_dir directory objects. Thus, the directory object ctx_dir.sales.doc.com. contains FNS tables which store FNS context and attribute data for the sales.doc.com domain.

Under NIS+, you use FNS and NIS+ commands to work with the information in FNS tables. Do not edit these tables directly or manipulate them with UNIX commands.

FNS and NIS Naming

NIS is an enterprise-wide information service in the Solaris environment. Local files can be used along with NIS. Under NIS, an enterprise is organized as a single NIS domain.

Each enterprise is a single NIS domain. There is one FNS organizational unit which corresponds to the single NIS domain.

FNS federates NIS and local files to support naming policies in the Solaris environment. To do this, FNS provides the XFN interface for performing naming operations on organization, site, user, and host maps. It implements these operations using the appropriate programming interface for accessing files, directories.

Under NIS, FNS context and attribute data are stored in NIS maps. These maps are stored in a /var/yp/domainname directory on a NIS server. Under NIS, the super user can use FNS commands to work with the information in FNS maps.

NIS Clients Can Update Contexts With FNS if SKI is Running

If certain conditions are met, any NIS client (machine, process, or user) can use FNS commands such as fncreate_fs or fncreate_printer to update the client's own contexts. This allows NIS clients to use FNS commands to update applications such as Printer Administrator, CDE Calendar Manager, Admin Tool and others.

For non-super-users to update their own contexts with FNS commands, the following conditions must be met:

• Secure Key_management Infrastructure (SKI) must be available on the NIS master server.

• The fnsypd daemon must be running on the NIS master server. This daemon must be started by someone with super user privileges.

• A client user or machine is only allowed to update its own context.

• The client must be authorized to perform the requested update.

FNS and Files-Based Naming

Files refers to the naming files normally found in a machine's /etc directory. These machine-based files contain UNIX user and password information, host information, mail aliases, and so forth. They also support Solaris-specific data such as the automount maps.

FNS federates local files to support naming policies in the Solaris environment. To do this, FNS provides the XFN interface for performing naming operations on organization, site, user, and host files. It implements these operations using the appropriate programming interface for accessing files, directories.

Under a files-based naming system, FNS context and attribute data is stored in files. These files are stored in a /var/fn directory exported from an NFS file server.

Under a files-based naming system, you use FNS commands to work with the information in FNS files.