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 email@example.com
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:
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
This feature allows you to keep your data private and much more secure
than is normally available in most CGI environments.
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
-rwx------ 1 sks vuser 153525 May 17 11:23 Count.cgi
From the UNIX shell you would set these permissions using the following
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.
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
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
(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
Let's take a look at our http_error_log file to see if we can
learn why the application failed.
(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
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.