GrahamDumpleton · May 18, 2024 03:35 · Dec 8, 2014 · Dec 8, 2014 · Dec 8, 2014 · Dec 8, 2014
diff --git a/gistfile1.md b/gistfile1.md
@@ -83,6 +83,8 @@ So you would be setting the ``python-path`` option there to the location of your
 
 This method can be used for any environment variables with the exception of those which affect the operation of the processes as a whole at a system level. That is, you cannot set ``LANG`` and ``LC_ALL`` in this way. Modern versions of mod_wsgi though have ``lang`` and ``locale`` options on ``WSGIDaemonProcess`` directive which achieve the same result. If not using daemon mode, you should be as embedded mode isn't generally recommended.
 
+* http://blog.dscpl.com.au/2014/09/setting-lang-and-lcall-when-using.html
+
 The only other problematic environment variable is ``LD_LIBRARY_PATH``. This is only a problem where shared libraries aren't installed in a proper system location. If this is unavoidable, set ``LD_RUN_PATH`` to the library directory when installing any Python modules using the library and the location will be embedded in the Python module extension so that the shared library will be found whether or not ``LD_LIBRARY_PATH`` is set properly.
 
 In summary, ignore the Django generated ``wsgi.py`` file. This never used to exist and that it started to be generated has caused problems with understanding how to set up Apache/mod_wsgi ever since. The first problem was that it used ``os.environ.setdefault()`` which causes problems when running multiple Django applications in the same Apache process. Secondly, that ``wsgi.py`` was auto generated, it gave users the impression that it would always be correct, must be used and wouldn't need modifying. Consequence was that people stopped seeing what one of the main roles of the WSGi script file was for, which was to set environment variables before the Django application got loaded.
diff --git a/gistfile1.md b/gistfile1.md
@@ -85,4 +85,4 @@ This method can be used for any environment variables with the exception of thos
 
 The only other problematic environment variable is ``LD_LIBRARY_PATH``. This is only a problem where shared libraries aren't installed in a proper system location. If this is unavoidable, set ``LD_RUN_PATH`` to the library directory when installing any Python modules using the library and the location will be embedded in the Python module extension so that the shared library will be found whether or not ``LD_LIBRARY_PATH`` is set properly.
 
-In summary, ignore the Django generated ``wsgi.py`` file. This never used to exist and that it started to be generated has caused problems with understanding how to set up Apache/mod_wsgi ever since. The first problem was that it used ``os.environ.setdefault()`` which causes problems when running multiple Django applications in the same Apache process. Secondly, that ``wsgi.py`` was auto generated, it gave users the impression that it would always be correct and wouldn't need modifying. Consequence was that people stopped seeing what one of the main roles of the WSGi script file was for, which was to set environment variables before the Django application got loaded.
+In summary, ignore the Django generated ``wsgi.py`` file. This never used to exist and that it started to be generated has caused problems with understanding how to set up Apache/mod_wsgi ever since. The first problem was that it used ``os.environ.setdefault()`` which causes problems when running multiple Django applications in the same Apache process. Secondly, that ``wsgi.py`` was auto generated, it gave users the impression that it would always be correct, must be used and wouldn't need modifying. Consequence was that people stopped seeing what one of the main roles of the WSGi script file was for, which was to set environment variables before the Django application got loaded.
diff --git a/gistfile1.md b/gistfile1.md
@@ -70,6 +70,17 @@ Require all granted
 
 Change the ``WSGIScriptAlias`` and ``Directory`` directive paths if you do put it under ``/etc`` somewhere, but leave the ``WSGIPythonPath`` setting alone as that still needs to refer to where the source code for the project resides.
 
