Is this mod_userdir config enought to configure mod_wsgi (Django)

[bsergean]

Hi,

I have an account on a friend machine where mod_wsgi/1.3 is installed.
I can put html under my ~user/public_html folder. The main apache
config load this mod_userdir conf file.

<IfModule mod_userdir.c>
UserDir public_html
UserDir disabled root

<Directory /home/*/public_html>
AllowOverride FileInfo AuthConfig Limit
Options MultiViews Indexes SymLinksIfOwnerMatch
ExecCGI IncludesNoExec
</Directory>
</IfModule>

Is it gonna give me enought "permission" to run my django site with
mod_wsgi on this machine ?
I was thinking about putting the mod_wsgi code in a .htaccess file.

If I read this post it seems like I need a AllowOverride All to do
that, but I don't really know.
http://www.webhostingtalk.com/showthread.php?t=52930

Does anyone know do I need to deploy a Django site on such machine, or
is it impossible ?

Thanks for any help,
- Benjamin

[gert]

On Mar 11, 6:46 pm, bsergean <bserg...@gmail.com> wrote:
> Hi,
>
> I have an account on a friend machine where mod_wsgi/1.3 is installed.
> I can put html under my ~user/public_html folder. The main apache
> config load this mod_userdir conf file.
>
> <IfModule mod_userdir.c>
>         UserDir public_html
>         UserDir disabled root
>
>         <Directory /home/*/public_html>
>                 AllowOverride FileInfo AuthConfig Limit
>                 Options MultiViews Indexes SymLinksIfOwnerMatch
> ExecCGI IncludesNoExec
>         </Directory>
> </IfModule>
>
> Is it gonna give me enought "permission" to run my django site with
> mod_wsgi on this machine ?
> I was thinking about putting the mod_wsgi code in a .htaccess file.
>
> If I read this post it seems like I need a AllowOverride All to do

> that, but I don't really know.http://www.webhostingtalk.com/showthread.php?t=52930

>
> Does anyone know do I need to deploy a Django site on such machine, or
> is it impossible ?
>
> Thanks for any help,
> - Benjamin

Until Graham is awake with is usually in a few hours just try it :)
http://code.google.com/p/modwsgi/wiki/IntegrationWithDjango

[Graham Dumpleton]

2009/3/12 bsergean <bser...@gmail.com>:

>
> Hi,
>
> I have an account on a friend machine where mod_wsgi/1.3 is installed.

It would be nicer if they were using mod_wsgi 2.3 instead as then you
get access to some nice features related to virtual environments as
well as other stuff.

These Debian folks who hold on to old packages and don't upgrade. :-(

Anyway, will describe the minimum that would be required.

