Item13076: Bug: LdapContrib fails to create cache.db on FreeBSD

1. hire somebody to fix the bug for you; think of it as a donation to those people making a living from Foswiki
2. fix the bug yourself; FLOSS lives from volunteers like you to improve software. Patches welcome!!!
3. neither of above; the bug will remain unfixed for you

1. We do NOT have anachronistic insistence on Apache, CGI and the lot. Foswiki works just fine with FastCGI or Mod_perl, and it works and is tested under Nginx, and Lighttpd as well as apache. We are still looking for a volunteer to support IIS.
2. As far as CGI goes, Foswiki roots go back to 1998. So it's an evolution. From http://openhub.net, Foswiki "... has had 25,076 commits made by 76 contributors representing 4,292,065 lines of code." and "... took an estimated 1,265 years of effort (COCOMO model) starting with its first commit in October, 2008 ending with its most recent commit 1 day ago" (Though a lot of that is jquery) We don't insist on CGI, but there is a bit of a codebase that needs volunteers to help modernize.
3. We also don't insist on Linux. We test on Windows and various flavors of linux, though mainly with apache. But Foswiki.org runs on FreeBSD, so that's covered as well. However our public site on freebsd doesn't use LDAP, so we just don't have that particular combination available.
4. RcsLite being busted is probably a bit of an overstatement. In Foswiki 1.1.9, we invoke RCS a bit too often, and RcsLite is slow, but mainly with large binary files. (It expands history in memory). It's also due to some overzealous validation of the revision history, as well as some bugs. It's improved in the upcoming 1.2.0 There is also a hotfix for 1.1.9 that can improve RCS performance a bit. So I'd say better advice is to use it with caution. Foswiki.org runs with FastCGI and RcsLite, so it's certainly not that broken.
5. Also in upcoming 1.2, we've made a PlainFile store the default store for new sites. No RCS involved. So these things are being addressed, just not as fast as we would like.
6. For FastCGI, RcsWrap is also usable. You have the overhead of the fork, but it is much less severe than on mod_perl where the fork applies to the entire apache install.
7. Also in the upcoming 1.2, volunteers have completely rewritten configure. It no longer requires CGI either. And we are testing install of 1.2 on Nginx / fcgid "out of the box" to ensure a better installation experience. With 1.2, the experience we are testing towards is:
   • Unzip foswiki
   • Configure webserver to point to correct file system locations
   • Visit your default View URL, short, long, however you want it.
   • Foswiki bootstrap code detects critical settings, "just works" and provides you with a link to configure to check & save the discovered configuration.

• If you have not done so, create a bin/LocalLib.cfg. (Copy example from bin/LocalLib.cfg.txt. Only change needed is to remove the comment (#) from the line: #$ENV{FOSWIKI_ASSERTS} = 1; That enables additional debug checks in Foswiki code and can sometimes reveal things. It also causes stack traces to go to the browser instead of the logs.
• Try running the failing command from the shell. cd to your bin directory, and run ./view -topic SomeTopic ... Running outside of the browser / CGI environment can reveal things sometimes.
• From there, I'd be probably adding print statements to code, both Foswiki and perl modules, trying to get a better picture of what is failing. Or use the perl debugger to try to find and step into the failure to better understand it.

--- data/foswiki-extensions/lib/Foswiki/Contrib/LdapContrib.pm  (revision 1090)
+++ data/foswiki-extensions/lib/Foswiki/Contrib/LdapContrib.pm  (working copy)
@@ -781,7 +781,7 @@ sub tieCache {
    unless (-e $this->{cacheFile}) {
      $locking->{'mode'} = 'write';
      my %db_hash;
-    my $x = tie(%db_hash, 'DB_File::Lock', $this->{cacheFile}, O_CREAT, 0664, $DB_HASH, $locking);
+    my $x = tie(%db_hash, 'DB_File::Lock', $this->{cacheFile}, O_CREAT|O_RDWR, 0664, $DB_HASH, $locking);
      undef($x);
      untie(%db_hash);
      $locking->{'mode'} = $mode;