cgiwrap for DEBIAN
----------------------

 This is worth reading through one time.  It is  a typescript log made
by running the configuration script inside an emacs buffer.

 If you don't like the way I've configured `cgiwrap`,  you may ftp the
source and compile it yourself.   If you think the mainstream  package
should  be configured  differently, please  drop me  a note explaining
why.  <karlheg@inetarena.com>

8<----------------------------------------------------------------->8
/usr/local/src/cgiwrap-3.5
$ ./Configure
 
Beginning of configuration questions for cgiwrap.
 
Checking echo to see how to suppress newlines...
...using -n.
The star should be here-->*
 
Would you like to see the instructions? [n] y
 
This installation shell script will examine your system and ask you questions
to determine how the cgiwrap package should be installed. If you get
stuck on a question, you may use a ! shell escape to start a subshell or
execute a command.  Many of the questions will have default answers in square
brackets; typing carriage return will give you the default.

On some of the questions which ask for file or directory names you are allowed
to use the ~name construct to specify the login directory belonging to "name",
even if you don't have a shell which knows about that.  Questions where this is
allowed will be marked "(~name ok)".

[Type carriage return to continue] 

The prompter used in this script allows you to use shell variables and
backticks in your answers.  You may use $1, $2, etc...  to refer to the words
in the default answer, as if the default line was a set of arguments given to a
script shell.  This means you may also use $* to repeat the whole default line,
so you do not have to re-type everything to add something to the default.

Everytime there is a substitution, you will have to confirm.  If there is an
error (e.g. an unmatched backtick), the default answer will remain unchanged
and you will be prompted again.

If you are in a hurry, you may run 'Configure -d'.  This will bypass nearly all
the questions and use the computed defaults (or the previous answers if there
was already a config.sh file). Type 'Configure -h' for a list of options.
You may also start interactively and then answer '& -d' at any prompt to turn
on the non-interactive behaviour for the remaining of the execution.

[Type carriage return to continue] 

Much effort has been expended to ensure that this shell script will run on any
Unix system.  If despite that it blows up on yours, your best bet is to edit
Configure and run it again.  If you can't run Configure for some reason,
you'll have to generate a config.sh file by hand.  Whatever problems you
have, let me (cgiwrap@umr.edu) know how I blew it.

This installation script affects things in two ways:

1) it may do direct variable substitutions on some of the files included
   in this kit.
2) it builds a config.h file for inclusion in C programs.  You may edit
   any of these files as the need arises after running this script.

If you make a mistake on a question, there is no easy way to back up to it
currently.  The easiest thing to do is to edit config.sh and rerun all the SH
files.  Configure will offer to let you do this before it runs the SH files.

[Type carriage return to continue] 
 
Checking your sh to see if it knows about # comments...
Your sh handles # comments correctly.
 
Okay, let's see if #! works on this system...
It does.
 
Checking out how to guarantee sh startup...
Let's see if '#!/bin/sh' works...
Yup, it does.
 
Locating common programs...
awk is in /usr/bin/awk.
cat is in /bin/cat.
echo is in /bin/echo.
expr is in /usr/bin/expr.
grep is in /bin/grep.
ln is in /bin/ln.
rm is in /bin/rm.
sed is in /bin/sed.
touch is in /usr/bin/touch.
tr is in /usr/bin/tr.
 
Don't worry if any of the following aren't found...
I don't see Mcc out there, offhand.
cpp is in /usr/bin/cpp.
date is in /bin/date.
perl is in /usr/local/bin/perl.
test is in /usr/bin/test.
uname is in /bin/uname.
Using the test built into your sh.
 
Checking compatibility between /bin/echo and builtin echo (if any)...
They are compatible.  In fact, they may be identical.
 
Symbolic links are supported.
 
Good, your tr supports [:lower:] and [:upper:] to convert case.
 
I see a config.sh file.  Shall I use it to set the defaults? [y] 
Fetching default answers from your old config.sh file...

The next question deals with whether or not you want cgiwrap to verify
that it is being run from the web server. The way it does this is, it
checks it's effective UID and compares that to the userid that the web
server runs as. If they are not the same, and you have this option turned
on, cgiwrap will exit.

Verify cgiwrap executed by server? [y] 

Now you need to tell me what userid your web server is running as. Note, 
this is most likely not 'root'. This is usually configured as part of your
server config. You can check which one it is by looking at the child 
httpd processes and seeing who owns them.

What user is the server running as? [www-data] 
 
