OpenGuides Troubleshooting Guide
================================

If you wish to install the OpenGuides modules in a private directory,
the Module::Build incantation for this is

  perl Build.PL install_path=lib=/path/to/my/modules/   # version 0.20 of M::B

  perl Build.PL config='sitelib=/path/to/my/modules/'   # version 0.18 of M::B

----------------------------------------------------------------------

If any or all of the modules required by the OpenGuides scripts are in
a private directory, then you'll need to tell the scripts where to find
them.  The only way I can see to do this is to install everything and
then manually edit the scripts wiki.cgi (or whatever you called it).
supersearch.cgi and preferences.cgi to include a line something like

  use lib qw( /path/to/my/modules/ );

at the top of the scripts before any other modules are required.

----------------------------------------------------------------------

If you are able to run wiki.cgi from the command line but receive an 
Error 500 when trying to view it in your browser, look for the following
message in your webserver error logs:

  "Unable to tie -map_name [...] datafiles directory [...] does not exist
   and cannot be created."

This means that the directory you specified in your configuration as
"indexing_directory" is inaccessible by the user that your CGI is running 
as.  This might mean one of two things:

 - you've specified an indexing_directory within your own webspace
   and the user your CGIs are running as - typically 'nobody' or 
   'www-data' - doesn't have permission to write there

or

 - you've specified an indexing_directory in a place that you're not
   allowed to write to

or a combination of both.  Your ISP or sysadmin might be able to help you
further with this problem if you can't figure it out yourself; as a start,
try setting your indexes directory as world-writeable.

----------------------------------------------------------------------

Important note for those using SQLite:

The user your CGI is running as must have write access to not only the
database file itself, but the directory that the file is in, in order
that it can write a lockfile. If it doesn't have write access to the
database file, you'll see errors like "Unhandled error: [DBD::SQLite::db 
do failed...".

----------------------------------------------------------------------