[clug-talk] Apache web server with cgi / perl scipts

[Darcy Brodie]

Gustin,
Thanks for the suggestions

Gustin Johnson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> <snip>
>    
>> *_Configuration_*
>>
>> CentOS 5.4
>> Apache 2.2.3
>> Perl 5
>>
>>
>> root directory for web site   /var/www/html/locks (locks is the name of
>> the web site home directory)
>> path for CGI-BIN directory /var/www/cgi-bin
>> path for perl                         /usr/bin/perl
>>
>> permissions on the perl scripts are set to 755, and the CGI-BIN directory
>>      
755 should give full access to the owner, read and execute to group and 
others, so even if the APACHE user does not have ownership, it should 
fall under the "other"  permissions
> Does the webserver uid have ownership of this folder and the files
> within?  Under Debian the apache user is called www-data.  If the
> folder/files are owned by another user, the permissions you listed will
> prevent the perl scripts from executing.
>    
One of the test scripts that I had written was owned by apache (that is 
the apache user), but I have changed ownership of the entire CGI-BIN 
directory and tried it.  No change
> It might be a good idea to make sure that there are no extended ACLs
> getting in the way.
>
> Have you had a look in /var/log/apache2/error.log?  Usually there are04
> more verbose error messages in there.
>    
yes, I have.  What they are saying for the test scripts is;
     malformed header from script.  Bad header=This is a test so see if 
this works : darcy2.pl

what I have in that script is

#!/usr/bin/perl
print"This is a test to see if this works \n";

It works fine from the command line, but not from the browser


 From the script for the password program, when I run it from the 
browser, I get
     (2)No such file or directory: exec of 
'/var/www/cgi-bin/batchsetup.cgi' failed
     Premature end of script headers: batchsetup.cgi


I'm so confused about this,
Darcy

>> I have verified that at the beginning of the scripts is the following
>> #!/usr/bin/perl
>>
>>      
> Make sure that this accurately reflects where perl is installed.  At the
> very least there needs to be a symlink in this location which points to
> the correct location.
>
> You also need to make sure that Apache knows to execute perl scripts. I
> avoid perl like the plague but I have seen similar issues with PHP when
> I did not enable and configure the PHP module.
>
> Hth,
>