Developers Log : upgrading from v3.2.0 to v7.0.0

Day-to-Day Users
#1

I thought this would be a good write up for life experience with upgrading from v3.2.0. The problem that I have come upon is the conversion of the user accounts. Once the upgrade was completed, no one could log in.

Steps taken:

  1. Installed a fresh copy of v7.
  2. Exported v3.2.0 database and imported it into the v7 created database.
  3. Ran the upgrade script and fixed errors like codes column missing from layout_options. easy stuff.

After the upgrade displayed completed, I tried to log in with one of the previous accounts from v3. No access granted. Also the system did not attempt to try and upgrade the credentials like it did when upgrading from v3 - v4.2.2.

I tried entering the credentials that were created when the clean copy was installed. Those credentials do not work now. I am working on how to get into the program after upgrading from v3.
One way to do it is to find a old copy of php, mysql, and apache for v4.2.2 and install it on a server. Then do the incremental upgrade from v3.2.0 - v4.2.2. This I have not tried but I theorize this would fix the login issue.

After a much digging, I read the error log and found this message.

  [Wed Nov 23 11:28:49.971962 2022] [php:notice] [pid 10809] [client 70.169:55768] OpenEMR Error : Decryption failed authentication.
  [Wed Nov 23 11:28:49.971998 2022] [php:notice] [pid 10809] [client 70.169:55768] OpenEMR Error : Key in drive is not compatible (ie. can not be decrypted) with key in database - Exiting.
  [Wed Nov 23 11:29:43.895517 2022] [php:notice] [pid 10806] [client 70.169:55828] OpenEMR Error : Decryption is not working because of unknown encrypt/decrypt version.

I will state the obvious. Something is breaking the encryption. That is why the login is not working.

UPDATE 12-1-2022:
I figured out a way to do the upgrade that does not follow the normal convention but did eventually work for me.

In my opinion, there is no upgrade path for the users and user_secure tables. The users_secure table did not exist in v3.2. I did not find a way to leave the user table in place and run the upgrade script. What I ended up doing was to import all tables but the users table.

For the users table only, I exported it to CSV from the v3.2. I added all of the missing columns to the CSV so that I could import all the users into v7.x. Once I was able to import all of the users. Then I was able to set new passwords for the active users. The calendar came up and so far so good.

UPDATE: 12/8/2022
A new issue has arose. In the past, when upgrading from version 3 to v4.2.2. There was an upgrade script to convert the logins on the first time that the user logged in. If the user has forgotten their password. The admin cannot create a new login for them because the code looks for the user in the users_secure table in which they do not exist. So, admin cannot create a new password for that user.

1 Like
#2

This is relevant to my interests, as there are several running installs of OpenEMR V4.x that I’ve been prototyping the upgrade path to V7 for, and thus far I cannot find a way to step through the necessary update stages to get there.
It’s possible to run the upgrade tool from 4.X to 5.0 (5.0.1 & 5.0.2, the upgrade routines aren’t functional). But it results in a system that can’t be logged into. Trying to run the next stage, and either upgrade from 5.0.0 to 6.0, or to 7.0, when it reaches the UUID update phase the code goes into infinite SQL query loops and never returns. I left one running for a week just to see if it really was something that took an extraordinarily long time, but it never finished, never got out of the UUID query loop, and never made any alterations to the tables that the running queries reported they were working on.
Seeing your issues with starting from v3.2, I feel somewhat fortunate that these are at least going from a 4.X base, but at this point it’s looking increasingly likely that there is no possible path for working installations from versions < V7 to ever successfully make it to to >= V7.
Next week I will begin a fresh set of tests, but run all the database upgrade sequences manually step by step, it will be tedious but that’s the only thing I can think of that offers a chance of determining exactly where the process is breaking down. I initially suspected a MySQL issue, but after multiple tests using MySQL 5.7, MySQL 8.0, and MariaDB 10.5, every upgrade run broke down in the same place.
I guess plan B, would require maintaining the V4 or V5 installations indefinitely in a static virtual environment, then importing patient data into a clean V7 installation and essentially making a clean start. That’s going to result in some very upset people because we’re talking about working environments with 10s of thousands of stored encounters, hundreds of thousands of linked patient documents, and close to a decade of clinical history.
If I run across any clues or end up in the same situation as you with regards to the user auth issues, I will certainly share any fixes here.

#3

hi @Penguin8R , have recently successfully updated from 4.2.2 to 7.0.0. patch 2

you might need to beef up your memory and mariadb settings to speed the uuid update along

#4

@Penguin8R, @stephenwaite is right.
You can’t run v7 on the same server hardware as v4. I ran into the loop you are referring to. For hardware, you should be running 4 CPUs and 16GB of ram. Otherwise you are going to find v7 to be very slow on anything less.

You can take the long road to get to v7 by downloading and upgrading each major release. You can find them all on source forge. You really only need to upgrade from v4.2.2 to v5.0.2. That should take care of the log in issue. In v5, there is a script to bridge that change in security from the users table to adding the users_secure. Each user will need to log in at least once so that script can run and upgrade their account.

Once you do that, then you can leap from v5.0.2(x) to v7.0.0(2).

#5

OK, now that is interesting. Resources aren’t an issue, 64 CPU cores, 24GB of RAM, all SAS storage, and it’s configured to allocate most of the horsepower to MariaDb.
4.2.2 might be the key there, as it’s starting out on 4.1.1, and though it seems like the 4.1.1 → 5.0.0 initial step of the upgrade is completing, maybe that’s not really the case. Getting the 4.2.2 upgrader to run could be problematic, might have to set up a temporary virtual environment with an old LAMP stack and run it just long enough to get past that step.
Will run some tests again this week and see if I can find anything new, thanks for the tips!

#6

Would rec at least skipping 6.0 and 6.1 (at least 6.0) in the upgrade since the uuid upgrading mechanism in 7.0 is magnitudes faster (thanks to @adunsulag!).

1 Like
#7

That is correct. If you can set up an old environment to run the older LAMP stack that would be a way to go without having to do any coding to solve upgrade issues.

@brady.miller is right to skip 6.0. But I still suggest that once you can get from from 4.x to 5.x the login hurdle will be crossed. But be sure to have the staff all log into the 5.x before moving on.
You should be able to leap from 5.x to 7.

I still experience issues with the UUID build process where the system in the top box will show timed out but the progress bar keeps moving. Once I get the red bar in the top box then I set the upgrade level to 6.1.0 and start it again. It has taken 5hrs to get through the UUID process on my last upgrade.

1 Like
#8

OK! Thanks for the tips everyone! Running in my test environment, I got from 4.X, to 5.0.0, tested a few user logins, and then made the jump, to 7.0.0.
You were exactly right about waiting until the UUID queries hung up, and, then starting again from 6.1.0. Then applied Patch 2 for V7 and almost all good. Nasty bug with NewCrop in V7, and there’s the persistent issue with encryption/decryption, but that’s a different discussion. Just wanted to say thank you and much appreciated for the advice given here.

1 Like
#9

Are there any shortcuts (ie: skips) that I can do in upgrading from V3.2.0 to V7.0.0 ??
Do I have to do every point upgrade? ie: V3.2.0->V4.0.0 and then V4.0.0->V4.1.1 etc

…or can I get myself to V4.0.0 and then skip directly to V5.0.0, V6.0.0 and finally V7.0.0 ???

#10

welcome @robertlight , @juggernautsei has some good advice above, take it 1 by 1 until 5.0.1 or so