@rickzimm
The issue here is the routine that queries keys table to check if the key exist is returning they don’t so, it tries to insert. I suspect the keys table is corrupt so try to run
CHECK TABLE `keys`; ALTER TABLE `keys` ENGINE = InnoDB; OPTIMIZE TABLE `keys`; This will really recreate and analyze insteadFLUSH TABLE `keys`; btw: check your collations
Hi @sjpadgett ,
I do not have the proper RELOAD privileges to run this in PHPmyAdmin, so I asked my provider to solve this, as soon as I have the information or right privileges from them I will get back to you.
What do I have to do for: check your collations?
BTW:
I installed a new (clean) openemr vs 6.0.0 (2), checked that everything worked as it is supposed to be, uploaded the (old) database from the openemr version which are giving the errors in the new openemr version, and replaced the correct keys (sixa and sixb) in the new openemr.
After logging in, in the new openemr version, the same errors still persist …
Maybe this will help you find the solution …
huh, something’s not making sense then, since if those are commented then the practice settings wouldn’t call the cryptogen function
From the error log, it looks like src/Common/Crypto/CryptoGen.php - line 433.
Disclaimer - Workaround till root cause is hunted down by the project angels.
Hi @mdsupport,
Can you show me how I have to insert those lines in: sqlStatementNoLog(“INSERT INTO keys (name, value) VALUES (?, ?)”, [$label, base64_encode($newKey)]);
Is this what you mean?
sqlStatementNoLog("INSERT INTO ‘keys’ (‘name’, ‘value’) VALUES (?, ?), ON DUPLICATE KEY UPDATE ‘value’ = ?, INSERT IGNORE INTO ‘keys’ (‘name’, ‘value’) VALUES (?, ?), [$label, base64_encode($newKey)]);
Hi @sjpadgett,
Attached the results of SQL query to the database …pr. screen results query.pdf (105.6 KB)
Can you make something out of it?
will become if you want new value to replace current record -
sqlStatementNoLog(“INSERT INTO keys ( name , value ) VALUES (?, ?) ON DUPLICATE KEY UPDATE value=?”, [$label, base64_encode($newKey), base64_encode($newKey)]);
Be sure to save the backup in case something strange happens…
Hi @mdsupport,
Replaced new value for current: in openemr by “practice settings” it’s says: unknown, actually for all menus.
Replaced new value for back -up (only CryptoGen.php), it didn’t worked out well: WSOD
Is it enough to only replace the database back up or also openemr itself?
Her is my error_log:
[Sat Jul 17 10:23:41.889921 2021] [fcgid:warn] [pid 7409:tid 140668265543424] [client 2a02:a45c:3bef:1:6000:873:b6eb:db00:40696] mod_fcgid: stderr: OpenEMR Error : Key creation is not working - Exiting., referer: https://www.domainname.nl/openemr/controller.php?practice_settings&pharmacy&action=list
[Sat Jul 17 10:23:51.413342 2021] [fcgid:warn] [pid 7315:tid 140668257150720] [client 2a02:a45c:3bef:1:6000:873:b6eb:db00:40754] mod_fcgid: stderr: OpenEMR Error : Key creation is not working - Exiting., referer: https://www.domeinname.nl/openemr/interface/main/tabs/main.php?token_main=onFEjAhJw69X5JY8SCSwULJ41oVC2FXmg1rBJcq0
hi @rickzimm, Can you try reinstall with
collation utf8mb4_general_ci
and server charset utf8Server charset: UTF-8 Unicode (utf8mb4)
Whenever you make changes ensure you delete sixa and sixb to regenerate. That’s why the errors.
Also, whatever the collation was that generated the keys or DB for that matter, should be the same when you upgrade.
Unless you reformate your DB to different collation which I would not recommend.
Use the same sqlconfig from previous openemr and use the same collation when creating the import.
My experience is that changing collations to something different than collation used to create data is problematic.
Hi @sjpadgett, @stephenwaite and @mdsupport,
Thank you Jerry the deleting of sixa and sixb did the trick!
However, this line didn’t work out: sqlStatementNoLog(“INSERT INTO keys ( name , value ) VALUES (?, ?) ON DUPLICATE KEY UPDATE value=?”, [$label, base64_encode($newKey), base64_encode($newKey)]);
The WSOD was fixed by deleting the sixa and sixb files.
The result, after deleting and selecting a menu item, is “unknown”. It only works again when deleting sixa and sixb again.
@rickzimm Sorry, I have not studied the crypto logic. But looks like we need to have a single script that can be called from os command line by an admin in trouble that can validate and optionally reset the necessary files+records.
I changed all the collations in utf8_general_ci … openemr still works, however with the same issues.
What mysql/mariadb version are you using?
What do you see if run the following query via mysql/phpmyadmin commandline:
SELECT `value` FROM `keys` WHERE `name` = 'sixa';
(btw, if this is a production environment, don’t paste the value here since it is a encryption key)
also what do you see for following queries from mysql/phpmyadmin commandline:
desc `keys`;
show keys from `keys`;
(btw, after looking at above commands, i should of not named this table keys since keys is a mysql/mariadb keyword; ok, but need to ensure we always encircle it with the backtics)