CGI Python problem

[timotoole@gmail.com]

Hi all,

I'm trying to get python to work with cgi for a small intranet site,
however even a simply "hello world test isn't working". Here is the
test file:

#!/usr/bin/python
# -*- coding: UTF-8 -*-

# enable debugging
import cgitb; cgitb.enable()

print "Content-Type: text/plain;charset=u tf-8"
print

print "Hello World!"

I've placed this file in both public_html and as a test in public_html/
cgi-bin directories in my local user account (I dont have root access
- its a corparate network). The file definitely has read and execute
permission (744) as have the assoicated directories. However when I
navigate to the file with my browser I get a 500 page?! The code was
written fully in linux, so its not some odd windows/linux line
termination issue.

As a test I tried a perl cgi hello world test, and this worked
correctly. The apache server appears to be locked down tightly, as
allowOverwrite is None, so I can't do anything in .htaccess files.

Any thoughts on how I might debug this or where the problem is

[Tim Chase]

Re: CGI Python problem

I've placed this file in both public_html and as a test in public_html/

cgi-bin directories in my local user account (I dont have root access
- its a corparate network). The file definitely has read and execute
permission (744) as have the assoicated directories.

My guess would be the permissions are awry -- if I parse that
correctly, 744 is -rwxr--r-- which means that other users (such
as the user your server runs as, likely "www" or "wwwdata"?)
can't execute the shell-script. As a first pass, I'd ensure that
the file has permissions, and the directory can be scanned by the
webserver ("eXecute" permissions on the containing directory):

bash$ cd ~/public_html/cgi-bin
bash$ chmod go+rx test.py .

As a test I tried a perl cgi hello world test, and this worked
correctly.

If the perl script is working correctly, I suspect the directory
permissions are set correctly, so I'd compare permission of the
..pl vs. the .py scripts to see if they're the same.
Alternatively, if your server is running mod_perl, it might be
short circuiting the CGI aspect, detecting the .pl file & running
it, and thus might be a red herring. (not using perl/mod_perl, I
don't know the ins and outs of this, so I could be waaaaay off
base on this line of thinking)

Just my first-pass debugging thoughts,

-tkc

[Tim O'Toole]

Re: CGI Python problem

Thanks for replying Tim,

Here is the permissions, which I think are definitely right now:

drwxrwxrwx 8 **** **** 4.0K Nov 6 13:34 public_html/

drwxrwxrwx 2 **** **** 4.0K Nov 6 13:35 cgi-bin/ [inside public_html]

-rw-r-xr-x 1 **** **** 117 Nov 6 11:39 test_pl.cgi* [inside cgi-bin]
-rw-r-xr-x 1 **** **** 168 Nov 6 13:35 test_py.cgi* [inside cgi-bin]

note both have *.cgi extensions otherwise plain text is shown.


the perl file correctly outputs hello world whereas the python file
gives a 500 internal server error warning.

Also I think I should be getting a traceback since I used import
cgitb; cgitb.enable() I wonder does this suggest the python
interpreter hasn't be found?


Also I'm not sure how to check if the server is running mod_perl?


Thanks for the help, much appreciated

>
My guess would be the permissions are awry -- if I parse that correctly, 744
is -rwxr--r-- which means that other users (such as the user your server
runs as, likely "www" or "wwwdata"?) can't execute the shell-script. As a
first pass, I'd ensure that the file has permissions, and the directory can
be scanned by the webserver ("eXecute" permissions on the containing
directory):
>
bash$ cd ~/public_html/cgi-bin
bash$ chmod go+rx test.py .
>

>As a test I tried a perl cgi hello world test, and this worked
>correctly.

>
If the perl script is working correctly, I suspect the directory permissions
are set correctly, so I'd compare permission of the .pl vs. the .py scripts
to see if they're the same. Alternatively, if your server is running
mod_perl, it might be short circuiting the CGI aspect, detecting the .pl
file & running it, and thus might be a red herring. (not using
perl/mod_perl, I don't know the ins and outs of this, so I could be waaaaay
off base on this line of thinking)
>
Just my first-pass debugging thoughts,
>
-tkc
>
>
>
>
>
>
>
>
>

[Tim Chase]

Re: CGI Python problem

Here is the permissions, which I think are definitely right now:

>
drwxrwxrwx 8 **** **** 4.0K Nov 6 13:34 public_html/
>
drwxrwxrwx 2 **** **** 4.0K Nov 6 13:35 cgi-bin/ [inside public_html]
>
-rw-r-xr-x 1 **** **** 117 Nov 6 11:39 test_pl.cgi* [inside cgi-bin]
-rw-r-xr-x 1 **** **** 168 Nov 6 13:35 test_py.cgi* [inside cgi-bin]

Those indeed look kosher

note both have *.cgi extensions otherwise plain text is shown.

I prefer to use .py (or .pl) for the extensions so my editors
pick up the syntax...In my server's CGI directory, as long as the
+x bits are set, it runs them with the .py extension. However,
that's an aesthetic matter.

Also I think I should be getting a traceback since I used import
cgitb; cgitb.enable() I wonder does this suggest the python
interpreter hasn't be found?

It's certainly something to check...Apache may run in a chroot'ed
environment where Perl may be available, and Python may not (or
it may be someplace else in the chroot environment).

If you've got Perl hacking skills, you might throw together a
simple perl-script that checks to see if /usr/bin/python exists
where you think it is, or walks the directory tree returning the
path of files containing the word "python". My perl skills are
close to non-existent (only having reverse-engineered some
hand-me-down perl code)

Also I'm not sure how to check if the server is running mod_perl?

I think that's usually (assuming your admin hasn't munged them)
included in the headers returned from the server, or if you've
got PHP installed in the same setup, you can create a simple PHP
page to dump the info (with this one line in it):

