| ||||||
 | ||||||
| ||||||
| ||||||
Before you try to understand the Content written below, I advise you strongly to click the link below and read this interesting Page: | ||||||
| ||||||
|
Where to place your CGI / Perl Scripts: Although
there is nothing dangerous about placing cgi scripts in random
directories throughout your site by an experienced Security Expert, most Server Hosters do even not allow the Use of CGI/Perl Scripts within the HTML-Sections by turning Apache's CGI Wildcard Setting to the "off" Position. For you, it's always best to keep your important Auction raleted Data Files in their own Place known as the "cgi-bin". This minimizes Security Risks and allows you to maintain your CGI/PERL programs from one Main Directory. The big advantage is, that even simple .txt-files stored within the CGI-BIN
Section cannot just be called or viewed by Visitors, so enhancing your Script & Site Security very much. At least, if you are served by a responsible and qualified Hoster. | ||||||
|
| ||||||
|
Most FTP programs look somehow similar, the picture above display's the content of a "Virtual Server" Root by using "WS-FTP". The "Server Root" is the "Bottom Directory" of your Site-Directory. As you see, there are several Subdirectories, but they areat the moment of no importance to you exept for the "cgi-bin" and the "httpdocs" Sub, because they both are used to place your Auction-related Files.
The Server Root is not accessible via Webbrowsers, e.t.c. The "cgi-bin" Directory contains all your PERL/CGI-Scripts and usually script-related Data-Files, but it does (or should) not contain "HTML"-Pages, Images, CSS-Files, .js-Scripts, e.t.c., but as explained above, it can contain certain Data-Files with certain extensions. On professionally configured Systems, such restrictions are usually set well in order to pevent unauthorized Access. Depending on the Configuration, the "cgi-bin" Section is therefore a secure place to store confidental Auction Data such as User & Item Registration Files, Contact Information, Feedback, Logs, e.t.c. - - - - - - - - - - Standard HTML / PHP File & Image Directories: For HTML or PHP Pages, Images, .js-Scripts, CSS-Files, e.t.c., the"httpdocs" Directory is the MAIN BASE of your Website. Be aware, on your virtual Server, this "httpdocs" Directory could carry another Name. So don't get mixed up, read the Info your Hoster sent you, if you find no "httpdocs" Directory. Or your Hoster will likely tell you how it is called. This Directory is "Web-Accessible", meaning, that Visitors access (usually) this Directory whenever calling your Site under "http://www.whatever.com". All of your HTML-Pages, PHP-Pages, Images, .js-Scripts, CSS-Files, e.t.c., are located in this Directory or in one of it's Subdirectories | ||||||
|
- - - - - - - - - - One of the first things you must do when configuring a script, is set the correct path to the Perl interpreter, which is the engine responsible for processing the script. The path to Perl on UNIX Systems is usually : #!/usr/bin/perl #!/usr/bin/perl -- Setting directories within your EveryAuction 1.5x Perl Auction Script: When you configure a cgi script for "any" server, it may ask you to set variables such as the base, relative, and CGI directory/url settings. $config{'imagedir'} = '/home/www/web4/everyauction/public_html/auction/pictures'; - - - - - - - - - - $config{'basepath'} = '/home/username/yourdomain/html/auctiondir/'; Some programs such as the ones, which send email will need to know where the Sendmail program resides on the server. The script will typically have a setting like this: $mailprog = '/usr/sbin/sendmail'; and will want you to set it appropriately. Sendmail on UNIX Systems is usually: Understanding UNIX / Linux Server based File Permissions: On UNIX Server Systems, there are a number of file permissions, which can be used for a variety of different purposes, however we'll limit this tutorial to the ones most commonly used. To begin with, it's important you understand the three categories of permissions, which are: Owner Permissions: The owner is you. In most cases, this is not so much of a concern, as you can only obtain owner permissions in one of two ways. 1. FTP into your account using your Username and Password. 2. Login via Telnet with the same information. Group Permissions: This represents a group of users who have access to a particular directory. For example, a password protected directory, whereas only members can access it upon providing the correct Username and Password. In this case, any permissions you assign to "Group" would be applicable to users with access to that particular directory. Public Permissions: This is the
most important one of all. Public permissions determine what your
world wide visitors can and cannot do with your files. ALWAYS make
sure you understand what a particular permission does before
assigning it to a file. If not, you may wakeup to find your website
demolished by some clown who was snooping about and gained access to
your files. To set file permissions: 1. Login with
your FTP client Observe how you can "select" the individual permissions you want, or simply enter the 3 digit number if you know what it is. Most instructions included with downloaded scripts will tell indicate this to you. By default, all files uploaded to the server automatically have permissions set to 644. The setting 644 is relatively safe, as it provides "Read" and "Write" access to the owner, while limiting the rest of the public to "Read Only" access. When setting permissions for cgi scripts, the most common permissions setting is 755. 755 allows the owner "Read and Write" access, while allowing the Group and Public "Read and Execute" permissions. So what are we actually saying? In short, when users access your cgi script, the server has been instructed to grant them permissions to "Read and Execute" it. Sound scary? It's not actually? Remember that
a script is a program that must be processed by the server. As long
as the script is written properly, you can safely allow users to
execute it, and thus providing the desired results. For example, if
they wanted to post a message to your wwwboard discussion forum,
then they would need these permissions to execute wwwboard.pl, which
would write their new message to an html file, which is displayed on
the main forum. The new message would reside in a directory on your
site so other users could view it. Most cgi, perl and other scripts
you'll be installing come complete with instructions telling you
which permissions you'll need to set them to. Setting permissions on files is a relatively simple task, however MAKE SURE you fully understand what it is you're allowing the public to do with your files. For example, some less experienced users often make the fatal mistake of simply setting ALL of their files to 777. While 777 will automatically allow executing privileges, it possibly also allows full READ, WRITE, and EXECUTION ability to the entire world! This is how web sites get hacked! While most visitors have good intentions, all it takes is one person whom snoops about your files seeking an Open
Back Door. This could result is them gaining full access to your
directories, which means they can do anything from deleting your
entire site, to defacing it with obscenities. | ||||||
 |
