Question

Can't get TWiki-4.2.0 working on FreeBSD 6.2-Release

I've followed the directions and searched the docs but can't find any reference to this issue. I get as far as clearing up warning and errors in the configure page, but when I try to go to View, I get this:

flush(): couldn't store datastr: store(): couldn't open '/var/www/vhosts/handbook3.bresnan.net/working/tmp/cgisess_f0f58d175d086020e5c91bf837126d27': Permission denied at /var/www/vhosts/handbook3.bresnan.net/lib/TWiki/LoginManager.pm line 542.

The httpd log as the same message.

I've tried everything I can think of as far as Apache and permissions/ownership goes. I've had two other Unix admins look at it also.

One thing I don't like is that the CGI Setup has my username under CGI User. The docs say that apache controls this (not a TWiki issue) but it's not the user that apache is running as. I can't figure out why it would have my username as the CGI User. But I don't know if this is the actual problem.

Environment

-- LarryDillon - 21 Jul 2008

Answer

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.

Apache has some features to run scripts in other security contexts than www-data/wwwrun/httpd. Ie. suexec is such a mechanism. In some configurations scripts are executed in the context of the file owner. Please make sure, the effective user (the one shown in bin/configure) has write access to the working directory and/or tmp.

-- OliverKrueger - 25 Jul 2008

Oliver, thanks for the reply. From what the error message says, the problem seems to revolve around either permissions to the working/tmp directory or the user httpd is running as. To test this I wrote a little cgi script, with the same ownership and perms as TWiki's scripts in bin/:

#!/usr/bin/perl
print "Content-type: text/html\n\n";
$date = `date`;
print "$date \n";
$id = `id`;
print $id;
system("echo `date` > /var/www/vhosts/handbook3.bresnan.net/working/tmp/mytest.txt");
system("echo `id` >> /var/www/vhosts/handbook3.bresnan.net/working/tmp/mytest.txt");


My script works as expected, has no problem writing to working/tmp and, more interestingly, verifies that "www" is the ID doing the writing. www is the user that a "ps -aux" verifies as the user httpd is running under. This is CONTRARY to what TWiki's bin/configure shows as the cgi user. Again, it shows my username there. I had a co-worker use sudo to restart apache and TWiki's bin/configure then showed his username as the cgi user. I do not believe that this should be the case.

I originally installed TWiki from tarball but, thinking I might have done something wrong, had a co-worker install it from ports. Exact same results.

-- LarryDillon - 25 Jul 2008

Digging deeper, I notice that bin/configure uses: $WebServer_uid = getlogin() || getpwuid($>) || ''; to determine the webserver's id.

getlogin() returns my username whereas getpwuid($>) returns www

I can edit this line to make configure return www on the configuration web page, but I still get the same error.

-- LarryDillon - 25 Jul 2008

Oliver, to answer your question, the working/tmp/cgisess_* files get created, with www as the owner, just fine. But TWiki can't seem to "lock" the files it just created:
flush(): couldn't store datastr: store(): couldn't lock '/var/www/vhosts/handbook3.bresnan.net/working/tmp/cgisess_97bf1dce88f0e9e1ada24fea0f349ee0': Operation not supported at /var/www/vhosts/handbook3.bresnan.net/lib/TWiki/LoginManager.pm line 542.

-- LarryDillon - 25 Jul 2008

Turning off UseClientSessions under Security and copying TWikiUserMapping.pm (a FreeBSD ports thing) to lib/TWiki/Users/ seems to have fixed this.

-- LarryDillon - 25 Jul 2008

Turning of UseClientSessions isn't going to be a long-term solution.

-- LarryDillon - 29 Jul 2008

This turned out to be a NFS file locking problem.

-- LarryDillon - 29 Jul 2008