Laughing at the stony face of gloom

(your instinct can’t be wrong)

Archive for the ‘web servers’ Category

Server Side Includes on IIS 6.0

leave a comment »

As is often the case, a department comes to us with a piece of software they’ve bought; they smile sweetly and say “by the way, we need this installed and working by the end of the week”…

This time around though, it’s some sort of web-based package. And it needs server side includes… turned on… Not usually a problem with IIS as .asp/.aspx pages will (I’m told, and have a vague recollection of) by default do server side includes without anything special needing to be put in place. That’s nice. However this application uses “proper” server side includes (or “historical, outdated and outmoded” server side includes… depending on your point of view), which means .shtml pages … which, by default IIS has no idea what to do with.

So, what do we need to do to remedy this?

Well, first we need to allow the server side extension.

in the IIS manager
computer name
|- Web Service Extensions

Server Side Includes (highlight then click “Allow”)

If there isn’t a Server Side Extension already there, we can add one. Select “Add a new Web Service Extension” ; the extension name will be : Server Side Includes – the required file is ssinc.dll – this is usually located in c:\windows\system32\inetsrv\ssinc.dll

That should be it… except in this case, it’s not.

These files use a “include virtual” directive rather than an “include file” directive (the installation notes, helpfully say

“If you have problems getting the server side includes to work, simply manually change the virtual to file” … sounds simple … except there are 441 shtml files to manually edit… FUN? Not!

(A quick test shows that their solution will work… but I don’t want to make hundreds of edits; so there must be a way of making the virtual directive work…. it is supported by IIS after all… The virtual directive meaning something along the lines of “a directory that exists relative to the virtual directory” )

So … could I make a simple virtual directory for this site ?

computer says… “no”

– I think the problem is that I need to do a virtual directory for each of the folders… let’s try that with one of the pages…

Success!

It looks like, when the include virtual directive is issued, we need to actually have a virtual directory of that name – or something along those lines (I’m guessing here – I’ll do some proper thinking tomorrow on work’s time :) )

Advertisements

Written by Mas

May 20, 2008 at 10:06 pm

Posted in web servers

Tagged with , , ,

Odd apache 404 behaviour

leave a comment »

Oh the legacy systems; just lately we’ve been experiencing a little bit of “what can only be described as” odd behavior. Our Apache server is set up to offer virtual hosts; one of these is a remnant of our yee oldee static site :) For some reason though, the following behavior is being observed.

If you click a link to one of the pages on any site you are thrown to a 404 error page on our primary site.

However…

If you type the url in (or do a “copy link”, “paste (into location bar) and go”) the page loads without issue; subsequent requests – as the page is now cached – resolve fine.

Suspicions
My main suspicion is that some thing’s going a bit askew on the redirect front (see – blame mod_rewrite – just because it is powerful and confusing with it’s regular expressions (but not the sort you hear in bars!))

Detailed setup
We have multiple virtual hosts all being accessed from a primary apache server (say 20 or so); many of these link into our primary http://www.domain (usually with a rewrite/proxy to some location – say http://www.domain/ex/servicename ).

The service that is experiencing the problem was previously known as http://www.some-other-domain (I’ll shorten this ’cause I’m lazy to http://www.sod ) but due to a departmental re-branding is now known as http://www.some-new-domain (and this I’ll shorten to http://www.snd ); however all the content remains the same. Additionally, the http://www.sod and the http://www.snd make use of apache’s ldap authentication to our Active directory service. Additionally, the http://www.sod and the http://www.snd have WebDav publishing enabled (as it saves giving users shell accounts (does anyone other than me call them “shell accounts” still?))

Investigation
Oh, just as I suspected – we have a couple of lines in our virtualhost file for the http://www.snd site.

RewriteCond %{HTTP_REFERER} /ex/servicename
RewriteRule ^/(.*)?$ http://www.domain/$1 [NC,P,R,L]

