After upgrading to 0.6.5 via web interface (and also after a new manual installation) the web interface's stylesheet is gone and "Oops problem during the request, please try again."-message appears. Maybe the priority of this bug is even "critical".
Apache Access Log says:
x.x.x.x - - [23/Jul/2010:21:11:54 +0200] "GET /piwik/tmp/assets/8c06f99faa9d140d731f08decd24e5d5.css HTTP/1.1" 403 255 "http://xxxxxxx/piwik/index.php?module=CoreHome&action=index&idSite=1&period=day&date=yesterday" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:126.96.36.199) Gecko/20100715 Ubuntu/10.04 (lucid) Firefox/3.6.7" x.x.x.x - - [23/Jul/2010:21:11:54 +0200] "GET /piwik/tmp/assets/6af420abb70510fee98e0926d5e90f78.js HTTP/1.1" 403 254 "http://xxxxxxx/piwik/index.php?module=CoreHome&action=index&idSite=1&period=day&date=yesterday" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:188.8.131.52) Gecko/20100715 Ubuntu/10.04 (lucid) Firefox/3.6.7"
The directories in /tmp/ have only rwx permissions for owner:
drwx------ 2 user1 user1 4.0K Jul 23 21:10 assets drwx------ 3 user1 user1 4.0K Jul 23 21:05 cache drwx------ 2 user1 user1 4.0K Jul 23 21:04 latest drwx------ 2 user1 user1 4.0K Jul 23 21:10 sessions drwx------ 2 user1 user1 4.0K Jul 23 21:05 templates_c
JS and CSS in /tmp/assets/:
-rw------- 1 user1 user1 377K Jul 23 21:05 6af420abb70510fee98e0926d5e90f78.js -rw------- 1 user1 user1 60K Jul 23 21:05 8c06f99faa9d140d731f08decd24e5d5.css
After manually doing cmhod g+rx tmp/* and chmod g+r tmp/assets/* the web interface is working again (on my system the user apache is running as is in group user1 - thus read access for group is sufficient in my case).
Maybe the the script, that creates the files and directories, should do a chmod afterwards. (I don't know if there is a best-practise to automatically determine which would be the minimal-sufficient permissions. a+rx and a+r would be the easiest.)
An addition: my system's default umask is 0027.
on every page view, in the FrontController in init:
$directoriesToCheck = array( '/tmp/', '/tmp/templates_c/', '/tmp/cache/', '/tmp/assets/' ); Piwik::checkDirectoriesWritableOrDie($directoriesToCheck);
This should have triggered an error asking you to put write permissions on the directory.
The testing code is in Piwik::checkDirectoriesWritable()
Somehow I expect your directories to have is_writable() == true, but still they are not writable by the web server.
Why is that that is_writable returns true in checkDirectoriesWritable? any idea?
Note that if the webserver can't write in tmp/cache/ this is pretty bad for performance, as Tracker will be doing potentially several SQL reads per page view, instead of caching in files the website data.
I'm running PHP as CGI with SuExec. So PHP-scripts are executed as user1 and have full (read+write) permissions, but the webserver-user itself is just in the user1-group and thus can have other permissions to the files than the PHP-scripts.
If php runs with suexec, what is user1's umask?
The umask is 0077 when testing with <? passthru('umask'); ?>.
<? echo decoct(umask()); ?> returns 77 too.
I checked out and tested trunk - the files now have sufficient permissions, but the tmp/assets-directory still needs a chmod g+x so that the webserver is able to read files within it.
The problem is, that the permissions that are passed to Piwik_Common:mkdir when creating the directory are masked by the umask too.
When i add
<a class='mention' href='https://github.com/chmod'>@chmod</a>($path, $mode); // bypass too restrictive umask
directly after the mkdir call in line 311 in Common.php it's working. But I'm not sure if it's a good solution to bypass the umask everytime for all directories...
(In ) refs #1507 - override umask only on public folders
Note: we're switching to a php proxy in #1527 -- I'll revert some/all of the previous changes once the new code is commited.