Unix Server EveryAuction Perl Script Installation Q & A

Ernie's EveryAuction Perl Auction ScriptsThis 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...

Home of Ernie's EveryAuction Perl Script Design Studio
Home of Ernie's EveryAuction Perl Script Design Studio

How to use your CGI-BIN

Before you try to understand the Content written below, I advise you strongly to click the link below and read this interesting Page:

http://www.ez-response.com/htucgi-bin/index.htm

Home of Ernie's EveryAuction Perl Script Design Studio

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.

Check in any case, if you are able to view imagefiles with extensions:

.jpg, .png, .gif

or different datafiles with extensions:

.txt, .dat, .feed, .log, .reg, .count, .cunter, .info, .htm, .html, .css, .store

If you are able to to get anything else but a (usually) "500 Internal Server Error" Page then contact your Hoster to get this Problem fixed fast. If he can't, you should move to another Hoster.

Where to place your CGI / Perl Scripts

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

- - - - - - - - - -

The path to Perl:

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.

Logically, the Server Perl Program Directory is, for Security reasons, not located "within your Access-Range", when you access your Server by FTP. The Perl Section of your Hoster may serve multiple hosted "Units", depending on how many hosted "Units" use Perl related Content anyway. Please be aware, that cheap Hosters usually do not tolerate active Auction Traffic on their Servers because of possible heavy Serverload.

The path to Perl on UNIX Systems is usually :

#!/usr/bin/perl
or:
#!/usr/local/bin/perl

or then even:
#!/usr/bin/perl5
#!perl
#!/usr/local/bin/perl5

If you are unsure but you don't want just to see a bloody 500 error page, you can have both lines in the script, like:

#!/usr/bin/perl
#!/usr/local/bin/perl

- - - - - - - - - -

Some Servers accept Perl Scripts only, if the Shebang  Line is written like:

#!/usr/bin/perl --
or:
#!/usr/local/bin/perl --

I found this info, trying to get an Auction Script to work for ntractorclub.com  within a socalled Sandbox-Environment  on a Go-Daddy Server, it's not officially documented either, but even on my Server, it's needed to work, if I add no specific options to the line.

---

The functional Sandbox-Lines mentioned above looked like:

#!/usr/bin/perl --
# $ENV{'SCRIPT_NAME'} =~ s/-bin\/sbox//;

- - - - - - - - - -

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.

The basepath defines, where the Server should find Content and Data without having the need to open an external Network or even http-connection just to reach access to Files located within it's own environment. This means, that, setting this important Path wrong, your Auction Script cannot set up, reach & handle Categories, User- & Item-Data, Images, e.t.c., and therefore not function.

The Basepath is, like on your Computer Harddisk, the Harddisk-Path from the "HD-Lobby" or "Root" to some Harddisk Sub-Directoriy, possibly containing all your "Server-Space" on that (Server) Computer-Harddisk. Your "Virtual Server" is actually nothing more than a Subdirectory of some Directories on a Harddisk of a Computer, containing your Pages, Images, e.t.c., and, eventually, in a cgi-bin Subdirectory, your Perl/CGI-Scripts.

Despite of beeing called like "http://www.whatever.com/cgi-bin/....", the "cgi-bin" Subdirectory is usually, at least on well configured Servers, for Security Reasons, not located within your "Web accessible" Server-Directories, but one Harddisk Sub below, and so within the "NON WEB ACCESSIBLE" Section of the Computer/Harddisk.

- - - - - - - - - -

So, typical Perl/CGI-File related (secure) Path's may look like:

$config{'basepath'} = '/home/www/web4/everyauction/cgi-bin/auction/';
or:
$config{'basepath'} = '/var/www/vhosts/everyauction.info/cgi-bin/auction/';

and typical Standard-File here an Image Path's may look like:

$config{'imagedir'} = '/home/www/web4/everyauction/public_html/auction/pictures';
or:
$config{'imagedir'} = '/var/www/vhosts/everyauction.info/httpdocs/auction/pictures';

bold - written Subdirectories are inside of the "WEB ACCESSIBLE" HTML-Section.

- - - - - - - - - -

Typical basepaths look like:

$config{'basepath'} = '/home/username/yourdomain/cgi-bin/auction/';
to set the basepath to the /cgi-bin/auction  - Main Section

a good place to store Scripts, User & Item Datafiles, Logfiles, e.t.c.

$config{'basepath2'} = '/home/username/yourdomain/html/auctiondir/';
set the basepath to the web-accessible /auctiondir  - Section

a good place to store Site-Images, Uploaded Customer Images&Thumbs, HTML- & Indexing Pages as well as possibly RSS Auction Feeds.

$config{'otherpath'}
$config{'secretpath'}

e.t.c.

- - - - - - - - - -

Using Unix Systems, a basepath may look like this:

/home/username/yourdomain/html/auctiondir

or in real phrases:

/home/vhosts/www.yourdomainname.com/html/auction

because Unix/Linux Disks are not named c: , d: ,   e.t.c.

the lowest access level of such a System is simply a plain "/"