Let’s remove these lines and give it a whirl!
Yep – everything seems to work. But these lines were put in place for a reason, weren’t they? (You don’t just go adding things willy-nilly to the old apache configs).

A quick ask around reveals no knowledge.

My suspicions are;
1) the site has been effectively decommissioned – this happens – slowly; but direct access has been allowed to give people access to specific areas that are currently unable to be migrated (online training packages and their ilk)
2) someone fugged up, possibly me.

I do need to do some confirmation – and hunting for reasons (should it be doing this? Has the site been decommissioned ? Why haven’t the content providers been told ? yadda yadda)

Solution – long term
Confirm whether or not the site is decommissioned, or whether there was another reason for the rules being put in place. (Contact point: head of Web Team/head of Customer Services)

Solution – short term
Let’s add in some exclusions to try and say “yeah, keep doing that, but not if it’s _these_ pages”

One of the pages is our antivirus software which we allow to be distributed to staff machines (that avoid our standard network for one reason or another) ; it is accessed by a number of pages – but the important thing is, if a request is made for it on the http://www.snd site, that it passes the request straight to the page.

Currently it’s throwing all content back to the http://www.domain site; so we need to put a rewrite rule in before the existing rule.

Something along the lines of

RewriteRule ^/antivirus(.*)?$ – [L]

ta-da :)
Now we just need to find out why it was put there in the first place.
Later!

Written by Mas

May 7, 2008 at 10:00 am

Posted in web servers

Tagged with , , ,

Server talking, talking server talk… reprise… (2)

leave a comment »

Okay – we’ve had a bit of a glitch today; but better late than never… onto meddling with the server. Currently we have tomcat 5 and nothing else running and we seem to have a healthy CPU situation. However, this is a physical box… so what is going to happen when we throw IIS or Apache into the situation? Well, let’s start with apache as I’ve just downloaded that and am raring to do an apache install on a windows production box… I know, I know – not so long ago this would have been frowned upon – but today… well… let’s give it a whirl and see what happens eh?

:)

(installing apache 2.2.8 – using the msi windows installer with openssl)

so – first an install; Like tomcat I’m installing it into the C:\Apache\ folder ; I’m including all the headers and things (to allow other modules to link in – it might be handy – if not – I can always delete them later)

Making it available to all users on port 80 (or just the current user on 8080 – which seems to be already taken – meaning that the tomcat installation has to been shifted onto a different port; in this case 9090 (it doesn’t matter too much about this; ) – moments later – we have an install in place. Brilliant.

Now how to link the apache installation to tomcat ?

There are two methods we currently employ – one being through the mod_jk connectors (as per the IIS install) the other being through apache acting as a proxy. The former is always the preferred; but we’ll see what happens now.

A quick installation check; what do we have?
Okay – in the /modules subdirectory we have 67 modules… do we need all these modules? We might do? Who knows? Well – I would say – as this is going to be a “front facing server install” we’ll see what we need (so that’s the common ones – mod proxy, mod rewrite, mod openss yadda yadda yadda; and a few odds and sods – whatever apache considers “it’s essential core” :) – I’ll have to check… by default, apache’s httpd.conf has the following included

LoadModule actions_module modules/mod_actions.so
LoadModule alias_module modules/mod_alias.so
LoadModule asis_module modules/mod_asis.so
LoadModule auth_basic_module modules/mod_auth_basic.so
LoadModule authn_default_module modules/mod_authn_default.so
LoadModule authn_file_module modules/mod_authn_file.so
LoadModule authz_default_module modules/mod_authz_default.so
LoadModule authz_groupfile_module modules/mod_authz_groupfile.so
LoadModule authz_host_module modules/mod_authz_host.so
LoadModule authz_user_module modules/mod_authz_user.so
LoadModule autoindex_module modules/mod_autoindex.so
LoadModule cgi_module modules/mod_cgi.so
LoadModule dir_module modules/mod_dir.so
LoadModule env_module modules/mod_env.so
LoadModule include_module modules/mod_include.so
LoadModule isapi_module modules/mod_isapi.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule mime_module modules/mod_mime.so
LoadModule negotiation_module modules/mod_negotiation.so
LoadModule setenvif_module modules/mod_setenvif.so

(yeah, I know, I was saying all that in parenthesis; and I know I was being lazy – oh cut and paste – my typing fingers are in your debt!!))

