[andynic]

Mac OS X 10.6
Apache 2.2
Perl CGI.

Would appreciate whatever ideas you can pass on to me -- I'm pretty much a newbie.

I have a set of cgi scripts that run perfectly on Apache 2.2 on Windows XP.
I am now porting the software to my iMac and cannot get past 1st base!

When I start an html file in Safari that contains the following image reference
<IMG src="icons/gallery_nicastro_logo.jpg" ...
The jpg displays as it should.

When I click the button in that same html file that contains the ref: href="http://localhost/dev/gfrm.cgi?init"
I get the Forbidden error message.

The directory for icons (which works) is defined like this in the httpd.conf file:
# For images displayed in the final webpage
# For images dispalyed in the maintenance scripts
Alias /icons/ "/Users/andynic/Desktop/Mac_XP_SharedFiles/DocumentsCurrent/Documents_20090101_to_20091231/Computing/gfrmMac/icons/"
<Directory "/Users/andynic/Desktop/Mac_XP_SharedFiles/DocumentsCurrent/Documents_20090101_to_20091231/Computing/gfrmMac/icons">
Options Indexes MultiViews
AllowOverride None
Order allow,deny
Allow from all
</Directory>


The direcotry of the cgi scripts (which causes the error) is defined like this:
Attempt 1:
<Directory "/Users/andynic/Desktop/Mac_XP_SharedFiles/DocumentsCurrent/Documents_20090101_to_20091231/Computing/gfrmMac">
Options +ExecCGI +Indexes
AddHandler cgi-script .cgi
Order allow,deny
Allow from all
</Directory>
ScriptAlias /dev/ "/Users/andynic/Desktop/Mac_XP_SharedFiles/DocumentsCurrent/Documents_20090101_to_20091231/Computing/gfrmMac/"

Attempt 2: (where the passwords file was created using htpasswd -c)
<Directory "/Users/andynic/Desktop/Mac_XP_SharedFiles/DocumentsCurrent/Documents_20090101_to_20091231/Computing/gfrmMac">
Options +ExecCGI
require valid-user
AuthType Basic
AuthName "gfr"
AuthUserFile "/private/etc/apache2/passwords"
</Directory>
ScriptAlias /dev/ "/Users/andynic/Desktop/Mac_XP_SharedFiles/DocumentsCurrent/Documents_20090101_to_20091231/Computing/gfrmMac/"


The server is started by user root: sudo apachectl -k start
I have tried running the cgi script both as owner andynic and root (chown).
chmod privs are set to 755.

What am I doing wrong?
Thanks for your help.
Andynic

[dock98]

try running as administrator.

[Lordandmaker]

There's nothing jumping out at me as being wrong, but I'm running low on caffeine. Apache's logs are generally pretty useful, though. Have you checked what they reckon?

Does Apache have execute rights on the scripts? (i.e. at least chmod 755)

[andynic]

Hi Lordandmaker and dock98,

Thanks very much for your speedy replies.

Re. Lordandmaker's reply:
===================
Here is the tail of error_log:
[Mon Oct 26 18:34:02 2009] [notice] caught SIGTERM, shutting down
[Mon Oct 26 18:34:06 2009] [warn] Init: Session Cache is not configured [hint: SSLSessionCache]
[Mon Oct 26 18:34:07 2009] [notice] Digest: generating secret for digest authentication ...
[Mon Oct 26 18:34:07 2009] [notice] Digest: done
[Mon Oct 26 18:34:07 2009] [notice] Apache/2.2.11 (Unix) mod_ssl/2.2.11 OpenSSL/0.9.8k DAV/2 configured -- resuming normal operations
[Mon Oct 26 18:34:17 2009] [error] [client ::1] (13)Permission denied: access to /dev/gfrm.cgi denied
[Mon Oct 26 18:48:04 2009] [error] [client ::1] (13)Permission denied: access to /dev/gfrm.cgi denied

and of access_log:
::1 - - [26/Oct/2009:18:19:45 +0100] "GET /dev/gfrm.cgi?init HTTP/1.1" 403 214
::1 - - [26/Oct/2009:18:34:17 +0100] "GET /dev/gfrm.cgi?init HTTP/1.1" 403 214
::1 - - [26/Oct/2009:18:48:04 +0100] "GET /dev/gfrm.cgi?init HTTP/1.1" 403 214
::1 - - [26/Oct/2009:20:01:20 +0100] "GET /dev/gfrm.cgi?init HTTP/1.1" 403 214
::1 - - [26/Oct/2009:20:03:51 +0100] "GET /dev/gfrm.cgi?init HTTP/1.1" 403 214
::1 - - [26/Oct/2009:20:04:09 +0100] "GET /dev/gfrm.cgi?init HTTP/1.1" 403 214


