A: Often times, permissions are set very leniently in order to avoid any permissions problem. This is not a good idea. Your Perl scripts should have the appropriate permissions depending on the function of that particular script.
First, all scripts should be set to the owner (you) having read, write and execute privilege (rwx) regardless of the function of the Perl script.
Next, you should ask yourself if you want people (visitors) to your website to be able to execute the Perl script. This is most likely the case. Under these conditions, your script would be set to world readable and executable (r-x). Do not give the world write permission on the Perl script! It is not necessary and may lead to problems!
If your script is not going to be executed through the web and only you will be executing the script through Telnet (there are various reasons for having a script operate under these conditions), then you set the script to no world permissions (---).
The group permissions should be set to read and executable (r-x) if the script is to be executable via the web. Otherwise, set your group permissions to nothing (---).
With this information, you have the following permissions breakdown:
Executed via the web by anyone: chmod 755
Executed by only yourself through the command line: 700
Often times, a Perl script will open a file for writing. This is the case in guestbooks and bulletin boards, where the information is received from the form and written to a certain file. The permissions of this particular file are now important.
Many times, the author of a Perl script you use on your account will require you to set this file to rwxrw-rw-, or chmod 766, which allows write access to the world. This is not a good idea and is unnecessary.
Files that need to be written to by way of a Perl script can be set to the default permissions of rw-r--r--, or chmod 644. This will work fine with our setup.
Finally, never set your file permissions to rwxrwxrwx, or chmod 777. This is not necessary, may cause a security problem on your website, and will cause your Perl script to not execute at all!
A: Your Perl scripts can have the extension .pl or .cgi. However, Perl scripts that are going to produce output to the web (world readable) would use the extension .cgi. Perl scripts that are only meant to be executed by yourself via the command line or even scripts which may be executed through the web without any output should be set to the .pl file extension.
A: You should always upload your Perl scripts in ASCII mode via FTP. If you upload your scripts in binary mode, the scripts will not work and you will get an "Internal Server Error: Premature End of Script Headers" error (500 Internal Server Error). It is very important to remember to only upload your Perl scripts in ASCII mode!
A: Issue the command "perl " from the command line, where "scriptname" is the relative or absolute path to the Perl script. If problems with the execution of the script are encountered, they will be reported on the terminal by the Perl Debugger.
A: Yes. In fact, a cig-bin is already configured for you in the "/var/www/cgi-bin/" (mainsitecgi) directory. This is the only location where cig scripts will execute.
A: SSH. You will get much more information about the cause of the problem through the command-line than through the web. Below is an example:
Case I: We execute the Perl script through the web and get the following error: "Internal Server Error: Premature End of Script Headers". Given this information, we know the problem could be with the permissions, a syntax error, or the process was killed.
Case II: We execute the Perl script through the command-line and receive the following output: syntax error at ./script.cgi line 9, near "@list shift" Execution of ./script.cgi aborted due to compilation errors.
Which method yields the most useful information? SSH. We now know that the problem is a syntax error on line 9 of the Perl script, versus the "could be anything" problem we receive through the web.
A: Below is a list of steps to go through to troubleshoot any problematic Perl scripts. These are the same troubleshooting methods employed by the technical support repetitive at FullServeHost.com:
Gather Information about the Problem
Execute the Perl script through the command-line.
If the output indicates a syntax error with the Perl script. The problem has been identified as a problem with the code in the Perl script.
If the error "Command not found." is returned at the prompt, do the following:
Check the permissions on the actual Perl script. Must be executable!
Retry. If it still fails, then check the permissions on all directories leading up to the Perl Script. They must be set to rwxr-xr-x, or chmod 755.
If the script will execute (possibly return HTML output) through Telnet, but still gets an "Internal Server Error" through the web, do the following:
Ensure that the file permissions are set to rwxr-xr-x, or chmod 755.
Ensure that the file permissions are not set to rwxrwxrwx, or chmod 777.
At this point, you must know the source of the problem, whether it be a permissions problem or a syntax error within the Perl code itself. Now all you must do is fix it!
A: The "-d" flag will invoke the Perl source debugger and should be used when you have tried all other troubleshooting techniques and are still confused. This program is very good with identifying syntax errors.
Through the command line, issue "perl -d " to execute your Perl script with the Perl source debugger.
A: It depends. When a Perl script encounters an "Internal Server Error" for whatever reason or a "Forbidden" message when executed via the web, useful information is logged to your error_log, located in your logs directory.
When you execute Perl scripts through the command line, any errors encountered are not logged to this file. The usefulness of this file applies only to the execution of Perl scripts through the web.
A good technique is to open a SSH session and issue the following command:
"tail -f /var/log/httpd/error_log"
Be sure to omit the quotation marks! What will happen is you will see all information being written into the error_log in real-time. Therefore, you can execute a troublesome Perl script through the web and refer to your Telnet session immediately to see any useful information placed in your log file.
A: Yes. Because of its widespread popularity, there are many places on-line that have valuable resources for troubleshooting Perl scripts. Below are some of the most useful resources:
http://www.dejanews.com/
http://www.webdeveloper.com/categories/cgi-perl/
http://language.perl.com/
