More functions and features provided by OpenSSL

For the following examples, here's a list of the files and what they represent:

1. cert.p12 = a PKCS#12 encoded certificate and key pair. This is one of the formats used by IIS.
   
2. cert.crt = a PEM encoded certificate. This is one of the formats used by Apache and the Load balancers.
   
3. cert.key and cert2.key = a PEM encoded key. This is one of the formats used by Apache and the Load balancers.
   
4. cert.csr = a certificate request. This is what gets sent to the CA for signing.

All examples assume you have OpenSSL installed somewhere on your PATH.

Converting from PEM (Apache/Load balancer) to PKCS#12 (IIS)

openssl pkcs12 -export -out cert.p12 -inkey cert.key -in cert.crt

Converting from PKCS#12 (IIS) to PEM (Apache/Load balancer)

This is a 2-step process. The first extracts the cert. The second extracts the key. Since the PKCS#12 certificate was encrypted during export, you'll need to provide that password. You'll be prompted for another password during the key extraction step. This will encrypt the resulting key but you can remove the password, as detailed later.

openssl pkcs12 -clcerts -nokeys -in cert.p12 -out cert.crt
openssl pkcs12 -nocerts -in cert.p12 -out cert.key

Removing a password from a key

openssl rsa -in cert.key -out cert2.key

Adding a password to a key

openssl rsa -in cert.key -des3 -out cert2.key

Displaying the contents of a Certificate Request

openssl req -in cert.csr -text

Displaying the contents of a self-signed certificate

openssl x509 -in cert.crt -text

By default, you can check the MMC that is provided in Windows to get a general view of the replication status. However, this is very basic at best. If you want to see a more detailed view of this all you can go to any of the systems apart of the DFS configuration/replication and run the following command:

C:\dfsrdiag replicationstate /v

With the introduction of Windows 2008, several improvements were introduced to improve upon Microsoft's cluster technology. In order to support a multisite cluster configuration, changes in how a cluster performs its inter cluster communication or health-checks was updated. Configuring these settings is done from the command line and is detailed below:

The following links below detail this process in more detail for your consumption.

To configure heartbeat and DNS settings in a multi-site failover cluster

1. On a node in the cluster, open a Command Prompt window.
   
2. Determine whether to change the heartbeat settings, for nodes on a common subnet, nodes communicating across subnets, or both. For background information about heartbeat settings, see Requirements and Recommendations for a Multi-Site Failover Cluster (http://go.microsoft.com/fwlink/?LinkId=129109).
   By default, regardless of subnet configuration, heartbeat frequency (also known as subnet delay) is once every second (1000 milliseconds). The range for heartbeat frequency is once every 250-2000 milliseconds on a common subnet, and 250-4000 milliseconds across subnets. By default, when a node misses a series of 5 heartbeats, another node will initiate failover, and the range for this value (also known as subnet threshold) is from 3 through 10.
   
3. If in step 2 you decided to change the heartbeat settings, run one or more of the following commands. Note that the first two commands affect nodes on a common subnet and the second two commands affect communication across subnets:

   cluster /cluster:<ClusterName> /prop SameSubnetDelay=<value>

   cluster /cluster:<ClusterName> /prop SameSubnetThreshold=<value>

   cluster /cluster:<ClusterName> /prop CrossSubnetDelay=<value>

   cluster /cluster:<ClusterName> /prop CrossSubnetThreshold=<value>

4. To confirm that the heartbeat settings are set as intended, run the following command:

   cluster /cluster:<ClusterName> /prop

5. View the network names of resources that are currently configured on the cluster by running the following command:

   cluster /cluster:<ClusterName> res

6. Determine which IP addresses should be registered in DNS for your cluster: either all IP addresses on which a network name resource depends, or only the IP address that successfully comes online (that is, the IP address on the subnet of the node that currently owns that network name resource). For background information about this setting, see Requirements and Recommendations for a Multi-Site Failover Cluster http://go.microsoft.com/fwlink/?LinkId=129109.
   The default is to register only the IP address that successfully comes online.
   
7. Choose and run only one of the following commands, substituting the name of the resource for <NetworkNameResource>:
   
   • To cause all IP addresses on which a network name resource depends to be registered, run the following command:

     cluster /cluster:<ClusterName> res <NetworkNameResource> /priv RegisterAllProvidersIP=1

   • To cause only the IP address that successfully comes online to be registered, run the following command:

     cluster /cluster:<ClusterName> res <NetworkNameResource> /priv RegisterAllProvidersIP=0

8. Determine the value to use for the DNS setting called Time to Live (TTL). As an example, the value recommended for Office Exchange Server 2007 is five minutes, which equals 300 seconds. If you do not adjust the TTL value, it defaults to 20 minutes (1200 seconds). For background information about TTL, see Requirements and Recommendations for a Multi-Site Failover Cluster http://go.microsoft.com/fwlink/?LinkId=129109.
   
9. To change the TTL setting, run the following command:

   cluster /cluster:<ClusterName> res <NetworkNameResource> /priv HostRecordTTL=<TimeInSeconds>

where <NetworkNameResource> is the name of the clustered resource that you want to set the TTL value for, and <TimeInSeconds> is the value you want to set for TTL.

1. To confirm that all the DNS settings are set as intended for a given network name resource, run the following command:

cluster /cluster:<ClusterName> res <NetworkNameResource> /priv

1. Take the clustered service or application offline and bring it back online, using the method that you are most familiar with. For example, to use the Failover Cluster Management snap-in, under Services and Applications, right-click the service or application and click Take this service or application offline, then right-click again and click Bring this service or application online.

The full article as well as additional resources are listed below for your reference:

Configuring thresholds for Heartbeat Network:

• http://technet.microsoft.com/en-us/library/dd197562%28WS.10%29.aspx

Information on Windows 2008 and changes to the heartbeat algorithm:

• http://blogs.technet.com/b/askcore/archive/2010/02/12/windows-server-2008-failover-clusters-networking-part-1.aspx
• http://blogs.technet.com/b/askcore/archive/2010/02/22/windows-server-2008-failover-clusters-networking-part-2.aspx
• http://blogs.technet.com/b/askcore/archive/2010/02/25/windows-server-2008-failover-clusters-networking-part-3.aspx

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.