NOTE
The Distributed Configuration Management utility maintains a repository of configuration data. If you manually update the configuration files, you must update the repository. To execute this update, use the command dcmctl –updateConfig –ct ohs. If you update the configuration using Enterprise Manager, the repository is automatically updated for you.
Oracle HTTP Server Modules
Some of the modules that OHS uses to add capabilities to the base server are self-contained, while others rely on separate modules, and some call external programs. Each module adds features to implement a specific function. There are nearly 50 core modules in a basic Apache server, while OHS adds even more modules to support specific Application Server 10g features.
Each module may add new directives that need to be defined in the httpd.conf file. The httpd.conf file contains a number of directives, enclosed within IfModules, that load parameters only if that module is loaded. Modules are not actually loaded at startup. OHS scans the module’s file and loads headers that will call the module if its functionality is required.
Table 4-1 provides a brief list of some of the main modules and the functions they add to the basic server. Many will be discussed in greater detail in the sections that follow. Because the function of an application server is to support enterprise applications using J2EE, mod_jserv and mod_oc4j are discussed in detail in Chapters 6 and 7.
In this chapter and throughout the book, some modules will be discussed in detail. For detailed information on each module, refer to the Oracle HTTP Server Administration Guide.
Type Name Function
Security mod_access Provides access control based on client host name or IP mod_auth Provides authentication using text files
mod_auth_anon Provides anonymous user authentication mod_ssl Supports SSL certificates
mod_osso Provides integration with Single Sign-On Configuration mod_actions Executes CGI scripts
mod_alias Maps directories into the document tree and supports URL redirecting
mos_setenvif Sets environmental variables based on the request mod_dir Supports trailing slash redirects and directory index files mod_headers Supports customization of HTTP response headers
P:\010Comp\Oracle8\958-6\ch04.vp Monday, March 08, 2004 3:44:37 PM
120
Oracle Application Server 10gAdministration HandbookType Name Function
Debug mod_log_config Supports logging of requests
mod_status Presents current server performance statistics Response mod_mime Determines file types from filename
mod_negotiation Supports selecting the best from multiple documents that support user’s capabilities
URL_Changes mod_rewrite Provides rule-based rewriting engine to rewrite requests on the fly
mod_userdir Supports user-specific directories
Language mod_perl Forwards Perl scripts to the Perl interpreter mod_jserv Forwards servlet request and handles response
(not used in Application Server 10g)
mod_oc4j Routes request to OC4J instances and supports load balancing
mod_plsql Forwards plsql requests to the Oracle database engine for execution of stored procedures
mod_include Supports server-parsed HTML mod_CGI Executes CGI scripts
Session mod_unique_id Supports unique identifiers for certain requests mod_usertrack Supports user tracking using cookies
Performance mod_proxy Supports caching proxy server
TABLE 4-1. Common Oracle HTTP Server Modules (continued)
Configuring OHS and Using Server Logs
The OHS is configured using one main configuration file called httpd.conf and a supplemental file called oracle_apache.conf. Both files are located in the $ORACLE_HOME/Apache/Apache/ conf/ subdirectory. Each Application Server 10g instance installs an Oracle HTTP 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. In the following sections, we will walk through a sample httpd.conf file and discuss the important configuration parameters.
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
P:\010Comp\Oracle8\958-6\ch04.vp Monday, March 08, 2004 3:44:38 PM
Chapter 4: Using the Oracle HTTP Server (OHS)
121
are appropriate and should only be changed when specific situations warrant. Be sure to read thecomments before making changes. The parameters are grouped into three sections: global parameters, default server parameters, and virtual host parameters. At the very end are the Oracle-specific configuration files.
Global Parameters
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.
ServerRoot "/home/oracle/oraportal904/Apache/Apache"
When defining a file location, placing the backslash (/, or 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".
PidFile /home/oracle/oraportal904/Apache/Apache/logs/httpd.pid
As you 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 installed.
MinSpareServers 5 MaxSpareServers 10 StartServers 5
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 ensure 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 its first check.
MaxClients 150
MaxClients 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 high-water 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 slowly than to refuse the client. The main value of this parameter is to stop the runaway creation of child processes in case of an error.
P:\010Comp\Oracle8\958-6\ch04.vp Monday, March 08, 2004 3:44:39 PM
122
Oracle Application Server 10gAdministration Handbook# 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 you 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.
Port 7778 Listen 7779
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.
User oracle Group oracle
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 reprivilege the child processes.
P:\010Comp\Oracle8\958-6\ch04.vp Monday, March 08, 2004 3:44:40 PM
Chapter 4: Using the Oracle HTTP Server (OHS)
123
The ServerName is a misunderstood parameter. It defines the response name and is used inredirecting URLs (which will be discussed later in the chapter). 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.
ServerAdmin [email protected]
The ServerAdmin parameter is an e-mail address that is included on most server-generated documents, such as error messages. This will give your clients an address to contact if necessary.
DocumentRoot "/home/oracle/oraportal904/Apache/Apache/htdocs"
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 preceding 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 Opening page
■ htdocs/resume Resume for company employees
■ htdocs/consulting Company consulting services
■ htdocs/consulting/database/oracle Oracle database consulting pages
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.
Once the document directories have been defined, you need to tell OHS what actions it can perform in each directory. To do this, you will need to understand container directives.
Container Directives
Container or block directives change the configuration within the area defined by the container. They use the familiar HTML notation, with some restrictions. Directives must be on their own line. Container directives have limited scope, and if included directives are outside the scope of the container, they will be ignored. The following code sample demonstrates the basic structure of a container directive.
<ContainerType objects> list of directives </ContainerType>
The following example container is a Directory container for our DocumentRoot directory.
<Directory /> Options All AllowOverride All </Directory>
P:\010Comp\Oracle8\958-6\ch04.vp Monday, March 08, 2004 3:44:41 PM
124
Oracle Application Server 10gAdministration HandbookBefore going into detail about how directory containers are defined, let’s discuss the different types of container directives and their functions.
Directory Container Directives Directory container directives apply only to the named directory and all subdirectories under the named directory. For this reason, an administrator normally starts by defining a Directory container for the root directory to set up default directives for all directories that are not explicitly defined. For example:
<Directory />
Options FollowSymLinks MultiViews AllowOverride None
</Directory>
One alternative to control access to directories is to place a .htaccess file in each subdirectory containing specific directives. If the AllowOverride is not set to None, OHS will read the .htaccess file and override the directives in the httpd.conf file with the directives in the .htaccess file. To preclude this, set AllowOverride to None. Note that we have set AllowOverride to None in the container for the root directory. This will not preclude us from specifying other Directory containers in the httpd.conf file.
AllowOverride only applies to the .htaccess file. The Options parameter can be set to None, All, a combination of Indexes, FollowSymLinks, ExecCGI, or MultiViews.
None is self-explanatory, as is All, except that All does not include MultiViews. If you use MultiViews, you can’t use All and must list each option.
MultiViews is a nice capability that allows OHS to do an implicit file name search and pick from the results. For example, if you request the file pictures.html and it does not exist, OHS will look for pictures.html.* and may find pictures.html.en, pictures.html.fr, and so on. OHS will check the mapping for languages and select pictures.html.en, if that is the first language on the language mapping priority. OHS could also find pictures.html.gz (a compressed file), and either uncompress the file before serving it, or serve it compressed and let the client uncompress it.
ExecCGI allows the execution of CGI scripts located in that directory. FollowSymLinks allows OHS to follow symbolic links to another directory or file. This does not change the directory directives that it is executing under. If the symbolic link leads to a directory with different defined options, OHS will continue to execute under the directives of the directory that it came from. The SymLinksIfOwnerMatch option is the same, except that the target directory or file must be owned by the same user ID as the link.
The Indexes option will cause OHS to return a formatted listing of the directory if it fails to find the Index.html file; otherwise, it returns an error message. The Includes option allows Server Side Includes. If not set, the Options directive defaults to all (excluding MultiViews).
Normally, an administrator will define all options explicitly; however, to avoid confusion, you can add a + or – to an option. If the option uses a +, as in option +Indexes, the Indexes option is added to the options of the directories’ parent options. Likewise, the –, as in –FollowSymLinks, will exclude that option from the options of the directories’ parent options. For example:
<Directory /www/docs>
Options FollowSymLinks MultiViews AllowOverride None
</Directory>
P:\010Comp\Oracle8\958-6\ch04.vp Monday, March 08, 2004 3:44:42 PM
Chapter 4: Using the Oracle HTTP Server (OHS)
125
Options -FollowSymLinks +Indexes </Directory>
The directory /www/docs/time has the Indexes and MultiViews options.
Defining Directory Containers Now let’s return to the httpd.conf file and look at how the Directory containers are defined. The first step is to define the directives for the root directory, since all other directories are subdirectories of root. By defining the root directives, you establish default directives for any directories that are not explicitly defined.
<Directory />
Options FollowSymLinks MultiViews AllowOverride None
</Directory>
Next, the httpd.conf file defines directives for the DocumentRoot directory.
<Directory "/home/oracle/oraportal904/Apache/Apache/htdocs"> Options Indexes FollowSymLinks MultiViews
AllowOverride None Order allow,deny Allow from all </Directory>
This container contains a couple of new clauses used to limit access to the directory. Since the container can both limit and grant access, it uses the Order clause to direct the order in which grants and limits are evaluated. In this case, execute the Allow clause or clauses, then the Deny clauses.
Order Deny,Allow Deny from all
Allow from oracle.com
Here, we first deny access to all users, and then allow access to those users from the oracle.com domain. If the order clause was Order Allow, Deny, the result would be to deny access to everyone, including those from oracle.com. At this point, you need to understand the Limit and LimitExcept containers.
Limit and LimitExcept Containers The Limit and LimitExcept containers define directives on HTTP methods. Limit defines directives on named HTTP methods, while LimitExcept defines directives on all HTTP methods, except those named.
<Limit POST PUT DELETE> Require valid-user </Limit>
<LimitExcept POST GET> Require valid-user <LimitExcept>
P:\010Comp\Oracle8\958-6\ch04.vp Monday, March 08, 2004 3:44:42 PM
126
Oracle Application Server 10gAdministration HandbookThe first example limits the POST, PUT, and DELETE methods to a valid user. The second example limits all methods to a valid user, except for the POST and GET methods. The Limit and LimitExcept containers should rarely be used.
As we continue through the httpd.conf file, we find a block directive.
Block Directives Block directives are used to test for an item during the processing of the configuration file. The directives that they contain are only executed if the test returns true. If the test returns false, the directives between the block start and end are ignored. The two types