mod_deflate – saves web server traffic by compression


  • The mod_deflate module provides the DEFLATE output filter that allows output from your server to be compressed before being sent to the client over the network.
  • mod_deflate allows Apache2 to compress files and deliver them to clients
  • With mod_deflate, you can compress HTML, text or XML files to approx. 20 – 30% of their original sizes, thus saving you server traffic.
  • Compressing files causes a slightly higher load on the server

How to use it?

1. Enable mod_deflate module

When we install apache2, mod_deflate should also already be installed on system
LoadModule deflate_module modules/mod_deflate.so Continue reading

Advertisements

The Enigma of WebSphere Application Server Plug-in, Part-2: Parameters that you can tune


In the first part of this series, we learned how the WebSphere application server plugin works and different components involved in its operation. In this second part, let us discuss different parameters that can affect the operation of the plugin and tuning options.

TCP timeout on operating system

This parameter controls when to drop a request when the client is not able to communicate with the server using TCP/IP. In case of the plugin, this parameter controls when the backend application server will be marked as down. For example, you have TCP/IP timeout on your linux operating system as 90sec and the plugin failed to communicate with an application server hosted on that machine, then it waits for the TCP/IP timeout setting and marks the server as down.

It is very important to know that since this parameter is set at operating system level, it will affect all other TCP/IP communications on that machine.

Connect timeout in plugin-cfg.xml

This setting allows plugin to perform a non-blocking connection with the backend server.

<Server CloneID=”abcd123x” LoadBalanceWeight=”2″ Name=”WASNClone1″ ConnectTimeout=”X”>

  • A value of ‘0’ allows plugin to perform non-blocking connection.
  • A value greater than 0 specifies the number of seconds you want the plug-in to wait for a successful connection. If a connection does not occur after that time interval, the plug-in marks the server unavailable and fails over to one of the other servers defined in the server group.
  • If no value is specified, the plugin wait until TCP/IP timeout occurs.

If no clone responds within the specified connect timeout, then a HTTP 500 error will be thrown.

When a clone is marked down, the plugin will retry for connection based on RetryInterval.

Plugin-log entry when connect timeout occurs

ERROR: ws_common: websphereGetStream: Connect timeout fired

ERROR: ws_common: websphereExecute: Failed to create the stream

ERROR: ws_server: serverSetFailoverStatus: Marking WASNClone1 down

ERROR: ws_common: websphereHandleRequest: Failed to execute the transaction to ‘WASNClone1’on host ‘test.josephamrithraj.com’; will try another one Continue reading

Configuring SSL for WebSphere and IBM Http Server, part-4 : Dmgr and Nodes


It is always good to spend some time on thinking how to do instead of start doing it and then thinking what to do. Also it is always advisable to draw picture to understand complex things in simple way.

Now Observe the below picture of WebSphere setup having one Web Server, one DMGR and 2 nodes. Write down all the possible communications among them. Also include a browser and its communication with DMGR.

  1. Browser to DMGR
  2. DMGR to Nodes
  3. Web Server to Application Servers… Through plug-in

Thats it, now we know where all we can configure SSL and secure our WebSphere environments.

Note:

  • Take back up of configuration using backupconfig
  • In a secure communication both end points need to exchange their certificates to establish the secure link.
  • Stop all process related to websphere

WEBSPHERE-SSL-2

 

1. DMGR certificate

Start Deployment Manager [DMGR]

Replace DMGR certificate

  • In the Administrative Console, go to Security > SSL certificate and key management > Key stores and certificates > CellDefaultKeyStore > Personal certificates > Create a self-signed certificate. Enter the required attributes.
  • image 

  • Click OK and Save the changes
  • Go back to Security > SSL certificate and key management > Key stores and certificates > CellDefaultKeyStore > Personal certificates
  • Select the old DMGR certificate and click Replace.
  • On the next screen, you are able to choose which certificate will replace the old certificate. Accept your new certificate. Do not select either Delete old certificate after replacement or Delete old signers. Accept your new certificate and any browser prompts.
  • On the next screen, select the old certificate and click Delete. Click OK and Save the changes.

Now you have your DMGR certificate replaced

