• Aucun résultat trouvé

Default Server Parameters

Dans le document Oracle Application Server 10 g (Page 141-151)

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.

ServerName appsvr.localdomain.com

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 in redirecting 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 jwg@oracle10gas.com

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 Handbook

Before 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>

<Directory /www/docs/time>

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">

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>

P:\010Comp\Oracle8\958-6\ch04.vp Monday, March 08, 2004 3:44:42 PM

126

Oracle Application Server 10gAdministration Handbook

The 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 of block directives are <IfModule> and <IfDefined>.

<IfModule mod_userdir.c>

If module mod_userdir.c is loaded in the first example, the variable UserDir is defined as public_html. If the module is not loaded, the block is skipped, and UserDir either remains with its current definition or is undefined. In the second example, if ReverseProxy is defined, the directed module headers are loaded.

Note that block directives can be nested, and they do not limit the scope of the contained directives, which execute within the scope of the container in which they were called, as well as globally.

Files and FilesMatch Containers The Files and FilesMatch containers allow for file-level access control. The difference between the Files container and the FilesMatch container is that the FilesMatch container uses regular expressions to identify affected files. The Files containers are placed after the Directories container in the httpd.conf file; however, they can also be nested inside a Directory container. The following Files container is located in the httpd.conf file of the OHS.

<Files ~ "^\.ht">

Order allow,deny Deny from all

</Files>

This Files container denies all access to any file that starts with .ht. Since directories may contain a .htaccess file that contains access information, this Files container ensures that no user can request that file. If the Files container is nested inside a Directories container, the scope of the Files container directive is limited to the scope of the Directories container.

The use of the ~ character in the file name allows Files to use regular expressions. Starting with Apache 1.3, it is preferred to use FilesMatch when regular expressions are needed. Many directives have a *Match companion. It is preferred to use the *Match version rather than the ~ option when using regular expressions. Last, the Files and FilesMatch containers can be used in the .htaccess file.

Location Containers The OHS httpd.conf file contains a number of Location containers spread through the file, so we will briefly explain them here. Location containers limit access by URL.

P:\010Comp\Oracle8\958-6\ch04.vp Monday, March 08, 2004 3:44:43 PM

Chapter 4: Using the Oracle HTTP Server (OHS)

127

They are normally located after the Files section of the httpd.conf file. For all origin (nonproxy) requests, the URL to be matched is of the form /path /, and you should not include any http://

servername prefix. For proxy requests, the URL to be matched is of the form scheme://servername/

path, and you must include the prefix.

<Location /status>

Order Deny,Allow Deny from all

Allow from .oracle.com

</Location>

Here, access to the /status path is limited only to those requests originating from oracle.com.

For more information on the Location container, see the Apache documentation.

Languages and File Types

The next section of the httpd.conf file deals with file types or mime support. Again, this section is inside a block directive and will only be read if the test returns true. Mime support provides metadata about files so that OHS can service requests correctly or, if necessary, pass that information to the client so that the client can handle the file correctly. You saw this in action with the MultiViews option earlier. A good example is language support.

OHS uses the module mod_negotiation to select the correct file using file mappings, or by executing a file name pattern match and choosing from the results. Files used by OHS to service requests can have multiple extensions. The order of the extension does not matter unless OHS cannot identify an extension. In that case, OHS uses the extensions to the right of the unidentified extension only. For example:

filename.jwg.html.en filename.jwg.en.html filename.en.jwg.html

The preceding three files define types for html and en, but not for jwg. The first two files are identified as HTML files associated with the language English. The last file is only identified as an HTML file, and no language information can be determined. So, the order of file extensions added is irrelevant, as long as the undefined extensions are to the left of the defined extensions.

Also, extensions are case sensitive (.z and .Z are two different extensions). Let’s return to our httpd.conf file and walk through this section.

<IfModule mod_mime.c>

TypesConfig /home/oracle/oraportal904/Apache/Apache/conf/mime.types AddEncoding x-compress Z

AddEncoding x-gzip gz tgz

The first step is to read a file that is used to define a long list of file types called mime.types.

Next, it defines additional extensions for compressed files. This mapping is added to existing mappings and will override any mappings that already exist for these extensions. The preceding example marks a file with the .Z extension as encoded using x-compress, and any file with the .gz or .tgz as encoded using x-gzip.

Now let’s look at the language types and character sets. When a client browser initiates a request, it supplies a heading that also identifies the preferred language. The preferred language

P:\010Comp\Oracle8\958-6\ch04.vp Monday, March 08, 2004 3:44:44 PM

128

Oracle Application Server 10gAdministration Handbook

is used to determine which file to serve that browser if there are a number of files to select from.

Taking another section from the httpd.conf file:

AddLanguage da .da

This section defines file extensions that support different languages. Using the AddLanguage directive allows you to map an extension to a language code. Normally, the extension is the same as the language code, but some will differ. For example, the language code for Poland is pl, but the .pl extension usually denotes a Perl script. Thus, you can map .po to the language code pl and use the .po extension on the Polish documents.

Another thing to note is that documents in some languages need a specific character set to display properly. This can be defined using the AddCharset directive. For example, the Korean language code is kr. You can see in the preceding code that it maps to the .kr extension. However, for the browser to properly display this document, it also needs to know which character set to use. The character set ISO-2022-KR is mapped to the extension .iso-kr. Thus, a document in the format filename.html.iso-kr.kr is an HTML document that requires the ISO-2022-KR character set and is in Korean.

It is important to note that an extension can only be mapped to one language. In the following code segment, .en is mapped only to kr, while both .po and .pl are mapped to Polish.

AddLanguage en .en AddLanguage pl .pl AddLanguage pl .po AddLanguage kr .en

If more than one mapping is present for a single extension, the last occurrence is used. The final step in defining language support is to provide a priority list, so that if two files tie, OHS will know which to use.

P:\010Comp\Oracle8\958-6\ch04.vp Monday, March 08, 2004 3:44:44 PM

Chapter 4: Using the Oracle HTTP Server (OHS)

129

<IfModule mod_negotiation.c>

LanguagePriority en da nl et de el it ja kr no pl pt pt-br ru

</IfModule>

This nested block directive establishes a priority list in descending order to be used by the module mod_negotiation to break a tie. Note that it is a language list, not an extensions list.

The final directive dealing with file types is the location of the magic file. This file is used by the module mod_mime_magic and is normally located in the ServerRoot/conf directory. This module will look into an unknown file and use the definitions in the magic file to try and determine the file type.

Log Files

The next section of the httpd.conf file defines log locations, logging levels, and formats. Logging levels determine how much information is logged. The greater the level, the more information and the faster the logs grow.

HostnameLookups Off

ErrorLog /home/oracle/oraportal904/Apache/Apache/logs/error_log LogLevel warn

You can have OHS log the host name instead of the IP address, but that is not recommended since OHS must hit the DNS to resolve the IP address. The default is HostnameLookups Off,

You can have OHS log the host name instead of the IP address, but that is not recommended since OHS must hit the DNS to resolve the IP address. The default is HostnameLookups Off,

Dans le document Oracle Application Server 10 g (Page 141-151)