Requirements And Installation | Submit Password Manager |
The File Submission System |
||
Configuration Script |
The submit system depends on number of configuration
variables to adapt it to the host system and site
preferences. Those needed for installation and
are defined in the Makefile
, and the rest in
the run-time configuration file, submit.conf
.
The submit system is distributed with a configuration script
setup.pl
that examines your system and
adjusts these files to reflect its findings. The modified
Makefile
is used to install the submit system, and
the modified submit.conf
is one
of the files installed.
Setup.pl
inspects your system, then writes a modified
Makefile
and submit.conf
, retaining
the original files
adding the extension .BAK
.
Setup.pl
adjusts variables which describe the host, but
not those which are simple preference. These you
must adjust by hand. See the
configuration variables page for a
complete list.
The usual operation is to perform the inspection and write the modified files without any interaction. If something cannot be discovered, the script writes an error and stops without updating the configuration. This behavior can be modified by the following options:
-i
-noscan
-f
-i
when you want to start with your
last try and change some values.
-force
-a file
-stem [ path ]
STEM
variable.
STEM
is used at the front of other
installation paths. If the -stem
option is not used,
the default value of STEM
is /usr/local
;
if -stem
is used with path
is omitted,
STEM
defaults to the empty string.
The -stem
option is most useful when
running non-interactively; when -i
is in force,
the program will confirm the STEM
value anyway.
-h
The system inspection does the following:
Search for executables named perl
,
tar
, and zip
on the path from the
PATH
environment variable.
Choose a location for man pages. It selects either /usr/share/man
,
/usr/man
, /usr/local/share/man
, or /usr/local/man
based on
what directories exist and whether the default STEM
value contains the
substring local
.
Look for a file httpd.conf
in a list of directories. If found,
we assume it is an Apache configuration file, and scan it for some
values we're interested in. If the -a
option was
given, we skip the search and read the specified file. We remember whatever
is found (or not found) and proceed as follows.
We determine the user of the web server process. If we found an
Apache User
directive, we use that value. Otherwise, we check the
/etc/passwd
file against a list of likely names.
Likewise, we determine the group of the server process from the
Apache Group
directive, if found. If not, we look up the
group field from the entry in /etc/passwd
for the user we
selected in the last step.
Look for a location for the CGI scripts. If we found a
ScriptAlias
in the Apache configuration, we use that directory.
Otherwise, we look for a directory cgi-bin
in a likely place.
Next we find a location to put images to make them
available on the web. If we found an Apache Alias
directive
for icons
, we use that. Otherwise, if we found the
DocumentRoot
from Apache we use that. Otherwise, we
look for a directory html
in a list of likely places.
We check /etc/login.defs
to find values for
the limits UID_MIN
and UID_MAX
which define the limits of user accounts.
If this file is not found, or does not contain these parameters,
the values are left undefined.
We attempt to connect to the https port on localhost, then just close the connection. If the connection succeeds, we configure HTTPS for logins. The other HTTPS flags are always cleared.
It is worth noting that the Apache configuration scanner is by no means an accurate parser of the configuration file syntax. It can miss things that are perfectly correct but not straightforward.