Chapter 23 FNS and Enterprise Name Services

This chapter discusses administration matters relating to FNS and enterprise level naming services.

• "FNS and Enterprise-Level Naming Services"

• "Choosing an Enterprise-Level Name Service"

• "FNS and Naming Service Consistency"

• "Selecting a Naming Service"

• "Default Naming Service"

• "When NIS+ and NIS Coexist"

• "Advanced FNS and NIS+ Issues"

• "Advanced FNS and NIS Issues"

• "Advanced FNS and File-Based Naming Issues"

FNS and Enterprise-Level Naming Services

Enterprise-level naming services are used to name objects within an enterprise. FNS currently supports three enterprise-level naming services:

• NIS+. See also "FNS and NIS+ Naming" and "How FNS Policies Relate to NIS+".

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

• Local files. See "FNS and Files-Based Naming" and "How FNS Policies Relate to Files-Based Naming".

Choosing an Enterprise-Level Name Service

When you initially set up and configure your FNS namespace with the fncreate command as described in Solaris Naming Setup and Configuration Guide, the correct default name service is automatically selected for each machine.

If you later change a machine's primary enterprise-level name service, you should run the fnselect command on that machine. See "Selecting a Naming Service" for details.

FNS and Naming Service Consistency

As a system administrator one of your tasks is to maintain consistency between FNS and the underlying naming service by ensuring that the contents of FNS contexts and the files, maps, or tables of the underlying naming service correspond.

When you initially set up and configure your FNS namespace with the fncreate command as described in Solaris Naming Setup and Configuration Guide, fncreate ensures that FNS contexts are correctly created and are consistent with the underlying naming service data. After the FNS contexts have been set up, this correspondence needs to be maintained as users, hosts, printers, and so forth are added to and removed from the system. The following sections describe how to maintain FNS and name service consistency.

FNS and Solstice AdminSuite

If you have the Solstice AdminSuite product, you can use it to add, change, or delete user and host information in the underlying name service. This is a recommended method because the AdminSuite tools update the corresponding FNS namespace automatically.

Checking Naming Inconsistencies

When updates to FNS or the primary name service are made independent of the Solstice AdminSuite product, the resulting inconsistencies are resolved by the use of the FNS tool, fncheck. The fncheck command checks for inconsistencies between the FNS hostname and user contexts, and:

• NIS+. The NIS+ hosts.org_dir and passwd.org_dir system tables.

• NIS. The NIS hosts.byname and passwd.byname maps.

• Files. The etc/hosts and etc/passwd files.

The fncheck command lists those host and user names that are in the FNS namespace but not in the name service data, and those host and user names that are in the name service data but not in the FNS namespace.

The command syntax is:

fncheck [-r][-s][-u][-t hostname|username][domain_name]

The -t option is used to specify the contexts to check (host or user). If you omit the -t option, both the hostname and username contexts are checked.

When the -r option is used with the -u option, items that appear only in the FNS context are removed from the FNS context. When the -s option is used with the -u option, items that appear only in the namespace dataset are added to the FNS context. If neither -r or -s are specified, items are added and removed from the FNS context to make it consistent with the corresponding namespace data.

Selecting a Naming Service

When FNS constructs the bindings in the initial context for a machine, it does so on the basis of a particular naming service.

You can choose which name service FNS is to use with the fnselect command. The name service setting you specify with fnselect affects the entire machine, all applications running on that machine, and all users logged in to that machine.

Only root can run fnselect. The command syntax is:

fnselect [-D] [namesvc]

For example, to select NIS+ as a machine's name service:

#fnselect nisplus

For example, to select the default as a machine's name service and print the name of the service used to generate the FNS initial context:

#fnselect -D default

Default Naming Service

If you do not designate a naming service with fnselect, FNS uses the default naming service. The default naming service is determined by FNS based on the name service that the machine is using. If the machine is an NIS+ client, FNS uses NIS+ as the name service. If the machine is a NIS client, FNS uses NIS. If the machine is neither an NIS+ nor a NIS client, FNS uses /etc files as the machine's default name service.

When NIS+ and NIS Coexist

In rare cases you may need to access both NIS+ and NIS-based contexts. For example, you might have a NIS server running that is itself an NIS+ client. In this situation, you use the fnselect command to select the enterprise-level naming service that you want to work with.

Advanced FNS and NIS+ Issues

This section provides detailed information on the relationship between NIS+ objects and FNS objects. This information is useful when you must change the access control of FNS objects.

