This message was posted on the mod_wsgi list, but the poster seemed to have
deleted it before they could even be moderated into the list. Though it was
worthwhile responding anyway.
> I was attempting to setup a mass-virtual hosting type of situation on my
> server for a few django apps that my company has by using the undocumented
> %{HOST} WSGIApplicationGroup option.
First added in 4.4.0.
* http://modwsgi.readthedocs.io/en/develop/release-notes/version-4.4.0.html
<http://modwsgi.readthedocs.io/en/develop/release-notes/version-4.4.0.html>
Not something I would generally recommend using though.
At the same time a %{HOST} value was also allowed with WSGIDaemonProcess.
Although in that case you still had to manually provision the daemon process
groups to match.
> Using info level debugging in Apache, I can see it creating, what I think,
> are two sub-interpreters. But it seems that the environment variables from
> the first application are still showing up in the second app, which is
> causing some issues with the python dotenv library.
>
> I've read a few threads from a few years ago where it was stated that in
> order to run multiple apps successfully, multiple processes must be used,
> especially with Django apps because of the settings module. But based on the
> example in the WSGIApplicationGroup docs about putting user apps into their
> own application group just for that user, I figured the same could be done by
> using the HOST variable. Am I mis-understanding how the WSGIApplicationGroup
> directive works when it comes to running multiple python apps? I also
> confirmed that the proper settings module is being loaded for each app the
> way I have it setup now.
WSGIApplicationGroup relates to a sub interpreter context of a process. So it
isn’t creating a new process. If for the one process you direct multiple WSGI
applications to run in different application groups based on host name, then
they are all still running in the same process. Even when using a daemon
process group with multiple processes, this still occurs, you just have it
occurring in all processes at the same time.
Although sub interpreters can be useful, the separation between them isn’t
perfect. One issue as you found is environment variables. This is made worse by
fact that Django by default sets the environment variable for
DJANGO_SETTINGS_MODULE in wsgi.py in a way that will cause leakage of the
environment variable across sub interpreters. Other scenarios also arise where
they can leak.
In short, do not use application groups to try and implement mass virtual
hosting where user could run any application they want. It will cause all sorts
of problems, including security problems as different users code would run in
the same process, so technically they could write an extension module that
allows them to steal data from other users applications.
The best practice recommendation is to use separate daemon process groups for
each WSGI application, with the WSGI application being forced into the main
interpreter context using %{GLOBAL} for WSGIApplicationGroup or
application-group option to WSGIScriptAlias. The latter is to get around
problems with third party Python extension modules that do not work properly in
sub interpreters.
Graham
--
You received this message because you are subscribed to the Google Groups
"modwsgi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/modwsgi.
For more options, visit https://groups.google.com/d/optout.