||||||
| ||||||
Right Mouse Click over clicked on Filename on Server activates CHMOD Option
| ||||||
|
||||||
| ||||||
| Uploading your files in the correct mode (ASCII or Binary)? Uploading in the wrong format for images or binaries will result in a strange mess appearing in place of the file. For CGI scripts, this mistake has to be the most common cause of that annoying error known as the (Server 500 Error - Malformed Headers), or something to that lovely extent. While this can be the result of many various programming errors, the most popular amongst new users are uploading their scripts in the "WRONG" format. Your cgi scripts MUST always be uploaded in ASCII mode. Alternatively, if you upload an image or .exe file, it must be done in BINARY mode. - - - - - - - - - - In short, html or text based files are supposed to be transferred in ASCII mode. Uploading them in Binary mode will append ^M's to the end of every line. In most cases, this is OK, with html files because your browser will ignore them. BUT, with other text files such as cgi scripts, uploading them in binary will damage them, thus causing a (server 500 error). This is because binary mode has added ^M's to the end of every line, which are not supposed to be in the program. This of course, is what causes the additional message of (Malformed Headers), which often displays at the bottom of the Server 500 message when a CGI script has crashed. Once again, BINARY mode is used for transferring executable programs, compressed files and all image/picture files. If you try to upload an image in ASCII mode, you observer a strange mess appearing on the page where the image is suppose to appear. ASCII mode in this case, has corrupted the binary coding in the jpeg or gif image. If this happens, just re-upload it in the Binary format. Setting your FTP client to automatically detect ASCII and Binary file transfers: Most FTP programs have "AUTO" mode, which will tell the FTP client to automatically detect the file type you're transferring and will select the appropriate mode. By default, most FTP programs will attempt to transfer everything in binary mode, but when "Automatic" is selected, the FTP client will check a list of known ASCII extensions, for example: | ||||||
| ||||||
You may run into problems if you download EveryAuction-related Data-Files (!!NOT xyz.pl or xyz.cgi Scripts!!) for manual modification, because, depending on the Server Setup, such Files need to be saved locally as beeing UNIX-FORMAT Files, not regular Ascii-Text Files, in order to function again in read/write Mode on the Server. File-transfer should still be made in ASCII Modus. I happen to have moved my Site to such a Server, so I figured this out rather soon! | ||||||
 | ||||||
