Apache Config for users to execute CGI scripts
 

Does anyone know how to configure the apache config file httpd.conf to allow users to execute CGI programs. What I would like is to basically allow any CGI script that is contained in any cgi-bin directory to be allowed to execute, under an address like so:

http://localhost/~com/cgi-bin/test.cgi

or

http://localhost/~com/cps/cgi-bin/test.cgi

What I don't want to do is individually set-up each directory to use CGI. If this is not possible then does anyone know how to configure the conf file to set up CGI in any directory?

Thanks

getting cgi to work
 

my understanding (the way i got it working on my box!!) is that u have to have this in ur http.conf file

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

AllowOverride None
Allow from from all


Order allow,deny
</Directory>

also try using "webmin" i find it not too bad for configuring apache, a bit complex and weird sometimes but handy!

hope this helps!!

So if I wanted to use any home directory I could use:

<Directory "/home/*/public_html/cgi-bin">
Options ExecCGI

AllowOverride None
Allow from from all


Order allow,deny
</Directory>

I will try that out. The error I keep getting is to do with Premature end of script headers. I have checked the Apache docs, but none of the advice is particularly useful. I know that I cab run CGI perl scripts, because I am able to use the script alias thing, but I really need to run CGI in the home directorys.

Thanks anyways.

Premature end of script headers is usually a symptom of DOS formatted perl scripts. Use the command "dos2unix" to convert these into UNIX formatted perl scripts.

naz

I can't see how that is true seeing as the scripts can be excuted, and the fact they were written and saved in Linux. All they do is say Hello World in Perl.

I'm pretty sure that this is an apache config problem, or something to do with the user who runs apache, who in this case is webuser.

I have the exact same problem. Did you ever find a solution, or does anyone have a solution for this? The script I am using is a very simple one that I use to test cgi permissions - runs on all my other boxes. Permissions set to 755

RH8, perl 5.x, apache 2.x

edit -

christ, I posted this on the wrong thread....I am attempting to run this script from the default /var/www/cgi-bin/ folder, not a user home directory...sorry

/edit

I'm not guaranteeing that this is your problem, but I found that suexec gave me fits similar to what you are describing. The easiest fix is to locate suexec, and move it to another directory, then restart apache. The reason is that (i think) suexec is compiled into the RPM with CGI running as the user has to be run from under the /var/www/cgi-bin directory. When you setup virtual servers that run from users home directories (i.e. /home/user/www/cgi-bin), seexec will not allow the script to run. You're supposed to be able to recompile suexec to use another directory, but I have never been brave enough to do it without specific directions from an advanced user. I do know that you can set Apache to run as user Apache and group Apache in the conf file, then remove suexec from the default path and Apache will run the scripts where you tell them to. I would just like to run Apache as the user instead of Apache.
Hope this helps somehow,
Mark

This solved the same problems for me.

chmod -R 755 /var/www/cgi_bin
chgrp -R apache /var/www/cgi-bin
chown -R apache /var/www/cgi-bin

See also....
http://www.redhat.com/support/resou...he-FAQ/x33.html

Wam! No more Premature end of script headers errors.

re: 755
 

The problem you will find (that I previously encountered) is that when files are created by apache through the cgi, they will be owned by apache. If the user logs in via ftp, telnet, or ssh, they will not have the permissions needed to edit or delete them. By fixing suexec, apache will run as the user, and all files or directories created by cgi processes will be owned by that user. In some situations, the 755 and group change will work fine, in others, it won't.

i had to delete my post. it is too early...sorry
cheers, jens