source: trunk/TROUBLESHOOTING @ 319

Last change on this file since 319 was 319, checked in by Dominic Hargreaves, 18 years ago

Doc fixes: copyright date in README, TROUBLESHOOTING private dir advice.

  • Property svn:eol-style set to native
  • Property svn:keywords set to Author Date Id Revision
File size: 2.5 KB
Line 
1OpenGuides Troubleshooting Guide
2================================
3
4If you wish to install the OpenGuides modules in a private directory,
5the Module::Build incantation for this is
6
7  perl Build.PL install_path=lib=/path/to/my/modules/ \
8                install_path=arch=/path/to/my/modules/auto/ \
9                install_path=libdoc=/path/to/my/man/ \
10                install_path=bindoc=/path/to/my/man/ \
11                install_path=script=/path/to/my/bin/    # version 0.20 of M::B
12
13  perl Build.PL config='sitelib=/path/to/my/modules/'   # version 0.18 of M::B
14
15----------------------------------------------------------------------
16
17If any or all of the modules required by the OpenGuides scripts are in
18a private directory, then you'll need to tell the scripts where to find
19them.  The only way I can see to do this is to install everything and
20then manually edit the scripts wiki.cgi (or whatever you called it).
21supersearch.cgi and preferences.cgi to include a line something like
22
23  use lib qw( /path/to/my/modules/ );
24
25at the top of the scripts before any other modules are required.
26
27----------------------------------------------------------------------
28
29If you are able to run wiki.cgi from the command line but receive an
30Error 500 when trying to view it in your browser, look for the following
31message in your webserver error logs:
32
33  "Unable to tie -map_name [...] datafiles directory [...] does not exist
34   and cannot be created."
35
36This means that the directory you specified in your configuration as
37"indexing_directory" is inaccessible by the user that your CGI is running
38as.  This might mean one of two things:
39
40 - you've specified an indexing_directory within your own webspace
41   and the user your CGIs are running as - typically 'nobody' or
42   'www-data' - doesn't have permission to write there
43
44or
45
46 - you've specified an indexing_directory in a place that you're not
47   allowed to write to
48
49or a combination of both.  Your ISP or sysadmin might be able to help you
50further with this problem if you can't figure it out yourself; as a start,
51try setting your indexes directory as world-writeable.
52
53----------------------------------------------------------------------
54
55Important note for those using SQLite:
56
57The user your CGI is running as must have write access to not only the
58database file itself, but the directory that the file is in, in order
59that it can write a lockfile. If it doesn't have write access to the
60database file, you'll see errors like "Unhandled error: [DBD::SQLite::db
61do failed...".
62
63----------------------------------------------------------------------
Note: See TracBrowser for help on using the repository browser.