12

I am trying to execute a Python program using Apache. However, Apache will only serve the file and not actually execute it. The permissions on the file are r/w/x and it is in /var/www. I will post the contents of httpd.conf and the program code after. I also tried to running the python script as a .cgi file but that did not work as well. I have both the mod_python and mod_wsgi modules loaded into apache as well.

Python sample:

#!/usr/bin/python

# enable debugging
import cgitb
cgitb.enable()

print "Content-Type: text/plain\r\n\r\n"
print

print "Hello World!"

httpd.conf:

AddHandler cgi-script .cgi .pl
AddHandler python-program .py

I know its a small httpd.conf file but when I installed apache, there was nothing in the file. I should also mention that this is just so that I learn the basics of running python in apache. It is not meant for production. Thanks for the help!

Edit

The OS I'm using is Ubuntu 10.04 and the version of apache is 2. I have python version 2.6 which is automatically used when #!/usr/bin/env python is invoked.
I am getting two main errors, the first is that the file is not being found even though the permissions of the file and folder are 777. The error from the log is

[Sun Feb 05 13:29:44 2012] [error] [client 192.168.1.3] File does not exist: /var/www/poit-0.1

This error is for a different python script that I did not write. What is weird is that the file shows up in the index of the folder when accessed from a browser window. However, when I navigate to the file, I get the above error.

The other error that I am getting is premature end of headers. The error is below:

[Sun Feb 05 12:10:19 2012] [error] (8)Exec format error: exec of '/var/www/pyth.py' failed
[Sun Feb 05 12:10:19 2012] [error] [client 192.168.1.3] Premature end of script headers: pyth.py
tpar44
  • 1,431
  • 4
  • 22
  • 35

6 Answers6

20

The first line of httpd.conf: AddHandler cgi-script .cgi .pl is irrelevant, since you're testing python scripts and not perl scripts. And you should define those directives within the location of your python script, and tell apache that it should execute cgi scripts in that location: Options +ExecCGI. This snippet would be a start:

<Directory /path/to/sample.py />
  Options +ExecCGI
  AddHandler cgi-script .py
</Directory>

Addendum 1:

As per my last comment, try this script. It should spit information about the cgi environment.

#!/usr/bin/python
import cgi
cgi.test()

Addendum 2:

I got your script to work with the above configuration. The problem is that script is written in python2. And the default interpreter apache is invoking to execute the script, is python3 (at least in my case, and chances are this would be the same for you too).

This is a python3 version of the hello world script:

#!/usr/bin/env python

# enable debugging
import cgitb
cgitb.enable()

print("Content-Type: text/plain;charset=utf-8")
print()

print("Hello World!")

Addendum 3:

For the first error, make sure the permission and the ownership of whatever directory and files you're attempting to deploy are properly set. And try adding those directives to httpd.conf:

Order allow,deny
Allow from all

Which will get you this:

<Directory /path/to/sample.py />
  Options +ExecCGI
  AddHandler cgi-script .py
  Order allow,deny
  Allow from all
</Directory>

For the second error, unless I am missing something, it looks like apache is invoking python 3 interpreter to execute your script. To rule out this possibility, you might try the following:

ls -al /usr/bin/python*

This will list the python interpreters available on your system. If you have more than one interpreter you'll get something similar to this output:

/usr/bin/python -> python3*
/usr/bin/python2.6*  
/usr/bin/python3*  

If not, it would be this output:

/usr/bin/python -> python2.6*
/usr/bin/python2.6*  

To make sure, this is not the issue you're having, try with this modified sample script:

#!/usr/bin/python2.6

# enable debugging
import cgitb
cgitb.enable()

print "Content-Type: text/plain\r\n\r\n"
print

print "Hello World!"

You'll notice that I explicitly mentioned the version of the interpreter apache should invoke, which is ugly. But for the sake of testing, you can do it. Of course you should map #!/usr/bin/python2.6, to whatever binary you have on your server, and make sure you don't mix python 3 comtipable code with python 2 interpreter and vice versa.

