Opened 23 months ago

Closed 22 months ago

Last modified 21 months ago

#3204 closed Task (fixed)

Piwik should not require mysql LOCK privilege so more users can enjoy Free Web Analytics!

Reported by: matt Owned by:
Priority: major Milestone: 1.x - Piwik 1.x
Component: Core Keywords:
Cc: Sensitive: no

Description

Since Piwik 1.8 (tickets #2984 and log deletion #2805), we require the LOCK privilege to install Piwik. Apparently, some web hosts have disabled it and refuse to enable it.

If you experience the problem that your web host does not allow LOCK privilege on the piwik mysql user, but you would like to use Piwik, please comment in this ticket. Thank you!

Change History (9)

comment:1 Changed 22 months ago by capedfuzz (diosmosis)

  • Resolution set to fixed
  • Status changed from new to closed

(In [6483]) Fixes #3204, removed LOCK TABLES privilege check from installation. Modified LogDataPurger so log_actions are not purged if the lock tables privilege is not granted.

comment:2 Changed 22 months ago by capedfuzz (diosmosis)

Committed a fix for this, but there's still one other instance of LOCK TABLES in ArchiveProcessing::loadNextIdarchive. I don't think its necessary, but I didn't write the code so I've left it for now. Is locking necessary here? If it is, I think it can be replaced w/ GET_LOCK.

comment:3 follow-up: Changed 22 months ago by matt (mattab)

It is "necessary" to make sure that when several archives are requested at the same time, they have a distinct idarchive allocated. Sounds good if we can use GET_LOCK instead. Could we not use GET_LOCK for the log deletion from log_action as well btw?

Also it would be nice to say in the UI, in the inline help "The table log_action will not be purged: please grant the LOCK privilege to the %s Mysql user" so that users understand that the feature is limited pending the privilege.

comment:4 in reply to: ↑ 3 Changed 22 months ago by capedfuzz (diosmosis)

Replying to matt:

It is "necessary" to make sure that when several archives are requested at the same time, they have a distinct idarchive allocated. Sounds good if we can use GET_LOCK instead. Could we not use GET_LOCK for the log deletion from log_action as well btw?

The reason I think the locking might not be necessary is that the INSERT INTO SELECT should lock the table itself. Do you know of a situation where it wouldn't?

And I don't think GET_LOCK will work for log_action purging. For log_action purging we need to make sure no visits/link_actions/conversions/etc. are added while actions are being deleted and GET_LOCK won't do that (unless you add a GET_LOCK call to the Tracker).

Also it would be nice to say in the UI, in the inline help "The table log_action will not be purged: please grant the LOCK privilege to the %s Mysql user" so that users understand that the feature is limited pending the privilege.

Ok, will get to it soon...

comment:5 Changed 22 months ago by matt (mattab)

The reason I think the locking might not be necessary is that the INSERT INTO SELECT should lock the table itself. Do you know of a situation where it wouldn't?

maybe a GET_LOCK would be enough here....? but we need the lock.
it was a patch suggested by power user lorieri which fixes an edge case bug hard to reproduce, so I'm reluctant to break it again by removing the lock :)

And I don't think GET_LOCK will work for log_action purging.

Thanks for reminding me.

comment:6 Changed 22 months ago by capedfuzz (diosmosis)

(In [6485]) Refs #3204, added extra info message to privacy manager purge function when lock tables privilege is not granted to user & replaced lock tables sql in ArchiveProcessing w/ GET_LOCK.

Notes:

  • Added Piwik_GetDbLock & Piwik_ReleaseDbLock functions.

comment:7 Changed 22 months ago by parisbonbon

comment:8 Changed 21 months ago by matt (mattab)

  • Priority changed from normal to critical
  • Summary changed from Piwik should not require LOCK privilege? to Piwik should not require mysql LOCK privilege so more users can enjoy Free Web Analytics!

comment:9 Changed 21 months ago by matt (mattab)

  • Priority changed from critical to major
Note: See TracTickets for help on using tickets.