» blog.e-shell.org

Apache configuration

As I've told you, I've been using Apache as the frontend for Zope servers for a while, this could be an example VirtualHost configuration in Apache for my myploneserver site:

ServerAdmin my@email.acc
ServerName myploneserver.com
ServerAlias www.myploneserver.com

RewriteEngine On
RewriteRule ^/(.*) \
      http://localhost:8080/VirtualHostBase/http/%{SERVER_NAME}:80/myploneserver/VirtualHostRoot/$1 [L,P]

ErrorLog /var/log/apache22/myploneserver-error_log
CustomLog /var/log/apache22/myploneserver-access_log combined

This code goes actually between the VirtualHost tags of your Apache configuration and it is a minimal version of the configuration you need for your Apache to be a frontend to your Plone site.

The interesting part of it (for this article at least) is:

RewriteRule ^/(.*) \
      http://localhost:8080/VirtualHostBase/http/%{SERVER_NAME}:80/myploneserver/VirtualHostRoot/$1 [L,P]

This is the magic that makes Apache to forward the incoming requests for your website to the Zope backend, using the so-called VirtualHostMonster, and this is the rule we have to translate/adapt in our Cherokee configuration to make it works as the frontend instead of Apache.

Entering the cherokee admin

To configure Cherokee you have to use the cherokee-admin, a webapp where you can modify almost anything in your web server configuration.

To start the webapp just use the cherokee-admin command-line tool:

cherokee-admin -b

