This FAQ collects common CGIWrap questions from both administrators and end users, covering installation problems, permission errors, debugging methods, PHP integration, and typical CGI execution issues. It is designed to make the documentation feel more approachable while still preserving the practical technical answers people need.
Many of these questions come from real setup friction points in Unix hosting environments, especially around server user configuration, setuid requirements, auxiliary groups, resource limits, and script debugging. That makes this page useful as both a quick reference and a troubleshooting guide.
The answers below keep the original guidance but present it in a cleaner, more personable format so the page reads more like a helpful knowledge base and less like a raw document dump.
CGIwrap needs to be configured with the userid that your web server is running as. For Apache based servers, this is the userid that is listed on the User line in httpd.conf. You specify this when configuring CGIWrap using the --with-httpd-user option.
CGIwrap needs to be installed set-uid to root. Log in as root, change to the server's cgi-bin directory, and issue the following commands:
chown root cgiwrap chmod 4755 cgiwrap
This is not supported by all web servers, but with Apache, use:
<!--#include virtual="/cgi-bin/cgiwrap/user/script...."-->
One of the problems is that this often is a security hole unless you can enable server side exec or virtual include only of executables that are in ExecCGI capable directories. Some people have made patches that will allow this to work. Ask on the list for details.
This occurs when CGIwrap is unable to set auxilliary groups. Auxilliary groups are groups that a user is a member of in /etc/group, that are not the user's primary group in /etc/passwd. Two things you can do here are to make sure CGIwrap is installed correctly, since it has to be setuid root to be able to set auxilliary groups, or disable setting auxilliary groups.
This indicates that you installed cgiwrap with resource limiting, with rlimit support, but the limits are set too low. There is not enough memory for Perl to load. Keep in mind that Unix applications usually use a lot of virtual memory, even though their resident size is small.
Here is an informal how-to written after setting up cgiwrap and PHP together. Much thanks goes to Nathan Nuelinger for pointing out the decisive step of compiling with --enable-discard-path.
Download cgiwrap and set that up first. It is best to get CGIwrap working with some simple CGI script tests before moving on. Options you may find helpful include --with-cgi-dir and --with-httpd-user.
Download the latest version of PHP and configure it as a CGI binary, not as a module. Basically, if you run ./configure with no options, PHP will be compiled as a CGI binary. To set it up as an Apache module, which you do not want if you are wrapping your scripts, you would have to explicitly say ./configure --with-apache.
Before you compile PHP, however, and this is crucial, configure PHP with the option --enable-discard-path. This allows you to move the PHP binary out of the web tree and into /usr/local/bin, which adds security, but more importantly it allows you to use PHP with CGIwrap properly.
To summarize, you need to run ./configure --enable-discard-path plus any other options you may desire, and place the PHP binary in /usr/local/bin.
Finally, you need the line #!/usr/local/bin/php at the very top of every PHP script you write. Then call the PHP script with CGIwrap exactly as you would call a CGI script.
For example:
https://yourdomain.com/cgi-bin/cgiwrap/<username>/<phpscript>
CGIwrap supports a debugging mode which can help to debug scripts. To use it, call CGIwrap via the URL https://.../cgiwrapd/... instead of https://.../cgiwrap/....
This generally results from either having the wrong path to Perl, or having control-M characters after the path to Perl. This is usually a result of uploading the script in binary mode instead of ASCII.
You can fix this by re-uploading the script in ASCII mode, or using vi, Perl, or another editor to get rid of the control-M characters in the file.
For some situations, simply adding -- to the end of the first line of the script will cause the error to go away, sometimes not.
cgiwrapd is still there, it just is not directly obvious how to use it. If you normally call your script as:
https://www.site1.com/test.cgi
you can call it as:
https://www.site1.com/cgiwrapDir/cgiwrapd/test.cgi
to run it under cgiwrapd. Basically they ScriptAlias cgiwrapDir to the directory where cgiwrap is installed.
As a whole, this FAQ highlights the most common CGIWrap trouble spots: server user mismatches, setuid installation requirements, group-setting failures, resource limits, interpreter path problems, and debugging workflow. Those are exactly the areas that tend to slow down first-time setups, so having them collected here adds real value for both users and administrators.