[modwsgi] Re: Django virtualenv mod_wsgi, can't import django.*
2009/4/15 Alen Ribic :
>
> I've seen a few posts related to Django, virtualenv and mod_wsgi
> however still can't solve my problem.
>
> I keep getting "ImportError: No module named
> django.core.handlers.wsgi" in my apache error log no matter what I
> try.
Read:
http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Access_Rights_Of_Apache_User
Apache runs as a special user . If you are using embedded mode, or
daemon mode but haven't set 'user' option to be your account, then may
not be able to read directories/files if permissions on them aren't
correct.
Try your command line test, but become the user that Apache runs as
first. If that fails you know this is the problem.
In your command line test from your account, also do:
import django
print django.__file__
Ensure that that is the version you want used. Then check that all the
files readable to others and that directories readable and searchable
to others. For directories, this includes directories back up the
hierarchy to root of file system.
Graham
>
> Here is the wsgi script:
>
> intrack.wsgi
> import os, sys, site
>
> import logging
>
> #create logger
> logger = logging.getLogger("intrack_wsgi")
>
> logger.setLevel(logging.DEBUG)
>
> fh = logging.FileHandler("/tmp/InTrackWSGI.log")
> fh.setLevel(logging.DEBUG)
>
> formatter = logging.Formatter("%(asctime)s - %(name)s - %(levelname)s
> - %(message)s")
>
> fh.setFormatter(formatter)
> logger.addHandler(fh)
>
> sys.path.append('/home/intrack/intrack_pythonenv/projects')
> sys.path.append('/home/intrack/intrack_pythonenv/projects/InTrack')
> os.environ['DJANGO_SETTINGS_MODULE'] = 'InTrack.settings'
>
> ALLDIRS = ['/home/intrack/intrack_pythonenv/lib/python2.5/site-
> packages']
>
> # Remember original sys.path.
> prev_sys_path = list(sys.path)
>
> # Add each new site-packages directory.
> for directory in ALLDIRS:
> site.addsitedir(directory)
>
> # Reorder sys.path so new directories at the front.
> new_sys_path = []
> for item in list(sys.path):
> #logger.debug("sys.path item: %s" % item)
> if item not in prev_sys_path:
> new_sys_path.append(item)
> sys.path.remove(item)
> sys.path[:0] = new_sys_path
>
> logger.debug(sys.path)
> logger.debug("exec_prefix: %s" % sys.exec_prefix)
> logger.debug("version: %s" % sys.version)
>
> import django.core.handlers.wsgi
>
> application = django.core.handlers.wsgi.WSGIHandler()
>
> end - intrack.wsgi
>
> apache wsgi.conf
> #
> WSGIScriptAlias / /var/www/wsgi_scripts/InTrack.wsgi
> end - apache wsgi.conf
>
>
> apache error log
> [Wed Apr 15 12:04:29 2009] [error] [client 10.10.0.47] Traceback (most
> recent call last):
> [Wed Apr 15 12:04:29 2009] [error] [client 10.10.0.47] File "/var/
> www/wsgi_scripts/InTrack.wsgi", line 44, in
> [Wed Apr 15 12:04:29 2009] [error] [client 10.10.0.47] import
> django.core.handlers.wsgi
> [Wed Apr 15 12:04:29 2009] [error] [client 10.10.0.47] ImportError: No
> module named django.core.handlers.wsgi
> [Wed Apr 15 12:04:32 2009] [error] [client 10.10.0.47] mod_wsgi
> (pid=3610): Target WSGI script '/var/www/wsgi_scripts/InTrack.wsgi'
> cannot be loaded as Python module.
> [Wed Apr 15 12:04:32 2009] [error] [client 10.10.0.47] mod_wsgi
> (pid=3610): Exception occurred processing WSGI script '/var/www/
> wsgi_scripts/InTrack.wsgi'.
> [Wed Apr 15 12:04:32 2009] [error] [client 10.10.0.47] Traceback (most
> recent call last):
> [Wed Apr 15 12:04:32 2009] [error] [client 10.10.0.47] File "/var/
> www/wsgi_scripts/InTrack.wsgi", line 44, in
> [Wed Apr 15 12:04:32 2009] [error] [client 10.10.0.47] import
> django.core.handlers.wsgi
> [Wed Apr 15 12:04:32 2009] [error] [client 10.10.0.47] ImportError: No
> module named django.core.handlers.wsgi
> end - apache error log
>
>
> wsgi script log
> 2009-04-15 12:14:13,938 - intrack_wsgi - DEBUG - ['/home/intrack/
> intrack_pythonenv/lib/python2.5/site-packages', '/usr/local/lib/
> python25.zip', '/usr/local/lib/python2.5', '/usr/local/lib/python2.5/
> plat-linux2', '/usr/local/lib/python2.5/lib-tk', '/usr/local/lib/
> python2.5/lib-dynload', '/usr/local/lib/python2.5/site-packages', '/
> home/intrack/intrack_pythonenv/projects', '/home/intrack/
> intrack_pythonenv/projects/InTrack', '/home/intrack/intrack_pythonenv/
> projects', '/home/intrack/intrack_pythonenv/projects/InTrack', '/home/
> intrack/intrack_pythonenv/lib/python2.5/site-packages']
> 2009-04-15 12:14:13,939 - intrack_wsgi - DEBUG - exec_prefix: /usr/
> local
> 2009-04-15 12:14:13,939 - intrack_wsgi - DEBUG - version: 2.5.4
> (r254:67916, Apr 14 2009, 15:48:34)
> [GCC 4.1.2 20071124 (Red Hat 4.1.2-42)]
> end - wsgi script log
>
[modwsgi] Re: Django virtualenv mod_wsgi, can't import django.*
Thank you Graham for your reply.
You are definitely right about the permissions.
Apache User and Group directives are both set to 'apache'.
My wsgi (django) application is in the /home/intrack which is the
'intrack' user.
I added the WSGIDaemonProcess directive:
#
WSGIDaemonProcess user=intrack group=intrack python-path=/home/intrack/
intrack_pythonenv/lib/python2.5/site-packages processes=2 threads=25
#
WSGIScriptAlias / /var/www/wsgi_scripts/InTrack.wsgi
That still gave me a same error "ImportError: No module named
django.core.handlers.wsgi"
Question: who is the .wsgi script ran by? Apache special user? or the
one defined on WSGIDaemonProcess (in my case 'intrack' user)?
Also, am I on the right track here using WSGIDaemonProcess to set the
user I wish to run the application as? (I have fully tested the django
application using the 'intrack' user. By the way, /home/intrack has
the django app and the python virtual environment.)
I started the httpd service as root by the way.
Is perhaps the WSGIDaemonProcess not using the intrack user to run the
python process?
-Alen
On Apr 15, 12:35 pm, Graham Dumpleton
wrote:
> 2009/4/15 Alen Ribic :
>
>
>
> > I've seen a few posts related to Django, virtualenv and mod_wsgi
> > however still can't solve my problem.
>
> > I keep getting "ImportError: No module named
> > django.core.handlers.wsgi" in my apache error log no matter what I
> > try.
>
> Read:
>
> http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Access_Rights...
>
> Apache runs as a special user . If you are using embedded mode, or
> daemon mode but haven't set 'user' option to be your account, then may
> not be able to read directories/files if permissions on them aren't
> correct.
>
> Try your command line test, but become the user that Apache runs as
> first. If that fails you know this is the problem.
>
> In your command line test from your account, also do:
>
> import django
> print django.__file__
>
> Ensure that that is the version you want used. Then check that all the
> files readable to others and that directories readable and searchable
> to others. For directories, this includes directories back up the
> hierarchy to root of file system.
>
> Graham
>
>
>
> > Here is the wsgi script:
>
> > intrack.wsgi
> > import os, sys, site
>
> > import logging
>
> > #create logger
> > logger = logging.getLogger("intrack_wsgi")
>
> > logger.setLevel(logging.DEBUG)
>
> > fh = logging.FileHandler("/tmp/InTrackWSGI.log")
> > fh.setLevel(logging.DEBUG)
>
> > formatter = logging.Formatter("%(asctime)s - %(name)s - %(levelname)s
> > - %(message)s")
>
> > fh.setFormatter(formatter)
> > logger.addHandler(fh)
>
> > sys.path.append('/home/intrack/intrack_pythonenv/projects')
> > sys.path.append('/home/intrack/intrack_pythonenv/projects/InTrack')
> > os.environ['DJANGO_SETTINGS_MODULE'] = 'InTrack.settings'
>
> > ALLDIRS = ['/home/intrack/intrack_pythonenv/lib/python2.5/site-
> > packages']
>
> > # Remember original sys.path.
> > prev_sys_path = list(sys.path)
>
> > # Add each new site-packages directory.
> > for directory in ALLDIRS:
> > site.addsitedir(directory)
>
> > # Reorder sys.path so new directories at the front.
> > new_sys_path = []
> > for item in list(sys.path):
> > #logger.debug("sys.path item: %s" % item)
> > if item not in prev_sys_path:
> > new_sys_path.append(item)
> > sys.path.remove(item)
> > sys.path[:0] = new_sys_path
>
> > logger.debug(sys.path)
> > logger.debug("exec_prefix: %s" % sys.exec_prefix)
> > logger.debug("version: %s" % sys.version)
>
> > import django.core.handlers.wsgi
>
> > application = django.core.handlers.wsgi.WSGIHandler()
>
> > end - intrack.wsgi
>
> > apache wsgi.conf
> > #
> > WSGIScriptAlias / /var/www/wsgi_scripts/InTrack.wsgi
> > end - apache wsgi.conf
> >
>
> > apache error log
> > [Wed Apr 15 12:04:29 2009] [error] [client 10.10.0.47] Traceback (most
> > recent call last):
> > [Wed Apr 15 12:04:29 2009] [error] [client 10.10.0.47] File "/var/
> > www/wsgi_scripts/InTrack.wsgi", line 44, in
> > [Wed Apr 15 12:04:29 2009] [error] [client 10.10.0.47] import
> > django.core.handlers.wsgi
> > [Wed Apr 15 12:04:29 2009] [error] [client 10.10.0.47] ImportError: No
> > module named django.core.handlers.wsgi
> > [Wed Apr 15 12:04:32 2009] [error] [client 10.10.0.47] mod_wsgi
> > (pid=3610): Target WSGI script '/var/www/wsgi_scripts/InTrack.wsgi'
> > cannot be loaded as Python module.
> > [Wed Apr 15 12:04:32 2009] [error] [client 10.10.0.47] mod_wsgi
> > (pid=3610): Exception occurred processing WSGI script '/var/www/
> > wsgi_scripts/InTrack.wsgi'.
> > [Wed Apr 15 12:04:32 2009] [error] [client 10.10.0.47] Traceback (most
> > recent call last):
> > [Wed Apr 15 12:04:32 2009] [error] [
[modwsgi] Re: Django virtualenv mod_wsgi, can't import django.*
2009/4/16 Alen Ribic :
>
> Thank you Graham for your reply.
>
> You are definitely right about the permissions.
> Apache User and Group directives are both set to 'apache'.
> My wsgi (django) application is in the /home/intrack which is the
> 'intrack' user.
>
> I added the WSGIDaemonProcess directive:
> #
> WSGIDaemonProcess user=intrack group=intrack python-path=/home/intrack/
> intrack_pythonenv/lib/python2.5/site-packages processes=2 threads=25
> #
> WSGIScriptAlias / /var/www/wsgi_scripts/InTrack.wsgi
This is wrong. See:
http://code.google.com/p/modwsgi/wiki/QuickConfigurationGuide
http://code.google.com/p/modwsgi/wiki/VirtualEnvironments
for complete examples.
The mistakes are that you have called the daemon process group
'user=intrack' as first argument is supposed to be the name. You also
don't appear to have WSGIProcessGroup directive to delegate
application to that process group.
What you probably want is:
WSGIDaemonProcess mysite user=intrack group=intrack
python-path=/home/intrack/intrack_pythonenv/lib/python2.5/site-packages
processes=2 threads=25
WSGIProcessGroup mysite
WSGIScriptAlias / /var/www/wsgi_scripts/InTrack.wsgi
Graham
> That still gave me a same error "ImportError: No module named
> django.core.handlers.wsgi"
>
> Question: who is the .wsgi script ran by? Apache special user? or the
> one defined on WSGIDaemonProcess (in my case 'intrack' user)?
>
> Also, am I on the right track here using WSGIDaemonProcess to set the
> user I wish to run the application as? (I have fully tested the django
> application using the 'intrack' user. By the way, /home/intrack has
> the django app and the python virtual environment.)
>
> I started the httpd service as root by the way.
>
> Is perhaps the WSGIDaemonProcess not using the intrack user to run the
> python process?
>
> -Alen
>
>
> On Apr 15, 12:35 pm, Graham Dumpleton
> wrote:
>> 2009/4/15 Alen Ribic :
>>
>>
>>
>> > I've seen a few posts related to Django, virtualenv and mod_wsgi
>> > however still can't solve my problem.
>>
>> > I keep getting "ImportError: No module named
>> > django.core.handlers.wsgi" in my apache error log no matter what I
>> > try.
>>
>> Read:
>>
>> http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Access_Rights...
>>
>> Apache runs as a special user . If you are using embedded mode, or
>> daemon mode but haven't set 'user' option to be your account, then may
>> not be able to read directories/files if permissions on them aren't
>> correct.
>>
>> Try your command line test, but become the user that Apache runs as
>> first. If that fails you know this is the problem.
>>
>> In your command line test from your account, also do:
>>
>> import django
>> print django.__file__
>>
>> Ensure that that is the version you want used. Then check that all the
>> files readable to others and that directories readable and searchable
>> to others. For directories, this includes directories back up the
>> hierarchy to root of file system.
>>
>> Graham
>>
>>
>>
>> > Here is the wsgi script:
>>
>> > intrack.wsgi
>> > import os, sys, site
>>
>> > import logging
>>
>> > #create logger
>> > logger = logging.getLogger("intrack_wsgi")
>>
>> > logger.setLevel(logging.DEBUG)
>>
>> > fh = logging.FileHandler("/tmp/InTrackWSGI.log")
>> > fh.setLevel(logging.DEBUG)
>>
>> > formatter = logging.Formatter("%(asctime)s - %(name)s - %(levelname)s
>> > - %(message)s")
>>
>> > fh.setFormatter(formatter)
>> > logger.addHandler(fh)
>>
>> > sys.path.append('/home/intrack/intrack_pythonenv/projects')
>> > sys.path.append('/home/intrack/intrack_pythonenv/projects/InTrack')
>> > os.environ['DJANGO_SETTINGS_MODULE'] = 'InTrack.settings'
>>
>> > ALLDIRS = ['/home/intrack/intrack_pythonenv/lib/python2.5/site-
>> > packages']
>>
>> > # Remember original sys.path.
>> > prev_sys_path = list(sys.path)
>>
>> > # Add each new site-packages directory.
>> > for directory in ALLDIRS:
>> > site.addsitedir(directory)
>>
>> > # Reorder sys.path so new directories at the front.
>> > new_sys_path = []
>> > for item in list(sys.path):
>> > #logger.debug("sys.path item: %s" % item)
>> > if item not in prev_sys_path:
>> > new_sys_path.append(item)
>> > sys.path.remove(item)
>> > sys.path[:0] = new_sys_path
>>
>> > logger.debug(sys.path)
>> > logger.debug("exec_prefix: %s" % sys.exec_prefix)
>> > logger.debug("version: %s" % sys.version)
>>
>> > import django.core.handlers.wsgi
>>
>> > application = django.core.handlers.wsgi.WSGIHandler()
>>
>> > end - intrack.wsgi
>>
>> > apache wsgi.conf
>> > #
>> > WSGIScriptAlias / /var/www/wsgi_scripts/InTrack.wsgi
>> > end - apache wsgi.conf
>> >
>>
>> > apache error log
>> > [Wed Apr 15 12:04:29 2009] [error] [client 10.10.0.47] Traceback (mos
[modwsgi] Re: Django virtualenv mod_wsgi, can't import django.*
> What you probably want is:
>
> WSGIDaemonProcess mysite user=intrack group=intrack
> python-path=/home/intrack/intrack_pythonenv/lib/python2.5/site-packages
> processes=2 threads=25
>
> WSGIProcessGroup mysite
>
> WSGIScriptAlias / /var/www/wsgi_scripts/InTrack.wsgi
>
Thank you kindly, that took me another step forward.
Now I got the following error in log:
[Thu Apr 16 09:29:09 2009] [error] [client 41.240.91.23] (13)
Permission denied: mod_wsgi (pid=19767): Unable to connect to WSGI
daemon process 'InTrack' on '/etc/httpd/logs/wsgi.19713.0.1.sock'
after multiple attempts.
I take it, in this case, that my user 'intrack' doesn't have
permission to connect to the socket /etc/httpd/logs/wsgi.
19713.0.1.sock. Is this right and do you have any suggestions how to
rectify this please?
I can confirm that the socket file /etc/httpd/logs/wsgi.19713.0.1.sock
does exist hence has been created.
-Alen
On Apr 15, 11:17 pm, Graham Dumpleton
wrote:
> 2009/4/16 Alen Ribic :
>
>
>
> > Thank you Graham for your reply.
>
> > You are definitely right about the permissions.
> > Apache User and Group directives are both set to 'apache'.
> > My wsgi (django) application is in the /home/intrack which is the
> > 'intrack' user.
>
> > I added the WSGIDaemonProcess directive:
> > #
> > WSGIDaemonProcess user=intrack group=intrack python-path=/home/intrack/
> > intrack_pythonenv/lib/python2.5/site-packages processes=2 threads=25
> > #
> > WSGIScriptAlias / /var/www/wsgi_scripts/InTrack.wsgi
>
> This is wrong. See:
>
> http://code.google.com/p/modwsgi/wiki/QuickConfigurationGuide
> http://code.google.com/p/modwsgi/wiki/VirtualEnvironments
>
> for complete examples.
>
> The mistakes are that you have called the daemon process group
> 'user=intrack' as first argument is supposed to be the name. You also
> don't appear to have WSGIProcessGroup directive to delegate
> application to that process group.
>
> What you probably want is:
>
> WSGIDaemonProcess mysite user=intrack group=intrack
> python-path=/home/intrack/intrack_pythonenv/lib/python2.5/site-packages
> processes=2 threads=25
>
> WSGIProcessGroup mysite
>
> WSGIScriptAlias / /var/www/wsgi_scripts/InTrack.wsgi
>
> Graham
>
> > That still gave me a same error "ImportError: No module named
> > django.core.handlers.wsgi"
>
> > Question: who is the .wsgi script ran by? Apache special user? or the
> > one defined on WSGIDaemonProcess (in my case 'intrack' user)?
>
> > Also, am I on the right track here using WSGIDaemonProcess to set the
> > user I wish to run the application as? (I have fully tested the django
> > application using the 'intrack' user. By the way, /home/intrack has
> > the django app and the python virtual environment.)
>
> > I started the httpd service as root by the way.
>
> > Is perhaps the WSGIDaemonProcess not using the intrack user to run the
> > python process?
>
> > -Alen
>
> > On Apr 15, 12:35 pm, Graham Dumpleton
> > wrote:
> >> 2009/4/15 Alen Ribic :
>
> >> > I've seen a few posts related to Django, virtualenv and mod_wsgi
> >> > however still can't solve my problem.
>
> >> > I keep getting "ImportError: No module named
> >> > django.core.handlers.wsgi" in my apache error log no matter what I
> >> > try.
>
> >> Read:
>
> >> http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Access_Rights...
>
> >> Apache runs as a special user . If you are using embedded mode, or
> >> daemon mode but haven't set 'user' option to be your account, then may
> >> not be able to read directories/files if permissions on them aren't
> >> correct.
>
> >> Try your command line test, but become the user that Apache runs as
> >> first. If that fails you know this is the problem.
>
> >> In your command line test from your account, also do:
>
> >> import django
> >> print django.__file__
>
> >> Ensure that that is the version you want used. Then check that all the
> >> files readable to others and that directories readable and searchable
> >> to others. For directories, this includes directories back up the
> >> hierarchy to root of file system.
>
> >> Graham
>
> >> > Here is the wsgi script:
>
> >> > intrack.wsgi
> >> > import os, sys, site
>
> >> > import logging
>
> >> > #create logger
> >> > logger = logging.getLogger("intrack_wsgi")
>
> >> > logger.setLevel(logging.DEBUG)
>
> >> > fh = logging.FileHandler("/tmp/InTrackWSGI.log")
> >> > fh.setLevel(logging.DEBUG)
>
> >> > formatter = logging.Formatter("%(asctime)s - %(name)s - %(levelname)s
> >> > - %(message)s")
>
> >> > fh.setFormatter(formatter)
> >> > logger.addHandler(fh)
>
> >> > sys.path.append('/home/intrack/intrack_pythonenv/projects')
> >> > sys.path.append('/home/intrack/intrack_pythonenv/projects/InTrack')
> >> > os.environ['DJANGO_SETTINGS_MODULE'] = 'InTrack.settings'
>
> >> > ALLDIRS = ['/home/intrack/intrack_pythonenv/lib/python2.5/site-
> >> > packages']
>
> >> > # Remember original sys.path.
> >> > prev_sys_path = list(sys.path)
>
>
[modwsgi] Re: Django virtualenv mod_wsgi, can't import django.*
2009/4/16 Alen Ribic :
>
>> What you probably want is:
>>
>> WSGIDaemonProcess mysite user=intrack group=intrack
>> python-path=/home/intrack/intrack_pythonenv/lib/python2.5/site-packages
>> processes=2 threads=25
>>
>> WSGIProcessGroup mysite
>>
>> WSGIScriptAlias / /var/www/wsgi_scripts/InTrack.wsgi
>>
>
> Thank you kindly, that took me another step forward.
>
> Now I got the following error in log:
>
> [Thu Apr 16 09:29:09 2009] [error] [client 41.240.91.23] (13)
> Permission denied: mod_wsgi (pid=19767): Unable to connect to WSGI
> daemon process 'InTrack' on '/etc/httpd/logs/wsgi.19713.0.1.sock'
> after multiple attempts.
>
> I take it, in this case, that my user 'intrack' doesn't have
> permission to connect to the socket /etc/httpd/logs/wsgi.
> 19713.0.1.sock. Is this right and do you have any suggestions how to
> rectify this please?
> I can confirm that the socket file /etc/httpd/logs/wsgi.19713.0.1.sock
> does exist hence has been created.
Read:
http://code.google.com/p/modwsgi/wiki/ConfigurationIssues#Location_Of_UNIX_Sockets
Then try setting:
WSGISocketPrefix run/wsgi
in Apache configuration as directed.
Graham
> -Alen
>
> On Apr 15, 11:17 pm, Graham Dumpleton
> wrote:
>> 2009/4/16 Alen Ribic :
>>
>>
>>
>> > Thank you Graham for your reply.
>>
>> > You are definitely right about the permissions.
>> > Apache User and Group directives are both set to 'apache'.
>> > My wsgi (django) application is in the /home/intrack which is the
>> > 'intrack' user.
>>
>> > I added the WSGIDaemonProcess directive:
>> > #
>> > WSGIDaemonProcess user=intrack group=intrack python-path=/home/intrack/
>> > intrack_pythonenv/lib/python2.5/site-packages processes=2 threads=25
>> > #
>> > WSGIScriptAlias / /var/www/wsgi_scripts/InTrack.wsgi
>>
>> This is wrong. See:
>>
>> http://code.google.com/p/modwsgi/wiki/QuickConfigurationGuide
>> http://code.google.com/p/modwsgi/wiki/VirtualEnvironments
>>
>> for complete examples.
>>
>> The mistakes are that you have called the daemon process group
>> 'user=intrack' as first argument is supposed to be the name. You also
>> don't appear to have WSGIProcessGroup directive to delegate
>> application to that process group.
>>
>> What you probably want is:
>>
>> WSGIDaemonProcess mysite user=intrack group=intrack
>> python-path=/home/intrack/intrack_pythonenv/lib/python2.5/site-packages
>> processes=2 threads=25
>>
>> WSGIProcessGroup mysite
>>
>> WSGIScriptAlias / /var/www/wsgi_scripts/InTrack.wsgi
>>
>> Graham
>>
>> > That still gave me a same error "ImportError: No module named
>> > django.core.handlers.wsgi"
>>
>> > Question: who is the .wsgi script ran by? Apache special user? or the
>> > one defined on WSGIDaemonProcess (in my case 'intrack' user)?
>>
>> > Also, am I on the right track here using WSGIDaemonProcess to set the
>> > user I wish to run the application as? (I have fully tested the django
>> > application using the 'intrack' user. By the way, /home/intrack has
>> > the django app and the python virtual environment.)
>>
>> > I started the httpd service as root by the way.
>>
>> > Is perhaps the WSGIDaemonProcess not using the intrack user to run the
>> > python process?
>>
>> > -Alen
>>
>> > On Apr 15, 12:35 pm, Graham Dumpleton
>> > wrote:
>> >> 2009/4/15 Alen Ribic :
>>
>> >> > I've seen a few posts related to Django, virtualenv and mod_wsgi
>> >> > however still can't solve my problem.
>>
>> >> > I keep getting "ImportError: No module named
>> >> > django.core.handlers.wsgi" in my apache error log no matter what I
>> >> > try.
>>
>> >> Read:
>>
>> >> http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Access_Rights...
>>
>> >> Apache runs as a special user . If you are using embedded mode, or
>> >> daemon mode but haven't set 'user' option to be your account, then may
>> >> not be able to read directories/files if permissions on them aren't
>> >> correct.
>>
>> >> Try your command line test, but become the user that Apache runs as
>> >> first. If that fails you know this is the problem.
>>
>> >> In your command line test from your account, also do:
>>
>> >> import django
>> >> print django.__file__
>>
>> >> Ensure that that is the version you want used. Then check that all the
>> >> files readable to others and that directories readable and searchable
>> >> to others. For directories, this includes directories back up the
>> >> hierarchy to root of file system.
>>
>> >> Graham
>>
>> >> > Here is the wsgi script:
>>
>> >> > intrack.wsgi
>> >> > import os, sys, site
>>
>> >> > import logging
>>
>> >> > #create logger
>> >> > logger = logging.getLogger("intrack_wsgi")
>>
>> >> > logger.setLevel(logging.DEBUG)
>>
>> >> > fh = logging.FileHandler("/tmp/InTrackWSGI.log")
>> >> > fh.setLevel(logging.DEBUG)
>>
>> >> > formatter = logging.Formatter("%(asctime)s - %(name)s - %(levelname)s
>> >> > - %(message)s")
>>
>> >> > fh.setFormatter(formatter)
>> >> > logger.addHandler(fh)
>>
>> >
[modwsgi] Re: Django virtualenv mod_wsgi, can't import django.*
Ok that fixed the socket connection permission issue. I confirm that all is working now. The WSGISocketPrefix directive worked. I just set mine to: WSGISocketPrefix /tmp/wsgi No mo permission issues as /tmp on my server is readable and writeable by all users. Thank you very much for all your help. -Alen On Apr 16, 10:02 am, Graham Dumpleton wrote: > 2009/4/16 Alen Ribic : > > > > > > >> What you probably want is: > > >> WSGIDaemonProcess mysite user=intrack group=intrack > >> python-path=/home/intrack/intrack_pythonenv/lib/python2.5/site-packages > >> processes=2 threads=25 > > >> WSGIProcessGroup mysite > > >> WSGIScriptAlias / /var/www/wsgi_scripts/InTrack.wsgi > > > Thank you kindly, that took me another step forward. > > > Now I got the following error in log: > > > [Thu Apr 16 09:29:09 2009] [error] [client 41.240.91.23] (13) > > Permission denied: mod_wsgi (pid=19767): Unable to connect to WSGI > > daemon process 'InTrack' on '/etc/httpd/logs/wsgi.19713.0.1.sock' > > after multiple attempts. > > > I take it, in this case, that my user 'intrack' doesn't have > > permission to connect to the socket /etc/httpd/logs/wsgi. > > 19713.0.1.sock. Is this right and do you have any suggestions how to > > rectify this please? > > I can confirm that the socket file /etc/httpd/logs/wsgi.19713.0.1.sock > > does exist hence has been created. > > Read: > > http://code.google.com/p/modwsgi/wiki/ConfigurationIssues#Location_Of... > > Then try setting: > > WSGISocketPrefix run/wsgi > > in Apache configuration as directed. > > Graham > > > -Alen > > > On Apr 15, 11:17 pm, Graham Dumpleton > > wrote: > >> 2009/4/16 Alen Ribic : > > >> > Thank you Graham for your reply. > > >> > You are definitely right about the permissions. > >> > Apache User and Group directives are both set to 'apache'. > >> > My wsgi (django) application is in the /home/intrack which is the > >> > 'intrack' user. > > >> > I added the WSGIDaemonProcess directive: > >> > # > >> > WSGIDaemonProcess user=intrack group=intrack python-path=/home/intrack/ > >> > intrack_pythonenv/lib/python2.5/site-packages processes=2 threads=25 > >> > # > >> > WSGIScriptAlias / /var/www/wsgi_scripts/InTrack.wsgi > > >> This is wrong. See: > > >> http://code.google.com/p/modwsgi/wiki/QuickConfigurationGuide > >> http://code.google.com/p/modwsgi/wiki/VirtualEnvironments > > >> for complete examples. > > >> The mistakes are that you have called the daemon process group > >> 'user=intrack' as first argument is supposed to be the name. You also > >> don't appear to have WSGIProcessGroup directive to delegate > >> application to that process group. > > >> What you probably want is: > > >> WSGIDaemonProcess mysite user=intrack group=intrack > >> python-path=/home/intrack/intrack_pythonenv/lib/python2.5/site-packages > >> processes=2 threads=25 > > >> WSGIProcessGroup mysite > > >> WSGIScriptAlias / /var/www/wsgi_scripts/InTrack.wsgi > > >> Graham > > >> > That still gave me a same error "ImportError: No module named > >> > django.core.handlers.wsgi" > > >> > Question: who is the .wsgi script ran by? Apache special user? or the > >> > one defined on WSGIDaemonProcess (in my case 'intrack' user)? > > >> > Also, am I on the right track here using WSGIDaemonProcess to set the > >> > user I wish to run the application as? (I have fully tested the django > >> > application using the 'intrack' user. By the way, /home/intrack has > >> > the django app and the python virtual environment.) > > >> > I started the httpd service as root by the way. > > >> > Is perhaps the WSGIDaemonProcess not using the intrack user to run the > >> > python process? > > >> > -Alen > > >> > On Apr 15, 12:35 pm, Graham Dumpleton > >> > wrote: > >> >> 2009/4/15 Alen Ribic : > > >> >> > I've seen a few posts related to Django, virtualenv and mod_wsgi > >> >> > however still can't solve my problem. > > >> >> > I keep getting "ImportError: No module named > >> >> > django.core.handlers.wsgi" in my apache error log no matter what I > >> >> > try. > > >> >> Read: > > >> >> http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Access_Rights... > > >> >> Apache runs as a special user . If you are using embedded mode, or > >> >> daemon mode but haven't set 'user' option to be your account, then may > >> >> not be able to read directories/files if permissions on them aren't > >> >> correct. > > >> >> Try your command line test, but become the user that Apache runs as > >> >> first. If that fails you know this is the problem. > > >> >> In your command line test from your account, also do: > > >> >> import django > >> >> print django.__file__ > > >> >> Ensure that that is the version you want used. Then check that all the > >> >> files readable to others and that directories readable and searchable > >> >> to others. For directories, this includes directories back up the > >> >> hierarchy to root of file system. > > >> >> Graham > > >> >> > Here is the wsgi script: > > >> >> > int
[modwsgi] Re: Django virtualenv mod_wsgi, can't import django.*
2009/4/16 Alen Ribic : > > Ok that fixed the socket connection permission issue. > I confirm that all is working now. > > The WSGISocketPrefix directive worked. > > I just set mine to: > > WSGISocketPrefix /tmp/wsgi Preferably do not put it in /tmp, especially if this is a shared system. Part of the security of mod_wsgi relies on it being in a directory not writable to mortal users. So, try the 'run/wsgi' value first, with no leading slash. The 'run' directory is used on RedHat based distributions. If that doesn't work, see if the system has a '/var/run/httpd' or '/var/run/apache' directory and if so, set it to that full path with '/wsgi' on end. Normally there should be a 'run' symlink to that under Apache server root though, so saying 'run/wsgi' should be sufficient on those systems where 'log' directory, which would normally be used, is not readable to mortal users. Graham > No mo permission issues as /tmp on my server is readable and writeable > by all users. > > Thank you very much for all your help. > > -Alen > > On Apr 16, 10:02 am, Graham Dumpleton > wrote: >> 2009/4/16 Alen Ribic : >> >> >> >> >> >> >> What you probably want is: >> >> >> WSGIDaemonProcess mysite user=intrack group=intrack >> >> python-path=/home/intrack/intrack_pythonenv/lib/python2.5/site-packages >> >> processes=2 threads=25 >> >> >> WSGIProcessGroup mysite >> >> >> WSGIScriptAlias / /var/www/wsgi_scripts/InTrack.wsgi >> >> > Thank you kindly, that took me another step forward. >> >> > Now I got the following error in log: >> >> > [Thu Apr 16 09:29:09 2009] [error] [client 41.240.91.23] (13) >> > Permission denied: mod_wsgi (pid=19767): Unable to connect to WSGI >> > daemon process 'InTrack' on '/etc/httpd/logs/wsgi.19713.0.1.sock' >> > after multiple attempts. >> >> > I take it, in this case, that my user 'intrack' doesn't have >> > permission to connect to the socket /etc/httpd/logs/wsgi. >> > 19713.0.1.sock. Is this right and do you have any suggestions how to >> > rectify this please? >> > I can confirm that the socket file /etc/httpd/logs/wsgi.19713.0.1.sock >> > does exist hence has been created. >> >> Read: >> >> http://code.google.com/p/modwsgi/wiki/ConfigurationIssues#Location_Of... >> >> Then try setting: >> >> WSGISocketPrefix run/wsgi >> >> in Apache configuration as directed. >> >> Graham >> >> > -Alen >> >> > On Apr 15, 11:17 pm, Graham Dumpleton >> > wrote: >> >> 2009/4/16 Alen Ribic : >> >> >> > Thank you Graham for your reply. >> >> >> > You are definitely right about the permissions. >> >> > Apache User and Group directives are both set to 'apache'. >> >> > My wsgi (django) application is in the /home/intrack which is the >> >> > 'intrack' user. >> >> >> > I added the WSGIDaemonProcess directive: >> >> > # >> >> > WSGIDaemonProcess user=intrack group=intrack python-path=/home/intrack/ >> >> > intrack_pythonenv/lib/python2.5/site-packages processes=2 threads=25 >> >> > # >> >> > WSGIScriptAlias / /var/www/wsgi_scripts/InTrack.wsgi >> >> >> This is wrong. See: >> >> >> http://code.google.com/p/modwsgi/wiki/QuickConfigurationGuide >> >> http://code.google.com/p/modwsgi/wiki/VirtualEnvironments >> >> >> for complete examples. >> >> >> The mistakes are that you have called the daemon process group >> >> 'user=intrack' as first argument is supposed to be the name. You also >> >> don't appear to have WSGIProcessGroup directive to delegate >> >> application to that process group. >> >> >> What you probably want is: >> >> >> WSGIDaemonProcess mysite user=intrack group=intrack >> >> python-path=/home/intrack/intrack_pythonenv/lib/python2.5/site-packages >> >> processes=2 threads=25 >> >> >> WSGIProcessGroup mysite >> >> >> WSGIScriptAlias / /var/www/wsgi_scripts/InTrack.wsgi >> >> >> Graham >> >> >> > That still gave me a same error "ImportError: No module named >> >> > django.core.handlers.wsgi" >> >> >> > Question: who is the .wsgi script ran by? Apache special user? or the >> >> > one defined on WSGIDaemonProcess (in my case 'intrack' user)? >> >> >> > Also, am I on the right track here using WSGIDaemonProcess to set the >> >> > user I wish to run the application as? (I have fully tested the django >> >> > application using the 'intrack' user. By the way, /home/intrack has >> >> > the django app and the python virtual environment.) >> >> >> > I started the httpd service as root by the way. >> >> >> > Is perhaps the WSGIDaemonProcess not using the intrack user to run the >> >> > python process? >> >> >> > -Alen >> >> >> > On Apr 15, 12:35 pm, Graham Dumpleton >> >> > wrote: >> >> >> 2009/4/15 Alen Ribic : >> >> >> >> > I've seen a few posts related to Django, virtualenv and mod_wsgi >> >> >> > however still can't solve my problem. >> >> >> >> > I keep getting "ImportError: No module named >> >> >> > django.core.handlers.wsgi" in my apache error log no matter what I >> >> >> > try. >> >> >> >> Read: >> >> >> >> http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Access_Rights... >> >>
[modwsgi] Re: Django virtualenv mod_wsgi, can't import django.*
> So, try the 'run/wsgi' value first, with no leading slash. I am running on a RedHat flavored distro, so: WSGISocketPrefix run/wsgi worked 100%. Thank you again. -Alen On Apr 16, 10:25 am, Graham Dumpleton wrote: > 2009/4/16 Alen Ribic : > > > > > Ok that fixed the socket connection permission issue. > > I confirm that all is working now. > > > The WSGISocketPrefix directive worked. > > > I just set mine to: > > > WSGISocketPrefix /tmp/wsgi > > Preferably do not put it in /tmp, especially if this is a shared > system. Part of the security of mod_wsgi relies on it being in a > directory not writable to mortal users. > > So, try the 'run/wsgi' value first, with no leading slash. > > The 'run' directory is used on RedHat based distributions. > > If that doesn't work, see if the system has a '/var/run/httpd' or > '/var/run/apache' directory and if so, set it to that full path with > '/wsgi' on end. Normally there should be a 'run' symlink to that under > Apache server root though, so saying 'run/wsgi' should be sufficient > on those systems where 'log' directory, which would normally be used, > is not readable to mortal users. > > Graham > > > No mo permission issues as /tmp on my server is readable and writeable > > by all users. > > > Thank you very much for all your help. > > > -Alen > > > On Apr 16, 10:02 am, Graham Dumpleton > > wrote: > >> 2009/4/16 Alen Ribic : > > >> >> What you probably want is: > > >> >> WSGIDaemonProcess mysite user=intrack group=intrack > >> >> python-path=/home/intrack/intrack_pythonenv/lib/python2.5/site-packages > >> >> processes=2 threads=25 > > >> >> WSGIProcessGroup mysite > > >> >> WSGIScriptAlias / /var/www/wsgi_scripts/InTrack.wsgi > > >> > Thank you kindly, that took me another step forward. > > >> > Now I got the following error in log: > > >> > [Thu Apr 16 09:29:09 2009] [error] [client 41.240.91.23] (13) > >> > Permission denied: mod_wsgi (pid=19767): Unable to connect to WSGI > >> > daemon process 'InTrack' on '/etc/httpd/logs/wsgi.19713.0.1.sock' > >> > after multiple attempts. > > >> > I take it, in this case, that my user 'intrack' doesn't have > >> > permission to connect to the socket /etc/httpd/logs/wsgi. > >> > 19713.0.1.sock. Is this right and do you have any suggestions how to > >> > rectify this please? > >> > I can confirm that the socket file /etc/httpd/logs/wsgi.19713.0.1.sock > >> > does exist hence has been created. > > >> Read: > > >> http://code.google.com/p/modwsgi/wiki/ConfigurationIssues#Location_Of... > > >> Then try setting: > > >> WSGISocketPrefix run/wsgi > > >> in Apache configuration as directed. > > >> Graham > > >> > -Alen > > >> > On Apr 15, 11:17 pm, Graham Dumpleton > >> > wrote: > >> >> 2009/4/16 Alen Ribic : > > >> >> > Thank you Graham for your reply. > > >> >> > You are definitely right about the permissions. > >> >> > Apache User and Group directives are both set to 'apache'. > >> >> > My wsgi (django) application is in the /home/intrack which is the > >> >> > 'intrack' user. > > >> >> > I added the WSGIDaemonProcess directive: > >> >> > # > >> >> > WSGIDaemonProcess user=intrack group=intrack > >> >> > python-path=/home/intrack/ > >> >> > intrack_pythonenv/lib/python2.5/site-packages processes=2 threads=25 > >> >> > # > >> >> > WSGIScriptAlias / /var/www/wsgi_scripts/InTrack.wsgi > > >> >> This is wrong. See: > > >> >> http://code.google.com/p/modwsgi/wiki/QuickConfigurationGuide > >> >> http://code.google.com/p/modwsgi/wiki/VirtualEnvironments > > >> >> for complete examples. > > >> >> The mistakes are that you have called the daemon process group > >> >> 'user=intrack' as first argument is supposed to be the name. You also > >> >> don't appear to have WSGIProcessGroup directive to delegate > >> >> application to that process group. > > >> >> What you probably want is: > > >> >> WSGIDaemonProcess mysite user=intrack group=intrack > >> >> python-path=/home/intrack/intrack_pythonenv/lib/python2.5/site-packages > >> >> processes=2 threads=25 > > >> >> WSGIProcessGroup mysite > > >> >> WSGIScriptAlias / /var/www/wsgi_scripts/InTrack.wsgi > > >> >> Graham > > >> >> > That still gave me a same error "ImportError: No module named > >> >> > django.core.handlers.wsgi" > > >> >> > Question: who is the .wsgi script ran by? Apache special user? or the > >> >> > one defined on WSGIDaemonProcess (in my case 'intrack' user)? > > >> >> > Also, am I on the right track here using WSGIDaemonProcess to set the > >> >> > user I wish to run the application as? (I have fully tested the django > >> >> > application using the 'intrack' user. By the way, /home/intrack has > >> >> > the django app and the python virtual environment.) > > >> >> > I started the httpd service as root by the way. > > >> >> > Is perhaps the WSGIDaemonProcess not using the intrack user to run the > >> >> > python process? > > >> >> > -Alen > > >> >> > On Apr 15, 12:35 pm, Graham Dumpleton > >> >> > wrote: > >> >> >> 2009/4/15 Alen Ribic : > > >>
