Strange, that thread is down for me. Maybe it has something to do with
cacheing in a different locale...
Anyhow, the idea is to create a new django instance and point to
different settings.py files for different wildcard subdomains. here
is current Vhost:
<VirtualHost 209.20.86.10>
ServerAlias *.stayunstuck.co.uk
RewriteEngine On
RewriteCond %{HTTP_HOST} ^([^.]+)\.stayunstuck\.co\.uk$ [NC]
RewriteRule . - [E=subdomain:%1]
WSGIDaemonProcess test user=ben group=ben threads=10 processes=1
WSGIProcessGroup %{ENV:subdomain}
WSGIScriptAlias / /home/ben/mod_wsgi/django.wsgi
<Directory /home/ben/mod_wsgi>
WSGIApplicationGroup %{ENV:subdomain}
Order deny,allow
Allow from all
</Directory>
</VirtualHost>
The rewrite is assigning the ENV value correctly but the
WSGIDaemonProcess has a fixed name. So it works for a subdomain
'test', but then fails for anything else.
I'm also not getting how to access the ENV value in the wsgi script to
specify a different settings file.
On 22 Dec 2008, at 22:00, Graham Dumpleton wrote:
>
>
>
> On Dec 22, 9:44 pm, Ben Eliott <[email protected]> wrote:
>> Hi Graham,
>> I've finally managed to get back to the wildcard subdomains &
>> mod_wsgi
>> today. Unfortunately the discussion thread you mentioned has
>> disappeared and after a few hours i still seem to be doing a good job
>> of getting nowhere.
>
> I can still access thread with no problems.
>
>> Although you mentioned using mod_rewrite to get hold of the url
>> variable, it looks like the %{SERVER} variable in mod_wsgi might take
>> care of this already?
>>
>> My main issue seems to be to accessing the %{SERVER} (or relevant
>> mod_rewrite) variable in the .wsgi script, to specify a particular
>> settings file.
>>
>> Within a VirtualHost i have:
>> WSGIApplicationGroup %{SERVER}
>> WSGIDaemonProcess %{SERVER} ...threads etc
>> WSGIProcessGroup %{SERVER}
>
> The %{SERVER} value is only magic when used with WSGIApplicationGroup
> directive.
>
>> So this is probably hoplessly wrong also, but if you can give some
>> further pointers that would be most kind.
>
> Can you post a more complete example of your Apache configuration
> showing what you are trying to achieve.
>
> Sorry I didn't get back to you last time, it was a hectic few weeks.
> Things have settled down somewhat now, so I'll go back over your
> original post and work out again what it is you were trying to do.
>
> Graham
>
>> Thanks and Regards,
>> Ben
>>
>> On 9 Dec 2008, at 10:18, Graham Dumpleton wrote:
>>
>>
>>
>>> On Dec 9, 8:05 pm, Ben Eliott <[email protected]> wrote:
>>>> Graham,
>>>> Thank you for coming back personally to such a lowly wsgi
>>>> question! I
>>>> started reading your email and thinking the answer was 'no', then
>>>> ended up thinking 'definitely maybe'. I'll keep an eye out in case
>>>> you
>>>> post more, otherwise i'll follow those links and your directions
>>>> and
>>>> hope to report back with some progress.
>>
>>> I'll definitely try and say more later when get a chance.
>>
>>> Just do be aware of one thing. By using a single WSGI script file
>>> for
>>> multiple sites, you loose the ability with mod_wsgi daemon mode to
>>> touch the WSGI script file and cause a single site to be reloaded.
>>> One
>>> would normally use this as a way of reloading a single site without
>>> the need to restart the whole of Apache. When sharing the single
>>> WSGI
>>> script file across sites, touching the WSGI script file will restart
>>> all sites using that WSGI script file. If they share the code this
>>> may
>>> actually be want you want, so not a problem, but worth mentioning.
>>
>>> In this arrangement, if you did want to reload one site, for example
>>> because you change its settings file, you would need to use 'ps' to
>>> identify process(es) in that daemon process group, based on what
>>> display-name option was set to, and send all those processes in that
>>> daemon process group a SIGINT using the 'kill' command.
>>> Alternatively,
>>> you would need to setup a background thread which monitored
>>> something
>>> like the distinct settings file for each site and have the process
>>> itself send a SIGINT to itself. This would be a variation on
>>> background reloader described in:
>>
>>> http://code.google.com/p/modwsgi/wiki/ReloadingSourceCode#Restarting_
>>> ...
>>
>>> More later.
>>
>>> Graham
>>
>>>> Thanks and Regards,
>>>> Ben
>>
>>>> On 9 Dec 2008, at 08:23, Graham Dumpleton wrote:
>>
>>>>> On Dec 9, 6:53 pm, "[email protected]"
>>>>> <[email protected]> wrote:
>>>>>> Hi, I'm converting to the excellent mod_wsgi and wondering if
>>>>>> it's
>>>>>> possible to make a single httpd virtual host/wsgi file to manage
>>>>>> wildcard subdomains.
>>
>>>>>> Basically I have an app where i'm creating a new instance for
>>>>>> each
>>>>>> client and using subdomains. So client1.example.com and
>>>>>> client2.example.com both point to the same app, but their own
>>>>>> settings.py/django instance.
>>
>>>>>> So far so fine. I've been happily converting to mod_wsgi
>>>>>> daemons,
>>>>>> creating virtual hosts and independent .wsgi files for each one.
>>>>>> But
>>>>>> now just wondering whether there is some way i can make this
>>>>>> process
>>>>>> dynamic so one virtual host/.wsgi file will take care of all
>>>>>> these
>>>>>> subdomains.
>>
>>>>>> I see the advice on the wsgi wiki to push domain sub-
>>>>>> directories to
>>>>>> different django instances, but i'd rather keep using the
>>>>>> subdomains
>>>>>> if possible.
>>
>>>>>> It looks possible to be able to parse information about the
>>>>>> incoming
>>>>>> request in the wsgi file and push it to different settings. But
>>>>>> i'm
>>>>>> not sure what this will do in terms of spawning processes etc, it
>>>>>> looks a little dangerous, or maybe this will work. Any advice
>>>>>> appreciated thanks!
>>
>>>>> Start by reading recent discussion:
>>
>>>>> http://groups.google.com/group/django-users/browse_frm/thread/dfd3521
>>>>> ...
>>
>>>>> I'll post more tomorrow if have time, have to do some things
>>>>> tonight
>>>>> and then out most of the day tomorrow.
>>
>>>>> In short though, no support for dynamic transient daemon processes
>>>>> yet, ie.,:
>>
>>>>> http://code.google.com/p/modwsgi/issues/detail?id=22
>>
>>>>> so, can't get away from using WSGIDaemonProcess for each
>>>>> instance at
>>>>> the moment.
>>
>>>>> One can use dynamic setting of WSGIApplicationGroup via a variable
>>>>> set
>>>>> by mod_rewrite to select daemon process as well as set some name
>>>>> relevant to settings file. WSGI application wrapper can then be
>>>>> used
>>>>> to override DJANGO_SETTINGS_MODULE.
>>
>>>>> So, information is in that post, you just need to adapt it to your
>>>>> situation. That is, use SERVER_NAME rather than REMOTE_USER from
>>>>> authentication as basis of selecting daemon process group. You
>>>>> could
>>>>> though skip the rewrite maps that allowed multiple levels of
>>>>> indirection and made it further dynamic in nature.
>>
>>>>> Graham
> >
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to [email protected]
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
-~----------~----~----~----~------~----~------~--~---
