8
Specialized Configurations

This chapter provides instructions for establishing specialized configurations for OracleAS Web Cache, including configuring OracleAS Web Cache for HTTPS protocol requests, multiple origin servers, a cache hierarchy, and a cache cluster.

This chapter contains these topics:

Configuring OracleAS Web Cache for HTTPS Requests

To provide more security for your Web site, you can configure OracleAS Web Cache to receive HTTPS protocol browser requests and send HTTPS requests to the origin server. HTTPS uses the Secure Sockets Layer (SSL) to encrypt and decrypt user page requests as well as the pages that are returned by the OracleAS Web Cache and origin servers.

Typically, HTTP requests to origin servers use port 80 and HTTPS requests use port 443.

See Also:
Oracle HTTP Server Administrator's Guide for information about enabling SSL on the Oracle HTTP Server

You can also configure OracleAS Web Cache to send traffic to the application Web server through an HTTP or HTTPS listening port.

To configure HTTPS support, perform these tasks:

Task 1: Create Wallets

To support HTTPS for OracleAS Web Cache, you must create a wallet on the OracleAS Web Cache server for each supported site. Wallets are needed to support the following HTTPS requests:

Browser requests using the HTTPS protocol for sites hosted by OracleAS Web Cache
Administration, invalidation, and statistics monitoring requests to OracleAS Web Cache using the HTTPS protocol
OracleAS Web Cache requests using the HTTPS protocol to origin servers

Each site that uses the HTTPS protocol requires at least one wallet. One wallet can be shared among all the HTTPS listening ports, or a separate wallet can be created for each HTTPS listening port.

For OracleAS Web Cache to use the wallet, OracleAS Web Cache must be started by the user that created the wallet.

For detailed instructions on creating a wallet, see the Oracle Application Server 10g Security Guide. The following provides the basic steps in creating a wallet for use by OracleAS Web Cache:

Invoke Oracle Wallet Manager:
- On UNIX, log in as the user and group ID configured in the Process Identity page (Properties > Process Identity). Then, run owm from $ORACLE_HOME/bin.
- On Windows, log in as the user that installed OracleAS Web Cache and choose Start > Programs > Oracle - Oracle_homename > Network Administration > Wallet Manager
  
  When the cache server process starts, OracleAS Web Cache opens the wallet as one of these users.
Create the wallet (Wallet > New), entering a password as prompted.
You are prompted whether or not to create a certificate request. Click Yes. Then, enter the information in the dialog box. For Common Name, specify the name or alias of the site that will be configured for HTTPS support.
Submit the certificate to a Certificate Authority (CA) for signature.
Import the CA's root certificate into the wallet (Operations > Import Trusted Certificate).
Enable Auto-login, which enables PKI-based access to services without a password. Select the wallet and choose Wallet from the menu bar. Check Auto Login.
Save the wallet. Select the wallet and choose Wallet > Save.

When you receive the signed certificate from the CA, import it into the wallet (Operations > Import User Certificate) and save the wallet.

Note:
If you are using OracleAS Web Cache in a standalone environment, you must take special actions to enable wallets to open on Windows. See "Enabling Wallets to Open on Windows" for more information.

By default, wallets are stored in the following locations:

Task 2: Configure HTTPS Listening Ports and Wallet Location for the Cache

To configure HTTPS protocol support between browsers and OracleAS Web Cache, you must configure an HTTPS listening port for OracleAS Web Cache:

From the navigator frame in OracleAS Web Cache Manager, select Ports > Listen Ports and click Add.
Specify the information for the port, selecting HTTPS for the Protocol.
Enable or disable client-side certificates.

Select Require Client-Side Certificate to enable OracleAS Web Cache to require browsers to provide SSL certificates.

A client-side certificate is a method for verifying the identity of the client. It binds information about the client user to the user's public key and must be digitally signed by a trusted CA.
Enter the location of the wallet in the Wallet field.

This wallet is used for browser requests for sites hosted by OracleAS Web Cache.

By default, wallets are stored in /etc/ORACLE/WALLETS/user_name on UNIX and in %USERPROFILE%\ORACLE\WALLETS on Windows operating systems. Oracle Corporation recommends entering the location, even if the default is being used.

If each site is configured with a separate wallet, the OracleAS Web Cache listening port can share the same wallet as specified in the Origin Server Wallet page (Origin Servers, Sites, and Load Balancing > Origin Server Wallet).
Click Submit.

See Also:
"Task 6: Configure OracleAS Web Cache with Listening Ports for Incoming Browser Requests" for information about adding ports

Task 3: Configure HTTPS Operations Ports for the Cache

To configure HTTPS ports for administration, invalidation, and statistics monitoring requests:

From the navigator frame, select Ports > Operations Ports and click Add.
Specify the information for the port, selecting HTTPS for the Protocol.
Enable or disable client-side certificates.

Select Require Client-Side Certificate to enable OracleAS Web Cache to require browsers to provide SSL certificates.

A client-side certificate is a method for verifying the identity of the client. It binds information about the client user to the user's public key and must be digitally signed by a trusted CA.
In the Wallet field, enter the location of the wallet.

This wallet is used for administration, invalidation, and statistics monitoring of HTTPS requests for sites hosted by OracleAS Web Cache.

By default, wallets are stored in /etc/ORACLE/WALLETS/user_name on UNIX and in %USERPROFILE%\ORACLE\WALLETS on Windows. Oracle Corporation recommends entering the location, even if the default is being used.

If each site is configured with a separate wallet, these ports can share the same wallet established for the OracleAS Web Cache listening port in "Task 2: Configure HTTPS Listening Ports and Wallet Location for the Cache" and specified in the Listen Ports page (Ports > Listen Ports) and the Origin Server Wallet page (Origin Servers, Sites, and Load Balancing > Origin Server Wallet).

"Task 8: Configure OracleAS Web Cache with Operations Ports" describes how to add a port.
Click Submit.

See Also:
Oracle Application Server 10g Administrator's Guide for information about updating the port numbers for other Oracle Application Server components

Task 4: Create a Site for HTTPS Requests

You must create a site that will accept HTTPS requests.

In the navigator frame, select Origin Servers, Sites, and Load Balancing > Site Definitions.
In the Site Definitions page, click Add Site.
Specify the information as described in "Task 10: Configure Web Site Settings" .

In the Port field, enter the number of the HTTPS listening port. This site will use the wallet defined for that port.

In the HTTPS Only Prefix field, enter the URL prefix for which only HTTPS requests will be served. If all traffic must be restricted to HTTPS, enter "/ " for the entire site.
Click Submit.

