The files that you need are as follows:  This is the main program file.  You don’t actually need to
do anything to it; in fact, you don’t even have to execute it.  This is the configuration file.  Everything you need to
change or modify is contained here.  This is also the file that you
will execute.  (Things are set up this way so that you can effectively
maintain multiple versions of the script, for example if you want to
run separate log analyses for different sites, just by keeping
separate config files for each.)

bar1.gif, bar2.gif, bar3.gif, bar4.gif, and bar5.gif:  These five small
graphics files are used to create the bar graphs in the main access

As noted above, the WebLog configuration file, and not the WebLog
program itself, should be executed.  (And please note that it should
be executed from the telnet command prompt rather than your browser;
WebLog is *not* a CGI script, and most likely won’t run correctly if you
try to access it from your browser.)  The configuration file should, of
course, be set executable.  Make sure that the first line of the script
matches the location of your system’s Perl interpreter.  As well, the
following variables need to be defined:

$LogFile:  The path (not URL) of the Web site access log file from
which the log reports will be generated.  Note that this file is
generated by your server; if you’re not sure where to find it or what
it’s called, check with your system administrators.  It is possible,
though not likely, that you don’t actually have access to log data.
If that is the case, then you won’t be able to use WebLog at all.
The script can read both NCSA common (“standard”) and combined
(“extended”) format log files, as well as Microsoft extended format
log files.  You don’t need to specify the type, as WebLog determines
it automatically when it reads the file.  Obviously, if you’re
dealing with NCSA standard log files, or with log files which for
whatever reason don’t include agent and referer information, WebLog
won’t be able to generate agent or referer reports.  You can use an
asterisk in the variable definition as a “wildcard.”  For example, if
your log files come to you named “www.YYMMDD” you can simply define
$LogFile as “www.*”.  This will tell WebLog to analyze *any* file
whose name matches the pattern.  This can also be useful if you have
several log reports backed up, and want to run WebLog on all of them
at once.

$IPLog:  The path to an optional DBM (database) file in which resolved
IP/domain pairs will be stored.  Logging this information will allow
WebLog to run much faster, especially if you’re running multiple
reports from a single log file.  However, especially on a busy site,
the log file could become *very* large.  If you define an IP log file,
keep an eye on its size.

$FileDir:  The path of the directory in which the various report files
will be created.

$ReportFile, $FullListFile, $DetailsFile, $RefsFile, $KeywordsFile and
$AgentsFile:  The file names to be used for each of the reports WebLog
can generate.  All but the first are optional; if you don’t assign a
file name, the report simply won’t be generated.  The “full list” file
allows you to put the “full” file, user ID and domain lists on a page
of their own, while keeping the “top N” lists on the main report page;
this makes the most interesting data easy to see, without requiring
that the main report page be extremely large.

$AgentListFile:  An optional DBM (database) file in which a *complete*
list of agents (browsers) visiting your site will be maintained.  In
most cases, there’s really no reason to maintain such a list.

$DBMType:  This variable determines how the DBM (database) files used
for storage of IP and/or agent info will be accessed.  Most users can
leave it set to 0.  If the script can’t open the database file,
though — and especially if you receive “Inappropriate file type
or format” errors — try setting it to 1.  This will replace the
basic tie() command with a version of the command specific to the
DB_File module, which produces the above error message.  If all
else fails, set $DBMType to 2, and instead of tie() commands, the
more generic (but less efficient) dbmopen() commands will be