On Jul 14, 9:41 am, ringemup <ringe...@gmail.com> wrote: > Thank you -- can't tell you how much I appreciate your taking the time > to help me out with this! The slides were extremely helpful, too, > although I'll need to do some research in order to understand some of > the details and figure out which of the options you presented we > should use. I'm feeling confident about at least getting this running > now.
Ensure you watch the video as well as that will explain slides better. Graham > On Jul 13, 7:11 pm, Graham Dumpleton <graham.dumple...@gmail.com> > wrote: > > > > > 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.comwouldbothbe 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.