Task 5: Configure HTTPS Port and Wallet Location for the Origin Server

You can configure HTTPS protocol support between OracleAS Web Cache and origin servers. When you use the Oracle HTTP Server as the origin server, requests from an OracleAS Web Cache server configured with an HTTPS listening port are passed on a secure (SSL) connection. It is not necessary to configure an HTTPS port for an Oracle HTTP Server.

However, for other origin servers, you must configure an HTTPS port to secure the connection from OracleAS Web Cache to the origin server.

To configure HTTPS protocol support between OracleAS Web Cache and origin servers:

From the navigator frame, select Origin Servers, Sites, and Load Balancing > Origin Servers.
In the Origin Servers page, either click Add to add an origin server, or select an existing server and click Edit.
In the dialog box, specify the information for the origin server, selecting HTTPS for the Protocol. (See "Task 9: Configure Origin Server, Load Balancing, and Failover Settings" for information on configuring the origin server.)
Click Submit.

Then, you specify the location of the wallet for OracleAS Web Cache communication to the origin server.

This wallet manages OracleAS Web Cache authentication data, such as keys, certificates, and trusted certificates needed by the Secure Sockets Layer (SSL). By default, wallets are stored in /etc/ORACLE/WALLETS/user_name on UNIX and %USERPROFILE%\ORACLE\WALLETS on Windows.

If each site is configured with a separate wallet, HTTPS requests from OracleAS Web Cache to the origin server can share the same wallet as established for the OracleAS Web Cache listening ports. This is the default wallet.

Oracle Corporation recommends entering the location, even if the default is being used.

To specify the wallet location:

In the navigator frame, select Origin Servers, Sites, and Load Balancing > Origin Server Wallet.

The Origin Server Wallet page appears.
Select the cache for which you want to modify wallet settings, and then click Edit Selected.

The Edit Origin Server Wallet dialog box appears.
In the Wallet Directory field, enter the location of the wallet.
Click Submit.

Task 6: Create the Site-to-Server Mapping

You must map the site for HTTPS requests to the origin server:

In the navigator frame, select Origin Servers, Sites, and Load Balancing > Site-to-Server Mapping.
Create a mapping as described in "Map Sites to Origin Servers", specifying the site you created in "Task 4: Create a Site for HTTPS Requests".
Click Submit.

Task 7: (Optional) Require Client-Side Certificates

You can require that clients send certificates (client-side certificates) to the cache to verify the identity of the client.

With client-side certificates, the browser sends the certificate to the cache during the SSL handshake. Then, the server processes the request for the document. If the requested document is not stored in the cache, the cache forwards the request to the application Web server, a peer cache (in a cluster), or a subordinate cache (in a hierarchy). To transfer information about the client-side certificate to another cache or to the application Web server, OracleAS Web Cache adds HTTP headers to the request. The headers begin with the string SSL-Client-Cert.

Note the following points about using client-side certificates:

In a simple configuration (client to cache to application Web server), the client sends the certificate to the cache during the SSL handshake. If the requested document is not stored in the cache, the cache forwards the request to the application Web server and transfers the client-side certificate information in headers to the application Web server. The application Web server recognizes the headers and responds to the request.
In a cluster, the client sends the certificate to a cache cluster member during the SSL handshake. If the requested document is not stored in that cache, the cluster member requests it from a peer (the cluster member that owns the document). With client-side certificates, OracleAS Web Cache must be able to pass the client-side certificate information in headers to the peer cluster member, and the peer must be able to pass the headers to the application Web server.
In an ESI hierarchical deployment, the browser sends the certificate to the subscriber cache in a hierarchy. That cache must be able to forward the certificate information in headers to a provider cache. However, with this configuration, the provider caches could inadvertently accept the certificate information in a header from a bogus entity. To prevent this, you must secure the provider caches, by methods such as installing them behind a firewall.

If client-side certificates are required, but not provided by the client, OracleAS Web Cache returns an error: 403: Forbidden.

Note:
OracleAS Web Cache supports the use of client-side certificates with Oracle HTTP Server only.
OracleAS Web Cache does not support client-side certificates with a distributed cache hierarchy because the security of the certificates cannot be guaranteed.

To use client-side certificates, you must enable an HTTPS listening port. If you have a cache cluster, you must enable HTTPS listening ports for all cluster members. In addition, take the following steps:

In the OracleAS Web Cache Manager navigator frame, select Ports > Listen Ports.

The Listen Ports page is displayed.
Select the HTTPS port and click Edit.
In the Edit Listening Port dialog box, select Require Client-Side Certificate.
Click Submit.
If you have a simple configuration, not a cache cluster or a cache hierarchy, proceed to the next section, "Task 8: (Optional) Permit Only HTTPS Requests for a URL or Set of URLs".
If you have a cache cluster, you must prevent a cache from accepting the certificate information in HTTP headers from any source other than a peer cluster member. In addition, each cache must be able to pass the client-side certificate information in headers to the peer cluster member, and the peer must be able to pass them to the application Web server. To configure this behavior:
1. In the navigator frame, select Properties > Security.
2. In the Special Security Header Configuration section of the Security page, the value of the following must be NO (the default):
```
Accept SSL client certificates encoded in SSL-Client-Cert HTTP headers
```
  If it is not, click Edit.
  
  The Special Security Header Configuration dialog box is displayed.
3. Clear Accept SSL client certificates encoded in SSL-Client-Cert HTTP headers.
4. Click Submit.
5. In the Cluster Security Configuration section of the Security page, the value of the following must be YES:
```
Route requests that contain SSL client certificates to cache cluster 
peers
```
  If it is not, click Edit.
  
  The Cluster Security Configuration dialog box is displayed.
6. Select Route requests that contain SSL client certificates to cache cluster peers.
7. Click Submit.
If you have an ESI cache hierarchy, a provider cache, must be able to accept the client-side certificate information in headers from the subscriber cache. To enable this behavior:
1. In the navigator frame, select Properties > Security.
2. In the Special Security Header Configuration section of the Security page, the value of the following must be YES:
```
Accept SSL client certificates encoded in SSL-Client-Cert HTTP headers
```
  If it is not, click Edit.
  
  The Special Security Header Configuration dialog box is displayed.
3. Select Accept SSL client certificates encoded in SSL-Client-Cert HTTP headers.
4. Click Submit.
5. If the subordinate caches are in a cluster, the subordinate caches must be able to pass the client-side certificate information in headers to the peer cluster member. In this case, in the Cluster Security Configuration section of the Security page, the value of the following must be YES:
```
Route requests that contain SSL client certificates to cache cluster 
peers
```
  If it is not, click Edit.
  
  The Cluster Security Configuration dialog box is displayed.
