I thought Apache was hard. Cherokee seems impossible to configure. A web
ui doesn't help much if it doesn't work. I have tried to follow the
application cookbook carefully. I have failed in some fundamental way. I
have to say that of the dozens of webpages I have looked, there are many
inconsistencies in the scripts and instructions for this configuration. It
seems a very sad state of affairs.
Here is what I have on Ubuntu 11.10:
installed:
cherokee
cherokee-admin
libcherokee-base0
libcherokee-mod-libssl
libcherokee-mod-rrd
libcherokee-server0
rrdtool
uwsgi
uwsgi-core
uwsgi-plugin-python
version of cherokee is v 1.2.2
version of uwsgi is v 0.9.8.1-1
That seems to be all of the dependencies anyone has ever mentioned. Am I
missing anything?
Here is my config.xml file, located in my web2py home (/var/web2py/):
<uwsgi>
<pythonpath>/var/web2py/</pythonpath>
<app mountpoint="/">
<script>wsgihandler</script>
</app>
<socket>127.0.0.1:40292</socket>
<processes>8</processes>
<memory-report/>
</uwsgi>
There seem to be many variations in config. Some people use <module>
outside of the <app> tag. Some people don't use mount point. Some people
don't hard code the socket and simply refer to a file in /tmp.
I attempted to follow the cookbook for the config of cherokee via the web
ui:
one virtual server: document root (/var/www)
rules: regular expression: ^(/.+?/static/.+)$ with a static content
handler at /var/web2py/applications and i/o cache enabled
default: handler (uWSGI), Balancer (Failover),
source: remote host, nickname (uWSGI 1), connection: 127.0.0.1:40292
Perhaps it is easier to diagnose with the cherokee.conf file:
config!version = 001002002
server!bind!1!port = 80
server!bind!2!port = 443
server!bind!2!tls = 1
server!group = www-data
server!ipv6 = 0
server!keepalive = 1
server!keepalive_max_requests = 500
server!panic_action = /usr/share/cherokee/cherokee-panic
server!pid_file = /var/run/cherokee.pid
server!server_tokens = full
server!timeout = 15
server!tls = libssl
server!tls!protocol!SSLv2 = 1
server!user = www-data
vserver!10!directory_index = index.html
vserver!10!document_root = /var/www
vserver!10!error_writer!filename = /var/log/cherokee/cherokee.error
vserver!10!error_writer!type = file
vserver!10!logger = combined
vserver!10!logger!access!buffsize = 16384
vserver!10!logger!access!filename = /var/log/cherokee/cherokee.access
vserver!10!logger!access!type = file
vserver!10!nick = default
vserver!10!rule!101!document_root = /var/web2py/applications
vserver!10!rule!101!handler = file
vserver!10!rule!101!match = request
vserver!10!rule!101!match!request = ^(/.+?/static/.+)$
vserver!10!rule!1!handler = uwsgi
vserver!10!rule!1!handler!balancer = failover
vserver!10!rule!1!handler!balancer!source!10 = 1
vserver!10!rule!1!handler!iocache = 1
vserver!10!rule!1!match = default
vserver!10!ssl_certificate_file = /etc/apache2/ssl/apache.pem
vserver!10!ssl_certificate_key_file = /etc/apache2/ssl/apache.key
source!1!host = 127.0.0.1:40292
source!1!nick = uWSGI 1
source!1!type = host
<icon and mime directives omitted....>
I start uwsgi with the following command in terminal starting in my web2py
home directory (/var/web2py):
uwsgi -x config.xml -d /tmp/uwsgi.log
The best I have ever done is have the cherokee index.html page come up, but
not with the above config. At this point all I get is a 500 internal
server error. I can send the logs if anyone things they would help--they
are gibberish to me.
A problem the uwsgi log does show is that it sees another instance of uwsgi
at the socket address. IT IS VERY HARD TO KILL uwsgi. Normal linux kill
doesn't do it. Only kill -KILL -<pid group> seems to do it--and only very
inconsistently. It is not clear to me if I need to start uwsgi manually or
if Cherokee will do it. In any case, it just won't die so that I can
restart. I really dread rebooting the VPS (linode) as I don't know how
many things will break and not restart normally.
(note that it is sudo kill... which only did the job once...)
I am really at my wit's end here after hours of research and reconfiguring.
These things are so fragile and poorly documented (except for the
cookbook, which is entirely clear as far as it goes--but like any cookbook,
it doesn't provide much in the way of diagnostics). Such a waste of time
when we could be writing nice Python code for web2py sites...
