Configuring OHS and Using
Oracle Application Server Tips by Burleson
The OHS is configured using one main
configuration file called httpd.conf, and a supplemental file called
oracle_apache.conf. The both files are located in the $ORACLE_HOME/Apache/Apache/conf/
subdirectory. Each Oracle9iAS instance installs an OHS server
and has a unique httpd.conf file.
When OHS starts, it reads three files:
httpd.conf, access.conf, and srm.conf. The oracle_apache.conf
file is used to load and configure specific Oracle modules and is an
INCLUDED file at the end of httpd.conf. It is common practice
to place all configuration data in the httpd.conf file and leave the
access.conf and srm.conf files empty. At this point, we will
walk through a sample httpd.conf file and discuss the important
Like the familiar init.ora of Oracle
databases, the httpd.conf file starts with heading data and uses
the?#? character for comments. When the Oracle Universal
Installer creates the httpd.conf file, it sets the parameters
necessary to get the application server up and running. Most
settings are appropriate and should only be changed when specific
situations warrant. Important: read the comments before making
changes. The parameters are grouped into three sections:
global parameters, the default server parameters, and virtual host
parameters. At the very end are the Oracle specific
ServerRoot in the OHS is analogous to the
database ORACLE_HOME. When OHS is looking for configuration or log
files it will use the ServerRoot as the base directory.
When defining a file location, placing
?/? (?X:\? in windows) defines a path/file in httpd.conf and tells
OHS to use only that path/file. If the path/file is defined
without a leading ?/?, then OHS will consider it a relative
path/file and append the ServerRoot to the front. Thus, if the
ServerRoot is set to ?/opt/oracle/mydir? and ErrorLog is set to
?logs/error_log?, OHS will log errors to ?/opt/oracle/mydir/logs/error_log?.
As we saw earlier, OHS prespawns server
processes (or threads in windows) to speed the handling of requests.
The UNIX OS pid of the parent server process is stored in the
PidFile location. To reset log files or kill OHS from the
operating system you need to use the pid located in the PidFile.
Other parts of the application server may also need this information
so it is not recommended to change the file name or location once
The Server Pool Size parameters configure
the number of child server processes created when starting, and
dictate when to add or remove processes. In this case, the OHS
spawns five child server processes on startup and checks
periodically to insure that there are five spare processes waiting
to handle new requests. If the processes are fewer than
specified in MinSpareServer, the parent process will spawn
additional processes. If there are more than specified in
MaxSpareServers, the parent process will kill some of the idle child
processes. This allows OHS to dynamically adjust to changing
load levels. Set StartServers to a number between Max and Min
SpareServers, or OHS will simply adjust the number on it?s first
Max Clients is similar to the database
processes parameter. It is used to limit the number of child
server processes that OHS can create. When it reaches this
limit, all new requests are rejected. It should be set higher
than the expected highwater mark of users connected to the system.
It can be used to limit resource use on a restricted system.
However, refusing connections from clients is rarely a good idea.
Normally, it is better to run slow than refuse the client. The
main value of this parameter is to stop the run away creation of
child processes in case of an error.
LoadModule foo_module libexec/mod_foo.so
LoadModule mmap_static_module libexec/mod_mmap_static.so
LoadModule vhost_alias_module libexec/mod_vhost_alias.so
The next important task is the loading of
module directives. Here, OHS reads the directives from each
module file so that it can dynamically load and use the module when
needed. One important note: some modules rely on other
modules, therefore the order that OHS reads each set of directives
is important. Do not change the order of the module listings
unless you are sure you will not break another module.
All the modules available to OHS are listed
under ?ServerRoot/libexec? and end with ?.so?. To list the
modules currently loaded, use ?ServerRoot/bin/httpd ?1?.
Default Server Parameters
Here, we transition to the Default or Main
Server Parameters. These parameters are used by the child
processes, and as we will see later, establish the default
parameters used by a Virtual Host, unless overridden. The
default parameters start with the ports that OHS will listen on.
The port is where OHS waits for a request.
Normally, HTTP requests are sent to port 80 by default. Oracle
has set the port to 7777 for the application server. If you
install multiple instances on one physical server, the first
instance will be assigned port 7777. As each successive
instance is installed, the OUI will detect that 7777 is used and
will increment the port number by 1 until it finds an unused port.
Thus, the second instance installed will be on port 7778, and the
third on 7779, and so forth.
The Listen parameter allows you to have OHS
listen on additional ports or even for other IPs. It can be
used either with the Port parameter or in place of it. If your
server is on multiple networks, you can use the Listen parameter to
limit the networks that OHS accepts requests from. For
example: Listen 192.168.3.124:80 will direct OHS
to service requests that arrive at that address. Listen
replaces the BindAddress directive that performed the same function.
However, you can have multiple Listen parameters, but you can only
have one BindAddress parameter. A second BindAddress will
overwrite the first. BindAddress is no longer available
starting with Apache 2.
Apache normally uses port 80 and is started
as root. Apache must be started as root to use ports below
1024. However, for security reasons, you do not want Apache
responding to requests as root. By setting the User and Group
parameters, you are telling the primary server process (which is
running as root) to spawn child processes running under the user and
group specified. However, since OHS uses ports above 1024, it
is started under the user and group that it was installed under, and
the User/Group parameters are not required. If you decide that
all or some of your OHSs will listen on port 80, you will have to
start those OHSs as root and use the User/Group parameters to
re-privilege the child processes.
The ServerName is a misunderstood parameter.
If defines the response name and is used in redirecting URLs (which
we will discuss later). It can be either a fully qualified
domain name or an IP address. If you are using Virtual Hosting
(described later in this chapter) you can override this parameter in
the Virtual Host.
Be careful changing the ServerName. If you
create a name that happens to be an actual domain name, you might
confuse your clients or cause redirection to fail.
The ServerAdmin parameter is an email
address that is included on most server-generated documents, such as
error messages. This will give your clients an address to
contact if necessary.
The DocumentRoot parameter defines the
directory that OHS will serve static content files from. It
can be defined explicitly, as in the example, or as a directory off
the ServerRoot. The above example can also be defined as
?DocumentRoot ?htdocs??, since our ServerRoot is
?/home/oracle/oraportal904/Apache/Apache?. The directory
defined in DocumentRoot can be any directory that the User/Group of
the child processes has permission to read, including a Network File
System (NFS). Static files are normally separated into
subdirectories located off the DocumentRoot such as:
htdocs/resume ? resume for company employees
htdocs/consulting ? company consulting services
htdocs/consulting/database/oracle ? the oracle database consulting
Many administrators are starting to change
the DocumentRoot to ?/var/www?. This is fine as long as the
User/Group has the necessary permissions to access the files.
Now that we have defined the document
directories, we need to tell OHS what actions it can perform in each
directory. To do this, we will introduce Container Directives.
This is an excerpt from "Oracle
10g Application Server Administration Handbook" by Don Burleson
and John Garmany.