Item1829: Configure shouldn't crash if there is no LocalSite.cfg

Using Foswiki 1.0.6, on a Linux Debian, with Apache 2.2.3, with all the lib/DEPENDENCIES installed except Win32::Console

1.

• Follow the installation instructions at http://foswiki.org/System/InstallationGuide up to the point you have to configure Apache
• Use the Apache Config Generator at http://foswiki.org/Support/ApacheConfigGenerator
• Configure it to require that an authorised user has to authenticate to access the configure script
• Use it with the following settings: http://foswiki.org/Support/ApacheConfigGenerator?vhost=&port=&dir=%2Fvar%2Fwww%2Ffoswiki&pathurl=%2Ffoswiki&shorterurls=enabled&engine=CGI&fastcgimodule=fastcgi&apver=2&allowconf=&requireconf=raul&loginmanager=Template&htpath=%2Fvar%2Fwww%2Ffoswiki%2Fdata&errordocument=UserRegistration&errorcustom=&phpinstalled=PHP4&blockpubhtml=on&blocktrashpub=on&controlattach=on&blockspiders=on#HighLight (replace "raul" with any other user to suit your installation)
• create the .htpasswd file for that user as directed by the documentation
• install the Apache .conf file, restart Apache, and point browser to http://host/foswiki/bin/configure
• you get the following error message :

Software error:

Content-type: text/plain

Perl error when reading LocalSite.cfg: 
Please inform the site admin.
 at /usr/share/perl/5.8/CGI/Carp.pm line 356
   CGI::Carp::realdie('Content-type: text/plain\x{a}\x{a}Perl error when reading LocalSite.c...') called at /usr/share/perl/5.8/CGI/Carp.pm line 437
   CGI::Carp::die('Content-type: text/plain\x{a}\x{a}Perl error when reading LocalSite.c...') called at /var/www/foswiki/lib/Foswiki/Configure/Load.pm line 56
   Foswiki::Configure::Load::readConfig() called at /var/www/foswiki/lib/Foswiki.pm line 269
   Foswiki::BEGIN() called at LocalSite.cfg line 498
   eval {...} called at LocalSite.cfg line 498
   require Foswiki.pm called at /var/www/foswiki/bin/view line 43
   main::BEGIN() called at LocalSite.cfg line 498
   eval {...} called at LocalSite.cfg line 498
BEGIN failed--compilation aborted at /var/www/foswiki/lib/Foswiki.pm line 498.
 at /var/www/foswiki/lib/Foswiki.pm line 498
   require Foswiki.pm called at /var/www/foswiki/bin/view line 43
   main::BEGIN() called at /var/www/foswiki/lib/Foswiki.pm line 498
   eval {...} called at /var/www/foswiki/lib/Foswiki.pm line 498
Compilation failed in require at /var/www/foswiki/bin/view line 43.
 at /var/www/foswiki/bin/view line 43
   main::BEGIN() called at /var/www/foswiki/lib/Foswiki.pm line 43
   eval {...} called at /var/www/foswiki/lib/Foswiki.pm line 43
BEGIN failed--compilation aborted at /var/www/foswiki/bin/view line 43.
 at /var/www/foswiki/bin/view line 43

For help, please send mail to the webmaster (xxx@yyy.com), giving this error message and the time and date of the error. 

2.

• comment the line Alias /foswiki "/var/www/foswiki/bin/view" and restart Apache
• point to the same address
• configuration page can be accessed after authentication, like it is supposed to be
• that alias is needed for "short urls" according to the comment preceding it

3.

• restore the line Alias /foswiki "/var/www/foswiki/bin/view"
• comment the lines AuthUserFile, AuthName, AuthType and the FilesMatch "^(configure)$" block (or just that block, or the require user in that block)
• restart Apache
• the configuration page can be accessed, in a non secure way

4.

• change the configuration file completely by another one generated by Apache Config Generator, without a required user to access configure (though it is a recommended setting) and only with a required IP address (which is an optional setting)
• install the configuration file
• restart Apache
• the configuration page can be accessed from an allowed IP
• the access indeed is impossible from a non listed IP
• a warning improperly says that is is being accessed in an insecure way ("BIG, BIG WARNING! This screen was accessed without requiring authentication. This is a high security risk! You should always make sure the configuration interface requires authentication, or it may be used by a hacker to modify your Foswiki configuration. See for Protecting Your Configuration for more information on limiting access to configuration.").

