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 have a question you asked answered by someone - please remember to edit the page and set the status to answered. The status is in a drop-down list 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