This chapter discusses administration matters relating to 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".
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.
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.
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.
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.
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.
fncheck [-r][-s][-u][-t hostname|username][domain_name] |
Option |
Description |
---|---|
domain |
Apply the command to an NIS+ domain other than the one in which you are running the command. |
-t |
Specifies the type of context to check. Allowed types are hostname or username. |
-s |
Lists host or user names from the namespace dataset that are not in the FNS namespace |
-r |
Lists host or user names from the FNS namespace that do not have entries in the corresponding namespace dataset |
-u |
Updates the FNS namespace based on information in the relevant namespace dataset |
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.
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] |
Option |
Description |
---|---|
namesvc |
The naming service you want to select. Must be one of: default, nisplus, nis, or files. |
-D |
Display the naming service used to generate the FNS initial context. |
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 |
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.
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.
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:
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.
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* |
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:
Give either the binding entry or the bindings table as an argument, depending on the object the operation is to affect.
This section provides specific information on the relationship between NIS and FNS.
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.
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.
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.
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.
fncopy [-i oldsvc -o newsvc] [-f filename] oldctx newctx |
Option |
Description |
---|---|
-i oldsvc |
Source naming service. Only nis or files may be specified. |
-o newsvc |
Target naming service. Only nisplus or nis may be specified. |
-f filename |
Name of file listing the FNS contexts to be copied |
oldctx |
Old FNS context to be copied |
newctx |
Target new FNS context |
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 |
This section provides specific information on the relationship between files-based naming and FNS.
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.
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.
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 |
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.