6. Select Route requests that contain SSL client certificates to cache cluster peers.
7. Click Submit.

You can also specify that an entire site require client-side certificates:

In the navigator frame, select Origin Servers, Sites, and Load Balancing > Site Definitions.
In the Site Definitions page, select the site and click Edit Site.
In the Edit Site page, select Required in the Client-Side Certificate field.
Click Submit.

Task 8: (Optional) Permit Only HTTPS Requests for a URL or Set of URLs

You can restrict a URL or set of URLs for a site to permit only HTTPS requests.

To allow only HTTPS traffic for a URL or a set of URLs:

Configure Web site settings, as described in "Task 10: Configure Web Site Settings".
In Step 2 d, enter the URL or URL prefix.

If all traffic must be restricted to HTTPS, enter "/" for the entire site.

Task 9: Restart OracleAS Web Cache

To apply changes, in the OracleAS Web Cache Manager main window, click Apply Changes.

Then, you must restart the cache or admin server processes, using the opmnctl utility or webcachectl utility (for standalone installations) on the computer on which OracleAS Web Cache software is installed and configured.

To use the opmnctl utility to restart both processes, enter the following command:

opmnctl startproc ias-component=WebCache

Configuring a Hierarchy of Caches

This section describes additional configuration options available for cache hierarchy deployments. This section contains the following topics:

Configuring a Distributed Cache Hierarchy

In a distributed cache hierarchy, the central cache stores content from application Web servers, and the remote cache stores content from the central cache. The central cache acts as an origin server to the remote cache.

To configure a distributed cache hierarchy, perform the tasks in "Tasks for Setting Up OracleAS Web Cache" for each cache. When performing the tasks, take special care to perform the following:

Configure the correct origin server:
- For the central cache, configure the central origin servers in the Origin Servers page (Origin Servers, Sites, and Load Balancing > Origin Servers).
- For the remote caches, configure the central cache as the origin server in the Origin Server page.
Create the same site definition for both the central and remote caches in the Site Definitions page (Origin Servers, Sites, and Load Balancing > Site Definitions).
For both central and remote caches, map the site definition to the origin server (configured in Step 1) in the Site-to-Server Mapping page (Origin Servers, Sites, and Load Balancing > Site-to-Server Mapping):
- For the central cache, map the site to the application Web server or proxy server.
- For the remote cache, map the site to the central cache.
Route that network so that browser requests are forwarded to the nearest cache.
Optionally, ensure that the ClientIP address information that is forwarded to the cache and origin server is valid.

See Also:
"Ensuring That ClientIP Headers Are Valid"

When content from the central cache becomes invalid, an invalidation message is sent to its cache. In addition, the central cache propagates the invalidation message to the remote caches.

Note:
In order for automatic propagation of invalidation messages to work, OracleAS Web Cache passes the encoded invalidator password in the page request between the remote and central cache during the hierarchy registration process. This HTTP traffic is susceptible to network sniffing. If the network is unprotected and insecure, configure HTTPS ports as follows:

In the Listen Ports page (Ports > Listen Ports) of the central cache, disable the default HTTP port and configure an HTTPS port in its place.

In the Operations Ports page (Ports > Operations Ports) of the remote cache, disable the default HTTP port for invalidation and configure an HTTPS port in its place.

Table 8-1 shows the example settings for the deployment depicted in "Deploying a Distributed Cache Hierarchy".

Table 8-1 Settings for us.webche-host and jp.webche-host

Setting Location in OracleAS Web Cache Manager	Central Cache us.webche1-host and us.webche2-host	Remote Cache jp.webche-host
Listening Port (Ports > Listen Ports)	Port: `7777`	Port: `7777`
Application Web Server (Origin Servers, Sites, and Load Balancing > Origin Servers)	Host and Port: `app1-host1: 7778` Host and Port: `app1-host2: 7778` Host and Port: `app2-host: 7778`	Host and Port: `us.webche1-host: 7777` Host and Port: `us.webche2-host: 7777`
Site Definition (Origin Servers, Sites, and Load Balancing > Site Definitions)	Host and Port: `www.app1.company.com`:8`0` Host and Port: `www.app2.company.com`:`80`	Host and Port: `www.app1.company.com:80` Host and Port: `www.app2.company.com:80`
Site-to-Server Mapping (Origin Servers, Sites, and Load Balancing > Site-to-Server Mapping)	Site Host and Port: `www.app1.company.com:80` Origin Server Host and Port: `app1-host1:7778` `app1-host2:7778` Site Host and Port: `www.app2.company.com:80` Origin Server Host and Port: `app2-host:7778`	Site Host and Port: `www.app1.company.com:80` `www.app2.company.com:80` Origin Server Host and Port: `us.webche1-host:7777` `us.webche2-host:7777`

Configuring an ESI Cache Hierarchy

In an ESI cache hierarchy, a provider cache stores content from an ESI provider site, and a subscriber cache stores content from the origin servers for a local site and contacts provider caches for ESI fragments. The provider cache acts as an origin server to the subscriber cache.

To configure an ESI cache hierarchy, perform the tasks in "Tasks for Setting Up OracleAS Web Cache" for each cache. When performing the tasks, take special care to perform the following:

Configure the correct origin server:
- For each provider cache, configure the origin servers of the ESI provider site in the Origin Servers page (Origin Servers, Sites, and Load Balancing > Origin Servers).
- For the subscriber cache, configure the origin servers of the local site and the provider caches in the Origin Servers page.

Create site definitions:

For each provider cache, create a site definition for the ESI provider site in the Site Definitions page (Origin Servers, Sites, and Load Balancing > Site Definitions).

For the subscriber cache, create site definitions for the local site and each ESI provider site in the Site Definitions page.

Note:
It may not be possible to specify a site definition for all external ESI provider sites. If an ESI request is made to a provider that does not match any application Web server mapping, then OracleAS Web Cache uses DNS to resolve the site name. Note that this will not work if there is a firewall between the cache and the ESI provider. In that case, you must provide a proxy server mapping that directs the request to the appropriate proxy.

For both subscriber and provider caches, map the site definition to the origin server (configured in Step 1) in the Site-to-Server Mapping page (Origin Servers, Sites, and Load Balancing > Site-to-Server Mapping):
- For the provider caches, map the site definition to the origin server of the ESI provider site.
- For the subscriber cache, map the local site definition to the origin server for that site, and map each ESI provider site definition to its respective provider cache
Optionally, ensure that the ClientIP address information that is forwarded to the cache and origin server is valid.

