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.

Note - 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 an 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

Table 25-23 fncopy Command Options

For example, to copy the contexts listed in the file /etc/sales_users from the doc.com domain of an 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