IBM HTTP Server basic directives
Lab Exercises
Author: Kalyan K Sugumar/Hermann Huebler
Owner: Hermann Huebler
Document History
Document Location
This is a snapshot of an on-line document. Paper copies are valid only on the day they are printed. Refer to the author if you are in any doubt about the currency of this document.
The source of the document will be found in:
Revision History
Date of this revision: | Date of next revision: |
Rev. # | Rev. date | Summary of changes | Changes marked |
|---|---|---|---|
|
|
|
|
|
|
|
|
Approvals
This document requires following approvals. Signed approval forms are filed in the Quality section of the PCB.
Name | Title |
|---|---|
|
|
Distribution
This document has been distributed to:
Name | Title |
|---|---|
|
|
Content
Table of Contents
1 Introduction 5
2 Pre-Requisites 6
3 Lab setup instructions 7
4 Tips and tricks 8
4.1 Starting IHS 8
4.2 Stopping IHS 8
4.3 Starting/Stopping multiple instances of IHS 8
4.4 Determining the server process status 8
4.5 Verification of the configuration 9
4.6 Restart IHS after configuration change 9
4.7 Make sure that proper authorities are set 9
4.8 Take a backup of the configuration 9
4.9 Disable browser cache for testing 9
4.10 Usage of priviliged ports 9
4.11 Using the “telnet” test 10
4.12 Determining what process listens on a port 10
4.13 Enabling IHS server-status display 11
5 The Lab starts here 12
DocumentRoot 13
ServerRoot 16
LoadModule 17
CustomLog 18
ErrorLog 21
LogFormat 22
AddLanguage 24
Allow 26
Deny 28
Order 29
Options 31
DirectoryIndex 34
User and Group 38
Include 41
ServerName 45
NameVirtualHost 51
ServerAlias 54
Alias and AliasMatch 56
WebSpherePluginConfig 58
Listen 59
ScriptAlias 61
TraceEnable 62
PidFile 63
ServerTokens 64
ServerSignature 65
ServerAdmin 66
Redirect and RedirectMatch 67
Introduction
The purpose of this lab is to demonstrate the basic configuration directives of the IBM HTTP Server. IHS directives are basically configuration elements in the configuration file (httpd.conf) what control the functionality and behavior of the web server. For example, the DocumentRoot directive can be used to specify the root directory (from OS perspective) for the IHS server to serve static content.
Each directive belongs either to the Apache core or to certain module. For directives not part of the core implementation it's therefore required to load the module in the configuration file.
For example: The WebSphere Application Server plugin is implemented as such a loadable module what provides the directive WebSpherePluginConfig to specify the configuration file for the WebSphere Application Server plugin. To be able to use this directive the corresponding module must be loaded first by using the LoadModule directive.
LoadModule was_ap22_module /opt/Plugins/i00/bin/32bits/mod_was_ap22_http.so
WebSpherePluginConfig /opt/Plugins/i00/config/i01/plugin-cfg.xml
The IBM HTTP Server (IHS) is based on the famous open source web server Apache. While IBM HTTP Server (IHS) 6.1 is based on Apache 2.0.47 the IBM HTTP Server (IHS) V7.0 is based on Apache HTTP Server 2.2.8. Therefore we can use the Apache documentation as well to configure the IHS as it is identical to a very high degree. The following links provide the detailed Apache documentation for the directives and a quick description of the functionality these provide:
For IHS v6.1 see: http://httpd.apache.org/docs/2.0/mod/quickreference.html
For IHS v7.0 see: http://httpd.apache.org/docs/2.2/mod/quickreference.html
The full documentation for the IHS can be found in the WAS InfoCenter of the relevant release. For IHS v7.0 it can be found at: http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.ihs.doc/info/ihs/ihs/welcome_ihs.html
Pre-Requisites
You must successfully have finished the following labs in order to run this lab:
none
Lab setup instructions
Perform the following steps to setup for the lab:
This lab instructions assume that the IHS server is installed and accessed from the local system.
Download the WebSphere application server supplemental CD-1
Unzip the file to a temporary location
Change to the IHS sub-directory of the directory to which you unzipped the downloaded file
Run the following installation command:
./install -silent -OPT silentInstallLicenseAcceptance="true" -OPT installType="installNew" -OPT installLocation="/opt/IBM/HTTPServer" -OPT feature="noFeature" -OPT httpPort="80" -OPT adminPort="8008" -OPT createAdminAuth="true" -OPT adminAuthUser="h0000a" -OPT adminAuthPassword="start123." -OPT adminAuthPasswordConfirm="start123." -OPT runSetupAdmin="true" -OPT createAdminUserGroup=true -OPT setupAdminUser="h0000a" -OPT setupAdminGroup="h0000g" -OPT installPlugin="false" -OPT disableOSPrereqChecking="true"
Verify the successful installation by checking the log.txt file (look for INSTCONFSUCCESS at the end) in directory: /opt/IBM/HTTPServer/logs/install/
Take a backup copy of the original config file: cp -p /opt/IBM/HTTPServer/conf/httpd.conf /opt/IBM/HTTPServer/conf/httpd.conf.install
It's recommended to upgrade the IHS to the latest fixpack using standard upgrade procedures
Start the IHS server by running: /opt/IBM/HTTPServer/bin/apachectl start
The lab instructions were written to be executed on the local workstation. Therefore URL references are using “localhost”. If your run the lab on a remote server it's therefore required to replace the hostname in the URLs accordingly!
Tips and tricks
The following hints might be helpful for you to run this lab and hopefully in your daily job.
Starting IHS
To start the IHS run the following command:
/opt/IBM/HTTPServer/bin/apachectl [start|restart|graceful]
See: http://httpd.apache.org/docs/2.2/stopping.html for details of the various options
Stopping IHS
To stop the IHS run the following command:
/opt/IBM/HTTPServer/bin/apachectl [stop|graceful-stop]
See: http://httpd.apache.org/docs/2.2/stopping.html for details of the various options
Starting/Stopping multiple instances of IHS
If you want to run multiple instances of an IHS server (with different configurations) you can use the -f option to specify the configuration file to be used for starting the server (default is: conf/httpd.conf).
/opt/IBM/HTTPServer/bin/apachectl -f /opt/IBM/HTTPServer/conf/h01.conf [start|restart|graceful|stop|graceful-stop]
/opt/IBM/HTTPServer/bin/apachectl -f /opt/IBM/HTTPServer/conf/h02.conf [start|restart|graceful|stop|graceful-stop]
Determining the server process status
To check the status of the processes you can run:
ps -ef | grep httpd
netstat -an | grep "801\ " | grep LISTEN
ps -ef | grep $(cat /opt/IBM/HTTPServer/logs/httpd.pid2)
Verification of the configuration
Once you updated the configuration it is recommended and a good practice to run a “configtest” before restarting the server to ensure that the configuration is basically correct.
/opt/IBM/HTTPServer/bin/apachectl configtest
Restart IHS after configuration change
Be reminded that modifications of the directives in the HTTP servers configuration file require a restart of the server. Depending on directive being changed it must be a full restart or a graceful restart might be sufficient.
Make sure that proper authorities are set
When handling files being served by the IHS always keep in mind that – although the parent process is is started and running as root – the child processes what are serving the requests run under a different user (configured via Directive User in httpd.cond)! Therefore the user the child processes are running under must have read access to the files and directories!
Take a backup of the configuration
It's generally a best practice to ensure that you have a valid backup of the configuration file(s) before you start making changes. This allows you to restore to the original configuration in case something goes wrong!
Disable browser cache for testing
During running this lab (and whenever you are developing an IHS configuration it is highly recommended to disable any sort of browser cache for testing! Otherwise you might not see correct results as requests will be served out of the cache instead of being sent to the server.
Usage of privileged ports
When starting the HTTP server you must be aware that on Unix based operating systems only root can open (i.e. set to LISTEN state) privileged ports i.e. ports below 1024! Therefore if your HTTP servers listens on port 80 it must be started as root.
Using the “telnet” test
Sometimes it's quite useful make a quick test about the servers availabilty using telnet. Here is an example! (blue text is input from the keyboard)
[at022405@hhuelinux ~]$ telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET / HTTP/1.1
Host: localhost
HTTP/1.1 200 OK
Date: Mon, 20 Dec 2010 11:37:46 GMT
Server: IBM_HTTP_Server
Content-Length: 1125
Content-Type: text/html;charset=ISO-8859-1
Index of /
IBM_HTTP_Server at localhost Port 80Name Last modified Size Description
file1.1.txt 16-Dec-2010 16:53 38
sub1/ 16-Dec-2010 17:25 -
Determining what process listens on a port
On AIX you can use the following commands to determine which process is listening on a socket:
netstat -Aan -f inet | grep LISTEN | grep
→ the first column is the socket number
rmsock
tcpcb
→ this gives the PID of the process which holding the port
On Linux you can use the “lsof” command to determine the listening process.
Enabling IHS server-status display
The IHS server provides the ability to track the server status in more detail via the server-status handler. This allows you to get in-dept information about the server-threads etc.
You need to configure that feaure in httpd.conf by configuring the following (directives are most likely already in httpd.conf) :
Make sure the mod_status is loaded
LoadModule status_module modules/mod_status.so
Enable the ExtendedStatus
ExtendedStatus On
Adjust Allow rule for the /server-status location
SetHandler server-status
Order deny,allow
Deny from all
Allow from 127.0.0.1 9 158.98.125.71
Access the /server-status URL
http://
The Lab starts here
Evaluate the following Apache directives in this exercises. Please contact any of the mentors in case you have troubles with the lab or with understanding any of the directives. For all exercises we'll use the default configuration file /opt/IBM/HTTPServer/conf/httpd.conf
DocumentRoot | |
Description | Defines the directory on the OS level what is the root directory visible for the web |
Web-Link | |
Default | |
Instructions-1 |
mkdir /opt/IBM/HTTPServer/htdocs/sub1/ echo "File-1 in default DocumentRoot direcory" > /opt/IBM/HTTPServer/htdocs/file1.txt echo "File-2 in default DocumentRoot sub-direcory sub1 " > /opt/IBM/HTTPServer/htdocs/sub1/file2.txt |
Verification-1 |
http://localhost/sub1/file2.txt The URLs should open correctly and the expected text should be shown.
This URL should open a directory listing of the sub1 subdirectory. |
Instructions-2 |
cp -p httpd.conf httpd.conf.ori
mkdir /opt/IBM/HTTPServer/myHtDocs
Replace: DocumentRoot "/opt/IBM/HTTPServer/htdocs" with DocumentRoot "/opt/IBM/HTTPServer/myHtDocs"
|
Verification-2 |
http://localhost/sub1/file2.txt These URLs should result in an error (
|
Instructions-3 |
mkdir /opt/IBM/HTTPServer/myHtDocs/sub1/ echo "File-1.1 in NEW DocumentRoot direcory" > /opt/IBM/HTTPServer/myHtDocs/file1.txt echo "File-2.1 in NEW DocumentRoot sub-direcory sub1 " > /opt/IBM/HTTPServer/myHtDocs/sub1/file2.txt echo "File-3.1 in NEW DocumentRoot sub-direcory sub1 " > /opt/IBM/HTTPServer/myHtDocs/sub1/newDocRoot.txt echo "This is a file containing content in English" > /opt/IBM/HTTPServer/myHtDocs/langfile.txt.en echo "Diese Datei beinhaltet deutschen Text" > /opt/IBM/HTTPServer/myHtDocs/langfile.txt.de |
Verification-3 |
http://localhost/sub1/file2.txt
Both URLs should now
|
Instructions-4 |
Search for “htdocs” und you should find:
|
Verification-4 |
http://localhost/sub1/file2.txt
Both URLs should still work
This URL should now open a directory listing of the sub1 subdirectory inside the NEW DocumentRoot |
Comments |
|
ServerRoot | |
Description | This directive defines the Base directory of the OS for the server installation. All relative directory or file references in the configuration file are relative to the directory specified in this directive. |
Web-Link | http://httpd.apache.org/docsin/2.2/mod/core.html#serverroot |
Default | The value given by the “-OPT installLocation” parameter during install! |
Instructions-1 |
|
Verification-1 |
What is the result? |
Instructions-2 |
mkdir /opt/IBM/HTTPServerx |
Verification-2 |
What is the result now? Why? Write down two ways to fix the problems! |
Instructions-3 |
|
Verification-3 |
|
Instructions-4 |
|
Verification-4 |
|
Comments |
|
LoadModule | |
Description | IHS is based on the Apache web server what is following modular design principle. There is a core functionality provided what can / must be enhanced by additional modules. Each module provides it's associated directives and only directives provided by active (i.e loaded) modules can be used in the configuration.
Basically all modules delivered with the product are in the configuration however many of them are under comment (i.e. preceeded by a “#”). To activate the module just remove the “#” preceeding the proper “LoadModule” directive. |
Web-Link | |
Default | Multiple modules are loaded by default |
Instructions-1 |
|
Verification-1 |
|
Instructions-2 |
|
Verification-2 |
|
Instructions-3 |
|
Verification-3 |
|
Instructions-4 |
|
Verification-4 |
|
Comments |
|
CustomLog | |
Description | This directive sets file name and format of the access_log file. The file-name can be either a file name in the file-system or a pipe i.e. a pipe symbol “|” followed by a program to receive the log-records on stdin. Although the format can be specified directly in the CustomLog directive this is not a good practice. Instead use the Directives to define a nickname and to use the nickname in the CustomLog directive. |
Web-Link | http://httpd.apache.org/docs/2.2/mod/mod_log_config.html#customlog http://httpd.apache.org/docs/2.2/mod/mod_log_config.html#formats |
Default | |
Instructions-1 |
|
Verification-1 |
What data field corresponds to which Format String? |
Instructions-2 |
CustomLog "|/opt/IBM/HTTPServer/bin/rotatelogs /opt/IBM/HTTPServer/logs/access_log.%Y_%m_%d_%H_%M_%S 120" combined
|
Verification-2 |
http://localhost/sub1/file2.txt
You'll see that another file access_log.2010_12_17_10_12_00 was created containing the access log data.
What happened now?
We are now using the pipe configuration of CustomLog directive. I.e. the access log data are not written to a file directly. Instead the log data are sent to a pipe what is the stdin for the “rotatelogs” program. Using “rotatelogs” we can configure automatic logfile rotation based on intervals (in seconds) or size. See the documentation of the rotatelogs program at: http://httpd.apache.org/docs/2.0/programs/rotatelogs.html for more details.
|
Instructions-3 |
|
Verification-3 |
What data field corresponds to which Format String? Which fields are only in the combined LogFormat but not in the CustomLog format? |
Instructions-4 |
|
Verification-4 |
|
Comments | The rotate logs program is a perfect tool to have IHS the logs rotated automatically and therefore prepare old logs for archiving.
Rotating logs in 120 seconds intervals usually does not make sense! In the real world logs are usually rotated once a day or based on size.
To rotate the logs once a day you specify: CustomLog "|/opt/IBM/HTTPServer/bin/rotatelogs /opt/IBM/HTTPServer/logs/access_log.%Y_%m_%d_%H_%M_%S 864005" |
ErrorLog | |
Description | This directive sets file name of the error_log file i.e. the file to which the server logs errors. The file-name can be either a file name in the file-system or a pipe i.e a pipe symbol “|” followed by a program to receive the log-records on stdin. |
Web-Link | http://httpd.apache.org/docs/2.2/mod/core.html#errorlog |
Default | ErrorLog logs/error_log |
Instructions-1 |
|
Verification-1 |
What did we achieve my using rotate logs here? |
Instructions-2 |
|
Verification-2 |
|
Instructions-3 |
|
Verification-3 |
|
Instructions-4 |
|
Verification-4 |
|
Comments | The rotate logs program is a perfect tool to have IHS the logs rotated automatically and therefore prepare old logs for archiving. Therefore the instructions in “Instructions-1” can be used to have the error log of the IHS rotated on a daily basis.
|
LogFormat | |
Description | This directive describes a format for use in a log file i.e. using this directive you can control what attributes related to the the request will be written to the logfiles. |
Web-Link | http://httpd.apache.org/docs/2.2/mod/mod_log_config.html#logformat http://httpd.apache.org/docs/2.2/mod/mod_log_config.html#formats |
Default | LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined LogFormat "%h %l %u %t \"%r\" %>s %b" common LogFormat "%{Referer}i -> %U" referer LogFormat "%{User-agent}i" agent
Note: There are multiple predefined Directives |
Instructions-1 |
What is the active LogFormat? |
Verification-1 |
|
Instructions-2 |
What are the additional fields we are adding here?
CustomLog "|/opt/IBM/HTTPServer/bin/rotatelogs /opt/IBM/HTTPServer/logs/access_log.%Y_%m_%d_%H_%M_%S 86400" combined_coe
|
Verification-2 |
http://localhost/sub1/file2.txt
What is the second but last field in the access_log? What is the unit of that field? Why is the last entry in the logfile “-”? |
Instructions-3 |
|
Verification-3 |
|
Instructions-4 |
|
Verification-4 |
|
Comments | Care must be taken is tools are used to analyze the logs (access-logs) of the HTTP server. Usually tools understand the two pre-definied logformats combined & common. It's a good practice to enhance these logformats only by adding the required attributes at the end. |
|
|
AddLanguage | |
Description | This directive can be used to map a given file extension to a specific content language. Therefore this directive can be used to serve content based on the clients browser language settings |
Web-Link | http://httpd.apache.org/docs/2.2/mod/mod_mime.html#addlanguage |
Default |
|
Instructions-1 | While performing the instructions for the exercises we created some language specific files we will use now for testing.
If the directive is not there you can basically add the following instructions anywhere however as the AddLanguage directive is provided via mod_mime and therefore it's a good practice to keep directives of the same module together. Therefore in our lab we'll search for “AddType” and add the following directives after the “AddType” directives:
Note: In the exercise we created files with the “.de” and “.en” extension. This “.de” and “.en” extension must match the file extension given in the “AddLanguage” directive.
|
Verification-1 |
|
Instructions-2 |
|
Verification-2 | You should get a page with the content: This is a file containing content in English
|
Instructions-3 |
|
Verification-3 |
|
Instructions-4 |
|
Verification-4 |
|
Comments | In this exercise we learned what needs to be done to enable the automatic content selection in the browser based on the language settings of the end-user.
See http://httpd.apache.org/docs/2.2/content-negotiation.html for a full documentation about alternative configuration options to deliver the best representation of a requested resource. |
Allow | |
Description | This directive controls which hosts can access an area (directory, virtual host, proxy etc.) of the server. Access can be controlled by hostname, IP address, IP address range, or by other characteristics of the client request captured in environment variables.
Access control to server areas is basically controlled via the following three directives: , and |
Web-Link | http://httpd.apache.org/docs/2.2/mod/mod_authz_host.html#allow |
Default |
|
Instructions-1 |
As per the default configuration for the DocumentRoot the server can be accessed from every client. |
Verification-1 | From the previous lab exercises we know that this is working so we don't need additional verification here. |
Instructions-2 |
Allow from 9
|
Verification-2 |
Tip: Check the access_log file of the HTTP server!
Trick: you can simulate access to a specific interface by opening a tunnel on the local workstation to port 80 on the local workstation: ssh -L8088:
http://localhost:8088/langfile.txt
Why is the access working now?
Tip: Check the access_log file of the HTTP server! |
Instructions-3 | Now let's grant access from the loopback interface as well as from the IBM intranet.
|
Verification-3 |
|
Instructions-4 |
|
Verification-4 |
|
Comments |
|
Deny | |
Description | This directive controls which hosts are denied to access an area (directory, virtual host, proxy etc.) of the server. The arguments the Deny directive takes are the same as Allow.
Access control to server areas is basically controlled via the following three directives: , and |
Web-Link | http://httpd.apache.org/docs/2.2/mod/mod_authz_host.html#deny |
Default |
|
Instructions-1 |
|
Verification-1 |
Tip: Checkout the “Order” directive. See for more information |
Instructions-2 |
|
Verification-2 |
|
Instructions-3 |
|
Verification-3 |
|
Instructions-4 |
|
Verification-4 |
|
Comments |
|
Order | |
Description | The “Order” directive controls the access state and the order in which the and rules are evaluated.
Keep in mind that all effective Allow/Deny rules are evaluated and that the last match is effective (what is very different to the usual firewall evaluation policy) |
Web-Link | http://httpd.apache.org/docs/2.2/mod/mod_authz_host.html#order |
Default |
|
Instructions-1 |
The Order, Allow, Deny block looks like the following at the moment:
Order allow,deny Deny from all Allow from 9 127
This basically ,means that first the “Allow” directives are evaluated what would grant access to all requests from the network 9 and 127 however in a second step the “Deny” is evaluated (all) and therefore no one can access the content in directory "/opt/IBM/HTTPServer/myHtDocs".
Order deny,allow
|
Verification-1 |
|
Instructions-2 |
|
Verification-2 |
|
Instructions-3 |
|
Verification-3 |
|
Instructions-4 |
|
Verification-4 |
|
Comments | Via the directives , and we can quite specifically control from what networks specific areas of the server are accessible and therefore an easy to implement form of access control. |
Options | |
Description | The “Options” directive configures what features are available in a particular directory. This directive allows the following options (check the provided Web-Link for details):
|
Web-Link | http://httpd.apache.org/docs/2.2/mod/core.html#options |
Default |
|
Instructions-1 | We'll use the Options directive in the subsequent exercises → no specific instructions here! |
Verification-1 |
|
Instructions-2 |
|
Verification-2 |
|
Instructions-3 |
|
Verification-3 |
|
Instructions-4 |
|
Verification-4 |
|
Comments |
|
Description | The
Read the provided links in details to figure out how multiple matching
While |
Web-Link | http://httpd.apache.org/docs/2.2/mod/core.html#directory http://httpd.apache.org/docs/2.2/mod/core.html#directorymatch |
Default |
|
Instructions-1 |
|
Verification-1 | You will get a directory listing of the sub1 sub-directory. This you will get because there is the “Options Indexes FollowSymLinks MultiViews” set in the “ |
Instructions-2 |
Add he following stanza after the matching directive:
Options -Indexes 7
|
Verification-2 |
|
Instructions-3 |
|
Verification-3 |
|
Instructions-4 |
|
Verification-4 |
|
Comments |
|
DirectoryIndex | |
Description | The “DirectoryIndex” directive sets the the list of resources (file-names) to look for when the client is accessing a directory (i.e. the URL requested ends with a “/”. Therefore the file name given here is also known as index-file or welcome-file.
If no “DirectoryIndex” exists and the default index.html can't be found the user gets an 403 error (forbidden) when he accesses a directory unless “Options Indexes” is in place for the directory and mod_autoindex is loaded. |
Web-Link | http://httpd.apache.org/docs/2.2/mod/mod_dir.html#directoryindex |
Default | DirectoryIndex index.html index.html.var |
Instructions-1 |
cat << EOT > /opt/IBM/HTTPServer/myHtDocs/sub1/index.html
This is the index.html of /sub1
EOT
|
Verification-1 |
|
Instructions-2 |
cat << EOT > /opt/IBM/HTTPServer/myHtDocs/sub1/welcome.html
This is the welcome.html of /sub1
EOT
cat << EOT > /opt/IBM/HTTPServer/myHtDocs/welcome.html
This is the welcome.html of /
EOT
|
Verification-2 |
|
Instructions-3 |
rm -f /opt/IBM/HTTPServer/myHtDocs/welcome.html /opt/IBM/HTTPServer/myHtDocs/sub1/welcome.html |
Verification-3 |
|
Instructions-4 |
|
Verification-4 |
|
Comments | In the exercise we saw that the access to http://localhost/sub1/ failed because the “Indexes” option was deactivated via the directive “Options -Indexes”. |
Description | The
While |
Web-Link | |
Default |
|
Instructions-1 |
|
Verification-1 |
|
Instructions-2 |
|
Verification-2 |
|
Instructions-3 |
|
Verification-3 |
|
Instructions-4 |
|
Verification-4 |
|
Comments |
|
User and Group | |
Description | The “User” and “Group” directives are used to define the OS level run-time user and group attributes as which the server will serve the requests.
It is highly recommended to use a specific user/group for the HTTP server (not even nobody) and make sure that the user does not have any access to files except to those intended for the outside world (and read-only to those intended to be served). It's your responsibility to make sure that the user has just the right access rights to serve the content.
Note: The server must be started as root to allow using these directives Note: As the server will be started as root the parent process will still be running as root however the other processes will be running as the user specified in these directives |
Web-Link | |
Default | User nobody Group nobody |
Instructions-1 |
ps -ef | grep httpd | grep -v grep |
Verification-1 | Your output should be similar to the following:
[root@hhuelinux conf]# ps -ef | grep httpd | grep -v grep nobody 8363 10667 0 12:18 ? 00:00:00 /opt/IBM/HTTPServer/bin/httpd -d /opt/IBM/HTTPServer -k restart nobody 8364 10667 0 12:18 ? 00:00:01 /opt/IBM/HTTPServer/bin/httpd -d /opt/IBM/HTTPServer -k restart nobody 8365 10667 0 12:18 ? 00:00:00 /opt/IBM/HTTPServer/bin/httpd -d /opt/IBM/HTTPServer -k restart nobody 8394 10667 0 12:18 ? 00:00:00 /opt/IBM/HTTPServer/bin/httpd -d /opt/IBM/HTTPServer -k restart root 10667 1 0 08:57 ? 00:00:00 /opt/IBM/HTTPServer/bin/httpd -d /opt/IBM/HTTPServer -k restart
and match your settings in httpd.conf: [root@hhuelinux conf]# cat httpd.conf | grep -E "^User|^Group" User nobody Group nobody
|
Instructions-2 |
groupadd zcoeihs useradd -M -g zcoeihs -c "z-Coe IHS user" zcoeihs
User zcoeihs Group zcoeihs
|
Verification-2 | Determine the current user being used for the running process by running: ps -ef | grep httpd | grep -v grep
Your output should be similar to the following:
root@hhuelinux HTTPServer]# ps -ef | grep httpd | grep -v grep root 10667 1 0 08:57 ? 00:00:00 /opt/IBM/HTTPServer/bin/httpd -d /opt/IBM/HTTPServer -k restart zcoeihs 29544 10667 0 14:46 ? 00:00:00 /opt/IBM/HTTPServer/bin/httpd -d /opt/IBM/HTTPServer -k restart zcoeihs 29545 10667 0 14:46 ? 00:00:00 /opt/IBM/HTTPServer/bin/httpd -d /opt/IBM/HTTPServer -k restart zcoeihs 29546 10667 0 14:46 ? 00:00:00 /opt/IBM/HTTPServer/bin/httpd -d /opt/IBM/HTTPServer -k restart zcoeihs 29585 10667 0 14:47 ? 00:00:00 /opt/IBM/HTTPServer/bin/httpd -d /opt/IBM/HTTPServer -k restart
|
Instructions-3 |
|
Verification-3 |
|
Instructions-4 |
|
Verification-4 |
|
Comments |
|
Description | The
This gives you some flexibility in writing your configurations or in preparing configuration artifacts you can include via the “” directive. |
Web-Link | |
Default |
|
Instructions-1 |
|
Verification-1 |
|
Instructions-2 |
|
Verification-2 |
|
Instructions-3 |
|
Verification-3 |
|
Instructions-4 |
|
Verification-4 |
|
Comments |
|
Include | |
Description | The “Include” directive allows you to include other files into the mail configuration file (httpd.conf). This allows you to split the configuration in multiple artifacts and avoid redundancy in the configuration (for example if you have specific settings you need in multiple VirtualHosts or Directory stanzas). The file name included can contain OS specific wild-cards hence multiple files might be included via one directive. |
Web-Link | |
Default |
|
Instructions-1 |
RewriteEngine on RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK) RewriteRule .* - [F]
Include conf/disable_trace.conf
|
Verification-1 | You will see that the restart of the server fails – WHY? |
Instructions-2 |
RewriteEngine on RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK) RewriteRule .* - [F]
|
Verification-2 | Does the server start now? What's the difference? What's the problem with that 'soliution'? |
Instructions-3 |
LoadModule rewrite_module modules/mod_rewrite.so
|
Verification-3 |
|
Instructions-4 |
|
Verification-4 | You can use the “telnet” test () using the GET method first to see if the server serves requests.
Now use the “telnet” test using the TRACE method to test if the rewrite rule is really active. If it's active you should get a “403 Forbidden” response.
|
Comments |
|
Description | The
The
The
Note: the
Note: |
Web-Link | |
Default |
|
Instructions-1 |
RewriteEngine on RewriteRule ^.*$ http://www.google.at/search?q=locationmatch [R,L]
|
Verification-1 |
This should work fine and you should see the following text displayed: File-1.1 in new DocumentRoot direcory
http://localhost/sub1/file1.1.txt What happens now? Why?
|
Instructions-2 |
|
Verification-2 |
|
Instructions-3 |
|
Verification-3 |
|
Instructions-4 |
|
Verification-4 |
|
Comments |
|
ServerName | |
Description | This directive in the global server configuration is used to define the name the server uses to identify itself. This name will be used for any error, redirect pages or self-referring URLs the server builds. If no “ServerName” is provided the server tries to detect one by running a reverse DNS lookup of the IP address. If the server is behind some kind of proxy make sure to configure the “ServerName” is a way so that the URLs generated by the server work for the clients.
When name-based virtual hosts are configured and used inside a “” directive the “ServerName” directive is used to define which hostname must appear in the “Host:” request header to match this virtual host. |
Web-Link | |
Default | Generated during the installation of IHS |
Instructions-1 |
|
Verification-1 |
|
Instructions-2 |
|
Verification-2 |
|
Instructions-3 |
|
Verification-3 |
|
Instructions-4 |
|
Verification-4 |
|
Comments |
|
Description |
Each Virtual Host must correspond to a different IP address, different port number or a different host name for the server, in the former case the server machine must be configured to accept IP packets for multiple addresses (either real interface or aliased).
Note:The IP address specified here is an IP address of a local interface of the server. Keep in mind that this IP address might be different from the IP address used by the client (due to NAT, Proxy, etc.)
Typical scenarios when using VirtualHost stanzas are
The address provided can be any of the following:
|
Web-Link | |
Default |
|
Instructions-1 | In this exercise we'll configure SSL for our server. First we need to create a key database and – for simplicity and to save money – we'll create a self-signed certificate.
cd /opt/IBM/HTTPServer/bin ./gsk7cmd1011 -keydb -create -db /tmp/coe_keys.kdb -pw start123. -type cms -expire 3650 -stash ./gsk7cmd -cert -create -db /tmp/coe_keys.kdb -pw start123. -label localhost -size 1024 -default_cert no -expire 1095 -dn "CN=localhost,OU=CoE,O=IBM India Pvt.,L=Bangalore,ST=Karnataka,C=IN" ./gsk7cmd -cert -create -db /tmp/coe_keys.kdb -pw start123. -label coetest -size 1024 -default_cert no -expire 1095 -dn "CN=coetest,OU=CoE,O=IBM India Pvt.,L=Bangalore,ST=Karnataka,C=IN" cp -p /tmp/coe_keys.* /opt/IBM/HTTPServer/conf/
|
Verification-1 |
cd /opt/IBM/HTTPServer/bin ./gsk7cmd -cert -details -db /opt/IBM/HTTPServer/conf/coe_keys.kdb -pw start123. -type cms -label localhost
Label: localhost Key Size: 1024 Version: X509 V3 Serial Number: 4D 10 2A 2B Issued by: CN=localhost, OU=CoE, O=IBM India Pvt., L=Bangalore, ST=Karnataka, C=IN Subject: CN=localhost, OU=CoE, O=IBM India Pvt., L=Bangalore, ST=Karnataka, C=IN Valid: From: Tuesday, December 21, 2010 9:46:43 AM GMT+05:30 To: Friday, December 20, 2013 9:46:43 AM GMT+05:30 Fingerprint: FB:BE:0F:71:E9:3F:4B:CB:CF:BD:0B:9D:B1:BD:B5:64:1A:11:0D:3F Signature Algorithm: SHA1withRSA (1.2.840.113549.1.1.5) Trust Status: enabled |
Instructions-2 | The second step to enable SSL is to add the required configuration directives to the httpd.conf file.
################################################################ ## Start SSL global config ################################################################ Listen 443 LoadModule ibm_ssl_module modules/mod_ibm_ssl.so Keyfile /opt/IBM/HTTPServer/conf/coe_keys.kdb SSLStashfile /opt/IBM/HTTPServer/conf/coe_keys.sth SSLV2Timeout 100 SSLV3Timeout 1000 SSLCacheEnable SSLCachePortFilename /opt/IBM/HTTPServer/logs/siddfile SSLCachePath /opt/IBM/HTTPServer/bin/sidd SSLCacheErrorLog /opt/IBM/HTTPServer/logs/sidd_log SSLDisable
ErrorLog "| /opt/IBM/HTTPServer/bin/rotatelogs /opt/IBM/HTTPServer/logs/default_ssl.error.%Y_%m_%d 86400" SSLEnable SSLClientAuth none SSLServerCert localhost CustomLog "|/opt/IBM/HTTPServer/bin/rotatelogs /opt/IBM/HTTPServer/logs/default_ssl_access_log.%Y_%m_%d_%H_%M_%S 86400" combined_coe
# disable TRACE method – Required on IHS V6.1 and before. For V7.0 and later use “TraceEnable Off” Include /opt/IBM/HTTPServer/conf/disable_trace.conf
################################################################ ## End SSL global config ################################################################
### NameVirtualHost 127.0.0.1:80 ### NameVirtualHost 127.0.0.1:443 ### ### ### ServerName localhost:80 CustomLog "|/opt/IBM/HTTPServer/bin/rotatelogs /opt/IBM/HTTPServer/logs/localhost_80_access_log.%Y_%m_%d_%H_%M_%S 86400" combined_coe
# disable TRACE method – Required on IHS V6.1 and before. For V7.0 and later use “TraceEnable Off” Include /opt/IBM/HTTPServer/conf/disable_trace.conf
ServerName coetest:80 CustomLog "|/opt/IBM/HTTPServer/bin/rotatelogs /opt/IBM/HTTPServer/logs/coetest_80_access_log.%Y_%m_%d_%H_%M_%S 86400" combined_coe
# disable TRACE method – Required on IHS V6.1 and before. For V7.0 and later use “TraceEnable Off” Include /opt/IBM/HTTPServer/conf/disable_trace.conf
ServerName localhost:443 CustomLog "|/opt/IBM/HTTPServer/bin/rotatelogs /opt/IBM/HTTPServer/logs/localhost_443_access_log.%Y_%m_%d_%H_%M_%S 86400" combined_coe
SSLEnable SSLClientAuth none SSLServerCert localhost
# disable TRACE method – Required on IHS V6.1 and before. For V7.0 and later use “TraceEnable Off” Include /opt/IBM/HTTPServer/conf/disable_trace.conf
ServerName coetest:443 CustomLog "|/opt/IBM/HTTPServer/bin/rotatelogs /opt/IBM/HTTPServer/logs/coetest_443_access_log.%Y_%m_%d_%H_%M_%S 86400" combined_coe
SSLEnable SSLClientAuth none SSLServerCert coetest
# disable TRACE method – Required on IHS V6.1 and before. For V7.0 and later use “TraceEnable Off” Include /opt/IBM/HTTPServer/conf/disable_trace.conf
Note: During stopping (or configtest / start) of the server you'll get a waring like the following: “[Wed Dec 22 09:44:30 2010] [warn] VirtualHost 127.0.0.1:443 overlaps with VirtualHost 127.0.0.1:443, the first has precedence, perhaps you need a NameVirtualHost directive [Wed Dec 22 09:44:30 2010] [warn] VirtualHost 127.0.0.1:80 overlaps with VirtualHost 127.0.0.1:80, the first has precedence, perhaps you need a NameVirtualHost directive ”. → For the time being let's ignore these warnings.
|
Verification-2 |
This should work fine and you should see the following text displayed: File-1.1 in new DocumentRoot direcory
At the first access you'll get a warning that the connection is untrusted because we are using a self-signed certificate. The way that looks like very much depends on the browser. Firefox gives a pretty straight information saying: “The certificate is not trusted because it is self-signed.”
As we know that this is expected (and nobody tried to compromise the server) we can add an exception for hat and should see the following text displayed12: File-1.1 in new DocumentRoot direcory
Why do we see that different log files are used?
Again you'll get a warning that the connection is untrusted because we are using a self-signed certificate. However note that there are two reasons for the warniung now namely: “The certificate is not trusted because it is self-signed.” “The certificate is only valid for localhost”
i.e. there are two reasons now why the connection is untrusted!
Add an exception for that and should see the following: File-1.1 in new DocumentRoot direcory
|
Instructions-3 |
|
Verification-3 |
|
Instructions-4 |
|
Verification-4 |
|
Comments |
|
NameVirtualHost | |
Description | The “NameVirtualHost” directive marks an IP address for being used as namebased virtual host. For the specification of the IP address it's advised not to use names but IP addresses.
Virtual hosts are used in environments in which multiple web-sites are running on a single server. The sites can be identified either via different IP addresses (i.e. you need one IP address by site) – that is what we are using by the “VirtualHost” directive. Another way to differentiate the requests for the different sides is by using the “Host:” field in the HTTP Request header. This method allows to use the same ip address for multiple sites however is transparent to the end-user. That is what requires the usage of the “NameVirtualHost” directive.
Note: Using the same IP address for multiple sites does not work when SSL is being used. In this case the first Entry (with the associated certificate) will be used!! Note: If none of the “ |
Web-Link | http://httpd.apache.org/docs/2.2/mod/core.html#namevirtualhost |
Default |
|
Instructions-1 | In the “VirtualHost” lab we added quite a few directives to the httpd.conf to enable SSL for the server. Furthermore we configured multiple virtual hosts. However since then we are getting warnings regarding the configuration – why? In the next steps we are going to resolve these issues. Perform the following steps for that:
### NameVirtualHost 127.0.0.1:80 ### NameVirtualHost 127.0.0.1:443
|
Verification-1 |
/opt/IBM/HTTPServer/bin/apachectl configtest What is the result now? Why? |
Instructions-2 |
|
Verification-2 |
This should work fine and you should see the following text displayed: File-1.1 in new DocumentRoot direcory
Again you'll get a warning that the connection is untrusted because we are using a self-signed certificate. However note that there are two reasons for the warniung now namely: “The certificate is not trusted because it is self-signed.” “The certificate is only valid for localhost”
i.e. there are two reasons now why the connection is untrusted!
Add an exception for that and should see the following: File-1.1 in new DocumentRoot direcory
Why is still the same logfile used? |
Instructions-3 |
coetest coealias1 coealias2 |
Verification-3 |
|
Instructions-4 |
|
Verification-4 |
Again you'll get a warning that the connection is untrusted because we are using a self-signed certificate. However note that there are two reasons for the warniung now namely: “The certificate is not trusted because it is self-signed.” “The certificate is only valid for localhost”
i.e. there are two reasons now why the connection is untrusted!
Why does IHS send the certificate for localhost instead of the certificate for coetest?
Add an exception for that and should see the following: File-1.1 in new DocumentRoot direcory
Why is the coetest_443 logfile used now? |
Instructions-5 |
|
Verification-5 |
|
Comments |
|
ServerAlias | |
Description | The “ServerAlias” directive allows to define multiple alternative host-names for a name-based virtual host. Therefore one name-based virtual host definition can be used for multiple host-names. When using “ServerAlias” directive in a name-based virtual host definition it might be required to use “UseCanonicalName Off” in conjunction. |
Web-Link | |
Default |
|
Instructions-1 |
ServerName localhost:80 : :
ServerAlias coealias1 UseCanonicalName Off
ServerName coetest:80 : :
ServerAlias coealias2 UseCanonicalName Off
|
Verification-1 |
All the requests above should work fine and you should see the following text displayed: File-1.1 in new DocumentRoot direcory
|
Instructions-2 |
|
Verification-2 |
|
Instructions-3 |
|
Verification-3 |
|
Instructions-4 |
|
Verification-4 |
|
Comments |
|
Alias and AliasMatch | |
Description | The “Alias” directive allows for mapping of URLs to filesystem paths.
The “AliasMatch” directive is similar to “Alias” except for the fact that this directive supports regular expression (regex) matching/substitution. |
Web-Link | http://httpd.apache.org/docs/2.2/mod/mod_alias.html#alias http://httpd.apache.org/docs/2.2/mod/mod_alias.html#aliasmatch |
Default | |
Instructions-1 |
mkdir /opt/IBM/HTTPServer/myAliases/
mkdir /opt/IBM/HTTPServer/myAliases/aliasmatch1/ mkdir /opt/IBM/HTTPServer/myAliases/aliasmatch2/ mkdir /opt/IBM/HTTPServer/myAliases/aliasmatch3/
echo "Alias Directive - Lab" > /opt/IBM/HTTPServer/myAliases/example.txt
echo "AliasMatch Directive - 1" > /opt/IBM/HTTPServer/myAliases/aliasmatch1/example.txt echo "AliasMatch Directive - 2" > /opt/IBM/HTTPServer/myAliases/aliasmatch2/example.txt echo "AliasMatch Directive - 3" > /opt/IBM/HTTPServer/myAliases/aliasmatch3/example.txt
|
Verification-1 |
|
Instructions-2 |
Alias /aliasexample /opt/IBM/mystatic
Note: If you use “Alias” directive for creating an alias to a directory outside the directory defined by DocumentRoot directive, then you will have to use
|
Verification-2 |
http://localhost/aliasexample/example.txt
|
Instructions-3 |
AliasMatch ^/aliasmatch(.*) /opt/IBM/HTTPServer/myAliases/aliasmatch$1
NOTE: $1 here would be replaced in runtime by the pattern that matches the regular expression (regex)
$2,$3 etc can be used if you have two regex, three regex, etc...
For example, To map http://www.coelab.com/coe/
AliasMatch ^/coe/([^/]*)/?(.*) /home/$1/public_html/$2
|
Verification-3 |
http://localhost/aliasmatch1/example.txt http://localhost/aliasmatch2/example.txt http://localhost/aliasmatch3/example.txt |
Instructions-4 |
|
Verification-4 |
http://localhost/aliasmatch111/example.txt
What happens? Why? |
Comments | Spend time to understand regular expressions (regex) and play around with different regex in your “AliasMatch” directive. |
WebSpherePluginConfig | |
Description | This directive is used when you would like to point your webserver to applications running on WAS.
Please note that before this directive can be used, mod_was_ap22_http.so module will have to be loaded using “LoadModule” directive.
mod_was_ap22_http.so module is delivered thru the IBM WebSphere Plugin Installation
Sample Configuration:- LoadModule was_ap22_module / WebSpherePluginConfig / |
Web-Link | |
Default |
|
Instructions-1 |
|
Verification-1 |
|
Instructions-2 |
|
Verification-2 |
|
Instructions-3 |
|
Verification-3 |
|
Instructions-4 |
|
Verification-4 |
|
Comments |
|
Listen | |
Description | This directive is used to specify the HTTP port(s) that the webserver should listen at for incoming requests. You can include as many Listen directives as you want, if you want your webserver to LISTEN on multiple ports, then you can have one Listen directive for every port that you wish. The “Listen” directive takes either a |
Web-Link | http://httpd.apache.org/docs/2.2/mod/mpm_common.html#listen |
Default |
|
Instructions-1 |
|
Verification-1 |
netstat –an | grep 2222 | grep LISTEN Analyze this command? What are you checking here?
Port 2222 should not be used on your server! If the port is in use determine the process what uses the port and stop that process! |
Instructions-2 |
Listen 2222
NOTE: If you edit httpd.conf and, update “Listen” directive port value while the server is running, you will have trouble shutting down the webserver gracefully. For any updates/addition to “Listen” directives, please shutdown the webserver first before making the change. |
Verification-2 |
netstat –an | grep 2222 | grep LISTEN’
Is port 2222 now in listen state? Which process?
|
Instructions-3 |
|
Verification-3 |
|
Instructions-4 |
|
Verification-4 |
|
Comments |
|
ScriptAlias | |
Description | This directive is used to point to a directory that contains CGI scripts. PERL language can be used write CGI scripts. |
Web-Link | http://httpd.apache.org/docs/2.2/mod/mod_alias.html#scriptalias |
Default |
|
Instructions-1 |
#!/usr/bin/perl -w print "Content-type: text/html\n\n"; print "Hello, world";
|
Verification-1 |
|
Instructions-2 |
ScriptAlias /cgi-bin/ "/opt/IBM/HTTPServer/cgi-bin/"
ScriptAlias /cgi /opt/IBM/cgi
|
Verification-2 |
http://localhost/cgi/helloworld.cgi
What happens? Analyse and fix the problem |
Instructions-3 |
|
Verification-3 |
|
Instructions-4 |
|
Verification-4 |
|
Comments |
|
TraceEnable | |
Description | This directive is used to override the behavior of the “TRACE” method for the core server as well as for the mod_proxy implementation. Using this method you can disable the HTTP trace method for the server / mod_proxy. The server will return an HTTP response code 405 instead.
Note: This directive is only valid for IHS v7.0 and above. Use the rewrite technique we used in the example for earlier versions. Note: ITCS104 and most GSD331 specifications require that the TRACE method is disabled. |
Web-Link | |
Default | TraceEnable on |
Instructions-1 |
TraceEnable Off
Set the following line under comment (by adding “###” in front of it ;) ): Include /opt/IBM/HTTPServer/conf/disable_trace.conf
|
Verification-1 | Use the Telnet test as outlined in to verify the results. Run the test once with “coetest” in the “Host:” field and once with “localhost” in the “Host:”.
What is the difference? Why do we see different behavior? |
Instructions-2 |
|
Verification-2 |
|
Instructions-3 |
|
Verification-3 |
|
Instructions-4 |
|
Verification-4 |
|
Comments |
|
PidFile | |
Description | The PidFile directive sets the file to which the server records the process id of the daemon. If the filename is not absolute then it is assumed to be relative to the ServerRoot.
The process id (PID) is this file is the PID of the currently running parent process. |
Web-Link | http://httpd.apache.org/docs/2.2/mod/mpm_common.html#pidfile |
Default |
|
Instructions-1 |
|
Verification-1 |
|
Instructions-2 |
|
Verification-2 |
|
Instructions-3 |
|
Verification-3 |
|
Instructions-4 |
|
Verification-4 |
|
Comments |
|
ServerTokens | |
Description | This directive controls whether Server response header field which is sent back to clients includes a description of the generic OS-type of the server as well as information about compiled-in modules.
Note: ITCS104 and most GSD331 specifications require that this directive is set to “ServerTokens Prod” |
Web-Link | |
Default | ServerTokens Prod14 |
Instructions-1 |
|
Verification-1 | You'll get a HTTP response code 404 (Not Found). Now look at the footer of the error page. You'll see: “IBM_HTTP_Server at coetest Port 80” |
Instructions-2 |
ServerTokens Full
|
Verification-2 |
|
Instructions-3 |
|
Verification-3 | You'll get a HTTP response code 404 (Not Found). Now look at the footer of the error page. You'll see much more detailed information about the server: “IBM_HTTP_Server/7.0.0.13 (Unix) at coetest Port 80” Why do you think it's a bad idea to provide too many details about the server? |
Instructions-4 |
ServerTokens Prod
|
Verification-4 | Please repeat the “Verification-1” steps |
Comments |
|
ServerSignature | |
Description | This directive is used configure the footer of server generated documents. The reason why you would want to enable such a footer line is that in a chain of proxies, the user often has no possibility to tell which of the chained servers actually produced a returned error message. Note: ITCS104 and most GSD331 specifications require that this directive is set to “ServerSignature Off” |
Web-Link | http://httpd.apache.org/docs/2.2/mod/core.html#serversignature |
Default | ServerSignature On |
Instructions-1 |
|
Verification-1 | You'll get a HTTP response code 404 (Not Found). Now look at the footer of the error page. You'll see: “IBM_HTTP_Server at coetest Port 80” |
Instructions-2 |
ServerSignature Off
|
Verification-2 |
|
Instructions-3 | You'll get a HTTP response code 404 (Not Found). You'll see that the footer: “IBM_HTTP_Server at coetest Port 80” is gone. |
Verification-3 |
|
Instructions-4 |
|
Verification-4 |
|
Comments |
|
ServerAdmin | |
Description | Using that directive you can configure the contact address (eMail) that the server includes in any error messages it returns to the client.
It's a good practive in a project to setup separate eMails per server infrastructure as users often don't provide detailed information about what URL they are contacting the admin. |
Web-Link | |
Default | ServerAdmin you@your.address |
Instructions-1 |
|
Verification-1 |
|
Instructions-2 |
|
Verification-2 |
|
Instructions-3 |
|
Verification-3 |
|
Instructions-4 |
|
Verification-4 |
|
Comments |
|
Redirect and RedirectMatch | |
Description | This directive allows you to configure the server to send a redirect to the client directing the client to fetch the content from another URL15.
RedirectMatch is basically providing the same functionality except that it supports the usage of regular expressions for match determination. |
Web-Link | http://httpd.apache.org/docs/2.2/mod/mod_alias.html#redirect http://httpd.apache.org/docs/2.2/mod/mod_alias.html#redirectmatch |
Default |
|
Instructions-1 |
Redirect /file1.txt /sub1/file2.1.txt Redirect temp /file1.1.txt /langfile.txt
|
Verification-1 |
You should see the following content returned16: This is a file containing content in English Why? Do we get another file served now? Check the access logs of the HTTP server!
What happens now? Try to trace the redirects being performed here. |
Instructions-2 |
Redirect /file1.txt /sub1/file2.1.txt Redirect temp /file1.1.txt /langfile.txt
|
Verification-2 |
|
Instructions-3 |
|
Verification-3 |
|
Instructions-4 |
|
Verification-4 |
|
Comments |
|
Description |
|
Web-Link |
|
Default |
|
Instructions-1 |
|
Verification-1 |
|
Instructions-2 |
|
Verification-2 |
|
Instructions-3 |
|
Verification-3 |
|
Instructions-4 |
|
Verification-4 |
|
Comments |
|
1Specify the port the server is listening on → see “Listen” directive
2File name is set via PidFile directive in servers configuration file
3Mind the relative file specification. Relative file specifications are relative to the ServerRoot
4This nickname is defined via the LogFormat directive
5One day = 86400 seconds :)
6Although various documentations state that mod_negotiations is part of the core that module must be loaded explicitly!
7Mind the “-” in front of the Indexes keyword!
8Be aware that depending on the user setup at the OS level (umask etc.) you might have to adjust the filesystem authorities for the zcoeihs user!
9This are actually configuration directives to disable HTTP trace method in IHS V6.1 and before. Note that this directives must be included in every VirtualHost of the configuration. For IHS v7 and later use “TraceEnable off” instead!
10Make sure that you use the proper gsk7cmd as you might lacking CMS key database support otherwise. On a system with WAS installed it might be required to “source” the setupCmdLine.sh of the profile.
11gsk7cmd provides multiple levels of help! Try to run: ./gsk7cmd -help ; ./gsk7cmd -keydb -help; ./gsk7cmd -keydb -create -help
12Note that the lock in the browsers status bar is locked now – indicating that you are using a secured connection. Double-clicking the lock gives you information on the certificate used!
13Maybe you will run into the problem (ssl_error_no_cypher_overlap): http://www-01.ibm.com/support/docview.wss?uid=swg21424112.
14The default between Apache and IHS differs or might change. Therefore always verify the directive
15Note: We used the mod_rewrite function before to redirect requests
16If your browser is set to prefer English content. See: for multi-processing
No comments:
Post a Comment