As i pointed earlier, the certs needs to be exchanged for establishing secure communication. So add the DMGR cert to DefaultCellTrustStore

  • Go to SSL certificate and key management > Key stores and certificates.
  • Select CellDefaultKeyStore and CellDefaultTrustStore and click Exchange signers.
  • image

  • Select the certificate in CellDefaultKeyStore personal certificates created in previous step and click Add.
  • image

  • Click OK and Save the changes.

2. Node Certificates

  • Go to Security > SSL certificate and key management > Manage endpoint security configurations.
  • Under Inbound, click the link for the node, node_name(NodeDefaultSSLSettings,null).
  • Click the Manage certificates button.
  • image

  • Click Create a self-signed certificate and Enter the required attributes.
  • Click OK and Save the changes
  • Go back to Security > SSL certificate and key management > Manage endpoint security configurations, click node_name(NodeDefaultSSLSettings,null), click Manage certificates.
  • Select the old certificate and click Replace.
  • On the next screen, you are able to choose which certificate will replace the old certificate. Accept your new certificate. Do not select either Delete old certificate after replacement or Delete old signers.
  • On the next screen, select the old certificate and click Delete. Click OK and save the changes.

Now Exchange the Node Signer cert with DefaultCellTrustStore

  • Go to Security > SSL certificate and key management > Manage endpoint security configurations.
  • Under Inbound, click the link for the node, node_name(NodeDefaultSSLSettings,null) and select Key stores and certificates.
  • Select NodeDefaultKeyStore and CellDefaultTrustStore and then Click Exchange signers.
  • image

  • Select the certificate in NodeDefaultKeyStore personal certificates created in previous step and click Add.
  • image

  • Click OK and Save the changes.

Delete the old signer certificates and extract the new ones.

  • Go to SSL certificate and key management > Key stores and certificates > CellDefaultTrustStore > Signer certificates
  • Select all of the old signer certificates and click Delete. If you are not sure, you can compare the Fingerprint and/or the Expiration dates with the personal certificate in the keystores.
  • Select one of the new certificates. Click Extract.
  • Enter a File Name that corresponds to the certificate. For example, node1.arm. Click Ok.
  • for each of the new certificates making sure you have done this for the cell signer and all of the node signers. These files are saved to the profile_root/Dmgr/etc directory

Manually copy the trust store to each of the /etc directories.

  • Backup the trust.p12 in profile_root\Dmgr\etc
  • Copy the profile_root\Dmgr\config\cells\cell-name\trust.p12 to profile_root\Dmgr\etc
  • Backup the trust.p12 on each of the nodes profile_root\Appsrv\etc directories.
  • Copy the profile_root\Dmgr\config\cells\cell-name\trust.p12 to profile_root\Appsrv\etc

Note: If you have multiple nodes… You need to do the Node Certificate section for all nodes separately.

Now, Restart the DMGR and sync the nodes using ‘syncnode’ command. Then start Node Agents and Application Servers.

3. Plug-in

  • Go to Servers > Web servers. Click webserver_name, then under Additional Properties click Plug-in properties.
  • Click Manage keys and certificates under Additional Properties, click Signer certificates and then click AddEnter a unique Alias Name and then specify the File Name that you exported as .arm file
  • image

  • Repeat this for each of the new certificates making sure you have done this for the cell signer and all of the node signers.
  • Manually copy the plugin-key.kdb from the local configuration to the Web server. [ default locations: profile_root\Dmgr\config\cells\cell-name\nodes\node-name\servers\web-server-name\plugin-key.kdb to Web-server-root\Plugins\config\web-server-name\plugin-key.kdb]
  • Start the Web server

Note: If you have multiple web servers … you need to do the above steps for each web server separately

The steps and procedure are from IBM Websphere Infocenter and document Reference #: 1305596

Configuring SSL for WebSphere and IBM Http Server, part-3 : Client Authentication and Ciphers


Client Authentication:

If you enable client authentication, the server validates clients by checking for trusted certificate authority, Known as CA root certificates in the local key database. To enable client authentication, you need to use SSLClientAuth directive. The options to use with this stanza are:

  • None – The server requests no client certificate from the client.
  • Optional – The server requests, but does not require, a client certificate. If presented, the client certificate must prove valid.
  • Required – The server requires a valid certificate from all clients and returns a 403 status code if no certificate is present.
  • Required_reset – The server requires a valid certificate from all clients, and if no certificate is available, the server sends an SSL alert to the client. This enables the client to understand that the SSL failure is client-certificate related, and will cause browsers to re-prompt for client certificate information on subsequent access. make sure you have GSKit version 7.0.4.19 or later when you choose this option.
    For example, If i want all the clients to be authenticated, then i need to add the following stanza