This problem blocks the user from reaching the configuration page though it is following the documentation by using the Apache Config Generator and using the recommended settings for it by choosing a user name allowed to access configure.

The alternative of securing by restricting to certain IP addresses works, except that the configure page gives a warning encouraging the user to use a setting that makes the configure page not accessible at all to anybody because of the above mentioned error.

-- RaulFRodriguez - 15 Jul 2009

Please note that once I have saved the lib/LocalSite.cfg configuration for the first time (by avoiding a 1st setup requiring a user), I can include the "Require user" directive again in the Apache config for the block, and that no longer produces any error, authentication to the created user is performed and access is granted.

The problem is only when configure is run for the 1st time, with this Apache directive recommended by the installation procedure, while lib/LocalSite.cfg does not yet exist.

The "Software error" message I quoted above seems to complain about "Perl error when reading LocalSite.cfg" ... at a stage where LocalSite.cfg is not supposed to exist, since that's the 1st time configure is ran.

-- RaulFRodriguez - 15 Jul 2009

As for 1. I agree (and so does Crawford) that Foswiki shouldn't crash when there is no LocalSite.cfg, just like it should work without any LocalLib.cfg.

Therefore, I've coded the following patch, which I'll commit as soon as I successfully test it on my windows installation, and maybe some others. As this is a very crucial part, we need it just to work in all other cases.

