1

我认为这可能是 WSGI/Apache 配置问题。

我有一个通过 Apache 和 mod_wsgi 服务的 Django 网站。我正在尝试从相同的代码库但通过不同的域、数据库和 settings.py 运行第二个网站。

我的 WSGI 配置文件似乎正在加载正确的、单独的 settings.py 文件。但是，似乎第二个域正在从原始数据库而不是新数据库加载数据。这仅发生在我的生产环境中，该环境具有 Apache 设置。

我的 settings.py 文件通过一个名为 common.py 的文件加载公共信息，然后加载数据库名称。

IE

设置1.py

from common import *
DATABASES['default']['NAME'] = 'database1'
...

设置2.py

from common import *
DATABASES['default']['NAME'] = 'database2'
...

这些设置是从它们各自的 WSGI 文件中加载的：

www.domain1.com -> index1.wsgi：

import os, sys
sys.path.insert(0,'/location/to/code/')
sys.path.insert(0,'/location/to/code/application')
sys.path.insert(0,'/virtual/env/python2.7/site-packages/')
os.environ['DJANGO_SETTINGS_MODULE'] = 'application.settings1'
os.environ['PYTHON_EGG_CACHE'] = '/location/to/.python-eggs'  

import django.core.handlers.wsgi

application = django.core.handlers.wsgi.WSGIHandler()

www.domain2.com -> index2.wsgi：

import os, sys
sys.path.insert(0,'/location/to/code/')
sys.path.insert(0,'/location/to/code/application')
sys.path.insert(0,'/virtual/env/python2.7/site-packages/')
os.environ['DJANGO_SETTINGS_MODULE'] = 'application.settings2'
os.environ['PYTHON_EGG_CACHE'] = '/location/to/.python-eggs'  

import django.core.handlers.wsgi

application = django.core.handlers.wsgi.WSGIHandler()

如您所见，我所做的只是改变设置位置。代码的位置保持不变。我确信这部分工作是基于这样一个事实，即服务器上保存和加载静态文件的位置已根据 settings1.py 和 settings2.py 的属性而改变。但是，即使从 www.domain2.com 调用，调用应用程序的信息也来自 database1。我什至不确定这是怎么可能的，因为该数据库名称仅在 settings1.py 中可用，而在 common.py 中不可用。有人对这个问题有任何见解吗？

编辑：

我在 Apache 包含中添加了将域定向到它们各自的 WSGI 文件的内容。请注意，虚拟主机在 localhost 上侦听，因为我让 NGINX 在端口 80 上侦听并将相关请求转发到 Apache。

AddHandler wsgi-script .wsgi 

NameVirtualHost 127.0.0.1:80
Listen 127.0.0.1:80

<IfModule mod_wsgi.c>
<VirtualHost 127.0.0.1:80>
    ServerName domain1.com
    ServerAlias www.domain1.com

    ErrorDocument 500 "We are experiencing difficulties.  Please contact webmaster@domain1.com if you feel you are receiving this page in error."

    WSGIScriptAlias / /path/to/index1.wsgi
    Alias /static/ /path/to/static_files/static/
    WSGIDaemonProcess djangodomain1 python-path=/virtual/env/python2.7/site-packages processes=8 threads=4 display-name=%{GROUP}
    WSGIProcessGroup djangodomain1
    WSGIApplicationGroup %{GLOBAL}

    ExpiresActive On
    ExpiresDefault "access plus 10 days"
    ExpiresByType text/css "access plus 1 second"
    ExpiresByType text/js "access plus 1 second"

    ServerAdmin webmaster@domain1.com
    UseCanonicalName Off
    CustomLog /path/to/logs/access_log combined
    CustomLog /path/to/domlogs/domain1.com-bytes_log "%{%s}t %I .\n%{%s}t %O ."

    ErrorLog /path/to/logs/error_log

    ## User group1 # Needed for Cpanel::ApacheConf
    <IfModule mod_suphp.c>
        suPHP_UserGroup group1 group1
    </IfModule>
    <IfModule !mod_disable_suexec.c>
        SuexecUserGroup group1 group1
    </IfModule>

</VirtualHost>

<VirtualHost 127.0.0.1:80>
    ServerName domain2.com
    ServerAlias www.domain2.com

    ErrorDocument 500 "We are experiencing difficulties.  Please contact webmaster@domain1.com if you feel you are receiving this page in error."

    WSGIScriptAlias / /path/to/index2.wsgi
    Alias /static/ /path/to/static/
    WSGIDaemonProcess djangodomain2 python-path=/virtual/env/python2.7/site-packages processes=8 threads=4 display-name=%{GROUP}
    WSGIProcessGroup djangodomain2
    WSGIApplicationGroup %{GLOBAL}

    ExpiresActive On
    ExpiresDefault "access plus 10 days"
    ExpiresByType text/css "access plus 1 second"
    ExpiresByType text/js "access plus 1 second"

    ServerAdmin webmaster@domain1.com
    UseCanonicalName Off
    CustomLog /path/to/logs/domain2/access_log combined
    CustomLog /path/to/domlogs/domain2.com-bytes_log "%{%s}t %I .\n%{%s}t %O ."

    ErrorLog /path/to/logs/domain2/error_log

    ## User group1 # Needed for Cpanel::ApacheConf
    <IfModule mod_suphp.c>
        suPHP_UserGroup group1 group1
    </IfModule>
    <IfModule !mod_disable_suexec.c>
        SuexecUserGroup group1 group1
    </IfModule>

</VirtualHost>
4

2 回答 2

0

好的，在研究了您的配置之后，我确信“最有可能”的 apache 与您的虚拟主机不匹配，并且正在路由到第一个。这可以解释为什么它只发生在第二个环境中。

阅读这篇博文的最后一节： 关于将 django Fallback 设置为默认 VirtualHost 定义的 Gram 的博客。

--- 剪断 ---

作为发现此类问题并确保请求不会无意中转到错误站点的故障保险，一个好的做法可能是确保 Apache 在读取其配置时遇到的第一个 VirtualHost 实际上是一个不等同的虚拟定义到一个实际的站点。

<VirtualHost _default_:*>
   Deny from all
</VirtualHost>

--- 结束剪辑 ---

Gram 列出了该文档中可能出错的其他几件事。但是在仔细研究了你的配置之后。我很确定你的问题是虚拟主机请求被路由到了不正确的配置。

于 2014-01-05T09:05:07.910 回答
0

我认为WSGIApplicationGroup设置把你搞砸了。我会从两个 VirtualHost 条目中删除它。

于 2012-12-03T07:37:14.030 回答