SSLClientAuth required

Ciphers

We set the cipher specification to use during secure transactions. The specified cipher specifications validate against the level of the Global Security Kit (GSK) toolkit that is installed on your system. Invalid cipher specifications cause an error to log in the error log. If the client issuing the request does not support the ciphers specified, the request fails and the connection closes to the client. IBM HTTP Server has a built-in list of cipher specifications to use for communicating with clients over Secure Sockets Layer (SSL).  The actual cipher specification that is used for a particular client connection is selected from those which are supported by both IBM HTTP Server and the client.

Some cipher specifications provide a weaker level of security than others, and might need to be avoided for security reasons. Some of the stronger cipher specifications are more computationally intensive than weaker cipher specifications and might be avoided if required for performance reasons. When an SSL connection is established, the client (web browser) and the web server negotiate the cipher to use for the connection. The web server has an ordered list of ciphers, and the first cipher in that list which is supported by the client will be selected.

IBM HTTP Server supports the following SSL ciphers: SSLv3 and TLS and SSLv2

IBM recommends the following setting, keeping in mind both strong security and performance

  ## SSLv3 128 bit Ciphers
  SSLCipherSpec SSL_RSA_WITH_RC4_128_MD5
  SSLCipherSpec SSL_RSA_WITH_RC4_128_SHA

  ## FIPS approved SSLV3 and TLSv1 128 bit AES Cipher
  SSLCipherSpec TLS_RSA_WITH_AES_128_CBC_SHA

  ## FIPS approved SSLV3 and TLSv1 256 bit AES Cipher
  SSLCipherSpec TLS_RSA_WITH_AES_256_CBC_SHA

  ## Triple DES 168 bit Ciphers
  ## These can still be used, but only if the client does
  ## not support any of the ciphers listed above.
  SSLCipherSpec SSL_RSA_WITH_3DES_EDE_CBC_SHA

  ## The following block enables SSLv2. Excluding it in the presence of
  ## the SSLv3 configuration above disables SSLv2 support.

  ## Uncomment to enable SSLv2 (with 128 bit Ciphers)
  #SSLCipherSpec SSL_RC4_128_WITH_MD5
  #SSLCipherSpec SSL_RC4_128_WITH_SHA
  #SSLCipherSpec SSL_DES_192_EDE3_CBC_WITH_MD5

View the Ciphers which the server uses for Secure transactions

Set the LogLevel to info in the configuration file. Look in the error log for messages in this format: TimeStamp info_message mod_ibm_ssl: Using Version 2/3 Cipher: longname|shortname. The order that the cipher specifications are displayed in the error log from top to bottom represents the attempted order of the cipher specifications.

View the Ciphers were used for negotiating a connection

You can use the following LogFormat directive to view and log the SSL cipher negotiated for each connection:

LogFormat “%h %l %u %t \”%r\” %>s %b \”SSL=%{HTTPS}e\” \”%{HTTPS_CIPHER}e\” \”%{HTTPS_KEYSIZE}e\” \”%{HTTPS_SECRETKEYSIZE}e\”” ssl_common

CustomLog logs/ssl_cipher.log ssl_common

This logformat will produce an output to the ssl_cipher.log that looks something like this:

127.0.0.1 – – [01/Sep/2010:00:02:05 -0800] “GET / HTTP/1.1″ 200 1582 “SSL=ON” “SSL_RSA_WITH_RC4_128_MD5″ “128″ “128″

SSL for multiple IP virtual hosts

When you do not define an SSL directive on a virtual host, the server uses the directive default. You can define different (SSL) options for various virtual hosts. To enable SSL:

  • Specify the SSLEnable directive on the virtual host stanza in the configuration file, to enable SSL for a virtual host.
  • Specify a Keyfile directive and
  • Any SSL directives you want enabled for that particular virtual host.
  • Restart the server.

With all the above security options enabled, your virtual host may look like this:

<VirtualHost *:443>

SSLEnable

Keyfile keyfile.kdb

SSLCientAuth required

## SSLv3 128 bit Ciphers

