Hi Graham, Thanks for your uber-fast response. I see exactly what you mean with the pre-set processes and rewrite map - and it's a great work around till the v4.0 release. Many thanks.
But are you saying daemon mode is only preferable due to the tendency for apache to be misconfigured? A correctly configured apache set up would be able to handle the embedded dynamic set up (and be better performing too)? Ben On Mar 23, 10:49 am, Graham Dumpleton <[email protected]> wrote: > 2009/3/23 [email protected] <[email protected]>: > > > > > > > Hi Graham, > > One final question. The scripts above required a wsgi file per site. > > I've rewritten it to direct all the sites through a single .wsgi file, > > then used thin wrapper round the application to send it on its way to > > the correct (django) settings based on environs settings. This seems > > to work pretty well, even though it removes the 'touch' reloading > > method. > > > But I'm concerned whether this script might be setting itself up for a > > fall due to the way modwsgi is handling apache processes in embedded > > mode since a new application group is being defined for each site > > (which it needs to be since each site may be operating in different > > virtualenv)? Isn't this what the daemon process mode is for? I'm > > thinking of this line from the Configuration Guidelines: > > > 'Where multiple applications, potentially owned by different users, > > need to be run, 'daemon' mode of mod_wsgi should instead be used." > > Using daemon mode would certainly be preferable, but as you already > know, one can do it with different application groups (sub > interpreters) within same process. > > > If that's true can the daemon process name be defined dynamically? Or > > does this method necessarily require embedded mode? > > You can switch it around. > > WSGIProcessGroup %{ENV:subdomain} > WSGIApplicationGroup %{GLOBAL} > > The only problem with this is that you then need to statically define > a WSGIDaemonProcess directive for each sub domain, which is contrary > to what your original aims were from memory. That is, to not have to > change the Apache configuration to add a new site. > > One of the main aims in mod_wsgi 4.0, see: > > http://blog.dscpl.com.au/2009/03/future-roadmap-for-modwsgi.html > > is to provide support for dynamic creation of daemon process groups > through defining only a single parameterisable template. > > So, you will not get exactly what you wish until then. > > The closest thing you will get for now is to define in advance > WSGIDaemonProcess directives for a pool of daemon process groups. This > would be given generic names. You would then use a RewriteMap to > dynamically assign stuff for a sub domain to one of the daemon process > groups in the pool of daemon process groups. > > WSGIDaemonProcess site-1 > WSGIDaemonProcess site-2 > WSGIDaemonProcess site-3 > WSGIDaemonProcess site-4 > WSGIDaemonProcess site-5 > WSGIDaemonProcess site-6 > WSGIDaemonProcess site-7 > > RewriteEngine On > RewriteMap wsgiprocmap txt:/etc/httpd/wsgiprocmap.txt > RewriteRule . - [E=PROCESS_GROUP:${wsgiprocmap:%{ENV:subdomain}}] > > WSGIProcessGroup %{ENV:PROCESS_GROUP} > > Then when you add a new site, as well as creating directories in file > system, add an entry in the rewrite map, such as: > > foobar.com site-1 > > Does mean you have to do some manual stuff in Apache configuration, > but you can at least preconfigure a whole bunch and then map then with > the write map file without having to restart Apache, as Apache will > automatically reread the rewrite map file when it changes. > > Have I captured the intent of what you are trying to do? > > Graham > > > Once again, many thanks for your advice on this. > > Ben > > > On Mar 15, 12:20 am, Graham Dumpleton <[email protected]> > > wrote: > >> Bouncing this back onto list for general interest. > > >> 2009/3/15 [email protected] <[email protected]>: > > >> > Been meaning to do this for ages now. Thanks Graham for all your help > >> > in other posts about this. Anyhow, following on from the thread as > >> > mentioned above, script below includes media handling, using > >> > VirtualDocumentRoot as mentioned above. The hard work was really > >> > already done above and this one has been modified to handle > >> > subdomains, using the subdomain name to identify the relevant > >> > folders. > > >> > I only just got it work and have posted it in a slightly overexcited > >> > way so probably needs tidying and strengthening. But any obvservations > >> > most welcome (yup favicon not handled), thanks: > > >> > RewriteEngine on > >> > RewriteMap tolower int:tolower > > >> > VirtualDocumentRoot /home/sites/static/%1/ > > >> > <Directory /home/sites/static/* > > >> > Order deny,allow > >> > Allow from all > >> > </Directory> > > >> > RewriteCond %{HTTP_HOST} ^([^.]+)\.domain\.co\.uk$ [NC] > >> > RewriteRule . - [E=subdomain:%1] > > >> > RewriteCond %{REQUEST_URI} !^/media/* > >> > RewriteCond %{REQUEST_URL} !^favicon.ico > >> > RewriteRule ^/(.*) /home/sites/init/modwsgi/${tolower:% > >> > {ENV:subdomain}}/django.wsgi/$1 > >> > RewriteRule . - [E=APPLICATION_GROUP:${tolower:%{SERVER_NAME}}] > > >> > WSGIProcessGroup %{GLOBAL} > >> > WSGIApplicationGroup %{ENV:subdomain} > > >> > <Directory /home/sites/init/modwsgi/* > > >> > Order allow,deny > >> > Allow from all > >> > Options ExecCGI > >> > AddHandler wsgi-script .wsgi > >> > </Directory> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en -~----------~----~----~----~------~----~------~--~---