I can set things up so that your shell scripts and binaries are more portable,
at what may be a noticable cost in performance.  In particular, if you
ask to be portable, the following happens:

     1) Shell scripts will rely on the PATH variable rather than using
	the paths derived above.
     2) ~username interpretations will be done at run time rather than
	by Configure.

Do you expect to run these scripts and binaries on multiple machines? [y] 

The next question(s) deal with whether you want CGIwrap to restrict it's 
usage only to userids that are listed in a configuration file.  

CGIwrap uses the same method for determining access as cron. If the allow
file exists, then the userid must be listed in it in order to use CGIwrap.
If the deny file exists, then the userid must NOT be listed in it to use
CGIwrap. 

I recommend enabling this option, and just creating an empty deny file to
start out. That way, you can cut someone off if they abuse the service. 

An option for restricting access further includes checking the remote host
address against a range of IP addresses. This allows you to restrict cgi
usage by a particular user to being access from only certain hosts. This
is usefull for a situation where you only want your users making CGI
scripts that can be accessed from your domain. 

The file format is one userid per line, unless you enable host checking.

Check access control files? [y] 

Now I need to know the paths where you will be storing the allow
and deny files.

Location of allow file? (~name ok) [/etc/cgiwrap.allow] 
Location of deny file? (~name ok) [/etc/cgiwrap.deny] 

If you want to enable checking the remote host against a list of specified
host addresses, answer yes to the following question. If you do enable
this, the formats allowed by the allow/deny files are: 

username
 or
username@subnet/mask
 or
username@subnet1/mask1,subnet2/mask2,...,subnetn/maskn

e.g
myuser@1.2.3.4/255.255.255.255,2.3.0.0/255.255.0.0

would allow myuser's CGI scripts to run from the host 1.2.3.4 or any hosts
whose IP address starts 2.3. (e.g. 2.3.56.78) if in the allow file or deny
access from those hosts if in the deny file.

Check Host Address? [y] 
 
AFS does not seem to be running...

The next several questions are for enabling or disabling certain checks 
that are made on the script before allowing it to be executed.

You can enable the check to prevent the script from executing if any of 
the following are true:
	o Script's owner does not match user
	o Script's group does not match user
	o Script is setuid
	o Script is setgid

If any of the chosen checks fail, the script will not be executed, and an
error message will be returned to the user.

Check if script is owned by this user? [y] 
Check if script's group matches this user? [y] 
Check if script is set-uid? [y] 
Check if script is set-gid? [y] 

Versions of CGIwrap up to and including version 3.4 were incorrectly setting 
the PATH_TRANSLATED environment variable. Unfortunately, since this wasn't 
noticed till recently, people may be relying on the incorrect behavior. If 
you want CGIwrap to set the PATH_TRANSLATED variable correctly, then answer 
the following question yes, otherwise answer no. The default is yes, since
I am assuming that most people will want the correct value, and will not have
previosly used it due to it being incorrect.

For your information, if you answer the question yes, the value of the 
PATH_TRANSLATED variable will be set to DOCUMENT_ROOT/PATH_INFO. Whereas 
if you choose no, the PATH_TRANSLATED variable will be set to the actual 
path to the script.

Correctly set PATH_TRANSLATED variable? [y] 
 
System manual is in /usr/man/man1.
 
Hmm...  Looks kind of like a Version 7 system, but we'll see...
 
Congratulations.  You aren't running Eunice.
 
It's not Xenix...
 
Nor is it Venix...
 
Use which C compiler? [gcc] 
 
Checking for GNU cc in disguise and/or its version number...
You are using GNU cc 2.7.2.1.
 
Hmm...  Doesn't look like a MIPS system.
 
Where are the include files you want to use? [/usr/include] 

Some systems have incompatible or broken versions of libraries.  Among
the directories listed in the question below, please remove any you
know not to be holding relevant libraries, and add any that are needed.
Say "none" for none.

Directories to use for library searches? [/lib /usr/lib /usr/local/lib] 

On some systems, shared libraries may be available.  Answer 'none' if
you want to suppress searching of shared libraries for the remaining
of this configuration.

What is the file extension used for shared libraries? [so] 
 
Checking for optional libraries...
No -lc_s.
 
Some versions of Unix support shared libraries, which make executables smaller
but make load time slightly longer.

On some systems, mostly newer Unix System V's, the shared library is included
by putting the option "-lc_s" as the last thing on the cc command line when
linking.  Other systems use shared libraries by default.  There may be other
libraries needed to compile cgiwrap on your machine as well.  If your system
needs the "-lc_s" option, include it here.  Include any other special libraries
here as well.  Say "none" for none.
 
Any additional libraries? [none] 