<?php phpinfo();?>

which should include a line for the modules loaded in Apache.

Hope this gives you a few more things to check,

-tkc

[Tim O'Toole]

Re: CGI Python problem

With regard to phpinfo(), its shows the mod_cgi is loaded, but neither
mod_perl or mod_python is loaded (I read on the python.org site that
mod_python can interfere with running python through mod_python).

As for writing some perl, not too sure how to do that, but from the
information in phpinfo I logged onto the webserver machine and did a
"whereis python" - it came back blank! Of course doing a whereis perl
gave a non-blank answer. So this seems to be the route cause of my
trouble.

Now to work around that, I've tried to change the shebang in the
python test file to the location of python on my local machine, but
still no use?

any thoughts?

>Also I think I should be getting a traceback since I used import
>cgitb; cgitb.enable() I wonder does this suggest the python
>interpreter hasn't be found?

>
It's certainly something to check...Apache may run in a chroot'ed
environment where Perl may be available, and Python may not (or it may be
someplace else in the chroot environment).
>
If you've got Perl hacking skills, you might throw together a simple
perl-script that checks to see if /usr/bin/python exists where you think it
is, or walks the directory tree returning the path of files containing the
word "python". My perl skills are close to non-existent (only having
reverse-engineered some hand-me-down perl code)
>

>Also I'm not sure how to check if the server is running mod_perl?

>
I think that's usually (assuming your admin hasn't munged them) included in
the headers returned from the server, or if you've got PHP installed in the
same setup, you can create a simple PHP page to dump the info (with this one
line in it):
>
<?php phpinfo();?>
>
which should include a line for the modules loaded in Apache.
>
Hope this gives you a few more things to check,
>
-tkc
>
>
>
>
>

[Tim Chase]

Re: CGI Python problem

As for writing some perl, not too sure how to do that, but from the

information in phpinfo I logged onto the webserver machine and did a
"whereis python" - it came back blank! Of course doing a whereis perl
gave a non-blank answer. So this seems to be the route cause of my
trouble.

Indeed! I made the rash assumption that it executed from the
command line (or as a lynxcgi from within Lynx). Not having
Python will make it awfully hard to run python apps.

