CiviCRM 4.2 and higher require more SQL privileges than past versions or binary logging disabled

Not sure how to reproduce the problem? We have tested cloning and migrating CiviCRM 4.2.4 D7 sites and there were no issues.

Hmm, while cloning works fine, migration 4.2.4 -> 4.2.4 fails (but with probably unrelated errors) and also 4.2.2 to 4.2.4 fails (but I'm not sure if it worked before for older versions).

The errors we see are:

Drush command terminated abnormally due to an unrecoverable error. Error: Cannot redeclare class CRM_Core_ClassLoader in /data/all/002/civicrm-4.2.2-7.16.1/sites/all/modules/civicrm/CRM/Core/ClassLoader.php, line 36

There are no other errors and we didn't experience any "You do not have the SUPER privilege and binary logging is enabled" error while testing CiviCRM 3.4.8 D6, CiviCRM 4.1.6 D6, CiviCRM 4.2.2 D7 and CiviCRM 4.2.4 D7.

Do you use the platforms which come with Octopus?

I can't reproduce the original problem, so I'm moving this to the provision_civicrm queue.

Feel free to move it back if there is any way to reproduce the problem using platforms installed by Octopus.

It is also possible that it would require some content created, so testing on vanilla sites with just enabled CiviCRM will not reveal it.

I can confirm that there seems to be an issue with Provision CiviCRM. I get the error described in #3 while just having civicrm and memcache enabled.

While trying to migrate from 7.15 with 4.2.1 to 7.15 with 4.2.2 the problems began. Today I tried again and were not able to do the upgrade with aegir and provision_civicrm.

None the less the manual upgrade, first of civicrm from 4.2.1 to 4.2.6 and later of Drupal 7.15 to 7.17 worked without any issues. So since manual upgrades work it's not a critical issue for me, but it still breaks the work flow and is just a little bit too inconvenient.

But still migrating and cloning from a platform with 7.17 + 4.2.6 to another platform with 7.17 + 4.2.6 gives me the same error. Verifying works.

I'm not sure if this is the right issue or if that is not connected to the SQL issues. But since I can reproduce the error maybe I can help solving it or test patches or workarounds.

Are we talking about the initial bug report, or the one about the ClassLoader in #3?

I'm also getting the ClassLoader issue.

About "Super" privileges: yes, if you have a multi-lingual site, or database logging of changelogs, CiviCRM uses triggers. If you have binary logging / replication, mysql requires SUPER, since it runs the trigger from the log as root (ex: on the secondary mysql server).

I was talking about the ClassLoader error. I posted here because I found exact the same error message I got in the comments, but it seems I should have opened a separte issue.

Since, as I described above, the manual upgrades work I don't think that there are any problems with my database settings / configuration. On the other hand I'm neither a database specialist nor a programmer and I thought maybe these two are somehow related in a way that I don't get.

Hi,
Any update on civicrm clone/migration issue?

I'm still getting an error cloning/migrating via AEgir a web site from platform D7.14 + Civi 4.2.2 to D7.18 + Civi 4.2.6

Drush command terminated abnormally due to an unrecoverable error. Error: Cannot redeclare class CRM_Core_ClassLoader in
/. . . /sites/all/modules/civicrm/CRM/Core/ClassLoader.php, line 36

Thanks in advance!

I opened #1907884: Migrations Fail - Error: Cannot redeclare class CRM_Core_ClassLoader to deal with the ClassLoader error. Please continue that discussion there.

ClassLoader issue is now fixed: #1907884: Migrations Fail - Error: Cannot redeclare class CRM_Core_ClassLoader

Regarding the SUPER privileges, I'd say it's hosting-specific. I'm not very familiar with BOA, but if it enables binary logging by default, it's a BOA-specific issue. On a mysql server without binary logging, you only need the "trigger" privilege, and it works fine.

Note that if you give "super" privileges to your mysql users, this means they can read/write on any database.

Also, the reason why mysql requires super privs for replication, is that the binary logs are run as the root user, so an attacker could use triggers to read/write in another database.

OK, so we have only BOA-specific issue left here now and the other issue fixed in another thread, I'm moving it back to the Barracuda queue, to avoid further duplicates like: #1918296: CiviCRM Extensions fail on install - MariaDB config

Binary logging is now optional and defaults to NO: http://drupalcode.org/project/barracuda.git/commit/dd43ec6 - this should fix the problem, AFAIK.