(using the -b parameter will force the admin to listen on all network interfaces and ip addresses of the server and not only on localhost, which is useful if you are managing a remote server and you don't want to mess with SSH tunnels for example).

Once the admin is started, you will see a One-Time-Password on screen and you can connect to the admin on http://your-server-ip:9090

Use admin and the One-Time-Password to log in and you will see something like:

Adding the source

So, as soon as you have the admin in front of you, click on the sources link located on the main menu you can see on the top side of the admin. You will see something like this:

In my case there are already some other sources in there, yours will be (probably) empty.

So, what is this about sources? A source in Cherokee is a backend Cherokee will connect to in order to serve some application(s). For example, our Zope server running on http://localhost:8080 is a source, a FastCGI setup serving some PHP code is another source and uWSGI serving some django code is another type of source.

If you want to learn more about Cherokee sources, take a look here:

http://www.cherokee-project.com/doc/config_info_sources.html

Ok, back to our task, we have to add our Zope server as a source, so click on the "New" button on the top-left side of the page and Cherokee will ask you (in a popup-like window) for the nick/identifier of that source and the connection string:

You can see in the screenshot that I've used localhost:8080 as the connection string. The reason for that is that Cherokee will use a TCP/IP connection to our Zope server, instead some other available mechanisms (like unix sockets for example). In the nick field you can write whatever you like, it is only a label to identify your source later on.

Once you've clicked the Add button, The source will be added to the list and you will see a page with detailed information about the source itself:

You can see that, in this page, there is a combo select where you can set the type of the source, but Cherokee already selected the right choice for us.

Good, now that we've our source/backend added, let's add a new Virtual Server.

Adding the Virtual Server

A Virtual Server in Cherokee is the same as a VirtualHost in Apache, or at least it fullfills the same role in our case. We need a Virtual Server that matches our domain/subdomain names and we need to set it up so all requests incoming for such domain/subdomain go to our Zope backend (and to our Plone site).

So, first thing to do is click on the vservers link on the main menu and you will see something like this:

Once again, I already have some Virtual Servers in there, in your case it will probably have only the default one. This default vserver is something similar to the old It Works! from Apache and it shows an html file with the Cherokee logo and some text.

Go ahead, click on the New button (top-left side of the screen again) and you will get another popup-like window, this time asking you for the needed information to create a new Virtual Server.

As you can see, Cherokee offers us a lot of different options to create our Virtual Server. This is because there are a lot or preconfigured recipes that allow you to create a specific Virtual Server depending on what you need. If you would like to learn more about that, just take a look at the Cherokee Cookbook here:

http://www.cherokee-project.com/doc/cookbook.html

For the purpose of this article, all we need is to click on the Manual option (which is the one that came selected by default) and fill in the Nick (our domain name) and the Document Root. And at this point let's stop for a moment, because this is weird.

Cherokee will force us to add a Document Root and you can't use some non-existing path, because it will complain. In my oppinion, this is no good, because we do not need to have a Document Root at all, we are going to send all the requests to the Zope backend. So, perhaps this is something that could be modified in one of the next Cherokee releases... ?

Ok, once we've filled the form and clicked the Add button we can see a page with information about our recently-created Virtual Server:

Perfect, now Cherokee is able to handle requests for our myploneserver.com domain. Only a comment before proceeding. If you would like Cherokee to process requests for www. myploneserver.com too, you have to go to the Host Match tab in the page of the Virtual Server and add some configuration there. This is out of the scope of this article, but you can find more information about that here:

http://www.cherokee-project.com/doc/config_virtual_servers.html

(search for Host Match).

Setting up the reverse proxy

Ok, let's keep working. By default Cherokee will reply any incoming request for myploneserver.com trying to serve contents from our Document Root (what it calls List and Send). To change that we have to click on the Behaviour tab in the detailed page of our new Virtual Server, you will see something like:

(which probably you recognize, as it is the page where Cherokee sent us when we added the Virtual Server).

Ok, let's click on the default link (in the Behaviour rules table, there are three options, the last one is the default one) and you will see a page like this one:

Now click on the Handler tab and you will see something like that:

Good, in that form you can see the Handler select field, if you click on it, you will get a list of available options:

As you can see, there are plenty of them. Do you remember what I've said about the wizard-style form to add new Virtual Servers? and what about the different options available there? What Cherokee does for you if you use one of the pre-defined wizards is set the correct parameters right here (among some other things of course).

Ok, in our case we are going to select the option HTTP Reverse Proxy, and as soon as we select it, the form will be reloaded, showing some extra fields and hiding some other, the result is something like this:

Now we have to configure the reverse proxy, which involves three easy steps:

Step one: Select your kind of backend

First thing we have to do to set up the reverse proxy is select the kind of backend we are going to use, between two options, Round Robin or IP Hash. So, scroll down to the bottom of the page and select Round Robin:

Again, explaining the difference between Round Robin and IP Hash is out of the scope of this article, but you can read more about that topic (and get your own conclusions) here:

http://www.cherokee-project.com/doc/modules_balancers.html

Step two: Select your source

After we've selected the backend type, we have to tell Cherokee which source to connect to when handling requests with the reverse proxy. This is where the source we've created at the beginning of the article comes in. Just below the field where we selected the type of backend we will see another select field with a list of available sources:

Just select your plone at localhost 8080 (or whatever the name is) from the list and Cherokee will add it to the table of available sources for this reverse proxy:

Step three: Add your rewrite rules

Ok, we've the backend type, we've the source, now we only have to tell Cherokee how to actually send the requests to our Zope server.

Now, remember that magic I've told you from our Apache configuration (probably you know the rewrite rule well if you are used to work with Apache and Zope):

RewriteRule ^/(.*) \
      http://localhost:8080/VirtualHostBase/http/%{SERVER_NAME}:80/myploneserver/VirtualHostRoot/$1 [L,P]

All we need is translate that into something Cherokee can understand. So, scroll up the form and find the Request section in the form:

I think you got the point in the screenshot. All we have to do is add the regular expresion to the field on the left and then the destination on our Zope server to the field on the right.

BUT: You can see I've made some changes to the original rewrite, instead of:

http://localhost:8080/VirtualHostBase/http/%{SERVER_NAME}:80/myploneserver/VirtualHostRoot/$1 [L,P]

I've used:

/VirtualHostBase/http/myploneserver.com:80/myploneserver/VirtualHostRoot/$1

So, what have I done here?

1- I've removed the http://localhost:8080 part of the rewrite rule as we do not need it. We are using Cherokee's sources, so the reverse proxy already knows where to connect.

2- Instead of %{SERVER_NAME}, which is an Apache variable that can be used instead of hardcoding our domain name, I had to put myploneserver.com (that is, the domain name). This is because Cherokee does not support these variables (yet). It is not that important, but I hope we will see something like that in future Cherokee releases.

3- I've removed the [L, P] flags, as they are Apache specific options (Last Rule, Proxy rule, IIRC).

Fine, now we have to click on the Add button and the rule will be loaded:

It works!

Ok, now all you've to do is be sure that you clicked the save button and that you restarted Cherokee and then open your browser and point it to myploneserver.com (or whatever your domain is) and you should see your Plone site, served from a Zope server through a Cherokee HTTP Reverse Proxy.

(sorry, no screenshots of my shiny-plone-site ;D)

Conclusions

Well, This article couldn't be complete without some conclusins, could it? Let me put them straight into a list:

1- Cherokee has two advantages over the Apache setup. First it is lightweight, it needs less memory than apache to complete the same tasks (in this case). Second it is not vulnerable to the Slowloris attack and yes probably there will be other attacks in the future, but right now that's true.

2- I don't like Cherokee's configuration file. It is not readable and you can't edit it by hand. Well, you can, but you will end attacking people with an axe or something. In my oppinion the web admin is nice, but it is easier for sysadmins to manage the config files directly, by hand.

3- I like all the sources/backend/balancing thing. Specially when working with Zope backends, because you can do some cool things really easy, for example, a setup with a multi-instance zope+zeo setup in a standalone server:

Or even a multi-server and multi-instance Zope+ZEO setup:

You could set it up with Cherokee in minutes and with little effort, allowing you to have redundancy and balancing capabilities that could be somehow difficult to setup with other web servers acting as frontends.

4- I didn't cover it in this article, but Cherokee is blazingly fast serving static contents and you can set up really easy some kind of a media/static server to serve all the static contents of your dynamic Zope apps, both using Behaviours or creating new VirtualServers to serve static content directly from disk.

And I think 4 conclusions are enough. Perhaps you would like to add your own conclusions as comments? ;D