While it's possible that Python is installed, but simply not
found by "whereis" (I don't know this tool), you could try

which python

if it's in your path, or the more brute-force search:

find /usr -name python

(ignore any permission-related responses) to see if it's
installed somewhere that's not on your path. If not, you may
have to either request that your admins install Python, or (if
you've at least got a compiler on the machine) build your own
deployment of Python in your user directory. Others on the list
may be able to direct you to good resources on building Python in
non-standard locations (I'm admin on all the boxes I use, or the
admins already have python2.4 or later installed).

Now to work around that, I've tried to change the shebang in the
python test file to the location of python on my local machine, but
still no use?

If your CGI is on machine A, and your local machine is machine B,
changing the shebang won't help, as you've noticed.

You might try creating a shell-script CGI to give you the info
you need:

#!/bin/sh
# saved as ~/public_html/cgi-bin/foo.cgi
echo Content-type:text/plain
echo
echo Python is found at:
which python
# find /usr -name python
echo Use the above as your shebang path.

and then

chmod ugo+x ~/public_html/cgi-bin/foo.cgi

You should then be able to browse to

http://yourserver.example.com/~totoole/cgi-bin/foo.cgi

to see if/where the python executable is stored for use in your
shebang line.

Yet another round in the game of troubleshooting ...

-tkc

[Tim O'Toole]

Re: CGI Python problem

Alas that cgi script confirmed python is not installed on the server
machine (which I had assumed it was).

Looks like game over with this avenue of trouble shooting?

On Fri, Nov 7, 2008 at 1:03 AM, Tim Chase <python.list@ti m.thechases.com wrote:

>As for writing some perl, not too sure how to do that, but from the
>information in phpinfo I logged onto the webserver machine and did a
>"whereis python" - it came back blank! Of course doing a whereis perl
>gave a non-blank answer. So this seems to be the route cause of my
>trouble.

>
Indeed! I made the rash assumption that it executed from the command line
(or as a lynxcgi from within Lynx). Not having Python will make it awfully
hard to run python apps.
>
While it's possible that Python is installed, but simply not found by
"whereis" (I don't know this tool), you could try
>
which python
>
if it's in your path, or the more brute-force search:
>
find /usr -name python
>
(ignore any permission-related responses) to see if it's installed somewhere
that's not on your path. If not, you may have to either request that your
admins install Python, or (if you've at least got a compiler on the machine)
build your own deployment of Python in your user directory. Others on the
list may be able to direct you to good resources on building Python in
non-standard locations (I'm admin on all the boxes I use, or the admins
already have python2.4 or later installed).
>

>Now to work around that, I've tried to change the shebang in the
>python test file to the location of python on my local machine, but
>still no use?

>
If your CGI is on machine A, and your local machine is machine B, changing
the shebang won't help, as you've noticed.
>
You might try creating a shell-script CGI to give you the info you need:
>
#!/bin/sh
# saved as ~/public_html/cgi-bin/foo.cgi
echo Content-type:text/plain
echo
echo Python is found at:
which python
# find /usr -name python
echo Use the above as your shebang path.
>
and then
>
chmod ugo+x ~/public_html/cgi-bin/foo.cgi
>
You should then be able to browse to
>

http://yourserver.example.com/~totoole/cgi-bin/foo.cgi

>
to see if/where the python executable is stored for use in your shebang
line.
>
Yet another round in the game of troubleshooting ...
>
-tkc
>
>
>
>
>
>
>

[Tim Chase]

Re: CGI Python problem

Tim O'Toole wrote:

Alas that cgi script confirmed python is not installed on the server
machine (which I had assumed it was).

Did you also try it with the "find" variant in addition to just
the "which" version? This would find Python if it wasn't on the
$PATH.

Looks like game over with this avenue of trouble shooting?

Well, if Python's not installed, the next step is _getting_ it
installed -- whether having your admin install it globally (I
mean, who *doesn't* install python?! ;-) or you install it
locally in your home directory as detailed at [1] where you
download the source and compile from scratch (assuming you have a
C compiler available).

If you can't get Python installed, then yes, it's game-over :)

-tkc


[1]

http://markmail.org/message/iezezfd7655xclyl

[Tim O'Toole]

Re: CGI Python problem

>

Well, if Python's not installed, the next step is _getting_ it installed --
whether having your admin install it globally (I mean, who *doesn't* install
python?! ;-) or you install it locally in your home directory as detailed
at [1] where you download the source and compile from scratch (assuming you
have a C compiler available).

Thanks for your help,

I'd have no problem compiling python on the webserver, but there isnt
user accounts on the webserver. The thing is though I dont need to
ssh/telnet/rlogin to get to another machine, it seems all the machines
hard disks are more of less mounted in a common hierarchy. So in
theory, thats why I thought altering the shebang would work. The
problem arises I think because the webserver is using SunOS whereas my
local machine is Linux, so python on my machine is non binary
compatiable with the server. I logged onto a couple of other Sun
Machines and it seems that python isnt installed in any of them (it is
installed on the linux machines). Time to chat to the administrator I
think.

Thanks ever so much for your help, it was much appreciated.

>
If you can't get Python installed, then yes, it's game-over :)
>
-tkc
>
>
[1]

http://markmail.org/message/iezezfd7655xclyl

>
>
>
>
>