Apache and mod_rewrite

The mod_rewrite module provides a very helpful, very powerful tool for the administration of web sites. As the name implies, it provides a mechanism to rewrite URLs. Here are a few examples where mod_rewrite comes in handy:

• client redesigns their web site and the programming framework uses different URLs than the previous site but the client needs to maintain "friendly" top-level links, such as http://www.client.com/products and http://www.client.com/support
• client removes a lot of content and would like to use a generic "not found" page to inform the user instead of a regular "404 Not found" page
  
• restrict access to certain content based on an environment variable
  
• set a cookie based on the URL
  
• the client has SSL certificates installed on the web server (not the load balancers) and needs to do redirects to HTTPs for certain pages, additionally, they would like to do this in Apache instead of processing the request with the more heavy-weight Tomcat/Jboss/Weblogic app layer.

The manual for mod_rewrite is available online at http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html and contains many examples.

It is important to remember that the rewrite engine checks patterns first, then checks the condition(s) to see if the pattern should be applied. This is a little backwards from traditional thinking where conditions are checked before applying the logic associated with the conditions.
This example was taken from a client with the following requirements:

• a 3rd party site contains a link to a Opsource-managed web site
  
• any requests coming from the 3rd party site should be allowed through
  
• requests coming from the 3rd party site would be distinguished by a special URI string
  
• all other requests to the site should be denied

The following rewrite rules were put in place. Again, the RewriteRule is checked *before* the RewriteConds are checks. In this case, the RewriteRule is looking at ^.* which matches everything.:

RewriteEngine On
#RewriteLog "logs/tac_rewrite.log"
#RewriteLogLevel 4

RewriteCond %{HTTP_REFERER} !^https://www\.heisenbug\.cop/portal/site/index\.jsp
RewriteCond %{REQUEST_URI} !/286482b67b05ad585cfc99996f5158d7
RewriteCond %{HTTP_REFERER} !^http://www\.mysupersite\.cop.*
RewriteRule ^.* /denied/denied.html [L]

The "RewriteEngine On" simply turns on the rewrite processing engine. The Rewrite log directives specify a log that only the rewrite engine uses and the level of information printed in the log. The first RewriteCond rule checks the environment variable HTTP_REFERER, which is the referring web site, is not set to the 3rd party site. This variable is sent by the browser when you click a link on a page. The second RewriteCond rule checks that the special string is, again, not set in the URI. The third RewriteCond rule checks that the referer variable is not the Opsource-managed site itself. This is necessary for when the user clicks links on the Opsource-managed site.  If any of these conditions are true, the user is redirected to a denied page. The [L] at the end of the ReWriteRule means "stop processing any more rules, this is the last rule."

This seems counterintuitive but fulfills all our requirements because only traffic that comes from the 3rd party web site or contains the special URI string will not be redirected to the denied page, in effect, the proper resource will be delivered to the browser. It should be noted that the HTTP_REFERER and the URI string (used in this example) are easily faked and this should *not* be used as a means of securing a web site. The client was made fully aware of this and they opted for it since they only wanted to prevent "casual" browsing.

1. Carve the new LUNs on the new array (Storage)
2. If possible, add the new array and its LUNs to the same switch as the existing array (Storage).
3. Configure the switch to expose the new LUNs to NodeA and NodeB (Storage)
4. Install Powerpath/Multipath and then use disk management to rescan the drives
5. Use the active node to partition and format the disks
6. Use Cluster Admin to create the new physical disk resources and put them into their proper cluster groups
7. Move the Quorum using a temp location
   1. In Cluster Administrator, right click the cluster name
   2. Select Properties
   3. Select the Quorum tab
   4. Use the drop down box to select a temp location for the quorum
8. Delete the existing MSDTC folder
   1. Stop the MSDTC resource
   2. Copy the MSDTC folder from Q: to the final qurom disk target location
   3. Stop the Q: resource
   4. Delete the MSDTC resource
9. Move the quorum to its final location
   1. Go into disk management and change the Q: name to another letter
   2. Use disk management and name the final quorum drive to Q:
   3. Repeat steps 7.1-7.4 to move the quorum to its final destination
10. Recreate the MSDTC resource
    1. Create a new MSDTC resource with the cluster name network name resource and the new Q: as dependencies
    2. Bring the MSDTC resource online
