|
Oracle9i Application Server Release Notes Addendum,
Release 2 (9.0.2) for AIX-Based Systems, hp HP-UX PA-RISC (64-bit), hp Tru64 UNIX, and Linux x86 Part No. A97395-09 |
|
|
|
|
Oracle9i Application Server Release Notes Addendum,
Release 2 (9.0.2) for AIX-Based Systems, hp HP-UX PA-RISC (64-bit), hp Tru64 UNIX, and Linux x86 Part No. A97395-09 |
|
|
|
|
This chapter summarizes issues associated with Oracle9i Application Server. Topics include:
This section contains the following topics:
Login Problems for Oracle Enterprise Manager of Secondary Instance
Microsoft Internet Explorer Fails in Chinese Environment on DAS
Deployment of Applications to OC4J When the Default User Manager is Principals
Language Help Files Missing for APAC, OC_4J, and IASTOP_HELP.JAR
Concurrent Administrative Operations on a Cluster Not Supported
Directing Requests to OC4J Instances in Different Oracle Homes
Metrics and Rollup Stats May Not Be Visible on Oracle9iAS Home Page
Do Not Use dcmctl and EMD Concurrently to Manage an Instance
You cannot log on to OEM of a secondary instance after it is made active during deinstall of first instance. As a workaround, perform the following steps:
After deinstalling the first instance and making the second instance OEM active, go to ORACLE_HOME/bin and issue "emctl set password" command with a new password.
You will not be able to access OEM using the new password until you restart emctl. In addition, "emctl stop" will not work as the password will not be accepted. When you issue "emctl start" directly, assuming the OEM service is up and running, the following option appears:
An instance of EMD is already running. Do you want to shut it down first [Y or N]
Select "Y" and click enter.
The status shows is:
Waiting for EM to initialize... Started.
Access the EM Web site using the new password
In addition, use this workaround before any subsequent installs on the same host.
Using Microsoft Internet Explorer 5.5 in a Simplified Chinese environment, you are unable to go to the next step, or edit/delete "Attribute" on "Configure User Attribute" page. For example:
Login to http://<hostname>:<port>/oiddas/
Click Configuration tab -> User Entry tab.
Go to second step "Configure User Attribute".
Click Next, or Edit, Delete. On this page, you cannot access the corresponding page, but stay in this page. The browser status bar displays "Error on Page".
The workaround is to use Netscape 4.7 to access the DAS component in a simplified Chinese environment.
Japanese text is not readable when running in a Japanese environment. This affects three help modules:
OID Server Manageability
Discoverer OEM help system
BC4J Help
The workarounds are as follows:
For Oracle Internet Directory Server Manageability:
Extract file to fix:
jar xvf ORACLE_HOME/sysman/webapps/emd/online_help/oidsm/oidsm_help_ja.jar oidsm.hs
Using a text editor, ensure the character set in the following line is specified as "Shift_JIS":
<xml version='1.0' encoding="Shift_JIS">
Convert oidsm.hs from "EUC" format to "SJIS" format.
Replace the fixed file:
jar cvf ORACLE_HOME/sysman/webapps/emd/online_help/oidsm/oidsm_help_ja.jar oidsm.hs
For Discoverer Oracle Enterprise Manager Help System:
Extract the following file to fix:
jar xvf ORACLE_HOME/sysman/webapps/emd/online_help/disco/disco_help_ja.jar disco.hs jar xvf ORACLE_HOME/sysman/webapps/emd/online_help/disco/disco_help_ja.jar disco.xml
Using a text editor, ensure the character set in the following line is specified as "Shift_JIS":
<xml version='1.0' encoding="Shift_JIS">
Convert disco.hs and toc.xml from "unicode" format to "SJIS" format.
Replace the fixed file:
jar uvf ORACLE_HOME/sysman/webapps/emd/online_help/disco/disco_help_ja.jar disco.hs jar uvf ORACLE_HOME/sysman/webapps/emd/online_help/disco/disco_help_ja.jar toc.xml
In a similar fashion, extract all nine HTML files from this.jar file, and add the following line to each file, within the <head> section:
<meta http-equiv=content-type content="text/html; charset=Shift_JIS">
For BC4J:
Extract file to fix:
jar xvf ORACLE_HOME/sysman/webapps/emd/online_help/bc4j/bc4j_help_ja.jar bc4j.hs
Delete the following lines:
<view>
<label>index</label> <type>oracle.help.navigator.keywordNavigator.KeywordNavigator</type> <data engine="oracle.help.engine.XMLIndexEngine">index.xml</data>
</view> Add the following lines.
Add the following lines:
<view>
<label>contents</label> <type>oracle.help.navigator.tocNavigator.TOCNavigator</type> <data engine="oracle.help.engine.XMLTOCEngine">toc.xml</data>
</view>
Replace the fixed file:
jar uvf ORACLE_HOME/sysman/webapps/emd/online_help/bc4j/bc4j_help_ja.jar bc4j.hs
With the default logging level, some of the Oracle Enterprise Manager Web Site log files become very large.
As a workaround, edit the logging properties configuration file and increase the logging level used by the Enterprise Manager software. The logging level can be set to INFO, WARN, or ERROR. When it is set to INFO, all informational messages are saved in the log files. When it is set to WARN, all warning messages are saved to the file. To reduce the amount of disk space required by the log files, do the following:
Edit the logging.properties file, which is located in <ORACLE_HOME>/sysman/config/logging.properties.
Change all occurrences of "INFO" and "WARN" to "ERROR".
Save the file and restart the Enterprise Manager Web site.
|
See Also: Oracle9i Application Server Administrator's Guide for information about restarting Oracle Enterprise Manager. |
For Japanese language version only, certain graphic (gif) files are missing from the ORACLE_HOME/classes/oracle/sysman/help/detailpanels_ja directory. The workaround is to copy the gif files from the ORACLE_HOME/classes/oracle/sysman/help/detailpanels directory (English files). If you are using the Enterprise Manager Web Site, you should also copy the gif files from ORACLE_HOME/oem_webstage/oracle/sysman/help/detailpanels into ORACLE_HOME/oem_webstage/oracle/sysman/help/detailpanels_ja.
Also, some Japanese files are installed into the wrong directory. Under ORACLE_HOME/classes/oracle/sysman/help/detailpanels_ja and ORACLE_HOME/oem_webstage/oracle/sysman/help/detailpanels_ja, the following files are installed into platform-specific subdirectories:
dv_advque.htm
dv_dguard.htm
dv_inst.htm
dv_logm.htm
dv_olap.htm
dv_schm.htm
dv_secu.htm
dv_stg.htm
The files are located under the "euc for solaris" subdirectory. The workaround is to copy the files for your platform from the subdirectory into the detailpanels_ja directory.
Each OC4J instance has a global application called "default" that is the parent application of all applications deployed to the instance. This will use jazn-xml as the user manager by default.
If the user manager for this application is changed to "principals", and you attempt to deploy an application using Oracle Enterprise Manager, the deployment will fail if changes are made on the "Select User Manager" page.
Thus, if the user manager for the default application of an OC4J instance is changed to be "principals", for future application deployments using Oracle Enterprise Manager, you should not visit the "Select User Manager" page in the wizard. The application will then be deployed successfully - with principals as its user manager. However, the summary screen of the deployment wizard will show jazn-xml as the user manager. Any changes you wish to make to the application's user manager can then be completed by drilling down to the application properties page.
Language help files are missing for APAC, OC_4J, and IASTOP_HELP.jar. Instead of Japanese files, Enlist help files are included in the following jar:
ORACLE_HOME/sysman/webapps/emd/online_help/apch/apch_help_ja.jar ORACLE_HOME/sysman/webapps/emd/online_help/oc_4j/oc_4j_help_ja.jar ORACLE_HOME/sysman/webapps/emd/online_help/iastop/iastop_help_ja.jar
Concurrent administrative operations on a cluster are not supported in Oracle9iAS. Configuration information for clusters is stored in a central repository. All members of the cluster have access to this repository. This keeps configuration consistent across the cluster. Since the objects in the repository are shared across the cluster, concurrent write access to these objects is not allowed.
This section describes how to direct requests to OC4J instances running on Oracle homes that are different from the one that first received the request. In other words, Oracle HTTP Server receives a request, then forwards it to an OC4J instance that belongs to a different Oracle home. In that Oracle home, OC4J instances are running, but Oracle HTTP Server may or may not be running. The Oracle homes can be installed on the same machine or different machines.
This scenario is different from clusters. In a cluster, all the Oracle9iAS instances are configured identically, and mod_oc4j sends requests to the instances in the cluster in a round-robin fashion. See the "Application Server Clustering" chapter in the Oracle9i Application Server Administrator's Guide for details on clustering.
In this scenario, the Oracle9iAS instances do not need to be the same type: they can be different mid-tier types and they can be configured differently. You can even direct requests between an infrastructure and a mid-tier type. See Section 6.1.9.3, "Directing Requests between Infrastructure and Mid-Tier" for details.
For this to work, your environment must have the following characteristics:
The Oracle homes must belong to the same farm (that is, they use the same metadata repository).
The targeted Oracle home must have the desired OC4J instances (for example, OC4J_Portal, OC4J_DAS, OC4J_Wireless) and the OC4J instance must be running.
The application must be deployed on the OC4J instance to which you want to route the request. In addition, the application must have the same URL prefix as on the local instance.
The mid-tier may be clustered with other identically configured mid-tier installations.
The procedure for directing requests to another Oracle home is to edit the Oc4jConf directive in the ORACLE_HOME/Apache/Apache/conf/mod_oc4j.conf file. The directive maps URLs to OC4J instances.
By default, the directive directs requests to OC4J instances in the local Oracle home (the OC4J instances belong to the same host:port specified in the URL).
For example, the following lines route requests that begin with /webapp and /portal to the home and OC4J_Portal OC4J instances on the local Oracle9iAS instance, respectively:
Oc4jMount /webapp/* home Oc4jMount /portal/* OC4J_Portal
To direct requests to an OC4J instance on another Oracle home, you prepend the name of the Oracle9iAS instance to the OC4J instance name, and you use the keyword "instance".
Syntax:
Oc4jMount url instance://ias_instance_name1:oc4j_instance_name [, ias_instance_name2:oc4j_instance_name, ...] Oc4jMount url cluster://cluster_name1:oc4j_instance_name [, cluster_name2:oc4j_instance_name, ...]
where:
instance is a keyword.
cluster is a keyword.
url specifies the URL for the application.
ias_instance_nameN specifies the names of Oracle9iAS instances. These instances can run on the same or different machine. The instance name includes the machine name. See Section 6.1.9.6, "Determining Oracle9iAS Instance Names" for details.
If you specify more than one instance name, the requests are sent to the instances in a round-robin manner.
cluster_nameN specifies the names of the clusters to which you want to direct the requests. Oracle HTTP Server distributes the requests to the Oracle9iAS instances in the cluster. See Section 6.1.9.8, "Determining Cluster Names" for details.
For clustering details, see the "Application Server Clustering" chapter in the Oracle9i Application Server Administrator's Guide.
oc4j_instance_name specifies the name of the OC4J instance name on the Oracle9iAS instance. See Section 6.1.9.7, "Determining OC4J Instance Names" for details.
For example, the following lines direct the requests to instances on an Oracle9iAS instance called "pw.machine2.us.oracle.com". The instances are running on a machine called "machine2.us.oracle.com".
Oc4jMount /webapp/* instance://pw.machine2.us.oracle.com:home Oc4jMount /portal/* instance://pw.machine2.us.oracle.com:OC4J_Portal
The syntax allows you to specify more than one instance to which to direct the requests. You separate the instances with the comma character. For example, the following line directs /portal/* requests to the OC4J_Portal instance running on machine2 and machine3 (all on one line):
Oc4jMount /portal/* instance://pw.machine2.us.oracle.com:OC4J_Portal, pw.machine3.us.oracle.com:OC4J_Portal
In the example above, the pw.machine2.us.oracle.com and the pw.machine3.us.oracle.com Oracle9iAS instances do not need to be the same install type, but they do need to be running the OC4J_Portal instance.
The syntax also allows you to direct requests to clusters. Oracle HTTP Server distributes the requests to the Oracle9iAS instances in the cluster.
The following example directs requests to OC4J_Portal instances in Oracle9iAS instances in the forms_cluster cluster.
Oc4jMount /portal/* cluster://forms_cluster:OC4J_Portal
A specific situation where you might want to redirect requests is where you have installed the Oracle9iAS infrastructure and a mid-tier install type on the same machine, but in different Oracle homes. You have Oracle HTTP Server processes running from both Oracle homes; they listen at different port numbers. Figure 6-1 shows such a situation: a machine, called machine1, has two Oracle homes. The infrastructure Oracle HTTP Server listens at port 7777, and the mid-tier Oracle HTTP Server listens at port 7780.
You now want to reduce the number of Oracle HTTP Server processes. One way of doing this is to configure Oracle HTTP Server running on one Oracle home (infrastructure's or mid-tier's) so that it can be the front-end to the other Oracle home. Two scenarios are possible:
You can configure Oracle HTTP Server running on the infrastructure Oracle home so that it can be the front-end to the mid-tier as well. This enables you to shut down Oracle HTTP Server processes running from the mid-tier Oracle home. See Section 6.1.9.4, "Directing Requests through the Infrastructure".
You can configure Oracle HTTP Server running on the mid-tier Oracle home so that it can be the front-end to the infrastructure as well. This enables you to shut down Oracle HTTP Server processes running from the infrastructure Oracle home. See Section 6.1.9.5, "Directing Requests through the Mid-Tier".
In both scenarios, the Oracle9iAS instances are different (infrastructure and mid-tier installation types) and thus cannot be clustered together.
The following table lists the advantages and disadvantages of consolidating Oracle HTTP Servers:
Table 6-1 Advantages and disadvantages of consolidating Oracle HTTP Servers
| Advantages | Disadvantages |
|---|---|
|
|
In this scenario (Figure 6-2), you shut down the Oracle HTTP Server running on the mid-tier. All requests goes through the Oracle HTTP Server running on the infrastructure Oracle home.
Figure 6-2 Using Only the Infrastructure Oracle HTTP Server
To enable the infrastructure Oracle HTTP Server to handle these requests, you have to do the following step:
Configure the mod_oc4j.conf file on the infrastructure
To configure the mod_oc4j.conf file on the infrastructure:
Make a copy of the infrastructure mod_oc4j.conf file, so that you have a backup.
Copy the Oc4jMount lines from the mid-tier mod_oc4j.conf to the infrastructure mod_oc4j.conf.
Note that there are some lines that are the same in both the infrastructure and mid-tier files. Do not copy these lines from the mid-tier file (that is, use the lines already in the infrastructure file).
The list below shows the lines in the mid-tier mod_oc4j.conf file.
|
Note: Your list ofOc4jMount directives might not match exactly the list shown above. The exact contents depends on the mid-tier installation type. Bigger installation types, such as Unified Messaging, have more directives than other installation types. You just need the ones that you see in your mod_oc4j.conf file.
|
Oc4jMount /j2ee/* # do not copy; already in the infrastructure file Oc4jMount /wwcp OC4J_Wireless Oc4jMount /wwcp/* OC4J_Wireless Oc4jMount /modules OC4J_Wireless Oc4jMount /modules/* OC4J_Wireless Oc4jMount /push OC4J_Wireless Oc4jMount /push/* OC4J_Wireless Oc4jMount /async OC4J_Wireless Oc4jMount /async/* OC4J_Wireless Oc4jMount /ptg OC4J_Wireless Oc4jMount /ptg/* OC4J_Wireless Oc4jMount /jocdemo OC4J_Demos # do not copy; already in the infrastructure file Oc4jMount /jocdemo/* OC4J_Demos # do not copy; already in the infrastructure file Oc4jMount /ojspdemos OC4J_Demos Oc4jMount /ojspdemos/* OC4J_Demos Oc4jMount /repdemo OC4J_Demos Oc4jMount /repdemo/* OC4J_Demos Oc4jMount /bmp OC4J_Demos Oc4jMount /bmp/* OC4J_Demos Oc4jMount /callerInfo OC4J_Demos Oc4jMount /callerInfo/* OC4J_Demos Oc4jMount /onlineorders OC4J_Demos # do not copy; already in the infrastructure file Oc4jMount /onlineorders/* OC4J_Demos # do not copy; already in the infrastructure file Oc4jMount /webapp home # do not copy; already in the infrastructure file Oc4jMount /webapp/* home # do not copy; already in the infrastructure file Oc4jMount /cabo home # do not copy; already in the infrastructure file Oc4jMount /cabo/* home # do not copy; already in the infrastructure file Oc4jMount /studio OC4J_Portal Oc4jMount /studio/* OC4J_Portal Oc4jMount /jpdk OC4J_Portal Oc4jMount /jpdk/* OC4J_Portal Oc4jMount /syndserver OC4J_Portal Oc4jMount /syndserver/* OC4J_Portal Oc4jMount /ultrasearch/query OC4J_Portal Oc4jMount /ultrasearch/query/* OC4J_Portal Oc4jMount /customization OC4J_Portal Oc4jMount /customization/* OC4J_Portal Oc4jMount /webtool OC4J_Portal Oc4jMount /webtool/* OC4J_Portal Oc4jMount /wcp OC4J_Portal Oc4jMount /wcp/* OC4J_Portal Oc4jMount /ultrasearch/admin OC4J_Portal Oc4jMount /ultrasearch/admin/* OC4J_Portal Oc4jMount /ultrasearch/admin_sso OC4J_Portal Oc4jMount /ultrasearch/admin_sso/* OC4J_Portal Oc4jMount /uddi OC4J_Portal Oc4jMount /uddi/* OC4J_Portal Oc4jMount /provider/ultrasearch OC4J_Portal Oc4jMount /provider/ultrasearch/* OC4J_Portal Oc4jMount /portal OC4J_Portal Oc4jMount /portal/* OC4J_Portal Oc4jMount /examples OC4J_Portal Oc4jMount /examples/* OC4J_Portal Oc4jMount /OP OC4J_BI_Forms Oc4jMount /OP/* OC4J_BI_Forms Oc4jMount /reports OC4J_BI_Forms Oc4jMount /reports/* OC4J_BI_Forms Oc4jMount /click OC4J_BI_Forms Oc4jMount /click/* OC4J_BI_Forms Oc4jMount /discoverer OC4J_BI_Forms Oc4jMount /discoverer/* OC4J_BI_Forms Oc4jMount /um OC4J_UM Oc4jMount /um/* OC4J_UM
Edit the lines in the infrastructure mod_oc4j.conf file so that it contains the "instance://" keyword and the name of the mid-tier instance.
Table 6-2 shows an example of how the lines would look in the infrastructure mod_oc4j.conf. In the table, ias_mid_tier_instance_name refers to the name of your mid-tier instance. Note that the table shows only a sample of two lines; you need to edit the rest of the lines that you copied.
Table 6-2 mod_oc4j.conf
| Lines in mid-tier mod_oc4j.conf (sample) | Edited lines in infrastructure mod_oc4j.conf (sample) |
|---|---|
Oc4jMount /wwcp OC4J_Wireless Oc4jMount /wwcp/* OC4J_Wireless |
Oc4jMount /wwcp instance://ias_mid_tier_instance_name:OC4J_Wireless Oc4jMount /wwcp/* instance://ias_mid_tier_instance_name:OC4J_Wireless |
You can edit the mod_oc4j.conf file using OEM or a text editor. See Section 6.1.9.9, "Editing the mod_oc4j.conf File" for details. If you use a text editor to edit mod_oc4j.conf, you must run "dcmctl updateConfig" and restart Oracle HTTP Server after you edit the file.
Start up the OC4J_Demos and home OC4J instances on the infrastructure. By default, these OC4J instances are not started up in the infrastructure. You can start them up using dcmctl or OEM.
Figure 6-3 shows a configuration where the infrastructure Oracle HTTP Server goes away, and all requests go through the mid-tier Oracle HTTP Server.
|
Note: This scenario is recommended only for J2EE and Web Cache mid-tier installation types and only if you do not use SSO in any way. Some components, such as SSO, cannot work without the infrastructure Oracle HTTP Server. This means that if you use components that use SSO, you cannot use this scenario. This includes Portal, Wireless, and DAS. It is recommended if you are directing requests between infrastructure and mid-tier, you direct your requests the other way (through the infrastructure Oracle HTTP Server instead of through the mid-tier Oracle HTTP Server). |
You have to configure Oracle HTTP Server on the mid-tier to handle requests that used to be handled by the infrastructure Oracle HTTP Server. This involves:
Editing the mod_oc4j.conf file to accept requests for the OC4J_DAS instance.
To configure the mid-tier mod_oc4j.conf file:
Make a copy of the mid-tier mod_oc4j.conf file, so that you have a backup.
Copy the Oc4jMount lines from the infrastructure mod_oc4j.conf to the mid-tier mod_oc4j.conf.
Note that there are some lines that are the same in both the infrastructure and mid-tier files. Do not copy these lines from the infrastructure file (that is, use the lines already in the mid-tier file). The only lines that you need to copy are the /oiddas lines.
The list below shows the lines in the infrastructure mod_oc4j.conf file.
Oc4jMount /j2ee/* # do not copy; already in the mid-tier file Oc4jMount /jocdemo OC4J_Demos # do not copy; already in the mid-tier file Oc4jMount /jocdemo/* OC4J_Demos # do not copy; already in the mid-tier file Oc4jMount /onlineorders OC4J_Demos # do not copy; already in the mid-tier file Oc4jMount /onlineorders/* OC4J_Demos # do not copy; already in the mid-tier file Oc4jMount /webapp home # do not copy; already in the mid-tier file Oc4jMount /webapp/* home # do not copy; already in the mid-tier file Oc4jMount /cabo home # do not copy; already in the mid-tier file Oc4jMount /cabo/* home # do not copy; already in the mid-tier file Oc4jMount /oiddas OC4J_DAS Oc4jMount /oiddas/* OC4J_DAS
Edit the lines in the mid-tier mod_oc4j.conf file so that it contains the "instance://" keyword and the name of the infrastructure instance, as shown in Table 6-3.
In the table, ias_infra_instance_name refers to the name of the infrastructure instance.
Table 6-3 mod_oc4j.conf when directing requests to the mid-tier Oracle home
| Copy from: Infrastructure mod_oc4j.conf | To: Mid-Tier mod_oc4j.conf |
|---|---|
Oc4jMount /oiddas OC4J_DAS Oc4jMount /oiddas/* OC4J_DAS |
Oc4jMount /oiddas instance://ias_infra_instance_name:OC4J_DAS Oc4jMount /oiddas/* instance://ias_infra_instance_name:OC4J_DAS |
You can edit the mod_oc4j.conf file using Enterprise Manager or a text editor. See Section 6.1.9.9, "Editing the mod_oc4j.conf File" for details.
|
Note: If you use a text editor to editmod_oc4j.conf, you must run "dcmctl updateConfig" and restart Oracle HTTP Server after you edit the file.
|
You can determine the name of an Oracle9iAS instance by running the dcmctl command with the whichInstance option:
prompt> dcmctl whichInstance doctest_j2ee.machine1.us.oracle.com
The instance name contains the host name, including the domain name.
dcmctl is in ORACLE_HOME/dcm/bin. If you have multiple Oracle homes on the same machine, run the command from the appropriate ORACLE_HOME.
For example, to route requests from the mid-tier to infrastructure OC4J instances (scenario 2), you need the name of the infrastructure instance.
prompt> cd INFRASTRUCTURE_ORACLE_HOME prompt> cd dcm/bin prompt> ./dcmctl whichInstance doctest_infra.machine1.us.oracle.com
You can determine the names of installed OC4J instances on a machine by running the dcmctl command with the listComponents option on that machine:
prompt> dcmctl listComponents HTTP Server OC4J_BI_Forms OC4J_Demos OC4J_Portal OC4J_Wireless home
The command returns the names of Oracle HTTP Server instances as well. You can determine the type of a component by running the dcmctl command with the getComponentType option:
prompt> dcmctl getComponentType -co home oc4j prompt> dcmctl getComponentType -co "HTTP Server" ohs
To route requests from the mid-tier to the infrastructure OC4J instances (scenario 2), you need the OC4J_DAS instance on the infrastructure.
You can determine the names of clusters by running the dcmctl command with the listClusters option.
prompt> dcmctl listClusters forms_cluster
You can edit the ORACLE_HOME/Apache/Apache/conf/mod_oc4j.conf file using a text editor or Enterprise Manager.
|
Note: If you use a text editor to editmod_oc4j.conf, you need to run dcmctl with the updateConfig option to sync the changes with the DCM repository. Then you have to restart Oracle HTTP Server so that it can read the updated file.
|
To edit the mod_oc4j.conf file using Enterprise Manager:
Navigate to the Enterprise Manager Web site:
http://host:1810/
where host specifies the machine running Enterprise Manager. The default port is 1810.
On the Farm page, click the name of the mid-tier instance.
On the mid-tier instance home page, click HTTP Server in the System Components table.
On the HTTP Server page, click Advanced Server Properties in the Administration section.
On the Advanced Server Properties page, click mod_oc4j.conf.
This displays the "Edit mod_oc4j.conf" page.
Make your changes to the file.
Click Apply.
Click Yes when prompted to restart HTTP Server.
To edit the mod_oc4j.conf file using a text editor:
Change directory to ORACLE_HOME/Apache/Apache/conf.
prompt> cd ORACLE_HOME/Apache/Apache/conf
Make your changes to the file using a text editor.
Run dcmctl with the updateConfig parameter.
prompt> cd ORACLE_HOME/dcm/bin prompt> ./dcmctl updateConfig
Restart Oracle HTTP Server.
prompt> ./dcmctl restart -ct ohs
On Tru64 UNIX, the Enterprise Manager Daemon does not support some host metrics, for example:
Process
I-node
File table statistics
Switch/Swap Activity
When you logon to the Oracle9iAS home page on host "xyz.oracle.com", you may not see the rollup stats. Also, you may not see metrics on the Oracle HTTP Server and OC4J instance pages.
As a workaround, edit targets.xml and set all instances of hostname "xyz" to the complete host and domain name, such as "xyz.oracle.com". The metrics and rollup data should be visible once you restart EMD.
You should use either dcmctl or EMD to manager your Oracle9iAS installation, not both concurrently. Concurrency issues arise when both dcmctl and EMD are used to manage the same Oracle9iAS instance.
Additional information regarding Oracle9iAS backup and recovery is available from the white paper "Oracle9i Application Server: Backup and Recovery".
There is also an associated Oracle9iAS Backup and Recovery tool. The tool requires Oracle9iAS Release 2 (9.0.2.1.0) or later.
The white paper and tool can be found at Oracle Technology Network:
http://otn.oracle.com/products/ias/hi_av/content.html
The following are known issues associated with Oracle9iAS security.
To run the Oracle HTTP Server with SSL server correctly after installation in Oracle9iAS, you should create a wallet and have the certificates contained within it signed by the proper Certificate Authorities. Make sure that the SSLWallet directive in httpd.conf points to this new wallet rather than the default wallet provided by the installation. Oracle HTTP Server will not start if you fail to do one of the following:
Obfuscate this new wallet's password by running:
iasobf -p password rootosslpassword -p password System
and place this obfuscated password in httpd.conf file using the Wallet Password directive (for example "WalletPassword obfuscatedPassword"). You can always choose to put the wallet password in httpd.conf in clear text but this is not recommended by Oracle.
Make this new wallet an SSO wallet as the root user.
|
See Also: Oracle9i Application Server Security Guide |
The demonstration pages for J2EE and Web Cache, located in http://host.domain:port/J2EE.htm is vulnerable in security. You must disable all demonstration pages when exhibiting a site in order to ensure security.
The following URLs indicate some demos that have vulnerabilities:
Oracle HTTP Server
http://host.domain:port/cgi-bin/printenv?<script>alert(document.cookie)</script> http://host.domain:port/perl/printenv?<script>alert(document.cookie)</script> http://host.domain:port/fcgi-bin/echo?<script>alert(document.cookie)</script>
OJSP Sample
http://host.domain:port/ojspdemos/basic/hellouser/hellouser.jsp http://host.domain:port/ojspdemos/basic/simple/welcomeuser.jsp http://host.domain:port/ojspdemos/basic/simple/usebean.jsp
JSP Sample
http://host.domain:port/j2ee/examples/jsp/snp/snoop.jsp?<script>alert(document.cookie)</script> http://host.domain:port/j2ee/examples/jsp/cal/login.html
Servlet Sample
http://host.domain:port/j2ee/servlet/RequestParamExample http://host.domain:port/j2ee/servlet/CookieExample http://host.domain:port/j2ee/servlet/SessionExample http://host.domain:port/j2ee/servlet/SnoopServlet?<script>alert(document.cookie)</script>