+If using mod_wsgi daemon mode as you should be, you would instead also have something like:
+
+```
+WSGIDaemonProcess example.com python-path=/path/to/mysite.com:/path/to/venv/lib/python2.7/site-packages
+WSGIProcessGroup example.com
+```
+
+So you would be setting the ``python-path`` option there to the location of your your source code instead. If using a modern version of mod_wsgi, use ``python-home`` instead.
+
+* http://blog.dscpl.com.au/2014/09/python-module-search-path-and-modwsgi.html
+
 This method can be used for any environment variables with the exception of those which affect the operation of the processes as a whole at a system level. That is, you cannot set ``LANG`` and ``LC_ALL`` in this way. Modern versions of mod_wsgi though have ``lang`` and ``locale`` options on ``WSGIDaemonProcess`` directive which achieve the same result. If not using daemon mode, you should be as embedded mode isn't generally recommended.
 
 The only other problematic environment variable is ``LD_LIBRARY_PATH``. This is only a problem where shared libraries aren't installed in a proper system location. If this is unavoidable, set ``LD_RUN_PATH`` to the library directory when installing any Python modules using the library and the location will be embedded in the Python module extension so that the shared library will be found whether or not ``LD_LIBRARY_PATH`` is set properly.

diff --git a/gistfile1.md b/gistfile1.md
@@ -53,7 +53,7 @@ from django.core.wsgi import get_wsgi_application
 application = get_wsgi_application()
 ```
 
-Alternatively, you could put the WSGI script file in a completely different location outside of the source code for your application, even putting it in a subdirectory under ``/etc``. In other words, tell your system adminstrator what need to go in it and let them create it where they want to per their policies.
+Alternatively, you could put the WSGI script file in a completely different location outside of the source code for your application, even putting it in a subdirectory under ``/etc``. In other words, tell your system adminstrator what needs to go in it and let them create it where they want to per their policies.
 
 With the modified WSGI script file in place, change the name of the WSGI script file in the Apache configuration snippet to refer to it instead of the original ``wsgi.py``.
 

diff --git a/gistfile1.md b/gistfile1.md
@@ -53,6 +53,8 @@ from django.core.wsgi import get_wsgi_application
 application = get_wsgi_application()
 ```
 
+Alternatively, you could put the WSGI script file in a completely different location outside of the source code for your application, even putting it in a subdirectory under ``/etc``. In other words, tell your system adminstrator what need to go in it and let them create it where they want to per their policies.
+
 With the modified WSGI script file in place, change the name of the WSGI script file in the Apache configuration snippet to refer to it instead of the original ``wsgi.py``.
 
 ```
@@ -66,6 +68,8 @@ Require all granted
 </Directory>
 ```
 
+Change the ``WSGIScriptAlias`` and ``Directory`` directive paths if you do put it under ``/etc`` somewhere, but leave the ``WSGIPythonPath`` setting alone as that still needs to refer to where the source code for the project resides.
+
 This method can be used for any environment variables with the exception of those which affect the operation of the processes as a whole at a system level. That is, you cannot set ``LANG`` and ``LC_ALL`` in this way. Modern versions of mod_wsgi though have ``lang`` and ``locale`` options on ``WSGIDaemonProcess`` directive which achieve the same result. If not using daemon mode, you should be as embedded mode isn't generally recommended.
 
 The only other problematic environment variable is ``LD_LIBRARY_PATH``. This is only a problem where shared libraries aren't installed in a proper system location. If this is unavoidable, set ``LD_RUN_PATH`` to the library directory when installing any Python modules using the library and the location will be embedded in the Python module extension so that the shared library will be found whether or not ``LD_LIBRARY_PATH`` is set properly.

diff --git a/gistfile1.md b/gistfile1.md
@@ -68,6 +68,6 @@ Require all granted
 
 This method can be used for any environment variables with the exception of those which affect the operation of the processes as a whole at a system level. That is, you cannot set ``LANG`` and ``LC_ALL`` in this way. Modern versions of mod_wsgi though have ``lang`` and ``locale`` options on ``WSGIDaemonProcess`` directive which achieve the same result. If not using daemon mode, you should be as embedded mode isn't generally recommended.
 
