It turns out that my two inquiries from the past three days were more related than I had thought. I have finally resolved both.
Let's first review what was going on. Here was my original problem, titled "Two projects fail to import the same main app when I turn on both in Apache". On Tue, May 5, 2015 at 10:32 AM, Thomas Levine <_...@thomaslevine.com> wrote: > I have two sites that I want to host on the same computer. > I have root access on this computer. The two sites are called > "dadaportal", which is on https://thomaslevine.com, and "scott", > which is on http://scott.dada.pink. > > ... > > Both sites work fine if I disable the other. Here is what its > configuration looks like. > > I have problem when I try to run both at the same time. Tom gave me something that seemed to work. On 05 May 13:49, Tom Evans wrote: > You're missing the process-group argument from WSGIScriptAlias so it > tries to run both of them in the default process group. > > https://docs.djangoproject.com/en/1.8/howto/deployment/wsgi/modwsgi/#using-mod-wsgi-daemon-mode After setting the process groups, I stumbled upon another problem, which I titled "How do I debug 400 errors that arise from turning off debug mode?" On 07 May 13:43, Thomas Levine wrote: > Hi, > > Every page on my site returns a status code of 400 when I set > `debug = False` in my settings file, and this doesn't happen > if I switch it to `True`. How can I determine what is going wrong? > > ... > > I believe that neither the `settings.py` nor even `wsgi.py` files > are being run, as adding the following lines to their tops did not > produce `settings.pyabc` nor `wsgi.pyabc`, respectively. > > with open(__file__ + 'abc', 'w') as fp: > fp.write('abc') I eventually managed to debug it somewhat. On 07 May 18:11, Thomas Levine wrote: > Well this is neat. Following the advice of Collin Anderson, > https://groups.google.com/d/msg/django-users/d_aWdw_AhH0/424ABkRajaoJ > > I removed the LOGGING stuff, which wasn't that interesting anyway. > And then the exception emails started appearing! > > I got this, > > > Invalid HTTP_HOST header: 'localhost:8000'. You may need to add > > 'localhost' to ALLOWED_HOSTS. > > which was a surprise to me because I already had 'localhost:*' in > my settings, but I switched it and it indeed worked on the development > server. For example, this returned the admin login page. > > curl 'http://localhost:8000/admin/login/?next=/admin/' > > But it still didn't work with the Apache server. ('scott.dada.pink', > the host that Apache watches for, had always been in ALLOWED_HOSTS.) > So I removed 'localhost' from ALLOWED_HOSTS and tried this. > > curl -H 'host: scott.dada.pink' > 'http://localhost:8000/admin/login/?next=/admin/' > > It returned the same web page, even though the host was not in > ALLOWED_HOSTS. I guess the development server does not care about > ALLOWED_HOSTS? > > curl -H 'host: scott.dada.pink' > 'http://localhost:8000/admin/login/?next=/admin/' > > Unfortunately, while email works with the development server, > it does not work on the production server, and I have yet to figure > out why. Then I looked at the scott2-error.log log again and noticed this. [Fri May 08 05:14:05.295576 2015] [wsgi:info] [pid 16576] [remote 81.234.202.247:15414] mod_wsgi (pid=16576, process='thomaslevine.com', application='scott.dada.pink|'): Loading WSGI script '/srv/dadaportal/dadaportal/wsgi.py'. Scott2 is running in the "thomaslevine.com" process group even though its Apache configuration contains this. WSGIScriptAlias / /srv/scott2/scott2/wsgi.py process-group=scott.dada.pink But now I saw the problem! The two sites' configuration files had the WSGI configuration lines outside of the virtual host, WSGIScriptAlias / /srv/scott2/scott2/wsgi.py process-group=scott.dada.pink WSGIDaemonProcess scott.dada.pink python-path=/srv/scott2 WSGIProcessGroup scott.dada.pink <VirtualHost *:80> ServerName scott.dada.pink # ... </VirtualHost> making them global. They needed to be inside the virtual host. <VirtualHost *:80> WSGIScriptAlias / /srv/scott2/scott2/wsgi.py process-group=scott.dada.pink WSGIDaemonProcess scott.dada.pink python-path=/srv/scott2 WSGIProcessGroup scott.dada.pink ServerName scott.dada.pink # ... </VirtualHost> When I switch even just one of them to be local, both sites work. This makes sense to me, as that's how name spaces are. Before I had done this, Dadaportal was working, and Scott2 wasn't. I think the reason for this is that Dadaportal's configuration file has a name (010-dadaportal) that is lower in alphabetical order than Scott2's configuration file (015-scott), but I have not tested this hunch. In response to my second question, about how to debug: I think I was doing everything that I could have done. And the information was in the Django errors for the development server, but my custom logging setup apparently interfered with the standard logging. Moreover, the causes of the 400 status codes were different on the development server and on the production server. The information was in the Apache logs, and I looked at them, but it took me a long time to notice that something was odd. Tom -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/20150508054010.GA2578%40d1stkfactory. For more options, visit https://groups.google.com/d/optout.
