CGI not working for Lenny/ISPConfig3

Something funny is going on. I'm using the tandem Lenny/ISPConfig3 now and perl doesn't work at all, not even in the cgi-bin. There was no such problem with my old Etch/ISPConfig combination.

Since the domain was created using the ISPConfig3 panel: is there something I could have done wrong while creating the site?

When creating one of my websites in ISPConfig3 I checked all boxes except SSL, with Auto-Subdomain set to www. and PHP set to Mod-PHP (and Active checked). I use both PHP and perl.

If you want to see what happens, go to opstartpagina.nl/opstartmail.html, send me a message and see what comes out of that. The perl script is in the cgi-bin and permissions are wide open.

If I can't get the new tandem working (I'm configuring it from the top on another box), I'll have to return to the old tandem or resort to another Linux distro.

= - = - = - = - = - =
Added later:

OK, perl is working in the cgi-bin now (newly installed Lenny/ISPConfig3). No luck yet outside the cgi-bin.

 

Have you added +ExecCGI to the options for the sites main directory?

 

In /etc/apache2/sites-enabled/000-default I found:

<Directory /var/www/>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
</Directory>

I added +ExecCGI to the Options to make it look like:

<Directory /var/www/>
Options Indexes FollowSymLinks MultiViews +ExecCGI
AllowOverride None
Order allow,deny
allow from all
</Directory>

I restarted apache2 (/etc/init.d/apache2 restart) and moved a perl script which works inside the cgi-bin out of the cgi-bin to the website's root folder. Of course, I checked the permissions.

No luck.

I also tried Falko's suggestion (2005):

ScriptAlias /cgi-bin/ /path/to/your/cgi-bin_directory/

in the Apache directives of ISPConfig3 (Website/Options).

No luck either.

Any other suggestions?

 

The whole question is about this:

How can I get a perl script working outside the CGI-bin?

 

I don't understand what I must differently from Etch/ISPConfig other than using different conf files. In Etch I made a modification in httpd.conf. In Lenny I did the following.

I added +ExecCGI to the Options to make it look like:

<Directory /var/www/>
Options Indexes FollowSymLinks MultiViews +ExecCGI
AllowOverride None
Order allow,deny
allow from all
</Directory>

I restarted apache2. This works for Etch/ISPConfig, but I can't get perl to work outside the cgi-bin.

When this did not work, I tried the same thing inside the vhost file for the specific website, i.e. for the file /etc/apache2/sites-available example1.com.vhost.

This didn't work either: perl script refused to work outside the cgi-bin.

I don't know how to go about the perl-mod suggestion and I'm almost beginning to believe that this cannot be fixed for Lenny/ISPConfig3.

 

I normally run cgi outside the cgi-bin.
For me its a convenience because I like to name my scripts '.cgi' and then can replace one script (eg php as cgi) with another (eg compiled cgi) and keep the same name and all links will still work. I use a lot of freepascal compiled for cgi access.

Where you want to make the change is in the vhost file for the site.
(Not the main httpd.conf file)
/etc/httpd/conf/sites-enabled/yourdomain.com.vhost.

Code:

<Directory /var/www/yourdomain.com/web>
        Options FollowSymLinks +ExecCGI
        AllowOverride All
        Order allow,deny
        Allow from all
    </Directory>

...and also (?) in the section that follows ie within
<Directory /var/www/clients/client1/web4/web>

I have also edited the master file (vhost.conf.master) so that ISPConfig makes the setting for me by default. I would like to propose an addition to ISPConfg to allow the option of either
1/ no CGI
2/ CGI via cgi-bin
3/ 'site-wide' CGI.

-----
edited to say...

You can alternatively make a suitable change through ISPConfig as admin

Go to : 'Sites'
Select the relevant site from the list
Click on the 'Options' tab
In the Apache Directives box add

Code:

<Directory /var/www/yourdomain.com/web>
   Options +ExecCGI
</Directory>
<Directory /var/www/clients/client1/web2/web>
  Options +ExecCGI
</Directory>

 

I followed Till's advice: added those two lines to the Apache directive field for the specific website. I restarted apache2. This is what happened when I tried to execute the script (chmod 755) outside the cgi-bin:

ERROR 403 - Forbidden!
The following error occurred:
You are not permitted to access the requested URL.
Please contact the webmaster with any queries.

Alas!

I'll study Mike's suggestion later.

 

No luck yet

This is what happened when I followed Mike_P's instructions.

1. In Debian 5 (Lenny) I have a choice of editing, among other ones, the following files inside directory /etc/apache2/sites-enabled:

000-default
mysite1.com.vhost

I decided to edit mysite1.com.vhost as I gathered that this is the last file the system is taking data from.

In mysite1.com.vhost I found these lines:

<Directory /var/www/mysite1.com>
AllowOverride None
Order Deny,Allow
Deny from all
</Directory>

I changed them into:

<Directory /var/www/mysite1.com>
Options FollowSymLinks +ExecCGI
AllowOverride All
Order Deny,Allow
Allow from all
</Directory>

I restarted apache2 and tested my perl script, working well inside the cgi-bin, outside the cgi-bin, with 755 permissions.

I got the ERROR - Forbidden! message.

I undid everything and went to Mike_P's second suggestion.

2. To the Apache directives field I added these lines:

<Directory /var/www/mysite1.com/web>
Options +ExecCGI
</Directory>
<Directory /var/www/clients/client1/web1/web>
Options +ExecCGI
</Directory>

I restarted Apache2 and tested the script outside the cgi-bin. Message:

ERROR 500 - Internal Server Error!
The following error occurred:
The requested URL caused an internal server error.
If you get this message repeatedly please contact the webmaster.

I was not tempted to contact the webmaster. He doesn't know mess and I know it, because it's me.

Any more suggestions?

 

Have you got Suexec enabled? If so can you check the suexec log.

The fact that the message has changed from permissions to a 500 suggests that the +ExecCGI has worked and that it is now just a Suexec problem. Please make sure that the script ownership is
web1:client1

 

Yes!

After changing the ownership of the cgi file, option 2 (adding those lines to the Apache directive in ISPConfig3 > Websites> Options) worked.

Just for folks who don't know how to change the ownership. In terminal, navigate to the folder that contains the file, e.g.:

cd /var/www/clients/client1/web1/web

then:

chown web1 somescript.cgi

You may, of course, also do it in one step:

chown web1 /var/www/clients/client1/web1/web somescript.cgi