-The only other problematic environment variable is ``LD_LIBRARY_PATH``. This is only a problem where shared libraries aren't installed in a proper system location. If this is unavoidable, set ``LD_RUN_PATH`` when installing any Python modules using the library and the location will be embedded in the Python module extension so that the shared library will be found whether or not ``LD_LIBRARY_PATH`` is set properly.
+The only other problematic environment variable is ``LD_LIBRARY_PATH``. This is only a problem where shared libraries aren't installed in a proper system location. If this is unavoidable, set ``LD_RUN_PATH`` to the library directory when installing any Python modules using the library and the location will be embedded in the Python module extension so that the shared library will be found whether or not ``LD_LIBRARY_PATH`` is set properly.
 
 In summary, ignore the Django generated ``wsgi.py`` file. This never used to exist and that it started to be generated has caused problems with understanding how to set up Apache/mod_wsgi ever since. The first problem was that it used ``os.environ.setdefault()`` which causes problems when running multiple Django applications in the same Apache process. Secondly, that ``wsgi.py`` was auto generated, it gave users the impression that it would always be correct and wouldn't need modifying. Consequence was that people stopped seeing what one of the main roles of the WSGi script file was for, which was to set environment variables before the Django application got loaded.
diff --git a/gistfile1.md b/gistfile1.md
@@ -36,7 +36,24 @@ from django.core.wsgi import get_wsgi_application
 application = get_wsgi_application()
 ```
 
-With that in place, change the name of the WSGI script file in the Apache configuration snippet.
+If you are concerned that you might have sensitive settings in a file which is part of your source code repository. Then have just the environment variables being set in a separate Python code file which you manually copy into place on the host in a directory such as ``/etc``.
+
+For example, on OpenShift, you would place the file in ``${OPENSHIFT_DATA_DIR}`` and then use:
+
+```
+import os
+
+OPENSHIFT_DATA_DIR = os.environ['OPENSHIFT_DATA_DIR']
+
+os.environ['DJANGO_SETTINGS_MODULE'] = 'mysite.settings'
+
+execfile(os.path.join(OPENSHIFT_DATA_DIR, 'mysite-production-envvars.py'))
+
+from django.core.wsgi import get_wsgi_application
+application = get_wsgi_application()
+```
+
+With the modified WSGI script file in place, change the name of the WSGI script file in the Apache configuration snippet to refer to it instead of the original ``wsgi.py``.
 
 ```
 WSGIScriptAlias / /path/to/mysite.com/mysite/production.wsgi

diff --git a/gistfile1.md b/gistfile1.md
@@ -13,7 +13,7 @@ Require all granted
 
 To set environment variables which would be inherited by the Django application referred to by this, one can set them in the ``envvars`` file created as part of the Apache installation. There are a few problems with that though.
 
-The first is that Linux distributions created a completely different way of configuring Apache and ignored in large part how the Apache Software Foundations default Apache distribution works. How you would do the equivalent varies between Linux distributions but generally requires setting some other special file alongside the system init scripts. Unfortunately some Linux distributions did't make this a separate file and instead require you to modify the init scripts themselves.
+The first is that Linux distributions created a completely different way of configuring Apache and ignored in large part how the Apache Software Foundations default Apache distribution works. How you would do the equivalent varies between Linux distributions but generally requires setting some other special file alongside the system init scripts. Unfortunately some Linux distributions didn't make this a separate file and instead require you to modify the init scripts themselves.
 
 The second is that the ``envvars`` file applies to the whole of Apache and cannot be made to apply to specific mod_wsgi daemon processes. This makes it unsuitable where hosting multiple Python web applications under the same Apache.
 

diff --git a/gistfile1.md b/gistfile1.md
@@ -53,4 +53,4 @@ This method can be used for any environment variables with the exception of thos
 
 The only other problematic environment variable is ``LD_LIBRARY_PATH``. This is only a problem where shared libraries aren't installed in a proper system location. If this is unavoidable, set ``LD_RUN_PATH`` when installing any Python modules using the library and the location will be embedded in the Python module extension so that the shared library will be found whether or not ``LD_LIBRARY_PATH`` is set properly.
 