- - - - - - - - - -

under Windows, you know already, a typical Harddisk Basepath would look like this:

c:\home\username\yourdomain\html\auctiondir
or in real phrases:
c:\home\vhosts\www.yourdomainname.com\html\auction

or then:
d:\home\username\yourdomain\html\auctiondir
or in real phrases:
d:\home\vhosts\www.yourdomainname.com\html\auction
e.t.c.

- - - - - - - - - -

So, the difference between a Path and a URL schould now be clear.
A URL does always include a "http://" - Statement, whereby "Path" are called by the scripts by "open" or whatever statements.

Examples:

$config{'cgipath'} = '/home/username/yourdomain/cgi-bin/auction/';

$config{'cgiurl'} = 'http://www.yourdomainname.com/cgi-bin/auction/auction.pl';

- - - - - - - - - -

Here are some Examples, but each script may vary, but this should provide you with some basic explanations:

$config{'basepath'} = '/home/username/yourdomain/html/auctiondir/';

..... or if you like to keep all script-related datafiles in the cgi-bin directory, use:

$config{'basepath'} = '/home/username/yourdomain/cgi-bin/auction/';

$config{'sitename'} = 'Your Nice Auction Title';

$config{'scripturl'} = 'www.yourdomainname.com';

..... or then something like:

$config{'scripturl'} = 'http://auctions.yourdomainname.com';

if you have your auction-url definded as Sub-Domain.

$config{'cgipath'} = '/home/username/yourdomain/cgi-bin/auction/';
$config{'cgiurl'} = 'http://www.yourdomainname.com/cgi-bin/auction/auction.pl';

$config{'auctiondir'} =  '/home/username/yourdomain/html/auctiondir/';
$config{'auctionurl'} = 'http://www.yourdomainname.com/auctiondir/';

$config{'htmldir'} = '/home/username/yourdomain/html/';
$config{'htmlurl'} = 'http://www.yourdomainname.com/';

$config{'imagedir'} = '/home/username/yourdomain/html/auctiondir/images/';
$config{'imageurl'} = 'http://www.yourdomainname.com/auctiondir/images/';

$config{'uploaddir'} = '/home/username/yourdomain/html/auctiondir/pictures/';
$config{'uploadurl'} = 'http://www.yourdomainname.com/auctiondir/pictures/';

$config{'thumbpath'} = '/home/username/yourdomain/html/auctiondir/pictures/thumbs/';
$config{'thumburl'} = 'http://www.yourdomainname.com/auctiondir/pictures/thumbs/';

Please make sure you read and understand the meaning of the above Lines before configuring the script.

- - - - - - - - - -

You are free to create and later use as many Basepath or Linkline Configurations as you like in order to refine certain programming, just make sure to use individual Names such as:

$config{'basepath'}
$config{'basepath2'}
$config{'basepath_img'}
$config{'basepath_secret'}

for Basepaths

$config{'uploadurl'}
$config{'uploadurl2'}
$config{'uploadurl_thumbs'}

for URL's

e.t.c.

- - - - - - - - - -

The path to Sendmail:

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:

/usr/sbin/sendmail
or:
/usr/lib/sendmail

Microsoft IIS Systems use:

$config{'mailhost'} = 'localhost';

- - - - - - - - - -

You cannot have UNIX & MS Settings active at the same time, therefore, you have to make sure to #QUOTE the line not active in your Script Config Section, or you have no Mails.

A typical UNIX/LINUX Setup would be:

$config{'mailprog'} = '/usr/sbin/sendmail';
#$config{'mailhost'} = 'localhost';

- - - - - - - - - -

A typical MS WINDOWS Setup would be:

#$config{'mailprog'} = '/usr/sbin/sendmail';
$config{'mailhost'} = 'localhost';

- - - - - - - - - -

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.

- - - - - - - - - -

Setting File Permissions:

To set file permissions:

1. Login with your FTP client
2. Open the directory where the file you wish to set permissions on resides
3. Right click on the file and select CHMOD
A box will appear

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.

- - - - - - - - - -

WARNING!

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.

Two typical CHMOD Windows are displayed below,  use the Chmod Calculator  to find out more about other possible settings if using a WS-FTP File Transfer Program.

Home of Ernie's EveryAuction Perl Script Design Studio

Right Mouse Click over clicked on Filename on Server activates CHMOD Option
 

Right Mouse Click over clicked on Filename on Server activates CHMOD Option

CHMOD 755

CHMOD 777

CHMOD 755 Command

CHMOD 777 Command

Home of Ernie's EveryAuction Perl Script Design Studio
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.

- - - - - - - - - -

The difference between ASCII and BINARY?

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:

.attach - .bak - .box - .cfg - .cgi - .cnf - .conf - .count - .counter - .css - .dat - .data - .dta - .feed - .flk - .hide - .htaccess - .htm - .html - .htmlt - .htpasswd - .idx - .info - .ip - .js - .lock - .log - .page - .php - .pl - .plate - .pm - .queue - .session - .setup - .shtm - .shtml - .skin - .store - .temp - .tmp - .track - .txt - .vote - .xml