SSLCipherSpec SSL_RSA_WITH_RC4_128_MD5

SSLCipherSpec SSL_RSA_WITH_RC4_128_SHA

## FIPS approved SSLV3 and TLSv1 128 bit AES Cipher

SSLCipherSpec TLS_RSA_WITH_AES_128_CBC_SHA

## FIPS approved SSLV3 and TLSv1 256 bit AES Cipher

SSLCipherSpec TLS_RSA_WITH_AES_256_CBC_SHA

## Triple DES 168 bit Ciphers

## These can still be used, but only if the client does not support any of the ciphers listed above.

SSLCipherSpec SSL_RSA_WITH_3DES_EDE_CBC_SHA

## The following block enables SSLv2.
## Excluding it in the presence of  the SSLv3 configuration above disables SSLv2 support.

## Uncomment to enable SSLv2 (with 128 bit Ciphers)

#SSLCipherSpec SSL_RC4_128_WITH_MD5

#SSLCipherSpec SSL_RC4_128_WITH_SHA

#SSLCipherSpec SSL_DES_192_EDE3_CBC_WITH_MD5

</VirtualHost>

Configuring SSL for WebSphere and IBM Http Server, part2 : Restrict unused HTTP methods and Verbose HTTP headers


Restricting unused HTTP methods

The HTTP method is supplied in the request line and specifies the operation that the client has requested. Browsers will generally just use two methods to access and interact with web sites; GET for queries that can be safely repeated and POST for operations that may have side effects. This means, we need to disable unused http methods. some of them are:(PUT|DELETE|TRACE|TRACK|COPY|MOVE|LOCK|UNLOCK|PROPFIND|PROPPATCH|SEARCH|MKCOL). Check with the application teams, if they need any of these methods for the application to work, before disabling them.

Testing before limiting http methods:

telnet josephamrithraj.mp 80
Trying xx.xx.xx.xx…
Connected to josephamrithraj.mp.
Escape character is ‘^]’.
OPTIONS / HTTP/1.1
Host: josephamrithraj.mp

HTTP/1.1 200 OK
Date: Thu, 14 Sep 2010 00:11:57 GMT
Server: Apache Web Server
Content-Length: 0
Allow: GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, PATCH, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK, TRACE

Connection closed by foreign host.

your IBM http servers configuration file [httpd.conf] has 2 sections named main and virtualhost sections. you need to add the following code at both the places. I am explaining this task using mod_rewrite module. So, first make sure that… mod_rewrite is enabled. then, add the following lines to your http.conf files main and virtualhost sections.

RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^(PUT|DELETE|TRACE|TRACK|COPY|MOVE|LOCK|UNLOCK|PROPFIND|PROPPATCH|SEARCH|MKCOL)
RewriteRule .* – [F]

Restart the web server after adding the above lines.

Now, when someone tried to use one of these http methods, they will get forbidden response since we specified [F] in the rewrite rule.

Testing after adding and restarting web server

telnet josephamrithraj.mp 80
Trying xx.xx.xx.xx...
Connected to josephamrithraj.mp.
Escape character is '^]'.
OPTIONS / HTTP/1.1
Host: josephamrithraj.mp

HTTP/1.1 200 OK
Date: Thu, 14 Sep 2010 00:15:44 GMT
Server: Apache Web Server
Content-Length: 0
Allow: GET, POST
Connection closed by foreign host.

Testing TRACE methods

telnet josephamrithraj.mp 80 Trying xx.xx.xx.xx... Connected josephamrithraj.mp Escape character is '^]'. TRACE / HTTP/1.0 Host: josephamrithraj.mp testing... <- ENTER twice HTTP/1.1 403 Forbidden Date: Thu, 14 Sep 2010 00:18:31 GMT Server: Apache Web Server Content-Length: 320 Connection: close Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML(link) PUBLIC "-//IETF//DTD HTML(link) 2.0//EN"> <html><head> <title>403 Forbidden</title> </head><body> <h1>Forbidden</h1> <p>You don't have permission to access / on this server.</p> </body></html> Connection closed by foreign host. 

Disable verbose HTTP headers:

