For Installation, we would store session information in a signed cookie, and delete the cookie when the installation is complete.
Note: Piwik still requires write access to ./tmp (i.e., templates_c, cache/tracker, latest).
While you're at it, add a systemCheck for the 'session' extension, in case php was compiled with --disable-session.
And look into handling disabled ini_set() -- used by Zend_Session.
Oh, and make sure we handle the case where session.use_cookies = 0 (ref: http://forum.piwik.org/index.php?showtopic=11381)
(In ) refs #1279 - refactor session initialization code out of index.php
(In ) refs #1279 - test that session.save_path is also readable, otherwise
session file cleanup may fail, e.g.,
Zend_Session_Exception: Zend_Session::start() - /PATH/libs/Zend/Session.php(Line:480): Error #8 session_start(): ps_files_cleanup_dir: opendir(/var/lib/php5) failed: Permission denied
I've confirmed on my fresh install that this patch fixes the exception output. Thank you.
Reprioritizing. On the demo server, I noticed we have 285000+ session files in piwik/tmp/sessions -- most being empty files. That's a lot of inodes, and could be a problem for some users with shared hosting accounts.
Nice to have:
Using a DB table should avoid the potential race condition experienced with locked session files (see #2296).
CI shows the update fails:
[22-May-2011 19:05:51] PHP Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[42S02]: Base table or view not found: 1146 Table 'piwik_qa.canoo_session' doesn't exist' in /home/www/data/root/jenkins.private/jobs/Piwik/workspace/build/libs/Zend/Db/Statement/Pdo.php:228 Stack trace: <a href='/0'>#0</a> /home/www/data/root/jenkins.private/jobs/Piwik/workspace/build/libs/Zend/Db/Statement/Pdo.php(228): PDOStatement->execute(Array) <a href='/1'>#1</a> /home/www/data/root/jenkins.private/jobs/Piwik/workspace/build/libs/Zend/Db/Statement.php(300): Zend_Db_Statement_Pdo->_execute(Array) <a href='/2'>#2</a> /home/www/data/root/jenkins.private/jobs/Piwik/workspace/build/libs/Zend/Db/Adapter/Abstract.php(479): Zend_Db_Statement->execute(Array) <a href='/3'>#3</a> /home/www/data/root/jenkins.private/jobs/Piwik/workspace/build/libs/Zend/Db/Adapter/Pdo/Abstract.php(238): Zend_Db_Adapter_Abstract->query('DESCRIBE `canoo...', Array) <a href='/4'>#4</a> /home/www/data/root/jenkins.private/jobs/Piwik/workspace/build/core/Db/Adapter/Pdo/Mysql.php(211): Zend_Db_Adapter_Pdo_Abstract->query('DESCRIBE `canoo...', Array) <a href='/5'>#5</a> /home/www/dat in /home/www/data/root/jenkins.private/jobs/Piwik/workspace/build/libs/Zend/Db/Statement/Pdo.php on line 234
This is great feature because it will ensure that load balanced Piwik Reporting UI will work fine without requiring to "stick" same users to the same backend server!
(In ) Refs #1279 Important to copy paste the table definitions in update files: this ensures that subsequent "ALTER" on these tables will work fine (otherwise, if we change table definition in myisam file in 1.8, and users upgrade from 1.4 to 1.9, the 1.5 upgrade will install the newest version of 1.8 tables which will then fail the 1.8 ALTER table on this table..)
I had to move the Piwik_Session::start() to front controller because the save handler needs the $db handle.
Purge: the frequency of cleanup and lifetime is defined in php.ini (e.g., session.gc_maxlifetime)
re: r4767 Good point. I'll go back and fix those cases in 0.2.10, 0.2.13, and 0.2.27, so we don't set a bad example. ;)
I'm just installing 1.0 now, and going through the auto-update to find out what's causing the problem in comment:30.
on the update screen I see an error at the bottom, not important but if easy to hide would be nice :) (see attached file)
Yes, I saw the exception too. This is fixed in r4772. I'm just waiting for confirmation from Jenkins before I close this ticket.
Thank you, Jenkins.