See Also:
"Ensuring That ClientIP Headers Are Valid"

When content from the provider cache becomes invalid, an invalidation message is sent to its cache. In addition, the provider cache propagates the invalidation message to the subscriber cache.

Note:
In order for automatic propagation of invalidation messages to work, OracleAS Web Cache passes the encoded invalidator password in the page request between the subscriber and provider cache during the hierarchy registration process. This HTTP traffic is susceptible to network sniffing. If the network is unprotected and insecure, configure HTTPS ports as follows:

In the Listen Ports page (Ports > Listen Ports) of the provider cache, disable the default HTTP port and configure an HTTPS port in its place.

In the Operations Ports page (Ports > Operations Ports) of the subscriber cache, disable the default HTTP port for invalidation and configure an HTTPS port in its place.

Table 8-2 shows the example settings for the deployment depicted in Figure 8-1.

Figure 8-1 Deploying Support for Multiple Internal ESI Provider Sites

Text description of owcag052.gif follows

Text description of the illustration owcag052.gif

Table 8-2 Settings for webche1 and webche2

Setting Location in OracleAS Web Cache Manager	Subscriber Cache webche-host	Provider Cache webche-providerhost
Listening Port (Ports > Listen Ports)	Port: `7777`	Port: `7777`
Application Web Server (Origin Servers, Sites, and Load Balancing > Origin Servers)	Host and Port: `server-host: 7778` Host and Port: `provider1-host:7778` Host and Port: `webche-providerhost:7777`	Host and Port: `provider2-host: 7778`
Site Definition (Origin Servers, Sites, and Load Balancing > Site Definitions)	Host and Port: `www.server.com:80` Host and Port: `www.providersite1.com`:`80` Host and Port: `www.providersite2.com`:`80`	Host and Port: `www.providersite2.com`:`80`
Site-to-Server Mapping (Origin Servers, Sites, and Load Balancing > Site-to-Server Mapping)	Site Host and Port: `www.server.com:80` Origin Server Host and Port: `server-host:7778` Site Host and Port: `www.providersite1.com:80` Origin Server Host and Port: `provider1-host:7778` Site Host and Port: `www.providersite2.com:80` Origin Server Host and Port: `webche-providerhost:7777`	Site Host Name and Port: `www.providersite2.com:80` Origin Server Host and Port: `provider2-host:7778`

Additional Hierarchy Configuration for a Cache Cluster

In a cache hierarchy, each cache cluster member acts as an independent cache. Invalidation messages are propagated from each central or provider cache cluster member to the respective remote or subscriber caches. This configuration can result in the same invalidation message being propagated multiple times by cache cluster members.

If your deployment uses a Load Balancer to distribute requests among cache cluster members, you can optionally configure the cache cluster members to act as one cache and to receive only one set of propagated invalidation messages.

To configure cache cluster members to act as one cache for the purposes of hierarchical caching:

Select a cache cluster member to represent the cache.
For each of the other cache cluster members, use a text editor to open the webcache.xml file.
Locate the CLUSTERINFO element.

Add the following subelements:

<CLUSTERINFO NAME="CLUSTER_IP" VALUE="IP_address" />
<CLUSTERINFO NAME="CLUSTER_NORM_PORT" VALUE="web_cache_listening_Port" />
<CLUSTERINFO NAME="CLUSTER_INV_PORT" VALUE="web_cache_invalidation_port" />
<CLUSTERINFO NAME="CLUSTER_INV_SSL" VALUE="SSL_version" />

Table 8-3 describes how to enter values for the subelements.

Table 8-3 CLUSTERINFO Subelements

Subelement	Description
`CLUSTER_IP`	Enter the IP address of the cache.
`CLUSTER_NORM_PORT`	Enter the listening port of the cache. See Also: "Task 6: Configure OracleAS Web Cache with Listening Ports for Incoming Browser Requests"
`CLUSTER_INV_PORT`	Enter the invalidation port of the cache. See Also: "Task 8: Configure OracleAS Web Cache with Operations Ports"
`CLUSTER_INV_SSL`	If the invalidation port is configured for HTTPS, configure the correct SSL version: `NONE` for HTTP-only requests (default) `SSL` for HTTPS requests supporting SSL version 1.0 `SSLV2` for HTTPS requests supporting SSL version 2.0 `SSLV3` for HTTPS requests supporting SSL version 3.0 `SSLV3_V2H` for HTTPS requests supporting either SSL version 2.0 or 3.0

For example, if a cache cluster has members webche1-host, webche2-host, and webche3-host, you cans configure webche2-host, and webche3-host with settings for webche1-host as follows:

<CLUSTERINFO NAME="CLUSTER_IP" VALUE="130.35.45.41" />
<CLUSTERINFO NAME="CLUSTER_NORM_PORT" VALUE="4000" />
<CLUSTERINFO NAME="CLUSTER_INV_PORT" VALUE="4001" />
<CLUSTERINFO NAME="CLUSTER_INV_SSL" VALUE="NONE" />

This configuration enables the cache cluster to acts as one logic cache and only webche1-host to receive the propagated invalidation messages.

Restart OracleAS Web Cache with the following command:
```
opmnctl restartproc ias-component=WebCache
```

Configuring a Cache Cluster

To increase the availability and scalability of your Web site, you can configure multiple instances of OracleAS Web Cache to run as members of a cache cluster.

To configure a cache cluster, you specify the general cluster information in the Clustering page of the OracleAS Web Cache Manager and add two or more OracleAS Web Cache instances to the cache cluster.

A cache cluster uses one configuration that is propagated from the current cache (the cache to which your browser is connected) to all cluster members. The configuration contains settings that are the same for all cluster members as well as cache-specific settings for each cluster member.

The following settings pertain to all members of a cluster:

Security
Auto-restart
Application Web servers
Proxy servers
Site definitions
Site to origin server mappings
Caching and expiration rules
Error pages
Session management

The following settings are specific to each member of the cluster:

Process identity
Network timeouts
Resource limits
End-User Performance Monitoring
Event logs
Access logs
Operations ports, such as administration, invalidation, and statistics ports
Listener ports
Origin server wallet

Because a cache cluster contains two or more instances of OracleAS Web Cache, you must have two or more instances of OracleAS Web Cache installed on one or more nodes before you configure a cache cluster. The instances must be the same version of OracleAS Web Cache.

