Oracle9i Net Services Administrator's Guide Release 2 (9.2) Part Number A96580-02 |
|
|
View PDF |
This chapter explains how to export data stored in a tnsnames.ora
file or an Oracle Names server to an LDAP-compliant directory server.
This chapter contains these topics:
See Also:
"Directory Server Support" for an overview of directory server support of Oracle Net Services |
If a tnsnames.ora
file already exists, its net service names can be exported to a directory server. The export is performed for one domain at a time.
The tasks to export data from a tnsnames.ora
file are as follows:
Task 1: Create Structure in Directory Server
Task 2: Create Oracle Contexts
Task 3: Configure Directory Server Usage
Task 4: Export Objects To a Directory Server
In the directory server, create the directory information tree (DIT) with the structure in which you want to import net service names. Create the structure leading up to the top of the Oracle Context.
For example, if the tnsnames.ora
file supports a domain structure acme.com
and you want to replicate this domain in the directory, then create domain component entries of dc=com
and dc=acme
in the directory, as depicted in Figure 10-1.
You can replicate the domain structure you currently use with tnsnames.ora
, or you can develop an entirely different structure. Introducing an entirely different structure can change the way in which clients enter the net service name in the connect string. Therefore, Oracle Corporation recommends considering relative and absolute naming issues prior to changing the structure.
See Also:
|
Create an Oracle Context under each DIT location that you created in Task 1. The Oracle Context has a relative distinguished name (RDN) of cn=OracleContext
. The Oracle Context stores network object entries, as well as other entries for other Oracle components. In Figure 10-2, cn=OracleContext
is created under dc=acme,dc=com
.
To create the Oracle Context, you must use Oracle Net Configuration Assistant. to create a DIT structure that looks similar to the one in Figure 10-2.
See Also:
|
If not already done as a part of creating the Oracle Contexts, configure the Oracle home for directory server usage. The Oracle home you configure should be the one that will perform the export.
See Also:
Chapter 8, "Setting Up Directory Server Usage" for further information about configuring directory server usage |
To export net service names contained in a tnsnames.ora
file to a directory:
tnsnames.ora
file you want to export is not the one loaded into Oracle Net Manager, then use File > Open Network Configuration to select the tnsnames.ora
file to export to the directory.The Directory Server Migration Wizard starts.
If net service names with multiple domain were detected in the tnsnames.ora
file, then the Select Domain page appears. Continue to Step 5.
If the net service names are not domain qualified, the Select Net Service Names page appears. Skip to Step 6.
The Select Net Service Names page appears.
The Select Destination Context page appears.
The Directory Server Update page appears with the status of the export operation.
Database and alias objects stored in an Oracle Names server can be exported directly to a directory server or indirectly to an LDAP Data Interchange Format (LDIF) file, which can then be used to load the directory server. When exporting the database objects, only the address record (A.SMD
) is exported. The address record contains the connect descriptor information for the database object. Database objects are exported as net service names. Aliases are exported as net service aliases.
Data is exported from a specified domain. Any subdomains within the region can
This section contains the following topics:
Notes:
|
See Also:
|
New client installations with directory server usage configuration can use directory naming entries when the following tasks are completed:
However, only clients that are upgraded to 9.2 can use net service alias entries.
To export data for newer client configurations, follow the procedure in "Exporting Data to a Directory Server".
For release 8.1.6 or later clients without directory server usage or pre-release 8.1.6 clients that do not support directory naming, you have two configuration choices. You can:
If you continue to use Oracle Names servers, data stored in Oracle Names servers and directory server must be maintained and synchronized separately.
Oracle Names LDAP Proxy servers are Oracle Names servers that have been configured to proxy for directory servers. Upon startup, Oracle Names LDAP Proxy servers obtain network object information from the directory server. This provides a single point of definition for all data in the directory server and does not require that data in both Oracle Names server and directory server be maintained separately and simultaneously.
To export data for older client configurations, follow the procedures in both "Exporting Data to a Directory Server" and "Configuring Oracle Names LDAP Proxy Servers".
To export global database links to a directory server, ensure that the database is release 2 (9.2). Otherwise, you must configure Oracle Names LDAP Proxy servers, as described in "Configuring Oracle Names LDAP Proxy Servers".
The tasks to export data from an Oracle Names server are as follows:
Task 1: Create Structure in Directory Server
Task 2: Create Oracle Contexts
Task 3: Configure Directory Server Usage
Task 4: Obtain List of Objects to Export
Task 5: Export Objects To a Directory Server
In the directory server, create the DIT with the structure in which you want to import Oracle Names objects. Create the structure leading up to the top of the Oracle Context.
For example, if Oracle Names has a domain structure acme.com
and you want to replicate this domain in the directory, then create domain component entries dc=com
and dc=acme
in the directory, as depicted in Figure 10-3.
You can replicate the domain structure you currently use with Oracle Names, or you can develop an entirely different structure. Introducing an entirely different structure will change the way in which clients enter the connect identifier in the connect string. Therefore, Oracle Corporation recommends that you consider the relative and absolute naming issues prior to changing the structure.
See Also:
|
Create an Oracle Context with Oracle Net Configuration Assistant under each DIT location that you created in Task 1. The Oracle Context has a RDN of cn=OracleContext
. Oracle Contexts may be required for the root domain and each of its delegated domains. If you are using Oracle Internet Directory, you can use the Oracle Context created at the root of the DIT structure. This root Oracle Context has a complete DN of dn:cn=OracleContext
. For most deployments, you will need to create additional Oracle Contexts.
In Figure 10-4, cn=OracleContext
is created under dc=acme,dc=com
.
See Also:
|
If not already done as a part of creating the Oracle Contexts, configure the Oracle home for directory server usage. The Oracle home you configure should be the one that will perform the export.
See Also:
Chapter 8, "Setting Up Directory Server Usage" for further information about configuring directory server usage |
Determine the Oracle Names domain structure and the objects within that structure. The Oracle Names Control utility offers commands described in Table 10-1 to help you with this task.
Command | Description |
---|---|
|
Lists all of the authoritative domains See Also: |
|
Lists all of the delegated domains See Also: |
|
Lists all of the authoritative network objects See Also: |
The Oracle Names Control utility enables you to export network objects from a domain into the directory server using the DUMP_LDAP
and DUMP_ALIAS
commands.
Use the DUMP_LDAP
command to export names and addresses of database objects. Use the DUMP_ALIAS
command to export net service aliases. You can export these objects directly to a directory server or indirectly to an LDIF file, which can then be used to the load the exported objects to the directory server.
To run the DUMP_LDAP
and DUMP_ALIAS
commands.
DUMP_LDAP
command from an authoritative Oracle Name server for the domain.
The syntax to export data directly to a directory server is as follows:
namesctlNAMESCTL> DUMP_LDAP [
source
] [
destination
] [
options]
{-h host} {-p port} {-D user_dn} {-w password}
The syntax to export data to a LDIF file is as follows:
namesctl NAMESCTL> DUMP_LDAP [source] [destination] [options] {-f[
filename]
}
DUMP_ALIAS
command:
The syntax to export data directly to a directory server is as follows:
namesctlNAMESCTL> DUMP_ALIAS [
source
] [
destination
] [
options]
{-h host} {-p port} {-D user_dn} {-w password}
The syntax to export data to a LDIF file is as follows:
namesctl NAMESCTL> DUMP_ALIAS [source] [destination] [options] {-f[
filename]
}
See Also:
|
If the directory server's DIT structure has been designed to match the current Oracle Names structure, review the following examples to understand how to export data. These examples demonstrate the use of the DUMP_LDAP
command. These examples also can be applied to net services aliases, except the DUMP_ALIAS
command must be used in place of the DUMP_LDAP
command.
See Also:
|
Figure 10-5 shows an Oracle Names domain structure of acme.com
. It contains a database object called db
. The DIT has been designed with domain entries that match the Oracle Names domain structure. With this DIT structure, db.acme.com
can be exported to cn=OracleContext,dc=acme,dc=com
.
Either of the following syntaxes exports data from Oracle Names to the configured DIT structure:
NAMESCTL> DUMP_LDAP acme.com (dn:dc=acme,dc=com) -f sample.ldif NAMESCTL> DUMP_LDAP acme.com -f sample.ldif
In the first line of syntax, the destination distinguished name (DN), excluding cn=OracleContext
, is explicitly specified. It is not necessary to specify the destination DN, as shown in the second line of syntax, because the destination DIT structure is domain based and matches the domain model used in Oracle Names. Note that cn=OracleContext
is automatically inserted.
The database object db
is exported to cn=OracleContext,dc=acme,dc=com
and has a DN location of cn=db,cn=OracleContext,dc=acme,dc=com
.
Data can be exported from a root domain and its delegated domains in Oracle Names to a directory server that uses a similar DIT in one step rather than one domain at a time.
Figure 10-6 shows an Oracle Names structure that contains a root domain of acme.com
and delegated domains of sales.acme.com
and dev.acme.com
. Database objects db
, orders
, and widgets
reside in acme.com
, sales.acme.com
and dev.acme.com
, respectively. The directory server's DIT is similar to the Oracle Names domain structure.
The following syntax exports data from the acme.com
root domain and its delegated domains to the configured DIT structure:
NAMESCTL> DUMP_LDAP acme.com -R -f sample.ldif
The following table shows how database objects in acme.com
, sales.acme.com
, and dev.acme.com
are mapped to DNs in the directory server.
If you are not ready to upgrade clients to a version that supports directory naming, you must use Oracle Names LDAP Proxy servers. Oracle Names LDAP Proxy servers enable these clients to look up data in the directory server.
Generally, client configurations do not require modification. However, if the directory server's DIT structure does not match the Oracle Names domain structure, you must also reconfigure the NAMES.DEFAULT_DOMAIN
parameter in the sqlnet.ora
file to point to the new domain structure.
See Also:
"Configuring a Default Domain for Clients" for instructions |
The tasks to create Oracle Names LDAP Proxy servers are as follows:
Task 1: Upgrade Oracle Names Servers to 9i
Task 2: Start Oracle Names Servers
Task 3: Populate the Directory Server
Task 4: Configure Oracle Names Servers as Proxies
Upgrade all Oracle Names servers within a region to 9i. Releases prior to 9i do not support Oracle Names LDAP Proxy servers.
Start each of the Oracle Names servers to generate the cktop.ora
file. Use either Oracle Net Manager or the Oracle Names Control utility.
Use Oracle Net Manager... | Use Oracle Names Control utility... |
---|---|
From the command line, enter:
|
Starting with release 9.0, an Oracle Names server creates a ckptop.ora
file in $ORACLE_HOME/network/names
on UNIX and ORACLE_HOME
\network\names
on Windows NT, or in the file specified by the names.ora
file parameter NAMES.TOPOLOGY_CHECKPOINT_FILE
. This file contains topology data that defines the domains in the administrative region and the Oracle Names servers that have authority for them. Specifically, topology data consists of definitions for all parent domains and Oracle Names servers in the region. The Oracle Names servers use this information to understand the structure of the domain tree.
Oracle Names LDAP Proxy servers require the generated ckptop.ora
file. If the Oracle Names structure has multiple administrative regions, Oracle Corporation recommends mirroring the current Oracle Names domain structure in the directory DIT structure. Using a different structure may require modifying the topology defined for the Oracle Names LDAP Proxy servers. Support for topology modification is not currently supported. The following constitutes a topology change:
If you have not already done so, populate the directory:
See Also:
"Configuring Directory Usage After Installation" for instructions on creating an Oracle Context |
ldap.ora
file.
To do this, select the Select the directory server you want to use option in Oracle Net Configuration Assistant.
Configure each Oracle Names server within a region to load directory server information from a specific DN.
To configure Oracle Names servers as proxy servers:
Use Oracle Net Manager... | Use Oracle Names Control utility... |
---|---|
From the command line, enter:
|
NAMES.ADMIN_REGION
parameter in the names.ora
file to the directory server's DN or read the directory server's DN from an LDIF input file.
The syntax for an Oracle Names LDAP Proxy server to load the data from a directory server is as follows:
NAMES.ADMIN_REGION=
(REGION=
(TYPE=ldap) [(USERID=user_dn)] [(PASSWORD=password)] [(HOST=host)] [(PORT=port)] [(TIMEOUT=time)] [(SUBTREE_LIST=] [(SUBTREE=(BASE=base_DN)[(SCOPE=sub|one))] [(SUBTREE=(BASE=base_DN)[(SCOPE=sub|one))] [)])
Values from equivalent ldap.ora
file parameters are used as defaults for the USER
, HOST
, and SUBTREE
(with SCOPE=one
) parameters.
Table 10-2 describes how to set the NAMES.ADMIN_REGION
subparameters.
Subparameter | Description |
---|---|
|
Specify that the Oracle Names LDAP Proxy server is to load data directly from a directory server. |
|
(Optional) This entry is necessary if data is restricted. Specify a directory user with read privileges in the form of a DN. For example, Note: Do not prefix the DN with |
|
(Optional) This entry is required if data is restricted. Specify the password for the directory user. |
|
(Optional) Specify the directory server host name. |
|
(Optional) Specify the listening TCP/IP port for the directory server. |
|
(Optional) Specify the time limit in seconds that the Oracle Names LDAP Proxy server can spend performing a search of directory objects. This time limit cannot be greater than the time limit set for searches in the directory server. By default, the time limit is set to 10 seconds, which is sufficient for most searches. See Also: "Increasing Search Size Limit" for instructions for increasing the time limit of |
|
(Optional) Use the
Note: Do not prefix the DN with "
|
The following example shows an Oracle Names LDAP Proxy server configured to load the data from an Oracle Context that is directly under the DN dc=acme,dc=com
and all Oracle Contexts under the DN subtree dc=us,dc=acme,dc=com
.
NAMES.ADMIN_REGION= (REGION= (TYPE=LDAP) (HOST=ldap-server) (PORT=389) (SUBTREE_LIST= (SUBTREE=(BASE=dc=acme,dc=com)) (SUBTREE=(BASE=dc=us,dc=acme,dc=com)(scope=sub))))
The syntax for an Oracle Names LDAP Proxy server to load the data from an LDIF file is as follows:
NAMES.ADMIN_REGION=
(REGION=
(TYPE=ldif) [(FILE=ldif_file)]))
Table 10-3 describes how to set the NAMES.ADMIN_REGION
subparameters.
The following example shows an Oracle Names LDAP Proxy server configured to load data from LDIF file onames.ldif
.
NAMES.ADMIN_REGION= (REGION= (TYPE=LDIF) (FILE=/private/eminer/nn/9i/proxy/onames.ldif))
The following LDIF file excerpt shows a DN of cn=sales,cn=OracleContext,dc=acme,dc=com
and cn=hr,cn=OracleContext,dc=acme,dc=com
for net service names sales
and hr
.
dn: cn=sales,cn=OracleContext,dc=us,dc=acme,dc=com objectclass: top objectclass: orclNetService cn: sales orclNetDescString: (DESCRIPTION=(ADDRESS_ LIST=(ADDRESS=(PROTOCOL=tcp)(Host=sales-server)(Port=1521)))(CONNECT_ DATA=(SERVICE_NAME=sales.us.acme.com))) dn: cn=hr,cn=OracleContext,dc=us,dc=acme,dc=com objectclass: top objectclass: orclNetService cn: hr orclNetDescString: (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(COMMUNITY=TCP_ COMMUNITY)(PROTOCOL=tcp)(Host=hr-server)(Port=1521)))(CONNECT_DATA=(SERVICE_ NAME=hr.us.acme.com)))
The following LDIF file excerpt shows a DN of cn=mysales,cn=OracleContext,dc=acme,dc=com
for net service alias mysales
.
dn: cn=mysales,cn=oracleContext,dc=acme,dc=com objectclass: top objectclass: alias objectclass: orclNetServiceAlias cn: mysales aliasedobjectname: cn=mysales,cn=OracleContext,dc=us,dc=acme,dc=com
Run each of the Oracle Names servers with the new configuration. Use either Oracle Net Manager or the Oracle Names Control utility.
Use Oracle Net Manager... | Use Oracle Names Control utility... |
---|---|
From the command line, enter:
|
See Also:
"Oracle Names LDAP Proxy Server Error Reporting" region load operation troubleshooting advice |
If the directory server's DIT structure has been designed with a DIT that is dissimilar to the current Oracle Names domain structure, review the following examples to understand how to export data. These examples demonstrate the use of the DUMP_LDAP
command. Examples 1 through 3 also can be applied to net service aliases, except the DUMP_ALIAS
command must be used in place of the DUMP_LDAP
command.
See Also:
"Considerations for Net Service Aliases" for limitations of the |
Figure 10-7 shows an Oracle Names domain structure of acme.com
. It contains a database object called db
. The directory server has been designed with a DIT of cn=OracleContext,o=acme,c=us
.
The following syntax exports data from the acme.com
domain to the configured DIT structure:
NAMESCTL> DUMP_LDAP acme.com (dn:c=us,o=acme) -f sample.ldif
Because the DIT is different from the Oracle Names structure, the destination DN must be explicitly specified. cn=OracleContext
is automatically pre-appended to the left of the destination DN; you do not need to explicitly specify cn=OracleContext
in the DN.
Data can be exported from an Oracle Names administrative region to a directory server that uses a dissimilar DIT. RDNs in the destination DN must be specified without a value for the delegated domains.
Figure 10-8 shows an Oracle Names structure that contains a root domain of acme.com
and delegated domains of sales.acme.com
and dev.acme.com
. Database objects of db
, orders
, and widgets
reside in acme.com
, sales.acme.com
and dev.acme.com
, respectively. The directory server's DIT has a top-level structure of o=acme,c=us
that correlates to acme.com
in Oracle Names. The subtrees, ou=sales
and ou=dev
, correlate to the sales.acme.com
and dev.acme.com
delegated domains in Oracle Names.
The following syntax exports data from the acme.com
root domain and its delegated domains to the configured DIT structure:
NAMESCTL> DUMP_LDAP acme.com (dn:ou,o=acme,c=us) -R -f sample.ldif
Note that organizational unit (ou
) contains no value, so that the sales
and dev
subdomain of acme.com
in the source region can be mapped to an ou
.
The following table shows how database objects in acme.com
, sales.acme.com
, and dev.acme.com
are mapped to DNs in the directory server. All objects are exported to cn=OracleContext
RDNs in the directory server.
If acme.com
contained a subdomain of mktg.dept.acme.com
, network objects in that subdomain would not be exported. This is because the destination DN template ou,o=acme,c=us permits only one level of delegated domains. In order to export objects from mktg.dept.acme.com
, the following syntax would be required:
NAMESCTL> DUMP_LDAP acme.com (dn:ou,ou,o=acme,c=us) -f sample.ldif
This syntax enables up to two levels of delegated domains to be exported. By adding additional attributes, you can specify any level of depth.
Data can be exported from multiple domains to one node in the destination DIT.
Figure 10-9 shows an Oracle Names structure that contains a root domain of acme.com
and delegated domains of sales.acme.com
and dev.acme.com
. Database objects of db
, orders
, and widgets
reside in acme.com
, sales.acme.com
and dev.acme.com
, respectively. The directory server's DIT has a structure of o=IS,c=uk
that contains no subtrees that correlate to the Oracle Names delegated domains.
All data can be exported from the root domain and the delegated domains to cn=OracleContext,o=IS,c=uk
in the DIT with the following syntax:
NAMESCTL> DUMP_LDAP acme.com (dn:o=IS,c=uk) -R -f sample.ldif
The following table shows how database objects in acme.com
, sales.acme.com
, and dev.acme.com
are mapped to DNs in the directory server. All objects are exported to cn=OracleContext
RDNs in the directory server.
If one of the delegated domains contained a database object named db
, it would not be exported. This is because the db
database object's name would conflict with the db
object exported from db.acme.com
.
In the previous examples, you saw how data can be exported to a non-DC DIT and how data can be exported from multiple domains to a one node in the DIT. This example combines these two types of exports to demonstrate how to export data to a DIT with a very different structure.
Figure 10-10 shows an Oracle Names structure that contains a root domain of acme.com
and four delegated domains, each of which contains at least one database object. The directory server's DIT has a top-level structure of dc=acme,dc=com
that correlates to the acme.com
domain in Oracle Names. The two subtrees, dc=intranet
and dc=storefront
, are unrelated to the delegated domains in Oracle Names.
In order to export data from the Oracle Names domain structure to the DIT, each domain must be exported separately:
DUMP_LDAP IS.acme.com (dn:dc=intranet,dc=com,dc=acme) -f sample.ldif DUMP_LDAP hr.acme.com (dn:dc=intranet,dc=com,dc=acme) -f sample.ldif DUMP_LDAP warehouse.acme.com (dn:dc=storefront,dc=com,dc=acme) -f sample.ldif DUMP_LDAP sales.acme.com (dn:dc=storefront,dc=com,dc=acme) -R -f sample.ldif
The first two DUMP_LDAP
commands export database objects to cn=Oraclecontext,dc=intranet,dc=acme,dc=com
. The last two DUMP_LDAP
commands export database objects to cn=Oraclecontext,dc=storefront,dc=acme,dc=com
. The -R
option in the DUMP_LDAP sales.acme.com
command enables the database objects to be exported from sales.acme.com
, europe.sales.acme.com
, and pacific.sales.acme.com
.
The following table shows how database objects in the Oracle Names domains are mapped to DNs in the directory server. All objects are exported to cn=OracleContext
RDNs in the directory server.
Using the DUMP_ALIAS
command is similar to the DUMP_LDAP
command, except for the following limitations:
If an alias is exported and the object it is referencing is not exported, then the DUMP_ALIAS
command exports the alias without verifying that the referenced object exists.
If an alias and the object it is referencing are exported with different destinations, then the net service alias will not contain the correct name for the object it is referencing. This can occur in a case of tree rearrangement.
Figure 10-11 illustrates this point. It shows an Oracle Names structure with a root domain of acme.com
that contains aliases of ordersalias
, dbalias
, and widgetsalias
. These aliases reference objects orders.sales.acme.com
, db.acme.com
, and widgets.dev.acme.com
, respectively. The directory's DIT structure is rearranged. Data that was in the sales
domain is exported to marketing
and data in dev
is exported to RandD
. However, the net services aliases remain in o=acme,c=us
.
The following syntax exports objects db
, orders
, and widgets
:
NAMESCTL> DUMP_LDAP acme.com (dn:o=acme,c=us) -f sample.ldif NAMESCTL> DUMP_LDAP dev.acme.com (dn:ou=RandD,o=acme,c=us) -f sample.ldif NAMESCTL> DUMP_LDAP sales.acme.com (dn:ou=marketing,o=acme,c=us) -f sample.ldif
The following table shows how database objects in the Oracle Names domains are mapped to DNs in the directory server:
The following command exports aliases ordersalias
, dbalias
, and widgetsalias
and the data for the referenced objects to o=acme,c=us
:
NAMESCTL> DUMP_ALIAS acme.com (dn:ou,o=acme,c=us) -R -f sample.ldif
The following table shows how aliases and data for reference objects are mapped to DNs in the directory server. It also describes what happens when a client attempts to look up of one of the net service aliases in the directory.