b2Wc0EKKOvLPn
  • 2,054
  • 13
  • 15
  • Yes, I know that the first line doesn't have anything to do with the problem and that I should have it mapped out for specific directories however, my main goal right now is to get it to work. What you suggested did not work. Could it be something with the script itself because there is also an error in the log saying premature end of headers – tpar44 Feb 05 '12 at 02:00
  • Actually, I think my snippet did work, but the problem now is your script itself. It seems apache is shocking on the carriage-return characters. Try the simpler test, I just appended to my main post. – b2Wc0EKKOvLPn Feb 05 '12 at 03:22
  • By the way, you should not enable mod_python and mod_wsgi at the same time, they're incompatible. And each of them require a different deployment configuration. And what you're attempting to do now, that is, deploying a python webapp as a cgi script, needs neither of them. So you might disable them to reduce the risk of misleading interferences. – b2Wc0EKKOvLPn Feb 05 '12 at 03:34
  • So apache won't let me run the second script and I'm not sure why since I did exactly what you said to do. The third script won't run either but when I run it from the command line with ./ i get the error that `syntax error near unexpected token `print'` before the first print statement. If I run it by invoking it with "python" then it works just fine. I'm thinking that there is something wrong with the shebang but I'm not sure what it could be. – tpar44 Feb 05 '12 at 16:33
  • It seems related to your python environment. Could you please add information to your post about, the operating system you're running this test on, the version of apache, the version(s) of python interpreters installed, and which one is the default. Also, would it be possible for you to document your attempts and post the error logs you get from apache. – b2Wc0EKKOvLPn Feb 05 '12 at 18:34
  • Please check my 3rd addendum. – b2Wc0EKKOvLPn Feb 06 '12 at 00:56
  • 1
    Sir you saved my day. I think the "Order" and "Allow all" part saved me. Thank you sir. Please have a nice life everyday – user3290525 Nov 12 '15 at 14:29
3

Re: The Exec format error.

I've run in to this myself a couple of times before. I had the exact same (cryptic) error message.

I was developing Python (3) scripts to use via CGI in Notepad++ on my Windows machine, and then uploading them to my Linux server.

After much frustration, I discovered that this issue is related to line endings and you need to convert Windows line endings (\r\n) to UNIX line endings (\n).

In Notepad++ (6.1.5), you can achieve this by going to the Edit menu and selecting the EOL conversion option and then saving the file.

nibbler
  • 31
  • 1
  • 3
    Only a partial response, but hopefully it helps some poor sod Googling for the problem. – nibbler Mar 21 '14 at 14:13
  • As an alternative, you can use the **dos2unix** tool on most Linux systems. This command line utility scans through the specified file and converts all of the line endings (and probably some other stuff too, but the line endings are important). – nibbler Feb 23 '17 at 03:34
1

**For apache2 version 2.4

sudo apt-get install python
sudo apt-get install apache2

edit file /etc/apache2/conf-enables/serve-cgi-bin.conf

====comment old section and add code below:

ScriptAlias /cgi-bin/ /var/www/cgi-bin/
<Directory "/var/www/cgi-bin">
AddHandler cgi-script .py
AllowOverride None
Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Allow from all
</Directory>

=========================================

edit file /etc/apache2/apache2.conf ***add code below:

<Directory "/var/www/cgi-bin">
AllowOverride None
Options ExecCGI
Order allow,deny
Allow from all
</Directory>

<Directory "/var/www/cgi-bin">
Options All
</Directory>

<Directory /usr/local/apache2/cgi-bin>
Require all granted
</Directory>

Note!

use for apache2.4 
  file python keep in directory: /var/www/cgi-bin/
  You can test :go to http://localhost/cgi-bin/<namefile>.py

referrence https://www.linux.com/blog/configuring-apache2-run-python-scripts

siczones
  • 9
  • 4
0

In my case, it was a trivial issue. I had to add this line:

#!/usr/bin/python3

to the top of every .py file I wanted to run.

Then, everything started working correctly.

Remolten
  • 2,614
  • 2
  • 25
  • 29
0

I had the same symptom and my config looked okay compared to the answers above.

I found that my new install was not configured to load mod_cgi.so

Loading the required module looks a bit like this. If restarting the server will give you an error that the file was not found, figure out where the file is adjust the path accordingly.

LoadModule cgi_module modules/mod_cgi.so

Chris
  • 5,788
  • 4
  • 29
  • 40
-5

I'm assuming you are using firefox. I read somewhere else on the 'net that it could be related to the firefox addons installed on a machine.

I was getting this error and I use firefox 20. Switched to Opera and I did not get any more errors and the python scripts seemed to execute just fine.

Edit: It was actually an eval() method call I had overlooked that had appended "(" and ")" to the results of the script that caused my failure. Once I removed them, it worked for me.

I noticed you did not post the javascript, html, or whatever it is you use to call the script in the first place. Perhaps you could post it for us? I did a direct copy/paste example from a blog site without looking at what I had copied. That was my error.

NuclearPeon
  • 5,743
  • 4
  • 44
  • 52
  • 1
    If Apache is serving a server-side script, this is not a client-side issue. Clients should not be able to access them directly. – tom Nov 06 '13 at 15:57
  • It's been a while since I've posted this answer. In my issue, I was calling server side methods from the client, which required knowledge of the method names from the client. It wasn't a project that I had designed. In that case, it is partially a client-side issue. (It was a web app, not a web site I was working on) Opera is most standard compatible when it comes to web standards, so having an Opera install can help debug issues, especially browser-based ones. – NuclearPeon May 14 '14 at 18:28