[mod_python] mod_python import failure on FreeBSD AMD64

Graham Dumpleton graham.dumpleton at gmail.com
Wed May 5 01:51:51 EDT 2010


On 5 May 2010 14:55, Surly The Clown <surly_the_clown at hotmail.com> wrote:
>
>
>> Date: Wed, 5 May 2010 13:17:07 +1000
>> Subject: Re: [mod_python] mod_python import failure on FreeBSD AMD64
>> From: graham.dumpleton at gmail.com
>> To: surly_the_clown at hotmail.com
>> CC: mod_python at modpython.org
>>
>> On 5 May 2010 13:13, Surly The Clown <surly_the_clown at hotmail.com> wrote:
>> >> > Any more ideas?
>> >>
>> >> Don't use mod_python if you don't have to.
>> >>
>> >> What are you wanting to host using it?
>> >
>> >
>> > Big(ish) media files, and I'm wanting to hook into Apache so that I can
>> > control access to them with custom logic. As far as I've been able to
>> > determine, this is something that wsgi/fastcgi can't really do, unless
>> > you
>> > use URL rewriting to force the requests to go through a script. Even
>> > then,
>> > it's suboptimal as the file would then be piped through a script instead
>> > of
>> > handled directly by Apache. mod_python was pretty much exactly what I
>> > need.
>>
>>
>> Depends exactly on what you want to do. See:
>>
>> http://code.google.com/p/modwsgi/wiki/AccessControlMechanisms
>>
>> Graham
>
>
>
> Interesting. Unfortunately, those access control mechanisms all seem to be
> based on http access control, which is inadequate for my needs.
> Specifically, what I need is the ability to enforce one login per user. You
> can't do this with http access control because it allows or denies access
> based solely on what the client sends the server, and does not have any way
> of denying access if, say, that username was logged in somewhere else, or if
> that is the case, logging out the other user session in favor of the new
> one. I spent quite some time looking for modules for both apache and nginx
> before I came to the conclusion that there were none, which I find
> astonishing. It's of course possible that I've missed something. However,
> mod_python will allow me to do what I need, and this scheme of access
> control does work.

I warn you that using mod_python to do that will be a PITA.

You don't even need to hook into the early phases of Apache request
processing to do what you want. You would be better off writing a
standard WSGI application which incorporates the form/session based
login mechanism to handle access and then use X-Sendfile response
header and mod_sendfile to then serve up the static file.

This gives you a number of benefits. The most important is that you
have a portable solution as it could be hosted on mod_wsgi or
mod_fcgid/flup on Apache with mod_xsendfile in Apache serving up the
file based on X-Sendfile. You could also use nginx/fastcgi/flup and
equivalent X-Sendile support in nginx using its mod_xsendfile.

Another way besides using X-Sendfile is to use nginx X-Accel-Redirect
header with private URL namespace. This can be used in front of
nginx/fastcgi/flup or where nginx is front end to Apache/mod_wsgi.

Thus, you have multiple widely used and well tested existing means of
serving up static files via the web server, where the file is
controlled by a web application implementing the access control.

Another benefit is that you don't have to implement from scratch the
form/session login mechanism as you can reuse an existing WSGI
component which performs that task already. Options for that are
Beaker (http://beaker.groovie.org/) and repoze.who
(http://docs.repoze.org/who/2.0/).

If you still don't want to go that path and want an Apache only
solution, suggest you look at mod_auth_tkt
(http://www.openfusion.com.au/labs/mod_auth_tkt/).

There is also mod_session in Apache, but that is only available from
Apache 2.3 onwards.

> Now, I can see why you'd prefer to use wsgi or fastcgi if they are adequate
> for your needs, but mod_python can do some things that those just can't, and
> they are useful things, so I'm surprised that it's been abandoned.

Few people need those additional features.

> At any rate, I now have an additional machine where mod_python works: an
> i386 FreeBSD instance running in QEMU. And I also discovered that running
> make extract in mod_python's directory yields the error:
> "/usr/local/sbin/apxs: not found" and "===> mod_python-3.3.1_2 : Your apache
> does not support DSO modules." Bizarre.

Not really. FreeBSD is a very backward system when it comes to Apache
and you may find it only ships with Apache 1.3. Even when you can get
Apache 2.X for FreeBSD, it often has all multithreading support
disabled completely in APR libraries.

> Searching the inter-net for the
> latter message makes me think that something is messed up with apache.
> However, /usr/local/sbin/apxs is on the system, is executable, and runs.
> Deinstalling apache and then attempting to rebuild it yields:
>
>
> ./buildconf: /usr/local/bin/autoheader-2.62: not found
>
>
> which is once again actually on the system and working fine. This leads me
> to believe that something is seriously messed up with that system and that
> is likely why mod_python isn't working. Thank you for your assistance,
> though.


Graham


More information about the Mod_python mailing list