See:

• "Migrating From NIS to NIS+".

• "Migrating From Files-Based Naming to NIS or NIS+".

Mapping FNS Contexts to NIS+ Objects

FNS contexts are stored as NIS+ objects. All contexts associated with an organization are stored under the FNS ctx_dir directory of the associated NIS+ domain. The ctx_dir directory resides at the same level as the org_dir directory of the same domain. In other words, when running in conjunction with FNS, for every NIS+ domain or subdomain, there are corresponding org_dir, groups_dir and ctx_dir directory objects.

Use the -v option for the fnlookup or fnlist command to see the detailed description of references. The internal name field displays the name of the corresponding NIS+ object.

Browsing FNS Structures Using NIS+ Commands

The NIS+ command, nisls, can be used to list the NIS+ objects used by FNS. For example, the following commands list the contents of the NIS+ domain directory and its ctx_dir subdirectory.

# nisls doc.com.
doc.com.:
manf
sales
groups_dir
org_dir
ctx_dir

# nisls ctx_dir.doc.com.
ctx_dir.DOC.COM.:
fns
fns_user
fns_host
fns_host_alto
fns_host_mladd
fns_host_elvira
fns_user_jjones
fns_user_jsmith
fns_user_aw

Use the niscat command to list the contents of the fns_hosts table.

# niscat fns_host.ctx_dir
altair *BINARY* *BINARY*
cygnus *BINARY* *BINARY*
centauri *BINARY* *BINARY*

Checking Access Control

Use niscat -o to see the access control of a context. To see the access control of a particular binding, use the name of the binding entry in the parent context's binding table (that is, the name displayed in the internal name field in the output of fnlookup -v and fnlist -v):

# niscat -o fns_host.ctx_dir
Object Name     	:	fns_host
Owner           	:	alto.doc.com.
Group      	        :       admin.doc.com.
Domain	                :	ctx_dir.doc.com.
Access Rights   	:	r-c-rmcdrmcdr-c-
Time to Live    	:	53:0:56
Object Type     	:	TABLE
Table Type      	:	H
Number of Columns	:	3
Character Separator	
Search Path     	:
Columns         	:
[0]	Name    	:	atomicname
	Attributes	:	(SEARCHABLE, TEXTUAL DATA,	CASE INSENSITIVE)
	Access Rights	:	r-c-rmcdrmcdr-c-
[1]	Name    	:	reference
	Attributes	:	(BINARY DATA)
	Access Rights	:	r-c-rmcdrmcdr-c-
[2]	Name    	:	flags
	Attributes	:	(BINARY DATA)
	Access Rights	:	r-c-rmcdrmcdr-c-

# niscat -o "[atomicname=altair],fns_host.ctx_dir"
Object Name	:	fns_host
Owner   	:	altair.doc.com.
Group   	:       admin.doc.com.
Domain  	:	ctx_dir.doc.com.
Access Rights	:	r-c-rmcdrmcdr-c-
Time to Live	:	12:0:0
Object Type	:	ENTRY
 Entry data of type H
 [1] - [5 bytes] 'alto'
 [2] - [104 bytes] '0x00 ...'
 [3] - [1 bytes] 0x01

(See "The niscat Command" for additional information on the niscat command.)

To change the access control or ownership of a particular context, use the commands:

• nischown

• nischmod

• nischgrp

Give either the binding entry or the bindings table as an argument, depending on the object the operation is to affect.

Advanced FNS and NIS Issues

This section provides specific information on the relationship between NIS and FNS.

NIS and FNS Maps and Makefiles

FNS uses six new maps which are stored in /var/yp/domainname directories on the NIS master and slave servers:

• fns_host.ctx which stores host attributes and subcontext data. When this is first created, it derives its information from the hosts.byname map.

• fns_host.ctx which stores user attributes and subcontext data. When this is first created, it derives its information from the passwd.byname map.

• fns_org.ctx which stores organization attributes and subcontext data.

• fns_host.attr which stores host attributes for attribute based searches.

• fns_user.attr which stores user attributes for attribute based searches.

• fns_org.attr which stores organization attributes for attribute based searches.

Service and file context information for hosts, users, and the organization are stored in the respective fns_host.ctx, fns_user.ctx, and fns_org.ctx maps. Printer context information is stored in the same maps as other service context information. However, the older printers.conf.byname map is still supported.

Sites are subcontexts of the organization and site context information is stored in the fns_org.ctx map.