-In summary, ignore the Django generated ``wsgi.py`` file. This never used to exist and that it started to be generated has caused problems with mod_wsgi ever since. This is because it used ``os.environ.setdefault()`` that causes problems when running multiple Django applications in the same Apache process. Secondly, that ``wsgi.py`` was auto generated, it gave people the impression that it would always be correct and wouldn't need modifying. Consequence was that people stopped seeing what one of the main roles of the WSGi script file was for, which was to set environment variables before the Django application got loaded.
+In summary, ignore the Django generated ``wsgi.py`` file. This never used to exist and that it started to be generated has caused problems with understanding how to set up Apache/mod_wsgi ever since. The first problem was that it used ``os.environ.setdefault()`` which causes problems when running multiple Django applications in the same Apache process. Secondly, that ``wsgi.py`` was auto generated, it gave users the impression that it would always be correct and wouldn't need modifying. Consequence was that people stopped seeing what one of the main roles of the WSGi script file was for, which was to set environment variables before the Django application got loaded.
diff --git a/gistfile1.md b/gistfile1.md
@@ -51,6 +51,6 @@ Require all granted
 
 This method can be used for any environment variables with the exception of those which affect the operation of the processes as a whole at a system level. That is, you cannot set ``LANG`` and ``LC_ALL`` in this way. Modern versions of mod_wsgi though have ``lang`` and ``locale`` options on ``WSGIDaemonProcess`` directive which achieve the same result. If not using daemon mode, you should be as embedded mode isn't generally recommended.
 
-The only other problematic environment variable is ``LD_LIBRARY_PATH``. This is only a problem where shared libraries aren't installed in a proper system location. If this is unavoidable, set ``LD_RUN_PATH`` when installing and Python modules using the library and the location will be embedded in the Python module extension so that the shared library will be found whether or not ``LD_LIBRARY_PATH`` is set properly.
+The only other problematic environment variable is ``LD_LIBRARY_PATH``. This is only a problem where shared libraries aren't installed in a proper system location. If this is unavoidable, set ``LD_RUN_PATH`` when installing any Python modules using the library and the location will be embedded in the Python module extension so that the shared library will be found whether or not ``LD_LIBRARY_PATH`` is set properly.
 
 In summary, ignore the Django generated ``wsgi.py`` file. This never used to exist and that it started to be generated has caused problems with mod_wsgi ever since. This is because it used ``os.environ.setdefault()`` that causes problems when running multiple Django applications in the same Apache process. Secondly, that ``wsgi.py`` was auto generated, it gave people the impression that it would always be correct and wouldn't need modifying. Consequence was that people stopped seeing what one of the main roles of the WSGi script file was for, which was to set environment variables before the Django application got loaded.
diff --git a/gistfile1.md b/gistfile1.md
@@ -13,7 +13,7 @@ Require all granted
 
 To set environment variables which would be inherited by the Django application referred to by this, one can set them in the ``envvars`` file created as part of the Apache installation. There are a few problems with that though.
 
-The first is that Linux distributions created a completely different way of configuring Apache and ignored in large part how the Apache Software Foundations default Apache distribution works. How you would do the equivalent varies between Linux distributions but generally requires setting some over special file in the system init scripts.
+The first is that Linux distributions created a completely different way of configuring Apache and ignored in large part how the Apache Software Foundations default Apache distribution works. How you would do the equivalent varies between Linux distributions but generally requires setting some other special file alongside the system init scripts. Unfortunately some Linux distributions did't make this a separate file and instead require you to modify the init scripts themselves.
 
 The second is that the ``envvars`` file applies to the whole of Apache and cannot be made to apply to specific mod_wsgi daemon processes. This makes it unsuitable where hosting multiple Python web applications under the same Apache.
 