| ||||||
| File types and what they represent: Various file types can effect both the behaviour of your files, as well as how the server treats them. While there are numerous file extensions, which represent a host of various file types, we'll stick to the basic ones in this quick overview: The .html file: This is one is the most commonly used and the most one of you are already familiar with. Html stands for (Hypertext Markup Language). Essentially, it tells the server, as well as the clients browser to process and display the .html coding in a way, which is meaningful to the end user through a browser. The .htm file: Many of you have probably noticed this newer extension appearing in place of the traditional .html one. In short, .htm is most often created, and or generated from the Microsoft FrontPage web editor. The two are essentially the same and provide the same basic purpose. Unless you're using FrontPage, you will probably use the .html extension at the end of your web pages. The .gif and .jpg file: Most commonly used because of its good compression in web page images. Generally, .gif files are the fastest loading, as they remove a lot of information, which is not required to maintain image integrity, but to a point however. .jpg will allow more flexibility in compression and quality settings, however can also result in larger files. The .cgi and the .pl file: .cgi and .pl are most often used for perl scripts. Perl scripts are small text based programs, which are executed on the server end, and will perform a host of interactive functions for a web site. In short, when a .pl or .cgi file is called, it tells the server to process it using the Perl Interpreter. The Perl Interpreter understands the programming within the script, and will perform the set of sub routines, which will yield your desired effect. This desired effect could be anything from a simple web page counter, to more complex programs such as discussion forums, e-commerce platforms, to online auctions. In many cases, you can download these ready to go scripts for free, and in others you may have to purchase them. | ||||||
| ||||||
| index.htm(l) and why you should use it:
This again is where a number of newer webmasters become stumped. They upload all of their files and directories, and then want to access them with their browser, but forgetting to create their welcoming page as index.html, so here's what happens: They access their site as http://www.mydomain.com or using the associated IP number, for example, http://66.97.3.95/~username, and what they see is their entire file directory structure! Yikes!? It looks just like exploring the C drive on your computer! You don't want visitors seeing that, do you? When you access your site by calling it as http://www.mydomain.com or the assigned IP (for example), http:// 66.97.3.95/~username, the web server looks for something called "index.html","index.htm","index.php","index.cgi","default.htm", beeing the "default" file to be
sent to visitors, if they do not specify a file name. Thus this is why "http://www.mydomain.com/" called by itself will automatically display the home or welcoming page, whenever a
domain or directory is called without a filename appended to it such
as this, http://www.mydomain.com/whatever.htm(l). | ||||||
| ||||||
| Understanding case sensitivity: Another small detail, which can throw many newer users into a tailspin. Unlike your local PC or Microsoft's IIS Servers, the Unix file system is very particular about UPPERCASE and lowercase file names. Therefore, if you were to install a script, (let's say the auction.pl for example), the name of this script would be auction.pl. If you name a file picture file called me.jpg, then this is what you must call it as. Naming it me.JPG for example, (observe the UPPERCASE) tells a Unix web server to treat it as a totally different file name. Unix file servers are exceptionally fussy on this issue, so make sure you pay close attention to case when uploading files, or installing and configuring cgi based scripts. The same rule applies for all files including your .html pages. Again, the server treats .html and .HTML as two entirely different files. Want to keep in simple? Try to stick with lowercase letters in all file names and extensions. |
||||||
| ||||||
|
Houston, we have a Problem... - - - - - - - - - - | ||||||
| ||||||
|
Common Perl / CGI Script Errors: Find the Apache Server Status & Error Codelist here A. Error 404 File not found The URL address you put in your browser is wrong. Check the web site address and the folder name as well as the script name. Remember this is case Sensitive. An occasional, if rare error, is if you have created a cgi-bin of your own in your web space however the server may ignore this and use it's own cgi-bin you have not got access to. B. Error 500 Internal Server Error The Path to Perl or CHMOD of your file or directory may be wrong. Try CHMOD all the files and the directory again. Your server may not like the CHMOD setting ask you hoster what you should be using. Check that you did not open & save the script with anything other than notepad or a similar TEXT Editor. Check your log to find out more. Also try putting the code below directly after your Path to Perl. This will stop and report the script error in more detail. --- use CGI::Carp qw(fatalsToBrowser); BEGIN { open (STDERR, ">/home/vhosts/www.yourdomainname.com/html/error.txt"); } --- or whatever your Server Basepath Name is. C. Error Premature end of script headers The CHMOD of your file or directory may be wrong. Try CHMOD all the files and directory again. Check you did not open & save the script with anything other than notepad or some similar TEXT Editor. D. The Script just opens so I can see the Source Code Some servers do not like .pl, try changing it to .cgi and some servers don't like .cgi so try changing to .pl. Remember to CHMOD the file again, usually to 755! E. Error Can't open file The file has been found on the server, but the script has not got permission to open it. Check you CHMOD on all the directories and files. F. Error Can't create file The script is trying to make a database but has not got permission to do so. Check your CHMOD Settings on all the directories and files. If you have uploaded a database already, the path may be wrong that is why the script has decided to make the file. | ||||||
| ||||||
|
If you still don't understand what all this means , you probably need Assistance |
This Page contains information on Installation & Troubleshooting of Perl Scripts, collected from many sources as well as from personal Experiences. I am glad to share what I've learned, just take into account, my english is self-teached only...
Zero Tolerance on