The permissions on the cgi file are 755, and I've tried 777 also
-rwxr-xr-x 1 andynic staff 19802 1 Oct 18:36 gfrm.cgi
-rwxr-xr-x 1 andynic staff 3366 24 Jun 18:46 gfrm.html

Re. dock98's reply:
I have just tried the following from a command window with the same (forbidden) results:
sudo open -a /Applications/Safari.app gfrm.html
::1 - - [26/Oct/2009:18:19:45 +0100] "GET /dev/gfrm.cgi?init HTTP/1.1" 403 214
::1 - - [26/Oct/2009:18:34:17 +0100] "GET /dev/gfrm.cgi?init HTTP/1.1" 403 214
::1 - - [26/Oct/2009:18:48:04 +0100] "GET /dev/gfrm.cgi?init HTTP/1.1" 403 214
::1 - - [26/Oct/2009:20:01:20 +0100] "GET /dev/gfrm.cgi?init HTTP/1.1" 403 214
::1 - - [26/Oct/2009:20:03:51 +0100] "GET /dev/gfrm.cgi?init HTTP/1.1" 403 214
::1 - - [26/Oct/2009:20:04:09 +0100] "GET /dev/gfrm.cgi?init HTTP/1.1" 403 214

No resolution yet, but thanks for your replies. Hope you can come up with something else.
Andynic

[Lordandmaker]

Can you run gfrm.cgi in the shell?

Can you do same if you su to whatever user apache is (often 'www-data' or 'nobody')

[andynic]

I tried it this way,
sudo open -a /Applications/Safari.app gfrm.html

I'm not sure what the syntax would be to run gfrm.cgi directly from a shell..
I have tried this:
sudo open -a /Applications/Safari.app 'http://localhost/dev/gfrm.cgi?init'
which produced the same "forbidden" error.

Then I changed the root password using sudo passwd. And as root I did the following:
open -a /Applications/Safari.app 'http://localhost/dev/gfrm.cgi?init'
and still got the same result.

Would it perhaps be helpful if I e-mailed you the httpd.conf file? Perhaps I have put things in the wrong order or wrong place?

Thanks for your help,
Andynic

[Lordandmaker]

Originally Posted by andynic

I tried it this way,
sudo open -a /Applications/Safari.app gfrm.html

Why sudo?
Why pass it on to Safari? And why the html file?

I'm not sure what the syntax would be to run gfrm.cgi directly from a shell..
I have tried this:
sudo open -a /Applications/Safari.app 'http://localhost/dev/gfrm.cgi?init'
which produced the same "forbidden" error.

Open a shell, and run

perl gfrm.cgi

and see what happens.

Would it perhaps be helpful if I e-mailed you the httpd.conf file? Perhaps I have put things in the wrong order or wrong place?

I can have a look through it, certainly.

[andynic]

I ran gfrm.cgi in a shell only, Here are the results.
gfrmMac$ perl -c gfrm.cgi
gfrm.cgi syntax OK

gfrmMac$ perl gfrm.cgi
Content-type:text/html

gfrm.cgi puts up a DB maintence form. The end-user manages the data via a web browser, which is why I've been running it through Safari.

I've also written a very simple program, hello.pl.
gfrmMac$ cat hello.pl
#!/usr/bin/perl
print "Content-type: text/html\r\n\r\n";
print "Hello, World.\n";

gfrmMac$ perl hello.pl
Content-type: text/html

Hello, World.

When accessed via a web browser, either this way from a command window:
open -a /Applications/Safari.app 'http://localhost/dev/hello.pl'
or
by starting safari and entering http://localhost/dev/hello.pl as URL,
both produce error 403.

[andynic]

One other thing I have just tried:

I moved the entire gfrmMac tree to /usr and changed all the protections in the new tree to 777. (The original tree was in a directory that is part of a set of directories shared between the iMac and a VMware Fusion Windows XP virutal machine. I thought that might have an impact).

Then I changed all the aliases in httpd.conf. For example,
<Directory "/Users/andynic/Desktop/Mac_XP_SharedFiles/DocumentsCurrent/Documents_20090101_to_20091231/Computing/gfrmMac">
Options +ExecCGI
require valid-user
AuthType Basic
AuthName "gfr"
AuthUserFile "/private/etc/apache2/passwords"
</Directory>
ScriptAlias /dev/ "/Users/andynic/Desktop/Mac_XP_SharedFiles/DocumentsCurrent/Documents_20090101_to_20091231/Computing/gfrmMac/"
is changed to
<Directory "/usr/gfrmMac">
Options +ExecCGI
require valid-user
AuthType Basic
AuthName "gfr"
AuthUserFile "/private/etc/apache2/passwords"
</Directory>
ScriptAlias /dev/ "/usr/gfrmMac/"

