CGI BIN

CGI-bin Applications

CGI stands for "Common Gateway Interface," a fancy name meaning computer programs running on the web server that can be invoked from a www page at the browser. The "bin" part alludes to the binary executables that result from compiled or assembled programs. It is a bit misleading because cgi's can also be Unix shell scripts or interpreted languages like Perl. CGI scripts need to be saved in ASCII format and uploaded to your server's cgi-bin in ASCII or text format. This is very important.

CGI, Common Gateway Interface, includes programs that run on the server to enhance the quality and functionality of a web site.    There are many resources on-line that allow the downloading of free cgi scripts.  

( For instance:  http://www.worldwidemart.com/scripts/ )
or ( http://cgi.resourceindex.com/Programs_and_Scripts/ )

We do allow running of cgi scripts on the server, however they must conform to our acceptable server resource usage policy. If we deem that a script is using an excessive amount of server resources, it will be disabled.  We do offer shell access to our servers for debugging or creating scripts-  you will need Telnet access.    We highly recommend that you setup Linux as a second operating system on your own workstation, as the more you familiarize yourself with this operating system, the better it will perform for you.  As often as possible, however, our web servers should be used only to upload the fully debugged final version of a cgi script so performance and uptime for other customers on the server is not compromised.

To keep our hosting prices as low as possible we do not keep a programmer on staff who can debug or install scripts for you. However we can refer you to a 3rd party programmer that can provide you that service for a fee if you need it. 

We have provided below some general information that will find helpful when installing cgi scripts.

Before a cgi script will work certain modifications must be made to them.  Certain paths must be specified in some scripts.    After the "#" in the first line of the perl script, the path to perl must be specified.  /usr/bin/perl should suffice for this path.  Below is a printout of a "whereis perl" from our system.

perl: /usr/bin/perl

Common paths sometime needed for cgi scripts:
Date: /bin/date
GNU Privacy Guard: /usr/bin/gpg
Sendmail: /usr/lib/sendmail
Perl5: #!/usr/bin/perl
perl: /usr/bin/perl
Serverpath: /home/username/domain-www/cgi-bin
Root path: /home/username/
(puts you in your the root of your account)
Domain directory: /home/username/public_html
(puts you in your public_html directory)
Cgi-bin path: /home/username/public_html/cgi-bin/filename
(puts you in your cgi-bin)
PHP4: #!/usr/bin/php

GNU Privacy Guard
Gnu Privacy Guard is an open source alternative to PGP. It's available at http://www.gpg.org .

Also, often you will need to know the exact physical path to your root directory on the webserver your account exists upon.  On our newer Linux servers, the path to your root directory is: /home/username/

Obviously, substitute "username" with the login you were assigned when you first received your account details.  Also, keep in mind that when you configure your CGI, that your /public_html is included in your path.  For instance, if you have a guestbook.pl script in your /cgi-bin, the exact physical path to that file is: /home/username/public_html/cgi-bin/guestbook.pl

The documentation of your program should tell you what lines that you need to changed in order to get your script up and running.

When you have all your modifications made you will want to save the file as a .pl or .cgi file.  (Make sure to use a plain text format.)  When you upload the file DO NOT upload in binary mode, instead using ASCII.    Uploading in binary will cause the server not to recognize the scripts as executables.  Most FTP clients will upload .pl or .cgi files in binary mode by default so you will need to change this.  You will need to upload your scripts into your cgi-bin.

Understanding File Permissions:

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:
The 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 similar to the one above 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. 

Apache suEXEC Support

The yougoweb servers are now set up with suEXEC wrapper!

CGI Scripting Notes 
We use the suEXEC wrapper that comes with Apache. This "wrapper" is a setuid-root script that is executed by the apache server, which will execute your CGI script. suEXEC does various security checks before executing your CGI script. If any of these checks fail, you're script won't be executed, and an error will be returned. 

The use of suexec is a good and wonderful thing. To take full advantage of it, file permissions can be optimized, replacing the more general defaults suggested in the install doc. For data files that normally require "766" permissions, use "744". Data folders that require "777" should use "755".

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 also allows full "READ, WRITE, and EXECUTION ability to the entire world!!!!  suEXEC will now take care of this problem!

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. 


New to cgi? Here is a page with questions and answers to numerous questions evolving around the inns and outs of using cgi within your scripts: http://www.w3.org/Security/Faq/www-security-faq.html 


Using Server Side Includes - SSI
SSI works in conjunction with a web page usually with the .shtml extension. The .shtml extension tells the server to do something different with the web page. When you append the .html or .htm extension, this tells the server to "read" the page only. The .shtml extension tells the server to "Execute" the page, in addition to just reading it. 

So, why would you want to execute the page? There are various commands you can program into a web page, which the server will look for and parse when the file is called as .shtml. In many cases, this mode is used in conjunction with Server Side Include (SSI) tags, to call a CGI script. For example, you have a visitor counter script, and we'll call it count.cgi. Every time someone visits your website, you want the script to be called, so that it logs the visitor into a file. 


To do this, you would place an SSI tag into your web page. The tag in this case, would look something like: 

<!--#exec cgi="/cgi-bin/count.cgi" -->

This small tag, which is hidden in the html coding of your page is telling the server to:

1. Go to the cgi-bin
2. Execute count.cgi

That's it! The information has been captured and processed by the count.cgi script. Of course, that's the short version of what happens. The long version would no doubt, would take us far beyond the scope of this document. 

PLEASE do not use the .shtml extension on "all" of your web pages unless it's absolutely necessary. With a busy web site, this means that every page must be executed, as opposed to just read. This as you can appreciate, can add considerable memory and CPU load to the system. As always, read the instructions that came with your script carefully. They should provide specific instructions on how to configure the script, as well as the SSI tag. 

Setting Permissions with the Cpanel File Manager

You can very easily change permission on your files in the File Manager option in your control panel.

If you go in to your file manager you can click on the file you want to change the permissions on. Then click on the Change Permissions in the right hand frame.

You then type in the permissions ie 775 or you can check the boxes. You can to it both ways.