Re: dynamic mod wsgi
Ok, thanks Graham, will do. On 11 Jan 2009, at 10:45, Graham Dumpleton wrote: > > > > On Jan 11, 7:59 pm, Ben Eliottwrote: >> 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
On Jan 11, 7:59 pm, Ben Eliottwrote: > 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
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
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
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 Eliottwrote: >> 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
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 Dumpletonwrote: > 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
On Dec 22, 9:44 pm, Ben Eliottwrote: > 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
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 Eliottwrote: >> 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
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
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, 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
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 -~--~~~~--~~--~--~---
dynamic mod wsgi
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! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---