diff --git a/core/lib/Foswiki/Configure/Load.pm b/core/lib/Foswiki/Configure/Load.pm
index a331bb0..a6b5a4b 100644
--- a/core/lib/Foswiki/Configure/Load.pm
+++ b/core/lib/Foswiki/Configure/Load.pm
@@ -40,26 +40,33 @@ provide defaults, and it would be silly to have them in two places anyway.
 sub readConfig {
     return if $Foswiki::cfg{ConfigurationFinished};
 
-    # Read LocalSite.cfg
-    unless ( do 'Foswiki.spec' ) {
-        die <<GOLLYGOSH;
-Content-type: text/plain
-
-Perl error when reading Foswiki.spec: $@
-Please inform the site admin.
-GOLLYGOSH
-        exit 1;
-    }
+    # Read Foswiki.spec and LocalSite.cfg
+    for my $file (qw( Foswiki.spec LocalSite.cfg)) {
+        unless ( my $return = do $file ) {
+            my $errorMessage;
+            if ($@) {
+                $errorMessage = "Could not parse $file: $@";
+            }
+            elsif ( not defined $return ) {
+                unless ( $! == 2 && $file eq 'LocalSite.cfg' ) {
 
-    # Read LocalSite.cfg
-    unless ( do 'LocalSite.cfg' ) {
-        die <<GOLLYGOSH;
+                    # LocalSite.cfg doesn't exist, which is OK
+                    $errorMessage = "Could not do $file: $errno $!";
+                }
+            }
+            elsif ( not $return ) {
+                $errorMessage = "Could not run $file" unless $return;
+            }
+            if ($errorMessage) {
+                die <<GOLLYGOSH;
 Content-type: text/plain
 
-Perl error when reading LocalSite.cfg: $@
+$errorMessage
 Please inform the site admin.
 GOLLYGOSH
-        exit 1;
+                exit 1;
+            }
+        }
     }
 
     # If we got this far without definitions for key variables, then

-- OlivierRaginel - 15 Jul 2009

Also, I forgot that one can "fix" this by simply creating a LocalSite.cfg with 1; in it:

echo '1;' > lib/LocalSite.cfg

-- OlivierRaginel - 17 Jul 2009

Olivier, that's good new. In fact, I had tried just creating an empty file with "touch", but as it didn't work I thought Foswiki may have been expecting some kind of specific structure, and I didn't realize about the 1; ending line to keep Perl "happy". If that fixes the problem maybe the next release should simply contain a dummy lib/LocalSite.cfg like that (and that may be a less risky solution than changing the behaviour of that crucial part of the code) ?

Of course, the aim you described would still not be met:

As for 1. I agree (and so does Crawford) that Foswiki shouldn't crash when there is no LocalSite.cfg, just like it should work without any LocalLib.cfg

I will also try your patch on one of my FreeBSD servers this week-end and report to you.

-- RaulFRodriguez - 17 Jul 2009

But it's odd, I've tried it without my patch, and I can't reproduce your behavior.

We discussed this on IRC with IsaacLin, and, even though I've seen users complaining about that before, I've never really understood the issue.

Normally, configure should work just fine without a LocalSite.cfg. Here, my guess is that, as you've protected it with Apache, Apache will see the protection, and issue a 401 to the browser. As we want the 401 to be the registration page (so the user can press cancel and have it), it will call the Foswiki engine to render it, and this will most likely fail, because there is no LocalSite.cfg.

Shipping a dummy LocalSite.cfg doesn't seem like a good solution to me, as we have the Foswiki.spec for exactly that purpose, which is why I'd rather use the patch I wrote.

But I'll call some other "historical" views on that one just to be sure

-- OlivierRaginel - 17 Jul 2009

This was marked as Urgent, with a lot of people in the Waiting for list, and nobody cared to answer.

Anyway, this behavior was "fixed" in trunk already, but wasn't very user-friendly. I've improved the reporting, and I'll close this bug.

-- OlivierRaginel - 28 Jul 2009

I just applied the patch to Load.pm against a fresh copy of 1.0.6, which cures "error when loading LocalSite.pm" (now allows configure to run without temporary modification to auto-generated apache config).

Environment:

• SuSE 10.2
• Perl 5.8.8
• Apache 2.2.3

-- PaulHarvey - 03 Aug 2009

Altered title to the fix that was actually applied.

-- KennethLavrsen - 05 Aug 2009

The applied fix (which I couldn't find back) solves the issue, but I think the reporting could be better, so I'll commit it here, and close it back. No need to put it in the release notes, as this has already been released in the release branch (most likely 1.0.7), and has never been an issue in trunk.

-- OlivierRaginel - 13 Feb 2010

Olivier, I tested your patch on an installation of Foswiki 1.0.9 affected by this problem.

i.e., I applied the following patch to the Load.pm from a Foswiki 1.0.9: http://trac.foswiki.org/changeset/6313

After applying the patch, the access to configure as described in this error report, without an existing LocalSite.cfg still fails, this time with another error message:

Foswiki Installation Error
Template "oopsaccessdenied" not found.

Check the configuration settings for {TemplateDir} and {TemplatePath}. 

This was tested on an updated FreeBSD 7.1-RELEASE box.

-- RaulFRodriguez - 16 Feb 2010

Raul, could you please test trunk against this? CDot rewrote many configure routines, and I'm pretty sure this has been fixed.

-- OlivierRaginel - 26 Mar 2010

No response from Raul yet, so pinging.

-- CrawfordCurrie - 10 Jun 2010

Sorry for the delay on this, and thanks for the reminder. It is on my TODO list, with lots of other things, but I will try to check this ASAP.

I am not sure the testing will be fully accurate, since the installation process is quite different when installing from an SVN checkout of trunk, compared to a regular installation from a tar.gz, but I'll report my findings here anyway.

-- RaulFRodriguez - 15 Jun 2010

As there are checkins against the release branch in this fix, I've changed it to "patch" and added 1.0.10 to the list of fixed codebase.

-- GeorgeClark - 18 Jun 2010

I can't reproduce the problem anymore on my various installations. The problem is that I can't reproduce it anymore whether on 1.0.9, on 1.0.9 patched as mentioned above, or on the current trunk. It looks like the reason why the affected system was generating this error is not there anymore, and that it is not (entirely) due to Olivier's patch in case of a patched 1.0.9.

As for trunk, like I said, I do not receive any error message, but I thought I should let you know the circumstances above.

-- RaulFRodriguez - 06 Jul 2010

OK, that's useful to know, thanks. I'm closing this no action. Any recurrence, re-open this task, with details of how to reproduce.

-- CrawfordCurrie - 07 Jul 2010