Thursday, July 24, 2008
Information On Perl
Q: What version of Perl does Hostwire use?
A: Hostwire is currently using Perl version 5.x.
Q: Does Hostwire frequently upgrade Perl with new build releases?
A: Yes. Once a new build of Perl has been deemed as stable versus experimental, Hostwire will promptly upgrade to this version of Perl.
Q: What are the absolute paths to Perl on the webservers?
A: Below are all of the current absolute paths to Perl on all webservers:
/usr/bin/perl
/usr/bin/perl
Q: How should I set my file permissions on a Perl script?
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!
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!
Q: What are the correct file extensions for Perl scripts?
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.
Q: Should I upload my Perl scripts in ASCII or Binary mode?
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!
Q: How do I execute my Perl scripts through Telnet/SSH?
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.
Q: Can I use a "cgi-bin" on my account for my Perl scripts?
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.
Q: Do my Perl scripts have to reside in a certain directory, such as the "cgi-bin"?
A: Yes. This is the ONLY location where cgi scripts will execute. Place all of your cgi scripts in the "/var/www/cgi-bin" (mainsitecgi) directory.
Q: For debugging purposes, should I execute the script through the web or SSH?
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.
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.
Q: Are there a list of steps for debugging my Perl script(s)?
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 Hostwire:
If the error "Command not found." is returned at the prompt, do the following:
- Gather Information about the Problem
- Execute the Perl script through the command-line.
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.
- 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.
Q: How do I invoke the Perl source debugger?
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.
Through the command line, issue "perl -d " to execute your Perl script with the Perl source debugger.
Q: Do my Apache error_logs contain any useful information?
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.
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.
Q: Are there other places to turn for help?
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/
http://www.dejanews.com/
http://www.webdeveloper.com/categories/cgi-perl/
http://language.perl.com/
