This part describes the Federated Naming Service (FNS) and how to administer it.
This chapter provides a summary overview of FNS, a brief description of set up and configuration steps, and a programming example. Experienced administrators may find that this quick start chapter is all that they need.
For more detailed information, see the remaining chapters of this part. For more detailed initial FNS set up and configuration information, see Solaris Naming Setup and Configuration Guide.
Federated Naming Service (FNS) provides a method for federating multiple naming services under a single, simple interface for naming and directory operations. Naming services that can be linked with FNS include: NIS+, NIS, files, DNS, and X.500/LDAP.
The programming interface and policies that FNS supports are specified by XFN (X/Open Federated Naming).
FNS is useful for the following reasons:
A single uniform naming and directory interface is provided to clients for accessing naming and directory services. Consequently, the addition of new naming and directory services does not require changes to applications or existing services.
Names can be composed in a uniform way. FNS defines a way to uniformly compose names from different naming systems so that applications can uniformly address objects in these different naming systems.
Coherent naming is encouraged through the use of shared contexts and shared names. Different applications can use these shared names and contexts and need not duplicate the work.
Fundamental to FNS are the notions of composite names and contexts.
A composite name is a name that spans multiple naming systems.
A composite name consists of an ordered list of components. Each component is a name from the namespace of a single naming system. Individual naming systems are responsible for the syntax of each component. FNS defines the syntax for constructing a composite name using names from component naming systems. Composite names are composed left to right using the slash character (/) as the component separator.
For example, the composite name .../doc.com/site/bldg-5.alameda consists of four components: ..., doc.com, site, and bldg-5.alameda.
A context provides operations for:
Associating (binding) names to objects
Resolving names to objects
Removing bindings
Listing names
Renaming
Associating attributes with named objects
Retrieving and updating attributes associated with named objects
Searching for objects using attributes
A context contains a set of name-to-reference bindings. Each reference contains a list of communication end-points or addresses. The federated naming system is formed by contexts from one naming system being bound in the contexts of another naming system. Resolution of a composite name proceeds from contexts within one naming system to those in the next until the name is resolved.
Attributes may be applied to named objects. Attributes are optional. A named object can have no attributes, one attribute, or multiple attributes.
Each attribute has a unique attribute identifier, an attribute syntax, and a set of zero or more distinct attribute values.
XFN defines the base attribute interface for examining and modifying the values of attributes associated with existing named objects. These objects can be contexts or any other types of objects. Associated with a context are syntax attributes that describe how the context parses compound names.
The extended attribute interface contains operations that search for specific attributes and that create objects and their associated attributes.
Enterprise-level naming services are used to name objects within an enterprise. FNS currently supports three enterprise-level naming services:
NIS+ (see "NIS+" below).
NIS (see "NIS").
Files (see "Files-Based").
NIS+ is the preferred enterprise-wide information service in the Solaris 2.6 release environment. FNS organization units correspond to NIS+ domains and subdomains. There is one orgunit context for each domain and subdomain.
Under NIS+, FNS context and attribute data are stored in NIS+ tables. These tables are stored in NIS+ directory objects named ctx_dir. There is a 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.
NIS is an enterprise-wide information service in the Solaris environment. Each enterprise is a single NIS domain. There is one FNS organizational unit which corresponds to the single NIS domain.
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.
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.
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.
Under a files-based naming system, FNS context and attribute data is stored in files. These FNS files are stored in machine's /var/fn directory. (The /var/fn directory does not have to be on each machine, it could be exported from an NFS file server.)
Under a files naming system, you use FNS commands to work with the information in FNS files.
FNS also supports federating NIS+ and NIS with DNS and X.500. This means that you can connect enterprise level namespaces with global namespaces to make the enterprise objects accessible in the global scope.
FNS currently supports the following global naming services:
DNS
X.500 (via DAP or LDAP)
FNS defines naming policies so that users and applications can depend on and use the shared namespace.
Within an enterprise, there are namespaces for organizational units, sites, hosts, users, files and services, referred to by the names orgunit, site, host, user, fs (for file system), and service. These namespaces can also be named by preceding each name with an underscore (_). For example, host and _host are considered identical.
Table 19-1 summarizes the FNS policies for enterprise-level namespaces.
Table 19-1 FNS Policy Summary
Context Type |
Subordinate Contexts |
Parent Contexts |
---|---|---|
orgunit _orgunit |
site user host fs service |
enterprise root |
site _site |
user host fs service |
enterprise root orgunit |
user _user |
service fs |
enterprise root orgunit |
host _host |
service fs |
enterprise root orgunit |
service _service |
Printer and other applications |
enterprise root orgunit site user host |
fs _fs(file system) |
(none) |
enterprise rootorgunit site user host |
The binding of an FNS orgunit is determined by the underlying naming service:
Under NIS+, an organizational unit corresponds to an NIS+ domain or subdomain. For example, assume that the NIS+ root domain is doc.com. and sales is a subdomain of doc.com. Then, the FNS names org/sales.doc.com. and org/sales both refer to the organizational unit corresponding to the NIS+ domain sales.doc.com. (Note the trailing dot in sales.doc.com.which is required for fully qualified NIS+ names.)
Under NIS, an organizational unit is the NIS domain which is always identified by the FNS name org// or org/domainname where domainname is a fully qualified domain name such as doc.com. Under NIS, there is no hierarchy in organizational unit names.
Under a files-based naming system, the organizational unit is the system which is always identified by the FNS name org//.
The types of objects that may be named relative to an organizational unit name are: user, host, service, fs, and site. For example:
org/sales/site/conference1.bldg-6 names a conference room conference1 located in building #6 of the site associated with the organizational unit sales. In this example, if org/sales corresponds to sales.doc.com, another way to name this object would be: org/sales.doc.com./site/conference1.bldg-6 (note the trailing dot in sales.doc.com.)
org/finance/user/mjones names a user mjones in the organizational unit finance.
org/finance/host/inmail names a machine inmail belonging to the organizational unit finance.
org/accounts.finance/fs/pub/reports/FY92-124 names a file pub/reports/FY92-124 belonging to the organizational unit accounts.finance.
org/accounts.finance/service/calendar names the calendar service of the organizational unit accounts.finance. This might manage the meeting schedules of the organizational unit.
Site names are created as needed. The types of objects that may be named relative to a site name are: user, host, service and fs. For example:
site/alameda/user/mjones names a user mjones at the site alameda.
site/alameda/host/sirius names a machine sirius at the site alameda.
site/alameda/service/printer/Sparc-2 names the printer Sparc-2 at the site alameda.
site/alameda/fs/usr/dist names a file directory usr/dist available in the site alameda.
User names correspond to names in the corresponding passwd table in NIS+, the passwd map in NIS, or the /etc/passwd file under files. A user's file context is obtained from his or her passwd entry.
The types of objects that may be named relative to a user name are: service, and fs. For example:
user/chou/service/fax names the fax service of the user chou.
user/esperanza/fs/projects/conf96.doc names the file conf96.doc in the projects subdirectory of the user esperanza's file system.
Host names correspond to names in the corresponding hosts table in NIS+, the hosts map in NIS, or the /etc/hosts file under files. The host's file context corresponds to the files systems exported by the host.
The types of objects that may be named relative to a host name are: service, and fs. For example:
host/smtp-1/service/mailbox names the mailbox service associated with the machine smtp-1.
host/deneb/fs/etc/.cshrc names the file .cshrc in the /etc directory on the host deneb.
Service names correspond to, and are determined by, service applications. The service context must be named relative to an organization, user, host, or site context. For example:
org//service/printer names the organization's printer service.
host/deneb/service/printer names the printer service associated with the machine deneb.
host/deneb/service/printer/Sparc-2 names the printer associated with the machine deneb.
user/charlie/service/calendar names the user charlie's calendar service.
site/conf_pine.bldg-7.alameda/service/calendar names the calendar service for the conf_pine conference room in Building 7 at the Alameda site.
File system names correspond to file names. For example:
host/altair/fs/etc/.login names the .login file on the machine altair.
user/prasad/fs/projects/96draft.doc names the file 96draft.doc in the user prasad's projects directory.
To begin using FNS with your underlying name service, you run the fncreate command.
The fncreate command recognizes the underlying naming service in which FNS contexts are to be created (such as, NIS+, NIS, or files). To specify a specific naming service, you must run the fnselect command as explained in "Designating a Non-Default Naming Service", below.
By default:
If fncreate is executed on a machine that is an NIS+ client or server, the FNS namespace will be set up in NIS+. (See Solaris Naming Setup and Configuration Guide if you want or need to designate some other machine as an FNS NIS+ master server.)
If the machine is an NIS client, the namespace will be set up in NIS.
If the machine is neither, the namespace will be set up in the machine's /var/fn directory. When your underlying naming system is files-based, the common practice is to create /var/fn by running fncreate on each machine. It is possible however to create /var/fn on one machine and export it by NFS to be mounted by other clients.
You can also explicitly specify a non-default target naming service by using the fnselect command. For example the following command selects the target naming service to be NIS.
# fnselect nis |
Once the naming service has been selected either using the default policy or explicitly via fnselect, you can execute the following command to create the FNS namespace:
# fncreate -t org org// |
This creates all the necessary contexts for users and hosts in the corresponding naming service.
When your primary enterprise-level naming service is NIS+, take into account the following points.
The command syntax shown above creates the FNS namespace for the root NIS+ domain. To specify a domain other than the root, add the domain name between the double slashes, as in:
# fncreate -t org org/sales.doc.com./ |
Note the trailing dot after the fully qualified sales.doc.com. domain name.
The fncreate commands creates NIS+ tables and directories in the ctx_dir directory. The ctx_dir directory object resides at the same level as the NIS+ groups_dir and org_dir directory objects of the domain.
With a large domain, the additional space required on the NIS+ server could be substantial and in a large installation performance might be improved by using separate servers for FNS and the standard NIS+ tables. See Solaris Naming Setup and Configuration Guide for information on how to use separate servers for FNS and NIS+.
In a large, or mission-critical domain, FNS service should be replicated. See Solaris Naming Setup and Configuration Guide for information on how to replicate FNS service.
The user who runs fncreate and other FNS commands is expected to have the necessary NIS+ credentials.
The environment variable NIS_GROUP
specifies the group owner for the NIS+ objects created by fncreate. In order to facilitate
administration of the NIS+ objects, NIS_GROUP
should be set
to the name of the
NIS+ group responsible for FNS administration for that domain prior to executing fncreate
and other FNS commands.
Changes to NIS+ related properties, including default access control rights, could be effected using NIS+ administration tools and interfaces after the context has been created. The NIS+ object name that corresponds to an FNS composite name can be obtained using fnlookup and fnlist, described later in this document.
The fncreate command must be executed by superuser on the NIS system that will serve as the NIS master server for the FNS maps.
The NIS maps used by FNS are stored in /var/yp/domainname.
Any changes to the FNS information can only be done by the superuser on the FNS NIS master server using FNS commands.
When using fncreate with the -t org option to create your FNS namespace, the command must be executed by superuser on the machine that owns the file system on which /var is located. The files used by FNS are stored in the /var/fn directory.
Once users' contexts are created, users are allowed to modify their own contexts based on their UNIX credentials.
If exported, the file system /var/fn can be mounted by other systems to access the FNS namespace.
Once the namespace has been set up, you can browse using the following commands:
fnlist to list context contents (see "Listing Context Contents" below)
fnlookup to display the bindings of a composite name (see "Displaying the Bindings of a Composite Name").
fnattr to show the attributes of a composite name (see "Showing the Attributes of a Composite Name").
The fnlist command displays the names and references bound in the context of name.
fnlist [-lvA] [name] |
Option |
Description |
---|---|
name |
A composite name. Displays the names bound in the context of name |
-v |
Verbose. Displays the binding in more detail |
-l |
Also displays the bindings of the names bound in the named context |
-A |
Forces fnlist to obtain its information from the authoritative server. Under NIS and NIS+, that is the domain master server. The -A option has no effect when the primary naming service is files. |
For example:
To list names in the initial context:
% fnlist |
To list in detail all the users in the current organizational unit:
% fnlist -v user |
To list the contents of the service context for the user pug:
% fnlist user/pug/service |
To list names and bindings from the authoritative server:
% fnlist -l -A |
The fnlookup command shows the binding of the given composite name.
fnlookup [-vAL] [name] |
Option |
Description |
---|---|
name |
The name of a context. Displays the binding and XFN link of name |
-v |
Verbose. Displays the binding in more detail |
-L |
Also displays the XFN link that the name is bound to |
-A |
Forces fnlist to obtain its information from the authoritative server. Under NIS and NIS+, that is the domain master server. The -A option has no effect when the primary naming service is files-based. |
For example: to display the binding of user/ana/service/printer:
# fnlookup user/ana/service/printer |
The fnattr command displays (and updates) the attributes of the given composite name.
For example, to search for the attributes associated with a user named ada:
# fnattr user/ada |
To search for the attributes associated with a printer named laser-9:
# fnattr thisorgunit/service/printer/laser-9 |
See "Working With Attributes" for more details.
The fnsearch command displays the names and, optionally, the attributes and references of objects bound at or below a composite name whose attributes satisfy the given search criteria.
For example:
To list the users and their attributes who have an attribute called realname:
% fnsearch user realname |
To list the users with the attribute realname whose value is Ravi Chattha:
% fnsearch user "realname == 'Ravi Chattha'" |
The fnsearch command uses the common Boolean operators. Note the use of double and single quotes and double equals sign in the above example.
Once the namespace has been set up, you can add, delete, and modify elements using the following commands:
fnbind to bind new references to a composite name (see "Binding a Reference to a Composite Name", below).
fnunbind to remove bindings (see "Removing Bindings").
fncreate to create new organization, user, host, site, and service contexts (see "Creating New Contexts").
fncreate_fs to create new file system contexts (see "Creating File Contexts").
fncreate_printer to create new printer contexts (see "Creating Printer Contexts").
fndestroy to destroy contexts (see "Destroying Contexts").
fnattr to display, create, modify, and remove attributes (see "Working With Attributes").
fncopy to copy FNS contexts and attributes from one naming service to another (see "Copying and Converting FNS Contexts").
FNS System administration varies according to the underlying naming service:
NIS+. Under NIS+, FNS system administration tasks can only be performed by those with authorization to do so. The usual method of granting system administration privileges is to create an NIS+ group and assign that group the necessary privileges for that domain. Any member of the group can then perform system administration functions.
NIS. Under NIS, FNS administration tasks must be performed by root on the NIS master server.
Files. Under a files-based naming system, FNS administration tasks must be performed by someone with root access to the /var/fn directory.
The ability of users to make changes to their own user sub-contexts varies according to the underlying naming service:
NIS+. Under NIS+, a user's context (and associated sub-contexts) are owned by them. When logged in as an NIS+ principle, users who have the appropriate credentials and privileges can make changes to their own context using the fncreate, fnbind, fnunbind, and similar commands.
NIS. Under NIS, users cannot make any changes to any FNS data. Only those with root access on the NIS master server can change FNS data.
Files. Under a files-based naming system, users own their own contexts. Standard UNIX access controls apply to FNS files.
The fnbind command is used to bind an existing reference (name) to a new composite name.
fnbind -r [-s][-v][-L] name [-O|-U] newname reftype addrtype [-c|-x] address |
Option |
Description |
---|---|
name |
The existing composite name |
newname |
The composite name of the new binding |
addrtype |
Address type to use. Applications-specific such as onc_cal_str. |
address |
Address contents to use. For example, tsvi@altair. |
reftype |
Reference type to use. Applications-specific such as one_calendar. |
-s |
Bind to newname even if it is already bound. This replaces the previous binding of newname. Without -s, fnbind fails if newname is already bound. |
-v |
Display the reference that will be bound to newname. |
-L |
Create an XFN link using oldname and bind it to newname. |
-r |
Bind newname to the reference constructed by the command line arguments. |
-c |
Store address contents in the form as entered, do not use XDR-encoding. |
-x |
Convert address to a hexadecimal string without converting it to XDR-encoding. |
-O |
The identifier format is FN_ID_ISO_OID_STRING, an ASN.1 dot-separated integer list string. |
-U |
The identifier format is FN_ID_DCE_UUID, a DCE UUID in string form. |
For example:
To add a calendar binding for the user jamal:
# fnbind -r user/jamal/service/calendar onc_calendar onc_cal_str jamal@cygnus |
To replace the existing binding of org//service/Sparc-4 with that of org//service/printer:
# fnbind -s org//service/printer org//service/Sparc-4 |
To copy the reference site/bldg-5/service/printer to user/ando/service/printer:
# fnbind site/bldg-5/service/printer user/ando/service/printer |
To bind the reference site/bldg-5/service/printer to user/ando/service/printer using a symbolic link:
# fnbind -L site/bldg-5/service/printer user/ando/service/printer |
To bind the name thisens/service/calendar to the address staff@altair, when staff@altair is a reference of the type onc_cal and an address of the type onc_cal_str:
# fnbind -r thisens/service/calendar onc_calendar onc_cal_str staff@altair |
To bind newname to the reference constructed by its command line address
# fnbind -r [-sv] newname [-O|-U] reftype {[-O|-U] addrtype [-c|-x] address} |
The fnunbind name command is used to remove bindings.
For example: to remove the binding for user/jsmith/service/calendar:
# fnunbind user/jsmith/service/calendar |
The fncreate command is used to create contexts.
fncreate -t context [-f file] [-o] [-r reference] [-s] [-v] [-D] name |
Option |
Description |
---|---|
-t context |
Create context of type context. Context types can be: org, hostname, host, username, user, service, fs, site, nsid, and generic. |
-f file |
Use an input file to list users and hosts for whom to create contexts. |
-r reference |
Type of reference. The -r reference option can only be used with -t generic. |
name |
A composite name |
-o |
Create only the context identified by name. |
-s |
Overwrite (supersede) any existing binding. If -s is not used, fncreate will fail if name is already bound. |
-D |
Display information about each context and corresponding tables, directories, and files as it is created. |
-v |
Verbose. Display information about each context as it is displayed. |
For example:
To create a context and subcontexts for the root organization:
# fncreate -t org org// |
To create a context, and subcontexts, for the host deneb:
# fncreate -t host host/deneb |
To create a context, service and file subcontexts, and then add a calendar binding for the user sisulu:
# fncreate -t user user/sisulu # fnbind -r user/sisulu onc_calendar onc_cal_str sisulu@deneb |
To create a site context for the sales organization:
# fncreate -t site org/sales/site/ |
The site context supports a hierarchal namespace, with dot-separated right-to-left names, which allows sites to be partitioned by their geographical coverage relationships. For example, to create a site context alameda and a site subcontext bldg-6.alameda for it:
# fncreate -t site org/sales/site/alameda # fncreate -t site org/sales/site/bldg-6.alameda |
The fncreate_fs command creates file contexts for organizations and sites with the description of the binding entered from the command line.
fncreate_fs [-r] [-v] name [options] [mount] |
The fncreate_fs command creates file contexts for organizations and sites with the description of the bindings supplied by an input file.
fncreate_fs [-r] [-v] -f file name |
Option |
Description |
---|---|
name |
The name of the file context |
options |
Mount options |
mount |
Mount location |
-f file |
Input file |
-v |
Verbose. Displays information about the contexts being created |
-r |
Replace the bindings in the context name with those specified in the input. |
For example:
To create a file system context named data for the sales organization bound to the /export/data path of an NFS server named server4.
# fncreate_fs org/sales/fs/data server4:/export/data |
To create a hierarchy of file system contexts for the sales organization named buyers and buyers/orders mounted on two different servers:
# fncreate_fs org/sales/fs/buyers server2:/export/buyers # fncreate_fs org/sales/fs/buyers/orders server3:/export/orders |
To create a file system context named leads for the sales organization bound to a server and path specified by an input file named input_a:
# fncreate_fs -f input_a org/sales/fs/leads |
(See the fncreate_fs man page for information on input file format.)
The fncreate_printer command creates printer contexts for organizations, users, hosts and site contexts. The printer context is created under the service context of the respective composite name.
fncreate_printer [-vs] name printer [prntaddr] |
fncreate_printer [-vs] [-f [file]] name |
Option |
Description |
---|---|
name |
The name of the org, host, user, or site of the printer |
printer |
The name of the printer |
prntaddr |
The printer address in the form <addresstype>=<address> |
-f file |
Use the named file as input for a list of printers to be created. The input file is in the format of the /etc/printers.conf file. If neither a printer name nor a -f file is specified, fncreate_printer uses the /etc/printer.conf file on the machine where fncreate_printer is run as a default input file. |
-s |
Replace an existing address with the same address-type. |
-v |
Verbose. Displays the binding in more detail |
For example:
To create printers for the sales organization based on the printers listed in the /etc/printers.conf file of the machine on which fncreate_printer is run:
# fncreate_printer -s org/sales/ |
Assume that the machine altair is the server for a printer named Sparc-5. To create a printer named invoices for the user nguyen that is actually the Sparc-5 printer:
# fncreate_printer user/nguyen invoices bsdaddr=altair,Sparc-5 |
It is also possible to organize printers hierarchically. For example, the fncreate_printer command can create printer contexts for the printers, color, color/inkjet and color/Sparc with the resulting contexts:
org/doc.com/service/printer/color org/doc.com/service/printer/color/inkjet org/doc.com/service/printer/color/Sparc |
To create the above contexts, you would run:
# fncreate_printer org/doc.com color bsdaddr=colorful,color # fncreate_printer org/doc.com color/inkjet bsdaddr=colorjet,inkjet # fncreate_printer org/doc.com color/Sparc bsdaddr=colorprt,Sparc |
The fndestroy command is used to destroy empty contexts.
For example, to destroy the service context of the user patel:
# fndestroy user/patel/service |
The fnattr command can be used to add, delete or modify attributes associated with a name. You can make modifications one at a time, or batch several within the same command.
fnattr [-l] name to list attributes for name.
fnattr name -a-s -U -O attrib values to add an attribute
fnattr name -m -O -U attrib oldvalue newvalue to modify an attribute
fnattr name -d -O | -U [values attrib] to destroy an attribute
Option |
Description |
---|---|
name |
The composite name |
attrib |
The identifier of an attribute |
values |
One or more attribute values |
oldvalue |
An attribute value to be replaced by a new value |
newvalue |
The attribute value that replaces an old value |
-a |
Add an attribute |
-d |
Destroy an attribute |
-l |
List attributes |
-m |
Modify an attribute |
-s |
Replace all old attribute values with the new values for the attribute specified. |
-O |
The identifier format is FN_ID_ISO_OID_STRING, an ASN.1 dot-separated integer list string. |
-U |
The identifier format is FN_ID_DCE_UUID, a DCE UUID in string form. |
For example:
To show all of the attributes associated with the user name rosa:
# fnattr user/rosa |
To display the size attribute associated with the user uri:
# fnattr user/uri/ size |
For a user named devlin, to add an attribute named shoesize with a value of small, delete the hatsize attribute, and change the dresssize attribute value from 12 to 8:
# fnattr user/devlin -a shoesize small -d hatsize -m dresssize 12 8 |
You can federate NIS+ or NIS to a global naming service like DNS and X.500.
To federate an NIS+ or NIS namespace under DNS or X.500, you first need to obtain the root reference for the NIS+ hierarchy or NIS domain.
From the point of view of the global name service, the root reference is known as the next naming system reference because it refers to the next naming system beneath the DNS domain or X.500 entry. To federate NIS+ or NIS with a global name service, you add the root reference information to that global service.
Once you have added the root reference information to the global service, clients outside of your NIS+ hierarchy or NIS domain can access and perform operations on the contexts in the NIS+ hierarchy or NIS domain. Foreign NIS+ clients access the hierarchy as unauthenticated NIS+ clients.
For example:
If NIS+ is federated underneath the DNS domain doc.com, you can now list the root of the NIS+ enterprise using the command
# fnlist .../doc.com/ |
If NIS+ is federated underneath the X.500 entry /c=us/o=doc, you can list the root of the NIS+ enterprise using the command:
# fnlist .../c=us/o=doc/ |
Note the mandatory trailing slash in both examples.
The fncopy command can be used to copy or convert an FNS context and attributes to a new FNS context.
By using the -i and -o options, you can copy FNS contexts based on one underlying enterprise-level name service to a context based on a different underlying name service. For example, if you have an FNS installation running on top of NIS, and you upgrade your NIS service to NIS+, you can use fncopy to create a new context using NIS+.
Note that:
If the new FNS context that you are copying an old context to already exists for the target name service, only new contexts and bindings are copied. The contexts are not over-written or changed
fncopy does not follow links, but copies the FNS link bound to a name to the new context namespace.
Option |
Description |
---|---|
-i oldservice |
The old (input) underlying enterprise-level name service. For example, -i nis specifies that the old service is NIS. Allowed values are files, nis, nisplus. |
-o newservice |
The new (output) underlying enterprise-level name. For example, o nisplus specifies that the new service is NIS+. Allowed values are files, nis, nisplus. |
-f filename |
A text file listing FNS contexts to be copied. In the absence of the -i and -o options, contexts must be identifies using global names. |
oldcontext |
The name of the context being copied |
newcontext |
The name of the context being created or copied to. |
For example, to copy the doc.com printer contexts (and sub-contexts) and bindings to orgunit/east/doc.com:
# fncopy .../doc.com/service/printer .../doc.com/orgunit/east/service/printer |
To copy the NIS FNS users' contexts specified in the file user_list to a NIS+ FNS users' context of the orgunit west/doc.com:
# fncopy -i nis -o nisplus -f /etc/user_list thisorgunit/user org/doc.com/user |
The programming examples in this section shows the usage of XFN APIs to perform the following operations:
The example below shows XFN operations to list a context.
#include <stdio.h> #include <xfn/xfn.h> #include <string.h> #include <stdlib.h> /* This routine returns the list of names bound under the given context (ctx_name). Examples of ctx_name are "user", "thisorgunit/service", host/alto/service, user/jsmit/service/calendar, etc., */ typedef struct fns_listing { char *name; struct fns_listing *next; } fns_listing; fns_listing * fns_list_names(const char *ctx_name) { FN_status_t *status; FN_ctx_t *initial_context; FN_composite_name_t *context_name; FN_namelist_t *name_list; FN_string_t *name; unsigned int stat; fns_listing *head = 0, *current, *prev; int no_names = 0; status = fn_status_create(); /* Obtain the initial context */ initial_context = fn_ctx_handle_from_initial(0, status); if (!fn_status_is_success(status)) { fprintf(stderr, "Unable to obtain intial context\n"); return (0); } context_name = fn_composite_name_from_str((unsigned char *) ctx_name); /* FNS call to list names */ name_list = fn_ctx_list_names(initial_context, context_name, status); if (!fn_status_is_success(status)) { fprintf(stderr, "Unable to list names\n"); return (0); } /* Obtain the names individually */ while (name = fn_namelist_next(name_list, status)) { no_names++; current = (fns_listing *) malloc(sizeof(fns_listing)); current->name = (char *) malloc(strlen((char *) fn_string_str(name, &stat)) + 1); strcpy(current->name, (char *) fn_string_str(name, &stat)); current->next = 0; if (head) { prev->next = current; prev = current; } else { head = current; prev = current; } fn_string_destroy(name); } fn_namelist_destroy(name_list); fn_status_destroy(status); fn_ctx_destroy(initial_context); return (head); |
The example below shows how to create a binding.
#include <stdio.h> #include <xfn/xfn.h> #include <string.h> /* This routine creates a binding with a name provided by "name" and having a reference type "reference_type" and address type "address_type". An example of using the function could be: fns_create_bindings( "user/jsmith/service/calendar", "onc_calendar", "onc_cal_str", "jsmith&calserver"); */ int fns_create_bindings( char *name, char *reference_type, char *address_type, char *data) { int return_status; FN_composite_name_t *binding_name; FN_identifier_t ref_id, addr_id; FN_status_t *status; FN_ref_t *reference; FN_ref_addr_t *address; FN_ctx_t *initial_context; /* Obtain the initial context */ status = fn_status_create(); initial_context = fn_ctx_handle_from_initial(0, status); /* Check status for any error messages */ if ((return_status = fn_status_code(status)) != FN_SUCCESS) { fprintf(stderr, "Unable to obtain the initial context\n"); return (return_status); } /* Get the composite name for the printer name */ binding_name = fn_composite_name_from_str((unsigned char *) name); /* Construct the Address */ addr_id.format = FN_ID_STRING; addr_id.length = strlen(address_type); addr_id.contents = (void *) address_type; address = fn_ref_addr_create(&addr_id, strlen(data), (const void *) data); /* Construct the Reference */ ref_id.format = FN_ID_STRING; ref_id.length = strlen(reference_type); ref_id.contents = (void *) reference_type; reference = fn_ref_create(&ref_id); /* Add Address to the Reference */ fn_ref_append_addr(reference, address); /* Create a binding */ fn_ctx_bind(initial_context, binding_name, reference, 0, status); /* Check the error status and return */ return_status = fn_status_code(status); fn_composite_name_destroy(binding_name); fn_ref_addr_destroy(address); fn_ref_destroy(reference); fn_ctx_destroy(initial_context); return (return_status); } |
The examples below show techniques to list and work with attributes of an object.
The example below shows how to list the attributes of an object.
#include <stdio.h> #include <xfn/xfn.h> /* This routine prints all the attributes associated with the named object to the standard output. Examples of using the function: fns_attr_list("user/jsmith"); fns_attr_list("thisorgunit/service/printer/color"); */ void fns_attr_list(const char *name) { FN_composite_name_t *name_comp; const FN_identifier_t *identifier; FN_attribute_t *attribute; const FN_attrvalue_t *values; char *id, *val; FN_multigetlist_t *attrset; void *ip; FN_status_t *status; FN_ctx_t *initial_context; name_comp = fn_composite_name_from_str((unsigned char *) name); status = fn_status_create(); /* Obtain the initial context */ initial_context = fn_ctx_handle_from_initial(0, status); if (!fn_status_is_success(status)) { fprintf(stderr, "Unable to obtain intial context\n"); return; } /* Obtain all the attributes */ attrset = fn_attr_multi_get(initial_context, name_comp, 0, 0, status); if (!fn_status_is_success(status)) { fprintf(stderr, "Unable to obtain attributes\n"); return; } /* List all attributes */ while (attribute = fn_multigetlist_next(attrset, status)) { identifier = fn_attribute_identifier(attribute); switch(identifier->format) { case FN_ID_STRING: id = (char *) malloc(identifier->length + 1); memcpy(id, identifier->contents, identifier->length); id[identifier->length] = '\0'; printf("Attribute Identifier: %s", id); free(id); break; default: printf("Attribute of non-string format\n\n"); continue; } for (values = fn_attribute_first(attribute, &ip); values != NULL; values = fn_attribute_next(attribute, &ip)) { val = (char *) malloc(values->length + 1); memcpy(val, values->contents, values->length); val[values->length] = '\0'; printf("Value: %s", val); free(val); } fn_attribute_destroy(attribute); printf("\n"); } fn_multigetlist_destroy(attrset); fn_ctx_destroy(initial_context); fn_status_destroy(status); fn_composite_name_destroy(name_comp); } |
The example below shows how to add, delete, or modify an object's attributes.
#include <stdio.h> #include <xfn/xfn.h> /* This routine modifies an attribute associated with the named object. The modify operation supported are: FN_ATTR_OP_ADD FN_ATTR_OP_ADD_EXCLUSIVE FN_ATTR_OP_REMOVE FN_ATTR_OP_ADD_VALUES FN_ATTR_OP_REMOVE_VALUES The function assumes the attribute values to be strings. Examples of using the function: The following function add an attribute of identifier "realname" with value "James Smith" to the user object "user/jsmith". fns_attr_modify( "user/jsmith", "realname", "James Smith", FN_ATTR_OP_ADD); The following function removes an attribute of identifier "location" from the printer object "thisorgunit/service/printer/color". fns_attr_modify( "thisorgunit/service/printer/color", "location", NULL, FN_ATTR_OP_REMOVE); */ static const char *attr_id_syntax = "fn_attr_syntax_ascii"; void fns_attr_modify(const char *name, const char *attr_id, const char *attr_value, unsigned int operation) { FN_composite_name_t *name_comp; FN_identifier_t identifier, syntax; FN_attrvalue_t *values; FN_attribute_t *attribute; FN_status_t *status; FN_ctx_t *initial_context; name_comp = fn_composite_name_from_str((unsigned char *) name); status = fn_status_create(); /* Obtain the initial context */ initial_context = fn_ctx_handle_from_initial(0, status); if (!fn_status_is_success(status)) { fprintf(stderr, "Unable to obtain intial context\n"); return; } /* Create the attribute to be added */ /* First, the identifier */ identifier.format = FN_ID_STRING; identifier.length = strlen(attr_id); identifier.contents = (void *) strdup(attr_id); /* Second, the syntax */ syntax.format = FN_ID_STRING; syntax.length = strlen(attr_id_syntax); syntax.contents = (void *) strdup(attr_id_syntax); /* Third, the attribute value */ if (attr_value) { values = (FN_attrvalue_t *) malloc(sizeof(FN_attrvalue_t)); values->length = strlen(attr_value); values->contents = (void *) strdup(attr_value); } else values = NULL; /* Fourth, create the attribute */ attribute = fn_attribute_create(&identifier, &syntax); /*Fifth, add the attribute value */ if (values) fn_attribute_add(attribute, values, 0); /* Perform the XFN operation */ fn_attr_modify(initial_context, name_comp, operation, attribute, 0, status); if (!fn_status_is_success(status)) fprintf(stderr, "Unable to perform attribute operation\n"); fn_ctx_destroy(initial_context); fn_status_destroy(status); fn_composite_name_destroy(name_comp); fn_attibute_destroy(attribute); free(identifier.contents); free(syntax.contents); if (values) { free(values->contents); free(values); ] ] |
The example below shows how to search for objects in a context with a specific attribute identifier and value.
#include <stdio.h> #include <xfn/xfn.h> #include <string.h> #include <stdlib.h> /* This routine searchs for objects in a context which has the specified attribute identifier and value. */ typedef struct fns_search_results { char *name; struct fns_search_results *next; } fns_search_results; static const char *attr_id_syntax = "fn_attr_syntax_ascii"; fns_search_results * fns_attr_search(const char *name, const char *attr_id, const char *attr_value) { FN_status_t *status; FN_ctx_t *initial_context; FN_composite_name_t *context_name; FN_searchlist_t *search_list; FN_string_t *search_name; FN_attribute_t *attribute; FN_attrset_t *attrset; FN_identifier_t identifier, syntax; FN_attrvalue_t *values; unsigned stat; fns_search_results *head = 0, *current, *prev; int no_names = 0; context_name = fn_composite_name_from_str((unsigned char *) name); status = fn_status_create(); initial_context = fn_ctx_handle_from_initial(0, status); if (!fn_status_is_success(status)) { fprintf(stderr, "Unable to obtain intial context\n"); return (0); } /* Construnct the attrset with attributes to be searched */ /* First, the identifier */ identifier.format = FN_ID_STRING; identifier.length = strlen(attr_id); identifier.contents = (void *) strdup(attr_id); /* Second, the syntax */ syntax.format = FN_ID_STRING; syntax.length = strlen(attr_id_syntax); syntax.contents = (void *) strdup(attr_id_syntax); /* Third, the attribute value */ values = (FN_attrvalue_t *) malloc(sizeof(FN_attrvalue_t)); values->length = strlen(attr_value); values->contents = (void *) strdup(attr_value); /* Fourth, create the attribute */ attribute = fn_attribute_create(&identifier, &syntax); /* Fifth, add the attribute value */ fn_attribute_add(attribute, values, 0); /* Sixth, create attrset, and add the attribute */ attrset = fn_attrset_create(); fn_attrset_add(attrset, attribute, 0); search_list = prelim_fn_attr_search(initial_context, context_name, attrset, 0, 0, status); if (!fn_status_is_success(status)) { fprintf(stderr, "Unable to list names\n"); return (0); } while (search_name = prelim_fn_searchlist_next(search_list, 0, 0, status)) { no_names++; current = (fns_search_results *) malloc(sizeof(fns_search_results)); current->name = (char *) malloc(strlen((char *) fn_string_str(search_name, &stat)) + 1); strcpy(current->name, (char *) fn_string_str(search_name, &stat)); current->next = 0; if (head) { prev->next = current; prev = current; } else { head = current; prev = current; } fn_string_destroy(search_name); } fn_searchlist_destroy(search_list); fn_status_destroy(status); fn_ctx_destroy(initial_context); fn_attrset_destroy(attrset); fn_attribute_destroy(attribute); free(identifier.contents); free(syntax.contents); free(values->contents); free(values); return (head); } |
This chapter describes the Federated Naming Service (FNS) which is Sun's implementation of the X/Open XFN federated naming standard.
Different name services are often embedded in different applications and services in a computing environment. Working with different name services presents significant difficulties to the application developer. Most applications are designed to use a single name service and have very limited access to objects in a distributed computing environment. Because different applications use different name services they expect names to be composed differently. They often use different names for what the user considers very similar objects. For example, you might be able to send mail to your friend Johanna using her name johanna@admin.doc.com, but be required to use another name, jsmith@altair, to access her calendar.
FNS, Sun's implementation of the XFN standard, allows you to name objects in a uniform way, yet still provide the functionality that applications and developers need.
XFN is X/Open Federated Naming. XFN is a standard actively supported by organizations such as SunSoft, Inc., IBM, Hewlett-Packard, DEC, Siemens, and OSF. FNS, the Solaris 2.6 release implementation of XFN, is compliant with the X/Open Preliminary Specification for Federated Naming (July 1994). Applications that use FNS are portable across platforms because the interface exported by FNS is XFN, a public, open interface endorsed by other vendors and X/Open. The X/Open Co. Ltd. is an international standards organization committed to defining computing standards that are endorsed and adhered to by the major computer vendors.
FNS provides a method for federating multiple name services under a single, simple uniform interface for the basic naming operations. The service supports resolution of composite names--names that span multiple name systems-- through the naming interface. Each member of a federation has autonomy in its choice of naming conventions, administrative interfaces, and its particular set of operations other than name resolution.
In the Solaris environment, the FNS implementation consists of a set of enterprise-level name services (see "Solaris Enterprise-Level Naming Services") with specific policies and conventions for naming organizations, users, hosts, sites, and services as well as support for global name services (see "Global Naming Services") such as DNS and X.500.
FNS is useful for the following reasons:
A single uniform naming interface is provided to clients for accessing different name services. As a consequence, the addition of new name services does not require changes to applications or to existing member name services.
Names can be composed in a uniform way, and the resulting composite names can have any number of components.
Coherent naming is encouraged through the use of shared contexts and shared names.
In this manual it is important to distinguish between XFN and FNS. The FNS policies include some extensions to XFN policies, and these are explicitly defined with notes. Objects belonging to the XFN programming interface are designated as XFN objects to avoid confusion with other programming interfaces.
This section describes the XFN naming model from several perspectives.
The primary services provided by a federated naming system are mapping a composite name to a reference and providing access to attributes associated with a named object. This section defines the elements of the XFN naming model.
The smallest, indivisible component of a name is called an atomic name. For example, the machine name nismaster or the user name chou. An atomic name may have one or more attributes, or no attributes at all (see "Attributes").
A reference is the information on how to reach an object. A reference contains a list of addresses. An address identifies a communication endpoint (an object). For example, the address of a machine such as nismaster.doc.com, or a user's email address such as chou@doc.com.
A reference might contain multiple addresses that identify multiple communication endpoints for a single conceptual object or service. For example, a list of addresses might be required because the object is distributed or because the object can be accessed through more than one communication mechanism.
XFN cannot guarantee specific properties of addresses such as their stability, validity, or reachability. A client might be able to look up a name but not be able to use the returned reference because the client might not have support for any of the necessary communication mechanisms or might lack the necessary network connectivity to reach the address. Further, the address might be invalid from that origin or stale; these issues are the province of the convention between the name's binder, the clients, and the service provider specified in the address.
A context is a set of atomic names bound to references, as shown in Figure 20-1. Every context has an associated naming convention. A context provides a lookup (resolution) operation, which returns the reference, and may provide operations such as binding names, unbinding names, and listing bound names. Contexts are at the heart of the lookup and binding operations.
Attributes may be applied to named objects. Attributes are optional. A named object can have no attributes, one attributes, or multiple attributes.
Each attribute has a unique attribute identifier, an attribute syntax, and a set of zero or more distinct attribute values. Attributes are indicated by the dotted lines in Figure 20-1 above.
XFN defines the base attribute interface for examining and modifying the values of attributes associated with existing named objects. These objects can be contexts or any other types of objects. Associated with a context are syntax attributes that describe how the context parses compound names.
The extended attribute interface contains operations that search for specific attributes and that create objects and their associated attributes.
A compound name is a sequence of one or more atomic names. An atomic name in one context can be bound to a reference to another context of the same type, called a subcontext. Objects in the subcontext are named using a compound name. Compound names are resolved by looking up each successive atomic name in each successive context.
A familiar analogy for UNIX users is the file naming model, where directories are analogous to contexts, and path names serve as compound names. Furthermore, contexts can be arranged in a "tree" structure, just as directories are, with the compound names forming a hierarchical namespace.
For example:
UNIX: usr/local/bin. UNIX atomic names are ordered from left to right and are delimited by slash (/) characters. The name usr is bound to a context in which local is bound. The name local is bound to a context in which bin is bound.
DNS: sales.doc.com. DNS atomic names are ordered from right to left, and are delimited by dot (.) characters. The domain name com is bound to a context in which doc is bound. doc is bound to a context in which sales is bound.
X.500: c=us/o=doc/ou=sales. An X.500 atomic name comprises an attribute type and an attribute value. Atomic names are known as relative distinguished names in X.500. In this string representation, X.500 atomic names are ordered from left to right, and are delimited by slash (/) characters. An attribute type is separated from an attribute value by an equal sign (=) character. Abbreviations are defined for commonly used attribute types (for example, "c" represents country name). The country name US is bound to a context in which doc is bound. The organization name doc is bound to a context in which the organizational unit name sales is bound.
A composite name is a name that spans multiple naming systems. Each component is a name from the namespace of a single naming system. Composite name resolution is the process of resolving a name that spans multiple naming systems.
Components are separated by slashes (/) and ordered from left to right, according to XFN composite name syntax. For example, the composite name
sales.doc.com/usr/local/bin
has two components, a DNS name (sales.doc.com) and a UNIX path name (usr/local/bin).
Atomic names and reference addresses may also be resolved relative to one or more namespaces. By default, FNS provides six namespaces: org (for organization), site, host, user, service, and fs (for files).
FNS policies are used to determine how names associated with namespaces relate to each other. For example; a user is named sergei in the user namespace and is identified as /user/sergei. A calendar application is named in the service namespace and is identified as /service/calendar. With this system, you can then identify Sergei's calendar service as: /user/sergei/service/calendar. (See "Introduction to FNS and XFN Policies" for more information on namespaces and how they are used.)
If an application is expecting you to type a user name, the application can include the namespace identifier user/ in front of names that you enter. If the application needs to name one of the user's services, such as the user's default fax machine, it can append the service namespace and the name of the service (/service/fax), to the input supplied. Hence, a fax tool might take as input the user name jacques and then compose the full name user/jacques/service/fax for the default fax of the user jacques. Similarly, to access a person's calendar, you just need to type the person's user name. The application takes the input, raj, and uses it to construct the composite name, in this case, user/raj/service/calendar.
An XFN link is a special form of a reference that is bound to an atomic name in a context. Instead of an address, a link contains a composite name. Many naming systems support a native notion of link that can be used within the naming system itself. XFN does not specify whether there is any relationship between such native links and XFN links.
Every XFN name is interpreted relative to some context, and every XFN naming operation is performed on a context object. The initial context object provides a starting point for the resolution of composite names. The XFN interface provides a function that allows the client to obtain an initial context.
The policies described in Chapter 21, FNS Policies, specify a set of names that the client can expect to find in this context and the semantics of their bindings. This provides the initial pathway to other XFN contexts.
Users experience federated naming through applications. Typically, the user does not need to compose or know the full composite name of objects because the application takes care of constructing the composite names. This allows the user to interact with XFN-aware applications in a simple, intuitive, and consistent manner.
Users and applications also experience federated naming through the file system. The initial context is located under /xfn in the root directory. For example, user ingrid's to_do file has the XFN name, xfn/user/ingrid/fs/to_do.
To read this file, you could type:
% cat /xfn/user/ingrid/fs/to_do |
Applications access the files under /xfn just as they do any other files. Applications do not need to be modified in any way, nor do they need to use the XFN API.
The way that client applications interact with XFN to access different naming systems is illustrated in a series of figures. Figure 20-2 shows an application that uses the XFN API and library.
Figure 20-3 shows the details beneath the API. A name service that is federated is accessed through the XFN client library and a context shared object module. This module translates the XFN calls into name service-specific calls.
Many clients of the XFN interface are only interested in lookups. Their usage of the interface amounts to:
Obtaining the initial context
Looking up one or more names relative to the initial context
Once the client obtains a desired reference from the lookup operation, it constructs a client-side representation of the object from the reference.
Within the Solaris environment, name services are integrated into other services such as the file system, the network information service, the mail system, and the calendar service. For example, the file system includes a naming system for files and directories; NIS+ service combines a naming system with a specialized information service.
Without FNS, users of the Solaris environment must use different, inconsistent names to refer to objects. For example: you might use the name jsmith@admin to send mail to Joan, the name jsmith@altair to access her calendar, and the name /home/jsmith/.cshrc to reach a file in her home directory. This disparity makes it hard for users to formulate names and hard for applications to automatically generate names on behalf of users. FNS policies define a coherent way for naming these objects.
Applications also need naming services and applications in the Solaris environment must often deal with a diversity of name service interfaces. An application might also be exposed to a variety of often incompatible naming systems external to the Solaris environment. Local- and wide-area networks connect a heterogeneous array of hardware and operating systems, increasing the variety of potential interfaces. Not only do these naming interfaces differ widely, but the essential naming operations are often obscure.
FNS simplifies these problems in two ways:
It provides a single standard interface to the basic naming functions that developers can use for their applications.
It permits changes or additions to network name services without changing existing applications.
Some applications use composite names to access objects in the Solaris environment. The commands mail and rcp are examples of such applications.
rcp uses composite names such as sirius:/usr/jsmith/memo, which has two components: the host name sirius and the file name (path) /usr/jsmith/memo. The mail program uses composite names such as jsmith@altair, which has two components: the user name jsmith and the host name altair.
Each application defines its own composition rule for names, parses the composite names, and resolves composite names. Composition rules often differ from one application to another.
Without FNS, the user must remember which applications permit composite naming and which do not. For example, the composite name sirius:/tmp/saleslist is accepted by the rcp command, but not by the cp command.
Without FNS, the user must also remember the different composition rules used among different applications. Applications that support composite names on their own can use only a small and specific set of naming systems, and must be changed whenever a new type of naming system is added.
Incorporating a uniform policy for composite naming into the computing platform permits any application to support composite names in a uniform way. The application passes one name to one interface.
The following principles were used to arrive at FNS policies:
When it is natural to name other objects relative to a certain object, that object should provide a naming context. For example, because it is natural to want to name various things relative to a user, a user object should be a naming context.
It should be possible to compose names using common components. This reduces the number of names that users need to remember and makes it easier for applications and users to construct names based on their knowledge of common components and how they can be logically composed.
Names should be intuitive and self-evident. For example, the FNS name /user/wong/service/calendar clearly identifies the calendar service used by Wong. In contrast, the calendar name wong@deneb names the host (deneb) where the calendar service for Wong is being provided. But to other users, there is no obvious connection between the user's calendar and a host. The host name is extraneous and difficult to discover and remember.
Never use two contexts when one context will do. In the example above, we would like to name a mail address, a calendar, and a file's directory relative to the user wong. Sharing contexts and their names make naming more coherent and simplifies administration.
In the Solaris environment, the FNS implementation currently consists of name services implemented on top of:
Enterprise-level name services such NIS+, NIS, and/or local files. (See "Solaris Enterprise-Level Naming Services", below.)
File naming, printer naming, and support for other applications. (see Chapter 24, Administering File Contexts.)
Global-level naming systems using DNS and X.500/LDAP. (See Chapter 25, FNS and Global Naming Systems.)
FNS will become increasingly more visible to Solaris users as more applications and systems use FNS.
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 22, FNS and Enterprise Name Services, for administration information regarding FNS and enterprise-level naming services.
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.
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.
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.
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.
A global naming service identifies (names) those enterprise-level networks around the world that are linked together via phone, satellite, or other communication systems. This world-wide collection of linked networks is known as the "Internet." In addition to naming networks, a global naming service also identifies individual machines and users within a given network.
FNS currently supports two global naming services:
DNS. See "FNS and DNS", below and "Federating Under DNS".
X.500/LDAP. See "FNS and X.500", below and "Federating Under X.500/LDAP".
You can only federate a global naming service if your enterprise-level name service is NIS+ or NIS. If you are using a files-based name service for your enterprise, you cannot federate either DNS or X.500/LDAP.
See Chapter 25, FNS and Global Naming Systems, for administration information regarding FNS and enterprise-level naming services.
The Internet Domain Name System (DNS) is a hierarchical collection of name servers that provide the world Internet with host and domain name resolution. FNS uses DNS to name enterprise objects globally.
A domain name is the name DNS uses to identify an enterprise-level network (LAN or WAN). Networks using NIS+ permit creation of subdomains within the parent domain, and DNS can identify such subdomains.
Names can be constructed for any enterprise that is accessible on the Internet; consequently, names can also be constructed for objects exported by these enterprises. For more information about FNS and DNS, see "Federating Under DNS".
X.500 is a global directory service. Its components cooperate to manage information about objects in a worldwide scope. Such objects include countries, organizations, people, and machines. FNS federates X.500 to enable global access to enterprise name services. You can choose to use one of two APIs to access the X.500 global directory service:
XDS/XOM API
LDAP (Lightweight Directory Access Protocol) API.
See "Federating Under X.500/LDAP" for information on federating X.500.
FNS supports:
Solaris NFS file service (see "FNS File Naming", below).
Printer naming (see "FNS Printer Naming").
Other applications (see "FNS Application Support").
FNS-based file naming integrates FNS naming into the Solaris file service. FNS-based file naming enables files to be named relative to users, hosts, sites, and organizations, using the FNS policies shared with other non-file applications.
FNS-based file naming gives clients a common view of the global and enterprise-wide file namespaces. Solaris applications that access the file system will, without modification, have access to the file namespaces supported by FNS.
FNS-based printer naming provides the basic naming support for the unbundled SunSoft Print Client (SSPC). FNS-based printer naming enables printers to be named relative to users, hosts, sites, and organizations, using the FNS policies shared with other non-printing-related applications.
FNS-based printer naming gives clients a common view of the global and enterprise-wide printer namespaces and allows centralized administration of the printer namespaces.
Applications that are aware of FNS can expect the namespace to be arranged according to the FNS policies, and applications that bind names in the FNS namespace are expected to follow these policies.
Applications use FNS three ways:
Applications can be direct clients of the FNS interface and policies. Application-level utilities such as the file system, the printing service, and the desktop tools (calendar manager, file manager) are examples of clients that use the FNS interface directly.
Applications can use FNS through existing interfaces. A significant proportion of FNS use is through existing application programming interfaces. For example, consider a UNIX application that obtains a file name that it later supplies to the UNIX open() function. With FNS support for resolution of file names, the application need not be aware that the strings it deals with are composite names rather than the traditional local path names. Many applications can thereby support the use of composite names without modification.
Systems can export the FNS interface. Naming systems, such as DNS and X.500, and naming systems embedded in other services, like the file system and printing service, are examples of naming systems that export the FNS interface.
FNS System administration varies according to the underlying naming service:
NIS+. Under NIS+, FNS system administration tasks can only be performed by those with authorization to do so. The usual method of granting system administration privileges is to create an NIS+ group and assign that group the necessary privileges for that domain. Any member of the group can then perform system administration functions.
NIS. Under NIS, FNS administration tasks must be performed by root on the NIS master server.
Files. Under a files-based naming system, FNS administration tasks must be performed by someone with root access to the /var/fn directory.
The ability of users to make changes to their own user sub-contexts varies according to the underlying naming service:
NIS+. Under NIS+, a user's context (and associated sub-contexts) are owned by them. When logged in as an NIS+ principle, users who have the appropriate credentials and privileges can make changes to their own context using the fncreate, fnbind, fnunbind, and similar commands.
NIS. Under NIS, users cannot make any changes to any FNS data. Only those with root access on the NIS master server can change FNS data.
Files. Under a files-based naming system, users own their own contexts. Standard UNIX access controls apply to FNS files.
For troubleshooting common FNS problems and solving them, see "FNS Problems and Solutions". FNS error messages are included in Appendix B, Error Messages.
This chapter describes FNS policies.
XFN defines policies for naming objects in the federated namespace. The goals of these policies are
To allow easy and uniform composition of names
To promote coherence in naming across applications and services
To provide a simple, yet sufficiently rich, set of policies so that applications need not invent and implement ad hoc policies for specific environments
To enhance an application's portability
To promote cross-platform interoperability in heterogeneous computing environments
FNS policies contain all the XFN policies plus extensions for the Solaris environment.
Computing environments now offer worldwide scope and a large range of services. Users expect to have access to services at every level of the computing environment. FNS policies provide a common framework for the three levels of services: global, enterprise, and application.
FNS provides to applications a set of policies on how name services are arranged and used:
Policies that specify how to federate the enterprise namespace so that it is accessible in the global namespace.
Policies that specify the names and bindings present in the initial context of every process.
Name service policies for enterprise objects: organizations, hosts, users, sites, files, and services.
Policies that define the relationships among the organization, host, user, site, files, and service enterprise objects.
Policies that specify the syntax of names used to refer to those enterprise objects.
The FNS policies do not specify:
The actual names used within name services.
Naming within applications. Application-level naming is left to individual applications or groups of related applications.
The attributes to use once the object has been named.
FNS policies specify the types and arrangement of namespaces within an enterprise and how such namespaces can be used by applications. For example, which namespaces can be associated with which other namespaces. The FNS policies described here include some extensions to XFN policy. These are explicitly defined with notes.
The FNS enterprise policies deal with the arrangement of enterprise objects within the namespace. Each enterprise objects has its own namespace.
By default, there are seven FNS enterprise objects and namespaces:
Organization (orgunit). Entities such as departments, centers, and divisions. Sites, hosts, users, and services can be named relative to an organization. The XFN term for organization is organizational unit. When used in an initial context the identifier org can be used as an alias for orgunit.
Site (site). Physical locations, such as buildings, machines in buildings, and conference rooms within buildings. Sites can have files and services associated with them.
Host (host). Machines. Hosts can have files and services associated with them.
User (user). Human users. Users can have files and services associated with them.
Service (service). Services such as printers, faxes, mail, and electronic calendars.
Printer (service/printer). The printer namespace is subordinate to the service namespace.
Figure 21-1 shows how these enterprise namespaces are arranged.
Some of these namespaces, such as users and hosts, can appear more than once in a federated namespace.
The policies that apply to these namespaces are summarized in Table 21-2.
Enterprise namespaces are referred to by their atomic names in the federated enterprise namespace.
XFN uses leading underscore ("_") characters to indicate an enterprise namespace identifier. For example, _site. FNS also supports the use of these identifiers without the leading underscore ("_") character. These names without the underscore are extensions to the XFN policies. The site and printer contexts are also extensions to the XFN policies. These atomic names are listed in Table 21-1.
Table 21-1 Enterprise Namespace Identifiers in the Enterprise
Namespace |
XFN Identifiers |
FNS Identifiers |
Resolves to |
---|---|---|---|
Organization |
_orgunit |
orgunit or org |
Context for naming organizational units |
Site |
_site |
site |
Context for naming sites |
Host |
_host |
host |
Context for naming hosts |
User |
_user |
user |
Context for naming users |
File system |
_fs |
fs |
Context for naming files |
Service |
_service |
service |
Context for naming services |
Printer |
|
printer |
Context for naming printers, (subordinate to service namespace) |
In XFN terminology, the names with the leading underscore are the canonical namespace identifiers. The names without the underscore are namespace identifies that have been customized for the Solaris environment. These customized namespace identifiers, with the addition of printer, might not be recognized in non-Solaris environments. The canonical namespace identifiers are always recognized and so are portable to other environments.
The XFN component separator (/) delimits namespace identifiers. For example, composing the namespace identifier orgunit with the organizational unit name west.sales gives the composite name, orgunit/west.sales.
There are seven namespaces supplied with FNS:
Organization. (See "Organizational Unit Namespace")
Site. (See "Site Namespace")
Host. (See "Host Namespace")
User. (See "User Namespace")
File. (See "File Namespace")
Service. (See "Service Namespace")
Printer. (See "Service Namespace")
The organizational unit namespace provides a hierarchical namespace for naming subunits of an enterprise. Each organizational unit name is bound to an organizational unit context that represents the organizational unit. Organization unit names are identified by the prefixes org/, orgunit/, or _orgunit/. (The shorthand alias org/ is only used in the initial context, never in the middle of a compound name. See "Initial Context Bindings for Naming Within the Enterprise" and "Composite Name Examples".)
In an NIS+ environment, organizational units correspond to NIS+ domains and subdomains.
Under NIS+, organization units must map to domains and subdomains. You must have an organizational unit for each NIS+ domain and subdomain. You cannot have "logical" organization units within a domain or subdomain. In other words, you cannot divide an NIS+ domain or subdomain into smaller organization units. Thus, if you have a NIS+ domain doc.com. and two subdomains sales.doc.com. and manf.doc.com., you must have three FNS organizational units corresponding to those three domains.
Organizational units are named using dot-separated right-to-left compound names, where each atomic element names an organizational unit within a larger unit. For example, the name org/sales.doc.com. names an organizational unit sales within a larger unit named doc.com. In this example, sales is an NIS+ subdomain of doc.com.
Organizational unit names can be either fully qualified NIS+ domain names or relatively named NIS+ names. Fully qualified names have a terminal dot; relative names do not. Thus, if a terminal dot is present in the organization name, the name is treated as a fully qualified NIS+ domain name. If there is no terminal dot, the organization name is resolved relative to the top of the organizational hierarchy. For example, orgunit/west.sales.doc.com. is a fully qualified name identifying the west organization unit, and _orgunit/west.sales is a relatively qualified name identifying the same subdomain.
In a NIS environment there is only one organization unit per enterprise which corresponds to the NIS domain. This orgunit is named orgunit/domainname where domainname is the name of the NIS domain. For example, if the NIS domain name is doc.com, the organizational unit is org/doc.com.
In an NIS environment, you can use an empty string as a shorthand for the organizational unit. Thus, org// is equivalent to org/domainname.
There is only one FNS organization unit and no subunits when your primary enterprise-level name service is files-based. The only permitted organization unit under files-based naming is org//.
The site namespace provides a geographic namespace for naming objects that are naturally identified with their physical locations. These objects can be, for example, buildings on a campus, machines and printers on a floor, conference rooms in a building and their schedules, and users in contiguous offices. Site names are identified by the prefixes site/or _site/.
In the Solaris environment, sites are named using compound names, where each atomic part names a site within a larger site. The syntax of site names is dot-separated right-to-left, with components arranged from the most general to the most specific location description. For example, _site/pine.bldg5 names the Pine conference room in building 5, while site/bldg7.alameda identifies building 7 of the Alameda location of some enterprise.
The host namespace provides a namespace for naming computers. Host names are identified by the prefixes host/or _host/. For example, host/deneb identifies a machine named deneb.
Hosts are named in hostname contexts. The host context has a flat namespace and contains bindings of host names to host contexts. A host context allows you to name objects relative to a machine, such as files and printers found at that host.
In the Solaris environment, host names correspond to Solaris host names. Alias names for a single machine share the same context. For example, if the name mail_server is an alias for the machines deneb and altair, both deneb and altair will share the contexts created for mail_server.
Network resources should only be named relative to hosts as appropriate. In most cases, it is more intuitive to name resources relative to entities such as organizations, users, or sites. Dependence on host names forces the user to remember information that is often obscure and sometimes not very stable. For example, a user's files might move from one host to another because of hardware changes, file space usage, network reconfigurations, and so on. And users often share the same file server, which might lead to confusion if files were named relative to hosts. Yet if the files were named relative to the user, such changes do not affect how the files are named.
There might be a few cases in which the use of host names is appropriate. For example, if a resource is available only on a particular machine and is tied to the existence of that machine, and there is no other logical way to name the resource relative to other entities, then it might make sense to name the resource relative to the host. Or, in the case of a file system, if the files are being shared by many users it might make sense to name them relative to the machine they are stored on.
The user namespace provides a namespace for naming human users in a computing environment. User names are identified by the prefixes user/or _user/.
Users are named in user contexts. The user context has a single-level namespace and contains bindings of user names to user contexts. A user context allows you to name objects relative to a user, such as files, services, or resources associated with the user.
In the Solaris environment, user names correspond to Solaris login IDs. For example, _user/inga identifies a user whose login ID is inga.
A file namespace (or file system) provides a namespace for naming files. File names are identified by the prefixes fs/or _fs/. For example the name fs/etc/motd identifies the file motd which is stored in the /etc directory.
The file namespace is described in more detail in "FNS File Naming". and file contexts are discussed in "File Contexts Administration"
The service namespace provides a namespace for services used by or associated with objects within an enterprise. Examples of such services are electronic calendars, faxes, mail, and printing. Service names are identified by the prefixes service/ or _service/.
In the Solaris environment, the service namespace is hierarchical. Service names are slash-separated (/) left-to-right compound names. An application that uses the service namespace can make use of this hierarchical property to reserve a subtree for that application. For example, the printer service reserves the subtree printer in the service namespace.
FNS does not specify how service names or reference types are chosen. These are determined by service providers that share the service namespace. For example, the calendar service uses the name _service/calendar in the service context to name the calendar service and what is bound to the name calendar is determined by the calendar service.
SunSoft, Inc., maintains a registry of the names bound in the first level of the service namespace. To register a name, send an email request to fns-register@sun.com, or write to:
FNS Registration Sun Microsystems, Inc. 2550 Garcia Avenue Mountain View, CA 94043
Please include a brief description of the intended use of the name and a description of the format of the reference that can be bound to that name.
The printer namespace provides a namespace for naming printers. The printer namespace is associated with (subordinate to) the service namespace. In other words, printer service and the printer namespace is one of the services in the service namespace. Printer names are identified by the prefixes service/printer or _service/printer. For example, service/printer/laser1 identifies the printer named laser1.
The trailing / names objects in the next naming system. You need it whenever you are going from one naming system to another.
For example, in the name, org/east.sales/service/printer the slash between org and east.sales is a component delimiter as described above and the slash that trails after the last element in the organization name (sales/) separates the service namespace from the organizational unit namespace. Thus, org/west.sales/service/printer names the printer service of the west.sales organization unit.
FNS reserves for its own use all the atomic names listed in Table 21-1 as namespace identifiers. For example: _orgunit, org, _site, site, and so forth. This limitation applies to contexts in which the namespace identifiers can appear, as defined by the arrangement of namespaces in "Structure of the Enterprise Namespace". FNS does not otherwise restrict the use of these atomic names in other contexts.
For example, the atomic name service is used as a namespace identifier relative to a user name, as in user/fatima/service/calendar, to mean the root of user fatima's service namespace. This does not preclude a system from using the name service as a user name, as in user/service, because FNS specifies that the context to which the name user/ is bound is for user names and not for namespace identifiers. In this case, service is unambiguously interpreted as a user name. On the other hand, you should not create a directory named user because /user/mikhail would cause confusion between the user mikhail and the file (or subdirectory) /user/mikhail.
This section shows examples of names that follow FNS policies. (See Table 21-2 for a summary of these policies.)
The specific choices of organization names, site names, user names, host names, file names, and service names (such as calendar and printer) are illustrative only; these names are not specified by FNS policy.
The namespaces that can be associated with the organization namespace (_orgunit, orgunit, or org) are: user, host, service, fs, and site.
For example:
orgunit/doc.com/site/videoconf.bldg-5 names a conference room videoconf located in Building 5 of the site associated with the organization doc.com. (You can also use the alias org for orgunit to form, org/doc.com/site/videoconf.bldg-5.)
orgunit/doc.com/user/mjones names a user mjones in the organization doc.com.
orgunit/doc.com/host/smptserver1 names a machine smptserver1 belonging to the organization doc.com.
orgunit/doc.com/fs/staff/agenda9604/ names a file staff/agenda9604 belonging to the organization doc.com.
orgunit/doc.com/service/calendar names the calendar service for the organization doc.com. This might manage the meeting schedules for the organization.
The namespaces that can be associated with the user namespace are service and fs.
user/helga/service/calendar names the calendar service of a user named helga.
user/helga/fs/tasklist names the file tasklist under the home directory of the user helga.
The namespaces that can be associated with the hosts namespace are service and fs.
host/mailhop/service/mailbox names the mailbox service associated with the machine mailhop.
host/mailhop/fs/pub/saf/archives.96 names the directory pub/saf/archives.96 found under the root directory of the file system exported by the machine mailhop.
The namespaces that can be associated with the sites namespace are service and fs.
site/bldg-7.alameda/service/printer/speedy names a printer speedy in the bldg-7.alameda site.
site/alameda/fs/usr/dist names a file directory usr/dist available in the alameda site.
No other namespaces can be associated with either the files (fs) or services (service) namespaces. For example, you cannot compose a name such as /services/calendar/orgunit/doc.com. In other words, you cannot compose a compound name relative to either the files or the service namespace. You can, of course, compose a file or service name relative to some other namespace such as /user/esperanza/service/calendar.
FNS policies define the structure of the enterprise namespace. The purpose of this structure is to allow easy and uniform composition of names. This enterprise namespace structure has two main rules:
Objects with narrower scopes are named relative to objects with wider scopes.
Namespace identifiers are used to denote the transition from one namespace to the next.
Table 21-2 is a summary of FNS policies for arranging the enterprise namespace. Figure 21-2 shows an example of a namespace layout that follows these FNS policies.
Table 21-2 Policies for the Federated Enterprise Namespace
Namespace Identifiers |
Subordinate Namespaces |
Parent Context |
Namespace Organization |
Syntax |
---|---|---|---|---|
orgunit _orgunit org |
Site, user, host, file system, service |
Enterprise root |
Hierarchical |
Dot-separated right-to-left |
site _site |
Service, file system |
Enterprise root, organizational unit |
Hierarchical |
Dot-separated right-to-left |
user _user |
Service, file system |
Enterprise root, organizational unit |
Flat |
Solaris login name |
host _host |
Service, file system |
Enterprise root, organizational unit |
Flat |
Solaris host name |
service _service |
Application specific |
Enterprise root, organizational unit, site, user, host |
Hierarchical |
/ separated left-to-right |
fs
_fs |
None |
Enterprise root, organizational unit, site, user, host |
Hierarchical |
/ separated, left-to-right |
printer |
None |
Service |
Hierarchical |
/ separated left-to-right |
The namespace of an enterprise is structured around a hierarchy of organizational units. Names of sites, hosts, users, files, and services can be named relative to names of organizational units by composing the organizational unit name with the appropriate namespace identifier and object name.
In Figure 21-2, a user myoko in the west division of the sales organization of an enterprise is named using the name orgunit/west.sales/user/myoko.
Note the use of the namespace identifier user to denote the transition from the orgunit namespace to the user namespace. In a similar fashion (with the use of appropriate namespace identifiers), names of files and services can also be named relative to names of sites, users, or hosts. Names of sites can be named relative to organizational unit names.
The goal of easy and uniform composability of names is met using this structure. For example, once you know the name for an organizational unit within an enterprise (for example, orgunit/west), you can name a user relative to it by composing it with the user namespace identifier and the user's login name to yield a name such as orgunit/west/user/josepha.
To name a file in this user's file system, you can use a name like orgunit/west/user/josepha/fs/notes.
The root context of an enterprise, is a context for naming objects found at the root level of the enterprise namespace. Enterprise roots are bound in the global namespace.
There are two ways of naming the enterprise root:
.../rootdomain.
org//.
You can use .../rootdomain/ to identify an enterprise root where:
The initial three dots (...) are an atomic name indicating the global context (see "Policies for the Global Namespace" for a description of the global context).
rootdomain/ is the enterprise root domain. For example, doc.com/.
Thus, .../doc.com/ identifies the enterprise root of a company whose root domain is doc.com. In this example, the context for naming sites associated with the enterprise root is .../doc.com/site/ such as .../doc.com/site/alameda or .../doc.com/site/alameda.bldg5.
You can only use the .../rootdomain format if you have set up the global binding in DNS.
You can use org// to identify an enterprise root. In essence, org// is an alias or functional equivalent for .../domainname/. When using org//, the double slashes identifies the root enterprise context and namespaces associated with it.
For example, org//site/alameda names the Alameda site associated with the enterprise root.
In contrast, org/ or orgunit/ (with a single slash) points to an organizational context which is not necessarily named relative to the enterprise root. For example, org/sales/site/alameda.
The following objects can be named relative to the enterprise root:
Organizational units in that enterprise
Sites in the top organizational unit of the enterprise (an extension to XFN policies)
Users in the top organizational unit of the enterprise
Hosts in the top organizational unit of the enterprise
Services for the top organizational unit of the enterprise
File service for the top organizational unit of the enterprise
These objects are named by composing the namespace identifier of the target object's namespace with the name of the target object.
Organizational subunits can be named relative to the enterprise root.
Given an organization root name, you can compose names for its subordinate organizational unit contexts by using one of the namespace identifiers, orgunit or _orgunit.
For example, if .../doc.com is the name of an enterprise, the root of the context for naming organizational units is .../doc.com/orgunit/, and organizational unit names look like .../doc.com/orgunit/sales and .../doc.com/orgunit/west.sales. Or, you could achieve the same result with org//orgunit/sales.
The following objects can be named relative to an organizational unit name:
Sites for that organizational unit (an extension to the XFN policies)
Hosts in that organizational unit
Users in that organizational unit
Services for that organization unit
File service for that organizational unit
For example, the name ...doc.com/orgunit/sales/service/calendar, identifies the calendar service of the sales organizational unit. (See "Organizational Unit Namespace" and "Composing Names Relative to Organizations "for a more detailed description of naming objects relative to organization units.)
Sites are an extension to the XFN policies.
Sites can be named relative to
The enterprise root
An organizational unit
Sites named relative to the enterprise root are the same as sites named relative to the top organizational unit. Given an organization name, you can compose a name for its site context by using one of the namespace identifiers, site or _site. For example, if the enterprise root is ../doc.com the context for naming sites relative to the enterprise root is ../doc.com/site. Sites would have names like ../doc.com/site/alameda.
The following objects can be named relative to a site name:
Services at the site, such as the site schedule or calendar, printers, and faxes
The file service available at the site
These objects are named by composing the site name with the namespace identifier of the target object's namespace and the name of the target object. For example, the name site/Clark.bldg-5/service/calendar names the calendar service of the conference room Clark.bldg-5 and is obtained by composing the site name site/Clark.bldg-5 with the service name service/calendar. (See "Composing Names Relative to Sites " for a more detailed description of naming objects relative to sites.)
Users can be named relative to
An organizational unit
The enterprise root
Users named relative to the enterprise root are the same as users named relative to the top organizational unit. Given an organization name, you can compose a name for its username context by using one of the namespace identifiers, user or _user. Thus, if orgunit/east.sales names an organization, then orgunit/east.sales/user/hirokani names a user hirokani in the east.sales organizational unit.
The following objects can be named relative to a user name:
Services associated with the user
The user's files
These objects are named by composing the user's name with the namespace identifier of the target object's namespace and the name of the target object. For example, the name user/sophia/service/calendar names the calendar for the user sophia. (See "User Namespace" and "Enterprise Root and Users" for more information on the user namespace and naming objects relative to users.)
Hosts can be named relative to
An organizational unit
The enterprise root
Hosts named relative to the enterprise root are the same as hosts named relative to the top organizational unit. Given an organization name, you can compose a name for its hostname context by appending one of the namespace identifiers, host or _host. Thus if orgunit/west.sales names an organization, the name org/west.sales/host/altair names a machine altair in the west.sales organizational unit.
The following objects can be named relative to a host name:
Services associated with the host
Files exported by the host
These objects are named by composing the host name with the namespace identifier of the target object's namespace and the name of the target object. For example, the name host/sirius/fs/release names the file directory release being exported by the machine sirius. (See "Host Namespace" and "Composing Names Relative to Hosts " for more information on the host namespace and naming objects relative to hosts.)
A service can be named relative to
An organizational unit
The enterprise root
A user
A host
A site
Services named relative to the enterprise root are the same as services named relative to the top organizational unit.
A service context is named by using the namespace identifiers service or _service, relative to the organization, site, user, or host with which it is associated. For example, if orgunit/corp.finance names an organizational unit, then orgunit/corp.finance/service/calendar names the calendar service of the organizational unit corp.finance. (See "Service Namespace" and "Composing Names Relative to Services and Files " for more information on the user namespace and naming objects relative to users.)
FNS does not restrict the types of bindings in the service namespace. Applications can create contexts of a type other than service contexts and bind them in the service namespace.
FNS supports the creation of generic contexts in the service context. A generic context is similar to a service context except that a generic context has an application-determined reference type. All other properties of a generic context are the same as a service context.
For example, a company named World Intrinsic Designs Corp (WIDC), reserves the name extcomm in the service namespace to refer to a generic context for adding bindings related to its external communications line of products. The context bound to extcomm is a generic context, with reference type WIDC_comm. The only difference between this context and a service context is that this context has a different reference type.
Service names should be registered with SunSoft, Inc., as directed in "Service Name and Reference Registration".
A file namespace can be named relative to
The enterprise root
An organizational unit
A user
A host
A site
Files named relative to the enterprise root are the same as files named relative to the top organizational unit. A file context is named by using the namespace identifiers fs or _fs, relative to the organization, site, user, or host with which it is associated. For example, if orgunit/accountspayable.finance names an organizational unit, then the name user/jsmith/fs/report96.doc names her file report96.doc. The file service of the user defaults to her home directory, as specified in the NIS+ passwd table. (See "File Namespace" for more information on the user namespace.)
There can be no other type of context subordinate to a file system.
The printer context is an extension of XFN policies.
A printer namespace can be named in the service context. A printer context is named by using the namespace identifier, printer, in the service context relative to
An organizational unit
A user
A host
A site
For example, if org/east.sales names an organizational unit, then org/eastsales/service/printer names the printer service of the organizational unit east.sales. Thus, an individual printer named lp1 would be identified as: org/east.sales/service/printer/lp1.
There can be no other type of context subordinate to a printer.
An initial context is the starting place from which client users, hosts, and applications can (eventually) name any object in the enterprise namespace.
Figure 21-3 shows the same naming system as the one shown in Figure 21-2, except that the initial context bindings are shaded and shown in italics. These initial contexts are shown from the point of view of the user, host, or application asking for a name to be resolved.
XFN provides an initial context function, fn_ctx_handle_from_initial(), that allows a client to obtain an initial context object as a starting point for name resolution. The initial context has a flat namespace for namespace identifiers. The bindings of these initial context identifiers are summarized in Table 21-3 and are described in more detail in subsequent sections. Not all of these names need to appear in all initial contexts. For example, when a program is invoked by the superuser, only the host and client-related bindings appears in the initial context, none of the user-related bindings appear.
Table 21-3 Initial Context Bindings for Naming Within the Enterprise
Namespace Identifier |
Binding |
---|---|
myself, _myself, thisuser |
The context of the user who is trying to resolve a name. |
myens, _myens |
The enterprise root of the user who is trying to resolve a name. |
myorgunit, _myorgunit |
The user's primary organizational unit context. For example, in an NIS+ environment, the primary organizational unit is the user's NIS+ home domain. |
thishost, _thishost |
The context of the host that is trying to resolve a name. |
thisens, _thisens |
The enterprise root of the host that is trying to resolve a name. |
thisorgunit, _thisorgunit |
The host's primary organizational unit context. For example, in an NIS+ environment, the primary organizational unit is the host's NIS+ home domain |
user, _user |
The context in which users in the same organizational unit as the host are named |
host, _host |
The context in which hosts in the same organizational unit as the host are named |
org, orgunit, _orgunit |
The root context of the organizational unit namespace in the host's enterprise. For example, in an NIS+ environment, this corresponds to the NIS+ root domain |
site, _site |
The root context of the site namespace at the top organizational unit if the site namespace has been configured |
In XFN terminology, names with a leading underscore prefix are called the canonical namespace identifiers. The names without the leading underscore, with the additions of org and thisuser, are Solaris customizations. Solaris customized namespace identifiers are not guaranteed to be recognized in other, non-Solaris environments. The canonical namespace identifiers are always recognized and therefore portable to other environments.
The current implementations of FNS does not support the addition or modification of names and bindings in the initial context.
Initial context bindings fall into three basic categories:
User-related bindings (see "User-related Bindings")
Host-related bindings (see "Host-related Bindings")
"Shorthand" bindings (see ""Shorthand" Bindings")
FNS assumes that there is a user associated with a process when the XFN initial context function is invoked. This association is based on the effective user ID (euid) of the process. Although the association of user to process can change during the life of the process, the original context handle does not change.
FNS defines the following bindings in the initial context that are related to the user requesting name resolution.
The namespace identifier myself (or either synonym _myself or thisuser) in the initial context resolves to the user context of whomever is making the request. For example, if a process owned by the user jsmith requests name resolution, the name:
myself resolves in the initial context to jsmith's user context
myself/fs/.cshrc names the file .cshrc of jsmith
FNS assumes that each user is affiliated with an organizational unit of an enterprise. A user can be affiliated with multiple organizational units, but there must be one organizational unit that is primary, perhaps by its position in the organizational namespace or by the user's role in the organization.
NIS+. In an NIS+ namespace, this organizational unit corresponds to the user's home domain (which could be a subdomain).
NIS. In a NIS namespace, there is only one enterprise-level organizational unit which corresponds to the user's domain.
Files. In a files-based namespace, there is only one organizational unit, org// which maps to myorgunit.
The namespace identifier myorgunit (or _myorgunit) resolves in the initial context to the context of the primary organizational unit of the user making the request. For example, if the user making the request is jsmith, and jsmith's home domain is east.sales, then myorgunit resolves in the initial context to the organizational unit context for east.sales, and the name myorgunit/service/calendar resolves to the calendar service of east.sales.
FNS assumes that there is an association of a user to an enterprise. This corresponds to the namespace that holds myorgunit.
The namespace identifier myens (and _myens) resolves in the initial context to the enterprise root of the enterprise to which the user making the request belongs. For example, if jsmith is making the request, and jsmith's NIS+ home domain is east.sales, which in turn is in the NIS+ hierarchy with the root domain name of doc.com. The name myens/orgunit/ resolves to the top organizational unit of doc.com.
Be careful about set-user-ID programs when using user-related composite names, such as myorgunit or myself/service, because these bindings depend on the effective user ID of a process. For programs that set-user-ID to root to access system resources on behalf of the caller, it is usually a good idea to call seteuid(getuid()) before calling fn_ctx_handle_from_initial().
A process is running on a particular host when the XFN initial context function is invoked. FNS defines the following bindings in the initial context that are related to the host the process is running on.
The namespace identifier thishost (or _thishost) is bound to the host context of the host running the process. For example, if the process is running on the machine cygnus, thishost is bound to the host context of cygnus, and the name thishost/service/calendar refers to the calendar service of the machine cygnus.
FNS assumes that a host is associated with an organizational unit. A host can be associated with multiple organizational units, but there must be one that is primary. In an NIS+ namespace, this organizational unit corresponds to the host's home domain.
The namespace identifier thisorgunit (or _thisorgunit) resolves to the primary organizational unit of the host running the process. For example, if that host is the machine cygnus, and cygnus's NIS+ home domain is west.sales, then thisorgunit resolves to the organizational unit context for west.sales and the name thisorgunit/service/fax refers to the fax service of the organizational unit west.sales.
FNS assumes that there is an association of a host to an enterprise. This corresponds to the namespace that holds thisorgunit.
The namespace identifier thisens (or _thisens) resolves to the enterprise root of the host running the process. For example, under NIS+, if the host's home domain is sales.doc.com, then the name thisens/site/ resolves to the root of the site namespace of doc.com.
FNS defines the following "shorthand" bindings in the initial context to enable the use of shorter names to refer to objects in certain commonly referenced namespaces.
The namespace identifier user (or _user) is bound in the initial context to the username context in organizational unit of the host running the process. This allows other users in the same organizational unit to be named from this context.
From the initial context, the names user and thisorgunit/user resolve to the same context. For example, if the host running the process is a machine altair and altair is in the east.sales organizational unit, the name user/medici names the user medici in east.sales.
The namespace identifier host (or _host) is bound in the initial context to the hostname context organizational unit of the host running the process. This allows other hosts in the same organizational unit to be named from this context.
From the initial context, the names host and thisorgunit/host resolve to the same context. For example, if the host running the process is a machine named sirius and it is in the east.sales organizational unit, the name host/sirius names the machine sirius in the organizational unit east.sales.
The namespace identifier org (or orgunit, _orgunit) is bound in the initial context to the root context of the organization of the enterprise to which the host running the process belongs.
From the initial context, the names org and thisens/orgunit resolve to the same context. For example, if the host running the process is the machine aldebaran and aldebaran is in the enterprise doc.com., the name org/east.sales names the organizational unit east.sales in doc.com.
The namespace identifier site (or _site) is bound in the initial context to the root of the site naming system of the top organizational unit of the enterprise to which the host running the process belongs.
From the initial context, the names site and thisens/site resolve to the same context. For example, if the host running the process is the machine aldebaran and aldebaran is in the enterprise doc.com., the name site/pine.bldg-5 names a conference room, pine in building 5 of doc.com.
FNS provides a method for federating multiple naming services under a single, simple interface for basic naming operations. FNS is designed to work with three enterprise-level name services:
NIS+. See "How FNS Policies Relate to NIS+", below and "FNS and NIS+ Naming"
NIS. See "How FNS Policies Relate to NIS" and "FNS and NIS Naming"
Files. "How FNS Policies Relate to Files-Based Naming" and "FNS and Files-Based Naming"
FNS is also designed to work with applications such as printer and calendar service as described in "Target Client Applications of FNS Policies".
See "FNS and NIS+ Naming" for overview and background information relating to FNS and NIS+. If you are not familiar with NIS+ and its terminology, refer to Part 1 and Glossaryof this guide. You will find it helpful to be familiar with the structure of a typical NIS+ environment.
FNS stores bindings for enterprise objects in FNS tables which are located in domain-level org_dir NIS+ directories on NIS+ servers. FNS tables are similar to NIS+ tables. These FNS tables store bindings for the following enterprise namespaces:
Organization namespaces as described in "NIS+ Domains and FNS Organizational Units".
Hosts namespaces as described in "NIS+ Hosts and FNS Hosts ".
Users namespace as described in "NIS+ Users and FNS Users"
Sites namespace which allows you to name geographical sites relative to the organization, hosts, and users.
Services namespace which allows you to name services such a printer service and calendar service relative to the organization, hosts, and users.
FNS names organization, user, and host enterprise objects within NIS+ which is the preferred Solaris enterprise name service. An NIS+ domain is comprised of logical collections of users and machines and information about them, arranged to reflect some form of hierarchical organizational structure within an enterprise.
FNS is implemented on NIS+ by mapping NIS+ domains to FNS organizations. An organizational unit name corresponds to a NIS+ domain name and is identified using either the fully qualified form of its NIS+ domain name, or its NIS+ domain name relative to the NIS+ root. The top of the FNS organizational namespace is mapped to the NIS+ root domain and is accessed using the name org/ from the initial context.
In NIS+, users and hosts have a notion of a home domain. A host or user's home domain is the NIS+ domain that maintains information associated with them. A user or host's home domain can be determined directly using its NIS+ principal name. An NIS+ principal name is composed of the atomic user (login) name or the atomic host name and the name of the NIS+ home domain. For example, the user sekou with home domain doc.com. has an NIS+ principal name sekou.doc.com and the machine name vega has an NIS+ principal name vega.doc.com.
A user's NIS+ home domain corresponds to the user's FNS organizational unit. Similarly, a host's home domain corresponds to its FNS organizational unit.
The trailing dot in an organization name indicates that the name is a fully qualified NIS+ domain name. Without the trailing dot, the organization name is an NIS+ domain name to be resolved relative to the NIS+ root domain.
For example, if the NIS+ root domain is doc.com., with a subdomain sales.doc.com., the following pairs of names refer to the same organization:
Table 21-4 Example of Relative and Fully Qualified Organization Names Under NIS+
Relative Name |
Fully Qualified Name |
---|---|
org/ |
org/doc.com. |
org/sales |
org/sales.doc.com. |
The name org/manf. (with trailing dot) would not be found, because there is no NIS+ domain with just the manf. name.
Hosts in the NIS+ namespace are found in the hosts.org_dir table of the host's home domain. Hosts in an FNS organization correspond to the hosts in the hosts.org_dir table of the corresponding NIS+ domain. FNS provides a context for each host in the hosts table.
Users in the NIS+ namespace are listed in the passwd.org_dir table of the user's home domain. Users in an FNS organization correspond to the users in the passwd.org_dir table of the corresponding NIS+ domain. FNS provides a context for each user in the passwd table.
The FNS fncreate command creates FNS tables and directories in the NIS+ hierarchy associated with the domain of the host on which the command is run. In order to run fncreate, you must be an authenticated NIS+ principle with credentials authorizing you to Read, Create, Modify, and Destroy NIS+ objects in that domain. You will be the owner of the FNS tables created by fncreate. One way to obtain this authorization is to be a member of the NIS+ group that has administrator privileges in the domain.
The NIS_GROUP
environment
variable should be set to name of the NIS+ administration group for the domain
prior to running fncreate. You can specify whether or not
individual users can make changes to FNS data that relates to them.
See Chapter 6, Security Overview, for a description of NIS+ security.
See "FNS and NIS Naming" for overview and background information relating to FNS and NIS.
FNS provides the XFN interface for performing basic naming and attributes operations using NIS as the naming service.
FNS stores bindings for enterprise objects in FNS maps which are located in a /var/yp/domainname directory on the NIS master server (and NIS slave servers, if any). FNS maps are similar in structure and function to FNS maps. These NIS maps store bindings for the following enterprise namespaces:
Organization which provides a namespace for naming objects relative to an entire enterprise. When NIS is the underlying naming service, there is a single organizational unit context that corresponds to the NIS domain. This organization unit context is identified in FNS by the NIS domain name or an empty name which defaults to the machines NIS domain name.
Hosts namespace which correspond to the hosts.byname map of the NIS domain. FNS provides a context for each host in the hosts.byname map.
Users namespace which correspond to the passwd.byname map. FNS provides a context for each user in the passwd.byname map of the domain.
Sites namespace which allows you to name geographical sites relative to the organization, hosts, and users.
Services namespace which allows you to name services such as a printer service and calendar service relative to the organization, hosts, and users.
FNS provides contexts which allow other objects to be named relative to these five namespaces.
The FNS fncreate command creates the FNS maps in the /var/yp/domainname directory of a NIS master server. This can be the same machine that is master server for the NIS naming service, or it can be a different machine that functions as an FNS master server. (If there are slave servers, NIS pushes the FNS maps to them as part of its normal operation.) To run fncreate, you must be a privileged user on the server that will host the FNS maps. Individual users cannot make changes to FNS data.
See "FNS and Files-Based Naming" for overview and background information relating to FNS and files.
FNS provides the XFN interface for performing basic naming and attribute operations using local files as the naming service.
FNS stores bindings for enterprise objects in files which are located in a /var/fn directory which is normally NFS mounted on each machine. These FNS files store bindings for the following enterprise namespaces:
Organization which provides a namespace for naming objects relative to the entire enterprise. When local files are the underlying naming service, there is a single organizational unit context that represents the entire system. This organization unit context is always identified in FNS as org//.
Hosts namespace which correspond to the /etc/hosts file. FNS provides a context for each host in the /etc/hosts file.
Users namespace which correspond to the /etc/passwd file. FNS provides a context for each user in the /etc/passwd file.
Sites namespace which allows you to name geographical sites relative to the organization, hosts, and users.
Services namespace which allows you to name services such as a printer service and calendar service relative to the organization, hosts, and users.
FNS provides contexts which allow other objects to be named relative to these five namespaces.
The FNS fncreate command creates the FNS files in the /var/fn directory of the machine on which the command is run. To run fncreate, you must have super-user privileges on that machine. Based on UNIX user IDs, individual users are allowed to modify their own contexts, bindings, and attributes using FNS commands.
One goal of the FNS policies is to maintain coherence across the most commonly used tools, including the file system, the DeskSet tools, such as Calendar Manager, Print Tool, File Manager, and Mail Tool, and services that support these tools, such as RPC, email, and print subsystems.
Some of these examples are not currently implemented in the Solaris environment. They are listed here to illustrate how FNS can be used.
Calendars. Instead of using names of the form username@hostname to access someone's calendar, in most cases you simply supply a site, organization, or user's name. You should also be able to use composite names to name calendars. For example, when federated under FNS, names of the following form are acceptable to calendar manager:
bernadette
user/bernadette
site/pine.bldg-5 (calendar for Pine conference room)
org/sales (calendar for the sales organization)
Printing. Instead of naming a specific printer by its name, you should be able to name a printer relative to a user, site, or organization. For example:
ilych (ilych's default printer)
org/sales (an organization's default printer)
site/pine.bldg-5 (printer in the Pine conference room)
File access. You should be able to use composite names to name file systems and files. The automounter should use FNS to make resolution of composite names possible. For example, you should be able to use a file name like /xfn/user/baruch/fs/.cshrc to reference the .cshrc file for user baruch.
RPC. Instead of addressing services by their host name, program, and version numbers, you should be able to name the service using a composite name. For example, you should be able to name an RPC service relative to a user or an organization such as: user/hatori/service/rpc.
Mail - Similarly, composite names can be used to name mail destinations. You should be able to use names such as the following:
angus
user/angus
org/mlist (an organization's mailing list)
site/pine.bldg-5 (mailbox of the conference room coordinator)
Other desktop applications - You should be able to pass composite names to other desktop applications such as spreadsheets, document preparation tools, fax tools, and so on. Some of these applications attach their own namespace to the service namespace, thus becoming part of the FNS federation.
This is a description of how one application, a calendar service, could be modified to use FNS policies. This example illustrates how FNS composite names might be presented to and accepted from users.
The DeskSet's calendar service is typical of client-server applications. Calendar servers run on some set of machines and maintain the users' calendars. Calendar Manager (cm) runs on the desktop and contacts the appropriate server to obtain the calendars of interest.
The calendar service could benefit from FNS using a simple registry/lookup model as follows:
Binding - Upon startup, the server registers the calendars that it manages by binding a reference containing its own ONC+ RPC address (host, program, version) to the composite name for each calendar it manages, such as user/jsmith/service/calendar.
Lookup - When using cm, the user specifies another user's calendar simply by entering the user's name (for example, hirokani) or selecting it from a list of names previously entered. Given the user name hirokani, cm composes the composite name user/hirokani/service/calendar and uses this to look up the RPC address that it needs to communicate with the server that manages that calendar.
In the previous example, we used the name "calendar" to denote a calendar binding. The developers of the calendar service should register the name "calendar" with the FNS administrator, much as RPC programs are registered with the RPC administrator. Refer to "Service Name and Reference Registration".
The name "calendar" used here is an example. FNS policy does not specify the names of specific services.
The calendar service could take further advantage of FNS policy by allowing calendars to be associated with sites, organizations, and hosts, while still naming them in a uniform way. For example, by allowing calendars to be associated with a conference room (a site), the service can be used to "multibrowse" the conference room's calendar as well as a set of user calendars to find an available time for a meeting in that room. Similarly, calendars can be associated with organizations for group meetings and hosts for keeping maintenance schedules.
The cm calendar manager could simplify what the user needs to specify by following some simple steps.
cm uses a tool for accepting composite names from the user and constructing the name of the object whose calendar is of interest.
The object is the name of a user, a site, a host, or an organization. For example, the user might enter the name kuanda and the calendar manager generates the composite name user/kuanda. This tool could be shared amongst a group of DeskSet applications.
cm uses the XFN interface to compose this name with the suffix /service/calendar to obtain the name of the calendar.
This calendar name is then resolved relative to the process's initial context.
Continuing with the example, this results in the resolution of the name user/kuanda/service/calendar. Similarly, if the user enters the name of a site, pine.bldg-5, cm generates the name site/pine.bldg-5/service/calendar for resolution.
Other services such as printing and mail could take advantage of the FNS policies in a similar way.
Files may be named relative to users, hosts, organizations, and sites in FNS by appending the fs enterprise namespace identifier to the name of the object, and following this with the name of the file. For example, the file draft96 in the sales division's budget directory might be named org/sales/fs/budget/draft96.
The initial context is located under /xfn in the file system's root directory. Thus a user might view the file by typing
% more /xfn/org/sales/fs/budget/draft96 |
Existing applications can access this directory just as they would any other directory. Applications do not need to be modified in any way or use the XFN API.
NFS is Sun's distributed file system. The files associated with an object will generally reside on one or more remote NFS file servers. In the simplest case, the namespace identifier fs corresponds to the root of an exported NFS file system, as shown in Figure 21-4.
In contrast, an object's file system may be composed of multiple--and possibly overlapping--remote mounts, woven together into a "virtual" directory structure managed by FNS.
Figure 21-5 illustrates how this capability might be used to piece together an organization's file system from three separate file servers. The project directory, along with its lib subdirectory, resides on one file server, while the src subdirectory resides on another. Users and applications need not be aware of the use of multiple servers; they see a single, seamless namespace.
For efficiency, the automounter is used to mount FNS directories on demand. The default /etc/auto_master configuration file contains the line:
/xfn -xfn |
which tells the automounter that the FNS namespace is "mounted" under /xfn, as specified by XFN.
Since the automounter is used to mount directories named through FNS, the subdirectories of an FNS directory cannot be listed until they have been mounted. For example, suppose the file system of the sales organization is composed of multiple NFS file systems. The following ls command shows only two file systems that have been visited recently and are currently mounted:
% ls /xfn/org/sales/fs customers products |
To see the entire listing, use the fnlist command.:
% fnlist org/sales/fs Listing `org/sales/fs': products goals customers incentives |
The printer context is not part of the XFN policies. It is provided in FNS in order to store printer bindings.
FNS provides the capability to store printer bindings in the FNS namespace. This gives print servers the means to advertise their services and allow users to browse and choose amongst the available printers without client side administration.
Printer bindings are stored in printer contexts, which are associated with organizations, users, hosts, and sites. Hence, each organization, user, host, and site has its own printer context.
The printer context is created under the service context of the respective composite name. For example, the composite name shown below has the following printer context:
org/doc.com./service/printer |
The name of a printer for a host, deneb, with a printer context might look like this:
host/deneb/service/printer/laser |
Global name services have worldwide scope. This section describes the policies for naming objects that use global naming systems.
In regard to naming, an enterprise links to the federated global namespace by binding the root of the enterprise in the global namespace. This enables applications and users outside the enterprise to name objects within that enterprise. For example, a user within an enterprise can give out the global name of a file to a colleague in another enterprise to use.
DNS and X.500 contexts provide global-level name service for naming enterprises. FNS provides support for both DNS and X.500 contexts. Without FNS, DNS and X.500 allow outside access to only limited portions of the enterprise namespace. FNS enables outside access to the entire enterprise namespace including services such as calendar manager.
The atomic name "..." (three dots) appears in the initial context of every FNS client. The atomic name "..." is bound to a context from which global names can be resolved.
Table 21-5 Initial Context Bindings for Global Naming
Atomic Name |
Binding |
---|---|
. .. |
Global context for resolving DNS or X.500 names |
/ ... |
Synonym for three dots |
Global names can be either fully qualified Internet domain names, or X.500 distinguished names.
Internet domain names appear in the syntax specified by Internet RFC 1035. For example, .../doc.com. (See "Federating DNS".)
X.500 names appear in the syntax determined by the X/Open DCE Directory. For example, .../c=us/o=doc. (See "Federating X.500/LDAP".)
The names "..." and "/..." are equivalent when resolved in the initial context. For example, the names /.../c=us/o=doc and.../c=us/o=doc resolve in the initial context to the same object.
Any fully qualified DNS name can be used in the global context. When a DNS name is encountered in the global namespace, it is resolved using the resolver library. The resolver library is the DNS name-resolution mechanism. A DNS name typically resolves to an Internet host address or to DNS domain records. When the global context detects a DNS name, the name is passed to the DNS resolver for resolution. The result is converted into an XFN reference structure and returned to the requester.
The contents of DNS domains can be listed. However, the listing operations might be limited by practical considerations such as connectivity and security on the Internet. For example, listing the global root of the DNS domain is generally not supported by the root DNS servers. Most entities below the root, however, do support the list operation.
DNS hosts and domains are distinguished from each other by the presence or absence of name service (NS) resource records associated with DNS resource names.
DNS domain names. If an NS record exists for a resource name, then that name is considered to be the name of a domain, and the returned reference is of type inet_domain.
DNS host names. If no NS record exists for a resource name, then that name is considered to be the name of a host, and the returned reference is of type inet_host.
DNS can be used to federate other naming systems by functioning as a non-terminal naming system.
For example, an enterprise naming system can be bound to doc.com in DNS such that the FNS name .../doc.com/ refers to the root of that enterprise's FNS namespace.
The enterprise naming system is bound to a DNS domain by adding the appropriate text (TXT) records to the DNS map for that domain. When the FNS name for that domain includes a trailing slash (/), the TXT resource records are used to construct a reference to the enterprise naming system.
For general information about DNS, see the in.named Man page or the DNS chapters in Solaris Naming Setup and Configuration Guide.
X.500 is a global directory service. It stores information and provides the capability to look up information by name as well as to browse and search for information.
X.500 information is held in a directory information base (DIB). Entries in the DIB are arranged in a tree structure. Each entry is a named object and comprises a defined set of attributes. Each attribute has a defined attribute type and one or more values.
An entry is unambiguously identified by a distinguished name that is the concatenation of selected attributes from each entry in the tree along a path leading from the root down to the named entry. For example, using the DIB shown in Figure 21-6,
c=us/o=doc
is a distinguished name of the doc organization in the U.S. Users of the X.500 directory can interrogate and modify the entries and attributes in the DIB.
FNS federates X.500 by supplying the necessary support to permit namespaces to appear to be seamlessly attached below the global X.500 namespace.
For example, FNS facilitates linking the enterprise naming system for the doc organization below X.500. Starting from the initial context, an FNS name to identify the sales organizational unit of the doc organization might be
.../c=us/o=doc/orgunit/sales
The name within the enterprise is simply concatenated onto the global X.500 name. (Note that FNS names use the name "..." in the initial context to indicate that a global name follows.)
Name resolution of FNS names takes place as follows. When an X.500 name is encountered in the global namespace, it is resolved using the X.500 name- resolution mechanism. One of three outcomes is possible:
The full name resolves to an X.500 entry. This indicates that the entry is held in X.500. The requested FNS operation is then performed on that entry.
A prefix of the full name resolves to an X.500 entry. This indicates that the remainder of the name belongs to a subordinate naming system.
The next naming system pointer (NNSP) to the subordinate naming system is examined to return the XFN reference. Name resolution then continues in the subordinate naming system.
An error is reported.
X.500 entries can be examined and modified using FNS operations (subject to access controls). However, it is not currently possible to list the subordinate entries under the root of the X.500 namespace by using FNS.
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 once 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 incriminated 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.
This chapter describes how to individually create, and administer existing enterprise-level contexts.
FNS contexts are created using the fncreate command. This section describes how to create FNS contexts individually rather than for the entire organization as described in Solaris Naming Setup and Configuration Guide. The fncreate command creates a context of the specified type and binds it to the given composite name. It also creates subcontexts for the context.
The fncreate command has the following syntax,
fncreate -t context_type [-f input_file] [-o][-r reference_type][-s][-v] [-D] composite_name |
Option |
Description |
---|---|
--t context |
Specifies the type of context to create. The context operator can be one of org, hostname, username, host, user, service, site, nsid, generic, or fs |
-f |
Creates a context for every host or user listed in input_file. This option can only be used with the -t username or -t hostname option and is useful for creating contexts for a subset of users and hosts found in the corresponding NIS+ passwd and hosts tables, respectively. |
-o |
Creates only the context specified. Without the -o option, subcontexts are created according to the FNS policies. |
-r |
Specifies the reference_type of the generic context being created. It can only be used with the -t generic option. |
-s |
Creates new contexts for composite names already in use. Otherwise, no new contexts are created for names already bound. |
-D |
Displays information about the NIS+ object associated with a context each time a context is created. This option is useful for debugging. |
-v |
Displays information about the creation as each context is created. |
If you specify the -o option when creating an organization context, the associated host, user, and service contexts are still created but they are not populated.
When creating contexts bound to namespace identifiers, the name without the underscore (for example, user) is used to create the context and the name with the underscore (for example, _user) is then bound to the reference of the newly created context. The is done regardless of whether the name with or without the underscore is specified in the command line.
For example, the command
fncreate -t username org/sales/_user |
creates a context for org/sales/user and adds a binding for org/sales/_user to the context of org/sales/user.
Use the org type to create an organization context. The composite name must be one of the following depending on the primary naming service:
NIS+. The name of an existing NIS+ domain (or subdomain). An NIS+ domain is an NIS+ directory object with an org_dir subdirectory. Populated host and passwd tables for the domain must exist in the domain's org_dir subdirectory.
NIS. The name of the NIS domain. Associated host and passwd maps must also exist.
/etc files. There is only the org// organization context when using /etc files.
Assume the root NIS+ domain is doc.com and there is a subdomain sales.doc.com. To create a sales organization context to correspond to the sales subdomain, you would enter the following command:
fncreate -t org org/sales/ |
When the new context is created, a ctx_dir directory, if it does not already exist, is created under the directory of the domain, sales.doc.com.
Because this example used only the -t option without the -o option, it created an organization context for the composite name org/sales/ and, in addition, created hostname, username, and service subcontexts for it, which in turn, created host and user contexts, and service subcontexts for hosts and users. In effect, that is the same as running the following commands:
fncreate -t hostname org/sales/host/ fncreate -t username org/sales/user/ fncreate -t service org/sales/service/ |
If, instead, you ran fncreate -o -t orgthe org context is created and the hostname, username, and service contexts are also created, but not populated with host and user contexts.
The org context is owned by the administrator who
executed the fncreate command, as are the hostname, username, and service
subcontexts. The host and user contexts,
however, and their subcontexts are owned by the hosts or users for which the
contexts were created. In order for the administrator to subsequently manipulate
host and user contexts, the NIS_GROUP
environment variable must have been set accordingly at the time fncreate is executed.
For example, assuming a C-Shell, to set NIS_GROUP
to fns_admins.doc.com:
rootmaster# setenv NIS_GROUP fns_admins.doc.com |
The hostname type creates a hostname context in which host contexts can be created and bound. Host contexts and their subcontexts are created for each machine name found in the NIS+ hosts.org_dir table unless the -o option is used. When the -o option is used, only the hostname context is created.
For example, running the command
fncreate -t hostname org/sales/host/ |
creates the hostname context and effectively runs the command:
fncreate -t host org/sales/host/hname |
Where hname is the name of each machine found in the hosts.org_dir table. It also adds a binding for org/sales/_host/ that is bound to the reference of org/sales/host/.
The hostname context is owned by the administrator who executed the fncreate command. A host context and its subcontexts are owned by the machine for which the contexts were created. That is, each host owns its own host context and subcontexts.
The -f option can be used to create contexts for a subset of the hosts found in the NIS+ table hosts.org_dir. It creates contexts for those hosts listed in the given input file.
The host type creates the context and subcontexts for a single host. The command automatically creates a service context for the host and a binding for fs unless the -o option is used. When the -o option is used, only the host context is created.
# fncreate -t host org/sales/host/antares/ |
creates a context for the host named antares and effectively runs the commands
fncreate -t service org/sales/host/antares/service/ fncreate -t fs org/sales/host/antares/fs/ |
The host context and its subcontexts are owned by the machine. In the above example, the machine antares, with NIS+ principal name antares.sales.doc.com, owns the contexts:
org/sales/host/antares/
org/sales/host/capsule/service/
org/sales/host/capsule/fs.
The hostname context (org/sales/host in the above example) to which the machine belongs must already exist. The machine name supplied should already exist in the NIS+ hosts.org_dir table.
Alias host names may exist in an NIS+ hosts.org_dir table. These appear in the table as a set of hosts with the same canonical name but different alias names.
In FNS, a single host with multiple alias names has a single host context. Alias names for that host in the hostname context are bound to the reference of that host context.
The username type creates a username context in which individual user contexts can be created and bound. User contexts and their subcontexts are created for each user name found in the NIS+ passwd.org_dir table unless the -o option is used. When the -o option is used, only the username context is created.
For example, running the command
# fncreate -t username org/sales/user/ |
creates the username context and effectively runs the command:
fncreate -t user org/sales/user/uname |
Where uname represents the various user names that appear in the passwd.org_dir table. It also adds a binding for org/sales/_user/ that is bound to the reference of org/sales/user/.
The username context is owned by the administrator who executed the fncreate command. Individual user contexts and their subcontexts are owned by the users for which the contexts were created. Each user owns his or her own user context and subcontexts.
The -f option can be used to create contexts for a subset of the users found in the NIS+ table passwd.org_dir. It creates contexts for those users listed in the given input file.
The user type creates the user context and subcontexts for a user. A service subcontext and a binding for fs are created under the user context unless the -o option is used. When the -o option is used, only the user context is created.
For example, the command
# fncreate -t user org/sales/user/jjones/ |
creates the user context for the user named jjones and effectively runs the commands
fncreate -t service org/sales/user/jjones/service/ fncreate -t fs org/sales/user/jjones/fs/ |
The user context and its subcontexts are owned by the user for whom the contexts were created. In the above example, the contexts created are owned by the user jjones with NIS+ principal name jjones.sales.doc.com.
The username context (org/sales/user in the above example) to which the user belongs must already exist. The user name supplied should already exist in the NIS+ passwd.org_dir table.
The service type creates the service context in which service names can be bound. There is no restriction on what type of references may be bound in a service context. The policies depend on the applications that use the service context. For example, a group of desktop applications may bind references for a calendar, a telephone directory, a fax service, and a printer in a service context.
# fncreate -t service org/sales/service/ |
creates a service context for the organization sales. Because the terminal atomic name is a namespace identifier, fncreate also adds a binding for org/sales/_service/ that is bound to the reference of org/sales/service/. After executing this command, names such as org/sales/service/calendar and org/sales/service/fax can then be bound in this service context.
The service context supports a hierarchical namespace, with slash-separated left-to-right names. The service namespace can be partitioned for different services. Continuing with the desktop applications example, a group of plotters may be named under the service context after the creation of the plotter context.
# fncreate -t service org/sales/service/plotter |
Names such as org/sales/service/plotter/speedy and org/sales/service/plotter/color could then be bound under the service context.
Because the terminal atomic name is not a namespace identifier, no additional binding is added (as was the case with service and _service).
The service context created is owned by the administrator who ran the fncreate command.
The printer context is created under the service context of the respective composite name.
The generic type creates a context for binding names used by applications.
A generic context is similar to a service context except it can have a different reference type. The -r option is used to specify the reference type for the generic context being created. If it is omitted, the reference type is inherited from its parent generic context or, if the parent context is not a generic context, the reference type used is a default generic reference type.
Like a service context, there is no restriction on what type of references may be bound in a generic context. The policies depend on the applications that use the generic context.
# fncreate -t generic -r WIDC_comm org/sales/service/extcomm |
creates a generic context with the WIDC_comm reference type under the service context of the organization sales. Names such as org/sales/service/extcomm/modem can then be bound in this generic context.
The generic context supports a hierarchical namespace, with slash-separated left-to-right names, which allows an application to partition its namespace for different services. Continuing with the example above, a generic subcontext for modem can be created running the command
# fncreate -t generic org/sales/service/extcomm/modem |
Names such as org/sales/service/extcomm/modem/secure and org/sales/service/extcomm/modem/public could then be bound under the modem context.
The generic context created is owned by the administrator who ran the fncreate command.
The site type creates contexts in which site names can be bound.
# fncreate -t site org/sales/site/ |
creates a site context. Because the terminal atomic name is a namespace identifier, fncreate also adds a binding for org/sales/_site/ that is bound to the reference of org/sales/site/.
The site context supports a hierarchial namespace, with dot-separated right-to-left names, which allows sites to be partitioned by their geographical coverage relationships.
For example, the commands
# fncreate -t site org/sales/alameda # fncreate -t site org/sales/site/alameda.bldg-5 |
create a site context alameda and a site subcontext alameda.bldg-5 for it.
Because these terminal atomic names are not namespace identifiers, no additional bindings are added (as was the case with site and _site).
The site context created is owned by the administrator who ran the fncreate command.
The fs type creates a file system context (or file context) for a user or a host. For example, the command
# fncreate -t fs org/sales/user/petrova/fs/ |
creates the fs context for user petrova. Because the terminal atomic name is a namespace identifier, fncreate also adds a binding for org/sales/user/petrova/_fs/ that is bound to the reference of org/sales/user/petrova/fs/.
The fs context of a user is the user's home directory as it is stored in the NIS+ passwd.org_dir table. The fs context of a host is the set of NFS file systems that the host exports.
Use the fncreate_fs command to create file contexts for organizations and sites or to create file contexts other than the defaults for users and hosts. See "File Contexts Administration", for details.
The fs context created is owned by the administrator who ran the fncreate command.
The nsid (namespace identifier) type creates a context in which namespace identifiers can be bound.
# fncreate -t nsid org/sales/site/alameda.bldg-5/ |
creates the nsid context for the site alameda.bldg-5 and permits the creation of subcontexts such as service/. Continuing with this example, you could then execute the command
# fncreate -t service org/sales/site/alameda.bldg-5/service/ |
to create the service context for alameda.bldg-5.
The nsid context created is owned by the administrator who ran the fncreate command.
A number of tools are provided for examining and managing FNS contexts. The commands and their syntax are shown in the sections that follow.
fnlookup displays the binding of the given composite name.
fnlookup [-v][-L] composite_name |
Option |
Description |
---|---|
-v |
Displays the binding in more detail |
-L |
Displays the reference to which the XFN link is bound |
For example, to show the binding for the user darwin in detail, you would enter:
# fnlookup -v user/darwin/ Reference type: onc_fn_user Address type: onc_fn_nisplus length: 52 context type: user representation: normal version: 0 internal name: fns_user_darwin.ctx_dir.sales.doc.com. |
Suppose user/Charles.Darwin is linked to user/darwin. The first command in the following example shows what user/Charles.Darwin is bound to (an XFN link). The second command follows the XFN link, user/darwin, and shows what user/darwin is bound to (the user context).
# fnlookup user/Charles.Darwin Reference type: fn_link_ref Address type: fn_link_addr Link name: user/darwin # fnlookup -L user/Charles.Darwin Reference type: onc_fn_user Address type: onc_fn_nisplus context type: user |
fnlist lists the contents of the context identified by the given name.
fnlist [-lv] [name] |
Option |
Description |
---|---|
-v |
Displays the binding in more detail |
-l |
Displays the bindings of the names bound in the named context |
For example, to display the bindings under the user context:
# fnlist user/ Listing 'user/': jjones julio chaim James.Jones |
If no name is given, the command lists the contents of the initial context.
# fnlist Listing '': _myorgunit ... _myself thishost myself _orgunit _x500 _host _thisens myens thisens org orgunit _dns thisuser _thishost myorgunit _user thisorgunit host _thisorgunit _myens user |
When the -l option is given, the bindings of the names bound in the named context are displayed.
# fnlist -l user/ Listing bindings 'user/': name: julio Reference type: onc_fn_user Address type: onc_fn_nisplus context type: user name: chaim Reference type: onc_fn_user Address type: onc_fn_nisplus context type: user name: James.Jones Reference type: fn_link_ref Address type: fn_link_addr Link name: user/jjones name: jjones Reference type: onc_fn_user Address type: onc_fn_nisplus context type: user |
When the -v option is given in conjunction with the -l option, the bindings are displayed in detail.
# fnlist -lv user/ Listing bindings 'user/': name: julio Reference type: onc_fn_user Address type: onc_fn_nisplus length: 52 context type: user representation: normal version: 0 internal name: fns_user_julio.ctx_dir.sales.doc.com. name: chaim Reference type: onc_fn_user Address type: onc_fn_nisplus length: 52 context type: user representation: normal version: 0 internal name: fns_user_chaim.ctx_dir.sales.doc.com. name: James.Jones Reference type: fn_link_ref Address type: fn_link_addr length: 11 data: 0x75 0x73 0x65 0x72 0x2f 0x6a 0x6a 0x6f 0x6e 0x65 user/jjones name: jjones Reference type: onc_fn_user Address type: onc_fn_nisplus length: 52 context type: user representation: normal version: 0 internal name: fns_user_jjones.ctx_dir.sales.doc.com. |
fnbind allows you to bind a composite name to a reference.
There are two uses of this command.
The first usage allows the user to bind the reference of an existing name to a new name. (See below.)
The second usage allows the user to bind a reference constructed using arguments in the command line to a name. (See "Constructing a Reference on the Command Line ".)
The syntax of fnbind for binding existing names to new names is:
fnbind [-s][-v][-L] oldname newname |
Option |
Description |
---|---|
oldname |
The existing composite name |
newname |
The new name to which you are binding the old name |
-s |
Supersedes any existing binding of the original composite name |
-v |
Prints out the reference used for the binding |
-L |
Creates an XFN link using name and binding it to new_name |
For example, to bind the name user/julio/service/printer to the reference of myorgunit/service/printer you would enter:
# fnbind myorgunit/service/printer user/julio/service/printer |
If the given newname is already bound, fnbind -s must be used or the operation will fail. In the above example, if user/julio/service/printer is already bound, the -s option must be used to overwrite the existing binding with that of myorgunit/service/printer as shown below:
# fnbind -s myorgunit/service/printer user/julio/service/printer |
The -v option prints out the reference used for the binding.
# fnbind -v myorgunit/service/printer user/julio/service/printer Reference type: onc_printers Address type: onc_fn_printer_nisplus |
The following command constructs an XFN link out of user/jjones and binds it to the name user/James.Jones:
# fnbind -L user/jjones user/James.Jones |
Similarly, to create a link from user/julio/service/printer to myorgunit/service/printer you would enter:
# fnbind -sL myorgunit/service/printer user/julio/service/printer |
The syntax of fnbind for building a reference on the command line is:
fnbind -r [-s] [-v] newname [-O | -U] reftype {[-O | -U] | addresstype [-c|-x] addresscontents}+ |
Option |
Description |
---|---|
newname |
The new name for which you are constructing a reference |
reftype |
The type of reference you are creating. Unless the -O or -U options are used, FN_ID_STRING is used as the indentifier for reftype. |
addresstype |
The type of address you are creating. Unless the -O or -U options are used, FN_ID_STRING is used as the indentifier for addresstype. |
addresscontents |
The address of the reference you are creating. Unless the -c or -x options are used, the address is stored as an XDR-encoded string. |
-s |
Supersedes any existing binding of the original composite name |
-v |
Prints out the reference used for the binding |
-c |
Stores address contents without XDR encoding |
-x |
Interprets address contents as a hexadecimal input string and store it as is |
-r |
Creates a reference with a specified type and binds the reference to a name specified on the command line |
-O |
Interprets and stores type string as ASN.1 dot-separated integer list |
-U |
Interprets and stores type string as a DCE UUID |
For example, to bind the name thisorgunit/service/calendar to the address contents of staff@cygnus with a reference type of onc_calendar and and an address type onc_cal_str you would enter:
# fnbind -r thisorgunit/service/calendar onc_calendar onc_cal_str staff@cygnus |
By default, the address contents supplied in the command line is XDR-encoded before being stored in the reference. If the -c option is given, the address contents are stored in normal, readable characters, not as an XDR-encoded string. If the -x option is given, the address contents supplied in the command line are interpreted as a hexadecimal string and stored (and not XDR-encoded).
By default, the reference and address types of the reference to be constructed uses the FN_ID_STRING
identifier format. If the -O option is given,
the identifier format is FN_ID_ISO_OID_STRING
, an ASN.1 dot-separated
integer list string. If the -U option is given, the identifier format is FN_ID_DCE_UUID
, a DCE UUID in string form.
For more information on ASN.1, see ISO 8824: 1990, Information Technology -- Open Systems Interconnection -- Specification of Abstract Syntax Notation One (ASN.1). For more information on DCE UUID see X/Open Preliminary Specification, October 1993, X/Open DCE: Remote Procedure Call (ISBN: 1-872630-95-2).
For example, to bind to the name thisorgunit/service/nx a reference with a hexadecimal string as the address contents and OIDs as reference and address types, you would enter:
# fnbind -r thisorgunit/service/nx -O 1.2.99.6.2.1 -O 1.2.99.6.2.3 -x ef12eab67290 |
fnunbind removes the given composite name from the namespace. Note that this does not remove the object associated with the name; it only unbinds the name from the object.
For example, to remove the binding associated with the name user/jjones/service/printer/color, you would enter:
# fnunbind user/jjones/service/printer/color |
The fnrename command renames an existing binding.
For example, to rename the binding of clndr to calendar, in the context named by user/jjones/service/ you would enter:
# fnunbind user/jjones/service/printer/color |
fndestroy removes the given composite name from the namespace and destroys the context named by the composite name.
For example, to unbind the name user/jones/ from the namespace and destroys the context named by user/jjones/ you would enter:
# fndestroy user/jjones/ |
If the composite name identifies a context to be removed, the command fails if the context contains subcontexts.
This chapter describes how to administer application specific contexts.
File contexts may be:
Created using the fncreate_fs command (see "Creating a File Context With fncreate_fs ").
Inspected using the fnlist command (see "Listing the Context") or the fnlookup command (see "Displaying the Binding").
Pruned or destroyed using fnunbind command (see "Removing a Composite Name") or the fndestroy command (see "Destroying a Context").
The fncreate_fs command creates file contexts for organizations and sites. It may also be used to override the default file contexts for users and hosts that are created by the fncreate command.
There are two methods of using the fncreate_fs command.
Input file. File context bindings may be provided by an input file (See "Creating File Contexts With an Input File")
Command line. File context bindings may be created from the command line (See "Creating File Contexts With Command-line Input").
The two methods of fncreate_fs have the following syntax:
fncreate_fs [-v] [-r] -f file composite_name fncreate_fs [-v] [-r] composite_name [options] [location...] |
Option |
Description |
---|---|
composite_name |
The composite name of the file context. |
-f file |
Use an input file named file. |
options |
Mount options |
location |
Mount location. |
-v |
Sets verbose output, displaying information about the contexts being created and modified. |
-r |
Replaces the bindings in the context named by composite_name --and all of its subcontexts--with only those specified in the input. This is equivalent to destroying the context (and, recursively, its subcontexts), and then running fncreate_fs without this option. The -r option should be used with care. |
The fncreate_fs command manipulates FNS contexts and bindings of the onc_fn_fs reference type. It uses an address of type onc_fn_fs_mount to represent each remote mount point. The data associated with an address of this type are the corresponding mount options and locations in a single, XDR-encoded string.
The input file supplies the names and values to be bound in the context of composite_name. Its format is based upon and similar, but not identical, to the format of indirect automount maps. The input file contains one or more entries with the form:
name [options] [location...] |
name is the reference name. The name field may be a simple atomic name or a slash-separated hierarchical name. It may also be "." (dot), in which case the reference is bound directly to composite_name.
options are mount options, if any. The options field begins with a hyphen ("-"). This is followed by a comma-separated list (with no spaces) of the mount options to use when mounting the directory. These options also apply to any subcontexts of composite_name/name that do not specify mount options of their own.
location is the mount location. The location field specifies the host or hosts that serve the files for composite_name/name. In a simple NFS mount, location takes the form:
host:path |
Where host is the name of the server from which to mount the file system and path is the path name of the directory to mount.
For each entry a reference to the mount locations and the corresponding mount options is bound to the name composite_name/name.
If options and location are both omitted, then no reference is bound to composite_name/name. Any existing reference is unbound.
For example, suppose you want kuanda's file system to be an NFS mount of the directory /export/home/kuanda from host altair as shown in Figure 21-4. The command would be run as follows:
% fncreate_fs -f infile user/kuanda/fs |
. altair:/export/home/kuanda |
To set up a more complex file system distributed over more than one server as shown in Figure 21-5, run the command
% fncreate_fs -f infile org/sales/fs |
with infile containing
tools/db altair:/export/db project altair:/export/proj project/lib altair:/export/lib project/src deneb:/export/src |
To change the NFS mounts for project and its subcontexts src and lib to be read-only, you can change infile as follows:
tools/db svr1:/export/db project -ro svr1:/export/projproject/lib altair:/export/lib project/src svr2:/export/src |
The -ro is unnecessary in the third and fourth lines because src and lib are subcontexts of project, they will inherit the -ro mount option from above.
The following input file would make all of the mounts read-only except for org/sales/fs/project/src.
. -ro tools/db svr1:/export/db project svr1:/export/proj project/lib altair:/export/lib project/src -rw svr2:/export/src |
The fncreate_fs command also allows the binding description to be provided on the command line:
fncreate_fs composite_name [mmount_options] [mount_location ...] |
This is equivalent to using the input file form of the command but entering the individual bindings from your keyboard. The previous example in which kuanda's file system was set could be set from the command line as follows:
% fncreate_fs user/kuanda/fs altair:/export/home/kuanda |
Similarly, the hierarchy illustrated in Figure 21-5 could have been set up by running the sequence of commands:
% fncreate_fs org/sales/fs/tools/db altair:/export/db % fncreate_fs org/sales/fs/project altair:/export/proj % fncreate_fs org/sales/fs/project/lib altair:/export/lib % fncreate_fs org/sales/fs/project/src deneb:/export/src |
To make all three of the mounts read-only, you would run this command:
% fncreate_fs org/sales/fs -ro |
The following two sections apply to both input file and command-line input formats.
Multiple location fields may be specified for NFS file systems that are exported from multiple, functionally equivalent locations:
% fncreate_fs org/sales/fs altair:/sales cygnus:/sales |
The automounter will attempt to choose the best server from among the alternatives provided. If several locations in the list share the same path name, they may be combined using a comma-separated list of host names:
% fncreate_fs org/sales/fs altair,cygnus:/sales |
The hosts may be weighted, with the weighting factor appended to the host name as an integer in parentheses: the lower the number, the more desirable the server. The default weighting factor is zero (most desirable). Negative numbers are not allowed.
The following example illustrates one way to indicate that cygnus is the preferred server:
% fncreate_fs org/sales/fs altair(2),cygnus(1):/sales |
Variable names, prefixed by $, may be used in the options or location fields of fncreate_fs. For example, a mount location may be given as:
altair:/export/$CPU |
The automounter will substitute client-specific values for these variables when mounting the corresponding file systems. In the above example, $CPU is replaced by the output of uname -p; for example, sparc.
For additional compatibility with automount maps, the following input file format is also accepted by fncreate_fs:
name [mount_options] [mount_location ...] \ /offset1 [mount_options1] mount_location1 ... \ /offset2 [mount_options2] mount_location2 ... \ ... |
Where each offset field is a slash-separated hierarchy. The backslash (\) indicates the continuation of a single long line. This is interpreted as being equivalent to:
name [mount_options] [mount_location ...] \ name/offset1 [ mount_options1] mount_location1 ... \ name/offset2 [mount_options2] mount_location2 ...... |
The first line is omitted if both mount_options and mount_location are omitted. This format is for compatibility only. It provides no additional functionality, and its use is discouraged.
This chapter describes two global naming systems (DNS and X.500/LDAP) and how to federate them under FNS.
See "Global Naming Services" for overview and background information on the relationship between FNS and global naming services.
FNS supports federation of enterprise naming systems into the global naming systems, DNS and X.500/LDAP. This chapter describes the procedures for federating NIS+ with DNS and X.500. In general, the procedures involve
Determining the NIS+ root reference for your NIS+ hierarchy
Adding this information in the format required by the global naming system
You can only federate a global naming service if your enterprise-level name service is NIS+ or NIS. If you are using a files-based name service for your enterprise, you cannot federate either DNS or X.500/LDAP.
To federate an enterprise naming service under DNS or X.500/LDAP, information must be added to these respective naming systems to enable access to and from the enterprise and the global Internet outside of the enterprise. This information is the root reference, which consists of network address information describing how to reach the top of a particular enterprise namespace.
The root reference consists of a single address which contains a single, XDR-encoded string. The address type and content varies according to the enterprise level name service you are using: NIS+ or NIS.
When your enterprise level name service is NIS+, the root reference address type is: onc_fn_nisplus_root. There are two required, and one optional, elements in a root reference network address. The elements are separated by white spaces:
root-domain server [server_IP_address] |
Address Element |
Description |
---|---|
root_domain |
The fully qualified name of the NIS+ root domain (trailing dot required). |
server |
The host name of one of the NIS+ servers (master or replica) serving nis+_root_domain. |
server_IP_address |
The IP address of nis+server. This is optional if the address of nis+server is expected to be known. This means it should be available through one of the name services listed in the /etc/nsswitch.conf file. |
For example, suppose that the NIS+ root domain is doc.com. (notice the trailing dot), and that it can be reached using the host nismaster.doc.com. The root reference would be:
doc.com. nismaster.doc.com |
The IP address of the server is not given in the example above because it is expected to be available through other means. If for some reason that IP address was not available through other means, the root reference would look like:
doc.com. nismaster.doc.com 123.123.123.33 |
When your enterprise level name service is NIS, the root reference address type is: onc_fn_nis_root. There are two required, and one optional, elements in a root reference network address. The elements are separated by white spaces:
root_domain server [server_IP_address] |
Address Element |
Description |
---|---|
root_domain |
The fully qualified name of the NIS domain (trailing slash required). |
server |
The host name of one of the NIS servers (master or slave) serving root_domain. |
server_IP_address |
The IP address of nis-server. This is optional if the address of nis-server is expected to be known. This means it should be available through one of the name services listed in the /etc/nsswitch.conf file. |
For example, suppose that the NIS domain is doc.com, and that it can be reached using the host ypmaster.doc.com. The root reference would be:
doc.com/ ypmaster.doc.com |
The IP address of the server is not given in the example above because it is expected to be available through other means. If for some reason that IP address was not available through other means, the root reference would look like:
doc.com/ ypmaster.doc.com 123.123.123.37 |
This section describes the steps required to add TXT (text) records for a subordinate enterprise naming system implemented with NIS+ or NIS. To federate a subordinate naming system in DNS, you need to add reference information into DNS describing how to reach the subordinate naming system's root reference.
Obtain the root reference.
Add a root reference TXT record to the DNS loopback file.
By default, this manual uses the name /etc/named.local for this file (other common names for this file are domain.127.0.0 or db.127.0.0).
The root reference TXT record has the following format:
For NIS+
TXT "XFNNISPLUS rootdomain server [server_IP_address]" |
For example:
TXT "XFNNISPLUS doc.com. nismaster.doc.com" |
For NIS
TXT "XFNNIS rootdomain server [server_IP_address]" |
For example:
TXT "XFNNIS doc.com/ ypmaster.doc.com" |
The TXT record must be associated with a DNS domain that includes an NS (name server) record entry. The following is an example of a DNS domain with reference information for NIS+ bound in it.
$ORIGIN doc.com @ IN SOA foo bar.eng.doc.com ( 100 ;; Serial 3600 ;; Refresh 3600 ;; Retry 3600 ;; Expire 3600 ;; Minimum ) NS nshost TXT "XFNNISPLUS doc.com. nismaster 123.123.123.33" nshost IN A 133.33.33.34 |
For more information about DNS files, see "DNS Boot and Data Files".
After adding the TXT record into the DNS table, either restart the DNS server or send it a signal to reread the table.
# kill -HUP pid |
Where pid is the process ID number of in.named.
For further information on how DNS TXT records are used for XFN references, see "DNS Text Record Format for XFN References ".
In order to federate a subordinate naming system (either NIS+ or NIS) in X.500/LDAP:
Root reference information must be added into X.500 describing how to reach the subordinate naming system.
An X.500 client API must be specified.
Obtain the NIS+ root reference for your NIS+ hierarchy.
Create an X.500 entry that supports XFN reference attributes.
For example, the following command creates a new X.500 entry called c=us/o=doc with the object classes top, organization, and XFN-supplement (1.2.840.113536.25). The XFN-supplement object class allows the c=us/o=doc entry to store reference information for a subordinate naming system.
# fnattr -a .../c=us/o=doc object-class \ top organization XFN-supplement |
If the X.500 entry already existed and was not defined with the XFN-supplement object class, it must be removed and re-created with the additional object class. Otherwise, it will not be able to hold reference information about the subordinate naming system.
Add the reference information about the subordinate system to the entry.
After creating the X.500 entry, you can then add information about the subordinate system by binding the appropriate root reference to the named entry.
For example, if your subordinate naming system is NIS+, and the NIS+ server you want to use is nismaster, your would enter:
# fnbind -r .../c=us/o=doc/ onc_fn_enterprise onc_fn_nisplus_root \ "doc.com. nismaster |
If your subordinate naming system is NIS, and the NIS server you want to use is ypmaster, your would enter:
# fnbind -r .../c=us/o=doc/ onc_fn_enterprise onc_fn_nis_root \ "doc.com/ ypmaster" |
These examples bind the reference for the NIS+ or NIS hierarchy with the root domain name doc.com, to the next naming system pointer (NNSP) of the X.500 entry c=us/o=doc, thus linking the X.500 namespace with the doc.com. namespace.
The address format used is that of the root reference described in "Obtaining the Root Reference". Note the use of the trailing slash in the name argument to fnbind, .../c=us/o=doc/, to signify that the reference is being bound to the NNSP of the entry, rather than to the entry itself.
For further information on X.500 entries and XFN references, see "X.500 Attribute Syntax for XFN References ".
An X.500 client API is required in order to access X.500 using FNS. You can use one of two different clients:
XDS/XOM API. The XDS/XOM API must be installed. It is exported from the /opt/SUNWxds/lib/libxomxds.so shared object. Consult "Getting started with the SunLink X.500 Client Toolkit" for details on SunSoft's X.500 product.
LDAP (Lightweight Directory Access Protocol) API. The LDAP API is automatically installed as part of Solaris Release 2.6.
The API that you use is specified in each machine's /etc/fn/x500.conf file. This file contains configuration information for X.500 and LDAP. This file can be edited directly. The default x500.conf file contains two entries:
x500-access: xds ldap ldap-servers: localhost ldap |
Where localhost and ldap are the IP addresses or hostnames of one or more LDAP servers.
The first entry specifies the order in which X.500 accesses APIs. In the example above, X.500 will first try to use XDS/XOM. If XDS/XOM is not available, it will default to using LDAP. If the entry read: x500-access: ldap xds, X.500 would use LDAP and only fall back on XDS if LDAP were not available.
The second entry lists the IP addresses or hostnames of servers running LDAP. Each server is tried in turn until a successful LDAP connection is achieved. In the example above, the localhost is tried first. If LDAP is not available on that server, the next one is tried.
This chapter describes FNS attributes and how to administer them. .
Attributes may be applied to named objects. Attributes are optional. A named object can have no attributes, one attribute, or multiple attributes.
Each attribute has a unique attribute identifier, an attribute syntax, and a set of zero or more distinct attribute values.
XFN defines the base attribute interface for examining and modifying the values of attributes associated with existing named objects. These objects can be contexts or any other type of object. Associated with a context are syntax attributes that describe how the context parses compound names.
The extended attribute interface contains operations that search for specific attributes and that create objects and their associated attributes.
Search for attributes with the fnsearchcommand.
The syntax of the fnsearch command is
fnsearch [-ALlv] [-n max] [-s scope] name [-a ident]... [-O|-U] filter_expr [filter_arg] |
Option |
Description |
---|---|
-n max |
Display only max number of objects. |
-s scope |
Set the scope of the search |
-a ident |
Display only those attributes that match ident. |
name |
Composite name |
filter_expr |
Boolean, logical, grouping, relational, and comparison operators (see Table 26-2) |
filter_arg |
Arguments for filter expressions (see Table 26-2] |
-A |
Consult only the authoritative source. |
-L |
Follow XFN links. |
-l |
Display the object references for the matching objects. |
-v |
Verbose. Display detailed object references for the matching objects. |
-O |
Use an OSI OID as the identifier |
-U |
Use a DCE UUID as the identifier |
With the fnsearch command, you can search for objects that are associated with the attributes you choose.
For example, to find all the objects that are associated with the attribute for_sale in orgunit/sales/site/, you would enter the following command:
% fnsearch orgunit/sales/site/ for_sale |
You can also use all the following in filter expressions in your search patterns.
Table 26-2 fnsearch Filter Expression Operators
Filter Expression Operator |
Symbols and Forms |
---|---|
Logical operators |
or, and, not |
Parentheses for grouping |
( ) |
Relational operators: Compare an attribute to a supplied value |
== True if at least one attribute value is equal to the supplied value. != True if none of the attribute values are equal to the supplied value. < True if at least one attribute value is less than the supplied value. <= True if at least one attribute value is less than or equal to the supplied value. > True if at least one attribute value is greater than the supplied value. >= True if at least one attribute value is greater than or equal to the supplied value. ~= True if at least one attribute value matches the supplied value according to some context-specific approximate matching criterion. This criterion must subsume strict equality. |
Example: |
% fnsearch name "not (make == 'olds' and year == 1983)" |
Substitution tokens: Helpful when writing shell scripts; allow the use of OSI OIDs and DCE UUIDs when used with the -O and -U options |
%a for attribute %s for string %i for identifier %v for attribute value (only fn_attr_syntax_ascii is currently supported) |
Example: |
The following three examples are equivalent. % fnsearch name "color == 'red'" % fnsearch name "%a == 'red'" color % fnsearch name "%a == %s" color red |
Wild card strings |
*, *string, string*, str*ing, %s* |
Extended operators |
'name'(wildcarded_string), 'reftype'(identifier), 'addrtype' (identifier) |
Example: |
Search for objects with names starting with "Bill" and IQ attributes over 80. % fnsearch name "'name'('bill'*) and IQ > 80" |
See the fnsearch man page for detailed information about creating search patterns.
The fnattr command lets you update and examine attributes associated with FNS named objects. You can perform four attribute operations with the fnattr command:
fnattr -a [-s] name [-O|-U] identifier values |
fnattr -d name [[-O|-U] identifier [values]] |
fnattr -m name [-O|-U identifier oldvalue newvalue |
fnattr -l name [[-O|-U] identifier |
Option |
Description |
---|---|
name |
Composite name. |
identifier |
Attribute name. |
values |
One or more attributes values |
oldvalue |
The attribute value that you want to change. |
newvalue |
The new attribute value. |
-aa |
Add (create) a new attribute |
-d |
Delete an attribute |
-m |
Change (modify) an attribute |
-l |
List attribute values |
-s |
Add in "supersede" mode. Removes any existing values for the identifier attribute and creates new attribute values. |
-l |
List attributes and values. |
-O |
Use an OSI OID as the identifier |
-U |
Use a DCE UUID as the identifier |
In each of these cases, the identifier format is FN_ID_STRING, unless the option -O or -U is used.
The -a option is for adding an attribute or adding a value to an attribute. Specify the composite name the attribute is associated with, the attribute identifier, and the values to add.
fnattr -a [-s] name [-O | -U] identifier value1 [value2+] |
The following example adds the attribute identifier model and the value hplaser to thisorgunit/service/printer.
# fnattr -a thisorgunit/service/printer model hplaser |
The -s option means "add in supersede" mode. If an attribute with the specified identifier already exists, -s removes all of its values and replaces them with the values added. If this option is omitted, the resulting values for the specified attribute includes the existing values and the new values added.
# fnattr -as thisorgunit/service/printer model hplaser |
The example above will first remove any existing values associated with model and add hplaser as the value.
To delete an attribute associated with an FNS named object, use the -d option.
fnattr -d name [[-O | -U] identifier value1 [value2+]]] |
You can control what to delete:
Name only. If only the composite name is specified and no attribute identifier is specified, all the attributes associated with the named object are removed.
Name and identifier only. If only the composite name and an attribute identifier is specified, but no attribute values are specified, the entire attribute identified by identifier is removed.
Name, identifier, and values. If the composite name, an attribute identifier, and one or more attribute values are specified, then only those values are removed from the attribute. (Removal of the last remaining value of an attribute is the same as removing the attribute itself.)
For example, to delete all the attributes associated with thisorgunit/service/printer.
# fnattr -d thisorgunit/service/printer |
The -l option is for listing attributes and their values.
fnattr -l name [[-O | -U] identifier] |
For example to list the values of the model attribute of thisorgunit/service/printer.
# fnattr -l thisorgunit/service/printer model laser postscript |
If an identifier is not specified, all the attributes associated with the named object are displayed.
The -m option lets you modify an attribute value.
fnattr -m name [-O | -U] identifier old_value new_value |
For example, to replace the value postscript with laser you would enter:
# fnattr -m thisorgunit/service/printer model postscript laser |
Only the specified values are affected. Other attributes and values associated with the name are not affected.
The -O option assumes the format of the attribute identifier is an ASN.1 dot-separated integer string list (FN_ID_ISO_OID_STRING).
The -U option assumes the format of the attribute identifier is a DCE UUID string form (FN_ID_DCE_UUID).