diff --git a/gistfile1.md b/gistfile1.md
@@ -11,7 +11,7 @@ Require all granted
 </Directory>
 ```
 
-To set environment variables which would be inherited by the Django application referred to by this, one can set them in the 'envvars' file created as part of the Apache installation. There are a few problems with that though.
+To set environment variables which would be inherited by the Django application referred to by this, one can set them in the ``envvars`` file created as part of the Apache installation. There are a few problems with that though.
 
 The first is that Linux distributions created a completely different way of configuring Apache and ignored in large part how the Apache Software Foundations default Apache distribution works. How you would do the equivalent varies between Linux distributions but generally requires setting some over special file in the system init scripts.
 

diff --git a/gistfile1.md b/gistfile1.md
@@ -0,0 +1,56 @@
+Django documentation says to use:
+
+```
+WSGIScriptAlias / /path/to/mysite.com/mysite/wsgi.py
+WSGIPythonPath /path/to/mysite.com
+
+<Directory /path/to/mysite.com/mysite>
+<Files wsgi.py>
+Require all granted
+</Files>
+</Directory>
+```
+
+To set environment variables which would be inherited by the Django application referred to by this, one can set them in the 'envvars' file created as part of the Apache installation. There are a few problems with that though.
+
+The first is that Linux distributions created a completely different way of configuring Apache and ignored in large part how the Apache Software Foundations default Apache distribution works. How you would do the equivalent varies between Linux distributions but generally requires setting some over special file in the system init scripts.
+
+The second is that the ``envvars`` file applies to the whole of Apache and cannot be made to apply to specific mod_wsgi daemon processes. This makes it unsuitable where hosting multiple Python web applications under the same Apache.
+
+The much simpler way is to create a separate WSGI script file independent of the ``wsgi.py`` that Django generates with its ``startproject`` template. You might call this ``django.wsgi``, or you might have separate ``production.wsgi`` and ``development.wsgi`` files if have multiple environments. Place the WSGI script file in the same directory as the ``wsgi.py`` file. In the file add something like:
+
+```
+import os
+
+os.environ['DJANGO_SETTINGS_MODULE'] = 'mysite.settings'
+
+os.environ['DJANGO_CONFIGURATION'] = 'Production'
+os.environ['DJANGO_SECRET_KEY'] = 'RANDOM_SECRET_KEY_HERE'
+os.environ['DJANGO_AWS_ACCESS_KEY_ID'] = 'YOUR_AWS_ID_HERE'
+os.environ['DJANGO_AWS_SECRET_ACCESS_KEY'] = 'YOUR_AWS_SECRET_ACCESS_KEY_HERE'
+os.environ['DJANGO_AWS_STORAGE_BUCKET_NAME'] = 'YOUR_AWS_S3_BUCKET_NAME_HERE'
+os.environ['SENDGRID_USERNAME'] = 'YOUR_SENDGRID_USERNAME'
+os.environ['SENDGRID_PASSWORD'] = 'YOUR_SENDGRID_PASSWORD'
+
+from django.core.wsgi import get_wsgi_application
+application = get_wsgi_application()
+```
+
+With that in place, change the name of the WSGI script file in the Apache configuration snippet.
+
+```
+WSGIScriptAlias / /path/to/mysite.com/mysite/production.wsgi
+WSGIPythonPath /path/to/mysite.com
+
+<Directory /path/to/mysite.com/mysite>
+<Files production.wsgi>
+Require all granted
+</Files>
+</Directory>
+```
+
+This method can be used for any environment variables with the exception of those which affect the operation of the processes as a whole at a system level. That is, you cannot set ``LANG`` and ``LC_ALL`` in this way. Modern versions of mod_wsgi though have ``lang`` and ``locale`` options on ``WSGIDaemonProcess`` directive which achieve the same result. If not using daemon mode, you should be as embedded mode isn't generally recommended.
+
+The only other problematic environment variable is ``LD_LIBRARY_PATH``. This is only a problem where shared libraries aren't installed in a proper system location. If this is unavoidable, set ``LD_RUN_PATH`` when installing and Python modules using the library and the location will be embedded in the Python module extension so that the shared library will be found whether or not ``LD_LIBRARY_PATH`` is set properly.
+
+In summary, ignore the Django generated ``wsgi.py`` file. This never used to exist and that it started to be generated has caused problems with mod_wsgi ever since. This is because it used ``os.environ.setdefault()`` that causes problems when running multiple Django applications in the same Apache process. Secondly, that ``wsgi.py`` was auto generated, it gave people the impression that it would always be correct and wouldn't need modifying. Consequence was that people stopped seeing what one of the main roles of the WSGi script file was for, which was to set environment variables before the Django application got loaded.
No results found