you might have seen this … when the web server [apache or ibm http server] throws errors page, sometimes it might show the information related to its version, build, modules etc. This is a security issue since you are giving away the details about your web server. for example, take a look at this:
Server: Apache/2.0.53 (Ubuntu) PHP/4.3.10-10ubuntu4 Server at xx.xx.xx.xx Port 80
The line in the server header expose important version and variant information about the Linux operating system and Apache software used on the machine, indirectly expose the possible security holes that are existed to the hackers, or at least make malicious attackers easier to identify your system for available attack points.
To ensure that the Apache HTTP web server does not broadcast this message to the whole world publicly and fix possible security issue, modify these two directives ServerTokes and ServerSignature in httpd.conf configuration file.

ServerTokens

This directive configures what you return as the Server HTTP response Header. The built-in default is ‘Full’ which sends information about the OS-type and compiled in modules.  The recommended value is ‘Prod’ which sends the least information.

Options:  Full | OS | Minor | Minimal | Major | Prod

“ServerTokens Prod”

This configures Apache to return only Apache as product in the server response header on very page request, suppressing OS, major and minor version info.

ServerSignature

This directive lets you add a line containing the server version and virtual host name to server-generated pages. It is recommended to set it to OFF and Set to “EMail” to also include a mailto: link to the ServerAdmin.

Options: On | Off | EMail

“ServerSignature Off”

This instructs Apache not to display a trailing footer line under server-generated documents, which displays server version number, ServerName of the serving virtual host, email setting etc..

The Enigma of WebSphere Application Server Plug-in, Part-1: What, why and How


This is a 4 part series which covers WebSphere Application Server Plugin related topics like: what is plug-in, why should you use plug-in, how does plug-in works, Different components invloved in plugin operation, Plgin configuration file, Configurable parameters, Troubleshooting and merging multiple plug-in files. This article series is written assuming that IBM http server is used as web server in front of the WebSphere application server. 

The first part of this article, discuss the basics of the websphere application server plug-in. In this part, you’ll understand what is plugin, advantages of plugin and how a plugin routes requests to the backend web containers.

What is WebSphere Application Server Plugin?
The IBM WebSphere Application Server Web server plug-in is the “glue” between a Web server and WebSphere Application Server. The plug-in was developed using native programming language “C”.

What does plugin do?
Plug-in forwards HTTP requests from the Web server to the WebSphere Application Server.

How do i get the Plugin?
It comes along with the WebSphere Application Server installation CD or part of your downloaded image.

Before we start ……
take a look at the below image.


In general, there will a web server sitting infront of the websphere application server. The request from browser/internet will first comes to web server and then it gets redirected/forwarded to application server. This forwarding/redirection is handled by the plugin. This redirection happens based on a set of rules defined in the plugin configuration file. The Web server gives the WebSphere plug-in an opportunity to handle every request first, and only when WebSphere is not configured to service that URL does the request go to the Web server for servicing.

What are advantages of using webserver and plugin?

  1. The plug-in provides work load management and failover capabilities by distributing requests evenly to multiple application servers and routing requests away from a failed application server.
  2. Static content can be served by the Web server without doing a full round trip to the application server.
  3. The Web server provides an additional hardware layer between the Web browser and the application server, thus strengthening the application server’s security.

components involved in plugin operation

  • Web server : which first receives the request
  • httpd.conf : This contains the reference to the plugin so/dll file and reference to the plugin configuration file.
  • Plugin : It is loaded into memory by the Web server during startup and runs inside the same process as the Web server.
  • plugin-cfg.xml : configuration file of the plugin, which contains iinformation about which URLs will be served by backend application servers
  • http transport : which accepts the forwarded request from plugin, on the application server side
  • web container: which actually handles the request

How does Plug-in work ?

A)Plug-in initialization

  • When web server is starting, httpd.conf will be read
  • httpd.conf will have: 1)LoadModule reference to the path of the plugin so/dll file. 2)WebSpherePluginConfig reference will have the path to plugin-cfg.xml
  • While web server is starting , it loads websphere plugin using LoadModule reference
  • Plugin will load configuration file using WebSpherePluginConfig reference, into the plugin process.
  • Then configuration file will be parsed and validated

Whenever the Web server receives a new HTTP request, it first passes that request to the plug-in. The plug-in determines whether this request should be handled by WebSphere by matching the URL requested to all the URLs defined in plugin-cfg.xml.