One of the things I dislike about the “default” apache setup, is it’s use of conditionals – “if this, if that, if the other”… I do so prefer to explicitly state “load this module, use this rule” – but that’s me; each to their own :)

Reading through the “Using apache with windows” page there are a few oddities to be aware of, not least that meddling with the httpd.conf file when the service is running could lead to issues (as, due to way apache/windows works, it has a single parent process and a child process, which, on creation re-reads the httpd.conf (without needing a(n apache) server restart)!); Apache can, it seem, load isapi modules (yay! (or nay,yay)) but cannot load filters (“mod_isapi” notes)… hmm… I’d better check how it does the aj13 connector to tomcat… ah… no worries – from the notes on the “ftp/apache/tomcat/tomcat-connectors/jk/binaries/win32/jk-1.2.26/” folder on your selected mirror :
mod_jk-1.2.26-apache-2.2.4.so is for Apache 2.2, and works with Apache 2.2.4 and later.
Rename to mod_jk.so before putting it in your
Apache2.2/modules directory.

phew. I was worried there :)

I’ll continue this thought tomorrow I think – it’s almost 5 already! Where does the time go (and why am I never invited :) ?)
Laters

Written by Mas

May 6, 2008 at 3:49 pm

Posted in web servers

Tagged with , ,

Server talking, talking server talk… reprise… (1)

leave a comment »

After getting our Tomcat5 / IIS6 installation up and running, we’ve noticed that we’re having a high CPU utilization; for 90% of the time the tomcat process is hitting %99 CPU usage. This is a bit of an issue as we aren’t planning “single server, single process”… So, we’re now doing some testing – to see

1) if we can replicate the issue

2) if we can make a solution
(proposed solutions so far – use Apache in front – don’t use any web server in front of Tomcat … )

The process:

1) download tomcat, java et al.
2) Install it :)

This time around (it’s hardly been a month) and the java version is now jdk1.6.0_06.

Java is installed to c:\java\jdk1.6.0_6 and C:\Java\jre1.6.0_06\
(no netbeans this time around – I don’t think they’re actually needed for what we want to do)

The Tomcat version is still apache-tomcat-5.5.26 (much slower turn-around?)

Tomcat is installed to C:\Apache\Tomcat_5.5

runtime is set to point to c:\java\jre1.6.0_06

Reading through tomcat notes (that I might have previously missed); Tomcat no-longer needs the full java jdk/sdk ( a mental note to be made, to myself, for future installations)

It looks like there are issues with JNI (Genie?) applications – I wonder if that could be causing some of the problems we’ve been having… -ponders-

Odd; we seem unable to access the server … I wonder if someone’s blocking 8080 on the firewall… ponders… oh well, it’ll wait until next week now

Written by Mas

May 2, 2008 at 3:56 pm

Posted in web servers

Tagged with , ,

Tomcat install (under linux) – part (2)

with 4 comments

Well, that was lunch… back to the install.

After all that work, we should have a working version of tomcat. However, we don’t have any users set up – so how do we manage our applications (etc) ? Well, first things first, let’s create a role in the

[tomcat root]/conf/tomcat-users.xml file.

it should look something like this

<?xml version=’1.0′ encoding=’utf-8′?>
<tomcat-users>
<role rolename=”manager”/>
<user username=”[pick a name]” password=”[pick a password]” roles=”manager” />
</tomcat-users>

once you have made the changes, you’ll need to restart tomcat
/[tomcat root]/bin/shutdown.sh

