How to Replicate FNS Under Files-Based Naming
There is no server replication when your primary naming service is files-based.
FNS Administration, Problem Solving, and Error Messages
FNS Error Messages
FNS messages are encapsulated in the FN_status_t object as status codes. See the FN_status_t man page for the corresponding status codes.
When an error occurs, FNS commands print out the remaining part of the name on which the operation failed. The part of the name that has not been printed has been processed successfully.
For example, a user attempted to create a context for org//service/trading/bb. The name org//service/ was resolved successfully, but trading was not found in the context named by org//service/. Thus, trading/bb is displayed as the part of the name that remains when the operation failed:
Error in creating 'org//service/trading/bb': Name Not Found: 'trading/bb' |
In another example, a user attempted to destroy the context org//service/dictionary/english, but could not carry out the operation because the context named was not empty. The pair of single quotes ('') indicates that FNS was able to resolve the complete name given, but could not complete the operation as requested:
Error in destroying 'org//service/dictionary/english': Context Not Empty: '' |
DNS Text Record Format for XFN References
The Solaris environment conforms to the XFN specification for federating global naming systems within DNS. In order to federate a naming system under DNS, you need to enter information into DNS TXT resource records. This information is then used to construct an XFN reference for that subordinate naming system. This chapter describes the format of these DNS TXT records.
See "Getting Started" for the procedures needed to federate DNS.
For details on how to manipulate records in DNS in general, see DNS and BIND in a Nutshell, by Paul Albitz and Crickett Liu (O'Reilly and Associates, 1992).
The reference type of an XFN reference is constructed from a TXT record that begins with the XFNREF tag. It has the following format:
TXT "XFNREF rformat reftype" |
If spaces occur within the string appearing after TXT, such spaces must be escaped, or the entire string must be enclosed within double quotation marks. The three fields, XFNREF, rformat and reftype, are separated using space (spaces and tabs). rformat specifies format of the reference type identifier. It can be one of the following:
reftype specifies the contents of the reference type identifier.
If no XFNREF TXT record exists, the reference type defaults to an identifier XFN_SERVICE, with an FN_ID_STRING format. If more than one XFNREF TXT record exists, the handling of the record is undefined. The following TXT record is equivalent to the default XFNREF:
TXT "XFNREF STRING XFN_SERVICE" |
The address information for an XFN reference is constructed using TXT records with tags prefixed with the XFN string. Multiple addresses may be specified for a single reference. Records with the same tag are grouped and passed to the handler for each group. Each handler generates zero or more addresses from its group of TXT records and appends the addresses to the reference. The XFNREF tag is special in that it is used only to construct the reference type and thus, it is excluded from the address-construction process.
The syntax of address TXT records is as follows:
XFNaddress_type_tag address_specific_data |
The two fields, XFN_address_type_tag and address_specific_data, are separated using space (spaces and tabs). The address_type_tag specifies the handler to be used for address_specific_data.
TXT records have a limitation of 2K bytes of characters per record. If the address-specific data is too long to be stored in a single TXT record, multiple TXT records may be used, as shown:
TXT "XFNaddress_type_tag address_specific_data1" TXT "XFNaddress_type_tag address_specific_data2" |
When the tag-specific handler is called, both records are passed to it. The handler is responsible for determining the order in which these two lines need to be interpreted.
The order in which TXT records appear is not significant. If lines with different tags are present, lines with the same tag are grouped together before the tag-specific handler is called. In the following example, the handler for tag1 will be called with two text lines, and the handler for tag2 will be called with three text lines.
TXT "XFNtag1 address_specific_data1" TXT "XFNtag2 address_specific_data2" TXT "XFNtag1 address_specific_data3" TXT "XFNtag2 address_specific_data4" TXT "XFNtag2 address_specific_data5" |
Here are some examples of TXT records that can be used for XFN references.
Example 1
TXT "XFNREF STRING XFN_SERVICE" TXT "XFNNISPLUS doc.com. nismaster 129.144.40.23" |
Example 2
TXT "XFNREF OID 1.3.22.1.6.1.3" TXT "XFNDCE (1 fd33328c4-2a4b-11ca-af85-09002b1c89bb...)" |
The following is an example of a DNS table with a subordinate naming system bound in it.
$ORIGIN test.doc.com
@ IN SOA foo root.eng.doc.com (
100 ;; Serial
3600 ;; Refresh
3600 ;; Retry
3600 ;; Expire
3600 ;; Minimum
)
NS nshost
TXT "XFNREF STRING XFN_SERVICE"
TXT "XFNNISPLUS doc.com. nismaster 129.144.40.23"
nshost IN A 129.144.40.21
|
X.500 Attribute Syntax for XFN References
This section contains supplemental information about the use of X.500 attributes for XFN references. In order to permit an XFN reference to be stored as an attribute in X.500, the directory schema must be modified to support the object classes and attributes defined in this chapter.
See "Getting Started" for the procedures needed to federate X.500.
See Managing the X.500 Client Toolkit for information about modifying the X.500 directory schema.
Object Classes
Two new object classes, XFN and XFN-supplement, are introduced to support XFN references. The XFN object class is not relevant in FNS since the Sun Microsystems X.500 directory product cannot support the introduction of new compound ASN.1 syntaxes. Instead, FNS uses the XFN-supplement object class.
The two new object classes are defined in ASN.1 as follows:
xFN OBJECT-CLASS ::= {
SUBCLASS OF { top }
KIND auxiliary
MAY CONTAIN { objectReferenceId |
objectReference |
nNSReferenceId |
nNSReference }
ID id-oc-xFN
}
id-oc-xFN OBJECT IDENTIFIER ::= {
iso(1) member-body(2) ansi(840) sun(113536)
ds-oc-xFN(24)
}
xFNSupplement OBJECT-CLASS ::= {
SUBCLASS OF { top }
KIND auxiliary
MAY CONTAIN { objectReferenceString |
nNSReferenceString }
ID id-oc-xFNSupplement
}
id-oc-xFNSupplement OBJECT IDENTIFIER ::= {
iso(1) member-body(2) ansi(840) sun(113536)
ds-oc-xFNSupplement(25)
}
|
The XFN-supplement object class is defined as an auxiliary object class so that it may be inherited by all X.500 object classes. It is defined with two optional attributes: