IHS release | corresponding Apache release that it was based on | corresponding Websphere Application Server release |
---|---|---|
1.3.12.x | 1.3.12 | 3.5.x |
1.3.19.x | 1.3.20 | 4.0.x |
1.3.26.x | 1.3.26 | 5.0.x |
1.3.28.x | 1.3.28 | 5.1.x |
2.0.42 | 2.0.42 | 5.0 |
2.0.42.1 | 2.0.44 | Fix pack 5.0.1 |
2.0.42.2 | 2.0.46 | Fix pack 5.0.2 |
2.0.42.2-PQ85834 and later | 2.0.47 | N/A |
2.0.47 and later | 2.0.47 | 5.1 |
6.0 and later | 2.0.47 | 6.0.x |
IHS keepalive settings affect connections between IHS and the web client. Websphere settings affect connections between the Websphere plug-in (running in IHS) and Websphere. The connections are independent and the settings are independent.
When enabling authentication in IHS, be aware that some configuration mechanisms apply only to static files served by IHS but not to requests handled by the WebSphere plug-in.
Example 1:
<Directory /usr/HTTPServer/htdocs/en_US> AuthType Basic AuthName WebAccess AuthUserFile /usr/HTTPServer/userids Require valid-user </Directory>
This type of configuration only affects files served by IHS. It does not affect WebSphere requests.
Example 2:
<Location /> AuthType Basic AuthName WebAccess AuthUserFile /usr/HTTPServer/userids Require valid-user </Location>
This type of configuration affects any request served by IHS, including WebSphere requests. The WebSphere plug-in would then pass the user id on to WebSphere for possible use by the application.
Watch out for redirections which make the web browser think it is contacting a different web server. Here is an example of this type of problem, where the web browser has to authenticate over non-SSL only to find out that it has been redirected to an SSL port. The browser assumes that it is a different server and will prompt again.
<Location /protected.html> RewriteEngine on RewriteCond %{SERVER_PORT} =80 RewriteRule ^(.*) https://%{SERVER_NAME}%{REQUEST_URI} Satisfy all AuthUserFile /etc/webusers AuthName Intranet AuthType basic Require valid-user </Location>
In this type of situation, the redirection to SSL should be unauthenticated. Then, the authentication should happen once the request has been issued to the SSL port. Here is a solution:
# when request for the protected resource is received over # non-SSL, redirect to SSL without authenticating <VirtualHost *:80> ... (existing configuration for this vhost) <Location /protected.html> RewriteEngine on RewriteRule ^(.*) https://%{SERVER_NAME}%{REQUEST_URI} </Location> </VirtualHost> # when request for the protected resource is received over # SSL, authenticate <VirtualHost *:443> ... (existing configuration for this vhost) <Location /protected.html> Satisfy all AuthUserFile /etc/webusers AuthName Intranet AuthType basic Require valid-user </Location> </VirtualHost>
This is with the LogFormat directive. The format string to use is "%{header-name}o", or "%{Set-Cookie}o".
Simple example for this existing access log configuration:
LogFormat "%h %l %u %t \"%r\" %>s %b" common CustomLog logs/access_log common
Add "%{Set-Cookie}o" to the format string on the LogFormat directive, resulting in
LogFormat "%h %l %u %t \"%r\" %>s %b %{Set-Cookie}o" common CustomLog logs/access_log common
(There may be a number of different LogFormat directives... the one of interest is the one whose format name (e.g., "common") is actually referenced on your CustomLog directive.)
On our non-Win32 platforms, IHS 1.3.x or 2.0.x must be started as root in order to bind to a low port. That is a hard requirement with no work-around on those platforms we support. A "low port" is a port below 1024. The normal web server ports (80 and 443) are low ports.
One work-around used by some Apache users is to utilize a firewall to redirect requests to port 80 to a high port. Then Apache (or IHS) wouldn't have to start as root in order to bind the port, since it won't bind to a low port.
IHS >= 2 on Windows can write to log files > 2GB.
This is supported, except for rotatelogs, starting with cumulative i-fix PK01070, and with IHS 6.0.0.2.
This will not be supported.
You can't prevent the product name from being sent to clients in the Server header field, but you can minimize it to
Server: IBM_HTTP_SERVERby coding
ServerTokens Prodin the web server configuration file.
See also the ServerSignature directive for controlling whether information about the server is included in certain error messages.
Even without the standard Server header field in the response:
IHS 2.0.42.x prior to PQ85834 had a defect which allowed CGIs and plug-ins to override the value of the Server header field.
Here are AIX inittab entries to start IHS 1.3 or IHS 2.0:
: ihshttpd:2:wait:/usr/HTTPServer/bin/httpd > /dev/console 2>&1 ihshttpd:2:wait:/usr/IBMIHS/bin/apachectl start > /dev/console 2>&1
The first entry is commented out (leading ":") and starts IHS 1.3. The second entry is active and starts IHS 2. For either 1.3 or 2.0, replace the path to httpd or apachectl with the chosen installation directory. The "apachectl start" command is a valid way to start IHS 1.3 or IHS 2.0. The "httpd" command is only valid for IHS 1.3.
When customers can't get to mod_status page from a browser, or when there is some load balancer in front that makes it difficult to get mod_status from a particular server, or when they want to have mod_status pages saved automatically, they can run something like this script on the web server machine. It requires that perl and wget be installed. Perl usually comes with the operating system, and wget is an open source program to save a web page in a file.
grabstatus.pl:
#!/usr/bin/perl -w use strict; my $STATUS_URL = "http://127.0.0.1/server-status/"; my $SLEEP_INTERVAL = 60; # seconds while (1) { my $timestamp = time(); system("wget -O serverstatus.$timestamp $STATUS_URL"); sleep($SLEEP_INTERVAL); }
If all you want is to know how many threads are busy and in what state, see mod_mpmstats.
Use mod_headers with the following configuration:
Header set Pragma "no-cache" Header set Cache-Control "no-cache" Header set Expires "-1"
Refer to this document.
SSLRequireSSL
directive?The SSLRequireSSL
directive is not supported with any
level of IHS. IHS uses a different SSL implementation than available
for Apache 1.3 or Apache 2.0.
Instead of using the SSLRequireSSL
directive to
specify that certain files or directories can only be served over SSL,
a customer can achieve the same result in different manner, by denying
access to the file or directory in the non-SSL configuration. In
following example, files under URI /onlyssl
can only be
served over SSL:
... # /onlyssl can't be served by default <Location /onlyssl> Order Allow,Deny Deny from all </Location> ... <VirtualHost *:443> SSLEnable ... # put this config for /onlyssl inside all SSL-enabled # VirtualHost containers <Location /onlyssl> Order Allow,Deny Allow from all </Location> </VirtualHost> ...
%{HTTPS_CIPHER}e
will log the name of the cipher
(e.g, TLS_RSA_WITH_AES_256_CBC_SHA
). Ensure that the
LogFormat directive which is changed is for the format used on the
CustomLog directive.
Example:
LogFormat "%h %l %u %t \"%r\" %>s %b %{HTTPS_CIPHER}e" common CustomLog logs/access_log common
9.48.108.152 - - [17/Feb/2005:15:37:39 -0500] "GET / HTTP/1.1" 200 1507 SSL_RSA_WITH_RC4_128_SHA 9.48.108.152 - - [17/Feb/2005:15:37:40 -0500] "GET /httpTech.view1.gif HTTP/1.1" 200 1814 SSL_RSA_WITH_RC4_128_SHA 9.48.108.152 - - [17/Feb/2005:15:37:40 -0500] "GET /httpTech.masthead.gif HTTP/1.1" 200 11844 SSL_RSA_WITH_RC4_128_SHA 9.48.108.152 - - [17/Feb/2005:15:37:41 -0500] "GET /httpTech.visit1.gif HTTP/1.1" 200 1457 SSL_RSA_WITH_RC4_128_SHA
For non-secure requests, "-" will be logged for the cipher specification.
The key size can be logged with the %{HTTPS_KEYSIZE}e
format string. See the section on SSL environment variables in the
IBM HTTP Server InfoCenter for information about other SSL environment
variables which can be logged. See the documentation for the
LogFormat and CustomLog directives for more information about format
strings in general.
A manual way to check this is to use Ethereal on the client box and start a packet trace capture. Then load the web page. Then stop the capture in Ethereal and look for the Server "Hello" response. This will appear in the packet window like this:
1.750088 server-ip-address client-ip-address TLS Server Hello, Certificate, [Unreassembled Packet]
Select that packet, then look for the "Handshake Protocol" information in the next window:
Handshake Protocol: Server Hello Handshake Type: Server Hello (2) Length: 70 Version: TLS 1.0 (0x0301) Random.gmt_unix_time: Apr 8, 2005 14:15:33.00000000 Random.bytes Session ID Length: 32 Session ID (32 bytes) Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004) Compression Method: null (0)
Check the display of the cipher suite.
<Location /some/url> SetEnv downgrade-1.0 1 </Location>
No, the rotate operation will not occur until IHS logs another request. If your configuration specifies that rotatelogs performs the rotation operation after 86400 seconds, and if IHS receives no requests after 86400 seconds have elapsed, the new log file will not yet be created. Then, when rotatelogs receives its next request to log, it will create the new log file and close the old one.
Short answer: This is working as designed; the lock file doesn't show up in directory listing except for a brief moment during IHS initialization.
Long answer: When IHS initializes an fcntl accept mutex during startup, it opens/creates the lock file, retains the file descriptor, but "unlinks" the lock file so that it is removed from the system just in case IHS exits abnormally and is unable to run its normal cleanup code. This procedure is a standard technique to avoid leaving dangling files after process termination, but it results in the file being invisible to the ls command. This means that other applications can't mess with the file, accidentally or not, since they can never open the same lock file used by IHS.
If you really want to see the lock file working, you can pick an IHS child process and run truss against it. ("truss -p PID") At the end of processing one client, a call like this will appear:
kfcntl(19, F_SETLKW, 0x2000AEE0) (sleeping...)
So file descriptor 19 is the lock file. (This actual number will almost certainly be different in your environment.) lsof when run against an httpd process ("lsof -p PID") would display that file descriptor as follows:
httpd 23104 root 19w VREG 10,8 0 2261678 /home (/dev/hd1)The size (7th column) should be 0 and the filesystem (two last columns) should match the filesystem used by your LockFile directive.
favicon.ico
in my
logs?A customer sees something like this in his access log:
127.0.0.1 - - [08/Mar/2005:12:51:08 -0500] "GET /favicon.ico HTTP/1.1" 404 304
Requests for favicon.ico are unavoidable. Internet Explorer and some other browsers will blindly request favicon.ico in case the web site has that file. You may have noticed that on some web sites, there is a cute icon in the URL box on your web browser; favicon.ico from that web site is the cute icon. Most web sides don't have that file, so there will be a 404 in the web site's access log and the browser will use the default icon.
The customer is not in control of whether or not the browser issues that request. They can have their site designer provide a favicon.ico file or they can ignore the entries in the access log. We do not recommend that they filter out the entries from the access log, because if there is ever a question of what requests are hitting the server, then the access log wouldn't be able to answer that question.
There are two common problems:
allow
from
directive for <Location /server-status>
which is not working.
[Sat Mar 12 06:36:21 2005] [error] [client 127.0.0.1] (13)Permission denied: access to /server-status/ denied
Occasionally, problems with IHS or third-party modules can be attributed to issues which occur when IHS child processes terminate. In this case, it is helpful to disable child process termination until the problem can be fully resolved.
Set MaxRequestsPerChild to 0 and set MaxSpareThreads to the same value as MaxClients.
Set MaxRequestsPerChild to 0 and set MaxSpareServers to the same value as MaxClients.
There is no mechanism to shut down the web server yet allow active requests to gracefully finish. Active requests must finish within about 7 seconds, or they may be forcefully terminated when the child process is killed.
Here is an example where all requests received on port 80 are redirected to the SSL port. Replace www.example.com with the hostname of your server. The new VirtualHost container will automatically apply to any requests received on the specifed port (80), and mod_rewrite will always redirect these requests to the https (SSL) equivalent.
<VirtualHost *:80> RewriteEngine on RewriteRule ^/(.*) https://www.example.com/$1 [R,L] </VirtualHost>
Example: The following RewriteRule is supposed to redirect requests for /datasheets to http://www.example.com/CatalogView?view=01&content=02#readme, but the # is getting translated to %23 in the response to the browser.
RewriteRule /datasheets http://www.example.com/CatalogView?view=01&content=02#readme
By default, mod_rewrite will perform URI escaping on special characters such as '#', such that the rewritten URL contains the percent sign followed by the numeric code for the character. The escaping behavior can be overridden with the noescape processing flag. Here is the new RewriteRule which avoids the escaping:
RewriteRule /datasheets http://www.example.com/CatalogView?view=01&content=02#readme [R,NE]
Consult the mod_rewrite documentation for more information.
Note: If there is a question about what is being sent to the
browser, the RewriteLog and RewriteLogLevel directives can be used to
turn on logging in mod_rewrite, or the Location header field can be
logged in the access log by adding %{Location}o
to the
access log format.
Set a variable called image-request when the request is for certain filenames. Then, update the CustomLog directive to indicate that requests should not be logged when the image-request variable is set.
SetEnvIf Request_URI \.gif$ image-request SetEnvIf Request_URI \.jpg$ image-request # add another SetEnvIf directive for other file extensions to be skipped CustomLog logs/access_log common env=!image-request
The mod_log_config documentation has an example showing how to put image requests in one access log and non-image requests in another access log.
Generally speaking, requests can fail in one of the following functional areas:
Finding the root cause requires finding which functional area failed the request. This can usually be determined by checking the log files maintained by the various components.
127.0.0.1 - - [08/Apr/2005:06:40:08 -0400] "GET /cgi-bin/test-cgi" 500 658 -
[Fri Apr 08 06:40:08 2005] [error] (13)Permission denied: exec of 'test-cgi' failed [Fri Apr 08 06:40:08 2005] [error] [client 127.0.0.1] Premature end of script headers: test-cgi
In this case, an IBM HTTP Server feature failed, and the error log contains more information.
If no entries were written to the error log at the time of the failure, the problem must have occurred in an area other than IBM HTTP Server. Proceed with the following checks.
If no entries were written to the plug-in trace file, the problem must have occurred in a different area. Proceed with the following checks.
If WebSphere didn't process the request, or WebSphere returned a good response code for the request (e.g., 200 or 302), the problem must have occurred in a different area. Proceed with the following checks.
It is likely that truss can be used to show which module is failing the request. If at all practical, re-configure IHS temporarily to use a single child process for processing client requests. Here is an example with IBM HTTP Server 2.0 or above:
<IfModule worker.c> ThreadLimit 256 ServerLimit 1 StartServers 1 MaxClients 256 MinSpareThreads 1 MaxSpareThreads 256 ThreadsPerChild 256 MaxRequestsPerChild 0 </IfModule>
Then start IHS as normal, and find the process id of the two IHS child processes via ps.
# cat /opt/IBMIHS/logs/httpd.pid 99999 <- example value # ps -ef | grep 99999 webuser 10001 99999 ..... webuser 10002 99999 ..... root 99999 1 .....
These two processes with 99999 for the parent are the two IHS child processes. One will be mod_cgid daemon and one will actually serve requests. We'll just trace both of them to avoid picking the wrong child process.
# truss -o /tmp/tracefile -u :: -u a.out,\* -p 10001 10002 (Replace 10001 and 10002 with the actual pids of the IHS child processes.)
Next, reproduce the problem.
Next, interupt the truss process (<Ctrl>C). The tracing via truss will slow down the web server significantly and will generate a large amount of output, so reproduce the problem and stop the tracing as quickly as possible.
Here is the type of information we would expect to find. In this example, I have configured mod_access to return 403 (access denied) for a certain request:
$ grep 403 /tmp/outfile 11729/27@27: <- mod_access:check_dir_access() = 403 11729/27@27: <- ap_run_access_checker() = 403 11729/27@27: <- decl_die() = 403 11729/27@27: <- ap_process_request_internal() = 403 11729/27@27: <- ap_die() = 403
The first place where 403 showed up (i.e., the module which set 403) was mod_access.
For your situation, search for the bad status code (e.g., 500) in /tmp/outfile and see which module (mod_sm, mod_access, whatever) set the 500. Send in the trace file for us to analyze if it isn't clear which module set 500, or if an IBM-provided module set 500. If the status was set by a third-party module, contact the vendor for diagnosis.
At the present time (20050408), we anticipate that a fix pack for IBM HTTP Server 6.0.x and a cumulative e-fix for IBM HTTP Server 2.0.x available at the end of Q2 '05 will provide a mechanism for recording the point of failure in the access log.
IHS 2.0 on AIX normally serves files using the
send_file()
API. This results in the files being stored
in
the AIX Network Buffer Cache. This leaves the files open as long as
they are in the cache, preventing the underlying filesystem from being
cleanly unmounted.
To clear files from the cache and unmount the filesystem:
The old cache size can be displayed by no -o nbc_limit
.
The cache size can be set to zero by no -o nbc_limit=0
.
no -o nbc_limit=old_value
An important IHS configuration directive which relates to this
the EnableSendfile
directive. By setting
EnableSendfile Off
in the IHS configuration file, IHS
won't use the AIX send_file() API, and thus static files served by
IHS won't possibly be added to the network buffer cache.
In newer IHS sample configuration files (starting with PQ85834), send_file() is disabled by default to eliminate the possibility that customers may encounter occasional sendfile nuances unless they choose to actually use it.
IHS itself is not aware of which objects are in the network buffer cache and can't remove such objects. Subject to the constraints of the network buffer cache (smallest/largest cacheable object, total size), objects (files) are sometimes added to the cache by the AIX kernel as a side-effect of IHS invoking the AIX send_file() API.
An infrequently used IHS module for AIX is the AFPA cache module. It also interacts with the network buffer cache and should be disabled if the customer does not wish to empty the network buffer cache prior to unmounting a filesystem containing files which were cached.
The %D custom log format calculates the time to serve the request, from the time that the web server reads the first line of the request from the client to the time the web server processes the %D format while logging the results of the request. If there is a subsequent request sent on the same TCP connection, the time measured by %D may not cover the end of the last buffer of the response.
IBM HTTP Server 2.0 and above uses the worker MPM on Unix and Linux systems, and it cannot be replaced. Any information about Apache that suggests recompiling the web server for a different MPM does not apply to IHS, as the MPM is pre-selected and IHS cannot be recompiled by customers.
>We would like to know the priority of the following directives. >- mod_dir(dir_module) >- mod_rewrite(rewrite_module) >- WebSpherePlugin(ibm_app_server_http_module)
mod_dir only handles objects which can be served by IHS as static files, so it cannot be used to redirect requests to WebSphere. mod_dir has the lowest priority of these modules, and the priority cannot be changed. It will only try to handle a request if the request was for a directory and no other module has decided to serve the request.
With IHS 2.0, mod_rewrite always takes precedence over the WebSphere plug-in and, with the proper configuration, mod_rewrite can first rewrite URLs and then the WebSphere plug-in can see the rewritten URL and decide whether or not to serve it.
Example: Customer wants to use mod_rewrite to change URL /home to /servlet/home/, and customer has configured the WebSphere plug-in to handle /servlet/*.
Here is a mod_rewrite directive to map /home to /servlet/home, and at the same time pass it through to the WebSphere plug-in to allow it to see the rewritten URL. The PT flag on the RewriteRule is what allows the WebSphere plug-in to process the rewritten URL.
RewriteRule ^/home /servlet/home [PT]
Note: In IHS 1.3, the actual order of the LoadModule or AddModule directives also makes a difference. The LoadModule or AddModule for mod_rewrite needs to come after the WebSphere plug-in is activated to allow mod_rewrite to rewrite URLs and then have the WebSphere plug-in process the rewritten URL. This is not the case with IHS 2.0, where mod_rewrite always takes precedence.
mod_perl does not work with IHS 1.3 or normal Apache 1.3 on AIX. There is a build trick with Apache 1.3 to turn on run-time linking, which is required for proper mod_perl support. This involves building Apache 1.3 from scratch with special build flags to enable run-time linking.
Since IHS can't be rebuilt by the customer and IBM can't change the build of IHS due to customer migration concerns, customers need to use real Apache 1.3 with mod_perl. Information about how to build Apache 1.3 to use with mod_perl on AIX can be found on the web.
The accept mutex is necessary in multiple child process configurations to prevent the thundering herd problem, where multiple child processes wake up to handle a single incoming connection. The accept mutex is used to ensure that only one child process wakes up when an incoming connection is ready to process.
The accept mutex is always used when there is more than one listening
socket. When there is a single listening socket, the accept mutex is
used unless httpd -V (IHS 1.3) displays -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
.
The default for IHS 1.3.19 through IHS 1.3.26 on AIX is AcceptMutex pthread. This has the following problems with IHS 1.3:
We have never seen this problem with IBM-provided modules (for example, the modules provided with IHS such as mod_rewrite, and the WebSphere plug-in module). If you are loading only IBM-provided modules into IHS (LoadModule directives in httpd.conf), then this is not a concern.
If you are using non-IBM modules, we cannot predict in advance whether or not you will encounter this type of problem with that module. That depends on whether the exact version of that module has such a defect which can occur in your environment.
This is the default mechanism for IHS 1.3.19 through IHS 1.3.26.x. This mechanism uses the pthread_mutex_lock() function in the AIX pthread library to serialize access to the listening socket between processes. The lock is in shared memory, which allows multiple httpd processes to use it. There is no underlying file associated with this type of mutex, so the LockFile directive is ignored.
pros
cons
This is a possible mechanism for IHS 1.3 (1.3.19.3 and above).
This mechanism uses the semop() and semctl() functions in the AIX
kernel to serialize access to the listening socket between processes.
There is no underlying file associated with this type of mutex, so the
LockFile directive is ignored. The semaphore is viewable with the AIX
ipcs
command.
pros
cons
This is the default mechanism for IHS 1.3.12 and below and for IHS 1.3.28 and above. This uses the fcntl() kernel function to serialize access to the listening socket between processes. The httpd processes wait for exclusive access to a lock file, then they can safely access the listening socket(s). There is no real file I/O performed. Because the mutex is file-based, a lock file will be used. Normally, the lock file is stored in the logs directory under the IHS ServerRoot directory. The LockFile directive needs to be used in the following situations to override the default name of the lock file:
pros
cons
AcceptMutex pthread
or AcceptMutex sysvsem
; the actual difference is hard to
measure with real world workloads
The authentication module which handles flat files of userids and passwords is mod_auth (described in the IHS Infocenters or in the Apache 1.3 documentation). On Windows, mod_auth accepts flat text files of the form
userid:password
There are three allowable forms of the password:
jeff:jeff
jeff:$apr1$PN2.....$iPOw99RhtaeLLZ6OnXeGW/
jeff:{SHA}8+cx36KTx6gxGdiqz6QbXS14C+k=
The traditional "crypt" format of the password is not supported by IHS 1.3 on Windows.