Re: dynamic mod wsgi

[Ben Eliott]

Ok, thanks Graham, will do.

On 11 Jan 2009, at 10:45, Graham Dumpleton wrote:

>
>
>
> On Jan 11, 7:59 pm, Ben Eliott  wrote:
>> Hi Graham,
>> Just following up on this thread. I replied with some details, but
>> maybe you missed those, or maybe i missed your reply. Or maybe this
>> isn't worth it and i should stop being lazy and just write out the
>> VirtualHost files :)
>
> I missed the posts. It was a festive time of year, plus have been
> exceedingly busy.
>
> If the only thing this web server is going to host is the Django
> instances, you are possibly better of not using VirtualHost at all,
> but use mod_rewrite to implement virtual hosts. See:
>
>  http://groups.google.com/group/modwsgi/browse_frm/thread/c29dde8fbef68e0b#
>
> They never came back with final configuration which incorporated
> static media hosting distinct for each site, but not too much work.
> Perhaps post a followup to that thread if you want to work through
> static media aliases that are needed so each instance can have its own
> separate media files.
>
> Also perhaps use that thread if you want to discuss how to extend that
> scheme such that a pool of daemon processes is available and so you
> can have dynamic assignment to one of the daemon process groups from
> the pool.
>
> Discussion on the mod_wsgi list where that thread is in general better
> for me as it then comes in my mail box and don't miss it, where as
> just browse here occasionally so don't always pick up posts.
>
> Graham
>
>> On 23 Dec 2008, at 01:13, Graham Dumpleton wrote:
>>
>>
>>
>>> Have some further questions about what you want to do.
>>
>>> Do you want a separate daemon process for each distinct Django site,
>>> or are you happy with one really fat process which contains each
>>> Django site in a separate sub interpreter of that process?
>>
>>> How much memory does each Django site instance take up?
>>
>>> How many different site instances would you have?
>>
>>> Are all the site instances distinguishable by server name alone?
>>
>>> Graham
>>
>>> On Dec 23, 9:00 am, Graham Dumpleton 
>>> wrote:
 On Dec 22, 9:44 pm, Ben Eliott  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  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 

Re: dynamic mod wsgi

[Graham Dumpleton]

On Jan 11, 7:59 pm, Ben Eliott  wrote:
> Hi Graham,
> Just following up on this thread. I replied with some details, but  
> maybe you missed those, or maybe i missed your reply. Or maybe this  
> isn't worth it and i should stop being lazy and just write out the  
> VirtualHost files :)

I missed the posts. It was a festive time of year, plus have been
exceedingly busy.

If the only thing this web server is going to host is the Django
instances, you are possibly better of not using VirtualHost at all,
but use mod_rewrite to implement virtual hosts. See:

  http://groups.google.com/group/modwsgi/browse_frm/thread/c29dde8fbef68e0b#

They never came back with final configuration which incorporated
static media hosting distinct for each site, but not too much work.
Perhaps post a followup to that thread if you want to work through
static media aliases that are needed so each instance can have its own
separate media files.

Also perhaps use that thread if you want to discuss how to extend that
scheme such that a pool of daemon processes is available and so you
can have dynamic assignment to one of the daemon process groups from
the pool.

Discussion on the mod_wsgi list where that thread is in general better
for me as it then comes in my mail box and don't miss it, where as
just browse here occasionally so don't always pick up posts.

Graham

> On 23 Dec 2008, at 01:13, Graham Dumpleton wrote:
>
>
>
> > Have some further questions about what you want to do.
>
> > Do you want a separate daemon process for each distinct Django site,
> > or are you happy with one really fat process which contains each
> > Django site in a separate sub interpreter of that process?
>
> > How much memory does each Django site instance take up?
>
> > How many different site instances would you have?
>
> > Are all the site instances distinguishable by server name alone?
>
> > Graham
>
> > On Dec 23, 9:00 am, Graham Dumpleton 
> > wrote:
> >> On Dec 22, 9:44 pm, Ben Eliott  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  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 