Still I get the 403 error.

[andynic]

I am a step further.

In what follows, "andynic" is the name of the usere logged in to the iMac.

I added the following line to httpd.conf, (the one that is using /usr/gfrmMac, the last one mentioned above):
Include /private/etc/apache2/users/andynic.conf

andynic.conf is just this:
<Directory "/usr/gfrmMac">
Options Indexes MultiViews
AllowOverride None
Order allow,deny
Allow from all
</Directory>

Now instead of 403, I'm getting 500 "Internal Server Error"
tail error_log:
[Tue Oct 27 15:48:13 2009] [notice] caught SIGTERM, shutting down
[Tue Oct 27 15:48:15 2009] [warn] Init: Session Cache is not configured [hint: SSLSessionCache]
[Tue Oct 27 15:48:16 2009] [notice] Digest: generating secret for digest authentication ...
[Tue Oct 27 15:48:16 2009] [notice] Digest: done
[Tue Oct 27 15:48:16 2009] [notice] Apache/2.2.11 (Unix) mod_ssl/2.2.11 OpenSSL/0.9.8k DAV/2 configured -- resuming normal operations
[Tue Oct 27 15:48:19 2009] [error] [client ::1] (2)No such file or directory: exec of '/usr/gfrmMac/hello.pl' failed
[Tue Oct 27 15:48:19 2009] [error] [client ::1] Premature end of script headers: hello.pl

I don't undersand the last two errors. hello.pl is taken from the apache2 website.
gfrmMac$ ls -l /usr/gfrmMac/hello.pl
-rwxrwxrwx 1 root wheel 85 27 Oct 11:24 /usr/gfrmMac/hello.pl

all protection codes on and in directory gfrmMac are 777.
I have tried this with both ower set to root and owner set to andynic.
All attempts now produce error 500.

[Lordandmaker]

Error 500s are when the script fails.

What happens when you run the script from the command line?

$ /usr/gfrmMac/hello.pl

Apache might have something against running scripts that're owned by root, even when they're 777'd and not setuid'd. I don't know, though, I've never tried it.

[andynic]

Problem seems to be solved.

I stumbled across these two related web pages.
http://encodable.com/internal_server_error/
http://encodable.com/suexec_problems/

Adding -w to the shebang line in the cgi script, as suggested in the second site, fixed it.

That is, instead of
#!/usr/bin/perl
I needed to use
#!/usr/bin/perl -w

So the hello script looks like this now:
#!/usr/bin/perl -w
print "Content-type:text/html\n\n";
print "Hello, World.\n";

An interesting sidelight: The script extension needs to be ".cgi". Then it works as expected in the Safari browser. If the script has extension ".pl", it causes a file to appear in the download list. Then if you open that file, the output is there.

All seems very mysterious. From what I can find, so far, these switches are just the command line perl options. "-w" from the command line simply allows the perl interpreter to generate warings. I don't see what it has to do with stopping the Apache server from generating error 500.

[andynic]

Summary of this thread:

This thread in the end turned out to be about two different problems.

The first had to do with Error 403: Forbidden -- You don't have permission to access ... on this server.

This was solved by the post above: 27-Oct-2009, 03:56 PM #10

The second had to do with Error 500: Internal Server Error.

This was solved by the post above: 28-Oct-2009, 12:40 PM #12

Hope this might be helpful to someone in the future.
Andynic

[Lordandmaker]

Originally Posted by andynic

Problem seems to be solved.
An interesting sidelight: The script extension needs to be ".cgi". Then it works as expected in the Safari browser. If the script has extension ".pl", it causes a file to appear in the download list. Then if you open that file, the output is there.

This is because your AddHandler directive stated

AddHandler cgi-script .cgi

Which means that only filenames ending in .cgi are treated as cgi scripts. If you'd written

AddHandler cgi-script .pl

Only .pl would.

All seems very mysterious. From what I can find, so far, these switches are just the command line perl options. "-w" from the command line simply allows the perl interpreter to generate warings. I don't see what it has to do with stopping the Apache server from generating error 500.

It shouldn't change it.
Perl scripts, in general, should be headed with

#! /usr/bin/perl
use strict;

Because the strict pragma stops you doing several dangerous things. Warnings can be really handy to tell why it went wrong, though, or more often, that you didn't notice it going wrong. It warns of things like variable assignments that never get used, or variables being clobbered before use. Things that you might well want to do, but probably don't.

As I said above, an http500 error on a cgi script is generally the script failing.