How to do Apache webserver browser caching for static files

When a URL is hit it reaches the webserver and other component and serve you  back the content.Some websites might have more static content like images ,js etc.These  files can be cached at the browser so the next hit from the same browser wont go  to the webserver and it will be served from the browser cache.To do this we need the below setup at the webserver.

Check the below module is loaded in httpd.conf

LoadModule expires_module modules/mod_expires.so 

You can check all the modules available in your httpd by executing 

<path to httpd>/httpd -M

for ex: /usr/bin/httpd -M

Add lines similar to below depending on your need :

<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType text/css "access plus 60 minutes"
  ExpiresByType text/javascript "access 1 year"
  ExpiresByType application/x-javascript "access plus 60 minutes"
  ExpiresByType text/xml "access plus 60 minutes"
</IfModule>

If module will check the module is there or not

ExpiresActive On directive will tell the http expire is on 

ExpiresByType will be used to tell which file type need to be cached in browser

access 1 year will keep the file type in the browser for a year,unless you clear the browser cache.

To check mod_expire is working or not.Hit the URL you wish from the browser.Hit it again

and check your webserver logs.You should not see the request logged in for the filetype

which is cached.

Or user Live http header extension for the browser to see the http header.

You will see Expires on field where it will be a future date. 

References:

Apache mod_expire

OpenSSL commands for certificate generation

Openssl is a command line tool used to generate certificates which will be used for opensource webservers like Apache and appservers like tomcat.

Most Linux/Unix platform will have openssl installed.

Check openssl is installed by issuing the command
openssl version.Below is the output.

[}$ openssl version
OpenSSL 1.0.0-fips 29 Mar 2010

To set up a SSL we need
1.private key
2.certificate request to send to CA
3.Get the certificate from CA via email.

openssl genrsa -des3 -out test.key 2048

The above command has genrsa which is to use RSA algorithm.des3 which is triple DES  algorithm  to encrypt passphrase and 2048 is the bit size.

openssl genrsa -aes128 -out test.key 2048 

In the above command mentioned aes algorithm  to use for key protection  if you dont want des3.
There are many websites to give the command you dont have to remember the command. 

2.Generate CSR.

CSR is the one where  you will provide your website information which will be used by CA to generate the certificate.

openssl req -new -key test.key -out test.csr
Once you type the command it will ask for passphrase and some other info like country ,state,email and common name.

To skip typing these either you can put the config in cnf file or put the details in the command itself.

[req]
prompt = no
distinguished_name = distinguished_name

[distinguished_name]
CN = www.test.com
emailAddress = test@test.com
O = Test Ltd
L = London
C = GB 

Place the above line in a file called test.cnf and issue the command below
openssl req -new -key test.key -out test.csr -config test.cnf
it will only ask for passphrase of the private key since other details are already mentioned in the cnf file.

The above example is for single domain.For multi domain you have to configure subject alternative name (SAN) in the cnf file with v3 extensions.

Once the csr is generated open the file with text editor and copy the content fully and paste it in any CA site you wish.
 






 

Perl script to zip native logs in websphere

#!/usr/bin/perl
my $dir='/websphere/logs';  (set to your log path directory)
if( -d $dir )
{
@jvmlist=`ls $dir/ |grep jvm`;   (grep for the content of your appserver name)
foreach(@jvmlist)
{
chomp($_);
my $loglist=`find $dir/$_/ -type f -name native_stderr.log -size +10k`;  (decide the size to zip)
if(length($loglist) > 0 )
{
print $loglist;
chdir "$dir/$_";
my $dat=`date +%d-%m-%y`;
chomp($dat);
`gzip -c native_stderr.log > nativelog_$dat.gz ; > native_stderr.log`;
}
}
}

Application Edition Rollout in Websphere 8.5

In Websphere 8.5 we can install different edition of the same application.While installing application there is a text box to input the edition number and description.

Once you have installed your editions of application you can rollout the new one to replace the old application without any outage.

I have installed two editions of HelloWorld App deployed in a dynamic cluster.

The edition 1.1 is active now .And  we replace the application with old base edition with Application Edition Controller feature.

Select the Checkbox of application which you want to rollout and click Rollout button.

It will take you to next page where certain configuration is needed.

 Rollout strategy 

Use group rollout to replace editions on members of the target cluster in a group of one. Group rollout is the most typical choice, and is useful when the cluster contains four or more members. Alternatively, you can perform group rollout with a specified group size through scripting. For more information about group rollout, read about application edition management administrative tasks. When the new edition becomes available during group rollout, all requests are directed to the new edition.

Use atomic rollout to replace one edition with another on half of the cluster at a time. This rollout type serves all user requests with a consistent edition of the application. Because all user requests are served a consistent edition, your cluster runs at half capacity. If your cluster has four or more members, consider dividing up the cluster into smaller groups by performing a group rollout. Atomic mode is also used with a single server deployment target. In a single server deployment target, the actions that are carried out against the second half of the cluster are omitted. If you stop your deployment targets before you start atomic rollout, the deployment targets are started when the new edition replaces the active edition regardless of the reset strategy you choose. This procedure provides better availability to the requests that are serviced during the rollout period.

Reset Strategy

Soft reset will restart only the application .If no native libraries is used by your application soft reset is enough.

Hard reset will restart the application server so the native files as well  can be loaded if needed by your application.

Drainage Interval
   Drainage interval is the time to wait for the existing affinity requests to be served .If the requests ended before the drainage interval time ,websphere will not wait till that time it will proceed with application rollout.
If you want it to wait till the mentioned drainage interval you have to set a custome property
appedition.rollout.softreset.fulldrainageinterval to true

Now the base edition is active .The application will be started automatically.

Enable and restore Checkpoints in Websphere 8.5

Checkpoint is a new feature introduced in WAS 8.5.It will be used to restore the data if  we committed the data wrongly.

Two types of checkpoint one is Delta and other is Full.

Full Checkpoint will backup all your respository and it has to be done manually.

Delta checkpoint will  be created automatically once you enable it ,and it will backup only the configuration changes made at the last time.

Checkpoint depth is used to limit how many backup is allowed .Once it crossed the limit it will delete the old backup automatically.

Once you have enabled delta checkpoint you can see under Repository Checkpoints a checkpoint has been created.

To check how it works I deleted a server and saved it to master repository.And I restore it back by selecting the latest checkpoint available in repository.

And it worked the deleted server has been restored.It may ask you to logout of the console to refresh the workspace.And if multiple people working on the console at the same time then the changes made by others will conflict and it will not be saved.