|
|
|
|
|||||
|
|
|
|||
|
|
|
|
|
|||||||||||||||||||||||||||||||||||||||||
|
|
|
|||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||
Author: Peter Bortas <peter@roxen.com>
Last modified: 2000-12-04 21:34:08
One of the big problems facing administrators of any kind, web server administrators included, is legacy code. Code that works but runs in environments that are about to become extinct. This article will teach you how to migrate from older versions of Roxen (or from other web servers) to Roxen 2 without losing legacy applications in the process and without having to rewrite anything. This article should be understandable to any Roxen administrator. The easy way out
Roxen 2.0 and up uses RXML2. RXML2 comes with a lot of advantages when compared with old RXML, but it is incompatible with old RXML applications. There is an easy way to solve this: Just add the Old RXML compatibility module.This solution isn't perfect though. The compatibility module adds a lot of overhead to the RXML parsing. What we want is good, fast and clean XML-compliant RXML2 in our new applications.
So, how do we solve this?
The author, Peter Bortas
<peter@roxen.com>
The best of both worlds
One answer that leaps out is that we could keep the old server. It ran the code yesterday, so it should work tomorrow too, right?And that is basically correct, so let's work with it as a base. Lets keep the old server around and let the new server silently ask the old one what what to do about old legacy code. This way we wouldn't have to change anything.
The "HTTP Relay" module combined with the "Index files only" module lets us do just that. By specifying a few simple patterns we have transformed our Roxen WebServer 2.1 into a fast frontend for the other servers.
Setting up
The first thing we do is to rebind the old server to a nonstandard port. We can't have it binding the port our new server is supposed to use. You could of course do it after having set everything up, but for the purpose of this article I will suppose that it is done before everything else. After that, set up a Roxen 2.1 and bind it to the port the old server was answering just a few moments ago. If you intend it to replace an old Roxen 1.3 server you could also copy the old configuration files for the sites. In this case, remember to remove the RXML compatibility module that will automatically be added.The first and easiest method to set things up is to mount a separate directory for the filesystem for the new server and then reroute any files not found in this directory to the old server. To do this we must first make sure that the server does not make directory listings in directories without an index file as there could be an index file on the old server. Do this by removing the "Directory Listings" module from the 2.1 server, then add the "Index files only" module instead.
Now that that is fixed it's time to do the actual relaying. Add an "HTTP Relay module" (some versions have the postfix ", take 2") and enter the settings tab for this module. The "Relay patterns" setting is where we decide what should be requested from other servers. To begin with just add the entry:
"LAST" means that this pattern should be used when no file is found. "LOCATION /" means that it should be used for all requests beginning with "/", or put another way: All requests. What you have now is a perfectly working setup, but until you start moving things manually from the old filesystems directory to the new directory everything will be served by the old, slower server. You also have to educate users about where they should put their files and what effect this will have. I for one want all my images and other static material automatically handled by the faster frontend server.
Extension based relay
So, let's keep our working setup, but remount the filesystem in the new server to use the same directory as the old server. As all files will be found by the frontend the old server will just be running idle in the background except for making the occasional directory listing. All our legacy code is served by the frontend server and we just removed the RXML compatibility module. Time to come up with a new solution to the problem.Let's assume that the extensions .html and .rxml was used for rxml-parsed pages on the old server, as this is the default. Now, since the shiny new RXML parser in Roxen WebServer 2 is XML-compliant .xml would seem a resonable extension for new RXML applications.
We begin by adding two entries to the "Relay patterns" in the "HTTP Relay" module:
The EXTENSION rule matches files with the given suffix. As there is no LAST here the rules will always apply regardless of existence of files in the local filesystem. All requests with extension html or rxml will now be handled by the old server, but we still have some clean up to do. First, make sure that the "Index files" setting in the "Index files only" module only lists "index.xml", since we want "index.html" and "index.rxml" to be handled by the old server. That LAST directive in the relay module will take care of the rest.
Next on the list is to make sure the setting "Extensions to parse" in the "RXML 2 parser" module lists xml as one of them. Normally it will, but if you used an old Roxen configuration as base it might not. It doesn't matter if additional extensions (including html and rxml) are listed here, because those will be relayed to the old server regardless. And lastly, .xml-pages should now be sent to the client as normal HTML pages after the parsing, so add the line
to the "Content types" module's "Extensions" setting in the 2.1 server. More sources
The relay module can of course relay material from more sources than one. One example could be if you would want to run ASP applications on a separate machine. A one line addition to the patterns already configured would fix this:
Several other approaches to relaying could be taken here. For example RXML-parsing the relayed data or relaying specified directories, but this is beyond the scope if this article.
