mysql 5.7 & login_history module problem with Opigno 1.29 and later

boyd.badten
Forums
I'm running Opigno on Ubuntu 16.04 with Mysql 5.7 and PHP7.0. Generally running pretty good. But when I upgrade to Opigno 1.29 or 1.30 your upgrade process forces the upgrade of the login_history module from 7.x-1.0 to 7.x-1.1. This newer version of login_history module is known to be broken with mysql 5.7---see: https://www.drupal.org/project/login_history/issues/2944461 If a person is running mysql 5.7 and upgrades to Opigno 1.29 or later, as mentioned above they receive the error: Failed: PDOException: SQLSTATE[42000]: Syntax error or access violation: 1171 All parts of a PRIMARY KEY must be NOT NULL; if you need NULL....etc. ........the new login_history module is trying to write some new columns in the db in a way which is illegal in mysql 5.7 or later. Getting a scary message and module upgrade failure is one thing, but then with the login_history module broken, LOGINS BY NON-ADMINS FAIL. Visitors can't log in to the site. I was able to temporarily disable opigno_stats and login_history [dependency] modules and replace the login_history module files found in "var/www/profiles/opigno_lms/modules/contrib' with the files from the older login_history 7.x-1.0 module, re-enable login_history and opigno_stats modules and it seems to be working fine again with the Opigno 1.30 version. It might be good to allow us to choose the option to update modules during an opigno version upgrade instead of forcing it on us. Also, I wonder if you guys have encountered this problem---or if everyone is running old versions of linux and mysql? Perhaps I'm missing something and there is an easier way of dealing with this? I'm not very interested in running old versions of things. The default mysql for Ubuntu 16.04 is 5.7 and it's not really very new any more.
axel

This is a known issue with

This is a known issue with Drupal 7 and MySQL 5.7

Try to apply this patch, it should fix the issue:

https://www.drupal.org/files/issues/D7-2615496-68.patch

 

boyd.badten

I tried that patch and got burnt hash

I know you didn't write this patch axel----but have you ever applied it? I'm not sure what the heck happened---here it is: ********************************************************************************************* patching file schema.inc Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] y Hunk #1 FAILED at 335. 1 out of 1 hunk FAILED -- saving rejects to file schema.inc.rej patching file schema.inc Hunk #1 FAILED at 357. Hunk #2 FAILED at 374. 2 out of 2 hunks FAILED -- saving rejects to file schema.inc.rej patching file schema.inc Hunk #1 FAILED at 324. 1 out of 1 hunk FAILED -- saving rejects to file schema.inc.rej can't find file to patch at input line 78 Perhaps you should have used the -p or --strip option? The text leading up to this was: ****************************************** |diff --git a/modules/simpletest/tests/schema.test b/modules/simpletest/tests/schema.test |index 4199428..8d810f5 100644 |--- a/modules/simpletest/tests/schema.test |+++ b/modules/simpletest/tests/schema.test ******************************************** I think it was asking me if I wanted to reverse a previous patch---I said no....go ahead and apply. "Hunk Failed" indigestion. It left a schema.inc.rej file and a schema.inc.orig file. Site was dead until I renamed the orig file to schema.inc. Seems like the patch does not work in some cases. I looked on the page that this patch comes from and the discussion and succession of patch attempts. I can't find any proposed patches that pass with mysql 5.7. Another thing----what about all those sections of the patch below line 30 which refer to pgsql/schema.inc, sqlite/schema.inc and the modules/simpletest....etc. stuff? I'm using mysql----do you think I should delete those sections below line 30 and retry it? Sorry to draw you into this. I've applied patches before. But this one is pretty complicated and messy compared to anything I've seen before and it obviously failed for reasons unknown to me. I'll mention it again. You guys might consider not forcing people to upgrade login_history module during the Opigno 1.29+ updaters. I can't be the only person running Ubuntu 16.04 and the native mysql 5.7 that comes with it. Opigno 1.29 and 1.30 seem to work fine with the old login_history 7.x-1.0 version Thanks for any wisdom you might like to share.
axel

Hello,

Hello,

Yes I applied this patch, it worked like a charm.

The messages you get are strange.

Instead of applying the patch, you can try doing a manual change in your database to avoid the alter query being blocked

boyd.badten

Cannot update to Opigno 1.31--Drupal 7.59 HELP!

I'm still in the same problem as described above---except I was able to update to Opigno 1.30 and revert the forced update of login_history module to the previous one and my site still worked fine on Opigno 1.30. But now It reports a serious error during the update process to Opigno 1.31 and the site will never come up again after that. Error is: Notice: undefined index: update_success in Update_results_page()(line 177 of ?var/www/update.php). Warning: reset() expects parameter 1 to be array, null given in update_results_page() (line 181 of /var/www/update.php). Warning: array_pop() expects parameter 1 to be array, null given in update_results_page()(line 182 of ?var/www/update.php). The update process was aborted prematurely while running update # in .module. Now it seems that I absolutely cannot update to Opigno 1.31. This is a problem because there is a serious vulnerability still in Drupal 7.58/Opigno 1.30 which I would REALLY LIKE TO PATCH OR UPDATE. The problem, is that your Opigno update process forces the updating of a module which is incompatible with mySQL 5.7. No Axel, I cannot fix this directly in the mySQL database---there is nobody on my staff who understands how to do such a thing. And I documented above that I tried applying the patch you pointed out and it failed for me. If you look at the developers documentation for the patch we were discussing above, it has not been tested or passed for mySQL 5.7---only 5.5. Directing everyone who might be using Ubuntu 16.04 (released in mid 2016) to apply this really sketchy patch or to manually change something directly in their DB in order to be able to update to Opigno 1.31 and avoid Drupalgeddon---is that your standard solution at this point? Can you give me a method of updating my Opigno without a forced update of the buggy module login_history v.7.x-1.1? If you look at the comments of the module maintainers, they admit that they have an unsolved problem with mySQL 5.7---which is far from bleeding edge. Updating to login_history v.7.x-1.1 breaks Opigno sites which run on the 2-year-old Ubuntu 16.04 and the accompanying mySQL v5.7. Opigno and the Opigno Statistics App work fine with the older version of login_history v.7.x-1.0 (which is required by the Opigno Statistics App). Here is what the login_history module bug report says about the new verson of this module--which you are forcing us to update to. The issue I'm speaking about is listed as Critical and Unassigned. The module maintainer's comments are, "This is bad. I'm not sure what to do about this at this point. Anyone have thoughts?". Nobody is working on this problem at the module team---it's unassigned. They're testing the module for release only on PHP5.5 and MySQL5.5. Does that mean that Opigno, which requires this module, can only run on these very old PHP and MySQL versions and is not ready for PHP7 or MySQL 5.7? That's what it means to me I guess---except I started my Opigno site using the 2-year-old Ubuntu 16.04---thinking that this is a very mainstream distribution. Is there a way to run the update to Opigno 1.31 without being forced to update the login_history module???? I'm really sorry if I sound upset. I'm trying to love and use Opigno for a serious part of our organization. But this issue is really becoming a deal-breaker.
James Aparicio

H boyd.badten,

H boyd.badten,

Its not rocket science really. Drupal has an issue adding a primary key to an existing db programatically with the specific version of mysql you are using.

Either you apply the patch to drupal that fixes that issue, allowing the login_history module to update or you comment that code inside the update function of the login_history and manually do the changes to the db. 

If you dont want to do any of the above simply replace the login_history with the older version so that everything is updated except that specific module.

If you think no one on your staff is capable of doing any of these 3 procedures, we are more than glad to help you out. https://www.opigno.org/en/professional-services/professional-support

Best regards