Release 2 (9.0.2) for UNIX
Part Number A90322-01
 Home |
| Oracle HTTP Server Release Notes Release 2 (9.0.2) for UNIX Part Number A90322-01 |
|
Release 2 (9.0.2) for UNIX
April 2002
Part No. A90332-01
This document summarizes the differences between Oracle HTTP Server and its documented functionality.
This section describes general issues and their workarounds for Oracle HTTP Server.
Oracle Corporation recommends that you use the Oracle9iAS Containers for J2EE (OC4J) for your servlet environment; it is the default configuration for Oracle9iAS Release 2 (9.0.2). However, you may want or need to use JServ in your Oracle9iAS Release 2 installation. These instructions are provided to explain how to enable JServ, and, if necessary, use it for some applications and OC4J for others. The instructions assume a working familiarity with the Oracle HTTP Server and JServ configuration.
This section has the following topics:
mod_oprocmgr.
ApJServManual directive has a new mode, `auto', that enables using JServ with the Oracle module mod_oprocmgr. The ORACLE_HOME/Apache/JServ/etc/jserv.conf file contains LoadModule directives for mod_jserv and mod_oprocmgr.
ApJServManual directive is set to `off' and the mod_jserv module launches and monitors the JVM. If the Oracle HTTP Server is restarted or stopped, mod_jserv restarts or stops the JVM.
ApJServManual directive is set to `on' and you have to stop and start the JVM manually. To monitor the JVM, you must use an external monitoring facility.
mod_rewrite to enable some applications to execute on JServ, and others on OC4J.
This section describes some JServ configuration directives that are related to using JServ with mod_oprocmgr. All directives are described thoroughly in the configuration files.
This section describes the following directive:
Port
Use this directive to specify the ports to which JServ will bind, as shown in the example below.
port=8007
If no ports are specified, the JServ processes will choose their ports. The port directive as shown below enables the JServ processes to choose their own ports (the default).
port=
If you eliminate the port directive entirely, an error will occur.
You can specify multiple ports, and separate the values with commas as shown in the example below. Note that a range of ports (9000-9010) is a valid value.
port=8007,9000-9010,8010
This section describes the following directives:
ApJServManual
This directive accepts a new mode, auto, which invokes the new infrastructure functionality (in which mod_oprocmgr manages processes). The syntax is:
ApJServManual auto
You can set the mode to on or off to use standard JServ functionality.
ApJServGroup
This directive defines groups for the process manager to manage for mod_jserv. If you have worked with mod_jserv, you will note that this directive replaces the ApJServBalance, ApJServHost, ApJServRoute and ApJServShmFile directives.
All JServ processes to be managed must belong to a group, and each group has its own ApJServGroup directive. If you only have one JServ process, you must define a group with just that process in it. The processes in a group are identical except for their listening ports, so requests directed to the group are distributed evenly among the processes.
The ApJServGroup directive takes four arguments: groupname, number of processes, node weight, and properties file. In the example below, the groupname is mygroup, the number of processes is 1, the node weight is 1, and the full path of the properties file used to start the JServ processes is
ORACLE_HOME/Apache/JServ/etc/jserv.properties ApJServGroup mygroup 1 1 /private2/up_1022/Apache/Jserv/etc/jserv.properties
ApJServGroupMount
This directive defines a mount point and maps it to a process group and zone. In the example below, the mount point is /servlets, the group is mygroup, and the zone is root. Note that the balance protocol is in use for routing, as in the standard JServ configuration.
ApJServGroupMount /servlets balance://mygroup/root
Place this directive after the ApJServGroup directive in the configuration file.
ApJServGroupSecretKey
This directive specifies the secret key that JServ needs to authenticate clients. It can be disabled, as shown below:
ApJServGroupSecretKey disabled
When activated, the directive takes one or two arguments. In the example below, with group and filename arguments, the filename mysecretkey applies to the group mygroup.
ApJServGroupSecretKey mygroup /usr/local/apache/jserv/mysecretkey
You can supply only the filename argument, as shown below. No group is named, so the secret key filename applies to all groups.
ApJServGroupSecretKey /usr/local/apache/jserv/mysecretkey
You cannot combine directives using the one-argument syntax with directives using the two-argument syntax. If you use the two-argument syntax, the default for groups without a group-specific secret key is 'disabled'.
Place this directive after the ApJServGroup directive in the configuration file.
This section explains how to implement process management and load balancing services for JServ processes with mod_oprocmgr. Terms used in this section to describe the module and its functions are defined below:
mod_oprocmgr: A module that starts, stops, and detects death of processes (starting new processes to replace them), and provides load balancing services to the processes. mod_oprocmgr gets the topology management information via HTTP requests from internal servers such as JServ, and does its job based on this information.
mod_oprocmgr provides infrastructure capabilities, such as automatic starting of processes, death detection and restart, and load balancing. These capabilities are enabled by a new mode, auto, for the ApJServManual directive.
Based on the configuration information provided by mod_jserv, mod_oprocmgr starts the specified number of JServ processes, managing them for the life of the servers.
Follow these steps to enable JServ with mod_oprocmgr:
jserv.conf file in ORACLE_HOME/Apache/Apache/conf/httpd.conf.
#include "/ORACLE_HOME/Apache/Jserv/etc/jserv.conf"
ORACLE_HOME/Apache/Jserv/etc/jserv.conf file, if needed.
ORACLE_HOME/Apache/Jserv/etc/jserv.properties file, if needed.
ORACLE_HOME/Apache/Jserv/etc/zone.properties file, if needed.
Follow these steps to enable JServ in automatic mode:
jserv.conf file in ORACLE_HOME/Apache/Apache/conf/httpd.conf.
#include "/ORACLE_HOME/Apache/Jserv/etc/jserv.conf"
ApJServManual directive in the ORACLE_HOME/Apache/Jserv/etc/jserv.conf file:
ApJServManual off
jserv.conf.
port directive in the ORACLE_HOME/Apache/Jserv/etc/jserv.properties file to the same value as that specified in the ApJServDefaultPort directive.
ORACLE_HOME/Apache/Jserv/etc/zone.properties file, if needed.
Follow these steps to enable JServ in manual mode:
Include directive for the jserv.conf file in ORACLE_HOME/Apache/Apache/conf/httpd.conf.
#include "/ORACLE_HOME/Apache/Jserv/etc/jserv.conf"
ApJServManual directive in the ORACLE_HOME/Apache/Jserv/etc/jserv.conf file:
ApJServManual on
jserv.conf.
ORACLE_HOME/Apache/Jserv/etc/jserv.properties file, if needed.
ORACLE_HOME/Apache/Jserv/etc/zone.properties file, if needed.
wrapper.bin.parameters and wrapper.classpath in the jserv.properties file).
An example of the command to do this is shown below:
java -classpath ORACLE_HOME/lib/servlet.jar:$CLASSPATH
org/apache/jserv/JServ </path/to>/jserv.properties
Perform the following configuration steps to enable JServ and Oracle9iAS Containers for J2EE (OC4J) to coexist. This is important if you have the Portal and Wireless installation type, because of the Portal dependency on OC4J.
/application1/file1.jsp to execute on JServ, and
/application2/file2.jsp to execute on OC4J.
You must rewrite the URL for application1.
ORACLE_HOME/Apache/Apache/conf/httpd.conf and ensure that the following directives are active (uncommented) and present:
LoadModule rewrite_module libexec/mod_rewrite.so AddModule mod_rewrite.c RewriteEngine on
ORACLE_HOME/Apache/jsp/conf/ojsp.conf to add these directives:
RewriteRule /application1/(.*)/(.*)\.jsp$ /application1/$1/$2.jsp1 ApJServAction .jsp1 /servlets/oracle.jsp.JspServlet
ApJServAction .jsp /servlets/oracle.jsp.JspServlet
ORACLE_HOME/Apache/Jserv/etc/jserv.conf and mount /servlets to the JVM that will service the JSP requests. Use the ApJServMount or ApJServGroupMount directive (depending on how the JServ processes are started).
The performance metrics collected for virtual hosts for Oracle HTTP Server are categorized by virtual host name only. So if an Oracle9iAS site deploys multiple virtual hosts that differ only in their listening port or IP address, then their performance metrics, as shown by the Enterprise Manager, will be displayed summed together.
The amount of space available for cookie data and/or header data has greatly decreased from Oracle HTTP Server/Jserv to Oracle HTTP Server/OC4J. Oracle HTTP Server/Jserv can approach 8K in size for cookie data while for Oracle HTTP Server/OC4J, this is limited to about 4K in size.
FastCGI, CGI, mod_perl, and CGI-bin/test-CGI demo scripts should be disabled from production systems as they might serve a good source of information for hackers. The demo scripts are shipped with the distribution in order for users to verify that the installation is successful. Note that there are no known security problems, such as buffer overflow, with these demo programs. The information leakage can be addressed by proper configuration.
You may not be able to access mod_osso protected pages from Netscape 4.7. If you want to access mod_osso protected pages from Netscape 4.7, then the partner application corresponding to mod_osso should be modified from the Single Sign-On server configuration console to point to Oracle9iAS Web Cache port number, which is usually 7777. For details on how to use the Single Sign-On console, refer to the appropriate Single Sign-On administration documentation on the documentation CD.
This section describes configuration issues and their workarounds for Oracle HTTP Server.
The parameter nonssl_sso_port=<port> and / or nonssl_sso_host=<alternative sso server name> need to be specified in the Oracle HTTP Server's mod_osso configuration file conf/osso/osso.conf when a SSO Server is operated in SSL mode. In particular, parameter nonssl_sso_port=<port> must be specified in the osso.conf file in order to facilitate internal communications between an Oracle HTTP Server and a SSL enabled SSO server. By default, the nonssl_sso_port is initiated automatically by the SSORegistrar tool at Oracle9i Application Server install time, and its default value is 5000.
There are other configuration steps need to be completed on the SSO apache server.
Add the following line in the httpd.conf file to expose Basic Authentication URL to the mod_osso.
Listen <port number> Example: Listen 5000 Note: If you have used the following configuration in the Apache configuration in SSO Server URLs then you need to turn it off. (Details in the Oracle9iAS Single Sign-on Administrator's Guide, Chapter 2, Enabling the Single Sign-On Server for SSL) <IfDefine SSL> <Location /pls/orasso> SSLRequireSSL </Location> </IfDefine> Instead of this, use following configuration to protect of SSO Server URLs: # SSO Server Login URL <IfDefine SSL> <Location /pls/orasso/orasso.wwsso_app_admin.ls_login> SSLRequireSSL </Location> </IfDefine> # Change password URL <IfDefine SSL> <Location /pls/orasso/orasso.wwsso_app_user.mgr.change_password> SSLRequireSSL </Location> </IfDefine> # External Application Login URL <IfDefine SSL> <Location /pls/orasso/orasso.wwsso_app_user.mgr.change_password> SSLRequireSSL </Location> </IfDefine>
DCM command line utility must be used to notify the DCM repository of all manual edits to the Oracle HTTP Server, OC4J or OPMN configuration files. Failure to run this tool could result in loss of configuration data.
The valid forms of this command are as follows:
dcmctl updateConfig: This copies the configuration on disk to the DCM Repository for Oracle HTTP Server, OC4J or OPMN.
dcmctl updateConfig oc4j: This copies the configuration files for OC4J to the DCM Repository.
dcmctl updateConfig ohs: This copies the configuration files for Oracle HTTP Server to the DCM Repository.
dcmctl updateConfig opmn: This copies the configuration files for OPMN to the DCM Repository.
When using OPMN/Oracle HTTP Server infrastructure, the user has to specify at least one non_ssl port. For a purely secure Web site, meaning it only accepts SSL connection, the user has to provide an extra non_ssl port in httpd.conf. The user can do so by adding the following to maintain a secure Web site:
Listen <port> <VirtualHost _default_:port> SSLEngine Off <Location /> Order deny,allow Deny from all Allow fromlocal hostAllow from <ip1 of a localhost> Allow from <ip2 of a localhost> Allow from <ip3 of a localhost> </Location> </VirtualHost>
This way security is maintained by restricting the non-ssl port to only accept traffic from local host.
FastCGI will fail if the ORACLE_HOME path length is longer than 92 characters. This is due to the limitation of UNIX domain socket pathname length. As a workaround, you may override the default path by using "FastCgiIpcDir<dir>" directive in ORACLE_HOME/Apache/Apache/conf/httpd.conf within the <IfModule mod_fastcgi.c> block.
For example:
<IfModule mod_fastcgi.c> FastcgiIpcDir "/tmp/fcgi" ... </IfModule>
When iPlanet is initially installed, it automatically maps all URL beginning with "/servlet" to its own servlet handler resulting usually in a "Not Found" error returned to client if /servlet request intended to be handled by the proxy plugin is handled by iPlanet.
If you wish to map /servlet to the proxy plugin, all references to servlet need to be commented out in the listener's obj.conf file. This file is located in the config directory. No change are needed to magnus.conf.
The following should be commented out:
NameTrans fn="NSServletNameTrans" name="servlet" NameTrans fn="pfx2dir" from="/servlet" dir="c:/iplanet/Servers/docs/servlet" name="ServletByExt" <Object name="servlet"> ObjectType fn=force-type type=text/html Service fn="NSServletService" </Object> <Object name="ServletByExt"> ObjectType fn=force-type type=magnus-internal/servlet Service fn="magnus-internal/servlet" fn="NSServletService" </Object>
When attempting to access a protected resource, user is redirected to the SSO Server, user receives 503 errors initially. To avoid this, when using a server load balancer, the KeepAlive directive should be disabled.
This section describes administration issues and their workarounds for Oracle HTTP Server.
Both iASOBF, a tool used to obfuscate Wallet password and/or OSSO configuration file, and SSO Wallet-support use Oracle obfuscation algorithm which requires the same user to obfuscate and deobfuscate it. For mod_ossl, typically the Oracle9iAS administrator does the obfuscation and Apache runtime does the deobfuscation. However, Apache is typically run as root (this is true if root.sh is executed at install time) and therefore will not start. It is important to make sure that obfuscation is also run as root, or as the user that Apache runtime is running under.
If you use Oracle Enterprise Manager to change the orasso schema password, the portal SMI plugin that is invoked by Oracle Enterprise Manager does not automatically restart Oracle HTTP Server. This will cause access to Single Sign-On Web pages to fail. The administrator requires to manually restart Oracle HTTP Server to pick up the new orasso password.
This section describes known errors in the documentation.
The Oracle HTTP Server Administration Guide contains information about a SOAP demo located on the Oracle HTTP Server main page. This demo is no longer a part of the Oracle HTTP Server main page and this information should be removed from the Oracle HTTP Server Administration Guide.
Step 6 of the "Configuring the iPlanet Listener for Single Sign-on" section in the Oracle HTTP Server Administration Guide provides incorrect information. It states the following:
Add the following line:
<object path="/path/login_success"> Service fn="osso_success_service" </object>
The correct line that should be added is:
<object ppath="/path/osso_login_success"> Service fn="osso_success_service" </object>
Oracle is a registered trademark, and Oracle9i is a trademark or registered trademark of Oracle Corporation. Other names may be trademarks of their respective owners.
Copyright © 2002 Oracle Corporation.
All Rights Reserved.
|
|
 Copyright © 2002 Oracle Corporation. All Rights Reserved. |
|