Re: dynamic mod wsgi

[Ben Eliott]

Hi Graham,
Just following up on this thread. I replied with some details, but  
maybe you missed those, or maybe i missed your reply. Or maybe this  
isn't worth it and i should stop being lazy and just write out the  
VirtualHost files :)
Ben

On 23 Dec 2008, at 01:13, Graham Dumpleton wrote:

>
> Have some further questions about what you want to do.
>
> Do you want a separate daemon process for each distinct Django site,
> or are you happy with one really fat process which contains each
> Django site in a separate sub interpreter of that process?
>
> How much memory does each Django site instance take up?
>
> How many different site instances would you have?
>
> Are all the site instances distinguishable by server name alone?
>
> Graham
>
> On Dec 23, 9:00 am, Graham Dumpleton 
> wrote:
>> On Dec 22, 9:44 pm, Ben Eliott  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  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, "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  
>>> 

Re: dynamic mod wsgi

[Ben Eliott]

I just saw your message below after sending the vhost.

I don't think i'd mind whether it's separate processes or one really  
fat one. I think perhaps separate processes with a quite a short  
inactivity timeout might work quite well? I'd rather keep the overall  
footprint as  small as feasible, especially since i'm only using a  
memory starved VPS for the time being. But this is for alpha-testing  
purposes really so not crucial concern.

I don't know the answer really to your questions, but perhaps if i can  
give you some background:  I'm looking to set up/demonstrate a django  
app for users according to a set of specific settings they choose.  
Subdomains are to identify the client accounts where they can see  
their django app . The subdomain would be temporary for demonstration/ 
set-up purposes and a client account  would get moved across to a  
dedicated domain name in due course.

Based on users entry in a form i can write/re-write python settings,  
and mod_wsgi allows me to programmatically restart a site - this is  
what led me to think it might be possible. The crunch is obviously  
that i want it to create these instances on the fly, so that the user  
completes the form and *bam* their subdomain is there complete with  
their customized django app.









On 23 Dec 2008, at 01:13, Graham Dumpleton wrote:

>
> Have some further questions about what you want to do.
>
> Do you want a separate daemon process for each distinct Django site,
> or are you happy with one really fat process which contains each
> Django site in a separate sub interpreter of that process?
>
> How much memory does each Django site instance take up?
>
> How many different site instances would you have?
>
> Are all the site instances distinguishable by server name alone?
>
> Graham
>
> On Dec 23, 9:00 am, Graham Dumpleton 
> wrote:
>> On Dec 22, 9:44 pm, Ben Eliott  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  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 

Re: dynamic mod wsgi

[Ben Eliott]

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:


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


WSGIApplicationGroup %{ENV:subdomain}
Order deny,allow
Allow from all



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  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  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, "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 

Re: dynamic mod wsgi

[Graham Dumpleton]

Have some further questions about what you want to do.

Do you want a separate daemon process for each distinct Django site,
or are you happy with one really fat process which contains each
Django site in a separate sub interpreter of that process?

How much memory does each Django site instance take up?

How many different site instances would you have?

Are all the site instances distinguishable by server name alone?

Graham

On Dec 23, 9:00 am, Graham Dumpleton 
wrote:
> On Dec 22, 9:44 pm, Ben Eliott  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  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, "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  
> > 

Re: dynamic mod wsgi

[Graham Dumpleton]

On Dec 22, 9:44 pm, Ben Eliott  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  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, "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 

Re: dynamic mod wsgi

[Ben Eliott]

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  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"
>>>  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 

Re: dynamic mod wsgi

[Ben Eliott]

Understood. Thanks.

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_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, "[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 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
-~--~~~~--~~--~--~---

Re: dynamic mod wsgi

[Graham Dumpleton]

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_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, "[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 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
-~--~~~~--~~--~--~---

Re: dynamic mod wsgi

[Ben Eliott]

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.
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/dfd352162db59ed7
>
> 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: dynamic mod wsgi

[Graham Dumpleton]

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/dfd352162db59ed7

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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---