(wait a few moments – you can type ps guax|grep java to see if the process has stopped before running)

/[tomcat root]/bin/startup.sh

to start the service up again.

You can check in the /[tomcat root]/logs/catalina.out file to see if there are any errors generated .

Written by Mas

April 21, 2008 at 4:24 pm

Posted in web servers

Tagged with , ,

Tomcat Install (under linux) – part (1)

with 2 comments

Introduction

Well, here we are again :) Installations! This time I’m installing Tomcat (not sure which version yet – possibly 6.x ) on a linux box. Of course, there’s a bit of head scratching and finding out exactly what we need to do prior to install.

So, we have a vanilla system. It has apache running but has never seen hide nor hair of anything like java. So first I have to download a jdk – sounds simple ? Well, it should be – but like many people I tend to get a bit confused when it comes to navigating Sun’s java site. So many varieties of jdk, sdk, jre with or without beans and whatever new “technological methods” Sun have come up with. Occasionally conflicting documentation (search for jdk linux – you get instructions telling you to install obsolete software … or is it obsolete ? I’ve no idea)

Installing Java

As I’m not sure I have access to compilers and the like (a legacy policy of never putting any sort of development malarkey on a front-facing server) I’m going to have to pick a binary install; which should work fine without any issues… I hope!

(fortunately, if there are any issues – this is a soon-to-be-decommissioned box that is just sitting around spinning it’s wheels, so to speak; so it’s not going to take down any “mission critical” applications … at least… it shouldn’t do :) )

In this instance, I’ve decided upon the Linux binary distribution of the Java SE Development Kit 6 (update 6) (I’d give a link to the page on java.sun.com but that looks to be generated via session variables on a by-user basis)

jdk-6u6-linux-i586.bin

(from the page http://java.sun.com/j2se/1.5.0/install_jdk150-nb40_linux.html we are told to set the permissions on the file so we can execute it; they say chmod 755 jdk*.bin although my preferred method is chmod u+x jdk*.bin (but that’s just me … oh, and I’m just being lazy – you can type the whole jdk filename in if you want (or if you have lots of jdk’s in the folder and don’t want them all to be executable :) )))

let’s run the executable

./jdk-6u6-linux-i586.bin

Good grief ! That’s a long user agreement… I really should read it one of these days, I heard rumours of them smuggling clauses allowing them to take your first born son … but… life’s too short :) and generally they could be summarized into a simple statement

“you agree to not do anything naughty – like stealing things , we’ll find out and catch you you know.”

to which, we have to say “yes” (surely we should be able to say “no, we don’t agree” and still use the software? Are these things really binding? I don’t know… anyway… I’m digressing )
of course, once it gets to the end “Java(TM) SE Development Kit 6 successfully installed”

So what have I got ?

in the directory I ran the jdk in, there is now a folder “jdk1.6.0_06” ; to make upgrades (hopefully) easier, I’ll make a symbolic link to this directory

ln -s jdk1.6.0_06 java

I’ll now set up some environment variables (so we know where to find things)

emacs /etc/profile

(or feel free to use vi or whichever text editor you prefer)
Assuming you’ve not done anything to tweak the default profile, there will be a line in the file that says something like

export PATH DISPLAY LESS TERM PS1 PS2

before this line I’ll add the following

JAVA_HOME=/[path to java install eg. /usr/local/java]
PATH=$JAVA_HOME/bin:$PATH
CLASSPATH=$JAVA_HOME/lib

and then on the end of this line I’ll add JAVA_HOME and CLASSPATH
i.e.

export PATH DISPLAY LESS TERM PS1 PS2 JAVA_HOME CLASSPATH

that done, I can type . /etc/profile which’ll re-set the environment variables (which can be proven by typing java -version ); which in turn means we can now run java. Now to install tomcat. Let’s try tomcat 6…

Installing Tomcat 6