If it detects one of these extensions, it automatically switches to ASCII mode. By Default, most of the well-known files to be uploaded in ASCII are already entered, however you can manually add additional extensions that you would like to transfer in ASCII mode by selecting the feature called Extensions. Here, you can any additional extensions that will cause the FTP client to toggle to ASCII mode automatically upon detecting an extension entered in its list. Remember, you must set your transfer mode to "Automatic" for this to work.

By Default, most of the well-known files to be uploaded in ASCII are already entered, however you can manually add additional extensions that you would like to transfer in ASCII mode by selecting the feature called Extensions. Here, you can any additional extensions that will cause the FTP client to toggle to ASCII mode automatically upon detecting an extension entered in its list. Remember, you must set your transfer mode to "Automatic" for this to work.
 

Uploading your files in the correct mode (ASCII or Binary)

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!

Manually modified Auction related files must possibly be saved as beeing UNIX-FORMAT Files before reuploaded to your Server
Home of Ernie's EveryAuction Perl Script Design Studio
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.

Cascading Style Sheets (CSS):

http://en.wikipedia.org/wiki/Cascading_Style_Sheets

CSS allows full control over the style of a hypertext (HTML) Document. Using CSS, you can control the Design of whole Pages, Table-Sections, Fonts and -Sizes, Colors, Borders, e.t.c. - e.t.c., enabling one to work faster and create professional and identical looking Pages and Sections easy. Today, its most common application is to style web pages written in HTML/PHP or to be used to work with Perl Scripts.
Advantage: Reduced Script Size, Clean Source-Code, and the Best, future Design Modifications are done for the entire Program by editing one or a few lines in the CSS-File.

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.

Home of Ernie's EveryAuction Perl Script Design Studio
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).

If it can't find index.html, on some Servers, it will simply list the entire web directory to everyone that access's it, which is a MAJOR security risk! So, ALWAYS, use an "index.html" file in any directory you create. In general, it's always a good idea to use index.html as your main page in all sub-directories, including image directories, of your Site. Forgetting to place an index.html in your root web, or any subdirectory of your web for that matter will possibly leave all of its contents viewable to the world. DO NOT install index.html files inside of your cgi-bin Directory as well as in it's Subdirectories.

- - - - - - - - - -

The EveryAuction 1.53 XL / XXL Versions do include the RSS Feed Creator  as well as the Search Engine Indexing Page Creator. This fine Addons create the index.htm file plus the feed.xml inside of the auctiondir Subdirectory:

$config{'auctiondir'} =  '/home/username/yourdomain/html/auctiondir/';
$config{'auctionurl'} = 'http://www.yourdomainname.com/auctiondir/';

http://www.yourdomainname.com/auctiondir/index.htm
..... meant to be the indexed Auction Link Page by Google , MSN , Yahoo , etc.

http://www.yourdomainname.com/auctiondir/feed.xml
..... meant to be the indexed Auction Link XML Page for RSS Feedreader Services

Home of Ernie's EveryAuction Perl Script Design Studio
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.

Home of Ernie's EveryAuction Perl Script Design Studio

Houston, we have a Problem...

... how do we find out about our Server?....

You can download a few Server Test Scripts. Use them at your own risk!  Adapt them to work by possibly editing the SHEBANG  Line, if needed. Then you should know everything important about your Server.

http://www.everyauction.info/info.zip  

- - - - - - - - - -

... the only thing we see is a 500 error Page or something similar....

Within the Script test phase, you always should have this below your SHEBANG  Line in your Auction Script. If Errors occure, they are, depending on the Server Setup, either displayed on the Screen or then registered in an error.txt file in the cgi-bin Main Directory.
---
#!/usr/bin/perl --
use CGI::Carp qw(fatalsToBrowser);
BEGIN { open (STDERR, ">error.txt"); }
---
You may save the error.txt File within the Server HTML Section in order to call it trough your browser by doing this:
---
#!/usr/bin/perl
#!/usr/local/bin/perl
use CGI::Carp qw(fatalsToBrowser);
BEGIN { open (STDERR, ">/home/vhosts/www.yourdomainname.com/html/error.txt"); }
---
or whatever your Server Basepath Name is.

DO NOT continue to browse, if you experience an error anywhere on an Script Page, regardles if the Error kills the whole Page or only some Part of it. Check your error.txt File FIRST, because if you contuinue browsing, the script my delete the error message and empties the file, as soon as it's been called to do another, possibly error-free routine.

Home of Ernie's EveryAuction Perl Script Design Studio
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.
Home of Ernie's EveryAuction Perl Script Design Studio

If you still don't understand what all this means , you probably need Assistance

Netmeter Internet Speed Test

CGI Resource Index Script Link Archive            NeedScripts.com Script Link Directory             scriptgateway.com Script Link Archive            Auctions Listed at CGIDIR.COM   Jacob Technology & Information
Copyright ? 2005 - 2009 Ernst (Ernie) Jacob, Jr.