This chapter provides information on how to work with Oracle HTTP Server (OHS). It discusses the procedures needed to configure and use OHS in your environment.
This chapter includes the following sections:
Before performing any of the tasks described in this chapter, you need to do the following:
Install and configure Oracle HTTP Server, as described in Installing and Configuring Oracle HTTP Server.
If you run Oracle HTTP Server in a WebLogic Server Domain, start WebLogic Server as described in "Starting and Stopping Servers" in Administering Server Startup and Shutdown for Oracle WebLogic Server.
Note:
When you start WebLogic Server from the command line, you might encounter many warning messages scrolling by. Despite these messages, WebLogic Server should start normally.Start Node Manager (required for both WebLogic and standalone domains), as described in "Using Node Manager" in Administering Node Manager for Oracle WebLogic Server.
Note:
As Node Manager starts, you might encounter many warnings scrolling by. You can ignore these messages.The Configuration Wizard enables you to create multiple Oracle HTTP Server instances simultaneously when you create a domain. If you are creating a WebLogic Server Domain, then you are not required to create any instances, whereas if you are creating a standalone domain, you need to create at least one Oracle HTTP Server instance. Note that, when creating a WebLogic Server domain, if you elect not to create any instances, a warning appears; however, you are allowed to proceed with the configuration process.
Note:
If you are attempting to create an Oracle HTTP Server instance that uses a TCP port in the reserved range (typically less than 1024), then you must perform some extra configuration to allow the server to bind to privileged ports. For more information, see Section 4.3.2.4, "Starting Oracle HTTP Server Instances on a Privileged Port (UNIX Only)."Note:
Oracle Fusion Middleware contains more than one version of WLST. The WLST commands used in all procedures in this chapter will only work if you run the WLST implementation on ORACLE_HOME/ohs/common/bin/.You can create a managed Oracle HTTP Server instance in a WebLogic Server Domain by using either the custom WebLogic Scripting Tool (WLST) command createOHSInstance()
or from Fusion Middleware Control. These procedures are described in the following sections.
Note:
If you are working with a WebLogic Server Domain, you should use the Oracle HTTP Server custom WLST commands, described in Section 3.6, "Using the WebLogic Scripting Tool". These commands offer superior error checking, provide automatic port management, and so on.To create an OHS instance in a WebLogic Server Domain by using WLST, do the following:
From the command line, launch WLST:
Linux: $ORACLE_HOME/ohs/common/bin/wlst.sh
Windows: $ORACLE_HOME\ohs\common\bin\wlst.cmd
Connect to WLST:
In a WebLogic Server Domain:
> connect('loginID', 'password', '<adminHost>:<adminPort>')
For example:
> connect('weblogic', 'welcome1', 'abc03lll.myCo.com:7001')
Use the createOHSInstance()
command, with an instance and machine name—which was assigned during domain creation—to create the instance:
> createOHSInstance(instanceName='ohs1', machine='abc03lll.myCo.com' [listenPort=XXXX] [sslPort=XXXX] [adminPort=XXXX])
Note:
If Node Manager should be down, the create command will take place partially. The master copy of the config files will appear at OHS/componentName. Once Node Manager comes back up, the system will resync and the runtime copy of the files will appear at OHS/instances/componentName.For example:
> createOHSInstance(instanceName='ohs1', machine='abc03lll.myCo.com')
Note:
If you do not provide port numbers, they will be assigned automatically.See also:
For information on using the WebLogic Scripting Tool (WLST), see Understanding the WebLogic Scripting Tool.To create an Oracle HTTP Server instance in a WebLogic Server Domain by using Fusion Middleware Control, do the following:
Log in to Fusion Middleware Control and navigate to the system component instance home page for the WebLogic Server Domain within which you want to create the Oracle HTTP Server instance.
Open the WebLogic Server Domain menu and select Administration then Create/Delete OHS.
Note:
Create/Delete OHS will only appear if you have extended the domain by using the Oracle HTTP Server domain template. Otherwise, this command will not be available.The OHS Instances page appears.
Click Create.
The Create OHS Instance page appears.
In Instance Name, type a unique name for the Oracle HTTP Server instance; for example, ohs4
.
In Machine Name, click the drop-down control and select the machine to which you want to associate the instance.
Click OK.
The OHS Instance page reappears, showing a confirmation message and the new instance.
After creating the instance, you will note that the Column on the OHS Instances page shows a down-arrow for that instance.
This indicates that the instance is not running. For instructions on starting an instance, see Section 4.3.2, "Starting Oracle HTTP Server Instances". Once started, the arrow will point up.
Once an instance is created, it will be provisioned within the DOMAIN_HOME.
The master copy will be in:
DOMAIN_HOME/config/fmwconfig/components/OHS/componentName
The runtime will be in:
DOMAIN_HOME/config/fmwconfig/components/OHS/instances/componentName
Immediately after creation, the state reported for an OHS instance will vary depending on how the instance was created:
If createOHSInstance()
was used, the reported state for the instance will be SHUTDOWN.
If the Configuration Wizard was used, the reported state for the instance will be UNKNOWN.
If you select Standalone as your domain during server configuration, the Configuration Wizard will create the domain but during this process you must create at least one Oracle HTTP Server instance. For more information, see Installing and Configuring Oracle HTTP Server.
If your Oracle HTTP Server instance is running in a standalone domain, you can use WLST but must use the offline, or "agent", commands that route tasks through Node Manager. The specific commands are described elsewhere in this chapter, in the context of the task they perform; however, you will need to use the nmConnect()
command to actually connect to offline WLST. For both Linux and Windows, enter:
nmConnect('login','password','hostname','port','<domainName>')
For example:
nmConnect('weblogic','welcome1','localhost','5556','myDomain')
You can use Fusion Middleware Control or WebLogic Scripting Tool for the following tasks:
If you plan to use WLST, you should familiarize yourself with that tool. You should also be aware of the following:
The online WLST commands described in this section and used in WebLogic Server Domains will only work if you run them from the WLST implementation on ORACLE_HOME/ohs/common/bin/wlst.sh (wlst.cmd on Windows).
If you run a standalone version of Oracle HTTP Server, you must use the offline, or "agent", WLST commands, which are also available in ORACLE_HOME/ohs/common/bin/wlst.sh (wlst.cmd on Windows). These commands are described in their appropriate context.
For more information, see "Getting Started Using the Oracle WebLogic Scripting Tool (WLST)" in the Oracle® Fusion Middleware Administrator's Guide.
When Oracle HTTP Server starts, it writes the process ID (PID) of the parent httpd
process to the httpd.pid file located in the following directory:
DOMAIN_HOME/servers/<componentName>/logs
The process ID can be used by the administrator when restarting and terminating the daemon. If a process stops abnormally, it is necessary to stop the httpd
child processes using the kill
command. You must not change the default PID file name or its location.
The PidFile
directive in httpd.conf specifies the location of the PID file; however, you should never modify the value of this directive.
Note:
On UNIX/Linux platforms, if you edit the PidFile directive, you also have to edit the ORACLE_HOME/ohs/bin/apachectl file to specify the new location of the PID file.See Also:
PidFile directive in the Apache HTTP Server documentation at:http://httpd.apache.org/docs/current/mod/mpm_common.html#pidfile
This section describes how to start Oracle HTTP Server using Fusion Middleware Control and WLST.
To start Oracle HTTP Server using Fusion Middleware Control, navigate to the Oracle HTTP Server home page and do one of the following:
From the Oracle HTTP Server menu:
Select Control.
Select Start Up from the Control menu.
From the Target Navigation tree:
Right-click the Oracle HTTP Server instance you want to start.
Select Control.
Select Start Up from the Control menu.
From the page header, select Start Up.
The instance will start in the state UNKNOWN.
To start all Oracle HTTP Server components in a system component instance by using WLST (this procedure assumes you have created as OHS instance, as described in Section 4.2, "Creating an OHS Instance" and WLST is running), use the start()
command in a WebLogic Server Domain or nmStart() for standalone domain, as shown here:
Notes:
Node Manager must be running for these commands to work. If it is down, you will receive an error message.serverType
is required for standalone domains. If it is not included an error will be thrown referencing an inability to find startWebLogic
.
Domain | Syntax | Example |
---|---|---|
WebLogic |
start('instanceName')or nmStart(serverName='name', serverType='type') |
start('ohs1')or nmStart(serverName='ohs1', serverType='OHS') |
Standalone |
nmStart(serverName='name', serverType='type') |
nmStart(serverName='ohs1', serverType='OHS') |
If you used createOHSInstance()
to create the instance (Section 4.2, "Creating an OHS Instance"), the state initially reported for the instance will be SHUTDOWN.
You can start Oracle HTTP Server directly from a command line—that is, without launching WLST—by entering the following command:
Linux: $DOMAIN_HOME/bin/startComponent.sh
componentName
Windows: %DOMAIN_HOME%\bin\startComponent.cmd
componentName
For example:
$DOMAIN_HOME/bin/startComponent.sh ohs1
This command invokes WLST and tells it to run its start()
command.
After a few seconds, you will be prompted for your Node Manager password. Type that and press Enter.
Successfully started server componentName...
Successfully disconnected from Node Manager...
Exiting WebLogic Scripting Tool.
You can avoid having to enter your Node Manager password every time you launch the server with startComponent.sh
/.cmd
by starting it with the storeUserConfig
option for the first time. Do the following:
At the prompt, enter the following command:
$DOMAIN_HOME/bin/startComponent.sh componentName storeUserConfig
The system will prompt for your Node Manager password.
Type the password and press Enter.
The system responds with this message:
Creating a key file can reduce the security of your system if it is not a secured location after it is created. Do you want to create the key file? y or n.
Type y
to store your Node manager password. When you subsequently use this command, you will not need to enter a password.
WARNING:
When this procedure is completed, any Oracle HTTP Server processes running from this Oracle Home as a user in the same group will be able to bind to privileged ports.
On a UNIX system, TCP ports in a reserved range (typically less than 1024) can only be bound by processes with root privilege. Oracle HTTP Server always runs as a non-root user; that is, the user who installed Oracle Fusion Middleware. On UNIX, special configuration is required to allow Oracle HTTP Server to bind to privileged ports.
To enable Oracle HTTP Server to listen on a port in the reserved range (for example, the default port 80 or port 443) as a process without root privilege, use the following one-time setup on each Oracle HTTP Server machine:
As the same user who will start Oracle HTTP Server, create a temporary cap.ora file by entering the following:
echo `id -ng`: bind > /tmp/cap.ora
Note:
The next steps must be performed as the root user. If you do not have root access, have the system administrator perform these steps.Update the ORACLE_HOME/oracle_common/bin/hasbind file by performing the following steps:
Change ownership of the file to root:
chown root $ORACLE_HOME/oracle_common/bin/hasbind
Change the permissions on the file as follows:
chmod 4755 $ORACLE_HOME/oracle_common/bin/hasbind
Generate the /etc/cap.ora file by performing the following steps:
If /etc/cap.ora does not exist, copy the temporary cap.ora file you created in step 1 to the /etc/ directory:
cp /tmp/cap.ora /etc/cap.ora
If /etc/cap.ora does exist, append the contents of the temporary file you created in step 1 to the existing /etc/cap.ora file:
cat /tmp/cap.ora >> /etc/cap.ora
Change the permissions on the /etc/cap.ora file as follows:
chmod 644 /etc/cap.ora
Change ownership of the file to root:
chown root /etc/cap.ora
The steps that require root permissions are now complete.
If you prefer, remove the temporary cap.ora you created in step 1:
rm /tmp/cap.ora
Modify the port settings for Oracle HTTP Server as described in Section 6.4, "Managing Ports".
Start (or restart) the instance by using any of the start-up methods described in Section 4.3.2, "Starting Oracle HTTP Server Instances".
This section describes how to stop Oracle HTTP Server using Fusion Middleware Control. Be aware that other services might be impacted when Oracle HTTP Server is stopped.
To stop Oracle HTTP Server using Fusion Middleware Control, navigate to the Oracle HTTP Server home page and do one of the following:
From the Oracle HTTP Server menu:
Select Control.
Select Shut Down from the Control menu.
From the Target Navigation tree:
Right-click the Oracle HTTP Server component you want to stop.
Select Control.
Select Shut Down from the Control menu.
From the page header, select Shut Down.
To stop Oracle HTTP Server by using WLST, from within the scripting tool, use one of the following commands:
Notes:
Node Manager must be running for these commands to work. If it is down, you will receive an error message.serverType
is required for standalone domains. If it is not included an error will be thrown referencing an inability to find startWebLogic
Domain | Syntax | Example |
---|---|---|
WebLogic |
shutdown('serverName')
|
shutdown('ohs1') |
Standalone |
nmKill(serverName='serverName', serverType='type') |
nmKill(serverName='ohs1', serverType='OHS') |
WARNING:
If you run shutdown() without specifying any parameters, WLS will terminate and boot you out of WLST. Oracle HTTP Server will continue running.
You can stop Oracle HTTP Server directly from a command line—that is, without launching WLST—by entering the following command:
$DOMAIN_HOME/bin/stopComponent.sh componentName
For example:
$DOMAIN_HOME/bin/stopComponent.sh ohs1
This command invokes WLST and tells it to run its shutdown()
command.
After a few seconds, you will be prompted for your Node Manager password. Type that and press Enter. Once the server is stopped, the system will respond:
Successfully killed server componentName...
Successfully disconnected from Node Manager...
Exiting WebLogic Scripting Tool.
Restarting Oracle HTTP Server causes the Apache parent process to advise its child processes to exit after their current request (or to exit immediately if they are not serving any requests). Upon restarting, the parent process re-reads its configuration files and reopens its log files. As each child process exits, the parent replaces it with a child process from the new generation of the configuration file, which begins serving new requests immediately.
The following sections describe how to restart Oracle HTTP Server using by Fusion Middleware Control and the WLST.
To restart OHS using Fusion Middleware Control, navigate to the Oracle HTTP Server home page and do one of the following:
From the Oracle HTTP Server menu:
Select Control.
Select Restart from the Control menu.
From the Target Navigation tree:
Right-click the OHS instance you want to stop.
Select Control.
Select Restart from the Control menu.
To restart OHS by using WLST, use the softRestart()
command. From within the scripting tool, enter one of the following commands:
Notes:
Node Manager must be running for these commands to work. If it is down, you will receive an error message.All parameters are required for standalone domains. If they are not included, an error will be thrown referencing an inability to find startWebLogic
.
Domain | Syntax | Example |
---|---|---|
WebLogic |
softRestart('serverName')
|
softRestart('ohs1') |
Standalone |
nmSoftRestart(serverName='name', serverType='type') |
nmSoftRestart(serverName='ohs1', serverType='OHS') |
This section describes how to check the status of a running Oracle HTTP Server instance. You can check this information from either Fusion Middleware Control or by using WLST.
An up or down arrow in the top left corner of any Oracle HTTP Server page's header indicates whether the selected server instance is running. This image shows the up arrow, indicating that the server instance, in this case, "ohs2", is running:
This image shows a down arrow, indicating that the server instance, in this case, "ohs2", is not running:
In a WebLogic Server Domain, if you used createOHSInstance()
to create the Oracle HTTP Server instance, its initial state (that is, before starting it) will be SHUTDOWN.
If you used the Configuration Wizard to generate the instance (both WebLogic Server Domain and standalone domain), its initial state (that is, before starting) will be UNKNOWN.
To check the status of a running Oracle HTTP Server instance by using WLST, from within the scripting tool, enter the following:
Notes:
Node Manager must be running for these commands to work. If it is down, you will receive an error message. If Node Manager goes down in a WebLogic Server Domain, the state will be returned as UNKNOWN, regardless of the real state of the instance. Additionallystate()
does not inform you that it cannot connect to Node Manager.
Unlike other WLST commands, state()
will not tell you when Node Manager is down so there is no way to distinguish an instance that truly is in state UNKNOWN as opposed to Node Manager simply being down.
All parameters are required for standalone domains. If they not included an error will be thrown referencing an inability to find startWebLogic
.
Domain | Syntax | Example |
---|---|---|
WebLogic |
state('serverName')
|
state('ohs1') |
Standalone |
nmServerStatus(serverName='name', serverType='type') |
nmServerStatus(serverName='ohs1', serverType='OHS') |
Note:
This command does not distinguish between non-existent components and real components in state UNKNOWN. Thus, if you enter a non-existent instance (for example, if you mis-identify the instance with a non-existent instance name—for example,ohsz
instead of ohs2
)— UNKNOWN will be returned.You can delete an Oracle HTTP Server instance in both a WebLogic Server Domain and a standalone domain.
In a WebLogic Server Domain, you can use either the custom WLST command deleteOHSInstance()
or from Fusion Middleware Control. These procedures are described in the following sections.
If you are in a WebLogic Server Domain, you can delete an Oracle HTTP Server instance by using the customer WLST command deleteOHSInstance()
. When you use this command, the following happens:
The selected instance information is removed form config.xml.
All OHS configuration directories and their contents are deleted; for example, OHS/instanceName and OHS/instances/instanceName).
All logfiles associated with the deleted instance are deleted.
All state information for the deleted instance is removed.
Note:
You cannot delete an instance by using deleteOHSInstance() if Node Manager is down.To delete an instance by using WLST:
Connect to WLST, as described in Section 4.3.2.2, "Starting Oracle HTTP Server Instances by Using WLST".
At the command prompt, enter:
deleteOHSInstance(instanceName='instanceName')
For example, to delete an OHS instance named ohs1
use the following command:
deleteOHSInstance(instanceName='ohs1')
You cannot delete any OHS instance in either an UNKNOWN or a RUNNING state.
To delete an Oracle HTTP Server instance by using Fusion Middleware Control:
Note:
You cannot delete a running Oracle HTTP Server instance. If the instance is running, stop it, as described in Section 4.3.3, "Stopping Oracle HTTP Server Instances" and then proceed with the following steps.Log in to Fusion Middleware Control and navigate to the system component instance home page for the WebLogic Server Domain within which you want to delete the Oracle HTTP Server instance.
Open the WebLogic Server Domain menu and select Administration then Create/Delete OHS.
The OHS Instances page appears.
Select the instance you want to delete and click Delete.
A confirmation window appears.
Click Yes to complete the deletion.
The OHS Instances page appears, with an information method indicating that the selected Oracle HTTP Server instance was deleted.
You can delete an Oracle HTTP Server instance in a standalone domain by using the Configuration Wizard so long as it is not the only instance in the domain. The Configuration Wizard always requires at least one Oracle HTTP Server instance in a standalone domain so you will not be able to delete one if it's the only instance in the domain. If you want to delete the only instance in a standalone domain, you should instead completely remove the entire domain directory.
Deleting Oracle HTTP Server instances by using the Configuration Wizard is actually only a partial deletion (and is inconsistent with the way deletion is done on the WebLogic Server domain side by using deleteOHSInstance()
; see Section 4.3.6.1.1, "Deleting an Instance by Using WLST"). When you delete a standalone instance by using the Configuration Wizard, the following occurs:
Information on the specific instance is removed from config.xml, so this instance is no longer recognized as valid. When you launch the Configuration Wizard again for another update, the deleted instance will not appear.
The logs compiled for the deleted instance are left intact at: DOMAIN_HOME/servers/ohs1... If a new instance with the same name is subsequently created, it will inherit and continue logging to these files.
The deleted instance's configuration directories and their contents are not deleted; they remain intact at: DOMAIN_HOME/config/fmwconfig/components/OHS/instanceName and DOMAIN_HOME/config/fmwconfig/components/OHS/instances/instanceName. The only change in both directories is that the following files are renamed: httpd.conf becomes httpd.conf.bak; ssl.conf becomes ssl.conf.bak; and admin.conf becomes admin.conf.bak. This prevents the instance from being started. (If you create a new instance with the same name as the instance you deleted, this information will be overwritten, but the *.bak files will remain).
The deleted instance's state information is left intact at DOMAIN_HOME/system_components/... If a new instance of the same name is subsequently created, it will inherit the state of the old instance. Instead of starting in UNKNOWN, it could be SHUTDOWN or even FAILED_NOT_RESTARTABLE out of the gate.
To delete an Oracle HTTP Server instance in a standalone domain, do the following:
Shutdown all running instances (see Section 4.3.3, "Stopping Oracle HTTP Server Instances"). Be aware the Configuration Wizard will not check the state of the Oracle HTTP Server instance so you will need to verify that all instances are indeed stopped.
If it is running, shut down Node Manager.
Launch the Configuration Wizard (see Installing and Configuring Oracle HTTP Server) and do the following:
Select Update an existing domain and select the path to the domain.
Skip both the Templates screen and the JDK Selection screen by clicking Next on each.
On the System Components screen, select the instance you want to delete and click Delete.
The selected instance is deleted.
Click Next and, on the OHS Server screen, click Next again.
On the Configuration Summary screen, verify that the selected instance has been deleted and click Update.
On the Success screen, click Finish.
You can remotely manage an Oracle HTTP Server running in a standalone environment from a collocated Oracle HTTP Server implementation running on a separate machine. This feature enables you to use the WebLogic Scripting Tool (WLST) or Fusion Middleware Control from the remote machine to start, restart, stop, and configure the component. This chapter describes how to set up the environments to
The following instructions describe how to set up a remote environment, which will enable you to run Oracle HTTP Server installed on one machine from an installation on another. This section contains the following information:
To remotely manage Oracle HTTP Server, you need to have separate hosts installed on separate machines:
A collocated installation (for this document, this installation will be called host1).
A standalone installation (host2). The path to standalone MW_HOME on host2 must be the same as the path to collocated MW_HOME on host1; for example:
/scratch/user/work
The following steps describe how to set up an expanded domain and link it to a database on the collocated version of Oracle HTTP Server (host1).
Using the Repository Configuration Utility (RCU), set up and install a database for the expanded domain. For more information, see Oracle Fusion Middleware Creating Schemas with the Repository Creation Utility.
Launch the Configuration Wizard and create an expanded domain. Use the values specified in Table 4-1.
Table 4-1 Setting Up an Expanded Domain
For... | Select or Enter... |
---|---|
Create Domain |
Create a new domain and specify its path (for example, MW_HOME/user_projects/domains/ohs1_domain) |
Templates |
Oracle HTTP Server (Collocated) |
Application Locations |
The default |
Administrator Account |
A username and password (for example, weblogic and welcome1) |
Database Configuration Type |
The RCU data. Then, click Get RCU Configuration and then Next. |
Optional Configuration |
The following items:
|
Administration Server |
The listen address (All Local Addresses or the valid name or address for host1) and port |
Node Manager |
Per Domain and specify the NodeManager credentials (for example, |
System Components |
Add and set the fields, using OHS as the Component Type (for example, use a System Component value of ohs1). |
OHS Server |
The listen addresses and ports or use the defaults. |
Machines |
Add. This will add a machine to the domain (for example, ohs1_Machine) and the Node Manager listen and port values. You must specify a listen address for host2 that is accessible from host1, such the valid name or address for host2 (do not use localhost or All Local Addresses). |
Assign System Components |
The OHS component (for example, |
Configuration Summary |
Create (note that the OPSS steps may take some minutes). |
On host1, use the following command to pack the domain:
<MW_HOME>/ohs/common/bin/pack.sh -domain=path to domain -template=path to template -template_name=name -managed=true
For example:
<MW_HOME>/ohs/common/bin/pack.sh -domain=<MW_HOME>/user_projects/domains/ohs1_domain -template=/tmp/ohs1_tmplt.jar -template_name=ohs1 -managed=true
Use the following steps to unpack the domain you packed on host1, above, on host2:
Copy the template file created in "Task 2: Pack the Domain on host1" from host1 to host2.
Use the following command to unpack the domain:
<MW_HOME>/ohs/common/bin/unpack.sh -domain=path to domain -template=path to template
For example:
<MW_HOME>/ohs/common/bin/unpack.sh -domain=<MW_HOME>/user_projects/domains/ohs1_domain -template=/tmp/ohs1_tmplt.jar
Once you have unpacked the domain created on host1 onto host2, you can use the same set of WLST commands and Fusion Middleware Control tools you would in a collocated environment to start, stop, restart, and configure the component.
To run an Oracle HTTP Server remotely, do the following:
Start the WebLogic Administration Server on host1:
<MW_HOME>/user_projects/domains/ohs1_domain/bin/startWebLogic.sh &
Start Node Manager on host2:
<MW_HOME>/user_projects/domains/ohs1_domain/bin/startNodeManager.sh &
You can now run the Oracle HTTP Server instance on host2 from the collocated implementation on host1. You can use any of the WLST commands or any of the Fusion Middleware Control tools. For example, to connect host2 to Node Manager and start the server ohs1, from host1 enter:
<MW_HOME>/ohs/common/bin/wlst.sh nmConnect('weblogic', 'welcome1', '<nm-host>', '<nm-port>', 'ohs1_domain') nmStart(serverName='ohs1', serverType='OHS')
See Section 4.3, "Performing Basic OHS Tasks" for information on starting, stopping, restarting, and configuring Oracle HTTP Server components.
Server properties for Oracle HTTP Server can be set using Fusion Middleware Control or direct editing of the Oracle HTTP Server configuration files. You cannot use WLST commands to specify the server properties.
To specify the server properties using the Fusion Middleware Control:
Select Administration from the Oracle HTTP Server menu.
Select Server Configuration from the Administration menu. The Server Configuration page appears.
Enter the documentation root directory in the Document Root field that forms the main document tree visible from the website.
Enter the e-mail address in the Administrator's E-mail field that the server will includes in error messages sent to the client.
Enter the directory index in the Directory Index field. The is the main (index) page that will be displayed when a client first accesses the website.
Optional: Enter the user name in the Operating System User field.
This field is normally blank. It may be set to the user that installed Oracle HTTP Server and starts Node Manager.
Optional: Enter the group name in the Operating System Group field.
This field is normally blank. It may be set to the group of the user that installed Oracle HTTP Server and starts Node Manager.
The Modules region is used to enable or disable modules. There are three modules that you can enable or disable: mod_perl, mod_fcgi, and mod_plsql.
For instructions on configuring the mod_perl module, see "Configuring mod_perl".
Create an alias, if necessary in the Aliases table. An alias maps to a specified directory. For example, to use a specific set of content pages for a group you can create an alias to the directory that has the content pages.
Review the settings. If the settings are correct, click Apply to apply the changes. If the settings are incorrect, or you decide to not apply the changes, click Revert to return to the original settings.
Restart Oracle HTTP Server as described in Section 4.3.4.
The server properties are saved, and shown on the Server Configuration page.
To specify the server properties using the httpd.conf file:
Note:
Before attempting to edit any .conf file, you should familiarize yourself with the layout of the configuration file directories, mechanisms for editing the files, and learn more about the files themselves. For this information, see Section 1.6, "Understanding Configuration Files".Open the httpd.conf file using either a text editor or the Advanced Server Configuration page in Fusion Middleware Control. (See Section 4.6.6, "Modifying an Oracle HTTP Server Configuration File.")
In the DocumentRoot section of the file, enter the directory that stores the main content for the website. The following is an example of the syntax:
DocumentRoot "${ORACLE_INSTANCE}/config/fmwconfig/components/${COMPONENT_TYPE}/instances/${COMPONENT_NAME}/htdocs"
In the ServerAdmin section of the file, enter the administrator's email address. This is the e-mail address that will appear on client pages. The following is an example of the syntax:
ServerAdmin WebMaster@example.com
In the DirectoryIndex section of the file, enter the directory index. This is the main (index) page that will be displayed when a client first accesses the website. The following is an example of the syntax:
DirectoryIndex index.html index.html.var
Create aliases, if needed. An alias maps to a specified directory. For example, to use a specific set of icons, you can create an alias to the directory that has the icons for the Web pages. The following is an example of the syntax:
Alias /icons/ "${PRODUCT_HOME}/icons/" <Directory "${PRODUCT_HOME}/icons"> AllowOverride None Order allow,deny Allow from all </Directory>
Save the file.
Restart Oracle HTTP Server as described in Section 4.3.4.
This section includes the following sections:
Section 4.6.5, "Configuring the Oracle WebLogic Server Proxy Plug-In (mod_wl_ohs)"
Section 4.6.6, "Modifying an Oracle HTTP Server Configuration File"
Section 4.6.8, "Using the apxs Command to Install Extension Modules"
Note:
Fusion Middleware Control and other Oracle software which manage the Oracle HTTP Server configuration might save configuration files in a different, equivalent format. After using the software to make a configuration change, multiple configuration files might be rewritten.Secure Sockets Layer (SSL) is an encrypted communication protocol that is designed to securely send messages across the Internet. It resides between Oracle HTTP Server on the application layer and the TCP/IP layer, transparently handling encryption and decryption when a secure connection is made by a client.
One common use of SSL is to secure Web HTTP communication between a browser and a Web server. This case does not preclude the use of non-secured HTTP. The secure version is simply HTTP over SSL (HTTPS). The differences are that HTTPS uses the URL scheme https
:// rather than http://
. The default communication port is 4443 in Oracle HTTP Server. Oracle HTTP Server does not use the 443 standard https://
privileged port because of security implications. For information about running Oracle HTTP Server on privileged ports see Section 4.3.2.4, "Starting Oracle HTTP Server Instances on a Privileged Port (UNIX Only)."
By default, an SSL listen port is configured and enabled using a default wallet during installation. Wallets store your credentials, such as certificate requests, certificates, and private keys.
The default wallet that is automatically installed with Oracle HTTP Server is for testing purposes only. A real wallet must be created for your production server. The default wallet is located in the DOMAIN_HOME/config/fmwconfig/components/OHS/instances/componentName/keystores/default directory. You can either place the new wallet in this location, or change the SSLWallet
directive in DOMAIN_HOME/config/fmwconfig/components/OHS/instances/componentName/ssl.conf to point to the location of your real wallet.
For the changes to take effect, you should restart the Oracle HTTP Server components as described in Section 4.3.4.
For information about configuring wallets and SSL using Fusion Middleware Control, see "Enabling SSL for Oracle HTTP Server Virtual Hosts" in the Administering Oracle Fusion Middleware.
The following sections contain information about how to enable and configure SSL for Oracle HTTP Server in standalone mode. These instructions make use of the mod_ossl plug-in to Oracle HTTP Server which enables the server to use SSL.
Section 4.6.2.2, "Specify SSLVerifyClient on the Server Side"
Section 4.6.2.3, "Enable SSL Between Oracle HTTP Server and Oracle WebLogic Server"
By default, SSL is enabled when you install Oracle HTTP Server. Perform these tasks to modify and configure SSL:
To configure Oracle HTTP Server for SSL, you need a wallet that contains the certificate for the server. Wallets store your credentials, such as certificate requests, certificates, and private keys.
The default wallet that is automatically installed with Oracle HTTP Server is for testing purposes only. A real wallet must be created for your production server. The default wallet is located in $ORACLE_INSTANCE
/config/fmwconfig/components/
$COMPONENT_TYPE
/instances/
$COMPONENT_NAME
/keystores/default
. You can either place the new wallet in that location, or change the SSLWallet
directive in $ORACLE_INSTANCE
/config/fmwconfig/components/
$COMPONENT_TYPE
/instances/
$COMPONENT_NAME
/ssl.conf
(the pre-install location) to point to the location of your real wallet.
See Also:
"orapki" in Administering Oracle Fusion Middleware for instructions on creating a wallet. It is important that you do the following:Generate a certificate request: For the Common Name, specify the name or alias of the site you are configuring. Make sure that you enable this auto_login_only feature.
Optionally, you can further customize your configuration using mod_ossl directives.
See Also:
Section G.2, "mod_ossl" for a list and descriptions of directives accepted by mod_ossl.Note:
The files installed during configuration contain all of the necessary SSL configuration directives and a default setup for SSL.Your SSL configuration must contain, at minimum, the following directives:
LoadModule ossl_module "${PRODUCT_HOME}/modules/mod_ossl.so" Listen 4443 ServerName www.testohs.com SSLEngine on # SSL Protocol Support: # List the supported protocols. SSLProtocol nzos_Version_1_2 nzos_Version_1_1 nzos_Version_1_0 # SSL Cipher Suite: # List the ciphers that the client is permitted to negotiate. SSLCipherSuite SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_RSA_WITH_DES_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA SSLWallet "${ORACLE_INSTANCE}/config/fmwconfig/components/${COMPONENT_TYPE}/instances/${COMPONENT_NAME}/keystores/default" </VirtualHost>To enable client authentication, do the following:
Use the appropriate client certificate on your client side for the HTTPS connection. See your client documentation for information on getting and using a client certificate. Be sure that your client certificate is trusted by the server wallet.
Section 4.6.2.2.1, "Forcing Clients to Authenticate Using Certificates"
Section 4.6.2.2.2, "Forcing a Client to Authenticate for a Particular URL"
Section 4.6.2.2.3, "Authorizing a Client for a Particular URL"
See Also:
"Importing a Certificate or a Trusted Certificate Using WLST" in Administering Oracle Fusion Middleware Guide for instructions on how to import a trusted certificate into your wallet.You can force the client to validate its client certificate and allow access to the server using the following method. This scenario is valid for all clients having a client certificate supplied by the server Certificate Authority (CA). The server can validate client's supplied certificates against its CA for additional permission.
# require a client certificate which has to be directly # signed by our CA certificate SSLVerifyClient require SSLWallet "${ORACLE_INSTANCE}/config/fmwconfig/components/${COMPONENT_TYPE}/instances/${COMPONENT_NAME}/keystores/default"
To force a client to authenticate using certificates for a particular URL, you can use the per-directory reconfiguration features of mod_ossl:
SSLVerifyClient none SSLWallet "${ORACLE_INSTANCE}/config/fmwconfig/components/${COMPONENT_TYPE}/instances/${COMPONENT_NAME}/keystores/default" <Location /secure/area> SSLVerifyClient require </Location>
To do this, check that part of the client certificate matches what you expect. Usually, this means checking all or part of the Distinguished Name (DN), to see if it contains some known string. There are two ways to do this, using either mod_auth_basic or SSLRequire.
The mod_auth_basic method is generally required when the certificates are completely arbitrary, or when their DNs have no common fields (usually the organization, and so on). In this case, you should establish a password database containing all of the clients allowed, for example:
SSLVerifyClient none <Directory /access/required> SSLVerifyClient require SSLOptions +FakeBasicAuth SSLRequireSSL AuthName "Oracle Auth" AuthType Basic AuthBasicProvider file AuthUserFile httpd.passwd Require valid-user </Directory>
The password used in this example is the DES encrypted string password
. For more information on the directive, see Section G.2.10, "SSLOptions" which describes the SSLOptions directive of the mod_ossl module.
httpd.passwd Subject: OU=Class 3 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US Subject: CN=GTE CyberTrust Global Root,OU=GTE CyberTrust Solutions\, Inc.,O=GTE Corporation,C=US Subject: CN=localhost,OU=FOR TESTING ONLY,O=FOR TESTING ONLY Subject: OU=Class 2 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US Subject: OU=Class 1 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US
When your clients are all part of a common hierarchy, which is encoded into the DN, you can match them more easily using SSLRequire, for example:
SSLVerifyClient none SSLWallet "${ORACLE_INSTANCE}/config/fmwconfig/components/${COMPONENT_TYPE}/instances/${COMPONENT_NAME}/keystores/default" <Directory /access/required> SSLVerifyClient require SSLOptions +FakeBasicAuth SSLRequireSSL SSLRequire %{SSL_CLIENT_S_DN_O} eq "VeriSign\, Inc." \ and %{SSL_CLIENT_S_DN_OU} in {"Class", "Public", "Primary"} </Directory>
The following examples presume that clients on the Intranet have IPs in the range 192.168.1.0/24, and that the part of the Intranet website you want to allow Internet access to is /access/required. This configuration should remain outside of your HTTPS virtual host, so that it applies to both HTTPS and HTTP.
SSLWallet "$ORACLE_INSTANCE/config/fmwconfig/components/$COMPONENT_TYPE/instances/$COMPONENT_NAME/keystores/default" <Directory /access/required> # Outside the subarea only Intranet access is granted Require ip 192.168.1.0/24 </Directory> <Directory /access/required> # Inside the subarea any Intranet access is allowed # but from the Internet only HTTPS + Strong-Cipher + Password # or the alternative HTTPS + Strong-Cipher + Client-Certificate # If HTTPS is used, make sure a strong cipher is used. # Additionally allow client certs as alternative to basic auth. SSLVerifyClient optional SSLOptions +FakeBasicAuth +StrictRequire SSLRequire %{SSL_CIPHER_USEKEYSIZE}>= 128 # Force clients from the Internet to use HTTPS RewriteEngine on RewriteCond %{REMOTE_ADDR} !^192\.168\.1\.[0-9]+$ RewriteCond %{HTTPS} !=on RewriteRule . - [F] # Allow Network Access and/or Basic Auth Satisfy any # Network Access Control Require ip 192.168.1.0/24 # HTTP Basic Authentication AuthType basic AuthName "Protected Intranet Area" AuthBasicProvider file AuthUserFile htpasswd Require valid-user </Directory>
Use the Oracle WebLogic Server Proxy Plug-In to enable SSL between Oracle HTTP Server and Oracle WebLogic Server. The plug-ins allow you to configure SSL libraries and configure one-way and two- way SSL communications. For more information, see "Use SSL with Plug-Ins" and "Parameters for Oracle WebLogic Server Proxy Plug-Ins" in Using Oracle WebLogic Server Proxy Plug-Ins 12.1.2.
Multipurpose Internet Mail Extension (MIME) settings are used by Oracle HTTP Server to interpret file types, encodings, and languages. MIME settings for Oracle HTTP Server can only be set using Fusion Middleware Control. You cannot use WLST commands to specify the MIME settings.
The following tasks can be completed on the MIME Configuration page:
MIME type maps a given file extension to a specified content type. The MIME type is used for filenames containing an extension.
To configure a MIME type using Fusion Middleware Control, do the following:
Select Administration from the Oracle HTTP Server menu.
Select MIME Configuration from the Administration menu. The MIME configuration page appears.
Click Add Row in MIME Configuration region. A new, blank row is added to the list.
Enter the MIME type.
Enter the file extension.
Review the settings. If the settings are correct, click Apply to apply the changes. If the settings are incorrect, or you decide to not apply the changes, click Revert to return to the original settings.
Restart Oracle HTTP Server, as described in Section 4.3.4.
The MIME configuration is saved, and shown on the MIME Configuration page.
MIME encoding enables Oracle HTTP Server to determine the file type based on the file extension. You can add and remove MIME encodings. The encoding directive maps the file extension to a specified encoding type.
Select Administration from the Oracle HTTP Server menu.
Select MIME Configuration from the Administration menu. The MIME configuration page appears.
Expand the MIME Encoding region by clicking the plus sign (+) next to MIME Encoding.
Click Add Row in MIME Encoding region. A new, blank row is added to the list.
Enter the MIME encoding, such as x-gzip
.
Enter the file extension, such as .gx.
Review the settings. If the settings are correct, click Apply to apply the changes. If the settings are incorrect, or you decide to not apply the changes, click Revert to return to the original settings.
Restart Oracle HTTP Server as described in Section 4.3.4.
The MIME language setting maps file extensions to a particular language. This directive is commonly used for content negotiation, in which Oracle HTTP Server returns the document that most closely matched the preferences set by the client.
Select Administration from the Oracle HTTP Server menu.
Select MIME Configuration from the Administration menu. The MIME configuration page appears.
Expand the MIME Languages region by clicking the plus sign (+) next to MIME Languages.
Click Add Row in MIME Languages region. A new, blank row is added to the list.
Enter the MIME language, such as en-US.
Enter the file extension, such as en-us.
Review the settings. If the settings are correct, click Apply to apply the changes. If the settings are incorrect, or you decide to not apply the changes, click Revert to return to the original settings.
Restart Oracle HTTP Server as described in Section 4.3.4.
The mod_perl module embeds the Perl interpreter into Oracle HTTP Server. This eliminates start-up overhead and enables you to write modules in Perl. The module is disabled, by default.
To enable the mod_perl module using Fusion Middleware Control, do the following:
Select Administration from the Oracle HTTP Server menu.
Select mod_perl Configuration from the Administration menu. The mod_perl configuration page appears.
Note:
If mod_perl has not been enabled, then you will be redirected to the Server Configuration page. Select mod_perl and click Apply to enable mod_perl. After the confirmation page has been displayed, restart Oracle HTTP Server, and then return to the mod_perl Configuration page.Enter the switch information in the Switches field.
Enter the environment variables to be passed to the scripts in the Environment field.
Enter the required script names in the Require field.
Click Add Row to create a new row.
Configure mod_perl directives for a Location in the Perl Locations table. The Location assigns many rules that the server should follow when the request's URI matches the Location.
Enter the base URI for the Perl scripts in the Locations field. Just as it is the widely accepted convention to use /cgi-bin for your mod_cgi scripts, it is also conventional to use /perl as the base URI of the Perl scripts that run under mod_perl.
Enter options in the Options field. The PerlOptions
directive provides fine-grained configuration by providing control over which class of Perl interpreter pool to be used. Options are enabled by prepending them with a plus sign (+) and are disabled by prepending them with a minus sign (-).
If you want to send headers, then click the Send Header check box. The PerlSendHeader
directive is for mod_perl 1.0 backwards-compatibility. When enabled, the server sends an HTTP header to the browser on every script invocation. You should disable this option for NPH (non-parsed-headers) scripts.
Enter the environment in the Environment field. The PerlSetEnv
directive enables you to specify system environment variables and pass them into your mod_perl handlers.
Enter the response handler in the Response Handler field. The PerlResponseHandler
directive tells mod_perl which callback is going to do the job.
Enter the authentication handler in the Authentication Handler field. The PerlAuthenHandler directive is used to set the handler to verify a user's identification credentials.
Review the settings. If the settings are correct, click Apply to apply the changes. If the settings are incorrect, or you decide to not apply the changes, click Revert to return to the original settings.
Restart Oracle HTTP Server as described in Section 4.3.4.
The mod_perl module configuration is saved and shown on the mod_perl Configuration page.
Note:
If you are manually editing the mod_perl configuration instead of using Fusion Middleware Control, then all directives must be defined within the<IfModule mod_perl.c>
block of the mod_perl.conf file. Any mod_perl related directives defined outside of this block might be ignored.You can configure the Oracle WebLogic Server Proxy Plug-In (mod_wl_ohs) either by using Fusion Middleware Control or by editing the mod_wl_ohs.conf configuration file manually.
For information about the prerequisites and procedure for configuring the Oracle WebLogic Server Proxy Plug-In to proxy requests from Oracle HTTP Server to Oracle WebLogic Server, see "Configuring the Plug-In for Oracle HTTP Server" in Using Oracle WebLogic Server Proxy Plug-Ins 12.1.2.
Note:
Fusion Middleware Control and other Oracle software that manage the Oracle HTTP Server configuration might save these files in a different, equivalent format. After using the software to make a configuration change, multiple configuration files might be rewritten.To modify an Oracle HTTP Server configuration file by using Fusion Middleware Control, do the following:
Select Administration from the HTTP Server menu.
Select Advanced Configuration from the Administration menu item. The Advanced Server Configuration page appears.
Select the configuration file from the list, such as the httpd.conf
file.
Edit the file, as needed.
Review the settings. If the settings are correct, click Apply to apply the changes. If the settings are incorrect, or you decide to not apply the changes, click Revert to return to the original settings.
Restart Oracle HTTP Server as described in Section 4.3.4.
The file is saved and shown on the Advanced Server Configuration page.
By default, the httpd.conf file allows server access to extra content such as documentation and sample scripts. This access might present a low level security risk.
You might want to tailor this extra content in your own environment to suit your use cases. Follow the instructions in Section 4.6.6, "Modifying an Oracle HTTP Server Configuration File" to access the file.
Examine the contents of the cgi-bin
directory. You can either remove the code from the httpd.conf file that you do not need, or change the following Directory directive to point to your own CGI script directory.
... # # "${ORACLE_INSTANCE}/config/fmwconfig/components/${COMPONENT_TYPE}/instances/${COMPONENT_NAME}/cgi-bin" should be changed to whatever your ScriptAliased # CGI directory exists, if you have that configured. # <Directory "${ORACLE_INSTANCE}/config/fmwconfig/components/${COMPONENT_TYPE}/instances/${COMPONENT_NAME}/cgi-bin"> AllowOverride None Options None Order allow,deny Allow from all </Directory> ...
Edit the following sections pertaining to fancy indexing in the httpd.conf file for your use cases.
... # # IndexOptions: Controls the appearance of server-generated directory # listings. # IndexOptions FancyIndexing HTMLTable VersionSort # We include the /icons/ alias for FancyIndexed directory listings. If # you do not use FancyIndexing, you may comment this out. # Alias /icons/ "${PRODUCT_HOME}/icons/" <Directory "${PRODUCT_HOME}/icons"> AllowOverride None Order allow,deny Allow from all </Directory> # # AddIcon* directives tell the server which icon to show for different # files or filename extensions. These are only displayed for # FancyIndexed directories. # AddIconByEncoding (CMP,/icons/compressed.gif) x-compress x-gzip AddIconByType (TXT,/icons/text.gif) text/* AddIconByType (IMG,/icons/image2.gif) image/* AddIconByType (SND,/icons/sound2.gif) audio/* AddIconByType (VID,/icons/movie.gif) video/* AddIcon /icons/binary.gif .bin .exe AddIcon /icons/binhex.gif .hqx AddIcon /icons/tar.gif .tar AddIcon /icons/world2.gif .wrl .wrl.gz .vrml .vrm .iv AddIcon /icons/compressed.gif .Z .z .tgz .gz .zip AddIcon /icons/a.gif .ps .ai .eps AddIcon /icons/layout.gif .html .shtml .htm .pdf AddIcon /icons/text.gif .txt AddIcon /icons/c.gif .c AddIcon /icons/p.gif .pl .py AddIcon /icons/f.gif .for AddIcon /icons/dvi.gif .dvi AddIcon /icons/uuencoded.gif .uu AddIcon /icons/script.gif .conf .sh .shar .csh .ksh .tcl AddIcon /icons/tex.gif .tex AddIcon /icons/bomb.gif core AddIcon /icons/back.gif .. AddIcon /icons/hand.right.gif README AddIcon /icons/folder.gif ^^DIRECTORY^^ AddIcon /icons/blank.gif ^^BLANKICON^^ # # DefaultIcon is which icon to show for files which do not have an icon # explicitly set. # DefaultIcon /icons/unknown.gif # # AddDescription allows you to place a short description after a file in # server-generated indexes. These are only displayed for FancyIndexed # directories. # Format: AddDescription "description" filename # #AddDescription "GZIP compressed document" .gz #AddDescription "tar archive" .tar #AddDescription "GZIP compressed tar archive" .tgz ... # # ReadmeName is the name of the README file the server will look for by # default, and append to directory listings. # # HeaderName is the name of a file which should be prepended to # directory indexes. ReadmeName README.html HeaderName HEADER.html # # IndexIgnore is a set of filenames which directory indexing should ignore # and not include in the listing. Shell-style wildcarding is permitted. # IndexIgnore .??* *~ *# HEADER* README* RCS CVS *,v *,t ...
You can remove the following documentation configuration sections from the httpd.conf file if they are not needed.
... # # This should be changed to the ServerRoot/manual/. The alias provides # the manual, even if you choose to move your DocumentRoot. You may comment # this out if you do not care for the documentation. # AliasMatch ^/manual(?:/(?:de|en|es|fr|ja|ko|pt-br|ru|tr))?(/.*)?$ "${PRODUCT_HOME}/manual$1" <Directory "${PRODUCT_HOME}/manual"> AllowOverride None Order allow,deny Allow from all <Files *.html> SetHandler type-map </Files> # .tr is text/troff in mime.types! <Files *.html.tr.utf8> ForceType text/html </Files> SetEnvIf Request_URI ^/manual/(de|en|es|fr|ja|ko|pt-br|ru|tr)/ prefer-language=$1 RedirectMatch 301 ^/manual(?:/(de|en|es|fr|ja|ko|pt-br|ru|tr)){2,}(/.*)?$ /manual/$1$2 LanguagePriority en de es fr ja ko pt-br ru tr ForceLanguagePriority Prefer Fallback </Directory> ...
Note:
This command is only for UNIX and Linux and should be used only for modules which are supplied in source code form. Follow the installation instructions for modules supplied in binary form.For more information about the apxs command, see the Apache HTTP Server documentation at:
The Apache Extension Tool (apxs) can be used to build and install Apache HTTP Server extension modules for Oracle HTTP Server. apxs installs modules in the ORACLE_HOME/ohs/modules directory for access by any Oracle HTTP Server instances which run from this installation.
Recommended apxs options for use with Oracle HTTP Server are:
Option | Purpose | Example Command |
---|---|---|
-c | Compile module source |
$ORACLE_HOME/ohs/bin/apxs -c mod_example.c |
-i | Install module binary into ORACLE_HOME |
$ORACLE_HOME/ohs/bin/apxs -ci mod_example.c |
When the module binary has been installed into ORACLE_HOME, a LoadModule
directive in httpd.conf or other configuration file is used to load the module into the server processes; for example:
LoadModule example_module "${ORACLE_HOME}/ohs/modules/mod_example.so"
The directive is required in the configurations for all instances which must load the module.
When the -a or -A option is specified, apxs will edit httpd.conf to add a LoadModule directive for the module. Do not use the -a
and -A
options with Oracle HTTP Server instances that are part of a WebLogic Server Domain. Instead, use Fusion Middleware Control to update the configuration, as described in Section 1.6.2, "Editing the Configuration".
You can use the -a or -A option with Oracle HTTP Server instances that are part of a standalone domain if the CONFIG_FILE_PATH environment variable is set to the staging directory for the instance before invoking apxs; for example:
CONFIG_FILE_PATH=$ORACLE_HOME/user_projects/domains/base_domain/config/fmwconfig/components/OHS/ohs1 export CONFIG_FILE_PATH $ORACLE_HOME/ohs/bin/apxs -cia mod_example.c
By default, apxs uses the Perl interpreter in /usr/bin. If apxs cannot locate the product install or encounters other operational errors when using /usr/bin/perl, use the Perl interpreter within the Middleware home by invoking apxs as follows:
$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/ohs/bin/apxs -c mod_example.c
Modules often require directives besides LoadModule
to properly function. After the module has been installed and loaded using the LoadModule directive, refer to the documentation for the module for any additional configuration requirements.
The Options method enables clients to determine which methods are supported by a web server. If enabled, it appears in the Allow
line of HTTP response headers.
For example, if you send a request such as:
---- Request ------- OPTIONS / HTTP/1.0 Content-Length: 0 Accept: */* Accept-Language: en-US User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Win32) Host: host123:80
you might get the following response from the web server:
---- Response --------
HTTP/1.1 200 OK
Date: Wed, 23 Apr 2008 20:20:49 GMT
Server: Oracle-Application-Server-11g/11.1.1.0.0 Oracle-HTTP-Server
Allow: GET,HEAD,POST,OPTIONS
Content-Length: 0
Connection: close
Content-Type: text/html
Some sources consider exposing the Options method a low security risk because malicious clients could use it to determine the methods supported by a web server. However, because web servers support only a limited number of methods, disabling this method will just slow down malicious clients, not stop them. In addition, the Options method may be used by legitimate clients.
If your Oracle Fusion Middleware environment does not have clients that require the Options method, you can disable it by including the following lines in the httpd.conf file:
<IfModule mod_rewrite.c> RewriteEngine on RewriteCond %{REQUEST_METHOD} ^OPTIONS RewriteRule .* – [F] </IfModule>
Functional or performance issues may be encountered when an Oracle HTTP Server component is created on a shared filesystem, including NFS (Network File System). In particular, lock files or UNIX sockets used by Oracle HTTP Server may not work or may have severe performance degradation; WLS requests routed by mod_wl_ohs may have severe performance degradation due to filesystem accesses in the default configuration.
Table 4-1 provides information about the Lock file issues and the suggested changes in the httpd.conf file specific to the operating systems.
Operating System | Description | httpd.conf changes |
---|---|---|
Linux |
Lock files are not required. The Sys V semaphore is the preferred cross-process mutex implementation. |
Change Comment out the |
Solaris |
Lock files are not required. The cross-process pthread mutex is the preferred cross-process mutex implementation. |
Change Comment out the |
Other UNIX platforms |
Change the |
|
UNIX socket issues |
mod_cgid is not enabled by default. If enabled, use the mod_fastcgi is not enabled by default. If enabled, use the |