First to download our copy of tomcat. http://tomcat.apache.org/download-60.cgi (Question: Why aren’t there any “linux” versions listed ? Answer: Because it’s java! The same package as is installed on windows will work on Macs, unix boxes and all sorts of places – probably even your hand-held device (assuming it has space for it!)

We’ll download the tar.gz version (tar being a unix standard “tape archive” (remember unix principles 101?) and gz being the gzip compression format (as tar archives are uncompressed by default – remember? Were you listening ? :) )) at the moment, the latest archive is http://www.smudge-it.co.uk/pub/apache/tomcat/tomcat-6/v6.0.16/bin/apache-tomcat-6.0.16.tar.gz (note that this is linking to one of the many mirror sites used for distribution of the apache/jakarta projects)

change directory to your installation folder – e.g. cd /usr/local
decompress the archive – gunzip apache-tomcat-6.0.16.tar.gz
untar the archive – tar -xmvf apache-tomcat-6.0.16.tar

(alternatively, you can miss out the decompressing stage and instead use tar -xmzvf (the z is for decompress gzip format)

we’ll make another symbolic link now, to make it (hopefully) easier to upgrade

ln -s apache-tomcat-6.0.16 tomcat

in the tomcat directory there will be a folder called “RUNNING.txt” – the following notes are derived from that…

First I’ll edit the /etc/profile file again and add in a new environment variable for “CATALINA_HOME” (this will point to the installation folder) and ensure that the variable gets exported – similar to the JAVA_HOME

in theory, we should now be able to start up tomcat and see it running on port 8080 – cd $CATALINA_HOME/bin and type ./startup.sh

When I tried this just, it complained about being unable to find a file … “setclasspath.sh” – which is strange as it is right there… Let’s try and troubleshoot a little bit…

(A quick search online provides an answer to this – on the tomcat wiki )

We have to edit the catalina.sh and setclasspath.sh files and add the following lines (to the beginning)

BASEDIR=/[path to your tomcat install]
CATALINA_HOME=[/path to your tomcat install]

we can then try again – cd /path to tomcat/bin
./startup.sh

if everything works okay, we should then be able to type

ps guax | grep java

which’ll show the process (note, versions of ps differ from system to system; so if you get an error, you can always try ps -guax or some other combination – remember the system manual is your friend :) man ps )

we can now try and display the site – in a web browser, point it to the server on port 8080 – if everything has worked (as it has in my case) you’ll get the default tomcat server page/documentation/examples.

And as everything has worked so far – I think it’s a good time to take lunch :)
More later!

Written by Mas

April 21, 2008 at 12:15 pm

Posted in web servers

Tagged with , ,

Server talking, talking server talk; talking about things they need to do…

with 7 comments

(with apologies to Rodgers and Hammerstein for appropriating the song “Happy talk” (from South Pacific) for my subject title :) )

Over the past couple of weeks I’ve been trying to get an installation of Tomcat talking with IIS 6. Something which I’ve found all sorts of documentation about, most of it misleading – or not appropriate to the versions I was attempting to get to communicate.

It’s the joys of being a developer with responsibility for the various servers, someone buys an application and comes to me and says “make it work” – I read through the supplier provided instructions and announce, “if it is as simple as these instructions make it look… well, it’ll only take 5 minutes to do”

Of course, it’s never as easy as the instructions make it look.

And it doesn’t help when the supply eventually gets back to us and tells us “actually, the instructions we gave you are completely wrong and hideously out of date”

Never mind though – I got it all working (and in case I ever need to do it again, here’s how)

Conventions

in italics – text in italics will indicate a comment or note following a command or statement. e.g. doing this makes it work

in bold – text in bold will indicate information which is installation specific. e.g. version numbers

underlined – underlined text will be used to highlight a choice e.g. select the security tab

Installing Tomcat 5.x and getting it to communicate with IIS 6.x

