So it would work to just create a standard deployment for each VirtualHost, just specifying a different DJANGO_SETTINGS_MODULE in each WSGI script? I should be able to get that working, as a fallback at worst.
I've read the Django integration and Application Issues pages from the mod_wsgi docs, and feel like I got the gist but won't claim to have understood every word; also read the virtualenv docs and was mostly lost. I do have someone lined up to handle the actual installation of mod_wsgi, but he has no experience with Django and very little with Python. My server administration skills are pretty basic (navigating the filesystem, configuring a plain-vanilla virtual host, etc), and I'm sure there are things I don't understand about the Python and Django operating environment -- I'm a little more familiar with the PHP model where everything is set up and torn down for each request. I figured there might be some solution using mod_rewrite or routing in the WSGI script to avoid having to create separate Virtual Hosts and WSGI scripts for each instance, but it is crucial that the correct "current site" be identified by the Sites contrib module for every request, and I have no idea whether that would be derailed by any sort of internal routing. Each settings file is named based on the domain it's associated with. So example.com and www.example.com would both be served using user_settings.example_com. example.co.uk and www.example.co.uk would be served using user_settings.example_co_uk. The domain-specific settings files basically just import all the settings from a global settings file and then override the SITE_ID. All media will be served from a single separate domain / virtual host, so there's no need to configure media serving for each site. Thanks for your help! Nan On Jul 12, 7:13 pm, Graham Dumpleton <graham.dumple...@gmail.com> wrote: > > > How much of the documentation on the official mod_wsgi site have you > read? > > Your use case is basically the standard deployment method, duplicated > for each VirtualHost. > > I could suggest some alternatives to that to support a common WSGI > script file, but still allow a way of restarting a single daemon > process by touching a file specific to each site, eg., that sites > settings file. > > Before doing that though would like to see that you have the standard > deployment method working first and understand that else if I start > talking about improvements to that without you have actually got the > standard method working first, then may just confuse you. > > Also would need to know what naming strategy you are going to use for > the site specific settings files. If know that can describe > alternative in a way that makes sense to you rather than you having to > translate it. > > 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-us...@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.
