IBM Http Server Basic Administration

CONTENTS Web server IHS How does IHS differ from Apache Basic configurations Advanced Configurations Performance

IBM HTTP Server (IHS) is a web server based on the Apache Software Foundation's Apache HTTP Server that runs on AIX, HP-UX, Linux, Solaris, Windows NT, IBM i and z/OS. It is available for download and use free of charge but without IBM support. The HTTP server is also included in the IBM WebSphere Application Server distribution packages. The default web console administration port is On IBM i, the administration port is 2001 Major releases IBM HTTP Server , 15 June 2012 (Apache based) IBM HTTP Server , 17 June 2011 (Apache based) IBM HTTP Server , 15 March 2009 (Apache based) IBM HTTP Server , 21 July 2006 (Apache based) , 29 July 2005 (Apache based) , 15 April 2005 (Apache based)

Web Server web servers are the computers that actually run web sites. The term "web server" also refers to the piece of software that runs on those computers, accepting HTTP connections from web browsers and delivering web pages and other files to them. web servers are the computers that actually run web sites. The term "web server" also refers to the piece of software that runs on those computers, accepting HTTP connections from web browsers and delivering web pages and other files to them. HTTPweb browsers HTTPweb browsers

How does IHS differ from Apache LDAP:IBM HTTP Server can access an LDAP server to obtain user and group authentication for the Web server itself Fast Response Cache Accelerator

Web server definition To administer or manage a web server using the administrative console, you must create a web server definition or object in the WebSphere® Application Server repository. The creation of this object is exclusive of the actual installation of a web server. The web server object in the WebSphere Application Server repository represents the web server for administering and managing the web server from the administrative console.

There are three types of WebSphere Application Server nodes upon which you can create a web server. The type depends on the version of WebSphere Application Server, as follows: Managed node. A node that contains a node agent. This node can exist only in a deployment manager environment. The importance of defining a web server on a managed node is that the administration and configuration of the web server is handled through the node agent from the administrative console. Support for administration and configuration through the administrative console is limited to IBM® HTTP Server only. Non-IBM HTTP Server web servers must be on a managed node to handle plug-in administrative functions and the generation and propagation of the plugin-cfg.xml file. Stand-alone node. A node that does not contain a node agent. This node usually exists in WebSphere Application Server (base) or WebSphere Application Server Express® environment. A stand-alone node can become a managed node in a deployment manager environment after the node is federated. A stand-alone node does not contain a node agent, so to administer and manage IBM HTTP Server, there must be an IBM HTTP Server administration server installed and running on the stand-alone machine that the node represents. IBM HTTP Server ships with the IBM HTTP Server administration server and is installed by default. Support for administration and configuration through the administrative console is limited to IBM HTTP Server only.

Unmanaged node. A node that is not associated with a WebSphere Application Server node agent. This node cannot be federated. Typically, the unmanaged node represents a remote machine that does not have WebSphere Application Server installed. However, you can define an unmanaged node on a machine where WebSphere Application Server is installed. This node can exist in aWebSphere Application Server (base), WebSphere Application Server Express, or deployment manager environment. An unmanaged node does not contain a node agent, so to administer and manage IBM HTTP Server, an IBM HTTP Server administration server must be installed and running on the stand-alone machine that the node represents. Support for administration and configuration through the administrative console is limited to IBM HTTP Server only. Web servers, which are not IBM HTTP Servers for WebSphere Application Server, are not fully administered from the WebSphere Application Server administrative console. The administration functions for Web servers, which are not IBM HTTP Servers for WebSphere Application Server, are: On managed nodes: Web server status in the web server collection panel or serverStatus.sh Generation of the plugin-cfg.xml Propagation of the plugin-cfg.xml On unmanaged nodes: Web server status in the web server collection panel or serverStatus.sh Generation of the plugin-cfg.xml