You will need;

  1. A current Java JDK (note – JDK – not JRE) (in this example it is 1.5.0.15)
    Download from http://java.sun.com/javase/downloads/index.jsp
  2. The current, stable, version of Tomcat 5 (in this example it is 5.5.26 )
    Download from http://tomcat.apache.org/download-55.cgi
  3. The currrent, stable, isapi filter (Tomcat Connectors) (in this example it is 1.2.26 (December 2007))
    Download from http://tomcat.apache.org/download-connectors.cgi

When it comes to performing installations, there is a mixture of opinions as to where to place the files. By default, the applications want to install into c:\program files\…. etc. using folders with spaces. During my tests I did have issues with paths (and including paths with spaces within quotes didn’t really make too much difference); some of the (online) notes I found made use of installation directories without spaces – and when I followed suit I experienced much less in the way of issues – so it is my preferred way of doing things, if only because I know I can make things work that way :)

1 Install Java

Simply run the Java installer; select the directory “c:\java\jdk version” for the root; if you’re installing the netbeans component (and I think they all come with the netbeans component) then I suggest installing it under “c:\java\netbeans version

Set the environment variables for JAVA_HOME. In windows XP/2003 this can be done by right clicking on the “my computer” icon on the desktop, selecting the advanced tab, then clicking the Environment Variables button. We want to add the variable as a System Variable so we would click the New button under the System variables section.

You add the Variable name as JAVA_HOME
You add the Variable value as c:\java\jdk version (or wherever it was you decided to install java)

You can also edit the PATH environment variable to point to the JAVA applications. (Highlight PATH on the list and select Edit. Assuming there isn’t already anything pointing to a “java” location, add the following to the end of the line.

;c:\java\jdk version\bin

This will ensure you’re using the correct version of JAVA. (if there was a previous entry, this should be removed and replaced by this one)

2 Install Tomcat

Run the tomcat installer process; make sure the installer points to the version of JAVA we’ve just installed (the environment variable for JAVA_HOME that we set should ensure this, but it’s always good to make sure :) ). Install Tomcat to the directory c:\Tomcat_tomcat version number (without spaces – e.g. c:\Tomcat_5.5.26)
When you’re prompted for an administration user you can accept the standard “admin” (although I tend to change it to something less standard) and enter a password – make a note of these details as you’ll need them to access the management console.

