Document Actions

Web Hosting & CGI Access


The College of Computing provides the following web and cgi servers for different purposes.

  • EXTERNAL SERVERS:

    NAME MACHINE USE TYPE URL DIRECTORY
    www.cc.gatech.edu
    (www3.cc.gatech.edu)    		 rhampora Sun Solaris 7 External WWW server
    with SSI and mod_ssl    		 HTML http://www.cc.gatech.edu/... /net/www
    cgi3.cc.gatech.edu rhodia Sun Solaris 7 External CGI server
    with PHP4    		 CGI
    PHP
    		 http://cgi3.cc.gatech.edu/cgi-bin/...
    http://cgi3.cc.gatech.edu/php/...
    		 /net/cgi3
    /net/php3
    qtss.cc.gatech.edu nishaya Apple Macintosh with
    QuickTime Streaming Server    		 QuickTime rtsp://qtss.cc.gatech.edu/... N/A

  • INTERNAL SERVERS:

    NAME MACHINE USE TYPE
    		 URL
    		 Directory
    www3-int.cc.gatech.edu/
    cgi3-int.cc.gatech.edu
    		 terel Sun Solaris 7 Internal Web and CGI server
    with SSI, mod_ssl, ApacheJServ 1.1.2 (JDK 1.3)
    and PHP4    		 HTML
    CGI
    PHP
    SERVLETS

    		 http://www3-int.cc.gatech.edu/...
    http://cgi3-int.cc.gatech.edu/cgi-bin/...
    http://cgi3-int.cc.gatech.edu/php/...
    http://cgi3-int.cc.gatech.edu/servlets/...
    		 /net/www3-int/
    /net/cgi3-int/
    /net/php3-int/
    /net/servlets3-int/


Restrictions on CoC External CGI server

The College's external web server is a strategic part of the college and is required to be stable. The external cgi server is separate from the external web server so that a rogue CGI program can't take down the entire web site. Because of the cgi security vulnerability, we cannot have people developing cgi programs on the external cgi server. Therefore, we provide our internal server for people to develop and test their cgi programs. The internal server is accessable only within the Georgia Tech domain (gatech.edu), excluding resnet and eastnet. We are simply trying to assure that CGI programing is done on a system which cannot be easily attacked from the outside.

In most cases, CGI scripts will not need to be accessed from the outside world. In the case where external access is needed, the development and testing of these scripts should still be done on the internal server. Once a production release is ready it will then be reviewed for security vulnerabilities before being placed on the external server. In other words, you develop cgi programs on the internal server for testing and we install them on the external server for operation.

We have developed the following procedures for assigning cgi space:

  • When you request cgi space on the CoC web server, we'll need to know the purpose of the cgi program. We'll also need to know whether the scripts will eventually require access from outside the Georgia Tech domain (.gatech.edu) and why. Only those scripts which absolutely have to be available from outside the .gatech.edu domain can be submitted for review once development and testing have been completed. As mentioned previously, all scripts will be developed and tested on the internal web server.

  • If the cgi program is a candidate for the external server, once you have completed developing and testing your scripts and are ready to have them installed into a production environment, you will have to submit a help request to help@cc.gatech.edu with a written description of how the program works. We will need a complete list of files which need to be installed and a description of each file's purpose. We will examine and install the cgi program on the external server. We will also need the name of the person who will be maintaining the program and a contact point so if it breaks we know who to call.

  • All the CGI programs on the external server will be owned by the webmaster inorder to prevent changes by anyone other than the CoC webmaster. The scripts will be executed under the Web server's user ID. Any revisions and changes to the CGI programs must be made to the copy on the internal server. Once you have a new version ready for installation you again send mail to help@cc.gatech.edu with the necessary information for us to review and install the updates.

Using PHP

We have included version 4.0.3pl1 of PHP on our new internal web/cgi server and our new external cgi server. We have included in this version of PHP support for the following databases:

If you need to create a database for use with your PHP scripts you will need to download one of these two packages and compile/install it in your web directory.

Because PHP scripts allow you to run commands just like a CGI script we are treating these pages with the same security guidelines as CGI scripts. This means no PHP scripts will be installed on our external CGI server unless it is absolutely necessary and then only after they have gone through the same review process as CGI scripts. In order to help you organize your files for the external server we have provided directories for each type of file: html, php, and cgi. These directories for the internal server are listed above. If you are only developing on the internal server you can elect to mix your html and php files together.


Using Servlets

As indicated, we are using ApacheJServ 1.1.2. The Java Virutal Machine (JVM) is version 1.3 (i.e. it uses 'java' from usr/local/jdk1.3/bin.) The URLs for servlets are a bit different than what you are use to. JServ doesn't look in the subdirectories of the main servlets folder. For example, if you have the java servlet named 'MyServlet' in the directory '/net/servlets3-int/projects/projdir', the URL:

http://cgi3-int.cc.gatech.edu/servlets/projects/projdir/MyServlet

isn't correct.

