Running Kitsune with mod_wsgi¶
Setting up Kitsune to run as a WSGI application is fairly straightforward. You will need to install the requirements as described in the installation chapter.
There are 3 steps once Kitsune is installed:
- Set the document root.
- Set up aliases.
- Some file permissions.
- Set up WSGI itself.
Most of the Apache modules are part of a default Apache install, but
may need to be activated. If they aren’t installed, all of them,
mod_wsgi should be installable via your favorite package
In the Apache config (or
<VirtualHost>) you will need the following:
Note that values may be slightly different.
DocumentRoot /path/to/kitsune/webroot/ <Directory "/path/to/kitsune/webroot/"> Options +FollowSymLinks </Directory> Alias /media/ "/path/to/kitsune/media/" Alias /admin-media/ \ "/path/to/virtualenv/lib/python<version>/site-packages/django/django/contrib/admin/media/" WSGISocketPrefix /var/run/wsgi WSGIDaemonProcess kitsune processes=8 threads=1 \ maximum-requests=4000 WSGIProcessGroup kitsune WSGIScriptAlias /k "/path/to/kitsune/wsgi/kitsune.wsgi"
- May or may not be necessary. It was for me.
processesshould be set to the number of cores.
threadsshould probably be left at 1.
maximum-requestsis good at between 4000 and 10000.
- Will make Kitsune accessible from
http://domain/k, and we use rewrites in
webroot/.htaccessto hide the
/k. This will change soon, and the
.htaccessfile won’t be necessary.
Alias directives let Kitsune access its CSS, JS, and images through
Apache, reducing the load on Django.
To upload files, the webserver needs write access to
media/uploads and all
its subdirectories. The directories we currently use are:
media/uploads media/uploads/avatars media/uploads/images media/uploads/images/thumbnails media/uploads/gallery/images media/uploads/gallery/images/thumbnails media/uploads/gallery/videos media/uploads/gallery/videos/thumbnails
media/uploads and its subdirectories should never be added to version
control, as they are installation-/content-specific.
Product Details JSON¶
Some people have issues with
django-mozilla-product-details and file
permissions. The management command
manage.py update_product_details writes
a number of JSON files to disk, and the webserver then needs to read them.
If you get file system errors from
product_details, make sure the files are
readable by the webserver (should be by default) and the directory is readable
product_details stores the JSON files in:
This is configurable. If you have multiple web servers, they should share this
data. You can set the
PROD_DETAILS_DIR variable in
kitsune/settings_local.py to a different path, for example on NFS.
Debugging via WSGI is a little more interesting than via the dev server. One
key difference is that you cannot use
pdb. Writing to
stdout is not
allowed within the WSGI process, and will result in a Internal Server Error.
There are three relevant cases for debugging via WSGI (by which I mean, where to find stack traces):
Apache Error Page¶
So you’ve got a really bad error and you aren’t even seeing the
Kitsune error page! This is usually caused by an uncaught exception
during the WSGI application start-up. Our WSGI script, located in
wsgi/kitsune.wsgi, tries to run all the initial validation that
the dev server runs, to catch these errors early.
So where is the stack trace? You’ll need to look in your Apache error logs.
Where these are is OS-dependent, but a good place to look is
/var/log/httpd. If you are using SSL, also check the SSL
logs, for example
DEBUG = True in your
kitsune/settings_local.py, you will see
a stack trace in the browser on error. Problem solved!
DEBUG = False in your
kitsune/settings_local.py, you’ll see our
Server Error message. You can still get stack traces, though, by setting the
ADMINS variable in
ADMINS = ( ('me', 'email@example.com'), )
Django will email you the stack trace. Provided you’ve set up email.
WSGI keeps Python and Kitsune running in an isolated process. That means code
changes aren’t automatically reflected on the server. In most default
mod_wsgi, you can simply do this:
That will cause the WSGI process to reload.