Add the following environment variables; TOMCAT_HOME and CATALINA_HOME
(using the same method as used for JAVA_HOME add an entry in the system variables for TOMCAT_HOME and CATALINA_HOME – both should have their values set to c:\Tomcat_tomcat version number

You should have tomcat running, by default, on port 8080. You should have the “Apache Tomcat” controller application appearing in the windows system tray. If every thing is working as it should, this should have a little green arrow in it identifying that Tomcat is running. If it doesn’t, there could be a conflict. A quick (and easy) test is to start up a web browser (I use, and recommend, firefox – but each to their own) and point it at our Tomcat Server. If it’s on the same machine, then http://localhost:8080 should pull up the “welcome to tomcat” webpage
. If it pulls anything else up then this could be due to local dns issues (check you don’t have localhost aliased to something odd in the file c:\windows\system32\drivers\etc\hosts ) or other services running on the server.

Assuming Tomcat is working, we can now look at making it talk with IIS.

3 Install the Tomcat Connector

Part 1; Tomcat side Installation

While it doesn’t particularly matter where you install the connectors, historically (and logically) it is best to install them within the same folders that Tomcat has been installed in.

Create a directory c:\Tomcat_tomcat version number\Connectors
copy into this folder the isapi filter (also referred to as a jkConnector) you acquired earlier. ( isapi_redirect-1.2.26.dll )

You then need to create a configuration for the connector. You may often find references to doing this via meddling with the windows registry keys. While this may work (I had no joy with this), it is most definitely not a way I’d recommend anyone configure anything. The preferred method is to create a configuration file in the same folder as the Tomcat Connector. This will have exactly the same name as the dll file, but with “properties” as it’s extension instead of dll.

e.g.
using the Connector isapi_redirect-1.2.26.dll means you’ll need to create a file called isapi_redirect-1.2.26.properties

Using a “property” file rather than manipulating registry keys means that multiple filters can be installed and used (which has a benefit when you need to upgrade, you can test out the configuration without damaging the existing service etc. )

Into the properties file (edit in notepad) add the following settings

# Configuration file for the Jakarta ISAPI Redirector
# The path to the ISAPI Redirector Extension, relative to the website
# This must be in a virtual directory with execute privileges

extension_uri=/jakarta/isapi_redirect-connector version.dll

# Full path to the log file for the ISAPI Redirector
log_file=c:\tomcat_
tomcat version\logs\isapi_redirect.log

# Log level (debug, info, warn, error or trace)
log_level=warn

# Full path to the workers.properties file
worker_file=c:\tomcat_tomcat version\conf\workers.properties

# Full path to the uriworkermap.properties file
worker_mount_file=c:\tomcat_
tomcat version\conf\uriworkermap.properties

I’ll try and explain what these all do.

  • extension_uri – this points to the location where the connector will be loaded into IIS
  • log_file – the location of the log file; by default I try and put it with the other Tomcat logs to make it easy to access and compare requests.
  • log_level – when you’re first setting this up, you may want to set it to debug to get full and detailed logs generated; just make sure you drop it back to warn when you go to a production environment or you’ll find logs spiraling out of control :)
  • worker_file – the path to the workers.properties file; this is essentially where we set up all the attributes (workers?) for this connector (in my mind it would make sense to have an option to amalgamate this into the current properties file – but never mind – there’s usually good reasons for multiple configure files (and I don’t just mean to separate the men from the boys :) )
  • worker_mount_file – the path to the uriworkermap.properties file; this is the file where you associate applications to specific workers. If your webapp doesn’t have an entry in here you’ll not be able to access it through IIS

As you’ve created links to property files, you’ll need to make sure they exist. By default they won’t – so don’t expect anything to work just yet :)

Create the workers.properties file in c:\Tomcat_tomcat version\conf containing the following.

# Define 1 real worker using ajp13
worker.list=worker1

# Set properties for worker1 (ajp13)

worker.worker1.type=ajp13
worker.worker1.host=localhost
worker.worker1.port=8009