We could list all the subdirectories in CLASSPATH for JServ but then we would have problems if people used the same names for their files. So, in order to allow the most flexibility, you will need to define a package name for your servlets which corresponds to your directory path. The JVM looks for and expects files in a package to be in the directory corresponding to the package name. The JVM looks in the main servlet directory and the package name tells the JVM to look in the appropriate subdirectory. Using our previous example the line to add to the top of your servlets file is:

package projects.projdir;

So, the correct URL is:

http://cgi3-int.cc.gatech.edu/servlets/projects.projdir.MyServlet

where 'projects.projdir' is the package name and 'MyServlet' is the servlet's name.


Using Prism Authentication Script

If your application needs to know that a user is a Tech student or a member of the Tech faculty/staff, you can have them "log in" using their Tech-issued account and password to prove it. This will also provide you with the information necessary to access institute records reliably (you'll find student accounts in class rolls and faculty accounts in class records, for instance).

OIT offers a service which will validate a person's OIT account and password. You can use this service through our internal cgi server cgi3-int.cc.gatech.edu. The command to use is prism-auth in /usr/sbin. The script takes one argument, the user's OIT account name. The password is sent to the script via standard input. In order to provide security for the password you need to create a pipe to the command and then write the password into the pipe.

Here is an example in perl5:

	$AUTH_SCRIPT = "/usr/sbin/prism-auth";
	open(FILE, "| $AUTH_SCRIPT $username");
	print FILE "$password";
	close(FILE);
	$exit_value  = $? >> 8;

The script prism-auth returns a 0 if the account and password are valid and a 1 upon improper format or authentication failure.

The html page which takes the username and password should go through the secure socket layer (SSL), that is, it should start with https://. You need to sanitize the username and password before passing it to the script. This mainly means making sure the username and password are eight characters or less.


Using Perl for CGI scripts

  • We have two versions of perl available, version 4.0.1.8 and version 5.004_04. To use perl 4 set the first line of your program to "#!/usr/local/bin/perl" and for perl 5 set it to "#!/usr/local/bin/perl5".

  • We ask that you use taintperl if you are going to be opening a shell from within your cgi script. This requires all data from outside the program (including data from the environment, from standard input and from the command line) which is used in any operation which invokes a shell to be sanitized. For more details checkout http://www.w3.org/Security/Faq/wwwsf5.html. To invoke taintperl under perl 4 change the first line of your perl program to "#!/usr/local/bin/taintperl". Under perl 5 you can simply add the option '-T' to the beginning line, i.e. "#!/usr/local/bin/perl5 -T".

    Two gotchas to note:

    • If you attempt to call an external program without explicitly setting the PATH environment variable Perl will exit.
    • If you are using your own personal modules, you have to add the full pathnames for where your modules are located even if they are in the same directory as your script. The default list of directories does not and should not include '.'.

  • Besides the basic perl 5 modules which are installed by default we also have these modules available: 
    	CGI
    	DBI
    	Data-Dumper
    	Data-ShowTable
    	Digest-MD5
    	HTML
    	IO
    	MIME
    	URI
    	XML-Parser
    	libnet
    	libwww-perl
    	mSQL-MySQL

    The default modules can be found in /usr/local/lib/perl5. The modules listed above can be found in /usr/local/lib/perl5/site_perl.

    You can also install your own modules. To do this you simply compile the modules you want to use and then install them in your cgi directory. At the beginning of your perl code you will need to add the install pathname for your modules in the variable '@INC'. In the man page perlvar (Perl 5 man pages are available in /usr/local/perl5/man) you will find this information regarding the variable '@INC':

    The array @INC contains the list of places to look for Perl scripts to
    be evaluated by the do EXPR, require, or use constructs. It initially
    consists of the arguments to any -I command line switches, followed by the
    default Perl library, probably /usr/local/lib/perl, followed by ".", to
    represent the current directory. If you need to modify this at runtime,
    you should use the use lib pragma to get the machine-dependent library
    properly loaded also:

    	use lib '/mypath/libdir/';
    	use SomeMod;

    CPAN (Comprehensive Perl Archive Network) is where you can find a complete list of available modules along with other Perl material.


Using Databases

TSO does not provide any databases for use with CGI scripts. If you need to setup a database you will need to provide your own. To do this you will need to download one of the freeware database packages available on the internet and compile and install it in your cgi directory. Some of the commonly used packages are:

You have the option of running your database on any machine as long as the database supports connections to remote machines. However we suggest you run it on the web server itself if reliability is an issue.


CGI Binaries

  • mailform - sends form data through email in one of serveral formats

Other CGI Progamming Notes

  • When accessing databases/files etc. from within a cgi script if the access hangs, the script must be able to send itself a signal to kill itself.

CGI Web Links


CGI Security Web Links


Local User Groups

  • - phpAtlanta User Group
Contact Us |  Job Opportunities |  Map/Directions |  Intranet |  Georgia Tech Home

© 2005-2006 The College of Computing at Georgia Tech :: Atlanta, Georgia 30332