To configure a cache cluster, perform these tasks:

In addition, see the following information about configuring clusters:

Task 1: Configure Cache Cluster Settings

To configure the settings for a cache cluster:

In the navigator frame, select Properties > Clustering.

The Clustering page appears. The General Cluster Information section displays the default clusterwide values for failover and invalidation propagation. The Cluster Members table displays the current cache (the cache to which you are connected) as the only cluster member. OracleAS Web Cache ignores the cluster information if there is only one cluster member.
In the General Cluster Information section of the Clustering page, click Edit.

The Edit General Cluster Information dialog box appears.
In the Cluster Name field, enter a name for the cluster.
In the Failover Threshold field, enter the number of allowed consecutive request failures before OracleAS Web Cache considers another cache cluster member to have failed.

OracleAS Web Cache considers a request to another cache cluster member to have failed if:
- There are any network errors
- The HTTP response status code is either less than 100, or is one of the following: 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, or 504 Gateway Timeout.
For each failed request, OracleAS Web Cache increments the failure counter for that cluster member. This counter is kept separately by each cluster member. When a request is successfully processed by a cluster member, OracleAS Web Cache resets the failure counter.

When the failover threshold is met, OracleAS Web Cache considers the cache cluster member to have failed. OracleAS Web Cache recalculates the relative capacity of the remaining cache cluster members. It then reassigns ownership of cache content.

When a cache cluster member is down, OracleAS Web Cache starts polling the cache cluster member. It does this by sending requests to the URL specified in the Ping URL field. When OracleAS Web Cache receives a success response from the cache cluster member, it considers that cache cluster member to be up again. It recalculates the relative capacity of the cache cluster members and it reassigns ownership of cache content.
In the Ping URL field, enter the URL that cache cluster members will use to attempt to contact a cache cluster member that has reached its failover threshold.

Use a URL that is cacheable and that you can guarantee is stored in each cache. The default is "/".
In the Ping Interval field, enter the time, in seconds, between attempts by a cluster member to reach the failed cluster member. The default, 10 seconds, is a reasonable interval for most situations.
In the Propagate Invalidation field, select Yes or No to specify whether or not you want all invalidation requests from any cache cluster member to be propagated to other cache cluster members.
Click Submit.
In the Cluster Members table of the Clustering page, default values are displayed for the current cache. Select the cache and click Edit Selected.

The Edit Cluster Member dialog box appears.
In the Cache Name field, enter a name for the OracleAS Web Cache instance. The name must be unique from the names of other caches in the cache cluster.
By default, the Host Name field contains the host name of the node on which OracleAS Web Cache is installed. Usually, you do not need to modify this field.
By default, the Oracle Home field contains the file specification for the Oracle home in which OracleAS Web Cache is installed. Usually, you do not need to modify this field. Note that the combination of Host Name and Oracle Home must be unique in a cache cluster.
In the Capacity field, enter the number of concurrent incoming connections from other cache cluster members that OracleAS Web Cache can sustain.

This field is used in two different ways:
- As the absolute capacity for the number of concurrent incoming connections to this cache cluster member from all other cache cluster members.
  
  The connections are used to receive requests for owned content from other cache cluster members. The number of connections are divided among the other cluster members. For example, in a three-cache cluster, if the capacity of Cache_A is 50, Cache_B can open 25 connections to Cache_A and Cache_C can open 25 connections to Cache_A.
  
  More connections are used when another cache cluster member contains little or no data in its cache, such as when it is initially started, when it recovers from a failure, or after invalidation. During this time, the cluster member sends many of the requests to its peers, the owners of the content. In most cases, these requests are satisfied more quickly than requests to the origin server. Having a higher number of connections increases performance during this time and shortens the time it takes to fully load the cache. After a cache is fully loaded, fewer of the connections are used. There is no overhead for unused connections.
- As the relative capacity of the cache cluster member.
  
  The capacity of a cache cluster member is weighted against the total capacity of all active cache cluster members. When you set the capacity, OracleAS Web Cache assigns a percentage of the ownership array to the cluster member, indicating how much of the cached content will be owned by the cluster member. The percentage is calculated using the following formula:
```
cluster_member_capacity / total_capacity_of_all_active_cluster_members
```
  For example, if cache cluster member Cache_A has a capacity of 100 and cache cluster member Cache_B has a capacity of 300, for a total capacity of 400, Cache_A is assigned 25 percent of the ownership array and Cache_B is assigned 75 percent of the ownership array. That means that Cache_A owns 25 percent of the cached content.
  
  Note that in calculating the relative capacity, OracleAS Web Cache considers the capacity of active cluster members; it does not consider the capacity of cluster members that it has determined to have failed.
In most cases, a capacity of 100 is a reasonable number to use as a starting point.

If you assign a capacity of 0 to a cluster member, that cluster member will not receive requests from other cluster members. However, that cluster member will forward requests to other cluster members, the owners of the content.

If you assign a capacity of 0 to all cluster members, no requests will be forwarded between cluster members. With this setup, you can propagate the configuration and invalidation across all cache cluster members, simplifying the administration of many caches. See "Configuring Administration and Invalidation-Only Clusters" for more information.
Click Submit.

You now have one cache, the current cache, in the cluster. However, the cluster information is ignored until you have more than one OracleAS Web Cache instance in the cluster.

Task 2: Add Caches to the Cluster

Before you can add a cache to the cluster, the following conditions must be met:

The cache must exist and must be started. See "Task 12: Apply Changes and Restart OracleAS Web Cache" for information about starting OracleAS Web Cache.
The administrator password of the cache to be added must be the same as the administrator password of the cache to which you are connected. If it is different, you must connect to the cache's admin server and modify the administration password, as described in "Task 2: Modify Security Settings".

To add another cache to the cluster:

In the navigator frame, select Properties > Clustering.

The Clustering page appears.
In the Cluster Members section of the Clustering page, click Add.

The Add Cache to Cluster dialog box appears.
In the Host Name field, enter the host name of the cache to be added to the cluster.
In the Admin Port field, enter the administration port for the cache to be added to the cluster.

The administration port is the listening port for administrative requests.
In the Protocol for Admin Port field, select either HTTP or HTTPS to accept HTTP or HTTPS browser requests.
In the Cache Name field, enter a name for the cache. The name must be unique from the names of other caches in the cache cluster.
In the Capacity field, enter the number of concurrent incoming connections from other cache cluster members that OracleAS Web Cache can sustain.