11. Stop the cluster service and the application cluster groups (you can just stop the application resources if you want to move app data one at a time)
12. Move the data from the old disks to the new ones
13. Re-letter the old disks to something outside the current range, but do not remove them yet - you might need to use them in your back out plan
14. Re-letter the new disks to the same drive letter as the old ones (no, you do not have to worry about disk signatures as applications don't understand disk signatures and don't care about anything other than drive letters)
15. Verify that all dependent resources are pointing to the proper physical disk resource.
16. Restart the cluster service
17. Make sure the new drive letters and disk resources are showing up properly in cluster administrator
18. Bring everything back online

Initiating Replication Using the Sites and Services Manager Snap

1. Click Start | Programs | Administrative Tools and then click Active Directory Sites and Services
2. Expand the Sites container in the left pane. Expand the container that represents the name of the site containing the target server that needs to be synchronized with its replication partners.
   
3. Expand the Servers container, and then expand the target server to display the NTDS Settings object
   
4. Click the NTDS Settings object.  The connection objects in the right pane represent the target server's direct replication partners.
   
5. Right-click a connection object in the right pane, and then click Replicate Now

Requirements:
(This guide assumes the following)
Apache 2.2 and Tomcat 7.0 installed and working with defaults settings

• Step 1: Login to the server with Apache 2.2 installed on it
  
• Step 2: Down load the following file mod_jk
• Step 3: Copy the file mod_jk.so to the following folder (%Apache root%\modules)
  
• Step 4: Edit the httpd.conf file (%Apache root%\conf\httpd.conf)
  
• Step 5: Add the following code to the bottom of the file

LoadModule jk_module modules/mod_jk.so

JkWorkersFile conf/workers.properties

JkLogFile logs/mod_jk.log

JkLogLevel error

JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "

JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories

JkRequestLogFormat "%w %V %T"