I can use 'nm' to extract the symbols from your C libraries. This is a time
consuming task which may generate huge output on the disk (up to 3 megabytes)
but that should make the symbols extraction faster. The alternative is to skip
the 'nm' extraction part and to compile a small test program instead to
determine whether each symbol is present. If you have a fast C compiler and/or
if your 'nm' output cannot be parsed, this may be the best solution.

Shall I use nm to extract C symbols from the libraries? [n] 
 
Now, how can we feed standard input to your C preprocessor...
You used to use gcc -E - so we'll use that again.
(And we'll use gcc -E - to preprocess directly.)

Some C compilers have problems with their optimizers, by default, cgiwrap
compiles with the -O flag to use the optimizer.  Alternately, you might want
to use the symbolic debugger, which uses the -g flag (on traditional Unix
systems).  Either flag can be specified here.  To use neither flag, specify
the word "none".

What optimizer/debugger flag should be used? [-O2] 

Your C compiler may want other flags.  For this question you should include
-I/whatever and -DWHATEVER flags and any other flags used by the C compiler,
but you should NOT include libraries or ld flags like -lwhatever.  If you
want cgiwrap to honor its debug switch, you should include -DDEBUG here.
To use no flags, specify the word "none".

Any additional cc flags?
[-m486 -malign-double -malign-loops=2 -malign-jumps=2 -malign-functions=2 -fno-strength-reduce] 
 
Let me guess what the preprocessor flags are...
They appear to be: -m486 -malign-double -malign-loops=2 -malign-jumps=2 -malign-functions=2 -fno-strength-reduce
 
Any additional ld flags (NOT including libraries)? [none] 
 
Checking your choice of C compiler and flags for coherency...
OK, that should do.
 
setgroups() found.
 
initgroups() found.

Your system supports the setgroups() call. Using this will allow CGIwrap 
to clear the auxilliary groups of the process before executing the 
script. This is useful if your server userid is a member of any groups 
that regular users are not. If you have problems with setgroups() when 
executing scripts, turn this option off. Auxilliary groups are usually 
defined in the /etc/group or /etc/logingroup files.

Clear auxilliary groups with setgroups()? [y] 

Your system supports the initgroups() call. Using this will allow CGIwrap
to set the auxilliary groups of the process before executing the script.
This is useful if the userid is a member of additional groups other than
their primary group (from /etc/passwd). If you have problems with
initgroups() when executing scripts, turn this option off. Auxilliary
groups are usually defined in the /etc/group or /etc/logingroup files. 

Set auxilliary groups with initgroups()? [y] 

CGIwrap can log all incoming CGI requests to a file or syslog. This allows
you to keep track of who is using CGIwrap on your system independent of
web server logging. The time, date, remote host, user, script name,
authenticated userid, and a short message are logged to this file. 

If you choose to log to syslog, cgiwrap will log using facility 
LOG_DAEMON, priority LOG_INFO, and will log the pid. The syslog message 
will have the format: "[label] user, script, host, address, user, message"

Log requests to syslog? [y] 

Since some sites will have multiple instances of cgiwrap running on a 
single machine, it is often handy to be able to differentiate between 
them. Since there is only one type of message for syslog, cgiwrap allows 
you to assign a label to any messages that are generated by this copy of 
cgiwrap. 

For example, if you are running an authenticated cgiwrap on a server on 
port 2000, you might label it "auth-2000". If you don't want a label, 
answer 'none'.

What label should be assigned? [none] 
Log requests to a file? [n] 

CGIwrap has the capability of automatically redirecting the stderr output
to stdout. This means that users can debug their scripts from the web 
browser instead of having to look at the server's error_log to see the error
output from their scripts. I reccomend you leave this as yes.

This feature has actually turned out to be one of the more handy 
capabilities of CGIwrap, particularly when combined with the debugging mode.

Redirect standard error [y] 

CGIwrap needs to know where the user will store their cgi scripts. I 
generally use the "public_html/cgi-bin". This is a path relative to the 
users' home directory.

Where will the users store cgi scripts? [public_html/cgi-bin] 

CGIwrap has the capability of allowing users to store scripts in 
subdirectories of their cgi-bin directory. You need to decide whether
or not you wish to allow this. I reccomend allowing it, it is extremely
convenient when you start to develop alot of scripts.

Allow users to store scripts in subdirectories of cgi-bin? [y] 
 
setrlimit() found.

If you system supports the set_rlimit system call, cgiwrap can automatically
limit various resource usages by a cgi-script. If you know that your system 
supports setrlimit, and you wish to enable this option, answer the next 
question yes.

Limit CPU usage with setrlimit? [y] 
Limit Virtual Memory usage with setrlimit? [y] 
 
system() found.

This question deals with how you want to have the script executed. If for 
some reason you don't want to exec() the script directly. (For instance, 
if your architecture does not support exec()'ing shell scripts directly) 
Answering this question yes will cause cgiwrap to use system() to execute
the script. I reccomend choosing no unless you know for certain you can't
use exec.

Use system() instead of exec()? [n] 

To allow for sites that don't run CGI scripts out of user directories, 
or have special needs, such as hosts performing virtual-server type
services, CGIwrap can read a configuration file that allows the path
to directories to be rewritten.

This way, the user's home directory can be located in one place, and the
cgi-bin directory can be located in a completely different location. 

Unless you absolutely need this, I would suggest NOT enabling this option, 
as it will slow cgiwrap down considerably.

Process User Directory Rewrite File? [y] 

Now I need to know the path to the file that contains the list
of user directories. Note, you only need to include userids in this
file that need to be rewritten. Otherwise, CGIwrap will just use the
directory that is listed in the passwd file.

The file format is line based, with each line having the format:

userid:directory

For example, if the user's home directory was "/users/fred", and you had
"fred:/web/users/freds-cgi-scripts" in the userdir file - then cgiwrap 
would look for cgi scripts in "/web/users/freds-cgi-scripts" instead of 
in "/users/fred/public_html/cgi-bin".

What file contains the list of user cgi dirs? (~name ok)
[/etc/cgiwrap.userdir] 
 
perror() found.
 
setegid() found.
 
seteuid() found.
 
setgid() found.
 
setregid() found.
 
setresgid() NOT found.
 
setreuid() found.
 
setresuid() NOT found.
 
setrgid() NOT found.
 
setruid() NOT found.
 
setuid() found.
 
sigset() NOT found.
 
strdup() found.
 
Computing filename position in cpp output for #include directives...
Your cpp writes the filename in the third field of the line.
 
strerror() found.
(You also have sys_errlist[], so we could roll our own strerror.)
 
syslog() found.
 
Checking to see how well your C compiler groks the void type...
 
  Support flag bits are:
    1: basic void declarations.
    2: arrays of pointers to functions returning void.
    4: operations between pointers to and addresses of void functions.
    8: generic void pointers.
 
Your void support flags add up to what? [15] 
 
<limits.h> found.
 
<pwd.h> found.
 
<stdlib.h> found.
 
Using <string.h> instead of <strings.h>.
 
<sys/resource.h> found.
 
Testing to see if we should include <time.h>, <sys/time.h> or both.
I'm now running the test program.... 
Succeeded with -DI_SYSTIME -DS_TIMEVAL 
We'll include <sys/time.h>.
 
<sys/types.h> found.
 
<unistd.h> found.

In order to function, CGIwrap issues a library call to change the real 
and effective uid and gid of the current process.

Different systems have different calls available for doing this. 

Your system has the following calls available:

   setegid()
   seteuid()
   setreuid()
   setregid()
   setuid()
   setgid()

The CGIwrap source code uses the following logic to determine which
set_ call to use. If this is not correct for your system, or you have 
special needs: 1) Send me a note about it, particularly if it is a 
problem with support for a particular machine. 2) Hand edit the config.sh 
file to change the d_set*id to 'define' and 'undef' as appropriate for the
configuration you desire.

The first match in the following list is used:

	setuid & setgid
	setreuid & setregid
	setresuid & setresgid
	seteuid, setegid, setruid, & setrgid

Regardless of which is chosen, CGIwrap as distributed WILL NOT allow
the script to execute if the both the real and effective uid and gid have 
not been successfully changed to those of the user owning the script. 
This is the case REGARDLESS of what options or setting have been chosen 
in this Configure script.

 
End of configuration questions.
 
 
Stripping down executable paths...
 
Creating config.sh...

If you'd like to make any changes to the config.sh file before I begin
to configure things, do it as a shell escape now (e.g. !vi config.sh).

Press return or use a shell escape to edit config.sh: 
 
Doing variable substitutions on .SH files...
(Looking for .SH files under the current directory.)
Extracting loganalyze.pl (with variable substitutions)
Extracting bconf.pl (with variable substitutions)
Extracting Makefile (with variable substitutions)
Extracting config.h (with variable substitutions)
 
Now you must run a make.
8<----------------------------------------------------------------->8

Karl M. Hegbloom <karlheg@inetarena.com>, Mon,  19 May 1997 15:15:25 -0700