Cherokee frontend for Zope applications and Plone sites
May 2022
Sun Mon Tue Wed Thu Fri Sat
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        
This site is an effort to share some of the base knowledge I have gathered through all this years working with Linux, FreeBSD, OpenBSD, Python or Zope, among others. So, take a look around and I hope you will find the contents useful.
Recent Entries
Recent Comments
Recent Trackbacks
OpenBSD (9 items)
BSD (0 items)
FreeBSD (19 items)
Linux (3 items)
Security (3 items)
Python (22 items)
Zope (13 items)
Daily (144 items)
e-shell (9 items)
Hacks (14 items)
PostgreSQL (3 items)
OSX (8 items)
Nintendo DS (0 items)
enlightenment (0 items)
Apache (3 items)
Nintendo Wii (1 items)
Django (24 items)
Music (12 items)
Plone (7 items)
Varnish (0 items)
Lugo (2 items)
Sendmail (0 items)
europython (7 items)
Cherokee (1 items)
self (1 items)
Nature (1 items)
Hiking (0 items)
uwsgi (0 items)
nginx (0 items)
cycling (10 items)
Networking (1 items)
DNS (0 items)

Syndicate this site (XML)

RSS/RDF 0.91

12 noviembre

Cherokee frontend for Zope applications and Plone sites

How to set up a cherokee webserver with a Zope backend

I've been working with Zope for quite some time now (I'm not sure, probably since 2003 or so) and I've been using the following setup for a long time now:

The usual setup: Apache as a frontend using mod_rewrite+proxy to send requests to the Zope backend

This is the usual setup in a production environment for any Zope app (including Plone), using a web server like Apache to act as a frontend to the Zope Application server (using mod_rewrite with proxy functions). As I've improved my skills managing this kind of setups, I've found some interesting alternatives to it and I even wrote some lines about a different setup some months ago. In that setup I added Varnish to the equation, as well as a multi-instance Zope setup using a ZEO backend.

Today I would like to write about another option to improve the usual Zope production environment:

A twist to the usual setup: replacing Apache with Cherokee

Yes, the only thing I did in that diagram is replace the Apache web server with one of the new options we've in the opensource world, the Cherokee web server.

In my oppinion this is a good choice, even better if you are using the web server only as a frontend for your Zope backends, because the new generation of web servers can eat much less memory than ol' Apache (or at least you don't have to tweak them that much for it).

Of course another important factor to decide for the migration is Slowloris... ;D

There are some other options, like nginx or lighttpd to mention two of them, but today I'll cover Cherokee.

So, first things first, let me explain some things before starting:

1- I've used Cherokee 1.0.7 for the purpose of writing this article, but probably you will find that it will work with newer releases of Cherokee (and there are plenty of them, as there is a new release almost each month!).

2- For the purpose of this article I've a Zope instance running on the same host as Cherokee and there is a Plone site on that Zope server with the id myploneserver which is available in the url http://localhost:8080/myploneserver (remember to change both localhost and myploneserver to suit your needs when following this article)

3- I'm going to use the cherokee-admin for everything related to the configuration of Cherokee. One thing you've to know about the Cherokee Admin interface is that things are only saved to the configuration file on disk when you click on the save button on the top-right side of the admin site and that changes are applied to the server only after restarting Cherokee itself. So, each time you add something, edit some other thing, whatever, you should click on the save button if you are sure that you want to write that into the configuration file of the web server.

4- I would like to say Thanks! to Alvaro Lopez Ortega (alobbs), who helped me a lot some days ago with all the doubts I had about this setup. Oh!, yes, and for creating Cherokee too... yes ;D

Ok, now let's go to the interesting (I hope so) part of the article...

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

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:

The cherokee web admin

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:

The list of sources, that is, backends Cherokee can connect to in order to serve applications

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:

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:

The popup window where you can add the basic information for a new source

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:

The page you can see after adding your source, containing some detailed information and the posibility to change some parameters.

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:

The Virtual Servers section, by default lists all available servers.

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.

The wizard-like window to add new virtual servers in cherokee

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:

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:

Once we've added the new virtual server, we can edit it and complete its configuration

Perfect, now Cherokee is able to handle requests for our domain. Only a comment before proceeding. If you would like Cherokee to process requests for www. 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:

(search for Host Match).

Setting up the reverse proxy

Ok, let's keep working. By default Cherokee will reply any incoming request for 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:

Once we've added the new virtual server, we can edit it and complete its configuration

(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:

The default behaviour of our new virtual server: List and Send any content inside our Document Root

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

The handler tab on the default behaviour, where we can modify it

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

The list of different handlers you can assign to a cherokee virtual server behaviour

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:

As soon as we select the HTTP Reverse Proxy option, the form will change, showing us some aditional fields to set up the proxy.

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:

Selecting the round robin backend type for our reverse proxy.

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:

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:

Selecting the source to where Cherokee will send the incoming requests through the reverse proxy.

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:

After selected the source, it is added to the table of available sources.
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:

The section were we can add rewrite-like rules for our reverse proxy

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:


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 (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:

Rewrite rule added, only one save left to finish the job.

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 (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)


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:

Cherokee as a frontend to a multi-instance Zope+ZEO setup

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

Cherokee as a frontend to a multi-server 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

Posted by wu at 02:26 | Comments (0) | Trackbacks (0)
<< The cathedral of Lugo and an early october night | Main | How dangerous is a zombie? >>
Re: Cherokee frontend for Zope applications and Plone sites


I'm bookmarking this for [hope-not-too-far-in-the] future references.

Thanks for sharing.

Posted by: foz at noviembre 17,2010 16:50
Re: Cherokee frontend for Zope applications and Plone sites

"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"

So true and so eloquently put. It's not impossible to edit the config by hand, but you're absolutely right. Aside from that, and the fact that Cherokee needs you to hard-code hostname and other variables into the rewrite (and thus require you to have separate rules for HTTP and HTTPS, and multiple hostnames or ports), Cherokee is very nice

Posted by: David at julio 13,2011 07:51
Re: Cherokee frontend for Zope applications and Plone sites

Hi David. I liked cherokee, really, but I don't like the idea of not being able to just ssh into a server and do modifications/updates to the web server configuration, having to do it always using the admin is a PITA.

Of course it has some other problems/limitations like the hardcoded hostnames in rewrite rules, but what made me "run" from it was the config files problem.

Oh, another thing I don't like is the release process, I think there would be more "control" on that (some months ago there were even 2 releases on the same day...).

Posted by: Wu at julio 19,2011 18:34
Please send trackback to:
There are no trackbacks.
Post a comment