Other: Frequently Asked Questions

Here is a list of the most frequently asked questions. Please refer to the appropriate section of the documentation for more details.

How to compile it

./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var

How to create dynamic modules

It’s the default way.

How to configure the module xyz to be linked statically

./configure --prefix=/usr --sysconfdir=/etc \
  --localstatedir=/var                      \

How to build everything statically

./configure --prefix=/usr --sysconfdir=/etc \
  --localstatedir=/var                      \

How to create a self signed certificate for TLS

openssl req -days 1000 -new -x509 -nodes    \
  -out /etc/cherokee/ssl/cherokee.pem       \
  -keyout /etc/cherokee/ssl/cherokee.pem

How to access cherokee-admin from a remote machine

cherokee-admin binds only to local loopback by default. There are some workarounds:

  • Create an SSH tunnel. This is the recommended way. In order to do so you must issue the following command:

    ssh -L 9090:localhost:9090 remote_IP

    After that you can access the remote interface through http://localhost:9090 and every request will be forwarded to the remote IP running cherokee-admin.

  • Launch cherokee-admin with the -b parameter in order to force it to listen to all the network interfaces.

  • Finally you could always install cherokee on your local host, configure it there and then copy the generated cherokee.conf file to the device running the cherokee instance you wanted to set up.

How to manually write configuration files without cherokee-admin

The configuration file is a plain text file and its syntax is well documented. Check the cherokee.conf internal format information. Notice that manually editing the configuration is not the recommended method, but the format will always be kept updated to facilitate scripting tasks, working with embedded devices and other similar situations.

Does Cherokee speak WSGI natively like mod_wsgi does?

In short: not like mod_wsgi at all. There is native support for the uWSGI server, which is a fast (pure C), self-healing, developer-friendly WSGI server aimed for professional python webapps deployment and development. Cherokee also provides a wizard to adjust its settings to those defined in the uWSGI configuration file of your project.

I need to make an administration script: What signals are supported by Cherokee?

The list is documented in the Signals entry.

Is there a clean way of switching Cherokee to Maintenance mode?

Check the Cookbook, there is a recipe on the subject.

What licensing is used by the Cherokee web server?

Cherokee is licensed under the GNU General Public License, version 2, which can be found in the file COPYING distributed with the source code. For more details, read the full license in the project’s SVN repository.

If for whatever reason this license does not suit your needs, other licensing schemes can be negotiated on a particular basis. Contact Octality if this is your case.

And what about the documentation?

The documentation is distributed under a Creative Commons Attribution (by) license, which is the most accommodating in terms of what others can do with it. It lets others distribute, remix, tweak, and build upon the work, even commercially.

How can I contribute contents to the documentation?

The documentation is written and maintained using AsciiDoc, a text document format for writing short documents, articles, books and UNIX man pages that can be easily translated to HTML and DocBook markups. It is really easy to get the hang of it, so if you want to contribute, please take a look at the AsciiDoc Cheatsheet and start editing the documentation sources right ahead. They are distributed with the source code and are located under ./doc of the source tree. If you don’t have SVN access, simply mail your contributions to [email protected].

Can encoders be set for specific file types?

Yes. Since content encoding is set on a per-rule basis, simply add a rule at the beginning of the virtual server that matches the specific file extensions and has the encoding enabled. Set the rule to be non-final. That should do the trick.

I can’t set TLS/SSL in Cherokee-Admin. There’s no TLS/SSL (and nothing in the pulldown) for me.

First, make sure openssl in installed. If you are not installing from source, most likely you’ve missed installing libcherokee-mod-libssl

Can I use an old configuration file with a new Cherokee release?

The answer is yes. Please refer to the Upgrading Cherokee section of the documentation.

I’m using *BSD and can’t compile Cherokee. What’s wrong?

Make sure you are building it with gmake.

Why do I keep getting HTTP Error 400 while uploading files to a PHP back-end?

PHP is configured by default to limit the size of uploaded files. Check the PHP upload limits note to tweak the appropriate settings.

Why are my nicknames not matched, while * does work?

The Cherokee Virtual Server nickname is not the first thing that is evaluated. In fact all the Host Matches are first evaluated from top to bottom, then the nicknames from top to bottom, and on last resort: Default.

For example: a virtual server (A) with the nickname, and a second virtual server (B) with a hostmatch .*\ In this example, the virtual server B will be matched first.

If you are specifically looking for the virtual server A to be matched first, you will have rely on it being matched by Host Match instead of by nickname.

  • Virtual Server A RegEx: ^$

  • Virtual Server B RegEx: .*\$

Carefully read the way in which host matches are performed if you still need further clarification.

SSLv2 is ancient, OpenSSL 1.0.0+ doesn’t like it, how can I disable it?

Within cherokee-admin, in the Advanced Menu, you can find the option to enable/disable SSLv2 all together. It is disabled by default. No need to resort to special ciphers such (ALL:!ADH:-LOW:-SSLv2:-EXP:-eNULL:@STRENGTH), or anythingh else for that matter. If you need it, simply enable the check-box to allow SSLv2.

I’m used to Apache’s .htaccess. Will Cherokee ever support it?

Short answer: No. Cherokee is designed to be efficient. Using .htaccess is not: it’s not a scalable architecture at all, it’s horrible for performance, you can’t use it with Cherokee, and even if you could, you shouldn’t. If you need .htaccess, you’re probably doing it wrong. For .htaccess to work, Apache has to check every directory in the requested path for the existence of a .htaccess file, and if present, read and parse every one of them. This happens for every request. Sure, changes in .htaccess are effective instantly, but that’s because Apache has to read and process the files every time. As the requests dig deeper into the directory tree, the associated overhead of stats an reads grows. And it is not negligible at all: an increase in anything from 5 to 50 is usual for very typical configurations.

Yes, the use of .htaccess is very extended. Yes, it has been around for a while. No, that doesn’t mean it is a good architecture. There are better ways of doing things. Converting the behavior of a .htaccess file to an efficient set of rules for Cherokee is not complicated.