0

For a while now I have been trying to get my django project install of badgr (badgr-server on github) working with mod_wsgi. I am pretty way in over my head but I do believe I have made some progress. Here is the error message I am currently getting:

    [Thu Nov 17 12:48:48.182772 2016] [core:notice] [pid 24556] AH00094:    Command line: '/opt/rh/httpd24/root/usr/sbin/httpd'
    [Thu Nov 17 12:48:50.421089 2016] [:error] [pid 24558] [remote 140.225.0.153:60440] mod_wsgi (pid=24558): Target WSGI script '/opt/badgr/code/apps/mainsite/wsgi.py' cannot be loaded as Python module.
    [Thu Nov 17 12:48:50.421165 2016] [:error] [pid 24558] [remote 140.225.0.153:60440] mod_wsgi (pid=24558): Exception occurred processing WSGI script '/opt/badgr/code/apps/mainsite/wsgi.py'.
    [Thu Nov 17 12:48:50.421200 2016] [:error] [pid 24558] [remote 140.225.0.153:60440] Traceback (most recent call last):
    [Thu Nov 17 12:48:50.421228 2016] [:error] [pid 24558] [remote 140.225.0.153:60440]   File "/opt/badgr/code/apps/mainsite/wsgi.py", line 27, in <module>
    [Thu Nov 17 12:48:50.421348 2016] [:error] [pid 24558] [remote 140.225.0.153:60440]     application = get_wsgi_application()
    [Thu Nov 17 12:48:50.421374 2016] [:error] [pid 24558] [remote 140.225.0.153:60440]   File "/opt/badgr/env/lib/python2.7/site-packages/django/core/wsgi.py", line 14, in get_wsgi_application
    [Thu Nov 17 12:48:50.421450 2016] [:error] [pid 24558] [remote 140.225.0.153:60440]     django.setup()
    [Thu Nov 17 12:48:50.421472 2016] [:error] [pid 24558] [remote 140.225.0.153:60440]   File "/opt/badgr/env/lib/python2.7/site-packages/django/__init__.py", line 20, in setup
    [Thu Nov 17 12:48:50.421558 2016] [:error] [pid 24558] [remote 140.225.0.153:60440]     configure_logging(settings.LOGGING_CONFIG, settings.LOGGING)
    [Thu Nov 17 12:48:50.421581 2016] [:error] [pid 24558] [remote 140.225.0.153:60440]   File "/opt/badgr/env/lib/python2.7/site-packages/django/conf/__init__.py", line 46, in __getattr__
    [Thu Nov 17 12:48:50.421705 2016] [:error] [pid 24558] [remote 140.225.0.153:60440]     self._setup(name)
    [Thu Nov 17 12:48:50.421728 2016] [:error] [pid 24558] [remote 140.225.0.153:60440]   File "/opt/badgr/env/lib/python2.7/site-packages/django/conf/__init__.py", line 42, in _setup
    [Thu Nov 17 12:48:50.421764 2016] [:error] [pid 24558] [remote 140.225.0.153:60440]     self._wrapped = Settings(settings_module)
    [Thu Nov 17 12:48:50.421782 2016] [:error] [pid 24558] [remote 140.225.0.153:60440]   File "/opt/badgr/env/lib/python2.7/site-packages/django/conf/__init__.py", line 98, in __init__
    [Thu Nov 17 12:48:50.421811 2016] [:error] [pid 24558] [remote 140.225.0.153:60440]     % (self.SETTINGS_MODULE, e)
    [Thu Nov 17 12:48:50.421841 2016] [:error] [pid 24558] [remote 140.225.0.153:60440] ImportError: Could not import settings 'settings' (Is it on sys.path? Is there an import error in the settings file?): No module named settings`

Here is a copy of my wsgi.py (/opt/badgr/code/apps/mainsite/wsgi.py):

    """
    WSGI config for badgr project.

    It exposes the WSGI callable as a module-level variable named ``application``.

    For more information on this file, see
    https://docs.djangoproject.com/en/1.7/howto/deployment/wsgi/
    """

    import sys
    import os
    import site

    activate_this = os.path.expanduser("/opt/badgr/env/bin/activate_this.py")
    execfile(activate_this, dict(__file__=activate_this))

    path = '/opt/badgr/code/apps/mainsite'
    if path not in sys.path:
       sys.path.append(path)

    os.environ["DJANGO_SETTINGS_MODULE"] = 'settings'

    site.addsitedir('/opt/badgr/env/lib/python2.7/site-packages')


    from django.core.wsgi import get_wsgi_application
    application = get_wsgi_application()

I am pretty sure my settings file is /opt/badgr/code/apps/mainsite/settings.py (or .pyc). But it seems to have trouble being called up.

Also it should be noted that I am running an env of Python 2.7: /opt/badgr/env/lib/python2.7/

Finnally: Here is my django config in httpd24 (/opt/rh/httpd24/root/etc/httpd/conf.d/django.conf):

    Alias /static /opt/badgr/code/staticfiles
    <Directory /opt/badgr/code/staticfiles>
     Require all granted
    </Directory>


    <Directory /opt/badgr/code/apps/mainsite>
        <Files wsgi.py>
     Require all granted
        </Files>
    </Directory>

    WSGISocketPrefix /var/run/wsgi/wsgi
    WSGIDaemonProcess badgr
    WSGIProcessGroup badgr
    WSGIPythonPath /opt/badgr:/opt/badgr/env/lib/python2.7/site-packages
    WSGIScriptAlias / /opt/badgr/code/apps/mainsite/wsgi.py
    WSGIPythonHome /opt/badgr/env

Any help or assistance appreciated.

1 Answers1

0

For the Apache configuration try using:

Alias /static /opt/badgr/code/staticfiles
<Directory /opt/badgr/code/staticfiles>
 Require all granted
</Directory>

<Directory /opt/badgr/code/apps/mainsite>
    <Files wsgi.py>
    Require all granted
    </Files>
</Directory>

WSGISocketPrefix /var/run/wsgi/wsgi
WSGIRestrictEmbedded On

WSGIDaemonProcess badge python-home=/opt/badgr/env python-path=/opt/badgr/code/apps
WSGIProcessGroup badge

WSGIScriptAlias / /opt/badgr/code/apps/mainsite/wsgi.py

For the wsgi.py file revert it back to being similar to what was created originally.

import os

os.environ["DJANGO_SETTINGS_MODULE"] = 'mainsite.settings'

from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()

The WSGIRestrictEmbedded ensures only mod_wsgi daemon mode is used.

Set the location of the Python virtual environment using python-home option to WSGIDaemonProcess. Set the parent directory of your project in python-path. Change DJANGO_SETTINGS_MODULE to include the project name in module path again.


UPDATE 1

Add to the wsgi.py file:

import sys
print 'SYS.PATH = %r' % sys.path

Check the Apache error log to see what the path is and verify that the parent directory above where your project is, is listed.

Graham Dumpleton
  • 57,726
  • 6
  • 119
  • 134
  • After trying the above and still getting similiar error messages I decided to consolidate down to having just one wsgi.py (/opt/badgr/env/lib/python2.7/site-packages/django/core/wsgi.py) rather than two in differen't places. This is what it contains now: `import django import os def get_wsgi_application(): django.setup() return WSGIHandler() os.environ["DJANGO_SETTINGS_MODULE"] = 'mainsite.settings' from django.core.wsgi import get_wsgi_application application = get_wsgi_application()` The error I am getting now is the same pretty much. Thoughts? (Sorry for newbness) – Sesshoumaru Nov 18 '16 at 20:45
  • Use the original ``wsgi.py`` file. If you keep changing it around you keep causing confusion. In the ``wsgi.py`` file add the debug I mention above. – Graham Dumpleton Nov 18 '16 at 21:23
  • Okay thanks, I will try this tomorrow and edit this comment or post a new one based on the results. – Sesshoumaru Nov 22 '16 at 00:15
  • I did not get to this today but I will probably get to it on Monday. Thanks again for your continuing help with this. I hope you have a good holiday. – Sesshoumaru Nov 23 '16 at 22:33
  • Okay I think we have made some progress. I am no longer getting the error about not finding the settings module. However I am still getting the following the other errors I was receiving in the original post in addition to this: `[Tue Nov 29 15:13:41.912012 2016] [:error] [pid 24544] [remote 140.225.0.153:33208] raise ImproperlyConfigured("The SECRET_KEY setting must not be empty.") [Tue Nov 29 15:13:41.912067 2016] [:error] [pid 24544] [remote 140.225.0.153:33208] ImproperlyConfigured: The SECRET_KEY setting must not be empty.` – Sesshoumaru Nov 29 '16 at 21:20
  • I am assuming I am missing some configurations in my __init__.pu and wsgi.py files because that is where I am getting the errors? Thanks for your continued assistance. – Sesshoumaru Nov 29 '16 at 21:21
  • The Django ``SECRET_KEY`` would normally be set in the Django settings module. Do you have it so that it expects to pull it from an environment variable? – Graham Dumpleton Nov 30 '16 at 00:14
  • The application should be pulling from a env of python 2.7.8 if that is what you mean. But as far as I know it doesn't have any password or key setup? – Sesshoumaru Dec 01 '16 at 17:24
  • I commented out the follow in the init file: `# if not self.SECRET_KEY: # raise ImproperlyConfigured("The SECRET_KEY setting must not be empty.")` and now I am getting the following in my httpd24 errors: `[Thu Dec 01 12:18:09.793953 2016] [:error] [pid 31047] [remote 140.225.0.153:164] NameError: global name 'WSGIHandler' is not defined` – Sesshoumaru Dec 01 '16 at 18:24
  • Normally the ``SECRET_KEY`` is set in the Django settings module. Some don't do this though because that file will be in a public git repo and you don't want to expose that key. So what they do is ``SECRET_KEY = os.environ.get('SECRET_KEY')`` or similar and expect it to be set as a process environment variable. With Apache, your user environment variables are not inherited by Apache, so the environment variable will not be set. You need to use different ways of setting the ``SECRET_KEY`` if using Apache. – Graham Dumpleton Dec 01 '16 at 23:43
  • So what do you have ``SECRET_KEY`` setting as in the Django settings module if it is not being set to an actual string value in the code file? – Graham Dumpleton Dec 01 '16 at 23:44
  • Honestly am not sure where that setting is being gotten from or set. The only place I have found concerning it is the line above that I tried commenting out. That only raises an alert about the self secret key not existing. Doesn't really tell me where to fix that. – Sesshoumaru Dec 05 '16 at 16:46
  • I found this: http://stackoverflow.com/questions/29455057/django-core-exceptions-improperlyconfigured-the-secret-key-setting-must-not-be generated a key based on it. I found out that /opt/badgr/env/lib/python2.7/site-packages/django/conf/global_settings.py is getting referenced for the key which is odd because it should be referencing /opt/badgr/code/apps/mainsite/settings.py instead. That may be the root of my issue, investigating further but would appreciate any further input. Thanks. – Sesshoumaru Dec 05 '16 at 17:02
  • Okay that indeed fixed the keying issue but I am still getting the following: `[Mon Dec 05 11:03:58.947390 2016] [:error] [pid 6777] [remote 140.225.0.153:32054] File "/opt/badgr/env/lib/python2.7/site-packages/django/core/wsgi.py", line 6, in get_wsgi_application [Mon Dec 05 11:03:58.947420 2016] [:error] [pid 6777] [remote 140.225.0.153:32054] return WSGIHandler() [Mon Dec 05 11:03:58.947449 2016] [:error] [pid 6777] [remote 140.225.0.153:32054] NameError: global name 'WSGIHandler' is not defined` – Sesshoumaru Dec 05 '16 at 17:06
  • Have you gone back and fixed up how you are configuring the Python virtual environment as described above? What does ``pip freeze`` say about what version of Django you have installed? – Graham Dumpleton Dec 05 '16 at 19:44
  • When you say "as described above" are you referring to the other stack overflow link I posted? If so I have not as I have just manually added a key in /opt/badgr/env/lib/python2.7/site-packages/django/conf/globa‌​l_settings.py as that seemed to get rid of the error I was seeing about the secret. Should I do the rest of the steps to help with the other issues I am seeing as well? – Sesshoumaru Dec 05 '16 at 21:45
  • Compare the Apache configuration I have in my answer to what you had. They are not the same. The changes were to ensure you are using the correct Python virtual environment. For more details on how to correctly set up a virtual environment with mod_wsgi see documentation at http://modwsgi.readthedocs.io/en/develop/user-guides/virtual-environments.html Use ``python-home`` and not ``python-path`` as using ``python-path`` can mask issues. Better to use recommended ``python-home`` option, setting it as explain in the documentation. – Graham Dumpleton Dec 05 '16 at 21:55
  • Okay will look into doing that. Django==1.7.1 Django-Select2==4.2.2 when I have the env activated. – Sesshoumaru Dec 05 '16 at 22:23
  • Well I have been told to abandon this project for other projects but I greatly appreciate all this assistance you have provided. If I even re-open it and try again I will post here. – Sesshoumaru Dec 08 '16 at 17:04