These FNS maps should not be edited directly. You modify or work with these maps by running the appropriate FNS commands such as fncreate, fndestroy, fnbind, fnunbind, fnrename, fnattr, fnlookup, and fnlist. These commands must be run on the NIS master server. You cannot run them on slave servers or client machines.

The FNS map files are placed in the /var/yp/domainname directory. The NIS Makefile in /var/yp is modified to be aware of the FNS Makefile in /etc/fn/domainname.

Large FNS Contexts

NIS has a 64K limit on the number of entries a NIS map can contain. If only service and printer contexts are created for each object (host or user), that limit will be reached when the number of users or hosts exceeds 7K. If additional contexts are created for hosts or users, as is usually the case, the upper 64K limit will be reached with far fewer hosts or users.

FNS solves this problem by automatically creating new maps after an old map has reached its maximum size. Each new map is identified by adding a numeric suffix to the map's name. For example, when a second fns_user.ctx map is created it is given the name fns_user_0.ctx. If a third map became necessary it would be given the name fns_user_1.ctx. As additional maps are created, the number is incremented each time.

Printer Backward Compatibility

In Solaris release 2.5, FNS support for printer naming under NIS was provided for the organization context with a map named printers.conf.byname. In the current Solaris release, organization context printer support is maintained in the fns_org.ctx map. That is, the fncreate_printer command now modifies the fns_org.ctx map and not the printers.conf.byname map.

Migrating From NIS to NIS+

The fncopy command handles the FNS-related aspects of changing your underlying enterprise-level naming service from NIS to NIS+. This command copies and converts NIS-based FNS contexts to NIS+ based contexts.

The command syntax is:

fncopy [-i oldsvc -o newsvc] [-f filename] oldctx newctx

For example, to copy the contexts listed in the file /etc/sales_users from the doc.com domain of a NIS-based naming service to the sales.doc.com domain of an NIS+ naming service, you would enter:

fncopy -i nis -o nisplus -f /etc/sales_users org/sales.doc.com/user

Advanced FNS and File-Based Naming Issues

This section provides specific information on the relationship between files-based naming and FNS.

FNS Files

FNS uses new files which are stored in /var/fn directories on each machine. (While a /var/fn directory is normally stored on each machine, you can mount and export a central /var/fn directory via NFS.)

The new FNS files are:

• fns_host.ctx which stores host attributes and subcontext data. When this is first created, it derives its information from the /etc/hosts file.

• fns_user.ctx which stores user attributes and subcontext data. When this is first created, it derives its information from the /etc/passwd file.

• fns_org.ctx which stores organization attributes and subcontext data.

• fns_host.attr which stores host attributes for attribute based searches.

• fns_user.attr which stores user attributes for attribute based searches.

• fns_org.attr which stores organization attributes for attribute based searches.

• Users' sub-context and attribute information is stored in separate /var/fn files that are owned by each user. This allows users to modify their own data with FNS commands. These user-specific files are named fns_user_username.ctx where username is the login ID of the individual user.

Service and file context information for hosts, users, and the organization are stored in the respective fns_host.ctx, fns_user.ctx, and fns_org.ctx files. Printer context information is stored in the same files as other service context information.

Sites are subcontexts of the organization and site context information is stored in the fns_org.ctx file.

These FNS files should not be edited directly. You modify or work with these files by running the appropriate FNS commands such as fncreate, fndestroy, fnbind, fnunbind, fnrename, fnattr, fnlookup, and fnlist. When you run these commands as root, they affect the context that they are applied to such as hosts, site, and organization unit. When you run these commands as a user, they affect only your own user sub-contexts.

Migrating From Files-Based Naming to NIS or NIS+

The fncopy command handles the FNS-related aspects of changing your underlying enterprise-level naming service from files to NIS or NIS+. This command copies and converts files-based FNS contexts to NIS or NIS+ based contexts.

The command syntax is:

fncopy [-i oldsvc -o newsvc] [-f filename] oldctx newctx

For example, to copy the contexts listed in the file /etc/host_list to the doc.com domain of an NIS+ naming service, you would enter:

fncopy -i files -o nisplus -f /etc/host_list //doc.com/host

Printer Backward Compatibility

In Solaris release 2.5, FNS support for printer naming for files was provided for the organization context with a file named printers.conf.byname. In the current Solaris release, organization context printer support is maintained in the fns_org.ctx map. That is, the fncreate_printer command now modifies the fns_org.ctx map and not the printers.conf.byname map.