See Also:
Step 13 in "Task 1: Configure Cache Cluster Settings" for more information about capacity
Click Submit.

The cache is now part of the cluster and is listed in the Cluster Member table.
To add more OracleAS Web Cache instances to the cache cluster, repeat Steps 2 through 8.
When you have completed adding members to the cache cluster, click Apply Changes.

OracleAS Web Cache adds the cache-specific information from the new cache cluster members to the cluster configuration.

You can add more OracleAS Web Cache instances to the cluster at any time by choosing Add. You can modify the settings for a cache cluster member by choosing Edit Selected. You can delete a cache cluster member, other than the current cache, by choosing Delete Selected.

Task 3: Enable Tracking of Session Binding

In a cache cluster, all cache cluster members must be able to determine which origin server established the session, although the request was routed originally through only one cache cluster member. To configure session binding in a cache cluster, you specify that OracleAS Web Cache adds a cookie that tracks session information so that it can be read by all cluster members. OracleAS Web Cache includes a Set-Cookie response-header in the response so that subsequent requests from the client include the cookie. The cookie provides information so that any of the cluster members can resolve the binding regardless of which cache handled the initial request.

See Also:

"Session Binding (Stateful Load Balancing)" for an overview of session binding

"Bind a Session to an Origin Server" for instructions on enabling session binding and tracking session binding in a cache cluster

Task 4: Propagate the Configuration to Cluster Members

When you modify the cluster and click Apply Changes, OracleAS Web Cache adds the cache-specific information from the new cache cluster members to the configuration. For those changes to take affect in all cluster members, you must propagate the configuration and restart the cache server process of the cluster members.

To propagate the configuration to new cluster members:

In the navigator frame, select Operations > Cache Operations.

The Cache Operations page appears. The Operation Needed column indicates the caches to which the configuration should be propagated.
Propagate the configuration to all cache cluster members:
1. Select All caches in the Operate On field.
2. Select an Interval of Immediate. (No other interval is allowed for propagation.)
3. Click Propagate.
(Alternatively, you can propagate the configuration to one cluster member at a time. Click Selected cache in the Operate On field, and then click Propagate.)

When the operation completes, the Operation Needed column in the Cache Operations page indicates the cluster members that need to be restarted.
Stop and restart all cluster members:
1. Select All caches in the Operate On field.
2. Select an Interval to stagger the time that operation begins on the caches, and then click Restart.
(Alternatively, you can restart one cluster member at a time.) Choose Selected cache in the Operate On field and then click Restart.)

When the operation completes, the Operation Needed column in the Cache Operations page indicates that no operations are needed. The cache cluster is ready to use.

Removing Caches from a Cluster

To remove a cache from a cluster, you must not only make sure that remaining cluster members no longer include that cache in cluster, but that the removed cache no longer considers itself to be part of the cluster. To remove a cache from a cluster, take the following steps:

Enter the URL for the OracleAS Web Cache Manager of one of the caches in cluster, but not the cache that you want to remove from the cluster. If prompted, enter the user name and password for the ias_admin or administrator user.
In the navigator frame, select Properties > Clustering.
In the Cluster Members section of the Clustering page, select the cache you want to remove from the cluster and click Delete Selected.
In the OracleAS Web Cache Manager main window, click Apply Changes.
Propagate the change to the other remaining cache cluster members:
1. In the navigator frame, select Operations > Cache Operations.
2. Select All caches in the Operate On field.
3. Select an Interval of Immediate.
4. Click Propagate.
  
  The change is propagated to all the remaining cluster members, but not to the removed cluster member.
Restart all cluster members:
1. In the Cache Operations page, select All caches in the Operate On field.
2. Select an Interval to stagger the time that operation begins on the caches, and then click Restart.
All remaining caches in the cluster no longer consider the removed cache to be part of the cluster. However, the removed cache still considers itself to be part of the cluster. To remedy that situation, take the next steps.
Enter the URL for the OracleAS Web Cache Manager of the cache you removed from the cluster. Enter the username and password for the ias_admin or administrator user.
In the navigator frame, select Properties > Clustering.

The Clustering page appears. The Cluster Members section still shows all members of the cluster.
In the Cluster Members section of the Clustering page, select each cache except the current one, and click Delete Selected. Repeat until only the current cache remains in the Cluster Members list.
In the OracleAS Web Cache Manager main window, click Apply Changes.
In the navigator frame, select Operations > Cache Operations.
Select the cache and click Restart.

Configuring Administration and Invalidation-Only Clusters

You can configure a cluster that supports propagating the configuration and invalidation requests across all cache cluster members, but that does not forward requests between cache cluster members. That is, in processing requests, each cluster member acts as an individual cache and does not request documents from its peer cluster members. However, configuration changes and invalidation requests can be propagated to cluster members.

This configuration can be used to simplify administration of many caches. It may be needed in a cluster where members are separated by a firewall. For example, you can have a cluster where two caches are located on either side of a firewall that separates the intranet from internet. (The network settings of such a setup--of sending internet traffic to one cache and intranet traffic to another--is beyond the scope of this document.)

To manage these caches as a cluster and avoid sharing contents between the caches, take the following steps:

Create a cluster and add members to it as discussed in "Task 1: Configure Cache Cluster Settings" and "Task 2: Add Caches to the Cluster", with the exception noted in the following step.
For each cluster member, set the capacity to 0. (Select Properties > Clustering. Then, select a cluster member and click Edit. In the Edit Cluster Member dialog box, set the Capacity to 0.)
Propagate the configuration to all cluster members, as described in "Task 4: Propagate the Configuration to Cluster Members".

Ensuring That ClientIP Headers Are Valid

A client, such as a browser, can send information about its IP address in a header in a request. However, because a client could use a false IP address in the header, allowing a cache to forward that information to another cache or to the origin server can be a potential security problem. By default, OracleAS Web Cache removes any IP header information forwarded from a client and replaces it with a header that contains the correct IP address of the client. (In this case, a client can be a browser or another cache in a hierarchy.)

In a cache hierarchy, OracleAS Web Cache must be able to preserve the information that is forwarded from one cache to another in the hierarchy or from a cache to the origin server.

To configure these settings:

In the navigator frame, select Properties > Security.
In the Special Security Header Configuration section of the Security page, check the value of the Accept client IP addresses encoded in ClientIP headers field.

If the value is NO, OracleAS Web Cache removes any ClientIP request-header forwarded from the client and replaces it with a header that contains the correct IP address.