FRCA FRCA provides a cache mechanism that dramatically improves the file serving performance on our iSeries server. This enables FRCA to accelerate the delivery of an individual file found in its cache and reduce the amount of central processing unit (CPU) needed to handle the request (as compared to HTTP Server (powered by Apache). FRCA can handle both a static file caching and a dynamic reverse proxy caching.

How To Enable FRCA AfpaDynaCacheMax directive, tune the maximum allowed cache size. AfpaDynaCacheMax directive, tune the maximum allowed cache size. To enable the Fast Cache Accelerator, update the following directives in this IBM HTTP Server's http.conf file To enable the Fast Cache Accelerator, update the following directives in this IBM HTTP Server's http.conf file AfpaEnable AfpaEnable AfpaCache on AfpaCache on AfpaLogFile "c:/Program Files/IBM HTTP Server/logs/afpalog" AfpaDynaCacheMax 10 AfpaLogFile "c:/Program Files/IBM HTTP Server/logs/afpalog" AfpaDynaCacheMax 10

Basic configurations Server Root Error Log Custom Log or Access log PidFile DocumentRoot

ErrorLog The server’s error log file. Default Setting: /usr/lpp/HTTPServer/var/log/error_log CustomLog The server’s access log file. Default Setting: /usr/lpp/HTTPServer/var/log/access_log PidFile A file that contains the process ID (PID) of the main server process. Default Setting: /usr/lpp/HTTPServer/var/run/httpd.pid DocumentRoot Specifies the root directory for files served by this server. Default Setting: /usr/lpp/HTTPServer/share/htdocs

Advanced Configuration Virtual Hosts Virtual Hosts Virtual Hosting is a concept of partitions a server into several Virtual servers that each act like dedicated servers. There are two different kinds of virtual hosts Ip Based Name based

IP Based Virtual Hosting IP virtual host implementation is based on the way the HTTP server uses the IP address to serve the domain.

Ip Based Virtual Hosting

Implementing Ip Based Virtual Hosting Add the followind derivative in the httpd.conf file ServerName ServerAdmin DocumentRoot /www/html/CompanyA ErrorLog /www/logs/CompanyA/error_log TransferLog /www/logs/CompanyA/access_log ServerName ServerAdmin DocumentRoot /www/html/CompanyB ErrorLog /www/logs/CompanyB/error_log TransferLog /www/logs/CompanyB/access_log

Name Based Virtual Hosting Name Based Virtual Hosting The named-based virtual host implementation allows one IP address and TCP/IP port to host more than one domain.

Name Based Virtual Hosting

Implementing Name Based Virtual Hosting Add the followind derivative in the httpd.conf file NameVirtualHost ServerName DocumentRoot /www/html/CompanyA ServerName DocumentRoot /www/html/CompanyB...

SSL SSL (Secure Sockets Layer) is a widely- used way to implement transport layer security into TCP/IP communication used for secure connections between browsers and servers.

What SSL provides, is Privacy Authentication Data integrity security

Establishing the SSL Connection

Implementing SSL The minimum configuration changes that need to be done are: Definitions for loading the mod_ibm_ssl module Port number for the SSL virtual host Definition for the SSL virtual host Keyfile location SSL timeouts

When editing the httpd.conf file, The following actions guide you through these steps: 1. First add the following row into the httpd.conf file as the first item of the LoadModule list: LoadModule ibm_ssl_module libexec/mod_ibm_ssl.so 2. Add the following row as the first line to the AddModule list: AddModule mod_ibm_ssl.c 3. Add the port number for the virtual server just below the “Listen 80” statement. The default port number for SSL is 443. Listen Check that you have defined the ServerName directive: ServerName

Add following text-block to the end of the httpd.conf SSLEnable SSLClientAuth none DocumentRoot /www/html/CompanyA ErrorLog /www/logs/CompanyA/error_log TransferLog /www/logs/CompanyA/access_log SSLDisable Keyfile /usr/lpp/HTTPServer/keys/CompanyA.kdb SSLCacheEnable SSLCachePortFilename /usr/lpp/HTTPServer/tmp/siddfile

Performance Parameters MaxClients MaxSpareServers MinSpareServers StartServers

MaxClients — Restricts the maximum number of child httpd daemons created that can process client requests in parallel. MaxClients = Total memory available to the IBM HTTP Server / memory consumption for each child httpd The default value is 150. MaxSpareServers — Specifies the upper number of idle httpd child processes which are not handling any requests. The default is 10. MaxSpareServers MaxSpareServers The MaxSpareServers directive sets the desired maximum number of idle child server processes. An idle process is one which is not handling a request. If there are more than MaxSpareServers idle, then the parent process will kill off the excess processes. MinSpareServers — Specifies the lower number of idle httpd child processes which are not handling any requests. The default is 10. MinSpareServers MinSpareServers The MinSpareServers directive sets the desired minimum number of idle child server processes. An idle process is one which is not handling a request. If there are fewer than MinSpareServers idle, then the parent process creates new children at a maximum rate of 1 per second.

StartServers — Specifies the number of httpd child processes to be created at startup. The default is 5 The StartServers directive sets the number of child server processes created on startup. As the number of processes is dynamically controlled depending on the load, there is usually little reason to adjust this parameter.

IBM HTTP Server supports a maximum of 600 concurrent connections. Performance will suffer if load dictates more concurrent connections, as incoming requests will be queued up by the host operating system. You can increase the number of maximum connections allowed by IBM HTTP Server by editing the httpd.conf file. Resolving the problem First and foremost, you must determine the maximum number of simultaneous connections required for this Web server. Using mod_status or mod_mpmstats to display the active number of threads throughout the day will provide some starting data. There are 3 critical aspects to MPM (Multi-processing Module) tuning in IBM HTTP Server.

1.Configuring the maximum number of simultaneous connections (MaxClients directive) 2.Configuring the maximum number of IBM HTTP Server child processes (ThreadsPerChild directive) 3.Less importantly, configuring the ramp-up and ramp-down of IBM HTTP Server child processes (MinSpareThreads, MaxSpareThreads, StartServers) The first setting (MaxClients) has the largest immediate impact, but the latter 2 settings help tune IBM HTTP Server to accommodate per-process features in modules, such as the WebSphere Application Server Web server plug-in.

Performance Monitoring A benchmarking tool is provided with the IBM HTTP Server package for webmasters to analyze how capable the IBM HTTP Server is running on the environment they had configured. This useful tool is called ab Syntax: ab [options] [ Options: -n requests Number of requests to perform -c concurrency Number of multiple requests to make -t timelimit Seconds to max. wait for responses -p postfile File containing data to POST -T content-type Content-type header for POSTing -v verbosity How much troubleshooting info to print -V Print version number and exit -k Use HTTP KeepAlive feature -h Display usage information (this message )

. An example of how webmasters can simulate 20 users, each requesting a CGI script called test.cgi 10 times using port 80 ab -n 200 -c 20

OUTPUT

THANK YOU :