> I can put html under my ~user/public_html folder. The main apache
> config load this mod_userdir conf file.
>
> <IfModule mod_userdir.c>
>        UserDir public_html
>        UserDir disabled root
>
>        <Directory /home/*/public_html>
>                AllowOverride FileInfo AuthConfig Limit
>                Options MultiViews Indexes SymLinksIfOwnerMatch
> ExecCGI IncludesNoExec
>        </Directory>
> </IfModule>
>
> Is it gonna give me enought "permission" to run my django site with
> mod_wsgi on this machine ?
> I was thinking about putting the mod_wsgi code in a .htaccess file.

Yes, but this would mean that things run in embedded mode and you
probably don't want that. It would be much better to have a daemon
process(es) setup just for your use.

> If I read this post it seems like I need a AllowOverride All to do
> that, but I don't really know.
> http://www.webhostingtalk.com/showthread.php?t=52930

No, FileInfo and ExecCGI is enough to get you going.

> Does anyone know do I need to deploy a Django site on such machine, or
> is it impossible ?

It is covered in the documentation:

http://code.google.com/p/modwsgi/wiki/ConfigurationGuidelines#The_Apache_Alias_Directive

Look for the bit that talks about .htaccess file.

That said, this is what I suggest you do. Following presumes that your
user account is call 'bsergean'.

First off, have them add in the VirtualHost the lines:

WSGIDaemonProcess bsergean user=bsergean group=bsergean

This will result in a specific daemon process being created that will
run as you, rather than the Apache user. We then make your WSGI
applications run in that daemon process instead.

They should then create inside VirtualHost:

<Directory /home/bsergean/public_html>

# Ensure that your WSGI applications run in your daemon process.
WSGIProcessGroup bsergean

# Enable process reloading mechanism so can just touch WSGI script
file to reload.
# This is only need because you are still using mod_wsgi 1.3, is the
default in 2.X.
WSGIReloadMechanism Process

</Directory>

The instructions for using .htaccess file would then be used:

AddHandler wsgi-script .wsgi

Since you are already getting them to change main Apache configuration
anyway, just as easy to stick that in there instead of .htaccess.
Thus, add it to Directory directive above.

<Directory /home/bsergean/public_html>

# Ensure that your WSGI applications run in your daemon process.
WSGIProcessGroup bsergean

# Mark .wsgi files as WSGI applications.
AddHandler wsgi-script .wsgi

</Directory>

Presuming you called your WSGI script file 'django.wsgi' at had it in
the 'public_html' directory, you would then access it as:

http://host/~bsergeab/django.wsgi/

The only other thing is that if you want Django site to reside at:

http://host/~bsergean/

then you will also want to use the RewriteRule and WSGI wrapper as
described in documentation I linked to. Just note the example mentions
'site.wsgi' so change as appropriate.

Just to clarify, the use of a daemon process group is optional, but if
I was the person allowing you use the machine, I would not let you use
it unless a daemon process was used. A daemon process is used
specifically to stop your Django application bloating out the main
Apache child server processes. The dangers of that I have recently
blogged about at:

http://blog.dscpl.com.au/2009/03/load-spikes-and-excessive-memory-usage.html

The daemon process must also be used to allow you a way of restarting
your application without having the ability to restart the whole of
Apache. For more information see:

http://code.google.com/p/modwsgi/wiki/ReloadingSourceCode

You obviously can't restart the whole of Apache, but provided
configured correctly, you can force a reload of your application by
just touching the WSGI script file.

Graham

[Graham Dumpleton]

BTW, if they are on older Debian system with mod_wsgi 1.3, likely that
they may still be using Python 2.4. If they are, this may cause grief
if they are also loading mod_php into Apache.

Take a note of where PHP is mentioned in:

http://code.google.com/p/modwsgi/wiki/ApplicationIssues

Also take note of expat library issue which can also affect Python 2.4.

Graham

2009/3/12 Graham Dumpleton <graham.d...@gmail.com>:

[Benjamin Sergeant]

Thanks so much Graham for all those precious infos. The open-source world is blessed to have such dedicated and competent people like you.

- Benjamin

ps:
Python-2.5.2 is used on this machine, and there is a mediawiki running. So I don't know if the mod_php problem will happen.

[Graham Dumpleton]

2009/3/12 Benjamin Sergeant <bser...@gmail.com>:

> Thanks so much Graham for all those precious infos. The open-source world is
> blessed to have such dedicated and competent people like you.

Although there is always a potential to have shared library symbol
name conflicts, Python 2.5 shouldn't be affected by the primary ones
as Python 2.4 can.

BTW, once you get something setup, the first WSGI wrapper application in:

http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Tracking_Request_and_Response

can be used to dump out WSGI environment as request is received. If
you look at the request half and see that 'wsgi.process_group' is
'bsergean' you know that your code is correctly running in daemon
mode.

Graham

[Graham Dumpleton]

2009/3/12 Graham Dumpleton <graham.d...@gmail.com>:

> 2009/3/12 Benjamin Sergeant <bser...@gmail.com>:
>> Thanks so much Graham for all those precious infos. The open-source world is
>> blessed to have such dedicated and competent people like you.
>
> Although there is always a potential to have shared library symbol
> name conflicts, Python 2.5 shouldn't be affected by the primary ones
> as Python 2.4 can.
>
> BTW, once you get something setup, the first WSGI wrapper application in:
>
>  http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Tracking_Request_and_Response
>
> can be used to dump out WSGI environment as request is received. If
> you look at the request half and see that 'wsgi.process_group' is
> 'bsergean' you know that your code is correctly running in daemon
> mode.

Whoops, hat should have been 'mod_wsgi.process_group'.

[Damjan]

> >        <Directory /home/*/public_html>
> >                AllowOverride FileInfo AuthConfig Limit
> >                Options MultiViews Indexes SymLinksIfOwnerMatch
> > ExecCGI IncludesNoExec

