On Jul 14, 3:05 am, ringemup <ringe...@gmail.com> wrote: > 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.
If you are just getting started, then would very much recommend going with the basic approach of separate VirtualHost for each with standard configuration, but where delegate each Django instance to a daemon process group. To get a better understanding of how to do it and the problems watch my Sydney PyCon talk. For details see: http://blog.dscpl.com.au/2010/06/sydney-pycon-modwsgi-talk-slides.html > 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. VirtualHost is better to start with because then you can have a separate Apache access/error log for each site. If you use other mechanisms then cant have separate log files. > Each settings file is named based on the domain it's associated with. > So example.com andwww.example.comwould both be served using > user_settings.example_com. example.co.uk andwww.example.co.ukwould > 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. The one thing you should be aware of given suggestion to use VirtualHost and mod_wsgi daemon process groups, is that you will need to restart Apache each time you add a new site. If that isn't very often, then quite acceptable. Graham > 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.