This is the most basic configuration for the worker.properties; in case it isn’t obvious what is happening here I’ll try and explain. You’re saying you have a single worker (you can have multiple workers, and then do things like load balance etc. with them). It is using the ajp13 protocol (there were previous protocols, but this is the current preferred standard – more details (technical) http://tomcat.apache.org/connectors-doc-archive/jk2/common/AJPv13.html) and is running on the local host computer on port 8009. (Which means IIS will try and communicate to Tomcat through this port)

Much more information about the workers.properties can be found at the Apache/Jakarta site http://tomcat.apache.org/connectors-doc/reference/workers.html

Create a uriworkermap.properties file in the same c:\Tomcat_tomcat version\conf folder containing the following

/|*=worker1

(yes, just a single line!!!)
What this does is say “any content requested should be given to worker1”. Note that the worker names should all be consistent otherwise nobody knows who they’re talking to.

Obviously, once we have everything working we will want to change this; we will most likely not want to pass all content to the tomcat server, rather limiting things to the specific webapps we’ve constructed and want to deploy to the outside world.

e.g.

/my_web_app|*=workername

(will pass the specific “my_web_app” to whichever worker you’ve decided to associate it with)
much more information can be found at the Apache/Jakarta site http://tomcat.apache.org/connectors-doc/reference/uriworkermap.html

That should be all you need to do for Tomcat to reveal itself (ready for IIS); you can restart tomcat if you like and attempt to telnet to port 8009 (there won’t be anything interesting to see – you should get a connection which quickly closes – if I can work out (or find) a way to perform a useful test, I’ll add it later)

Part 2; IIS side installation

As with all IIS sites, you need a root directory; security/backup concerns will often have you creating a folder away from the O/S drive – e.g. D:\Tomcat-IIS-site . Once this is created you can open the IIS Manager [found via: Start Menu, Administrator Tools, Internet Information Services Manager (IIS)]

Expand the Tree in the left hand window so you have the following exposed.

Internet Information Services
[-]—-This server name (e.g. IIS-server-01) (local computer)
[+] Application Pools
[ -] Web Sites
[+] Default Web Site
[+] Web Service Extensions

[Right click] on Default Web Site and select stop ; the default site will run on port 80 which is where we’ll want our site running. Obviously if your server is already providing a number of services you’ll not want to stop the default site as this would be a bit disastrous for your clients!!

Now [Right Click] on Web Sites and chose New, Web site ; call it something obvious (e.g. IIS/Tomcat site ) point the directory root to the root directory you created earlier (e.g. D:\Tomcat-IIS_site ) – assuming that this will be the only service running on this server (or you have a specific domain name set up for this site) you can chose to run on all unassigned IP Addresses and port 80. If you have other things running on this service, or maybe want to perform a dummy “test” installation, you may chose to install this site on a different port that’s available.

Now [Right Click] on the new site, and select [New] , [virtual directory] ; give it a name of jakarta (remember – you gave it this name back when you created the properties config file for the tomcat connector?) and point the directory to the one containing the Tomcat connector. ( c:\tomcat_tomcat version\connectors ); this directory will need to have execute access

Next you need to set up the connector to act as a filter for IIS. First [left click] on Web Service Extensions – on the right hand pane you’ll have a list of the currently installed isapi filters (allowed and disallowed). On the left of this pane there will be a link to add a new Web Service Extension select this and type jakarta as the extension name, then select [Add] and browse to the c:\Tomcat_tomcat version\Connectors folder and select the isapi_redirect-version number.dll ; tick the set extension to allowed checkbox and okay everything. You should now have the jakarta filter listed as allowed in the extension list.

Now [right click] on your website, select properties and chose the ISAPI Filters tab; select [add] and enter a filter name of jakarta (as per the connector properties file created earlier) and point the executable to the dll in the c:\tomcat_tomcat version number\Connectors directory

In the pane you should now see something along the lines of
Status Filter name Priority
unknown jakarta unknown

if you okay everything, [right click] on the web site name, select stop followed by start (once it has stopped) and then go back to the ISAPI Filters you should see that the Status will be replaced with an arrow – hopefully a green arrow pointing up. If you have a red arrow pointing down then something has gone horribly wrong; retrace your steps. It may be an idea to confirm that the SYSTEM and anonymous accounts that IIS uses have read access to the folder and files in the Tomcat Connectors directory.

If you have no arrow – don’t worry; IIS is just being a bit slow. Test the site again using your browser of choice, only this time without specifying a port. i.e. http://localhost/
If you were using the “pass everything to tomcat” rules in the uriworkermap.properties file then you should be presented with the “welcome to tomcat” page – the same as you’d receive if you pointed your browser to http://localhost:8080/ .Assuming this works, your tomcat/IIS installation is a success. Well done. Have a cup of tea and a slice of cake (this is optional)

Since the installation I’ve been having issues with CPU utilization on this set-up. I will follow up this with a post regarding tweaks that have been made (hopefully successfully) to improve performance. I might post an additional note regarding testing and troubleshooting. But that’s for another day. Right now I’m going to look at getting IIS 6 and Tomcat 6 talking. My track record so far is II6 and Tomcat 4 – failed to talk; IIS 6 and Tomcat 5 – talk happily; IIS6 and Tomcat 6 – failed to talk (so far; although someone else did the initial installs)

Technorati Tags: ,

Written by Mas

April 3, 2008 at 2:16 pm

Posted in web servers

Tagged with ,