| Oracle® Application Server Release Notes 10g (10.1.4.0.1) for Solaris Operating System (x86) and Solaris Operating System (x86-64) Part Number B32092-01 |
|
|
View PDF |
| Oracle® Application Server Release Notes 10g (10.1.4.0.1) for Solaris Operating System (x86) and Solaris Operating System (x86-64) Part Number B32092-01 |
|
|
View PDF |
This chapter describes issues associated with Oracle Internet Directory. It includes the following topics:
This section describes general issues and their workarounds. It includes the following topics:
If you use standard database backup and restore procedures, such as those performed by the Oracle Application Server Backup and Recovery Tool, you must perform a full database backup after any of the following administrative tasks:
Using the bulkload bulk management tool
Using the catalog bulk management tool
Installing Oracle Internet Directory
Upgrading Oracle Internet Directory to a major release version or patchset
Installing an LDAP application against Oracle Internet Directory, such as Oracle Collaboration Suite, that modifies the cn=catalogs entry to add orclindexedattribute
If you do not perform a full backup after using the bulkload bulk management tool, you might encounter unrecoverable errors when performing a restore. The bulkload utility performs a direct path load, which does not generate redo logs. If you do not perform a full backup after performing a bulkload, and later perform a restore that attempts to apply archived redo logs, you might encounter errors that cannot be fixed.
If you do not perform a full backup after any of the other four tasks, you might encounter recoverable errors when performing a restore. Performing any of those tasks might create indexes with the NOLOGGING option, which means that redo logs are not created for the index. If you do not perform a full backup after one of these operations, and later perform a restore that attempts to apply archived redo logs, you might see errors upon restart of Oracle Internet Directory. Specifically, you would see ORA-1578 and ORA-2640 errors in oidmon.log or oidldapd*.log. In this case, shut down Oracle Internet Directory and recreate all Oracle Internet Directory database indexes by typing:
bulkload connect="conn_str" index="TRUE"
With the 10g (10.1.4.0.1) release, Oracle Internet Directory introduces a new restriction for Access Control Lists (orclaci and orclentrylevelaci attributes). Specifically, you cannot specify attribute names that are not defined in directory schema. As a result, while adding or migrating entries from previous Oracle Internet Directory releases, the load operation will fail if any entries have attribute names that are not defined in the directory schema.
To avoid this problem, in the LDIF file, comment out any ACLs that have undefined attributes.
For example, the following 10g Release 2 (10.1.2) entry uses undefined attributes that are identified with bold text:
orclaci: access to attr=(orclUserApplnProvStatus,orclUserApplnProvStatusDesc, orclUserProvFailureCount) by group="cn=oracledasedituser,cn=groups, cn=OracleContext,dc=us,dc=oracle,dc=com" (read,search,write,compare) by group="cn=oracledascreateuser,cn=groups,cn=OracleContext,dc=us,dc=oracle, dc=com" (read,search,write,compare) by self (read,search,nowrite,compare) by * (none)
To avoid this problem, comment the entry as follows, before loading or verifying the LDIF file.
# orclaci: access to attr=(orclUserApplnProvStatus,orclUserApplnProvStatusDesc, # orclUserProvFailureCount) by group="cn=oracledasedituser,cn=groups, # cn=OracleContext,dc=us,dc=oracle,dc=com" (read,search,write,compare) by # group="cn=oracledascreateuser,cn=groups,cn=OracleContext,dc=us,dc=oracle, # dc=com" (read,search,write,compare) by self (read,search,nowrite,compare) # by * (none)
When you add a new directory to a directory replication group, you copy entries from an existing directory to the new directory using the ldifwrite and bulkload tools.
Normally, the easiest way to do this is to specify a replication agreement DN as the basedn argument to ldifwrite. This causes the ldifwrite tool to dump all entries that are replicated by the specified replication agreement. Then you can load the entries to another replicated directory using bulkload tool.
In release 10g (10.1.4.0.1), this functionality does not work when the replication agreement DN is orclagreementid=000001,cn=replication configuration, which is the DN of an Advanced replication agreement. The workaround is to explicitly specify the DN of the DIT that you want to copy as the base DN argument to ldifwrite.
This section describes configuration issues and their workarounds. It includes the following topics:
If your server locale is not English, set NLS_LANG to AMERICAN_AMERICA.AL32UTF8 before running bulkload.
This section describes documentation errata. It includes the following topics:
The document links from the Related Documents help pages for Identity Management Grid Control Plug-in and Oracle Internet Directory Server Manageability are broken. Please navigate to the documents from http://www.oracle.com/technology/documentation.
The following command line appears in the HTML version of Appendix I of Oracle Internet Directory Administrator's Guide, Section I.6.2, "Tasks To Be Performed on the New Advanced Replication Node," Step 18:
$> sqlplus rep_admin_db_account_name/password@db_conn_str_of_new_nodeSQL> exec dbms_repcat.drop_master_repgroup( gname => 'LDAP_REP' )
There should be a line break before SQL>. That is, the command should be:
$> sqlplus rep_admin_db_account_name/password@db_conn_str_of_new_node SQL> exec dbms_repcat.drop_master_repgroup( gname => 'LDAP_REP' )
