On Jan 11, 7:59 pm, Ben Eliott <ben.dja...@googlemail.com> 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 <graham.dumple...@gmail.com>
> > wrote:
> >> On Dec 22, 9:44 pm, Ben Eliott <ben.dja...@googlemail.com> 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 <ben.dja...@googlemail.com> wrote:
> >>>>> Graham,
> >>>>> Thank you for coming back personally to such a lowly wsgi  
> >>>>> question! I
> >>>>> started reading your email and thinking the answer was 'no', then
> >>>>> ended up thinking 'definitely maybe'. I'll keep an eye out in case
> >>>>> you
> >>>>> post more, otherwise i'll follow those links and your directions  
> >>>>> and
> >>>>> hope to report back with some progress.
>
> >>>> I'll definitely try and say more later when get a chance.
>
> >>>> Just do be aware of one thing. By using a single WSGI script file  
> >>>> for
> >>>> multiple sites, you loose the ability with mod_wsgi daemon mode to
> >>>> touch the WSGI script file and cause a single site to be  
> >>>> reloaded. One
> >>>> would normally use this as a way of reloading a single site without
> >>>> the need to restart the whole of Apache. When sharing the single  
> >>>> WSGI
> >>>> script file across sites, touching the WSGI script file will  
> >>>> restart
> >>>> all sites using that WSGI script file. If they share the code  
> >>>> this may
> >>>> actually be want you want, so not a problem, but worth mentioning.
>
> >>>> In this arrangement, if you did want to reload one site, for  
> >>>> example
> >>>> because you change its settings file, you would need to use 'ps' to
> >>>> identify process(es) in that daemon process group, based on what
> >>>> display-name option was set to, and send all those processes in  
> >>>> that
> >>>> daemon process group a SIGINT using the 'kill' command.  
> >>>> Alternatively,
> >>>> you would need to setup a background thread which monitored  
> >>>> something
> >>>> like the distinct settings file for each site and have the process
> >>>> itself send a SIGINT to itself. This would be a variation on
> >>>> background reloader described in:
>
> >>>>  http://code.google.com/p/modwsgi/wiki/ReloadingSourceCode#Restarting_
> >>>> ...
>
> >>>> More later.
>
> >>>> Graham
>
> >>>>> Thanks and Regards,
> >>>>> Ben
>
> >>>>> On 9 Dec 2008, at 08:23, Graham Dumpleton wrote:
>
> >>>>>> On Dec 9, 6:53 pm, "ben.dja...@googlemail.com"
> >>>>>> <ben.dja...@googlemail.com> wrote:
> >>>>>>> Hi, I'm converting to the excellent mod_wsgi and wondering if  
> >>>>>>> it's
> >>>>>>> possible to make a single httpd virtual host/wsgi file to manage
> >>>>>>> wildcard subdomains.
>
> >>>>>>> Basically I have an app where i'm creating a new instance for  
> >>>>>>> each
> >>>>>>> client and using subdomains. So client1.example.com and
> >>>>>>> client2.example.com both point to the same app, but their own
> >>>>>>> settings.py/django instance.
>
> >>>>>>> So far so fine.  I've been happily converting to mod_wsgi  
> >>>>>>> daemons,
> >>>>>>> creating virtual hosts and independent .wsgi files for each one.
> >>>>>>> But
> >>>>>>> now just wondering whether there is some way i can make this
> >>>>>>> process
> >>>>>>> dynamic so one virtual host/.wsgi file will take care of all  
> >>>>>>> these
> >>>>>>> subdomains.
>
> >>>>>>> I see the advice on the wsgi wiki to push domain sub-
> >>>>>>> directories to
> >>>>>>> different django instances, but i'd rather keep using the
> >>>>>>> subdomains
> >>>>>>> if possible.
>
> >>>>>>> It looks possible to be able to parse information about the
> >>>>>>> incoming
> >>>>>>> request in the wsgi file and push it to different settings.  
> >>>>>>> But i'm
> >>>>>>> not sure what this will do in terms of spawning processes etc,  
> >>>>>>> it
> >>>>>>> looks a little dangerous, or maybe this will work. Any advice
> >>>>>>> appreciated thanks!
>
> >>>>>> Start by reading recent discussion:
>
> >>>>>>  http://groups.google.com/group/django-users/browse_frm/thread/dfd3521
> >>>>>> ...
>
> >>>>>> I'll post more tomorrow if have time, have to do some things  
> >>>>>> tonight
> >>>>>> and then out most of the day tomorrow.
>
> >>>>>> In short though, no support for dynamic transient daemon  
> >>>>>> processes
> >>>>>> yet, ie.,:
>
> >>>>>>  http://code.google.com/p/modwsgi/issues/detail?id=22
>
> >>>>>> so, can't get away from using WSGIDaemonProcess for each  
> >>>>>> instance at
> >>>>>> the moment.
>
> >>>>>> One can use dynamic setting of WSGIApplicationGroup via a  
> >>>>>> variable
> >>>>>> set
> >>>>>> by mod_rewrite to select daemon process as well as set some name
> >>>>>> relevant to settings file. WSGI application wrapper can then be  
> >>>>>> used
> >>>>>> to override DJANGO_SETTINGS_MODULE.
>
> >>>>>> So, information is in that post, you just need to adapt it to  
> >>>>>> your
> >>>>>> situation. That is, use SERVER_NAME rather than REMOTE_USER from
> >>>>>> authentication as basis of selecting daemon process group. You  
> >>>>>> could
> >>>>>> though skip the rewrite maps that allowed multiple levels of
> >>>>>> indirection and made it further dynamic in nature.
>
> >>>>>> Graham
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to