For the issues I have been having with the above formula, I decided to write up my experience in hopes that I can either help someone or at least provide a few little details to make some sense of things.
First off, I just want to say, that if you, as a programmer, choose to use Perl, and then further choose to design a full web application with Perl, PLEASE, PLEASE use the CGI-BIN file so that for future programmers on your project may be able to move your project without an act of congress. KEEP THINGS SIMPLE!!!
Ok, here is the preface of the situation, A company I have been working with for a few months has a large number of antiquated servers. They purchased some new ones and then wanted to move everything to the new servers. This seems like a not too difficult task, the source machines are Fedora. I opted for the newest release of Ubuntu because of the many new features like integrated cloud control and the fact that it is built on Debian. Don’t boo me since I am taking the easy road, there is a Sonic wall that will do the filtering and provide a very high level of security and IDS. Since this is not a post on security I won’t get into the details of my security plan.
Once LAMP and IspCP was all setup, it was time for the copy. After I had a complete copy of all the files, I began filling out the holes of the new, empty webserver. For anyone who has messed with IspCP, you will know that it uses /var/www/virtual/[domain name]/htdocs to store the web accessible files. The cgi-bin folder is stored at the same level as htdocs.
I began populating htdocs with the info from the previous server and everything starting going fine. Even all of the PHP files worked and executed properly thanks to settings in IspCP. The issue, Perl was sprinkled throughout much of the web applications. Many database calls and functions were all written in Perl. One would think that this isn’t a big deal and that with a few apt-get calls, everything would work out.
The major issue is that it was the intention of the “Elders of The Internet” to store executable files in the cgi-bin. And from my research (which is many hours at this point), it seems Apache2 with Virtual Hosts is dedicated to following these directives. After hours of messing with the apache2.conf, ispcp.con, and other config files, I finally have found a work around that is not convenient, but workable.
Inside the virtual host file ispcp.conf (in /etc/apache2/site-enabled/ispcp.conf) under the <VirtualHost> directive, you can place:
AddHandler cgi-script .pl .html
Options +ExecCGI
Inside the same file, inside the <Directory *> directive you can place the same information as above to have it apply only to the specific directory. However, this only works with directories at the same level or deeper in the tree. (Eg. /here or /here/nowhere). When I would try to use a directory outside the VirtualHost document root, I would get an Internal Error 500 with the suexec.log file saying that the directory had other write permissions enabled…. Very strange.
The things that don’t work, and guarantee Internal Error 500 are adding the <file ~ .pl> with the file handlers for perl scripts to apache2.conf. If you try to add an ‘*’ to the directory in the above example, it causes a 500 error.
Finally, I found out the hard way that make changes to the ispcp.conf file don’t stay if someone adds a new website or addon. Instead you must modify the following file to make it persistent. /etc/ispcp/apache/working/ispcp.conf
Now back to adding the top directive to the subdirectories.
***UPDATE: It seems that the previous practice I prescribed earlier has failed. When I added all of the info to the ispcp.conf, it gave me another Internal Error 500. This time it was saying a file was writeable by others. To compound the issue, it looks like Firefox and IE were both reporting Cached pages. I found a setting in IE to only pull fresh, new copies everytime. I figured a CTRL+F5 would give me a fresh copy. It looks like the solution was to add AddHandler cgi-script .pl .html Options +ExecCGI to the .htaccess file. But now when I add it to a subdomain I am back to the stupid issue with the internal error 500. I am going to bed.
Good Luck,
Mike