If plugin-cfg.xml is updated, it can automatically be reloaded by the plug-in without requiring a restart of the Web server. By default, the plug-in attempts to reload the plug-in configuration file every 60 seconds

<?xml version=”1.0″ encoding=”ISO-8859-1″?>
<Config ASDisableNagle=”false” AcceptAllContent=”false” AppServerPortPreference=”HostHeader” ChunkedResponse=”false” FIPSEnable=”false
” HTTPMaxHeaders=”300″ IISDisableNagle=”false” IISPluginPriority=”High” IgnoreDNSFailures=”false” RefreshInterval=”60″ ResponseChunkSi
ze=”64″ SSLConsolidate=”false” TrustedProxyEnable=”false” VHostMatchingCompat=”false”>
<Log LogLevel=”Error” Name=”/www/logs/ibmhttp/http_plugin.log”/>
<Property Name=”ESIEnable” Value=”true”/>
<Property Name=”ESIMaxCacheSize” Value=”1024″/>
<Property Name=”ESIInvalidationMonitor” Value=”false”/>
<Property Name=”ESIEnableToPassCookies” Value=”false”/>

The plug-in does this by checking the timestamp of plugin-cfg.xml, and if the timestamp has changed since the previous check, it reloads it.

B) How does plug-in determines where to send the request?

The plug-in compares the request to each route.

<Route ServerCluster=”app1_cluster” UriGroup=”joseph-app1_app1l_cluster_URIs” VirtualHostGroup=”joseph-app1″/>

