![]() 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.
-hThe 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.