The original script with the Perl path altered works perfectly fine on my VM… so I’m not sure how to produce that error the two of you are receiving.
Edit: Here is the file that runs perfectly fine on my setup (the -w is pointless for this script though based on my understanding of what that does; -w File is writable by effective uid/gid.)
http://paste.ubuntu.com/21744357/
I’ll take another look later. The other option, is I try replicating things on my Hyper-V copy of Ubuntu instead of the one on the physical box.
It works OK as far as GET for me now.
The problem I had was that before I figured out the OS ↔ guest copy-paste problem* I needed to transcribe the code and I introduced some typos.
*After I installed vm tools to my first guest (my localhost Discourse) the tools settings appeared in the Manage options for subsequently created guests. This led me to think the tools were installed globally per VM not per guest, which was not the case.
Just as a quick x-check, who has ownership on your respective cgi-bin folders?
I was actually thinking on the cgi-bin folder itself, however, that’s useful in itself.
My cgi-bin
cgi-bin contents
I’ve been reading bit and came upon the suggestion that the error message may be a permissions issue. I’ll be interested to see how @Mittineague’s permissions look.
my cgi-bin folder is the “.” entry in my screenshot, also has me as the owner on it.
I did “sudo” so mine are “root”
ubuntu-perl@ubuntu:~$ ls -la /home/www/cgi-bin/
total 24
drwxr-xr-x 2 root root 4096 Jul 31 21:36 .
drwxr-xr-x 3 root root 4096 Jul 28 15:37 ..
-rwxr-xr-x 1 root root 1187 Jul 31 18:16 formtest.pl
-rw-r--r-- 1 root root 1024 Jul 31 21:36 .formtest.pl.swp
-rw-r--r-- 1 root root 1024 Jul 31 15:16 .formtest.p.swp
-rwxr-xr-x 1 root root 154 Jul 28 21:54 perltest.pl
ubuntu-perl@ubuntu:~$
I feel a chown coming on…
Not sure, everything looks okay. It has group ownership to www-data which should be sufficient. But if you wanted to be certain, setting it to www-data.www-data should suffice (I would think).
That’s what I did - no dice. It still throws out the 500 error on the page when it hits echo.pl
I’ll check the error.log again, but I’m not expecting to see any difference.
I’m stumped. First thing I’d do is make sure that Apache is looking at that cgi-bin and not the cgi-bin at another location (home directory or something)
There’s an idea. Somewhere in one of the Apache conf files then - I thought we did that much earlier, but no harm in checking.
In other news, at least I got my credit card paid off tonight…
I went back through /etc/apache2/sites-enabled/000-default.conf again. I guess in all the excitement, I forgot that we’d tested perltest.pl from the browser and that worked fine. So in that sense, it seems that certain Perl files can be run from cgi-bin just fine. It’s just this particular file that’s having an issue. I tried calling echo.pl directly from the browser address bar, and it fails in exactly the same way as if it’s being called by the HTML form & JS trying to use it.
In my head, that says it is the Perl file itself that has the issue, not the server config, not the cgi-bin folder, and not the file permissions.
Time to create another unrelated Perl file and see what happens.
AFAIK the -w in the shebang line is the old way of turning on Warnings.
the newer way is to have the line
use warnings;
Calling @Stomme_poes.
I’d be grateful for any assistance you could offer on this one. I’ll post the current version of the Perl file very shortly.
This is the current version of the Perl file echo.pl
#!/usr/bin/perl -w
# This is a Perl script written by Mike McGrath to display, in alphanumeric name order, all name/value pairs submitted from a HTML form.
# It requires Perl to be installed and this script should be placed on the web server, in the directory configured for CGI scripts.
# Process request ----------------------------------------------------------------------
if ($ENV{'REQUEST_METHOD'} eq 'GET')
{
@pairs = split(/&/, $ENV{'QUERY_STRING'});
}
elsif ($ENV{'REQUEST_METHOD'} eq 'POST')
{
read (STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
@pairs = split(/&/, $buffer);
if ($ENV{'QUERY_STRING'})
{
@getpairs =split(/&/, $ENV{'QUERY_STRING'});
push(@pairs,@getpairs);
}
}
else
{
print "Content-type:text/html\r\n\r\n";
print "Unrecognized Request Method - Use GET or POST.";
}
foreach $pair (@pairs)
{
($key, $value) = split(/=/, $pair);
$key =~ tr/+/ /;
$key =~ s/%(..)/pack("c", hex($1))/eg;
$value =~ tr/+/ /;
$value =~ s/%(..)/pack("c", hex($1))/eg;
$value =~s/<!--(.|\n)*-->//g; # ignore SSI
if ($formdata{$key})
{
$formdata{$key} .= ", $value";
}
else
{
$formdata{$key} = $value;
}
}
# Send response ----------------------------------------------------------------------
print "Content-type:text/html\r\n\r\n";
print "<head><title>Web Server Response</title></head><div id='Panel'>";
print "The following data was received from a HTML form submission...<br>";
print "<table width='450' border='2' cellpadding='5'><col><col><tr><th>Name</th><th>Value</th></tr>";
foreach $key (sort (keys %formdata)){ print "<tr><td>$key</td><td>$formdata{$key}</td></tr>"; }
print "</table></div></body></html>";
# End ----------------------------------------------------------------------------------
I tried another completely different file - basically the same as "cpradio got working, but no joy with it on my setup - just the same errors as I got with echo.pl.
The only thing different I can think of at the moment, is that perltest.pl was typed up inside nano, where the other two were FTP’d onto the server, and then moved to the cgi-bin folder using the sudo mv command.
###another.pl
#!/usr/bin/perl
print "Content-type: text/html\r\n\r\n";
print "Hello there!<br />Just testing.";
That makes me think the FTP program is pushing a BOM marker or something odd like that. Did you make sure it transferred the file as ASCII and not binary?
I think we may finally be onto something. I just re-typed it from scratch in nano under the name newperl.pl. Once I’d done a chmod 755 to it, it ran sweet as a nut.
Let me go see how it pushed the file - I don’t think I’ve ever needed to do anything like that before.