The contents of graphite.wsgi, should be pretty typical… It should import settings from various configs to build and point apache to the django app which is in a different location than the default web root.
# cat /opt/graphite/conf/graphite.wsgi
import os, sys
os.environ'DJANGO_SETTINGS_MODULE'] = 'graphite.settings'
application = django.core.handlers.wsgi.WSGIHandler()
# READ THIS
# Initializing the search index can be very expensive, please include
# the WSGIScriptImport directive pointing to this script in your vhost
# config to ensure the index is preloaded before any requests are handed
# to the process.
from graphite.logger import log
log.info("graphite.wsgi - pid %d - reloading search index" % os.getpid())
Apache is ignoring the django settings exposed by wsgi and continues to point to the default web root (/srv/www/htdocs)
Is there something <specific> (hopefully) I can look at that is supposed to re-direct the web root? From what I understand, Apache is supposed to come installed with default settings and only if no additional settings are imported then the default settings are used. I should not need to modify the default settings to disable them.
Maybe I should be doing something in a vhosts config somewhere although I’m deploying just this one instance?
From what I’ve read and so far implemented (works), httpd.conf is still important since it does successfully load modules.
Also, from what I’ve read, default-server.conf is supposed to be the system’s default server config, if you’re going to modify how Apache works you’re not supposed to modify this file unless you really want “the defaults” to be different.
WSGI is an approach similar to what I’ve seen with Java containers where Apache is directed to deploy a website (or more than one) by re-directing to a new webroot complete with its own app configuration which can be very complex, so it should not be any surprise to see the default web root empty.
WSGI is also not an Apache-specific technology, I’m also currently looking at how it’s implemented with nginx in case I can’t get a certain answer why it’s failing with Apache for me. Cherokee is also supposed to be a webserver with strong integrated support for WSGI.
But, in all its complexity I’m unclear exactly where this re-direction is controlled.
I hope I won’t have to devote an entire day (likely more) to learning WSGI from the ground up when I don’t know how often I’ll encounter it (although according to the documentation they believe they will become a very popular and common way to deploy web apps).
First, the importance of WSGI.
For anyone who installs and runs any kind of Python web app on a webserver configured for virtual websites, WSGI (WebServerGatewayInterface) is needed. This applies not only to Apache, but most other popular webservers as well.
As of today, IMO the official documentation at Django and WSGI are sorely lacking. Someone new to WSGI likely won’t get anywhere, the Django documentation might be detailed and complete but without any guidance how to configure and setup (IMO). The official WSGI documentation simply points to a few things (including broken links) but again won’t likely help much. For both of these, I can see if you <already> know how WSGI works, then they can be used as references to find things.
But, for newbies I’d recommend the following YouTube video (33 minutes). Very basic, although describes how to setup on Ubuntu it should be useful for anyone setting up on openSUSE as well (using slightly different commands). http://www.youtube.com/watch?v=hBMVVruB9Vs