Personal CGI

Personal CGI allows you complete control over your cgi-bin applications. The biggest advantage to this architecture is that it provides you with a safe environment from which to run CGI based applications. The NetGate Personal CGI architecture provides quality of service (QOS) features to protect the over-all performance of the server. Without Personal CGI any single site on a server could potentially consume most of of the available resources. With NetGate Personal CGI no single site can consume more than its fair share of the server resources.

Your cgi-bin directory is located at the root level of your home directory.  The cgi-bin directory is placed outside of your "www" directory space for enhanced security. The directory is named "cgi-bin" and the permissions have been set to allow secure access to the applications within that directory.  Please do not change the permissions on your cgi-bin directory.

Note: If you have a virtual hosting account (you have your own domain) but do not have a "cgi-bin" directory you need to send an e-mail to support@netgate.net so that we can create one for you.

Personal CGI Setup

NetGate Personal CGI is based around the Apache "suexec" application. The suexec application essentially allows the web server to wrap another application around your own CGI applications. This allows your CGI applications to run in your environment instead of in the web servers environment making the over-all server more secure and your site easier to manage. Documentation for suexec is available on the Apache web site at:

        http://www.apache.org/docs/suexec.html

After reading the docs you should have a full understanding of how your applications and file permissions need to be implemented to ensure your scripts work correctly. There are several points listed on the page above that are important when deploying applications into your personal cgi-bin directory space so please take a few minutes to review the information.

CGI Application Permissions

When installing your CGI applications into your personal cgi-bin directory the applications need to have the following permissions set to allow secure access.  For example, a customer using the user name of "sks" would want to use the following file permissions:

-rwx------  1 sks  vuser  153525 May 17 11:23 Count.cgi

From the UNIX shell you would set these permissions using the following command:

        chmod 700 Count.cgi

Another advantage of Personal CGI is that the CGI applications located in your personal cgi-bin directory will run as your user id instead of as the web server user id allowing you to set up secure data files that only your user id can access.  In the past if your CGI application wrote to a data file that file needed to be set up with world write permissions allowing anyone on the server access to your data.  With Personal CGI you can now set up your data files so that only you have access to the data.  For example:

Previously your data file would have needed the following permissions:

-rw-rw-rw-  1 sks  vuser  153525 May 17 11:23 datafile

Using personal CGI you would want to set the permissions to be:

-rw-------  1 sks  vuser  153525 May 17 11:23 datafile

QOS (Quality of Service)

Personal CGI also allows us to offer you Quality of Service (QOS) guarantees.  We believe we are the only hosting provider with a rock solid solution for sites hosted on an Apache server using CGI resources (dynamic content). We have made extensive changes to the Apache server to support this model. Apache does include some built-in facilities to support resource allocation but the default code is broken and can result in runaway CGI applications that can bring an entire server to a grinding halt. The NetGate implementation is a real benefit to our customers. No one customer will be able to consume the entire server resources as was possible in the past.  Personal CGI allows us to control process, memory, and CPU limits for each customer.  More information concerning current QOS resource limits, and process usage tracking can be found on our Process Limits and PCGI page.

Debugging Personal CGI Applications

The web server will write log information in relation to errors caused by QOS limits or security restrictions to your "cgi_log" file. The daily "cgi_log" file is located in your raw logs directory. Previous days logs are archived in the file "cgi_log.Month.gz" file also located in your raw logs directory.

Errors caused by the execution of the CGI application itself will be logged into your current "http_error_log" file. The log file is located in your raw logs directory. Previous days logs are archived in the file "http_error_log.Month.gz" file also located in your raw logs directory.

Example:

If we installed a new CGI application, but with the wrong permissions the program would fail to execute. Let's follow the process of tracking down the problem.

Use a web browser to execute the new CGI application. The user would get an error message back such as "The attempt to load "http://..." failed".

We'll use the UNIX "tail" command to view the end of our "cgi_log" file to see if we can discover why the application is failing.

tail /usr/local/apache/logs/site_name/cgi_log
(where "site_name" is "www.yourdomain")

[19:07:37 02-06-99]: uid: (sks/sks) gid: (vuser/vuser) nph-tr.pl

Unfortunately the information isn't really all that interesting. It basically tells us that the CGI application passed all the basic security tests.

Let's take a look at our http_error_log file to see if we can learn why the application failed.

tail ~www/logs/mysite_name/http_error_log
(where "mysite_name" is "www.yourdomain")

fopen: Permission denied

Although it doesn't tell you in plain english it does give you enough information to question the file permissions. The key phrase from the http_error_log is "Permission denied".

We use the UNIX "ls" command to view the file permissions.

ls -al cgi-bin

rw------- 1 sks vuser 387 Mar 31 1998 nph-tr.pl

The problem was caused because the CGI application was installed with no exec permissions. The error is easily corrected by setting the permissions on the application to allow execution. To change the permissions using the UNIX "chmod" command do the following:

chmod 700 nph-tr.pl

To ensure you've fixed the problem re-test the CGI application using a web browser. In our example the CGI application is now fixed and working as expected.