WSGI User Directories
Todd Wilson
I would like to do something similar to Apache's UserDir to allow my
users to host WSGI applications from their home directories. The
machine has several hostnames pointing to the same IP, so I can pick one
of these hostnames (call it "myhostname") and use a VirtualHost block
with ServerName set to this hostname for this purpose. I'd like to
allow each user (call him/her "user") to have a wsgi directory in their
home directory that looks like this:
/home/user/wsgi/
wsgi-files/
proj1.wsgi
proj2.wsgi
....
proj1/
proj2/
....
and be able to access these projects using
http://myhostname/user/proj1/...
http://myhostname/user/proj2/...
etc. Is this possible? What if I wanted to use daemon processes --
what kind of configuration could be used for that?
Todd Wilson
Graham Dumpleton
How many users? The problem in this is the need to manually provision
new daemon process groups for each user and restart Apache.
Anyway, you can still use mod_userdir so that they are accessed as:
You also don't need to create a special wsgi-files directory.
Suggest instead the following:
# Make sure that embedded mode is turned off and not risk of any
# users code running in main Apache child processes. Thus, must
# always be configured to delegate to daemon process group.
WSGIRestrictEmbedded On
# Allow static files and .wsgi scripts in users standard public_html
# directory. Need to have ExecCGI so that can use .wsgi files with
# AddHandler directive.
UserDir public_html
<Directory /home/*/public_html>
Order allow,deny
Allow from all
AddHandler wsgi-script .wsgi
Options ExecCGI
AllowOverride None
</Directory>
Then for each user you need to do:
WSGIDaemonProcess user-1
<Directory /home/user-1/public_html>
WSGIProcessGroup user-1 user=user-1
</Directory>
With this they will get one daemon process group only. Each WSGI
application will run in a separate sub interpreter of that process.
The daemon process will run as that user because of 'user' option.
Note that Apache user must still have read access down to public_html
directory. If home directory permissions are restrictive and prevent
that, the put their public_html directories somewhere outside of the
home accounts.
If they really needed a separate daemon process group per application
then is a bit more setup along the lines of:
WSGIDaemonProcess user-1/default user=user-1
WSGIDaemonProcess user-1:/project-1 user=user-1
<Directory /home/user-1/public_html>
WSGIProcessGroup user-1/default
<Files proj1.wsgi>
WSGIProcessGroup user-1/project-1
</Files>
</Directory>
They should then add .wsgi file into public directory. If this is for
something like Django or other big framework, the actual project site
directory should not be under the public_html directory but elsewhere
in the home account.
The URL would then be:
http://myhostname/~user/proj1.wsgi
That is, .wsgi extension appears in the URL. Depending on how clean
you want to be, then that can be avoided but requires fiddling with
rewrite rules.
Static files can also be put under public_html and will be able to be
access as well.
That should get you started. There is a lot of flexibility in how you
can do things and this isn't the only way. Thus you really need it to
be done a bit differently, there is no doubt a way, but this is the
simplest way to start with.
Graham
Todd Wilson
Thank you very much for that detailed reply. Responses and further
information below.
My idea was doing this for all users, which might be up to 30 or so, but
it sounds like there is a definite overhead for each user. Many of
these users would not be using WSGI, but I was hoping to make it
available without further effort in case they wanted to use it.
> Anyway, you can still use mod_userdir so that they are accessed as:
>
> http://myhostname/~user/
>
> You also don't need to create a special wsgi-files directory.
>
> Suggest instead the following:
>
> # Make sure that embedded mode is turned off and not risk of any
> # users code running in main Apache child processes. Thus, must
> # always be configured to delegate to daemon process group.
>
> WSGIRestrictEmbedded On
>
> # Allow static files and .wsgi scripts in users standard public_html
> # directory. Need to have ExecCGI so that can use .wsgi files with
> # AddHandler directive.
>
> UserDir public_html
>
> <Directory /home/*/public_html>
> Order allow,deny
> Allow from all
>
> AddHandler wsgi-script .wsgi
> Options ExecCGI
> AllowOverride None
> </Directory>
I'm using public_html to serve user directories under a different
virtual host, so that URLs of the form
map to this directory. That's why I thought a second subdirectory,
/home/user/wsgi/
for use by the myhostname virtual host would be appropriate.
> Then for each user you need to do:
>
> WSGIDaemonProcess user-1
>
> <Directory /home/user-1/public_html>
> WSGIProcessGroup user-1 user=user-1
> </Directory>
>
> With this they will get one daemon process group only. Each WSGI
> application will run in a separate sub interpreter of that process.
I interpret this to mean that these processes would always be running,
waiting for requests, which would be a real waste of resources for those
users who never create WSGI applications. I was hoping that there'd be
a way of using patterns (as with the WSGIScriptAliasMatch examples) here
to cover a dynamic list of users (which would change each semester)
> The daemon process will run as that user because of 'user' option.
> Note that Apache user must still have read access down to public_html
> directory. If home directory permissions are restrictive and prevent
> that, the put their public_html directories somewhere outside of the
> home accounts.
That's been set up already for the myotherhostname virtual server UserDir.
> If they really needed a separate daemon process group per application
> then is a bit more setup along the lines of:
>
> WSGIDaemonProcess user-1/default user=user-1
> WSGIDaemonProcess user-1:/project-1 user=user-1
>
> <Directory /home/user-1/public_html>
> WSGIProcessGroup user-1/default
> <Files proj1.wsgi>
> WSGIProcessGroup user-1/project-1
> </Files>
> </Directory>
>
> They should then add .wsgi file into public directory. If this is for
> something like Django or other big framework, the actual project site
> directory should not be under the public_html directory but elsewhere
> in the home account.
>
> The URL would then be:
>
> http://myhostname/~user/proj1.wsgi
>
> That is, .wsgi extension appears in the URL. Depending on how clean
> you want to be, then that can be avoided but requires fiddling with
> rewrite rules.
OK, I've seen the examples there, so I think I can tweak that if necessary.
> Static files can also be put under public_html and will be able to be
> access as well.
>
> That should get you started. There is a lot of flexibility in how you
> can do things and this isn't the only way. Thus you really need it to
> be done a bit differently, there is no doubt a way, but this is the
> simplest way to start with.
Thanks again. For these student accounts, performance is not critical,
but uniformity is. However, if a student creates a project that
outlasts a particular semester, or for some reason needs extra
performance, I wouldn't mind moving it to a different place and serving
it more efficiently.
Todd Wilson
Graham Dumpleton
Unfortunately no, there is no means for dynamic creation of daemon
process groups, only static definition. Adding dynamic creation has
been on the todo list for quite a while but requires a bit of
rearchitecting of mod_wsgi code and haven't had much time over the
last two years. This year should be much better, but still go to
prioritise things as far as whether it is worthwhile to do or not.
Overall, Apache as a platform for mod_wsgi and the way it works,
doesn't make this sort of dynamic creation straight forward and
possibly better to start over from scratch and write a new WSGI
hosting mechanism which is in part not dependent on Apache. Again,
haven't pursued that due to lack of time but this year may finally get
around to it.
Graham
> --
> You received this message because you are subscribed to the Google Groups "modwsgi" group.
> To post to this group, send email to mod...@googlegroups.com.
> To unsubscribe from this group, send email to modwsgi+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
>
>
Michael Semcheski
> Thanks again. For these student accounts, performance is not critical,
> but uniformity is. However, if a student creates a project that
> outlasts a particular semester, or for some reason needs extra
> performance, I wouldn't mind moving it to a different place and serving
> it more efficiently.
I would look at using Puppet (or another programatic solution) to
provision the WSGI configuration components.
You could require that students request the WSGI service before using
it, and then if they request it, deploy the necessary files and
refresh httpd.
Most of the stuff that needs to be deployed per user instance should
be pretty self contained, and having a script or configuration
management system provision that stuff will ensure that things are
done uniformly. Puppet can be used to manage an entire system, but
you can also use a very scaled back configuration to manage just
httpd, or even just the mod_wsgi files that each user requires.