|
|
| |
Installing and Configuring the Apache HTTP Server Plug-In
The following sections describe how to install and configure the Apache HTTP Server Plug-In:
The Apache HTTP Server Plug-In allows requests to be proxied from an Apache HTTP Server to WebLogic Server. The plug-in enhances an Apache installation by allowing WebLogic Server to handle those requests that require the dynamic functionality of WebLogic Server.
The plug-in is intended for use in an environment where an Apache Server serves static pages, and another part of the document tree (dynamic pages best generated by HTTP Servlets or JavaServer Pages) is delegated to WebLogic Server, which may be operating in a different process, possibly on a different host. To the end user—the browser—the HTTP requests delegated to WebLogic Server still appear to be coming from the same source.
The HTTP-tunneling can also operate through the plug-in, providing non-browser clients access to WebLogic Server services.
The Apache HTTP Server Plug-In operates as an Apache module within an Apache HTTP Server. An Apache module is loaded by Apache Server at startup, and then certain HTTP requests are delegated to it. Apache modules are similar to HTTP servlets, except that an Apache module is written in code native to the platform.
As of WebLogic Server 6.1 SP6, 7.0 SP5, 8.1 SP2, the WebLogic Server plug-ins are now certified to proxy to any version of WebLogic Server, including 5.1.
Keep-Alive Connections in Apache Version 1.3.x
The Apache HTTP Server Plug-In creates a socket for each request and closes the socket after reading the response. Because Apache HTTP Server is multiprocessed, connection pooling and keep-alive connections between WebLogic Server and theApache HTTP Server Plug-In cannot be supported.
Keep-Alive Connections in Apache Version 2.x
The Apache HTTP Server Plug-In improves performance by using a reusable pool of connections from the plug-in to WebLogic Server. The plug-in implements HTTP 1.1 keep-alive connections between the plug-in and WebLogic Server by reusing the same connection in the pool for subsequent requests from the same client. If the connection is inactive for more than 30 seconds, (or a user-defined amount of time) the connection is closed and returned to the pool. You can disable this feature if desired. For more information, see KeepAliveEnabled.
Proxying Requests
The plug-in proxies requests to WebLogic Server based on a configuration that you specify. You can proxy requests either based on the URL of the request (or a portion of the URL). This is called proxying by path. You can also proxy request based on the MIME type of the requested file. You can also use a combination of both methods. If a request matches both criteria, the request is proxied by path. You can also specify additional parameters for each of these types of requests that define additional behavior of the plug-in. For more information, see Configuring the Apache HTTP Server Plug-In.
The Apache HTTP Server Plug-In is supported on the Linux, Solaris, AIX, Windows, and HPUX11 platforms. Plug-ins are not supported on all operating systems for all releases. For information on platform support for specific versions of Apache, see Platform Support for WebLogic Server Plug-ins and Web Servers in Supported Configurations for WebLogic Server 6.1.
Installing the Apache HTTP Server Plug-In
You install the Apache HTTP Server Plug-In as an Apache module in your Apache HTTP Server installation. The module is installed either as a Dynamic Shared Object (DSO) or as a statically linked module. (Installation as a statically linked module is only available for Apache version 1.3.x). There are separate instructions in this section for each type of installation (DSO, or statically linked module).
Installing as a Dynamic Shared Object
To install the Apache HTTP Server Plug-In as a dynamic shared object:
The Apache plug-in is distributed as a shared object (.so
) for use on Solaris, Linux, Windows, and HPUX11 platforms. Each shared object file is distributed as separate versions, depending on the platform, whether or not SSL is to be used between the client and Apache, and the encryption strength for SSL (regular or 128 bit— 128 bit versions are only installed if you install the 128 bit version of WebLogic Server). The shared object files are located in the following directories of your WebLogic Server installation:
Platform |
Location of Shared Object File |
---|---|
Solaris |
|
Linux |
|
Windows (Apache 2.0 only) |
|
HPUX11 |
Note: If you are running Apache 2.0.x server on HP-UX11, set the environment variables specified below before you build the Apache server. Because of a problem with the order in which linked libraries are loaded on HP-UX11, a core dump can result if the load order is not preset as an environment variable before building. Set the following environment variables: export EXTRA_LDFLAGS="-lstd -lstream -lCsup -lm -lcl -ldld -lpthread" See the Apache HTTP Server documentation for information about building and configuring your Apache server. |
Choose the appropriate shared object from the following table (note that on the Compaq OpenVMS platform, the file suffix that is .so
on other platforms is .exe
):
If you are using Compaq OpenVMS, skip to step 5.
The Apache HTTP Server Plug-In will be installed as an Apache Dynamic Shared Object (DSO).
DSO support in Apache is based on a module named mod_so.c
that must be enabled before mod_wl.so is loaded. If you installed Apache using the supplied script, mod_so.c
should already be enabled. To verify that mod_so.c
is enabled, execute the following command:
APACHE_HOME
/bin/httpd -l
(Where APACHE_HOME
is the directory containing your Apache HTTP Server installation.)
This command lists all of the enabled modules. If mod_so.c
is not listed, build your Apache HTTP Server from the source code, making sure that the following options are configured:
...
--enable-module=so
--enable-rule=SHARED_CORE
...
apxs
(APache eXtenSion) that builds DSO-based modules outside of the Apache source tree, and adds the following line to the httpd.conf
file:
AddModule mod_so.c
weblogic_module
by issuing this command (note that you must have Perl installed to run this Perl script):
perl
APACHE_HOME\bin\apxs -i -a -n weblogic mod_wl.so
This command copies the mod_wl.so
file to the APACHE_HOME\libexec
directory. It also adds two lines of instructions
for weblogic_module
to the httpd.conf
file and activates the module. Make sure that the following lines were added to your APACHE_HOME/conf/httpd.conf file in your Apache server installation:
LoadModule weblogic_module libexec/mod_wl.so AddModule mod_weblogic.c
.exe
as opposed to .so used by other platforms. Thus the module libraries for OpenVMS are:
mod_wl.exe
: Apache Plugin Module (NonSSL)
mod_wl_ssl.exe
: Apache Plugin Module (SSL)
As a result of this different suffix on OpenVMS you must manually add the LoadModule
entries to APACHE$ROOT:[CONF]httpd.conf
based on where the Apache plugin modules are copied. For example, if the modules are in APACHE$ROOT:[000000]
directory, add the following entry to the APACHE$ROOT:[CONF]httpd.conf
file:
LoadModule weblogic_module /apache$root/000000/mod_wl.exe
LoadModule weblogic_module /apache$root/000000/mod_wl_ssl.exe
The following is a complete stanza added to the httpd.conf
file in the section headed Dynamic Shared Object (DSO) Support:
LoadModule weblogic_module modules/mod_wl.exe
AddModule mod_weblogic.c
<IfModule mod_weblogic.c>
WebLogicHost [hostname]
WebLogicPort 7001
PathTrim /weblogic
</IfModule>
<Location /weblogic>
SetHandler weblogic-handler
</Location>
For more information on editing the httpd.conf file, see Configuring the Apache HTTP Server Plug-In.
httpd.conf
configuration file as described in the section Configuring the Apache HTTP Server Plug-In. The httpd.conf
file allows you to customize the behavior of the Apache HTTP Server Plug-In.
APACHE_HOME
\conf\httpd.conf file with one of the following commands:
For Apache 1.x,
APACHE_HOME\bin\apachect1 configtest
For Apache 2.x,
APACHE_HOME\bin\Apache -t
The output of this command indicates any errors in your httpd.conf
file.
/weblogic/
", which should bring up the default WebLogic Server HTML page, welcome file, or default servlet, as defined for the default Web Application on WebLogic Server. For example:
http://myApacheserver.com/weblogic/
Installing as a Statically Linked Module
To install the Apache HTTP Server Plug-In as a statically linked module:
Each library file is distributed as separate versions, depending on the platform and the encryption strength for SSL (regular or 128-bit—128-bit versions are only installed if you install the 128-bit version of WebLogic Server). The library files are located in the following directories of your WebLogic Server installation:
Choose the appropriate shared object from the following stable.
Apache Version |
Regular Strength Encryption |
128-bit |
---|---|---|
Standard Apache Version 1.3.x |
|
|
If you are using the Gnu C Compiler (gcc), gcc 2.95.x is the recommended version.
tar -xvf apache_1.3.x.tar
src/modules
directory.
weblogic
.
Makefile.libdir, Makefile.tmpl
from the lib
directory of your WebLogic Server installation to src/modules/weblogic
.
libweblogic.a
. (Use libweblogic128.a
instead, if you are using 128 bit security.) from the same directory containing the linked library file (see step 1. ) to
src/modules/weblogic
.
configure --activate-module=src/modules/weblogic/libweblogic.a
configure--activate-module= src/modules/weblogic/libweblogic128.a
make
make install
Configuring the Apache HTTP Server Plug-In
After you install the plug-in (see Installing the Apache HTTP Server Plug-In), edit the httpd.conf
file to configure the Apache plug-in. Editing the httpd.conf
file informs the Apache Web server that it should load the native library for the plug-in as an Apache module and also describes which requests should be handled by the module.
Editing the httpd.conf File
To edit the httpd.conf
file to configure the Apache HTTP Server Plug-In:
httpd.conf
file. The file is located at APACHE_HOME
/conf/httpd.conf
(where APACHE_HOME
is the root directory of your Apache installation).
httpd.conf
LoadModule stanza will load the correct module by verifying that the following two lines were added to the httpd.conf
file when you ran the apxs
utility:
LoadModule weblogic_module libexec/mod_wl.so AddModule mod_weblogic.c
IfModule
block that defines one of the following:
For a non-clustered WebLogic Server:
The WebLogicHost and WebLogicPort parameters.
For a cluster of WebLogic Servers:
The WebLogicCluster parameter.
For example:
<IfModule mod_weblogic.c> WebLogicHost myweblogic.server.com WebLogicPort 7001 </IfModule>
MatchExpression
line to the IfModule
block. (You can also proxy requests by path. Proxying by path takes precedence over proxying by MIME type. If you only want to proxy requests by path, skip to step 5. )
For example, the following IfModule
block for a non-clustered WebLogic Server specifies that all files with MIME type .jsp
are proxied:
<IfModule mod_weblogic.c> WebLogicHost myweblogic.server.com WebLogicPort 7001 MatchExpression *.jsp </IfModule>
You can also use multiple MatchExpressions
, for example:
<IfModule mod_weblogic.c>
WebLogicHost myweblogic.server.com WebLogicPort 7001MatchExpression *.jsp MatchExpression *.xyz </IfModule>
If you are proxying requests by MIME type to a cluster of WebLogic Servers, use the WebLogicCluster
parameter instead of the WebLogicHost
and WebLogicPort
parameters. For example:
<IfModule mod_weblogic.c>
WebLogicCluster w1s1.com:7001,w1s2.com:7001,w1s3.com:7001MatchExpression *.jsp MatchExpression *.xyz </IfModule>
Location
block and the SetHandler
statement. SetHandler
specifies the handler for the Apache HTTP Server Plug-In module. For example the following Location block proxies all requests containing the /weblogic
in the URL:
<Location /weblogic> SetHandler weblogic-handler </Location>
If you want to proxy requests to multiple clusters by path, you can use multiple Location
blocks and SetHandler statements.
For example:
<Location /x>
SetHandler weblogic-handler
WebLogicCluster cluster1
</Location>
<Location /y>
SetHandler weblogic-handler
WebLogicCluster cluster2
</Location>
<Location /z>
SetHandler weblogic-handler
WebLogicCluster cluster3
</Location>
An alternate way of proxying by path to multiple clusters would be:
MatchExpression /x
WebLogicCluster=server1:port,server2:port,server3:port,server4: port|PathTrim=/x
MatchExpression /y
WebLogicCluster=server1:port,server2:port,server3:port,server4: port|PathTrim=/y
MatchExpression /z
WebLogicCluster=server1:port,server2:port,server3:port,server4: port|PathTrim=/z
Where the general syntax is
MatchExpression exp name=value|name=value
where exp=Mime type(*.jsp) or exp=/x(path)
and the next argument in the list is a pipe(|) delimited list of name=value such as
WebLogicHost, WebLogicPort, WebLogicCluster, PathTrim, PathPrepend..
The Apache HTTP Server Plug-In recognizes the parameters listed in General Parameters for Web Server Plug-Ins. To modify the behavior of your Apache HTTP Server Plug-In, define these parameters either:
Notes on Editing the httpd.conf File
weblogic.conf
file that is included in the IfModule
block. Using this included file may help modularize your configuration. For example:
<IfModule mod_weblogic.c>
# Config file for WebLogic Server that defines the parameters
Include conf/weblogic.conf
</IfModule>
Note: Defining parameters in an included file is not supported when using SSL between Apache HTTP Server Plug-In and WebLogic Server.
PARAM_1 value1 PARAM_2 value2 PARAM_3 value3
MatchExpression
in an IfModule
block and a path specified in a Location
block, the behavior specified by the Location
block takes precedence.
IfModule
block.
Using SSL with the Apache Plug-In
You can use the Secure Sockets Layer (SSL) protocol to protect the connection between the Apache HTTP Server Plug-In and WebLogic Server. The SSL protocol provides confidentiality and integrity to the data passed between the Apache HTTP Server Plug-In and WebLogic Server. In addition, the SSL protocol allows the plug-in to authenticate itself to WebLogic Server to ensure that information is passed to a trusted principal.
The Apache HTTP Server Plug-In does not use the transport protocol (http
or https
) specified in the HTTP request (usually by the browser) to determine whether or not the SSL protocol is used to protect the connection between the Apache HTTP Server Plug-In and WebLogic Server.
Note: You cannot configure a 2-way SSL between the Apache HTTP Server and WebLogic Server. The SSL protocol is a point-to-point connection, cyptographically sealed end-to-end. Therefore, any type of proxy or firewall cannot see into the SSL socket. The Apache HTTP Server acts as the server end-point in the SSL connection. The configuration is:
client-->2-way SSL-->Apache<--1-way SSL<--WebLogic Server
The Apache HTTP Server cannot use the digital certificate from the first SSL connection in the second SSL connection because it cannot use the client's private key.
Configuring SSL Between the Apache HTTP Server Plug-In and WebLogic Server
To use the SSL protocol between Apache HTTP Server Plug-In and WebLogic Server:
WebLogicPort
parameter in the httpd.conf
file to the listen port configured in step 2.
SecureProxy
parameter in the httpd.conf
file to ON
.
httpd.conf
file that define information about the SSL connection. For a complete list of parameters, see SSL Parameters for Web Server Plug-Ins.
Issues with SSL-Apache Configuration
Three known issues arise when you configure the Apache plug-in to use SSL:
<Location>
tag.
The following configuration is incorrect:
<Location /weblogic> SetHandler weblogic-handler </Location>
<IfModule mod_weblogic.c>
WebLogicHost localhost
WebLogicPort 7001
PathTrim /weblogic
</IfModule>
The following configuration is the correct setup:
<Location /weblogic>
SetHandler weblogic-handler
PathTrim /weblogic
</Location>
Include
directive does not work with Apache SSL. You must configure all parameters directly in the httpd.conf
file. Do not use the following configuration when using SSL:
<IfModule mod_weblogic.c> MatchExpression *.jsp Include weblogic.conf </IfModule>
Specifying Trust of the WL-Proxy-Client-Cert Header
The plug-in can encode users' identity certifications in the WL-Proxy-Client-Cert
header and pass the header to WebLogic Server instances (see Proxying Requests to Another HTTP Server in the WebLogic Server Administration Guide). A WebLogic Server instance uses the certificate information from that header, trusting that it comes from a secure source (the Plug-In), to authenticate the user. In previous releases of WebLogic Server, the default behavior was to always trust the WL-Proxy-Client-Cert
header. Beginning with WebLogic Server 6.1 SP2, you need to explicitly define trust of the WL-Proxy-Client-Cert
header. A new parameter, clientCertProxy
, allows WebLogic Server to determine whether to trust the certificate header. For an additional level of security, use a connection filter to limit all connections into WebLogic Server (therefore allowing WebLogic Server to only accept connections from the machine on which the plug-in is running).
The clientCertProxy
parameter has been added to the HTTPClusterServlet
and Web applications.
For the HTTPClusterServlet
, add the parameter to the web.xml
file as follows:
<context-param>
<param-name>clientCertProxy</param-name>
<param-value>true</param-value>
</context-param>
For Web applications, add the parameter to the web.xml
file as follows:
ServletRequestImpl context-param
<context-param>
<param-name>weblogic.httpd.clientCertProxy</param-name>
<param-value>true</param-value>
</context-param>
You can also use this parameter in a cluster as follows:
<Cluster ClusterAddress="127.0.0.1" Name="MyCluster"
ClientCertProxyHeader="true"/>
Connection Errors and Clustering Failover
When the Apache HTTP Server Plug-In attempts to connect to WebLogic Server, the plug-in uses several configuration parameters to determine how long to wait for connections to the WebLogic Server host and, after a connection is established, how long the plug-in waits for a response. If the plug-in cannot connect or does not receive a response, the plug-in will attempt to connect and send the request to other WebLogic Servers in the cluster. If the connection fails or there is no response from any WebLogic Server in the cluster, an error message is sent.
Figure 11-1 demonstrates how the plug-in handles failover.
Connection Failures
Failure of the host to respond to a connection request could indicate possible problems with the host machine, networking problems, or other server failures.
Failure of WebLogic Server to respond, could indicate that WebLogic Server is not running or is unavailable, a hung server, a database problem, or other application failure.
Failover with a Single, Non-Clustered WebLogic Server
If you are running only a single WebLogic Server the same logic described here applies, except that the plug-in only attempts to connect to the server defined with the WebLogicHost parameter. If the attempt fails, an HTTP 503
error message is returned. The plug-in continues trying to connect to WebLogic Server until ConnectTimeoutSecs is exceeded.
The Dynamic Server List
When you specify a list of WebLogic Servers in the WebLogicCluster
parameter, the plug-in uses that list as a starting point for load balancing among the members of the cluster. After the first request is routed to one of these servers, a dynamic server list is returned containing an updated list of servers in the cluster. The updated list adds any new servers in the cluster and deletes any that are no longer part of the cluster or that have failed to respond to requests. This list is updated automatically with the HTTP response when a change in the cluster occurs.
To avoid traffic on a new server you need to test, wait until the newly added server is fully tested, target it to the cluster and it will become a node of the cluster. This node will get automatically begin to receive traffic from the proxy.
Failover, Cookies, and HTTP Sessions
When a request contains a session information stored in a cookie, in the POST data, or by URL encoding, the session ID contains a reference to the specific server in which the session was originally established (called the primary server) and a reference to an additional server where the original session is replicated (called the secondary server). A request containing a cookie attempts to connect to the primary server. If that attempt fails, the request is routed to the secondary server. If both the primary and secondary servers fail, the session is lost and the plug-in attempts to make a fresh connection to another server in the dynamic cluster list. For more information, see Figure 11-1 Connection Failover.
Note: If the POST data is larger than 64K, the plugin will not parse the POST data to obtain the session ID. Therefore, if you store the session ID in the POST data, the plugin cannot route the request to the correct primary or secondary server, resulting in possible loss of session data.
Figure 11-1 Connection Failover
*The Maximum number of retries allowed in the red loop is equal to ConnectTimeoutSecs
÷ ConnectRetrySecs.
Template for the httpd.conf File
This section contains a sample httpd.conf
file. You can use this sample as a template that you can modify to suit your environment and server. Lines beginning with # are comments. Note that Apache HTTP Server is not case sensitive, and that the LoadModule
and AddModule
lines are automatically added by the apxs
utility.
####################################################
APACHE-HOME/conf/httpd.conf file ####################################################
LoadModule weblogic_module libexec/mod_wl.so
AddModule mod_weblogic.c
<Location /weblogic> SetHandler weblogic-handler PathTrim /weblogic ErrorPage http://myerrorpage1.mydomain.com </Location>
<Location /servletimages> SetHandler weblogic-handler PathTrim /something ErrorPage http://myerrorpage1.mydomain.com </Location>
<IfModule mod_weblogic.c> MatchExpression *.jsp WebLogicCluster w1s1.com:7001,w1s2.com:7001,w1s3.com:7001 ErrorPage http://myerrorpage.mydomain.com </IfModule>
Instead of defining parameters in the location
block of your httpd.conf
file, if you prefer, you can use a weblogic.conf
file that is loaded by the IfModule
in the httpd.conf
file. The following examples may be used as templates that you can modify to suit your environment and server. Lines beginning with # are comments.
Example Using WebLogic Clusters
# These parameters are common for all URLs which are # directed to the current module. If you want to override # these parameters for each URL, you can set them again in # the <Location> or <Files> blocks. (Except WebLogicHost, # WebLogicPort, WebLogicCluster, and CookieName.)
<IfModule mod_weblogic.c> WebLogicCluster w1s1.com:7001,w1s2.com:7001,w1s3.com:7001 ErrorPage http://myerrorpage.mydomain.com MatchExpression *.jsp </IfModule> ####################################################
Example Using Multiple WebLogic Clusters
# These parameters are common for all URLs which are # directed to the current module. If you want to override # these parameters for each URL, you can set them again in # the <Location> or <Files> blocks (Except WebLogicHost, # WebLogicPort, WebLogicCluster, and CookieName.)
<IfModule mod_weblogic.c> MatchExpression *.jsp WebLogicHost=myHost|WebLogicPort=7001|Debug=ON MatchExpression *.html WebLogicCluster=myHost1:7282,myHost2:7283|ErrorPage= http://www.xyz.com/error.html </IfModule>
Example Without WebLogic Clusters
# These parameters are common for all URLs which are # directed to the current module. If you want to override # these parameters for each URL, you can set them again in # the <Location> or <Files> blocks (Except WebLogicHost, # WebLogicPort, WebLogicCluster, and CookieName.)
<IfModule mod_weblogic.c> WebLogicHost myweblogic.server.com WebLogicPort 7001 MatchExpression *.jsp </IfModule>
Example Configuring IP-Based Virtual Hosting
NameVirtualHost 172.17.8.1 <VirtualHost goldengate.domain1.com> WebLogicCluster tehama1:4736,tehama2:4736,tehama:4736 PathTrim /x1 ConnectTimeoutSecs 30 </VirtualHost> <VirtualHost goldengate.domain2.com> WeblogicCluster green1:4736,green2:4736,green3:4736 PathTrim /y1 ConnectTimeoutSecs 20 </VirtualHost>
Example Configuring Name-Based Virtual Hosting With a Single IP Address
<VirtualHost 162.99.55.208> ServerName myserver.mydomain.com <Location / > SetHandler weblogic-handler WebLogicCluster 162.99.55.71:7001,162.99.55.72:7001 Idempotent ON Debug ON DebugConfigInfo ON </Location> </VirtualHost>
<VirtualHost 162.99.55.208> ServerName myserver.mydomain.com <Location / > SetHandler weblogic-handler WebLogicHost russell WebLogicPort 7001 Debug ON DebugConfigInfo ON </Location> </VirtualHost>
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|