Graham Dumpleton wrote:
> That is basically it and hopefully it makes sense. It may seem a bit
> complex, but what you want to do isn't normal. Also, it all could have
> been done a bit simpler if were using mod_wsgi 3.0 development code
> from subversion trunk as with that have a way of avoiding use of
> WSGIImportScript.
There is actually a more simpler way that it could be done even when
using mod_wsgi 2.X. It does do something that I tend to discourage,
and for which I complain about Django/mod_python integration doing,
but in this case do it for single variable and not many like Django/
mod_python. :-)
What we will do this time is use a second rewrite map file to hold
which Django settings module should be used. This will be passed as
WSGI environment variable, but then forced into process environment
variables.
WSGIScriptAlias / /usr/local/django/mysite/apache/django.wsgi
RewriteEngine On
RewriteMap procmap txt:/usr/local/django/mysite/apache/procmap.txt
RewriteRule . - [E=PROCESS_GROUP:${procmap:%{REMOTE_USER}|
undefined}]
RewriteMap configmap txt:/usr/local/django/mysite/apache/
configmap.txt
RewriteRule . - [E=DJANGO_SETTINGS_MODULE:${configmap:%
{ENV:PROCESS_GROUP}|mysite.settings}]
WSGIProcessGroup %{ENV:PROCESS_GROUP}
WSGIDaemonProcess django1 display-name=%{GROUP}
WSGIDaemonProcess django2 display-name=%{GROUP}
WSGIDaemonProcess django3 display-name=%{GROUP}
...
WSGIDaemonProcess djangon display-name=%{GROUP}
The WSGI script file would then be:
import os, sys
sys.path.append('/usr/local/django')
sys.path.append('/usr/local/django/mysite')
import django.core.handlers.wsgi
_application = django.core.handlers.wsgi.WSGIHandler()
def application(environ, start_response):
os.environ['DJANGO_SETTINGS_MODULE] = environ
['DJANGO_SETTINGS_MODULE']
return _application(environ, start_response)
The bit I don't like here is that we are setting a process environment
variable on every request. For it to work, we are relying on fact that
Django settings module is actually lazily loaded only when first
required (at least I believe it is). Thus, we use the value of
DJANGO_SETTINGS_MODULE derived from very first request passed in by
Apache. After that request, for that life of the daemon process, even
if value changes, it is ignored.
The 'configmap.txt' file would then contain:
django1 mysite.settings1
django2 mysite.settings2
...
All this allows us to then get rid of the WSGIImportScript and the
associated preconfig scripts. It does mean having distinct settings
module files for each instance. They would be completely separate, or
would import 'mysite.settings' and then override only what is
required.
from settings import *
DATABASE_HOST = ...
DATABASE_NAME = ...
Adding new site would then be:
1. Add new instance settings file and configure it. Setup database
etc.
2. Edit configmap.txt and map instance to new settings file.
3. Use 'ps' to determine PID of instance and send it SIGINT.
4. Edit procmap.txt and map user to instance.
Give that one a whirl as well and let me know if have questions or
something doesn't quite work as advertised. Only bit I am not sure
about is if %{ENV:PROCESS_GROUP} will be available for use in second
rewrite rule already.
Graham
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
