Upgrading from v3.2.0 no patches no modifications

So, we are upgrading from 3.2.0. We did the usual. We installed v6 and patch 1 first. We exported the database from v3 with the Drop Add table commands. Imported the v3 into the v6 database replacing the new tables with the old. Ran upgrade starting at 3.1.0. After fixing SQL errors along the way. I saved a few of them in the attached text file. We get to the end and could not log in with any of the known accounts.

tracy_migration_errors.txt (2.9 KB)

I did a new install then exported the username and password from the second v6 install to import into the first v6 install. That did not work because it gave me a column mismatch.

I am looking for suggestions on what can be done to log in.
In the past when upgrading from version 3x to 4x the passwords were moved to the users_secure table and the users table was marked as ‘nolongerused’. Well that does not happen in v6. The login fails and I check the table and the password is still in the users table password column.

Suggestions??

I was thinking of going back and do the upgrade to 4.2.2 first. Any comments on this topic are welcomed.

Delete sites/default/documents/logs_and_misc/methods/sixa and sixb then log in.
v5.0.2 or v6

Oh @sjpadgett , if only it was that easy. I went ahead and did it again. No joy. After deleting the keys, I still cannot login. I checked the error log and there is nothing in there.

Re run your upgrade script again at 501. sounds like password conversion was maybe missed. otherwise ???

1 Like

Looks like I need to go looking for the password conversion. Running the script again did not produce the desired results. I will let you know what I find.

UPDATE users_secure SET password = '$2a$05$MKtnxYsfFPlb2mOW7Qzq2Oz61S26s5E80Yd60lKdX4Wy3PBdEufNu', salt = '$2a$05$MKtnxYsfFPlb2mOW7Qzq2b$' WHERE username = 'admin'

That would work but

 mysql> select username, salt from users_secure where username = 'admin';

ERROR 1054 (42S22): Unknown column ‘salt’ in ‘field list’

Remember 3.2.x did not have a users_secure. That did not come about until 4.2.x

And v6.x has no salt column. No, we tried to make the leap from 3.2.0 to 6.0.1 no stops in between.

I suggested that we might have to do the upgrade to 4.2.2 log in and get the conversion then do the upgrade to v6.

Also, v6 drops the salt columns so from v3 - v6 there will be no salt column

but you upgraded to 5?

@sjpadgett has good advice to try to get to 5 and then try logging in

1 Like

What if you follow these 3 upgrade steps from your 3.2.0 (don’t install 6.0.0 and try to go backwards, but instead start from 3.2.0) (note the first 2 upgrades below involve directory shifts):

  1. https://www.open-emr.org/wiki/index.php/Linux_Upgrade_3.2.0_to_4.0.0 (3.2.0 to 4.0.0)
  2. https://www.open-emr.org/wiki/index.php/Linux_Upgrade_5.0.1_to_5.0.2 (4.0.0 to 5.0.2)
  3. https://www.open-emr.org/wiki/index.php/Linux_Upgrade_5.0.2_to_6.0.0 (5.0.2 to 6.0.0)
1 Like

It also looks like that when passing 4.1.2 (Using RSA public/private key pairs to exchange password information. · openemr/openemr@c9a5aa4 · GitHub), the passwords will need to all be reset since pretty sure the backward compatibility for md5/sha1 unsalted hashed passwords is no longer supported. Can set password for admin in users_secure to (after complete 3 above upgrade steps):

$2a$05$.hH4Godes3dORmHjOjtXXekQPf2n5tQsw2H/ahwsBECLA/QCgWRS.

(the password for this hash is ‘pass’)
then when get in from there can reset all the users passwords via Users gui.