JKMount /*.jsp example

#example can be renamed but (worker.list=) must be updated in the workers.properites file

• Step 6: Make a new file called workers.properties at (%Apache root%\conf) with the following code
  

  Icon

  Make sure to add host IP and port, and remove <> sections

# Define worker 'example'

worker.list=example # Must be same name as name at the end of JKMount in apache's httpd.conf file

# Set properties for worker 'example' (ajp13)

worker.example.type=ajp13

worker.example.host=<server IP of tomcat server, can be localhost if tomcat is installed on the same server>

worker.example.port=<port number for Tomcat AJP/1.3 connector, Default is 8009>

worker.example.cachesize=10

worker.example.cache_timeout=600

worker.example.socket_keepalive=1

worker.example.recycle_timeout=300

• Step 7: Make a .jsp page to test
  
• Step 8: Use the following code make a file called test.jsp and save (%Tomcat Root%\webapps\test)

<html>

<head>

<title>Tutorial: HelloWorld</title>

</head>

<body>

<h1>Testing Page Load from Tomcat</h1>

JSP page loading from Tomcat

</body>

</html>

Now you are done, any request for a .jsp page that comes into Apache will be served by Tomcat.

Each application server has a slightly different process for enabling remote JMX Access. It's best to consult with your application server for specific instructions.

For a default tomcat install, one can simply add the following line at the top of server/tomcat/bin/catalina.sh after initial comments (remember, many customers or admins modify start up scripts to a great extent, but the principle of enabling JMX remains same)

CATALINA_OPTS="-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=12345 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false"

One can then use JConsole (jconsole is available in openjdk software) to connect to <IP>:12345, where IP has to be replaced with host IP.

Note: You should ensure port 12345 is opened from where the host is monitored. So, if you are would like to monitor JMX values from a third party monitoring such as zenoss, make sure port is opened to zenoss.

Wondering why we used CATALINA_OPTS instead of JAVA_OPTS?

Read the comments in catalina.sh

JAVA_OPTS   (Optional) Java runtime options needs to be used when the "start","stop", or "run" command is executed.

CATALINA_OPTS   (Optional) Java runtime options used when the "start"  or "run" command is executed.

You may encounter following error during tomcat shutdown:

Error: Exception thrown by the agent : java.rmi.server.ExportException : Port
already in use: 12345;nested exception is:    java.net.BindException: Address already in use

To avoid error like this when shutting down tomcat, Port 12345 need not be in use while the instance is shutting down.

We are therefore using CATALINA_OPTS and disabling the exceution of this option during tomcat shutdown via "stop" in catalina.sh.

After the following lines in catalina.sh

elif [ "$1" = "stop" ] ; then

  shift

  FORCE=0

if [ "$1" = "-force" ]; then

    shift

    FORCE=1

  fi

Change

"$_RUNJAVA" $JAVA_OPTS $CATALINA_OPTS \

to

"$_RUNJAVA" $JAVA_OPTS \

This was actually a bug reported in apache site, you can find details for this issue at:

Tomcat shutdown bug while using JMX port

If you need JMX monitoring enabled via zenoss, please refer the following article:

Monitoring Using ZenJMX

System Requirements

• Tomcat 6 or higher
  
• The application's web.xml has must have <distributable/> tag.

Network Requirements

• Have multicast enabled for tomcat to communicate.

Configuring Tomcat for Cluster

1. Add the cluster config inside the <Host> tag. I have attached the cluster config text to this page.
   
   • The only changes that needs to be made is the (name="<Put_application_Name_Here>"). Put the .war file name.
2. export the server.xml file to the servers that are part of the cluster.
   
3. restart all tomcat instances.

To enable a bigger cluster log file you can refer to the following document online at: http://support.microsoft.com/kb/168801

Do note that to fully enable this you have to also reboot the cluster service on ALL nodes for this to work.

The following is a checklist for common items that should be implemented or considered when you need to install a Windows based cluster for a customer:

1. Number of Cluster Nodes - typically this is (2) nodes but can go up to (4) node configurations within OpSource.
   
2. Number of NIC's - Network interfaces are often bonded together for fault tolerance.  But, for a cluster, we usually require additional dedicated interfaces for cluster traffic.  As a result, the recommendation is usually (2) NIC's one for internal cluster traffic and the other NIC for external application traffic.
   
3. Windows OS Type - When installing a cluster, you are REQUIRED to install Windows 2003 Enterrpise 32-bit or 64-bit
   
4. Shared Disk Partition(s) - A part of clustering involves usually a shared volume that is used to "float" amongst the nodes in a given cluster.  Disks that are to be used for clustering then are required to be seen and owned by all nodes participating in the cluster.  So, we typically use hte following mediums to achieve this:
   
   1. DAS Storage via SCSI or SAS cable
      
   2. SAN Storage via Fiber
5. SAN Storage Configuration - SAN storage LUN's should be created as distinctly separate LUN's so the proper redundancy can be achieved when a disk fails.  This will prevent all partitions created for a cluster to be on the SAME LUN and thereby causing a bigger outage event of one of the disks were in a failed state for whatever reason.
   
6. DNS Naming - All names used by the cluster MUST be in DNS as both A and PTR records.  This also includes any virtual or cluster management names setup for use by the cluster.  If these names are not present, naming issues usually result and cause weird connection errors within the cluster.
   
7. Networking Configuration - By nature of the cluster, a minimum of (2) networks should be defined for a proper cluster configuration. One of these networks can be the TRUST VLAN setup by default.  The other usually is a private non-routed network used solely for cluster communication.  If there are (2) nodes in a cluster, you may opt for a cross over cable to achieve this.  Otherwise, configuring a flat VLAN with no routing will suffice. 
8. Uninstalling Internet Explorer Security Component - These add-on components usually cause major issues when installing the application portion of software specifially when an application tries to connect via CIFS or UNC to the remote server to run the installer.  Uninstalling this component takes these sorts of issues out of the picture.
   
9. Security Patches - All cluster nodes should be at the same patch revision to ensure the same operating environment is maintained when failing over from one node to another.
   
10. Creation of AD SSO Objects - For any cluster setup, at a bare minimum, (1) service account is REQUIRED to act as a dedicated account that is not a named user so that the cluster can function across all nodes with the appropriate rights.  Additional accounts are typically added as it applies to the application needs.  For example, MSSQL usually requires 2-3 accounts for various services it maintains.
    
11. Assignment of Admin Rights to AD SSO Objects - Assigning administrative control or the like to the service accounts used for cluster operations is imperative to a properly configured setup.  Avoid adding individual accounts on a per server basis but rather assigning them to AD Security Groups and then assigning those groups access to what is needed on the target cluster nodes.