SID-02115: Unable to install: LocalSite.cfg path, software error

Status:	Answered	TWiki version:	6.0.1	Perl version:	5.10.1
Category:	CategoryInstallation	Server OS:	CentOS 6.7	Last update:	10 years ago

I am trying to move my TWiki site from one server to another - a task which I have successfully accomplished before - but I am not able to install this site on the new server, nor am I able to install a freshly downloaded version of TWiki.

1. Fresh install of a TWiki site: I browse to bin/configure, the page displays as expected and asks for a password.
2. After submitting this page I get the following page: "Could not find where LocalSite.cfg is supposed to go. Edit your LocalLib.cfg and set $twikiLibPath to point to the 'lib' directory for your install. Please correct this error before continuing. Resetting the admin Password for the TWiki "
3. I copy LocalLib.cfg.txt to LocalLib.cfg and put in the full system path to the lib directory. I reload the configure page. I get the same message: "Could not find where LocalSite.cfg is supposed to go. Edit your LocalLib.cfg and set $twikiLibPath to point to the 'lib' directory for your install. Please correct this error before continuing. Resetting the admin Password for the TWiki "
4. After a refresh - or sometimes a few refreshes - I might get the full configure page again where it asks for a password - I type in a password. On submission this time, I get a software error message: "Can't call method "ui" on an undefined value at /var/www/vhosts/.../httpdocs/bin/configure line 451, <DATA> line 1."

I have checked all the file permissions and they match between the server where TWiki works and the one where TWiki doesn't.

Any ideas as where I should look?

Operating system: CentOS 6.7; Perl version: 5.10.1

(Older server - where TWiki works: OS: CentOS 5.11 Perl version: 5.18.2)

-- Neil Thompson - 2015-10-23

Discussion and Answer

You possibly run into a "gotcha" with the Perl CGI module, which is unfortunately a moving target. Make sure to use CPAN:CGI >=3.18 to <=4.03. For background see SID-02001 and AddCGIpmToTWikiCore.

-- Peter Thoeny - 2015-10-24

Thank you for this, but that doesn't seem to be the problem.

These are the versions of all the resources specified in TWikiSystemRequirements:

SERVER:

• CentOS release 6.7 (Final)
• This is perl, v5.10.1 (*) built for x86_64-linux-thread-multi
• $ rcs -V RCS
  • version 5.7
• $ diff -v
  • diff (GNU diffutils) 2.8.1
• $ patch -v
  • patch 2.6
• df, fgrep, egrep (pre-installed)

• $ httpd -v
  • Server version: Apache/2.2.15 (Unix) Server built: Aug 24 2015 17:52:49

• CGI : 3.51
• CGI::Carp : 3.51
• Config :
• Cwd : 3.3
• Data::Dumper : 2.124
• Encode : 2.35
• File::Copy : 2.14
• File::Find : 1.14
• File::Spec : 3.3
• File::Temp : 0.22
• FileHandle : 2.02
• HTML::Parser : 3.64
• HTML::Entities : 3.64
• IO::File : 1.14
• LWP : 5.833
• Net::SMTP : 2.31
• Time::Local : 1.1901

-- Neil Thompson - 2015-10-26

Looking at the code where the error message is written, there is one simple thing to check:

• In your lib directory, there should be a file TWiki.spec. Is it there, and readable for the web server's user id?

Two minor points:

• On a "standard" install where you have all TWiki components under the same directory and you have admin access to web server configuration, LocalLib.cfg is not required at all. I suggest you remove it, and apologize for the misleading error message.
• The behaviour of TWiki with "one or several refreshes" may appear strange. It is harmless, and a consequence of TWiki trying to remember the state of the configuration process (using a session cookie) but not finding a place to write it to. To force a fresh start you can restart your browser.

-- Harald Jörg - 2015-10-26

If you have mod_perl enabled, try to disable, e.g. run under straight cgi mode.

-- Peter Thoeny - 2015-10-26

On LocalLib.cfg, it is not required on an install with standard directory structure, but it is recommended. If you don't specify an absolute path, TWiki will use a relative path to figure out the twiki/lib. There are/have been plugins that choke on the relative path.

-- Peter Thoeny - 2015-10-26

Thank you very much for this. In the end, on looking at the server's suexec log, I discovered that the user under which Apache would call the scripts had been misconfigured. Correcting this solved the problem.

-- Neil Thompson - 2015-10-28

-- Neil Thompson - 2015-10-28

If you answer a question - or someone answered one of your questions - please remember to edit the page and set the status to answered. The status selector is below the edit box.