Not sure how or why the message got deleted, I don't recall doing that, but
I do appreciate you responding to it. We don't run very many python apps,
just a few one-offs, so I suppose just manually creating a different daemon
process for each app won't be too much management overhead. My main
concern is that I'm the primary, and really only guy on the team that can
handle/manage Linux servers, so I was attempting to make it the easiest for
the rest of the team should they ever need to do anything on the server or
add new apps without my intervention.
Thanks again!
On Monday, October 10, 2016 at 4:39:03 PM UTC-7, Graham Dumpleton wrote:
>
> 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
>
> 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.