<UriGroup Name=”joseph-app1_app1l_cluster_URIs”>
<Uri AffinityCookie=”JSESSIONID” AffinityURLIdentifier=”jsessionid” Name=”/app1_context/*”/>
</UriGroup>

<VirtualHostGroup Name=”joseph-app1″>
<VirtualHost Name=”testapp1:80″/>
<VirtualHost Name=”testapp1.joseph.com:80″/>
<VirtualHost Name=”app1-dev.joseph.com:9081″/>
<VirtualHost Name=”app1-dev.joseph.com:9444″/>
<VirtualHost Name=”app2-dev.joseph.com:9081″/>
<VirtualHost Name=”app2-dev.joseph.com:9444″/>
</VirtualHostGroup>

If a match for URIGroup and VirtualHostGroup is found, the plug-in sends the request to the associated Server.

If there are multiple servers in the servercluster, the request is sent to one of them depending upon various factors such as WLM policy, session information, etc.

<ServerCluster CloneSeparatorChange=”false” GetDWLMTable=”false” IgnoreAffinityRequests=”true” LoadBalance=”Round Robin” Name=”appl
_cluster” PostBufferSize=”64″ PostSizeLimit=”-1″ RemoveSpecialHeaders=”true” RetryInterval=”60″>

<Server CloneID=”abcdxyz” ConnectTimeout=”0″ ExtendedHandshake=”false” LoadBalanceWeight=”2″ MaxConnections=”-1″ Name=”appnode1_server1_app1″ ServerIOTimeout=”0″ WaitForContinue=”false”>
<Transport Hostname=”app1-dev” Port=”9081″ Protocol=”http”/>
<Transport Hostname=”app1-dev” Port=”9444″ Protocol=”https”>
<Property Name=”keyring” Value=”/www/ibmhttp/Plugins/config/dev/plugin-key.kdb”/>
<Property Name=”stashfile” Value=”/www/ibmhttp/Plugins/config/dev/plugin-key.sth”/>
</Transport>
</Server>

<Server CloneID=”xyzabcd” ConnectTimeout=”0″ ExtendedHandshake=”false” LoadBalanceWeight=”2″ MaxConnections=”-1″ Name=”appnode2_server1_app2″ ServerIOTimeout=”0″ WaitForContinue=”false”>
<Transport Hostname=”app2-dev” Port=”9081″ Protocol=”http”/>
<Transport Hostname=”app2-dev” Port=”9444″ Protocol=”https”>
<Property Name=”keyring” Value=”/www/ibmhttp/Plugins/config/dev/plugin-key.kdb”/>
<Property Name=”stashfile” Value=”/www/ibmhttp/Plugins/config/dev/plugin-key.sth”/>
</Transport>
</Server>

<PrimaryServers>
<Server Name=”appnode1_server1_app1″/>
<Server Name=”appnode2_server1_app2″/>
</PrimaryServers>

</ServerCluster>

C) Sending requests to application server?

This is handled in two steps:

  1. Once the server/clone determination has been made [step-B], the plug-in breaks down the HTTP request into its various components such as HTTP header, GET/POST data, etc. A new data packet is created by populating an empty HTTP client object with data from the user request. Once this new HTTP client object has been populated, it is ready to be sent. If the plug-in is configured to communicate with the HttpTransport over SSL, it is required to perform security functions as well.
  2. The request will be sent by flushing out the client object stream to the network using TCP/IP.

D) Receiving response from application Server

After sending a request to the application server, plug-in will wait for the response.

  • If a response from the application server has been received by the plug-in, the response is passed on to the Web server and then to the Web browser
  • If there is no response from the selected server, then that application server is marked as unreachable and is then taken out of the routing algorithm for a period specified by the RetryInterval. In a ServerCluster, request will be passed on to other clones. If communication with every clone in the cluster fails due timeouts, then you receive an HTTP 500 error.

<ServerCluster CloneSeparatorChange=”false” GetDWLMTable=”false” IgnoreAffinityRequests=”true” LoadBalance=”Round Robin” Name=”appl
_cluster” PostBufferSize=”64″ PostSizeLimit=”-1″ RemoveSpecialHeaders=”true” RetryInterval=”60″>

References:

In the next part, we will learn about different parameters, how plugin handles servers and configuration options.

WebSphere Admin Toolkit : apachectl command


Everyone likes tweaks and hacks but the most important thing is that that feature is already present and we just don’t about it or don’t know how to use it.  In part2 of out AdminToolkit, you’ll learn how to use apachectl of IBM http server / Apache as a power user.

apachectl is a front end to the Apache HyperText Transfer Protocol (HTTP) server. It is designed to help the administrator control the functioning of the Apache httpd The apachectl script can operate in two modes. First, it can act as a simple front-end to the httpd command that simply sets any necessary environment variables and then invokes httpd, passing through any command line arguments. Second, apachectl can act as a SysV init script, taking simple one-word arguments like startrestart, and stop, and translating them into appropriate signals to httpd.

  • 1. Know what modules are loaded

# ./apachectl -l
this will display all the modules that are compiled into your installation of IHS/Apache

  • 2. Syntax issues

This happens to everyone. You make some changes to your config file and restarts IHS/Apache but it fails with error message syntax error. you can use apachectl -t to test your config file before restarting your IHS/Apache, to know if the config file has correct syntax.

# apachectl -t -f conf/httpd.conf_joseph
Syntax OK

  • 3. Have ever been asked to change DocumentRoot temporary ?

you can do it without restarting your server… using

# ./apachectl start -c "DocumentRoot /var/new/html" The above command starts your server with /var/new/html as docroot.  
  • 4. change loglevel temporary ?

It is possible to change the LogLevel temporary. the below command sets the loglevel to DEBUG temporarily.

apachectl start -e debug

  • 5. Startup errors

If you are getting error whilel starting your server and wants to log the startup errors to separate file  ..use

# ./apachectl start -E file_name

  • 6. What version of the server you are using?

# ./apachectl -v

  • 7. Know where can you use httpd.conf directives

This command will display all the httpd.conf directives and the places where they are valid. For a specific directive, it tells all the possible values and where it can be used inside the httpd.conf.

# ./apachectl -L

  • 8. Testing your changes.

The best practise is to make a backup of the httpd.conf file and then edit it . The other idea is to take a backup, edit the backup file, test your changes and then make the changes to the original. Now i have two config files httpd.conf [orginal] and httpd.conf_joseph [with new changes/configs]. Before i stop my IHS/Apache, i want to make sure that, my new httpd.conf will run with out erros.

This can be achieved by using “apachectl -f “
# ./apachectl -f conf/httpd.conf_joseph 

The above command specify an alternate ServerConfigFile. After running the above command, try ‘ps -ef|grep httpd’ .. you should see httpd.conf_joseph as argument to httpd.

here is what you do :
cd APACHE/bin

  • cp httpd.conf httpd.conf_joseph
  • Make your changes in httpd.conf_joseph
  • apachectl -f conf/httpd.conf_joseph
  • ps -ef|grep httpd
  • your changes are good 
  • cp httpd.conf_joseph httpd.conf
  • apachectl restart