If the value is YES, OracleAS Web Cache accepts the header received from the client and can forward it to another cache or the origin server.
If the settings do not match the following information, click Edit and change the settings in the Special Security Header Configuration dialog box:
- For a simple configuration, the value should be NO.
- In a cache cluster, the value should be NO for all cluster members.
- In an ESI hierarchy, for the subscriber cache, the value should be NO.
- In an ESI hierarchy, for the provider cache, the value should be YES.
  
  Because the provider cache received the header from the subscriber cache, it can safely forward it to the origin server.
- In a distributed cache hierarchy, for the remote cache, the value should be NO.
- In a distributed cache hierarchy, for a central cache that receives requests only from other caches, the value should be YES.
  
  If the central cache receives requests from both browsers and other caches in the hierarchy, OracleAS Web Cache cannot distinguish which is a browser and which is another cache. In this case, if you specify YES, a false IP address could potentially be forwarded from a browser. However, correct information would be forwarded from another cache. If you specify NO, a false IP address could not be forwarded from a browser. However, the information forwarded from another cache would contain the IP address of the cache, not of the original client.
Click Submit, and then click Apply Changes.

Enabling End-User Performance Monitoring

Using OracleAS Web Cache, you can monitor the response time of your applications by viewing information about how quickly the responses are delivered to the end users. From the time a user enters the Web site until they exit, you can monitor which URLs they view and view reports about the response times the end user has experienced.

To configure OracleAS Web Cache for end-user performance monitoring, configure a network load balancer for a deployment supporting multiple OracleAS Web Cache servers. The network load balancer enables OracleAS Web Cache to receive requests from the same browsers.

You can enable end-user performance monitoring for a specific cache or for a site. Take the following steps:

In the navigator frame of OracleAS Web Cache Manager, select Logging and Diagnostics > End-User Performance Monitoring.
Enable monitoring for a particular cache or for an entire site:
- To enable monitoring for a particular cache, in the End-User Performance Monitoring page, select the cache from the Cache-Specific End-User Performance Monitoring section. Then, click Enable.
- To enable monitoring for the entire site, in the End-User Performance Monitoring page, select the site from the Site-Specific End-User Performance Monitoring section. Then, click Enable.
Note the following:
- If you enable monitoring for a specific cache, but you disable monitoring for a site, monitoring is performed for all the sites in that cache except for the site for which it is disabled.
  
  If a request does not match any of the sites for which monitoring is enabled, the request will not be monitored.
- If you disable monitoring for a cache, monitoring is not performed for any of the sites of that cache node.
- For a site, you can specify end-user performance monitoring rules.
When end-user performance monitoring is enabled for a cache, OracleAS Web Cache monitors all requests that are routed through the cache. When end-user performance monitoring is enabled for a site, OracleAS Web Cache monitors all of the Web pages on your Web site and provides you with information about how the pages are responding to customer requests.
Optionally, select URLs to monitor or not monitor by creating site-specific monitoring rules as described in "Selecting URLs to Monitor".
Configure OracleAS Web Cache to use the Web Cache Log Format (WCLF) access log format, as described in "Configuring Access Logs".

See Also:
"Gathering End-User Performance Data" for information about gathering the data

Selecting URLs to Monitor

Using the OracleAS Web Cache Manager, for each site, you can further refine which Web pages are monitored, by specifying regular expressions or path substrings. Take the following steps:

In the navigator frame, select Logging and Diagnostics > End-User Performance Monitoring.
In the Site-Specific End-User Performance Monitoring section of the End-User Performance Monitoring page, select the site, then click View.
To add a site-specific rule, click Create Site-Specific Rule.

The Create End-User Performance Monitoring Rule page is displayed.
In the URL Expression field, specify the URL expression. Note the following information, which is dependent on the Expression Type selected:
- Path Substring: Enter a path substring.
  
  The substring is interpreted literally, including reserved regular expression characters. These characters include periods (.), question marks (?), asterisks (*), brackets ([]), curly braces ({}), carets (^), dollar signs ($), and backslashes (\).
  
  For example, if you enter a substring of down, any of the following URLs match the expression:
```
http://www.company.com/wireless/downloads/index.htm
http://www.company.com/support/updown.htm
http://www.company.com/support/shutdown_gdlines.htm
```
- Regular Expression: Enter the regular expression. Remember to use "^" to denote the start of the URL and "$" to denote the end of the URL.
  
  Regular expression syntax is based on the POSIX 1003 extended regular expressions for URLs, as supported by Netscape Proxy Server 2.5.
  
  When using POSIX regular expression, keep the following syntax rules in mind:
  - If these characters are not used, POSIX assumes a substring match. For example, ^/a/b/.*\.gif$ will match GIF files under /a/b or any of its subdirectories. /a/b/.*\.gif, on the other hand, could match /x/y/a/b/c/d.gift.
  - Use a period (.) to match any one character
  - Use a question mark (?) to match zero or one occurrence of the character that it follows
  - Use an asterisk (*) to match zero or more occurrences of the pattern that it follows
  - Use a backslash (\) to escape any special characters, such as periods (\.), question marks (\?), or asterisks (\*)
  For example, to monitor all URLs beginning with /machine/doc and ending in .gif, enter the following expression:
```
^/machine/doc/.*\.gif$
```
From the list in the Expression Type column, select one of the following options:
- Path Substring: Applies the monitoring rule to objects matching a substring of a path
- Regular Expression: Applies the monitoring rule to objects matching regular expression syntax
For Monitoring Policy, select Monitor or Don't Monitor for the rule.
Click Submit.
To create another monitoring rule, click Edit, Insert Above, or Insert Below. Then, repeat Steps 4 through 7.
If you have more than one monitoring rule, you can use the Move Up and Move Down buttons on the End-User Performance Monitoring page to prioritize the rules. Higher priority rules are processed first. The highest priority rule appears first in the list. The lower the number listed in the priority column, the higher the priority. For example, the highest priority rule is assigned a priority of one (1).

For a regular expression that matches documents or a subset of documents that you do not want to monitor, give the rule that specifies Don't Monitor a higher priority than the rule that specifies Monitor. For example, if you want all URLs containing /cec/cstage?ecaction=ecpassthru to be monitored except for /cec/cstage?ecaction=ecpassthru2, you would enter the rules in the following order:
1. ^/cec/cstage\?ecaction=ecpassthru2, Don't Monitor
2. ^/cec/cstage\?ecaction=ecpassthru.*, Monitor
If the order were reversed, all documents starting with /cec/cstage?ecaction=ecpassthru would be monitored, including /cec/cstage?ecaction=ecpassthru2.

