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.
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}
So this is probably hoplessly wrong also, but if you can give some
further pointers that would be most kind.
Thanks and Regards,
Ben
On 9 Dec 2008, at 10:18, Graham Dumpleton wrote:
>
>
>
> On Dec 9, 8:05 pm, Ben Eliott <ben.dja...@googlemail.com> 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_Daemon_Processes
>
> More later.
>
> Graham
>
>> Thanks and Regards,
>> Ben
>>
>> On 9 Dec 2008, at 08:23, Graham Dumpleton wrote:
>>
>>
>>
>>> On Dec 9, 6:53 pm, "ben.dja...@googlemail.com"
>>> <ben.dja...@googlemail.com> 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 django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
