Oracle® Application Server Release Notes
10g (9.0.4) for Solaris Operating System (SPARC) Part No. B10629-15 |
|
![]() Previous |
![]() Next |
This chapter describes issues associated with Oracle Ultra Search. It includes the following topics:
This section describes general issues and their workarounds for Oracle Ultra Search. It includes the following topics:
Section 13.1.2, "Upgrading to Oracle Application Server 10g"
Section 13.1.4, "Security Considerations When Using Restricting Access to a Data Source"
Section 13.1.5, "Oracle Ultra Search Reconfiguration After Database Character Set Change"
Section 13.1.6, "Crawl of Data Source with Multibyte Name Fails"
Section 13.1.7, "Crawling Data in ISO-2022-JP Character Set Fails"
Section 13.1.8, "Oracle Ultra Search does not Support All Database Character Sets"
Oracle Ultra Search uses a set of codes to indicate the crawling result of the crawled URL. Besides the standard HTTP status codes, it uses its own codes for non-HTTP related issues. Only URLs with a status of 200 will be indexed. Table 13-1 lists the Oracle Ultra Search status codes.
Table 13-1 Oracle Ultra Search Crawler URL Status Codes
Code | Description |
---|---|
200 |
URL OK |
400 |
Bad Request |
401 |
Authorization required |
402 |
Payment required |
403 |
Access forbidden |
404 |
Not found |
405 |
Method not allowed |
406 |
Not acceptable |
407 |
Proxy authentication required |
408 |
Request timeout |
409 |
Conflict |
410 |
Gone |
414 |
Request-URI too large |
500 |
Internal server error |
501 |
Not implemented |
502 |
Bad gateway |
503 |
Service unavailable |
504 |
Gateway timeout |
505 |
HTTP version not supported |
902 |
Timeout reading document |
903 |
Filtering failed |
904 |
Out of memory error |
905 |
IOEXCEPTION in processing URL |
906 |
Connection refused |
907 |
Socket bind exception |
908 |
Filter not available |
909 |
Duplicate document detected |
910 |
Duplicate document ignored |
911 |
Empty document |
951 |
URL not indexed |
952 |
URL crawled |
953 |
Metatag redirection |
954 |
HTTP redirection |
955 |
Black list URL |
956 |
URL is not unique |
957 |
Sentry URL (URL as a placeholder) |
958 |
Document read error |
959 |
Form login failed |
1001 |
Data type is not TEXT/HTML |
1002 |
Broken network data stream |
1003 |
HTTP redirect location does not exist |
1004 |
Bad relative URL |
1005 |
HTTP error |
1006 |
Error parsing HTTP header |
1007 |
Invalid URL table column name |
1008 |
JDBC driver missing |
1009 |
Binary document reported as text document |
1010 |
Invalid display URL |
Per the Oracle Application Server 10g Upgrading to 10g (9.0.4) document, you must apply database 9.0.1.5 patch set before you upgrade Oracle9iAS 9.0.2 to Oracle Application Server 10g.
After you apply the patch set, do not perform the following post install actions as described in the patch set note:
"Execute the following steps only if you have installed Oracle Ultra Search in the database you are attempting to modify."
Instead, perform the following post install steps:
CONNECT / AS SYSDBA
GRANT SELECT ON SYS.DBMS_LOCK_ALLOCATED TO WKSYS;
ALTER USER WKSYS ACCOUNT UNLOCK;
ALTER PACKAGE WKSYS.WK_CRW COMPILE BODY;
ALTER PACKAGE WKSYS.WK_SNAPSHOT COMPILE BODY;
Oracle Ultra Search can only crawl public Oracle AS Portal sources. See the Oracle Application Server Portal Configuration Guide for how to set up public pages.
This section covers important security considerations when using a single ACL to restrict access to a data source.
An Oracle Ultra Search data source can be protected by a single administrator specified ACL. This ACL specifies which users and groups are allowed to view the documents belonging to that data source.
Oracle Ultra Search uses the Oracle Server's ACL evaluation engine to evaluate permissions when queries are performed by search users. This ACL evaluation engine is a feature of Oracle XML database. If an Oracle Ultra Search query attempts to retrieve a document that is protected by an administrator specified ACL, the ACL is evaluated and subsequently cached.
The duration an ACL is cached is controlled by an XDB configuration parameter. See the chapter titled "Oracle XML DB Resource Security" in Oracle XML DB Developer's Guide. The XDB documentation indicates that the /xdbconfig/sysconfig/acl-max-age
parameter should be modified. The value is a number in seconds that determines how long ACLs are cached. See the chapter on "Installing and Configuring Oracle XML DB" for information on altering this configuration parameter.
Because ACLs are cached, it is important to remember that changes to an administrator specified ACL may not propagate immediately. This only applies to database sessions that existed before the change was made.
Two SQL scripts (wk0prefcheck.sql
and wk0idxcheck.sql
) under $ORACLE_HOME/ultrasearch/admin/
are used for this reconfiguration.
wk0prefcheck.sql
is invoked under wksys
to reconfigure default cache character set and index preference.
wk0idxcheck.sql
is needed for reconfiguring instance(s) created before database character set change; for example, the default instance. This script must be invoked by the instance owner and wk0prefcheck.sql
must be run first as it depends on reconfigured default settings generated by wk0prefcheck.sql
.
Running wk0idxcheck.sql
will also drop and recreate the Oracle Text index used by Oracle Ultra Search. So, if there are already data sources indexed, then you must re-crawl all of the data sources.
Note that wk0idxcheck.sql
must be run once for each instance. If there are two instances "inst1" and "inst2" owned by "owner1" and "owner2" respectively, then wk0idxcheck.sql
should be run twice; once by "owner1" and once by "owner2".
An Oracle Ultra Search crawl of a data source with a multibyte name will fail. An error of the file not being found occurs if the local environment that starts the Oracle database is not compatible with the locale's target files.
To correct this problem, you must set the correct locale, restart the Oracle database, and force Oracle Ultra Search to re-crawl the data source.
For example:
Shutdown the Oracle database instance with the following command:
SQL> shutdown immediate
Set the locale to 'ja'
using the following commands:
> setenv LANG ja > setenv LC_ALL ja
Restart the Oracle database instance with the following command:
SQL> startup
Restart the Oracle Ultra Search schedule with a forced re-crawl.
If you plan to use Ultra Search on data in the ISO-2022-JP character set, then you must download SUN's JDK 1.4.2_04 or later, install it on the host machine(s) of the Ultra Search backend (that is, the database where the Ultra Search schema resides), and point the Ultra Search backend to the new JDK installation.
To point the Ultra Search backend to a particular JDK (in other words, to set the JDK that is to be used for running the Ultra Search crawler), run the ORACLE_HOME/ultrasearch/admin/wkrepca.sql
script with SQL*Plus. You must connect as the wksys
user and pass to the script the path to the JDK installation. For example:
sqlplus wksys/schema_password @ORACLE_HOME/ultrasearch/admin/wkrepca.sql /usr/local/jdk1.4/bin/java
Oracle Ultra Search does not support database character sets that are not supported by Oracle Text. For example, the AL32UTF8 character set is not supported.
For Unicode support, use UTF8.
For the complete list of supported database character sets, see the Oracle Text Reference for Lexer Types.
When upgrading to Oracle Application Server 10g, the Oracle Ultra Search Configuration Assistant may fail while upgrading to Oracle Identity Management. This occurs because the WKSYS
password that is changed using SQL
is not synchronized with the password in the OracleAS Metadata Repository.
To prevent configuration assistant failure:
Start Oracle Directory Manager with the following command:
% $ORACLE_HOME/bin/oidadmin
Log in to Oracle Directory Manager as the orcladmin
user.
In the System Objects frame:
expand Entry Management
expand cn=OracleContext
expand cn=Products
expand cn=OracleAS
expand cn=OracleAS Infrastructure Databases
expand the orclReferenceName
for the OracleAS Metadata Repository.
Select the OrclResourceName
entry for schema WKSYS
.
Select the Properties tab to view the randomized password in the orclpasswordattribute
field.
Use sqlplus
to login to the OracleAS Infrastructure 10g OracleAS Metadata Repository.
sqlplus /nolog
Perform the following commands:
SQL> CONNECT / AS SYSDBA SQL> ALTER USER WKSYS IDENTIFIED BY <randomized password>
For Oracle Ultra Search, installation of OracleAS RepCA is not a schema only installation; it is the full installation and configuration of the Oracle Ultra Search backend. Oracle recommends that you backup your existing ORACLE_HOME/ultrasearch
directory and then copy the new version of Oracle Ultra Search from the OracleAS RepCA installation disc to the Oracle home directory.
For Oracle Application Server Real Application Clusters (RAC) where the Oracle home is not on a Cluster File System, the copy of new information into the Oracle home is not complete. The Oracle Ultra Search installation from the OracleAS RepCA installation disc is not applied to each Oracle Application Server instance in the RAC. You must backup each existing ORACLE_HOME/ultrasearch
directory and copy the new version of Oracle Ultra Search from the OracleAS RepCA installation disc for each Oracle home of the RAC.
Bug 3186386: Creating or Editing Oracle Ultra Search ACLs Fails in Non-SSO Mode
An Oracle Ultra Search Administrator can log in as a database administrator or an SSO user who has been granted administrative privileges. In this release, when logging in as a database administrator, then under certain circumstances, the administrator will not be able to create nor edit administrator-specified ACLs for a data source. An "Access Denied" error will be encountered when attempting to create or modify ACLs. The workaround is to always log in as an SSO user in order to create/modify ACLs for a data source.
Bug 3411206: Default instance has incorrect indexing preference if database character set is UTF8 or any Asian language character set
The default instance is created along with the seed database and is set to English/ISO8859. During installation, if you choose to have a database character set (for example, UTF8) that handles multibyte languages like Chinese, then the default instance should be updated. The workaround for this is to run $ORACLE_HOME/ultrasearch/admin/wk0prefcheck.sql
under wksys
to confirm the index preference setting, and then run $ORACLE_HOME/ultrasearch/admin/wk0idxcheck.sql
under the instance owner to correct the problem. All data sources (if any) under the default instance will need to be recrawled. If the database character set is JA16EUC, then you should apply the workaround for bug 3411046 first.
Bug 3411046: Wrong filter output character set for database character set change to JA16EUC
If the database character set has been changed to JA16EUC after Ultra Search installation and wk0prefcheck.sql
or wk0idxcheck.sql
has been run, then the cache file character set will be set to a wrong value 'EUC_JP'. The workaround is to modify the line "Encoding:= 'EUC_JP' " in wk0prefcheck.sql
and wk0idxcheck.sql
to "Encoding:= 'Unicode' " and then to rerun wk0prefcheck.sql
and wk0idxcheck.sql
.
Bug 3318301: Korean lexer is not available if the database character set is KO16MSWIN949
Korean document indexing is not available if the database character set is KO16MSWIN949.
There is the same problem for Japanese lexer if the database character set is JA16EUCTILDE, JA16EUCYEN, JA16SJISTILDE or JA16SJISYEN.
There is the same problem for Chinese lexer if the database character set is ZHS32GB18030, ZHT16MSWIN950 or ZHT16HKSCS.
The workaround is to obtain an updated wk0prefcheck.sql
and wk0idxcheck.sql
to patch the installation. An updated wk0pref.sql
is needed if Ultra Search is reinstalled.
XML DB Dependency—the following two XML database bugs are identified in the 9.2.0.4 database release. They will be fixed in post 9.2.0.4 database patch release.
Bug 3172282: Oracle Core Dumps When an Attempt Is Made to List All Aces for a Specific ACL
When using Oracle 9.2.0.4, the Oracle Ultra Search Administrators will not be able to view administrator specified ACLs after creation. As a result, these ACLs cannot be edited or modified. Administrators must therefore assume responsibility for keeping track of permissions specified in these ACLs. Furthermore, because ACLs cannot be viewed, they cannot be edited. As a result, if an ACL has to be changed, you must drop the existing data source, re-create it, and assign a new ACL with the new permissions.
Bug 3176161: Updating resource_view
with updatexml
Causes Core Dump
When using Oracle 9.2.0.4, this bug prevents ACLs stored in the XDB repository from being updated. Therefore, even if bug 3172282 is fixed (and the administrator can view an administrator specified ACL after creation), the ACL cannot be successfully edited. As a result, if an ACL has to be changed, you must drop the existing data source, re-create it, and assign a new ACL with the new permissions.
Oracle Ultra Search can be installed on top of an existing Oracle 9i (9.0.1.4) or later database. This can be done in one of two ways:
Oracle Application Server Repository Creation Assistant (OracleAS RepCA) converts a customer database into an OracleAS Metadata Repository. OracleAS RepCA will install all of the Oracle Application Server component schemas and also install the Oracle Ultra Search backend.
OracleAS RepCA is only available in the Oracle Application Server release. OracleAS RepCA is the recommended way of installing Oracle Ultra Search backend onto a customer database. Although there is the overhead of having all the other Oracle Application Server component schemas installed along with Oracle Ultra Search, you will get the benefits of OracleAS Infrastructure 10g (for example, Identity Management Integration, well defined processes for IM re-association, and so forth).
For details on how to use OracleAS RepCA to create an MR, see the "Using an Existing Database for the OracleAS Metadata Repository" section of the Oracle Application Server 10g Installation Guide.
IMPORTANT: For Oracle Ultra Search, there is a required post-OracleAS RepCA install configuration step. Oracle Ultra Search crawler is a Java application that requires JDK 1.4.1 or later. Oracle Ultra Search is configured by OracleAS RepCA to use the default JDK installation (for example, $ORACLE_HOME/jdk/bin/java
), which in the pre-10g ORACLE_HOME
is pre-JDK 1.4.1; thus, unless your $ORACLE_HOME/jdk/bin/java
is already JDK 1.4.1 or later, you must perform the following steps:
Install JDK 1.4.1 or later on the local system.
Go to the ultrasearch/admin
directory of the OracleAS RepCA CD. Then run the wkrepca.sql
script in SQL*Plus. You must connect as the wksys
user and pass to the script the path to the JDK 1.4.1 or later Java executable. For example:
sqlplus wksys/wksys password@repca_cd/ultrasearch/admin/wkrepca.sql /usr/local/jdk1.4/bin/java
If you want to install only the Oracle Ultra Search backend into a customer database, you can opt for manual installation of Oracle Ultra Search backend. To illustrate this process here, we use the following values and conventions:
ORACLE_HOME—the Oracle home directory of the target database
SH — the source directory, the directory on the OracleAS RepCA CD, that contains the Oracle Ultra Search directory (for example OracleAS RepCA)
Following are the steps involved in a manual installation of the Oracle Ultra Search backend:
Back up the $ORACLE_HOME/ultrasearch
directory. You can do this by renaming this directory to $ORACLE_HOME/ultrasearch.old
.
Copy SH
/ultrasearch
to $ORACLE_HOME/ultrasearch
.
Change directory to $ORACLE_HOME/ultrasearch/admin
.
If the Oracle Ultra Search schema wksys
already exists on the target database then de-install it by running the following:
@ sqlplus /nolog @$ORACLE_HOME/ultrasearch/admin/wk0deinst.sql sysSYSPW
CSTR
See the following section for the meaning of each parameter.
Run the SQL*Plus script wk0setup.sql
.
For example:
sqlplus /nolog @$ORACLE_HOME/ultrasearch/admin/wk0setup.sql $ORACLE_HOME CSTR sys SYSPW 'as sysdba' WKSYSPW TBLSPC TMPTBLSPC portal CFS oui PSEP JDBCDRV JDBCNLS JEXEC CTXHX JDBC_NODE JDBC_ALL $ORACLE_HOME
where the various parameters are as follows (parameters should be enclosed in single quotes to avoid misinterpretation):
CSTR
—TNS alias preceded with '@'
(for example, @inst1
), this parameter can also be passed in as a single white space (' ')
SYSPW
—password for the SYS user/schema
WKSYSPW
—password to be used for the Oracle Ultra Search schema wksys
TBLSPC
—tablespace for wksys
TMPTBLSPC
—temporary tablespace for wksys
CFS
—if ORACLE_HOME
is on a Cluster File System (CFS) then 'true'; else 'false'
PSEP
—path separator (for example, on UNIX this is ':', on Windows it is ';')
JDBCDRV
—path to JDBC drivers, classes12.zip
(for example, $ORACLE_HOME/jdbc/lib/classes12.zip
)
JDBCNLS
—path to nls_charset12.zip
or orai18.jar
(for example, $ORACLE_HOME/jdbc/lib/nls_charset12.zip
)
JEXEC
– Java executable path (for example, /packages/jdk1.4.1/bin/java
). Note that this has to point to a JDK 1.4.1 or later installation
CTXHX
– path to INSOFILTER
, ctxhx
(for example, $ORACLE_HOME/ctx/bin/ctxhx
)
JDBC_NODE
– thin JDBC connect string, and only the part after the '@' (for example, HOST
:
PORT
:
SID
); note that in case of RAC, this connect string must be to the current node
JDBC_ALL
– same as JDBC_NODE
, but in case of RAC with CFS true, this JDBC string should include all the RAC nodes (hint: use TNS syntax)
If the database character set has been changed after Oracle Ultra Search installation, then you must reconfigure the Oracle Ultra Search backend so that it can adapt to the new character set.
Two SQL scripts (wk0prefcheck.sql
and wk0idxcheck.sql
), located in $ORACLE_HOME/ultrasearch/admin/
, are used for this reconfiguration:
wk0prefcheck.sql
is invoked under wksys to reconfigure default cache character set and index preferences.
Running wk0idxcheck.sql
also drops and re-creates the Oracle Text index used by Oracle Ultra Search. If there are already data sources indexed, you must force a re-crawl of all of the data sources.
wk0idxcheck.sql
must be run once for each instance. For example, if there are two instances, "inst1" and "inst2," owned by "owner1" and "owner2," respectively, then wk0idxcheck.sql
should be run twice: once by "owner1" and once by owner2.
wk0idxcheck.sql
is needed for reconfiguring instance(s) created before the database character set change (for example, the default instance). This script must be invoked by the instance owner, and wk0prefcheck.sql
must be run first, as it depends on reconfigured default settings generated by wk0prefcheck.sql
.
This section describes documentation errata for the Oracle Ultra Search User's Guide. It includes the following topics:
Section 13.3.3, "Section 2.2.2 - Configure a Secure Oracle Ultra Search Installation"
Section 13.3.5, "Section 2.5.4.1 - Configuring the Middle Tier with Oracle HTTP Server and OC4J"
Section 13.3.6, "Section 2.5.4.5 - Editing the ultrasearch.properties File"
Section 13.3.7, "Section 2.6.2 Configuring the Backend on Remote Crawler Hosts"
Section 13.3.8, "Section 5.1.1 - Ultra Search Security Model"
References to the "temporary directory" in the tuning and administration chapters should read "cache directory" instead.
Oracle Ultra Search only supports the "Crawl ACLs from the Data Source" mode for user-defined data source types where the crawler agent retrieves the ACL from the data source along with other document attributes. You cannot get ACL from a data source if it is a Web, table, portal, email, or file type.
With agent APIs, there is a new URL property "UrlData.ACL" that allows the agent to set the ACL of the URL submitted. There is also a new AclHelper
class in the Agent APIs. This generates the ACL string to make sure that the ACL string format is correct.
Only Distinguished Name (DN) and Global User Id (GUID) can be used as the principal of an ACL.
The following additions and corrections apply to setting up a secure Oracle Ultra Search installation. Before you can set up a secure Oracle Ultra Search installation, you must:
Install or upgrade the Oracle Database version 9.2.0.4 or higher. The document incorrectly reads version 10.1.0 or higher.
Install Oracle Internet Directory. The middle tier and IM (identity management) version should be 9.0.4 or higher.
The document currently states that you can use OracleAS RepCA to convert a 9.2.0.4 database to an Oracle Application Server 9.0.4 metadata repository. It should add that you can do this if you have a 9.2.0.4 database.
Register the database to Oracle Internet Directory.
You can use OracleAS RepCA to register the database to Oracle Internet Directory. After registration, you need to perform these manual steps:
Add the distinguished name of the database to the database server parameter file, spfile.ora, as an RDBMS_SERVER_DN initialization parameter value.
Restart the database, so that the new initialization parameter takes effect.
Configure the Oracle-Oracle Internet Directory SSL link (previously, the "SSL" was omitted). To establish a secure connection between database and Oracle Internet Directory, follow the instructions in the following books:
Configuring Oracle Internet Directory for SSL: "Secure Sockets Layer (SSL) and the Directory," chapter in the Oracle 9.2 release of the Oracle Internet Directory Administrator's Guide
Configuring the database for SSL: "Managing Enterprise User Security" chapter (Part II, Task 1 - Task 3), in the Oracle Database 9.2 release of the Oracle Advanced Security Administrator's Guide
Also, the reference to the Oracle Database Administrator's Guide for details on configuring the database to use Oracle Identity Management and Oracle Internet Directory should be ignored.
If you checked the "OracleAS Portal" option on the "Configuration Options" Oracle Installer screen, then the configuration steps in the following section are automatically performed by the Oracle Portal Configuration Assistant (OPCA).
You do not need to perform any additional manual steps as indicated in the section text ("Editing the data-sources.xml File"). Everything is configured automatically.
For application.xml
file, under the <orion-application>
tag, change the following:
Change:
<library path="$ORACLE_HOME/ultrasearch/lib/ultrasearch_query.jar" /> <library path="$ORACLE_HOME/ultrasearch/webapp/config" /> <library path="$ORACLE_HOME/jlib/uix2.jar" /> <library path="$ORACLE_HOME/jlib/share.jar" /> <library path="$ORACLE_HOME/jlib/regexp.jar" /> <library path="$ORACLE_HOME/lib/mail.jar" /> <library path="$ORACLE_HOME/lib/activation.jar" /> <library path="$ORACLE_HOME/lib/xmlparserv2.jar" /> <library path="$ORACLE_HOME/jdbc/lib/nls_charset12.zip" /> <library path="$ORACLE_HOME/jdbc/lib/classes12.jar" />
to:
<library path="$ORACLE_HOME/ultrasearch/lib/ultrasearch_query.jar" /> <library path="$ORACLE_HOME/ultrasearch/webapp/config" /> <library path="$ORACLE_HOME/jlib/uix2.jar" /> <library path="$ORACLE_HOME/jlib/share.jar" /> <library path="$ORACLE_HOME/jlib/regexp.jar" /> <library path="$ORACLE_HOME/jdbc/lib/nls_charset12.zip" /> <library path="$ORACLE_HOME/jlib/repository.jar"/> <library path="$ORACLE_HOME/jlib/ohw.jar"/> <library path="$ORACLE_HOME/jlib/ldapjclnt9.jar"/> <library path="$ORACLE_HOME/j2ee/home/jazn.jar"/> <library path="$ORACLE_HOME/portal/jlib/ptlshare.jar"/> <library path="$ORACLE_HOME/portal/jlib/pdkjava.jar"/>
For the default-web-site.xml
under the <web-site>
tag, add the following:
Change:
<web-app application="UltrasearchAdmin" name="admin" root="/ultrasearch/admin" /> <web-app application="UltrasearchQuery" name="query" root="/ultrasearch/query"/> <web-app application="UltrasearchPortlet" name="query" root="/provider/ultrasearch" />
To:
<web-app application="UltrasearchQuery" name="query" root="/ultrasearch/query"/> <web-app application="UltrasearchQuery" name="welcome" root="/ultrasearch" /> <web-app application="UltrasearchAdmin" name="admin" root="/ultrasearch/admin" /> <web-app application="UltrasearchAdmin" name="admin_sso" root="/ultrasearch/admin_sso" /> <web-app application="UltrasearchAdmin" name="ohw" root="/ultrasearch/ohw" />
The content of the ultrasearch.properties
file has changed.
Here is an example of the ultrasearch.properties
file:
connection.driver=oracle.jdbc.driver.OracleDriver #If set, The JDBC connection URL specified here will override the dynamically #acquired one from OID. #This setting is also used by the 9i query sample (gsearch.jsp) #Example: connection.url=jdbc:oracle:thin:@<host>:<port>:<sid> connection.url=%JDBC_CONN_STR% oracle.net.encryption_client=REQUESTED oracle.net.encryption_types_client=(RC4_56,DES56C,RC4_40,DES40C) oracle.net.crypto_checksum_client=REQUESTED oracle.net.crypto_checksum_types_client=(MD5) oid.app_entity_cn=m16bi.sgtcnsun03.cn.oracle.com domain=us.oracle.com
You no longer need to configure the JDBC connect string in the ultrasearch.properties
file. The database connect information is taken from Oracle Internet Directory.
Note: The Oracle Ultra Search 9i query sample pages (gsearch.jsp ) will no longer work out of the box. You must use a separate property file or edit the ultrasearch.properties file.
|
Step 4 should read as follows:
4. Invoke the registration script.
Start up SQL*Plus as the WKSYS
super-user and enter the following:
@full_path_of_registration_script
The registration script for RMI-based remote crawling is the following:
$REMOTE_ORACLE_HOME/ultrasearch/tools/remotecrawler/scripts/<platform>/register.sql
The registration script for JDBC-based remote crawling is the following:
$REMOTE_ORACLE_HOME/ultrasearch/tools/remotecrawler/scripts/<platform>/register _jdbc.sql
For example, if the value for $REMOTE_ORACLE_HOME
on a UNIX host is /home/oracle9i
, then enter the following at the SQL*Plus prompt to register an RMI-based remote crawler:
/home/oracle9i/ultrasearch/tools/remotecrawler/scripts/unix/register.sql
Likewise, if you are running SQL*Plus on Windows, and $REMOTE_ORACLE_HOME
is in d:\Oracle\Oracle9i
, then enter the following at the SQL*Plus prompt to register a JDBC-based remote crawler:
d:\Oracle\Oracle9i\ultrasearch\tools\remotecrawler\scripts\winnt\register_jdbc.sql
For Oracle Ultra Search to access secure Web sites, you may need to import certificates into the crawler's trust store and the Oracle Containers for J2EE (OC4J) JVM's trust store.
The Oracle Ultra Search administration tool is a Web application that runs within the OC4J JVM. Secure portal instances require clients to authenticate with SSL. To discover page groups in secure portal instances, the Oracle Ultra Search administration tool must make HTTPS network calls.
By default, the OC4J JVM recognizes certificates of well-known certificate authorities. However, if the secure portal instance uses a self-signed certificate or a certificate signed by an unknown certificate authority, then you must import the portal's certificate into the OC4J JVM's truststore. This can be done with the keytool utility provided by Sun Microsystems.
The OC4J JVM default truststore is located at $ORACLE_HOME/jdk/jre/lib/security/cacerts
.
See Also: Sun Microsystems documentation for more information about using Sun's keytool key and certificate management utility, for information on customization of the SSL service, and for information on truststore management.OracleAS Containers for J2EE documentation for information on configuring OC4J to use a different truststore. |