...

> First off, have them add in the VirtualHost the lines:
>
>    WSGIDaemonProcess bsergean user=bsergean group=bsergean
>
> This will result in a specific daemon process being created that will
> run as you, rather than the Apache user. We then make your WSGI
> applications run in that daemon process instead.
>
> They should then create inside VirtualHost:
>
>   <Directory /home/bsergean/public_html>
>
>   # Ensure that your WSGI applications run in your daemon process.
>   WSGIProcessGroup bsergean

Note that his friend has a generic directive for all the users on the
system:
<Directory /home/*/public_html>

Now, in WSGIProcessGroup you could use A %{ENV:...} variable, which
means with some additional Apache trickery you could make that generic
- right?

The only thing left to be statically configured, will be the
"WSGIDaemonProcess ..." directive.

(can this be somehow made dynamic?)

[Graham Dumpleton]

2009/3/17 Damjan <gda...@gmail.com>:

As you seem to have already found, that is in part what:

http://code.google.com/p/modwsgi/issues/detail?id=22

is about.

Graham

[Damjan]

> > The only thing left to be statically configured, will be the
> > "WSGIDaemonProcess ..." directive.
>
> > (can this be somehow made dynamic?)
>
> As you seem to have already found, that is in part what:
>
>  http://code.google.com/p/modwsgi/issues/detail?id=22
>
> is about.

Right, and then I was thinking what's the better forum for discussing
the feature :)

[Graham Dumpleton]

2009/3/17 Damjan <gda...@gmail.com>:

Here is.

Just hold off a bit on a discussion as possible that will end up
having a general discussion on where mod_wsgi goes from here. This may
include on demand daemon processes, but also whether mod_wsgi should
provide a way of supporting multiple installations/versions of Python
at the same time.

Graham

[gert]

On Mar 17, 12:06 am, Graham Dumpleton <graham.dumple...@gmail.com>
wrote:
> 2009/3/17 Damjan <gdam...@gmail.com>:

Multiple version should be lowest priority, because for me it
translates into, lazy administrators or developers that want to get
rich by doing as little work as possible not updating there code and
blame it on stability or security. When multiple version is supported
they will get away with it. In my world everybody should be using
trunk, nobody is going to die if it sometimes crashes.

[Graham Dumpleton]

2009/3/17 gert <gert.c...@gmail.com>:

Reality is though that web hosters, if mod_wsgi is stuck with one
version of Python, will never update it and so over time people using
that service will be stuck with an ancient version of Python. This
already happens, with some web hosters still on Python 2.3 or Python
2.4. If one can make it an easy process to support old and new it is
better. Otherwise they stay at the old, or just use fastcgi instead.

Graham

[gert]

On Mar 17, 12:23 am, Graham Dumpleton <graham.dumple...@gmail.com>
wrote:
> 2009/3/17 gert <gert.cuyk...@gmail.com>:

My suggestion would be, if possible make it python independable so
servers do not have any python installed at all and the user just drop
a compiled python image in the user public place so modwsgi can load a
custom daemon out of the python image ? Some sort of public shared
python libs where modwsgi takes care of the ldconfig suff :-)