CGI, PHP, & Databases
CGI stands for "Common Gateway Interface" which just means any web site that is automatically generated (as opposed to just being static) by the web server. A lot of times these CGI scripts use a database to create the web page.
- 1 FastCGI
- 2 Extra Web Security
- 3 What is your mod_perl policy?
- 4 What version of Python do you have installed?
- 5 What version of Perl do you have for your customers?
- 6 Do you have this perl module installed on your servers?
- 7 Do I have to put my cgi scripts in a special cgi-bin directory? Where is it?
- 8 Which plans include access to a cgi-bin directory (full cgi access)?
- 9 What is an internal server error, and why doesn't my CGI work?
- 10 Can I make my index page a cgi or php script?
- 11 What if I don't want .pl, .py, or .cgi files to run as CGI scripts?
- 12 Can I get such and such installed on the server?
- 13 Good resources for Perl CGI scripters
- 14 Common values needed in CGIs.
- 15 Do you support ASP?
FastCGI is a way to have CGI scripts execute time-consuming code (like opening a database) only once, rather than every time the script is loaded. To use FastCGI you will need to:
- Enable it in the control panel under Domains -> Manage Domains -> Web Hosting -> Edit.
- Make some minor changes to your scripts (detailed in the FastCGI article).
- Name your script with an .fcgi extension, or add the line "SetHandler fastcgi-script" to your .htaccess file.
See more in the FastCGI article.
Extra Web Security
The Extra Web Security option (you see it when adding a new domain or editing the web settings for an existing domain) enables the use of a special security module for your website.
Many common attacks that can compromise your website will be blocked by this option. We cannot guarantee that all attacks will be blocked but we will do our best to ensure the most common known attacks will be prevented.
A few specific web applications do not work properly with this option enabled, but most sites will work normally (but with extra security!). At this time, it appears that phpstats, some PHP-based BitTorrent trackers, and possibly some binary image upload scripts may not work. Solid components do not currently work when you have the extra security turned on. No other known problems exist.
FYI: checking this box enables the mod_security apache module on your domain.
What is your mod_perl policy?
We're sorry about this. There are several problems with allowing mod_perl in our shared hosting environment. mod_perl can hog too much memory if code isn't properly written. It has the potential to introduce a great deal of instability to our systems. We are not anti mod_perl - we use it extensively in our own web panel, however we don't feel that supporting it in a shared environment is scalable.
We are looking into ways to provide mod_perl with our shared hosting offerings in the future, but do not currently have a time line in place.
What version of Python do you have installed?
All of our machines should now have (as of the time of writing) 2.3.x as default, as well as 2.2.x installed as python2.2 and 2.4.x as python2.4.
machine# python -V Python 2.3.5 machine# python2.4 -V Python 2.4.1 machine# python2.3 -V Python 2.3.5 machine# python2.2 -V Python 2.2.3+
What version of Perl do you have for your customers?
Currently we have Perl version 5.8.4 installed on all our servers.
Do you have this perl module installed on your servers?
Most likely we do! Check the list of perl modules we usually have installed by default on all of our shared hosting servers (although inconsistencies occasionally happen).
You can test whether a perl module is installed by typing "perl -MThe::Module::Name" at the commandline (without quotes). If you don't get an error message, that module is installed!
If the one you need isn't there, please let tech support know (don't just post a comment on this page!) and we'll add it, usually in a very short amount of time!
Do I have to put my cgi scripts in a special cgi-bin directory? Where is it?
NO! If you have cgi access enabled, any script with a .cgi or .pl extension will be recognized by the server to be a cgi script and does NOT have to be in a special directory. The only restriction is that you need to place those files under your domain directory. You can put them in a directory named "cgi-bin" if you'd like of course! (examples: /home/youruser/yourdomain.com/blah.cgi or /home/youruser/yourdomain.com/cgi-bin/blah.cgi) Just be sure to tell your FTP client to upload them as ASCII files or they won't work!
Which plans include access to a cgi-bin directory (full cgi access)?
All our plans do! You don't need to put cgi scripts in any special directory on our servers, either.. just make sure the files have a .cgi, .pl, or .py extension (php scripts should have a .php, .php3, .php4, or .phtml extension)! If scripts aren't being run from the web, but are just showing their source code instead, you may have CGI turned off for that domain!
To turn it on, simply go to the Domains > Manage section of our web panel and click the  link to the right of the "http" service for the domain you're having trouble with!
What is an internal server error, and why doesn't my CGI work?
I've set up a couple of CGI scripts that I call from one of my pages, but it always returns a message saying 'Internal Server Error'. It doesn't actually seem to do anything. What do I do?
A CGI is a program or script that interfaces with the web server in order to provide some sort of extra functionality to a web site. Some CGIs provide counters or guestbooks, while some of the more ambitious ones provide feature-rich bulletin boards or search engines for your site's visitors. CGI is one of the most powerful tools you can use to create a professional, dynamic web experience for your target audience.
One very common problem when setting up a CGI is the error message 'Internal Server Error'. This is a generic message meaning that somewhere along the line, the script or program being run could not successfully complete the task.For Perl scripts (the most common way to write CGIs), this can be one of a few things:
- Often, scripts edited on Macs or Windows-based PCs will contain carriage return characters, which the Perl executable does not deal well with.
- Also, any syntax error or mistake in the program's code which does not allow it to execute properly will result in this error.
The best way to debug any CGI is to run it from a command line by using telnet to log onto the server, changing into the directory which the CGI resides in, and running it. For example, typing this:
perl scriptname.cgi (only with Perl scripts)
...will run the CGI and return whatever is meant to be sent to the user's web browser (usually a messy glob of HTML tags).
If you run a Perl script which is unable to be interpreted successfully, you will often receive a message stating the general problem and the line number it occurs on. Usually it is best to fix the first error that comes up, as that will often help with errors that occur further down the script.
Some scripts require input to function, usually provided by an HTML form. Since debugging from the command line does not provide you with such luxuries, you will be prompted for name and value pairs instead. Specify these on a separate line per pair, with an equal sign between the name and value. We suggest that value strings be wrapped in quotation marks. After the last line, hit the return key and then type control-D, which will run the script with those values. For example, these are three valid name/value pairs:
nameone="valueone" nametwo="valuetwo" namethree="valuethree"
Carriage Returns In Perl Scripts
Perl scripts in particular will occasionally mention a problem caused by carriage returns within the script. Perl has problems executing files with carriage returns, which are usually caused by scripts being edited in many Mac or Windows PC based text editors (which natively use carriage returns to mark line endings).
Another problem is the WebFTP text editor available in your Dreamhost panel. After editing a perl script in WebFTP, it will have DOS carriage returns and will no longer work. Do not use Dreamhost's WebFTP to edit your perl scripts. WebFTP is EVIL!!!!
The quickest way to fix the problem is to open the file up in pico, a Unix/Linux based text editor, and resave it. To do so, type this into the command prompt while in the same directory as the script:
(replacing 'scriptname.cgi' with the name of your script)
This will open up the file in pico. Now, make a minor change (such as adding a space) and erase it. Then, quit pico and save when prompted by typing control-X. When pico saves files, it strips them of carriage returns.
However, this will only fix a single file. In the long term, you should find a text editor that gives you an option to save with 'Unix-style' line endings. For the Macintosh, Bare Bones BBEdit (or the free BBEdit Lite) is regarded as the best text editor to use.
For Windows-based PCs, a popular text editor that many use is Allaire HomeSite (now by Adobe). A trial version is available here:
For the BeOS, a very well done text editor called 'Pe' is available. Those familiar with BBEdit for the Macintosh will feel right at home using this top-notch text editor.
Good text editors are available for just about any platform. If you need help finding one, please let us know.
Text Encoding Issues
If you save a perl script using BBEdit with a Unicode encoding, it will write add three bytes at the beginning (such as 0xefbbff), before the shebang, to identify the encoding. This is called a byte order mark (BOM). The system will barf on this and give a server error. Solution: In BBEdit's Save panel, click button Options and in the Encoding popup select an encoding that has "No BOM".
Special considerations because we run suexec!
Normally on a web server, CGI scripts run as the special unix user nobody in the group nogroup. That means that in order for the cgi to write or read files, they must be readable or writable to the world. This isn't really that safe, since that means any other user on your server can read and write those files too!
On DreamHost servers, we have a special feature called suexec (which stands for "switch user execution") turned on that makes your CGI scripts on your web site run as though they were run by your user and group!
As a security precaution, suexec REQUIRES that all cgi scripts AND THE DIRECTORIES IN WHICH THEY RESIDE *NOT* be writable by anyone but the owner user. Otherwise, another user on your machine could go into the directory, edit your script to do something, then visit it from the web and they would then have access as though they were you! Then, they would essentially have full access to your user account, and that's bad!
SO, suexec requires that you change the owner (chown) and change the group (chgrp) to be your primary user and group (don't worry, these are the defaults when you upload or create a file), AND that you chmod (change permissions) that file AND THE DIRECTORY it resides in to be not-writable by the world. If the containing directory is owned by a supplementary group, your program will not run. You can do this with the
- chmod 755 filename.pl
command. You do NOT want to do chmod 777 filename.pl, even if your scripts' installation instructions tell you to do that. They don't know that you're installing your script on a server with suexec installed.
The various chmod modes are fairly complicated, but there is a good explaination of the chmod command which you can view here:
http://www.analysisandsolutions.com/code/chmod.htm So if you've tried everything else above, and your script keeps giving a 500 error (Internal server error), and ESPECIALLY if it worked before on a different (non-dreamhost) machine.. directory and file permissions may be the problem!
Check the error log!
tail -f /home/username/logs/domain.com/http/error.log
a line like this:
[Wed Mar 12 11:26:42 2003] [error] [client 126.96.36.199] Premature end of script headers: /home/username/domain.com/perl/helloworld.pl
would indicate the the script headers:
Content-Type: text/html; charset=ISO-8859-1
aren't being printed correctly. here is a basic working script:
#!/usr/bin/perl use CGI; my $query= new CGI; print $query->header; print "hello people in my head\n";
Can I make my index page a cgi or php script?
Yes. Simply name the file 'index.cgi'.
You can also have a php script be your index page by naming it "index.php" or "index.phtml" or "index.php3" or "index.pcgi"!
Just make sure that you don't also have a file named index.html in the same directory, because the server will use that one instead!
What if I don't want .pl, .py, or .cgi files to run as CGI scripts?
If you'd rather have .pl, .py, or .cgi files displayed in the browser rather than executed as scripts, simply create a .htaccess file in the relevant directory with the following content:
RemoveHandler cgi-script .pl .py .cgi
If you're using ssh to connect you can create the .htaccess file by running the following command:
echo "RemoveHandler cgi-script .pl .py .cgi" > .htaccess
Can I get such and such installed on the server?
As long as what you are installing does not use excessive resources, there should be no problem. Our support staff is very knowledgeable and will do their best to assist you if you have trouble installing something.
Good resources for Perl CGI scripters
I understand that you recommend Perl for writing CGI scripts and 'web applications'. Where should I go to get started?
Perl is by far the most common language used to write CGI scripts. A fairly easy learning curve, coupled with tons of freely available source code, make it a perfect choice for the beginning (and advanced!) web coder. One of its greatest strengths is that the language was written with text processing in mind. Given that the web is almost nothing but text, it's a perfect match.
You can download the latest version of Perl at the official Perl site: http://www.perl.com
This site also contains a lot of great general information about writing Perl and Perl CGI scripts. There are also numerous online tutorials and books available to help you get started.
But what if I just want a script to install and start using it right away?
DreamHost has a number of pre-written CGI scripts available at no cost, including forms and counters. See the Related Links in the column to the left for more information.
The sites below offer numerous scripts that you can use with a CGI-enabled Dreamhost account. Some are better than others, so you should shop around before deciding on a given script.
Note: Although we will attempt to help with generic CGI problems you have, we do not provide technical support for any external scripts/CGIs. We'll help if we can within reason, but we can't guarantee that any given script will work with our servers. If you need help installing or debugging a certain script, we can do so at extra cost.
- Why won't my Perl script run? How to fix common problems
- The CGI Resource Index
- Bandley3 CGI & PHP Scripts (Hosted at DreamHost!)
- The CGI Collection
- Web Bazarr Perl Scripts
- PerlCrawler (Perl search engine)
These are scripts specifically for running CGI based message boards on your site. Each have somewhat different feature sets and requirements, but all work fine with our servers.
- UBBThreads (Requires MySQL, $229 a license)
- GossamerForum (Requires MySQL, $200 a license)
- YaBB (No MySQL Needed, FREE)
- Discus (No MySQL needed, FREE [$150 for Discus Pro])
- IkonBoard (MySQL optional, FREE)
Common values needed in CGIs.
Many CGIs and Perl scripts require different utilities to function. For example, a guestbook may want the path to the Unix/Linux 'date' program, whereas another may want to know what the root of your account is. Here are some values that you may find useful and/or necessary in order to work.
The sendmail executable can be found at the following path:
The date executable can be found at the following path:
The Perl interpreter, needed at the beginning of your Perl scripts, can be found at either of the following two paths:
You can find Python here:
The root directory of your account can be found at the following path, substituting 'username' with your username.
Root Directory Of Web Site
The root directory of your web site is usually stored within the root directory of your account, and is almost always named the same thing as the domain or subdomain it is hosted under (ie. 'mydomain.com' or 'subdomain.domain.com'). For example:
This is also the path of the directory in which you should place your files for any given site.
Dreamhost does not use a standard CGI-BIN, but rather allows you to place executable scripts anywhere within your account and achieve the same functionality. Simply create a directory somewhere within your account and put your scripts there, then use the 'pwd' command while within that directory to get its pathname. This is what you would use within your script's configuration when asked for a path to the CGI-BIN.
A potentially useful way to find out why your script isn't working is by looking in your site's "error log". This is located inside your home directory in the following directory:
By looking at the last line of the error log you may get an idea why your script is giving an Internal Server error..
Do you support ASP?
Currently we do not support ASP, as we run only Linux servers (Debian), and ASP is a Microsoft technology. If you need support for ASP, we recommend either finding a hosting provider running Microsoft boxes or re-writing your scripts into PHP. Actually, we don't really recommend the first one; that is merely presented as an alternate option.