[Tutor] Re: Help with 500 error on cgi script
Sheila King
sheila@thinkspot.net
Mon, 19 Mar 2001 09:44:13 -0800
49A3C40@kserver.org> <20010319110431.B22954@harmony.cs.rit.edu>
In-Reply-To: <20010319110431.B22954@harmony.cs.rit.edu>
X-Mailer: Forte Agent 1.8/32.548
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <5D9D382BD8@kserver.org>
On Mon, 19 Mar 2001 11:04:31 -0500, D-Man <dsh8290@rit.edu> wrote about Re:
[Tutor] Re: Help with 500 error on cgi script:
:On Sun, Mar 18, 2001 at 04:42:30PM -0800, Sheila King wrote:
:<snip>
:| No, our Apache server is using suexec and runs cgi scripts under our own
:| userID.
:
:Ok. I think that might help because you might be able to manipulate
:the environment the script is run in.
...<snipped>...
:when I use
:
:$ su username
:
:My previous environment remains (ie PATH, etc) but if I use
:
:$ su - username
:
:I get a new environment, the environment specified by that user's
:.bash_profile/.bashrc.
Either of these gives me the following error message:
while opening UTMP file: Permission denied
while opening UTMP file: Permission denied
...<snipped>...
:Can some other unix gurus mention a file that will always be executed
:to set up an environment for the cgi scripts to run in? I'm not
:familiar with how suexec behaves so it might not be a problem.
...<snipped>...
:I haven't worked on cgi scripts in a while and from Wesley Chun's
:message I think I forgot something here. I remember that printing
:"Content-type" tells the web server that it should add headers for
:you. I think that you have to supply the basic
:<HTML><BODY></BODY></HTML> tags yourself. Alternatively you can
:announce the type as "text/plain" and it will just spit the text out
:at the client with no formatting.
Not a problem. I am aware of all of the above issues.
...<snipped>...
:| Python 2.0 (#1, Jan 15 2001, 01:09:04)
:| [GCC 2.7.2.3] on linux2
: ^^^^^
:Heh, that's a bit old. I have heard (but not tried it for myself)
:that g++ 2.7.x had a problem with calling dtors before calling copy
:ctors when returning objects from functions. Just FYI in case you
:decide you want to play with C++ on that system. That C compiler
:should be ok since C is older and the compiler more mature.
Are you saying, that maybe I should uninstall my Python-2.0 and then
re-install it using the C compiler instead of GCC? You think that might help?
<sigh--sounds like a weekend project> I used gcc because that is what I'm
familiar with. I don't know how to use the c compilers.
...<snipped>...
:I think those "clear ..." lines are showing that the interpreter is
:removing stuff from memory before it quits. Since it is clearing
:sys.path, it must have found it. You could tweak PYTHONPATH in the
:script before you import cgi to get it to work. Ie:
:
:import sys
:sys.path.insert( 0 , "/path/to/my/python/modules" )
:import cgi # should work now
No, I can't do that, because I wouldn't even be able to...
Wait. I was going to say, that I couldn't even import modules. But, on the off
chance that that somehow I could import the sys module, I tried one of the
things you suggested in a previous message. You previously wrote:
D-Man> To determine if I am at all close in diagnosing the problem, make a
D-Man> simple script that is nothing more than :
D-Man>
D-Man> #!/usr/bin/env python
D-Man>
D-Man> import sys
D-Man>
D-Man> print "Content-type text/html\n"
D-Man> print sys.version
Here's my version of the script:
-----------------------------------------------
#! /big/dom/xthinkspot/Python-2.0/python
import sys
print "Content-type: text/plain\n\n"
print sys.version
-----------------------------------------------
And darned if it don't run! Here is the output, calling it as a cgi-script:
-----------------------------------------------
2.0 (#1, Jan 15 2001, 01:09:04)
[GCC 2.7.2.3]
-----------------------------------------------
OK, I beefed it up a bit, to find out what the actual paths are, when I run a
script. I changed the script to this:
-----------------------------------------------
#! /big/dom/xthinkspot/Python-2.0/python
import sys
print "Content-type: text/plain\n\n"
print sys.version
print
print
for path in sys.path:
print path
print
print "Those are the paths"
-----------------------------------------------
Here is the output:
-----------------------------------------------
2.0 (#1, Jan 15 2001, 01:09:04)
[GCC 2.7.2.3]
/usr/local/lib/python2.0/
/usr/local/lib/python2.0/plat-linux2
/usr/local/lib/python2.0/lib-tk
/usr/local/lib/lib-dynload
Those are the paths
-----------------------------------------------
So, it is apparently not running my local copy of 2.0 at all??? These are not
the paths to my install.
Hmm. Well, I will try what you suggest, and try manipulating the sys.paths and
see if that will help. I'm feeling a bit hopeful, but I'm cautious of getting
too hopeful, and be discouraged yet again.
:
:When you run the interpreter at an interactive shell prompt and import
:cgi, where does it find cgi? Do this:
:
:import sys
:print sys.path
:import cgi
:print sys.modules[ "cgi" ]
Python 2.0 (#1, Jan 15 2001, 01:09:04)
[GCC 2.7.2.3] on linux2
Type "copyright", "credits" or "license" for more information.
>>> import sys
>>> for path in sys.path:
... print path
...
/big/dom/xthinkspot/Python-2.0/Lib
/big/dom/xthinkspot/Python-2.0/Lib/plat-linux2
/big/dom/xthinkspot/Python-2.0/Lib/lib-tk
/big/dom/xthinkspot/Python-2.0/Modules
>>> import cgi
>>> print sys.modules["cgi"]
<module 'cgi' from '/big/dom/xthinkspot/Python-2.0/Lib/cgi.pyc'>
>>>
:If we can figure out where (and how) it is getting 'cgi' interactively
:then it should be easier to find it when executed by apache.
Well, I feel like I have enough to try something else now. Thanks for the
help.
:| Heh...I was thinking of letting my computer science students do some cgi
:| scripting the last two weeks of class (end of May) as an optional project. (In
:| C++, though, not Python...) I may rethink that...? Well, we would be working
:| on Windows machines on a web server running on our desktop, though.
:
:If you can get the web server configured properly to run the CGI
:programs then it shouldn't be a problem. Most of the trouble comes
:not with the script itself but with getting the web server to execute
:it in the proper environment.
...<snipped>...
:
:Since you got your python script to run fine on your windows system at
:home you can certainly get apache set up on the school's systems.
:Once you have that done it shouldn't be any trouble for the students
:to write the scripts/apps.
Well, thanks for the tips. I know I have at least one student who is very
intersted in cgi and web programming in general, which is why I'm even
entertaining the notion of trying this.
:HTH,
Yes, thanks. I will try it out and get back to you on whether it worked or
not.
--
Sheila King
http://www.thinkspot.net/sheila/
http://www.k12groups.org/