Re: environment variables in virtualenv's postactivate using mod_wsgi

[Bill Freeman]

On Wed, May 22, 2013 at 12:41 PM, Charles Mulder <charle...@gmail.com> wrote:

Hi, 

Hope you're well. 

I've added a couple of environment variables to my virtualenv postactivate file, for example:

export DATABASE_USER="root"

export DATABASE_PASSWORD="12345678"

N.B. that environment variables are not as secure as you might hope (though certainly better than passwords on the command line).

I then assign those variables in my settings.py using os.environ['DATABASE_USER'], for example

DATABASE_USER = os.environ['DATABASE_USER']

Since my Apache virtualhost file contains

WSGIDaemonProcess mysite.local python-path=/my/python/path:/path/to/my/project/venv/lib/python2.7/site-packages

If memory serves, this does not cause the .pth files in site-packages to be applied.  Could be OK.  Could be a problem.

If you have only one wsgi script on that Apache, you might consider the WSGIPythonHome directive (the directive must be global, rather than in a vhost, thus there can be only one).

Or, if you have a new enough mod_wsgi, the WSGIDaemonProcess directive also takes a "python-home" argument  (I do have three or four ve's running on one Apache this way).  There are some restrictions as to other configuration stuff, but the defaults work for me.

Otherwise you need to play with sys.path in your wsgi script, or at least invoke site.addsitedir() correctly, see: http://code.google.com/p/modwsgi/wiki/VirtualEnvironments

WSGIProcessGroup mysite.local

WSGIScriptAlias / /path/to/my/project/wsgi.py

This wouldn't be the wsgi.py created by manage.py startproject, would it?  It's necessary these days for manag.py runserver, but I've yet to find it adequate to use with mod_wsgi.  (I must confess that I haven't played with it for at least 6 months.)  It's not too hard to write your own, taking all the path manipulations, that runserver doesn't need but mod_wsgi does, into account.

As I understand it, this tells mod_wsgi to run in daemon mode and which virtualenv to use.

Since it knows which virtualenv to use, I would image it would run postactivate, thereby enabling my environment variables, but this however is not the case. 

mod_wsgi does not "activate" the virtualenv.  You will have to find somewhere else to add environment variables.  Maybe in some Apache config file, but more likely in your wsgi script.

The only truly useful thing that activate normally does is to put the directory containing the venv's python early on the shell path.  If you run:

  /absolute/path/to/ve/bin/python manage.py runserver

It will work just fine (for folks who don't depend on other actions like setting environment variables in postactivate).

You can use *nix's cmp command to confirm that the python is an unmodified of the(a) system python.  The whole trick to virtualenv is that, if the PYTHONHOME environment variable isn't set. python uses the location of the executable file to figure out where the correct lib/pythonX.X directory is.

Am I doing something wrong? Any suggestions or recommendations are welcome. 

Kind regards,

 

[Graham Dumpleton]

On Thursday, 23 May 2013 07:57:02 UTC+10, ke1g wrote:

Since my Apache virtualhost file contains

WSGIDaemonProcess mysite.local python-path=/my/python/path:/path/to/my/project/venv/lib/python2.7/site-packages

If memory serves, this does not cause the .pth files in site-packages to be applied.  Could be OK.  Could be a problem.

It has processed .pth files and ensured that path ordering is done as necessary since mod_wsgi 2.0.

 

WSGIProcessGroup mysite.local

WSGIScriptAlias / /path/to/my/project/wsgi.py

This wouldn't be the wsgi.py created by manage.py startproject, would it?  It's necessary these days for manag.py runserver, but I've yet to find it adequate to use with mod_wsgi.  (I must confess that I haven't played with it for at least 6 months.)  It's not too hard to write your own, taking all the path manipulations, that runserver doesn't need but mod_wsgi does, into account.

Except for setdefault() being used to set environment variables causing issues in some cases:

http://blog.dscpl.com.au/2012/10/requests-running-in-wrong-django.html

the generated wsgi.py file should be fine, you can do all the path setup from mod_wsgi.

A reasonable configuration if using mod_wsgi 3.4 would be:

WSGIDaemonProcess example.com python-home=/path/to/your/venv python-path=/path/to/mysite.com

WSGIProcessGroup example.com

WSGIApplicationGroup %{GLOBAL}

WSGIRestrictEmbedded On

WSGIScriptAlias / /path/to/mysite.com/mysite/wsgi.py

This is mostly covered in:

https://docs.djangoproject.com/en/dev/howto/deployment/wsgi/modwsgi/

with the exception that using python-home in this example.

The WSGIRestrictEmbedded directive turns off Python in the Apache worker processes since you are using a daemon process group. Saves on memory and CPU startup cost of worker processes.

The WSGIApplicationGroup with value %{GLOBAL} for daemon process forces use of main interpreter, avoiding creation of a second sub interpreter context and avoids issues with some third party C extension modules which do not work properly in sub interpreters.

Graham

[Steffen Zieger]

On 22.05.13 18:41, Charles Mulder wrote:
> Hi,
Hi!

> Am I doing something wrong? Any suggestions or recommendations are welcome.

This might help you:

http://drumcoder.co.uk/blog/2010/nov/12/apache-environment-variables-and-mod_wsgi/

> Kind regards,
> C

Kind regards

Steffen