Making Apache2 execute CGI scripts, globally?
Posted by fraktalisman on Mon 14 Apr 2008 at 12:08
I have set up a Debian etch system with apache2, perl etc, but I cannot get apache to actually execute my scripts..
I want to be able to have .pl executed everywhere below /var/www . Everything is installed from the regular Debian packages, and all packages have been updated yesterday.
I first modified /etc/apache2.conf adding:
AddHandler cgi-script .cgi .pl Options +ExecCGI
But still get the error message "403 Forbidden" in the browser, and the following logged:
Options ExecCGI is off in this directory
When I put the AddHandler and Options directives once more for the actual subdirectory, after restarting apache, the scripts are served for downloading, instead of being executed!
In the error log, I see:
(2)No such file or directory: exec of '/var/www/auktionator/admin/_rechte.pl' failed Premature end of script headers: _rechte.pl
The script is chmodded 0755, and so are the directories in /var/
drwxr-xr-x 4 root root 4096 2008-04-08 13:06 www
I can execute the script from the command line, as follows:
perl -cw /var/www/auktionator/admin/_rechte.pl
My perl script starts correctly with:
#! /usr/bin/perl
which is the actual location of my perl binary.
I wonder if perl is configured correctly for apache to find it. How and where would I check this? There is a perl.load in
/etc/apache2/mods-available
and a link to it in
/etc/apache2/mods-enabled
What does the Perl script look like? What does it output look like when you run it from the command line?
--
"It's Not Magic, It's Work"
Adam
[ Parent | Reply to this comment ]
/etc/apache2/apache2.conf surely?
[ Parent | Reply to this comment ]
no space after #!
[ Parent | Reply to this comment ]
Also, include a space after the exclamation point in interpreter specifications, like this:
#! /usr/bin/perl
If you omit the space before the path, then 4.2BSD based systems (such as DYNIX) will ignore the line, because they interpret `#! /' as a 4-byte magic number. Some old systems have quite small limits on the length of the `#!' line too, for instance 32 bytes (not including the newline) on SunOS 4.
[ Parent | Reply to this comment ]
Does "ls -l /var/www/auktionator/admin/_rechte.pl" show something like rwxr-xr-x ?
All CGI-Scripts must be executable on the command line to work.
[ Parent | Reply to this comment ]
-- Dariusz Cieslak
[ Parent | Reply to this comment ]
That normally implies the interpreter can't be found -- you show that you can run the script with "perl -cw /path/to/script" (which ignores the shebang line) but can you also run it just as "/path/to/script" (which, like apache, will rely on the shebang line).
A common culprit for this is line endings. DOS (CRLF) or Mac (CR) line endings will will cause the shebang line to be incorrectly interpreted and give you exactly this error. Check the line endings using a decent editor (vim will tell you for example) or try a conversion program and see if the files are different after an attempted conversion. (dos2unix is in the tofrodos package, or you could use col, tr -d '\r' ... there are many possibilities)
Oh, and you'll get more immediate help if you jump on #debian on irc.debian.org.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
Oddly. even after I put all those directives into httpd.conf, my test script STILL refused to run. One thing I was SURE about was there was nothing wrong with my "Hello World" test script. I'd used it on my old server to help solve scripting issues several times...
After chasing this bug for hours I even tried moving the cgi-bin directrory from one location on the server to another. But that did me no good either. The messsages in the Apache error.log for the domain were telling me I was being successful in moving the script around and and in being able to find it later. AND ownership, group, permissions on all the files were just fine, Yet the test script still failed to run!
One thing I did notice that you didn't mention is when I tried to run the script from the shell prompt WITHOUT invoking perl as Apache's troublshooting procedure suggested. When I typed: ./hello.pl at the shell prompt as opposed to: perl hello.pl (which ALWAYS worked), I got the following puzzling message:
-bash: ./hello.pl: /usr/bin/perl^M: bad interpreter: No such file or directory
Yet, /usr/bin is exactly where the perl binary is located on my server! But then there was that not-so-obvious CTRL-M (^M) after the perl path. Why was it there? That eventually that got me to wondering if there WAS indeed something wrong in the program. Sure enough, I proved there was! Since my test program was just 2 lines long, and that extra CRL-M (carriage return) in the
bugged me, I eventually decided to delete the program file and simply retype it.
That proved to be the remainder of the solution to my perl script problem. As it turned out, that lingering (and invisible in the vim editor) ^M was causing bash to misread the path to perl as /usr/bin/perl^M rather than as just /usr/bin/perl
In short, the problem I was having was a direct result of a practically invisible anomaly hidden in the script I was using to test with! Once I fixed that problem in my test script, I realized that ALL my other cgi-bin scripts had been running finde all day. By the luck of the draw, I just happened to decide to test with the shortest 2 line perl script I could find and THAT script had a flaw buried in it that my OLD server's install of cgi-bin had ignored but it stopped my server build project for a whole day while I tried to figure out what was wrong with Apache and perl. In the end, the REAL problem was in the script I was testing with.
Argh!!
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]