Configuring for High Availability Without a Hardware Load Balancer

Many of the topologies described in Chapter 5 use hardware load balancers to provide support for virtual IP addresses and IP failover and to distribute incoming requests.

Certain operating systems provide similar support, which can increase the availability of OracleAS Web Cache, particularly in cache clusters.

When the operating system detects a failure of one of the caches, automatic IP takeover is used to distribute the load to the remaining caches in the cluster configuration. Because requests are sent to the virtual IP address, not to a specific host, requests can be served even if one of the hosts is unreachable.

In addition, some operating systems provide load balancing for incoming requests. You can configure the operating system to balance the load of incoming requests across caches on multiple nodes.

Note that a network load balancer does not provide all the features, such as a firewall, that a hardware load balancer may provide, but if those needs are already met, you could consider using a network load balancer.

The following section, "Configuring Microsoft Network Load Balancing" describes how to configure a network load balancer on one operating system. Refer to your operating system documentation for more information.

Configuring Microsoft Network Load Balancing

On certain Windows platforms, you can use the Microsoft Network Load Balancing (NLB) component of the operating system instead of a hardware load balancer. NLB is part of the Microsoft clustering offerings and is available on the following platforms:

Windows 2000 Advanced Server
Windows 2000 Datacenter Server
Windows 2003 (all editions)

You configure the hosts as a cluster and you configure the operating system to provide load balancing. Then, you configure NLB for hosts that are running Web Cache in a cache cluster, taking the following steps for each host:

Choose Start > Settings > Network and Dial-up Connections.
Select the network adapter. Then, right-click and select Properties.
In the Properties dialog box, select Network Load Balancing. Then, click Properties.
In the Cluster Parameters tab of the Network Load Balancing Properties dialog box, take the following steps:
1. For Primary IP Address, enter the virtual IP address to be shared by all members of the cluster.
2. For Subnet mask, enter the subnet mask for the virtual IP address.
3. For Full Internet Name, enter the full internet name for the virtual IP address.
4. Note the Network Address, which is a generated address.
5. For Multicast support, check enabled.
6. Optionally, enter a Remote password and enable Remote control.
Select the Host Parameters tab and take the following steps:
1. For Priority, enter an integer between 1 and 32. The lower the number, the higher the priority. Priority establishes the default handling priority among hosts for requests that are not load-balanced by port rules. (See Step 6 for information about configuring port rules.)
2. For Initial cluster state, check active. This specifies that this host should be included in the cluster array immediately upon Windows startup.
3. For Dedicated IP address, enter the IP address of this host.
4. For Subnet mask, enter the subnet mask of this host.
Select the Port Rules tab, and take the following steps:
1. For Port Range, to balance the load from all client requests with a single port rule, use the default port range (0-65535). Use multiple port rules if different applications require different protocols, filtering modes, or affinity.
2. For Protocols, select TCP. If your application uses software that requires UDP, select Both.
3. For Filtering Mode, select Multiple Hosts.
4. For Affinity, you can select one of three options. None results in load balancing of all requests across all hosts. Single results in all requests from a particular client being processed by the same host. Use this option to maintain session state. Class C results in all client requests from a TCP/IP class C address range being processed by the same host.
5. For Load Weight, either enter a percentage of the load to be handled by the host or select equal.
Note that Port Rules must be identical for all hosts in the cluster.

For more information about Microsoft Network Load Balancing, see the Microsoft documentation at:

http://www.microsoft.com

Configuring HTTP Request Header Limits

By default, OracleAS Web Cache provides the following limits for HTTP request header field:

81900 bytes for the total sum of all HTTP request header fields in requests

Oracle Corporation recommends setting the header size to a lower value than the default to ensure security and prevent denial-of-service attacks from malicious browsers.

If the length of the request is larger than the allowed limit, OracleAS Web Cache sends an error to the client and reports the WXE-11356 error to the event log:
```
Total request header length exceeds configured maximum. A forbidden error 
response is returned to the client.
```
8190 bytes for an individual HTTP request header field

Oracle Corporation recommends setting the individual header size based on how large an application sets HTTP requests header fields.

If the length of the request is larger than the allowed limit, OracleAS Web Cache sends an error to the client and reports the WXE-11355 error to the event log:
```
Single request header length exceeds configured maximum. A forbidden error 
response is returned to the client.
```

To modify the default header limits:

Start OracleAS Web Cache Manager.

See Also:
"Starting OracleAS Web Cache Manager"
In the navigator frame, select Properties > Security.

The Security page appears.
In the HTTP Request Header Limits section of the Security page, click Edit.

The HTTP Request Header Limits dialog box appears.
In the Maximum combined header size in bytes field, specify the total sum of all HTTP request header fields in requests.
In the Maximum individual header size in bytes field, specify the allowed length limit of an individual HTTP request header fields.
Click Submit, and then click Apply Changes.

Running webcached with Root Privilege

On UNIX, webcached must run as the root privilege in the following cases:

Privileged port numbers less than 1024 are being used for OracleAS Web Cache listening ports.
There are more than 1,024 file descriptors being used for connections to OracleAS Web Cache.
The current opmnctl or webcachectl user does not match the configured user in the Process Identity page (Properties > Process Identity) of OracleAS Web Cache Manager.

To run webcached with the root privilege:

Change the process identity of the OracleAS Web Cache processes.

Oracle Corporation recommends running OracleAS Web Cache using a restricted user, such as nobody/nobody.

To establish the process identity of a restricted user:
1. In the navigator frame, select Properties > Process Identity.
  
  The Process Identity page appears in the right pane.
2. In the Process Identity page, choose Change IDs.
  
  The Change Process Identity dialog box appears.
3. Enter the new user in the New User ID field and the group ID of the user in the New Group ID field.
4. Click Submit.
5. In the OracleAS Web Cache Manager main window, click Apply Changes.
Use the webcache_setuser.sh script as follows to run OracleAS Web Cache as a different user, such as nobody/nobody, and add set-user ID permission to the webcached executable:
```
webcache_setuser.sh setidentity <user_ID> 
```
where <user_ID> is the user you specified in the New User ID field of the Process Identity page.

For example, to run OracleAS Web Cache as nobody/nobody, enter:
```
webcache_setuser.sh setidentity nobody
```
See Also:
"Script for Setting File Permissions on UNIX" for further information about the webcache_setuser.sh script
Log out of the computer, and re-login as the user configured in the Process Identity page.
Start OracleAS Web Cache.

See Also:
"Starting and Stopping OracleAS Web Cache"

8 Specialized Configurations